LLM 推論の本番運用:KV キャッシュとバッチングによるコスト最適化の実務
エンタープライズAI

LLM 推論の本番運用:KV キャッシュとバッチングによるコスト最適化の実務

要点 LLM を本番サービスに組み込む段階で、コスト管理の中心はモデル選定から推論スタックの最適化に移る。KV キャッシュのメモリ効率、動的バッチング (continuous batching) によるスループット向上、投機的デコ…

  • 5 分で読了
要点

LLM を本番サービスに組み込む段階で、コスト管理の中心はモデル選定から推論スタックの最適化に移る。KV キャッシュのメモリ効率、動的バッチング (continuous batching) によるスループット向上、投機的デコーディングによるレイテンシ削減——これらの実装差が、同じモデル・同じハードウェアでもトータルコストで数倍の差を生む。vLLM・TGI・SGLang などのオープンソース推論エンジンの内部設計を理解することが、実運用の意思決定を左右する。

推論コストの内訳を分解する

LLM 推論のコストを分解すると、主要な変数は 3 つに整理できる。第 1 に、モデルサイズと量子化 (FP16 vs INT8 vs INT4)。第 2 に、GPU の稼働率——バッチングでどこまで並列処理できているか。第 3 に、リクエストごとの入出力トークン長の分布である。API 経由 (OpenAI・Anthropic・Google) を利用する場合はトークン単価に集約されるが、自社ホスティングを検討する規模の組織では、この 3 変数の設計が推論コストを直接決める。

NVIDIA が公開している H100 の性能特性と、コミュニティが検証した実測ベンチマークを組み合わせると、7B パラメータクラスのモデルであれば、単一 H100 で毎秒 1,000 トークン級のスループットが達成できる構成が現実的である。ただし、これは連続的なバッチング前提の数字で、リクエストがまばらな環境では稼働率が下がり、単価が跳ね上がる。

KV キャッシュがコストに与える影響

Transformer ベースの LLM は、生成中の各トークンについて過去のトークンの Key・Value を保持する KV キャッシュを持つ。このキャッシュのメモリ消費が、実運用コストの大きな部分を占める。7B モデル・シーケンス長 2,048・FP16 で、リクエストあたり数 GB の KV キャッシュが必要になるのが目安である。

vLLM が導入した PagedAttention は、KV キャッシュを OS のページング機構と類似の方式で管理し、メモリの断片化を解消することで、同じ GPU 上で扱えるリクエスト数を大幅に増加させた。UC Berkeley の元論文と実装が公開されており、その後多くの推論エンジンが類似のアプローチを採用している。KV キャッシュの実効利用率を上げることは、モデル置き換え以上のコスト削減効果を生む場合がある。

もっとも、PagedAttention のような最適化は実装の透明性が失われやすく、レイテンシ分布の予測が難しくなる副作用もある。SLA 上、P99 レイテンシに厳しい要件がある場合、単純な実装のほうが動作が予測可能で運用しやすい面がある。

動的バッチングによるスループット改善

従来の静的バッチング (バッチ内のすべてのリクエストの生成が終わるまで待つ) は、生成長が異なるリクエストが混在すると GPU 稼働率が大きく落ちる。Continuous Batching (Iteration-level Scheduling) は、生成完了したリクエストのスロットを即座に新規リクエストで埋めることで、GPU の休止時間を最小化する。

Hugging Face TGI・vLLM・SGLang などの主要推論エンジンは、いずれもこの継続的バッチングをコア機能として実装している。導入前と比較して、同じハードウェアでスループットが 3〜5 倍に向上する事例が複数のベンチマークで報告されている。ただし、これらの数値は、リクエスト分布・平均トークン長・ハードウェア構成に強く依存し、自社ワークロードで実測すべき性質の指標である。

投機的デコーディングの実務的な適用範囲

投機的デコーディング (Speculative Decoding) は、小さな「ドラフトモデル」で複数トークンを先読みし、大きな本モデルで一括検証することで、生成レイテンシを短縮する手法である。Google DeepMind が示した理論と、その後の実装で、平均 2〜3 倍のレイテンシ削減が観察されている。

実務的な適用の観点では、次の 2 点に注意が要る。第 1 に、ドラフトモデルの品質次第で、投機的デコーディングの効果が大きく変動する。第 2 に、追加の GPU メモリを消費するため、KV キャッシュや動的バッチングとのメモリ配分のバランスが必要になる。導入を判断する際には、自社ワークロードでの実測が不可欠である。

API 利用と自社ホスティングの選択

推論スタックの最適化は、ある程度以上の規模——目安として月間数億トークンを超えるワークロード——で自社ホスティングを検討する意義が出てくる。それ未満の規模では、API 単価の透明性・スケーリングの容易さから、外部 API 利用のほうが総保有コストで有利である場合が多い。

ただし、業務上の要件で自社ホスティングが不可避となる状況もある。データが外部 API に送信できない業種——金融・医療・防衛関連——では、規模の閾値に関わらず自社ホスティングを選ぶ必要が生じる。この場合、推論スタックの最適化知識を組織内に蓄積することが、長期的なコスト管理の前提になる。RAG と Fine-tuning の選択基準で扱うドメイン特化のアプローチも、自社ホスティング前提での議論と重なる領域である。

結論:モデル比較から推論スタック設計へ

「どのモデルを使うか」の議論から、「どのスタックでモデルを動かすか」の議論へ、実運用の関心は移りつつある。GraphQL Federation と REST API ゲートウェイの選択基準で扱う API 層の設計と同様、上流の技術選定だけでなく、実行基盤の最適化余地を初期段階から検討する姿勢が、投資対効果を左右する。生成 AI エージェント時代の RPAで議論した業務自動化の再編も、推論コストの管理が土台になる。

関連記事