プラットフォームチームのためのLLM推論セルフホスティング実践ガイド

組織がサードパーティAPIへの依存度を下げ、機密データのセキュリティを強化する中、プラットフォームチームは大規模言語モデル（LLM）を社内で運用する役割を担うことが増えています。Modelplaneによる新しい技術ガイドは、2026年10月時点のプロダクション環境におけるGPU管理、メモリの最適化、パフォーマンス測定など、推論エンジニアリングの必須プラクティスを詳述しています。

何が起きたか

高品質なオープンモデルの台頭により、多くの企業にとってセルフホスティングは、ホスト型APIに代わる現実的な選択肢となりました。Hugging Faceには200万を超えるモデルが公開されており、DeepSeek R1などのリリースも競争力のある性能を発揮しているため、企業は自社インフラを構築してレイテンシ、稼働率、データ所在国を制御できるようになりました。この変化により、プラットフォームチームは単に外部エンドポイントを消費するだけでなく、モデルサービングのライフサイクル全体を管理する「推論チーム」へと変貌を遂げています。

API支出が大幅に増加した場合や、特定の信頼性およびデータガバナンス要件がベンダーの提供範囲を超える場合、セルフホスティングは経済的に魅力的になります。高ボリュームの処理において、社内でのモデル実行は商用APIと比較してコストを約80パーセント削減できる可能性があります。このコスト削減の主な要因はハードウェアの改善ではなく、より効率的なサービング戦略です。ソフトウェアの改善により、固定されたAI機能のコストは毎年ほぼ10分の1に低下しています。

同ガイドは、推論エンジニアリングとは本質的に、新しいワークロードに対するサイトリライアビリティエンジニアリング（SRE）であると強調しています。スケジューリング、キャパシティプランニング、オブザーバビリティに関するスキルはそのまま転用できますが、指標は変化します。例えば、オートスケーリングはCPU負荷ではなく、キューの深さやキー・バリューキャッシュの使用状況に応じて対応する必要があり、ロールアウトにはモデルバージョン、ハードウェアタイプ、エンジンビルドの複雑なマトリクスが含まれます。確立された役職名はまだありませんが、内部AIインフラを採用する企業が増えているため、需要は拡大しています。

仕組み

推論エンジンは、モデルの重みをGPUメモリに読み込み、セッションごとの状態を管理するステートフルサーバーとして機能し、特殊なアクセラレーターを持つデータベースに似ています。スタックは4つの層で構成されます。演算を行うカーネル、作業をスケジュールするエンジン、デプロイメントを管理するコントロールプレーン、トラフィックをルーティングするゲートウェイです。vLLMやSGLangなどのエンジンが主要な処理を担当し、静的な重みを応答性の高いAPIに変換すると同時に、重要なリソースであるGPUメモリを管理します。

メモリ管理は推論における中心的な課題です。モデルの重みは固定されており、すべてがGPUメモリ内に存在する必要がありますが、キー・バリュー（KV）キャッシュは会話ごとに動的に増加します。KVキャッシュは、進行中のすべてのトークンのアテンションキーと値を保存し、モデルが履歴を再計算せずに済むようにします。そのサイズはコンテキスト長と同時接続ユーザー数に依存し、単一のGPUが処理できるリクエスト数の制限要因となることがよくあります。例えば、半精度の700億パラメータモデルは、重みのために大量のメモリを必要とし、キャッシュ用に限られたスペースしか残されません。

リクエスト処理は、異なるボトルネックを持つ2つの明確なフェーズで行われます。プリフィルフェーズは、最初のトークンを生成するために全体の入力を並列で読み取り、計算能力によって制限されます。デコードフェーズは、後続のトークンを1つずつ生成し、重みと増加するKVキャッシュを読み取るため、メモリ帯域幅によって制限されます。最適化は正しいボトルネックに対して行う必要があります。プリフィルを高速化する手法が、必ずしもデコード速度を向上させるわけではありません。最初のトークンまでの時間（Time to First Token）や秒あたりのトークン数などの指標は、エンジニアが特定のワークロードでどのフェーズをチューニングすべきかを識別するのに役立ちます。

主要な詳細

• メモリ計算が重要: パラメータあたり2バイトの80億パラメータモデルは、重みのみで約16 GBのGPUメモリを必要とし、残りはKVキャッシュとランタイムオーバーヘッドのために確保されます。
• 2フェーズ処理: プリフィルは計算バウンドであり、最初のトークンまでの時間を決定します。一方、デコードはメモリバウンドであり、ストリーミング速度を決定します。
• コスト計算: 100万トークンあたりのコストは、GPUの時給をスループットで割ることで算出され、ホスト型APIの価格と直接比較できます。
• エージェントワークロードの違い: コーディングエージェントは長く反復的なプロンプトを送信し、中央値サイズが59,000トークンに達するため、プレフィックスキャッシュが非常に効果的です。
• 量子化の利点: 重みを少ないビット数で保存すると、KVキャッシュ用のメモリが解放され、モデルアーキテクチャを変更することなく、より多くの同時接続ユーザーに対応できます。
• スケーリングシグナル: オートスケーリングは、CPUまたはGPUの使用率パーセンテージだけでなく、キューの深さとKVキャッシュの使用率に基づいてトリガーされるべきです。

なぜ重要なのか

ソフトウェア開発者にとって、推論エンジニアリングを理解することは、製品のパフォーマンスとコスト構造に対するより大きな制御を可能にします。外部APIへの依存は、エンタープライズアプリケーションでは受け入れられない可能性のあるレイテンシの変動やデータプライバシーリスクをもたらします。推論スタックを習得することで、チームは低レイテンシのインタラクティブチャットや高スループットのバッチ処理など、特定のワークロードパターンに合わせてインフラをカスタマイズできます。

この変化は採用やチーム構成にも影響を与えます。推論関連の役割が一般的になるにつれ、プラットフォームエンジニアはGPUメモリ管理やモデル固有のオブザーバビリティを含むようスキルセットを更新する必要があります。最適化の利益の大半がハードウェアのアップグレードではなくソフトウェア効率から得られることを認識すれば、リーダーは適切なツールとトレーニングに投資できます。この知識は、ユーザー需要の増加に伴い予測可能な形でスケールする、回復力のあるAI機能をチームが構築できるようにします。

実施できること

• 現在のAPI支出を監査する: 100万トークンあたりのコストを計算し、現在のGPU価格を用いたセルフホスティングの推定コストと比較してください。
• 小規模モデルから始める: より小さなオープンモデルをデプロイし、重み読み込み、KVキャッシュ管理、モニタリングといった運用の基本を学んでください。
• 主要指標を監視する: ユーザー体験とシステム効率を理解するために、最初のトークンまでの時間、トークン間レイテンシ、グッドプットを追跡してください。
• プレフィックスキャッシュを有効にする: アプリケーションが反復的なプロンプトやエージェントワークフローを含む場合、冗長な計算を減らすためにエンジンがプレフィックスキャッシュを使用していることを確認してください。
• メモリオーバーヘッドを計画する: 生のモデル重みや推定キャッシュだけでなく、ランタイムオーバーヘッドと断片化のために十分なGPUメモリを残してください。
• SLOを明確に定義する: ワークロードがインタラクティブ型かバッチ指向型かに基づき、レイテンシと可用性に関するサービスレベル目標（SLO）を設定してください。