Skip to Content
Docs05. 運用セルフホスト推論の実務
上級self-hostinginference-servinggpu更新: 2026-08-18この記事の誤りを報告

この記事の音声は準備中です。

音声の一覧・再生リストへ

セルフホスト推論の実務

この記事の目的

「API を借りる」から「自分で提供する」へ切り替える判断と、推論サービングの設計・運用ができるようになります。セルフホストが本当に得か(「原価が下がる」とは限らない構造)を見極め、推論サーバーの類型と代表例・スループットの作り・GPU メモリAgent が「覚えている」ように見えるデータの総称。短期記憶(コンテキスト)・作業状態・長期記憶(外部ストレージ)の 3 層に分けて設計する。見積り・量子化モデルの重みを低い数値精度(INT8・INT4 等)で表現してサイズを縮める手法。VRAM とメモリ帯域の負荷が下がり、同じ GPU により大きいモデル・多い同時実行を載せられる。精度を下げるほど品質が落ちうるため、量子化後の品質は自社タスクで検証してから使う。の運用判断・監視・モデル更新までを、選定判断に使える形で持ち帰れる状態を目指します。ハードウェアの基礎は GPU・AI ハードウェアの基礎 が前提です。

対象読者

前提知識

本文

概要: 分担と「なぜ自ホストするのか」

本記事はモデルを自分で提供する層を扱います。どのモデルを選ぶかは モデル選定ガイド / 主要 LLM の全体像、アプリ側の容量・フォールバック設計は デプロイとスケーリング が正本です。ここでは「借りるより自ホストが適切な場面はどこか、そのときどう作るか」に集中します。

セルフホストの判断: 「原価が下がる」とは限らない

まず判断です。セルフホストは、コスト削減が動機なら裏切られやすい選択です。

  • 向く動機: データ主権(データを外部に出せない)・閉域網(外部 API に到達できない 企業システム環境の制約と対応)・カスタムモデル(FT した独自モデルを動かす)・特定のレイテンシ要件
  • コストの損益分岐: 「API より原価が下がる」は、高い稼働率が前提です。GPU は借りても買っても高価で、遊んでいる時間は損失です。低・中程度の利用量では、従量課金の API のほうが安いことが多いです
  • 隠れコスト: GPU 費用に加え、運用人件費・可用性確保(冗長化)・モデル更新の手間がかかります(GPU・AI ハードウェアの基礎の TCO)
  • 結論: セルフホストは「安くなるから」ではなく「外に出せない/借りられないから」を主動機に選ぶのが健全です。コスト目的なら、まず損益分岐を稼働率込みで計算します

推論サーバーの類型と代表例

セルフホストの中核が**推論サーバー(サービングエンジン)**です。大きく 2 類型あり、用途で選びます(具体のエンジンは変化が速いため 2026-08 時点の代表例)。

類型用途代表例(2026-08 時点・OSS)
高スループット系(サーバー GPU)多数同時リクエストを高効率で捌くvLLM・SGLang・LMDeploy・NVIDIA TensorRT-LLM(NVIDIA 専用)。汎用サーバーの Triton(backend 経由)
軽量・ローカル系個人・端末・小規模での実行ローカル・オンデバイス LLM の実務を参照
  • サーバー用途では、上記の高スループット系エンジンが定番です。多くが連続バッチング・KV キャッシュ生成中に各トークンの中間表現(Key / Value)を保存・再利用する仕組みで、プロンプトキャッシュの実体。中間表現は先頭からの並びに依存するため、キャッシュは前方一致でしか効かない。の効率管理・量子化・OpenAI 互換 API を備え、既存の OpenAI クライアントからそのまま叩けることが多いです(2026-08 時点で vLLM・SGLang・LMDeploy に加え、TensorRT-LLM も trtllm-serve コマンドで OpenAI 互換 API を明記)
  • 顔ぶれは入れ替わる: かつて定番だった Hugging Face TGI は、メンテナンスモード告知を経て 2026-03 にリポジトリがアーカイブされました(README は代替として vLLM・SGLang・llama.cpp・MLX を案内)。採用時は機能だけでなく開発が継続しているかも確認します
  • ハードウェア束縛に注意: NVIDIA 専用のエンジン(TensorRT-LLM)と、より広いハードに対応するものがあります。手持ち/調達予定の GPU に合うかを確認します
  • ライセンスは主要 OSS の多くが寛容(Apache-2.0・MIT・BSD 系)ですが、採用時に最新の公式情報で確認します(下記 TODO)

スループットの作り: 連続バッチングと KV キャッシュ

セルフホストで「速く・安く」回す鍵は、GPU を遊ばせないことです。中心が 2 つの仕組みです(理論の詳細は本記事の範囲外)。

  • 連続バッチング(continuous batching): 複数リクエストをまとめて処理し、リクエストの開始・終了が揃わなくても空いたスロットに次を詰めてGPU を遊ばせない方式。1 件ずつ処理するよりスループットが大きく上がります
  • KV キャッシュのメモリ管理: 生成済みトークンの中間状態(KV キャッシュ 注意機構とコンテキストウィンドウの仕組み)を効率よく管理し、VRAM を無駄なく使う仕組み(ページ単位の管理など)。長い文脈・多数同時実行でメモリを破綻させないための要点です
  • これらは前述の高スループット系エンジンが備える機能で、自分で実装するものではなく、エンジンを選んで使うのが基本です

GPU メモリの見積り

セルフホストの容量計画は、VRAM が載るかから始まります。

  • 重み: パラメータ数 × 精度あたりのバイト数(FP16≈2・INT8≈1・INT4≈0.5 バイト)(GPU・AI ハードウェアの基礎)
  • KV キャッシュ: 同時実行数 × 文脈長に比例して増えます。多数同時・長文脈ほど KV キャッシュが VRAM を圧迫し、これを見落とすと「モデルは載ったのに同時実行数を上げたら溢れる」ことになります
  • 作業領域: 実行時の一時メモリも上乗せされます
  • 見積りは「重み + 想定同時実行・文脈長での KV キャッシュ + 余裕」で行い、ピーク時に溢れないかを確認します

量子化の運用判断

量子化(quantization) で VRAM を節約できますが、運用では品質検証とセットで判断します。

  • 効果: 精度を下げると VRAM とメモリ帯域の負荷が下がり、同じ GPU により大きいモデル・より多い同時実行を載せられます
  • リスク: 精度を下げるほど品質が落ちうる。落ち方はモデル・タスク・量子化手法で異なります
  • 運用判断: 「どの量子化レベルなら自社タスクの品質基準を満たすか」を評価で確かめます(Agent 評価の基礎)。「載るから」で品質未検証のまま量子化を本番投入しないことが肝心です

監視

セルフホストは、API では見えなかった指標を自分で監視します。

モデル更新の運用

セルフホストでは、モデルの更新も自分の運用になります。

実務での注意点

アンチパターン

  • コスト削減目的でセルフホストする → 低稼働率で API より高くつく → 損益分岐を稼働率込みで計算し、主動機はデータ主権・閉域網に置く
  • 重みの VRAM だけ見て KV キャッシュを忘れる → 同時実行を上げた途端に溢れる → 想定同時実行・文脈長での KV キャッシュを見積もる
  • スループット機能を自作しようとする → 連続バッチング・KV 管理の再発明で消耗する → 成熟した推論エンジンを選んで使う
  • 量子化を品質未検証で本番投入する → 品質が静かに落ちる → 量子化レベルごとに自社タスクで品質を検証する
  • モデル更新を無停止・切り戻し設計なしで行う → 更新失敗が即障害になる → 並行稼働での切り替えと切り戻しを用意する

チェックリスト

  • セルフホストの主動機(データ主権・閉域網・カスタムモデル)を明確にした
  • コスト目的の場合、稼働率込みの損益分岐で API と比較した
  • 用途に合う推論エンジン(高スループット系)を、ハード束縛・API 互換・ライセンスで選んだ
  • 重み + 想定同時実行・文脈長での KV キャッシュ + 余裕で VRAM を見積もった
  • 量子化を使う場合、量子化レベルごとに自社タスクで品質を検証した
  • GPU 使用率・VRAM・スループット・キュー・末尾レイテンシを監視している
  • モデル更新を並行稼働での切り替え + 切り戻しで設計し、評価・キャッシュ・バージョニングと連動させた

関連トピック

参考資料

TODO・未確認事項

本文の未確認事項を参照してください。

AI の環境負荷とグリーン AIGPU・AI ハードウェアの基礎