計算資源とプロビジョニング
GPUキャパシティの確保、ノードプール、サービングエンジンとの互換性を保ったドライバとCUDAスタック。
AI推論ガイド
インフラと運用
モデルを動かし続けるために、その周囲で必要になるすべてを扱います。プラットフォームの構成要素、モデルの変更を安全に出すための運用規律、急激な負荷変動に対するスケーリング、リージョンとクラウドをまたぐ運用、そして複数のモデルを1つの製品にまとめる方法です。
推論インフラに含まれるもの
サービング層
推論エンジンと、その前段に置くゲートウェイ：認証、クォータ、ルーティング、バックエンド間のフェイルオーバー。
オーケストレーションとスケーリング
モデルをハードウェアに割り当てるスケジューリング、オートスケーリングの方針、ワークロード間の動的な配分。
バージョン管理とレジストリ
どのモデル、重み、プロンプト、設定がどこで稼働しているか。この問いに答えられることが、安全に変更を加えるための前提になります。
セキュリティ
呼び出しとモデル成果物に対するアクセス制御、プロンプトと出力の保護、誰が何を変更したかの監査。
コスト管理
ワークロード別・機能別の提供コスト。効かせられるレバーは、モデルの選択、ハードウェアの適合、バッチング、ルーティング、スケーリング方針です。
InferenceOps：モデルの変更を安全に出す
モデルのデプロイをコードのデプロイと同じ厳密さで扱う運用の実践です。障害がクラッシュではなく挙動として現れる成果物に合わせて調整します：
- リリースパイプライン： トラフィックが到達する前にリリース前の検証（品質リグレッションスイート、レイテンシとトークンレートの確認）を行う、標準化されたデプロイのワークフロー。
- 段階的なロールアウト： 候補バージョンを実トラフィック上で稼働中のバージョンと比較するカナリアまたはブルーグリーンのリリース。比較結果に自動ロールバックを接続します。
- フォールトトレランス： 予算付きのリトライ、タイムアウト、サーキットブレーカー、負荷の切り捨てを備え、劣化した1つのモデルやプロバイダーが連鎖しないようにします。
- ガバナンス： ライフサイクル状態、所有者、監査証跡、コンプライアンス用メタデータを持つレジストリ。リクエストからモデルのバージョンまで遡れるデプロイのトレーサビリティ。
- コストの衛生管理： アイドル状態のGPUの検出と稼働率のレビュー。使われていない予約済みキャパシティは、最も静かに予算を溶かす原因です。
高速なスケーリングとコールドスタートの問題
推論のトラフィックはバースト的で、GPUの利用時間は多すぎても少なすぎても高くつきます。過剰にプロビジョニングすれば費用が無駄になり、不足すればリクエストを落とします。LLMの弾力的なスケーリングが従来のオートスケーリングより難しい理由は2つあります：
コールドスタートが長い
新しいレプリカは3つの支払いを順番に負担します。GPUインスタンスのプロビジョニング、大きなコンテナイメージの取得、そして数十ギガバイトの重みをストレージからGPUメモリへ読み込む処理です。緩和策は各段階を狙います：ウォームプール、イメージのキャッシュと軽量化、高速なローカルストレージへの重みの配置や並列でのストリーミング。ゼロへのスケールはアイドル時のコストを抑えますが、最初のリクエストにコールドスタートの全負担がかかります。ワークロードごとに判断してください。
分かりやすい指標ほど誤解を招く
CPU使用率はGPUに律速されたサービスについてほとんど何も語らず、報告されるGPU使用率は、チップが有用な仕事をほとんどしていなくても高く見えることがあります。代わりに需要側のシグナルでスケールします：キューの深さ、処理中の同時実行数、リクエストレートを、エンジンが実際に達成しているバッチサイズと関連付けて見ます。
分散、マルチリージョン、マルチクラウド
- 分散推論 には2つの規模があります。1つはGPUとノードをまたいで1つのモデルをシャーディングすること（テンソル並列、パイプライン並列、エキスパート並列。詳しくは サービングの最適化を参照）。もう1つは、レプリカ群をゾーンとクラスタに分散し、状態を考慮したスケジューリング、ヘルスチェック、障害復旧を備えることです。
- マルチリージョンやマルチクラウドに踏み切る理由： プロバイダーやリージョンによるGPUの逼迫と価格差、ユーザーのレイテンシ、フェイルオーバー、データ所在地の法規制（GDPRのような制約は一部のデータを特定の管轄に固定します）、そしてロックインの回避。
- 必要になること： 各サービング拠点の近くにモデル成果物を複製すること、キャパシティとコンプライアンスを考慮したグローバルロードバランシング、自動フェイルオーバー、そして拠点ごとのコスト配賦を伴う統一された可観測性。
- 支払う代償： リージョンをまたぐトラフィックには実際のレイテンシと下り転送料がかかり、クラウドを1つ増やすたびに運用面の対象範囲が膨らみます。既定では集約し、理由を挙げられるときにだけ分散してください。
複数モデルのパイプライン
本番の機能が単一のモデルで完結することはまれです。検索拡張された回答は、埋め込みモデル、リトリーバー、多くの場合はリランカー、生成モデル、安全性チェックを連結します。ドキュメントAIはOCR、レイアウト解析、分類、要約を連結し、マルチモーダルなアシスタントはモダリティごとのエンコーダを加えます。段階ごとに必要な能力、適したハードウェア、スケーリングの挙動が異なる場合、専門特化したモデルを組み合わせるほうが一枚岩のモデルより優れます。
- トポロジー：逐次的な段、マージを伴う並列のファンアウト、そしてそれらの間の条件付きルーティング。
- 各段は独立してスケールさせ、独立して配置します。小さな分類器に、生成モデルと同じGPUクラスは必要ありません。
- グラフ全体でレイテンシ予算を明示的に配分し、段の間のインターフェースを安定させます。段ごとの障害モードが観測できなければ、原因の切り分けは当て推量になります。
- パイプライン並列（1つのモデルを段に分割すること）とも、エージェント的なループ（モデルが動的に制御フローを決めること）とも異なります。パイプラインのグラフはアプリケーション側で固定されています。
自前構築か購入か、コストを正直に見積もる
自前で運用する推論インフラには、最初の見積もりにはめったに現れないコストが伴います。逼迫した市場でのGPUの調達、手作業で作り込んで調整するオートスケーリングと同時実行制御、プラットフォームなら標準で備わるのにDIYのスタックでは自前実装が必要になる最適化機能（プレフィックスキャッシュ、ディスアグリゲーション）、GPUを理解した可観測性、そしてエンジン、フレームワーク、ドライバのバージョンを歩調を合わせて動かし続ける依存関係のトレッドミルです。さらにアプリケーション側の接着剤（前処理と後処理、コネクタ、モデルごとのストリーミングとキャッシュの挙動）と、それらすべてを回すための希少で高価な人材が加わります。この継続的なエンジニアリングコストを、プラットフォームの利用料と、チームが作れずにいるものの機会費用と比べてください。正しい答えは規模によって変わるので、量が増えたら見直してください。