6.6 AIのインフラストラクチャと運用

概要と動機

AIのインフラストラクチャと運用とは、AIのワークロードが要求する専門的な計算、ストレージ、サービングのシステムを、費用対効果よく、確実に、観察可能に、プロビジョニングし、スケジュールし、運用する規律です。現代のAIは動かすのに高価です。大きなモデルの訓練とサービングには、希少なアクセラレーター(GPUとTPU)、高帯域のネットワーキング、検索のための大規模なベクトルストレージ(似たものを素早く見つけられるよう、データを数値のベクトルとして索引付けすること)、レイテンシとスループットに調整されたサービング層が必要です。このインフラストラクチャを正しく整えることは、持続可能にスケールするAIと、期待に届かないまま静かに予算を消費するAIとの違いです。

大きなチームにとって、中核の問題は規模、希少性、コストです。アクセラレーターは限られていて高価なので、スケジューリングと利用率が非常に重要です。遊んでいるGPUは燃やされるお金で、バッチ化の下手な推論はリクエストごとのコストを倍増させます。検索の多いアプリケーションには、成長しても速さを保つベクトルデータベースが必要です。生成AIのアプリケーションには、安全に運用し時間とともに改善するために、プロンプトのバージョニング、評価のパイプライン、オブザーバビリティ(ときにLLMOpsと呼ばれる)が必要です。共有のインフラストラクチャと運用の規律がなければ、すべてのチームが同じ戦いを戦い、コストが螺旋状に上がります。

政府と規制対象の組織は、データ主権、セキュリティ、予測可能な支出についての要件を加えます。機微なデータとモデルが管理された境界を決して出ないよう、オンプレミスやソブリンクラウドのデプロイが必要かもしれません。インフラの支出を予測して正当化し、セキュリティと可用性の標準を満たさなければなりません。これらの設定でのAIインフラの決定は複数年にわたる結果を伴うので、調達、セキュリティ、出口を念頭に置いて行ってください。

主要原則

アクセラレーターの計算を、買い占めるのではなく、スケジュールされ利用されるべき希少で高価な資源として扱います。
生の容量ではなく、有用な仕事の単位あたりのコストを最適化します。
モデルとハードウェアをタスクに合わせて適切なサイズにします。最大の選択肢が最も費用対効果が高いことはまれです。
バッチ化とキャッシュを第一級の技法として、レイテンシとスループットのためにサービングを設計します。
AIシステムを観察可能にします。コスト、レイテンシ、品質、エラーを継続的に追跡します。
プロンプトとモデルに、コードと同じ厳密さでバージョンを付けて評価します。
インフラストラクチャとサービングの選択で、可搬性を計画し、ロックインを避けます。

推奨事項

アクセラレーターの計算を計画して制御する

訓練と推論の需要を、形が異なるので別々に予測します。訓練はバースト的でスケジュール可能で、推論は継続的でレイテンシに敏感です。スケジューラーとクォータを使い、希少なGPUとTPUをチームにわたって共有し、ワークロードに優先順位をつけ、利用率を上げます。利用率を測定し、慢性的な遊びを直すべき問題として扱います。コストを制御するために、基準負荷には予約された容量を、バーストにはオンデマンドあるいはスポットの容量を混ぜます。より安価あるいは小さなアクセラレーター、軽量なモデルにはCPUでの推論で足りるかを検討します。あなたの規模でのコスト、データ主権のニーズ、バーストのパターンに基づいて、クラウド、オンプレミス、ハイブリッドの間で選び、出口の経路を保ちます。

検索のインフラストラクチャを築く: 埋め込みとベクトルデータベース

検索拡張アプリケーションのために、埋め込み(似たものを近くに置く数値のベクトル表現)を生成し、あなたの規模で高速な近似最近傍探索(すべてを網羅的に比べずに最も似たベクトルを見つけること)をサポートするベクトルデータベースに保存するインフラストラクチャを立ち上げます。三つを計画します。埋め込みの生成のコストとレイテンシ、文書が変わるにつれたインデックスの鮮度、インデックスを一貫して保つ運用の負担。専用のベクトルデータベース、既存のデータベースのベクトル対応の拡張、マネージドサービスのどれが、規模とロックインの許容度に最も合うかを評価します。検索の品質がアプリケーションの品質を直接決めるので、検索のレイテンシと再現率を監視します。

モデルのサービングを最適化する: バッチ化、キャッシュ、レイテンシ

サービングは、推論のコストとユーザー体験が決まる場所です。バッチ化を使って複数のリクエストをまとめて処理し、アクセラレーターのスループットを上げ、バッチサイズとレイテンシのバランスをとります。キャッシュを積極的に使います。同一あるいは意味的に似たリクエストをキャッシュし、埋め込みをキャッシュし、プラットフォームがサポートする所では、共有コンテキストの再計算を避けるためにプロンプトやプレフィックスのキャッシュを活用します。明確なレイテンシの目標を設定し、平均だけでなく裾のレイテンシを測定します。リクエストを適切なサイズのモデルにルーティングします。簡単なケースには小さなモデル、必要なときだけ大きなモデル。需要に合わせてサービングを自動スケールし、容量とコストの曲線を知るために、ローンチ前に負荷テストを行います。

LLMOpsを実践する: プロンプトのバージョニング、評価のパイプライン、オブザーバビリティ

プロンプトを、レビューとロールバックの能力を備えて、ソース管理下のバージョン管理された成果物として扱います。プロンプトやモデルが変わるたびに自動でオフラインのテストスイートを実行する評価のパイプラインを築き、リリース前に回帰を捉えます。本番を包括的に計装します。入力、出力、レイテンシ、トークン使用量、コスト、エラーを、サンプリングとプライバシーの安全策を伴って記録します。品質のシグナルとユーザーのフィードバックをオンラインで追跡します。このオブザーバビリティにより、劣化を捉え、コストを制御し、失敗をデバッグし、システムを安全に改善できます。本番の生成AIの運用の背骨です。

コストを容赦なく、観察可能に管理する

AIの支出をチームとユースケースに帰属させ、コストが見え、所有されるようにします。予算とアラートを設定し、リクエストごとと成果ごとのコストを監視し、最大のコストの要因を定期的にレビューします。持っているてこを引きます。モデルの適切なサイズ化、キャッシュ、バッチ化、プロンプトとコンテキストの削減、要件を満たす最も安いデプロイの選択。AIのコストは使用量に応じて驚くべき形でスケールしうるので、不愉快な驚きを避けるために、継続的なコストのオブザーバビリティが不可欠です。

トレードオフ: 長所と短所

決定	選択肢A	選択肢B	トレードオフ
計算の場所	クラウド	オンプレミス	弾力性と低い事前コスト対、制御、主権、定常状態の経済性
容量	予約	オンデマンド/スポット	予測可能なコスト対、柔軟性と中断のリスク
バッチサイズ	大きなバッチ	小さなバッチ	スループットとコスト対レイテンシ
モデルのサイズ	大きなモデル	小さなモデル	品質対コストと速度
ベクトルストア	専用のデータベース	既存のデータベースの拡張	規模でのパフォーマンス対、単純さと少ないシステム
キャッシュ	積極的	最小限	低いコストとレイテンシ対、鮮度と複雑さ

支配的なトレードオフは、コスト対レイテンシと品質です。バッチ化、キャッシュ、より小さなモデルはコストを削りますが、レイテンシを加えたり品質を下げたりしえます。正しいバランスは、アプリケーションの許容度によります。オンプレミス対クラウドは、制御と定常状態の経済性を、弾力性と低いコミットメントと交換し、データ主権のニーズと規模に大きく形づくられる決定です。

チームで議論すべき問い

今日の、有用な成果あたりのコストは何で、どのてこがそれを最も動かしますか。 生の容量とリクエストごとの平均は、重要な数字を隠します。一つの本物の価値の単位を届けるのにいくらかかり、それが使用量とともにどうスケールするか。大きなチームにとって、最適化されたデプロイと最適化されていないデプロイの支出の差は、しばしば数倍で、だからこの問いは、請求書についての漠然とした不安を、順位づけされた修正の一覧に変えます。チームとユースケースごとの現在のコストの帰属、リクエストごとと成果ごとの傾向、最大のコストの要因を持ち込んでください。見返りの順にてこを議論してください。モデルの適切なサイズ化、(プレフィックスと意味的なものを含む)キャッシュ、バッチ化、プロンプトやコンテキストの削減。政府では、複数年の支出を予測して正当化する圧力を加えてください。答えは、上位のコストの要因それぞれに、肩すくめではなく、所有者とてこを割り当てるべきです。
現在の推論プロバイダーが明日価格を倍にするか、ダウンしたら、どれだけ速く切り替えられますか。 静かなロックインは築くのが易しく、逃れるのが苦痛で、サービングのスタックは、それが最も深く隠れる所です。企業、特に政府にとって、可搬性は礼儀ではなく、調達と継続性の要件です。アーキテクチャを持ち込んでください。モデルが内部のインターフェースの背後にあるか、プロンプトと評価スイートが可搬か、プロバイダー固有のサービングの振る舞いにどれだけ依存しているか。見るべきシグナルは、評価スイートを第二のプロバイダーや第二のデプロイ先に対して誰かが実行したことがあるかです。切り替えに数か月かかり、中核の経路の書き直しを要するなら、それを今対処すべき設計上の欠陥として扱ってください。ソブリンやオンプレミスの選択肢が、ほとんど予告なく必須になるかもしれないからです。
今のアクセラレーターの利用率は何で、遊んでいるGPUとバッチ化されていない推論はどれだけ燃やしていますか。 アクセラレーターは希少で高価なので、慢性的な遊びとリクエストごとのサービングは、より多くの能力に資金を出せたはずの予算を静かに流出させます。チームにわたってGPUを共有する大きな組織にとって、この問いは、スケジューリング、クォータ、優先順位が利用率を実際に高く保つのか、買い占められ使われないハードウェアが普通なのかを露わにします。本物の利用率の数字、バッチ化とキャッシュの姿勢、平均だけでなく裾のレイテンシの測定を持ち込んでください。ユーザーは遅い裾を感じるからです。訓練と推論の需要が、形が異なるので別々に予測されているか、軽量なケースにはより小さなモデルやCPUでの推論で足りるかを議論してください。答えは、取り戻すべき具体的な遊びの容量と、バッチ化あるいは適切なサイズのモデルにルーティングする具体的なリクエストを指すべきです。
プロンプトやモデルの変更が出荷されるとき、静かな品質やコストの回帰がユーザーに届くのを何が止めますか。 サービングのスタックは、レイテンシと稼働時間では健全に見えても、返す答えが静かに悪くなったり、新しいプロンプトがリクエストあたりのトークン使用量を倍にしたりしえます。多くのグループがプロンプトを編集しモデルを独立して入れ替える大きなチームでは、ゲートされない変更は起こりかけている本番インシデントで、影響範囲は共有プラットフォームのチームごとに広がります。評価のカバレッジを持ち込んでください。どのプロンプトとモデルにオフラインのテストスイートがあるか、そのスイートがあらゆる変更で自動的に走るか、どの品質とコストの閾値がリリースをゲートするか、どれだけ速くロールバックできるか。プロンプトがレビュー付きでソース管理にあるのか、誰かがまだ稼働中のシステムプロンプトを手で編集できるのかを議論してください。企業と政府の設定では、各変更を監査証跡と名前のある承認者に結びつけてください。規制当局が「誰がこれを変え、何をテストしたか」と尋ねるとき、答えは、覚えているものではなく、記録されたものでなければならないからです。
クラウド、オンプレミス、ソブリンのデプロイをどう決め、パイロットではなく、本物の定常状態の経済性を値付けしましたか。 計算の場所の選択は、コストの曲線、データ主権の姿勢、何年もの出口の選択肢を設定しますが、しばしば、規模の本番とは似ても似つかないパイロットのクラウドの請求書に基づいて行われます。大きな組織では、弾力的なクラウドの容量は始めるのに安く、推論が継続的に動くと最大の単一項目になりえ、オンプレミスは低いコミットメントを、制御と定常状態の経済性と交換します。予測される訓練と推論の量、予約あるいは所有のハードウェアがオンデマンドに勝つ損益分岐点、データ所在地とセキュリティの制約、ハイブリッドを支持するバーストのパターンを持ち込んでください。政府と規制対象の設定では、ほとんど予告なく必須になるかもしれないソブリンクラウドあるいはオンプレミスの要件を量り、強いられた移行が中核の経路を書き直さないよう、アーキテクチャがモデルを内部のインターフェースの背後に保つことを確認してください。
AIの支出を実際に所有していて、各チームは自分が駆動するコストを見て、それに答えられますか。 AIのコストは、人々を驚かせる形で使用量とともにスケールし、帰属なしには、請求書は、どのチームもそれを縮める責任を感じない一つの不透明な数字として着地します。大きな組織では、誰も所有しないコストは、誰も最適化しないコストなので、問いは、支出が予算、アラート、成果ごとの傾向とともにチームとユースケースにタグ付けされているか、それとも財務がエスカレートしたときにだけ発見されるかです。コストの帰属モデル、チームごとの最大の要因、各所有者が制御するてこを持ち込んでください。モデルの適切なサイズ化、キャッシュ、バッチ化、コンテキストの削減。企業と政府の予算では、複数年のインフラ支出を予測して正当化する規律を加えてください。計算の請求書を項目ごとに説明できない公的機関は、レビューでそれを擁護するのに苦労するからです。

セクター別の視点

スタートアップ。 避けられるインフラストラクチャは所有しないでください。ホスト型の推論APIを呼び、簡単なリクエストを小さく安いモデルにルーティングして、大きなものは難しいケースのために取っておき、繰り返されるプロンプトのコストがゼロになるよう積極的にキャッシュします。自分で運用するのではなくマネージドなベクトルデータベースを使い、プロンプトをgitに保って各変更の前に短い評価スクリプトを実行し、暴走した請求書が痛む前に見えるよう、リクエストごとのコストを記録します。最も乏しい資源はエンジニアリングの注意なので、運用性を買い、切り替えを安く保ってください。

小規模事業者。 プラットフォームチームがないので、サービング、検索、オブザーバビリティを、人員を置くシステムではなく、すでに使っているツールの中で買うものとして扱ってください。透明で予測可能な価格のマネージドな推論とマネージドなベクトル検索を好み、初日から固い支出の上限と請求のアラートを設定します。選択を、買うか作るかとして誠実に枠づけてください。あなたの量では、GPUやベクトルインデックスの運用が元を取ることはまれで、ホスト型APIの背後の小さなモデルが、通常は労力のごく一部で必要を満たします。

大企業。 問題は、多くのチームにわたる共有の舗装された道のプラットフォームです。利用率を上げるスケジューラー、クォータ、優先順位を備えたプールされたアクセラレーター、標準のバッチ化とキャッシュ、適切なサイズ化のルーター、各チームとユースケースに帰属されたコスト。自動化された評価スイートでプロンプトとモデルの変更をゲートし、プロバイダーとデプロイ先が入れ替え可能であるようにインターフェースの層を標準化し、各グループが高価で使われないインフラストラクチャを再発明する代わりに、成果ごとのコストを第一級の指標として管理します。

政府。 データ主権、セキュリティ、予測可能な支出があらゆる選択を形づくります。機微なデータとモデルが管理された境界の内側に留まるよう、オンプレミスあるいはソブリンクラウドのデプロイを好み、調達で正当化できるクォータで部門にわたって希少なGPUをスケジュールし、複数年の支出を項目ごとに擁護できるよう容量を予測します。記録された監査証跡とともにプロンプトとモデルにバージョンを付けて評価し、コストと品質にわたる包括的なオブザーバビリティを保ち、新しいプロバイダーやソブリンのプラットフォームへの強いられた移行があなたを取り残さないよう、モデルを内部のインターフェースの背後に保ってください。

事例

スタートアップ。 AIライティング機能を動かす小さなスタートアップは、GPUを一台も所有せずに、請求書を健全に保ちました。ホスト型の推論APIを呼び、簡単なリクエストをより安い小さなモデルにルーティングし、大きなものを難しいケースのために取っておき、繰り返されるプロンプトへの答えをキャッシュしました。プロンプトを、各変更の前に走る短い評価スクリプトとともにgitに保存し、検索には自分で運用しなくて済むようマネージドなベクトルデータベースを使い、支出が驚きになる前に創業者たちが上昇を見られるよう、リクエストごとのコストを記録しました。

大企業。 トラフィックの多いLLM機能を動かすメディア企業は、推論のコストを大幅に削りました。簡単なリクエストを小さなモデルにルーティングし、難しいものに大きなモデルを取っておきました。繰り返されるクエリへの応答をキャッシュし、共有のシステムプロンプトにプレフィックスキャッシュを有効にしました。利用率を高く保つため共有のスケジューラーを通じてGPUを動かし、自動化された評価スイートが変更をゲートするようにすべてのプロンプトをgitでバージョン管理し、各プロダクトチームが自分の支出を所有するよう、リクエストごとのコストを計装しました。

政府。 厳格なデータ主権のルールを持つ国の機関は、機微なデータとモデルが管理された環境を決して出ないよう、AIシステムをオンプレミスでデプロイしました。クォータと優先順位で部門にわたって希少なGPUをスケジュールし、複数年の調達を正当化するために容量を予測し、公式の文書に対する検索のためのベクトル検索プラットフォームを築きました。プロンプトとモデルはリリース前にバージョン管理され評価されました。包括的なオブザーバビリティがコストと品質を追跡し、アーキテクチャは出口の経路を保ちロックインを避けるために、モデルを内部のインターフェースの背後に保ちました。

ビジネスケース: 動機、ROI、TCO

規律あるAIインフラストラクチャの動機は単純です。規模でのAIはコストがかかり、最適化されたデプロイと最適化されていないデプロイの差は、支出でしばしば数倍です。ROIは、より高いアクセラレーターの利用率、バッチ化とキャッシュによるリクエストごとの低いコスト、適切なサイズのモデル、過剰なプロビジョニングの回避から来ます。オブザーバビリティと評価のパイプラインは、高価なインシデントを防ぎ、安全な反復を可能にすることで元を取ります。

TCOは、アクセラレーターの計算(多くのワークロードで最大の項目)、ベクトルストレージ、サービングのインフラストラクチャ、ネットワーキング、それを動かすプラットフォームと運用の人員にわたります。投資しないコストと量ってください。暴走する推論の請求書、採用を損なう貧しいレイテンシ、スケールできないこと。政府では、主権やセキュリティの要件を満たせないコストを加えてください。リーダーシップへの論拠は、成果あたりのコストの傾向と、各チームが高価で使われないインフラストラクチャを築く代わりに、多くのチームが効率的にAIをデプロイできる舗装された道のプラットフォームを示すことで示します。

アンチパターンと落とし穴

遊んでいるアクセラレーター。 希少なGPUを、十分に利用しないチームに専有させること。
バッチ化もキャッシュもない。 すべてのリクエストを個別にサービングし、共有コンテキストを再計算すること。
既定で最大のモデル。 小さなもので足りる所で高価なモデルを使うこと。
コストへの盲目。 請求書が届くまで、帰属も予算もリクエストごとのコストの可視性もないこと。
バージョン管理されないプロンプト。 バージョニングも評価のゲートもなく、本番でプロンプトを変更すること。
裾のレイテンシの無視。 ユーザーが遅い裾に苦しむ間、平均のレイテンシを最適化すること。
静かなロックイン。 可搬性なしに、一つのプロバイダーのサービングのスタックの上に深く築くこと。

成熟度モデル

開始。 最も声の大きい人に反応するその場しのぎのGPUの割り当て、バッチ化もキャッシュもなし、請求書が届くまでコストの可視性なし、ライブで編集されバージョン管理されないプロンプト、最小限の監視。
発展。 共有のスケジューリング、キャッシュ、バージョン管理されたプロンプトを採用するチームもありますが、実践は組織全体で一貫しません。あるグループはバッチ化して評価し、別のグループはまだすべてのリクエストを個別にサービングし、プロンプトを手で変更します。
標準化。 文書化された舗装された道のプラットフォームが組織全体で徹底されます。クォータと優先順位を備えた共有のスケジューリング、標準のバッチ化、キャッシュ、適切なサイズ化、検索のためのベクトルインフラストラクチャ、あらゆるプロンプトやモデルの変更をゲートする自動化された評価のパイプライン、チームとユースケースへのコストの帰属。
管理。 プラットフォームがベースラインに対して測定され、制御されます。アクセラレーターの利用率、有用な成果あたりのコスト、裾のレイテンシ、検索の再現率、変更ごとの品質の回帰が、アラートと閾値とともに追跡され、コストは各チームが所有し、変更の実施/不実施は直感ではなく証拠で決められます。
オーケストレーション。 インフラストラクチャは継続的に改善し適応します。ルーティング、バッチ化、スケーリングがライブのコストと品質のシグナルに自ら調整され、需要と制約が変わるにつれて、チームの間、そしてクラウド、オンプレミス、ソブリンのデプロイ先の間で容量が再均衡され、可搬性はリハーサルされ、インフラの計画はプロダクト、セキュリティ、調達と統合されます。

議論のためのアイデア

優先度の高いワークロードを飢えさせずに、アクセラレーターの利用率をどう上げますか。
レイテンシの要件に対して、正しいバッチ化とキャッシュのバランスはどこにありますか。
オンプレミスやソブリンのデプロイは、いつクラウドに対するコストを正当化しますか。
多くのチームにわたって、AIの支出をどう帰属させ制御しますか。
プロンプトやモデルの変更が本番に届くのを、何がゲートすべきですか。
プロバイダーを切り替えられるほど、サービングのインフラストラクチャを可搬に保つにはどうしますか。

要点

アクセラレーターは希少で高価です。意図してスケジュールし、共有し、利用します。
バッチ化、キャッシュ、モデルの適切なサイズ化は、コストとレイテンシの主要なてこです。
検索アプリケーションには、よく運用された埋め込みとベクトル検索のインフラストラクチャが必要です。
LLMOps(プロンプトのバージョニング、評価のパイプライン、オブザーバビリティ)は、生成AIの運用の背骨です。
コストを観察可能に管理し、ロックインを避けるために可搬性を保ちます。

参考文献とさらなる読み物

Chip Huyen, Designing Machine Learning Systems.
Google, Site Reliability Engineering (Beyer, Jones, Petoff, Murphy, editors).
Jared Kaplan et al., Scaling Laws for Neural Language Models.
Reza Yazdani Aminabadi et al., DeepSpeed Inference: Enabling Efficient Inference of Transformer Models at Unprecedented Scale.
Woosuk Kwon et al., Efficient Memory Management for Large Language Model Serving with PagedAttention (vLLM).
Andriy Burkov, Machine Learning Engineering.