大規模言語モデル推論の最適化：KVキャッシュ・連続バッチング・投機的デコード

1. 概要

定義：大規模言語モデル（LLM）推論の最適化とは、学習済みモデルを提供する際に品質と安全性を維持しながら、応答遅延、スループット、メモリ使用量、トークン当たりコストを改善するモデル・ランタイム・システム設計である。

LLM推論は入力プロンプトを処理し、その文脈から次のトークンを繰り返し生成する。利用者からは一つの回答に見えるが、サーバーにはプロンプト長、出力長、同時実行数、モデル規模の異なる処理が到着する。したがってGPUを追加するだけでは、資源利用効率と応答体験の両立は保証されない。

自己回帰生成では、過去の文脈状態を保存して再計算を避けるKey・Valueキャッシュが重要となる。しかし、キャッシュは増加に伴いGPUメモリを占有し、長い文脈や多数の同時利用者の間でメモリ圧迫を生む。キャッシュ効率、要求スケジューリング、並列実行、品質低下を一体として調整する必要がある。

最適化の目的をスループットだけに限定できない。対話型システムでは最初のトークンまでの時間やトークン間遅延が重要であり、オフライン要約では総処理量とコストが重視される。応答品質、信頼性、公平性、セキュリティもサービスSLOとともに考慮する。

実務では、低精度量子化やモデル軽量化、KVキャッシュ管理、バッチングとスケジューリング、並列実行、要求ルーティングを一つのサービングアーキテクチャに統合する。効果はハードウェア、モデル構造、プロンプト分布、応答長、同時実行性によって変わるため、実際の負荷を再現するベンチマークが不可欠である。

2. 推論構造とボトルネック

A. 要求処理の全体構造

以下の構造では、ゲートウェイが認証・割当量・ポリシーを確認した後、適切なモデルエンジンへ要求を転送する。エンジンはキュー内の要求をスケジューリングし、生成トークンをストリーミングまたは完了応答として返す。

flowchart LR
  U[利用者要求] --> G[APIゲートウェイ]
  G --> P[ポリシー 割当量 ルーティング]
  P --> Q[要求キューとスケジューラ]
  Q --> E[LLM推論エンジン]
  E --> W[モデル重み]
  E --> K[KVキャッシュプール]
  E --> R[ストリーミング応答]
  R --> G
  G --> U
  M[メトリクス ログ トレース] -.可観測性.-> G
  M -.可観測性.-> Q
  M -.可観測性.-> E

ゲートウェイはモデル実行から分離したポリシー境界である。トークン上限、最大文脈長、テナント別優先度、プライバシー制御を検証し、要求のモデル・リージョン・ハードウェア要件に適合するエンジンを選ぶ。これらの責務をすべて推論エンジンに持たせると、ポリシー変更がランタイムのデプロイに結び付く可能性がある。

スケジューラはGPUメモリの余裕と実行中要求の進行状況を基に次の処理を決める。静的バッチングは一定数の要求を集めて実行するが、生成長が異なると短い要求も最長要求の終了を待つことがある。連続バッチングはトークン生成ステップごとに完了要求を除き、待機中の要求を追加してバッチを再構成する。

推論エンジンはモデル重みだけでなく、一時アクティベーション、KVキャッシュ、カーネルバッファを管理する。メモリ割当とカーネルスケジューリングは相互に影響するため、キャッシュを確保し過ぎると新規要求を受け付けられず、少な過ぎると処理量が低下する。

B. プリフィルとデコード

sequenceDiagram
  participant C as クライアント
  participant S as スケジューラ
  participant M as モデルエンジン
  participant K as KVキャッシュ
  C->>S: プロンプト送信
  S->>M: プリフィル処理を割当て
  M->>M: 入力トークンのアテンション計算
  M->>K: 層ごとのKey Value状態を保存
  M-->>C: 最初のトークンを送信 TTFT
  loop 出力トークン生成
    S->>M: デコードステップを実行
    M->>K: 過去のKey Valueを読込
    M->>M: 次トークンを計算
    M-->>C: トークンを送信 ITL
  end
  M->>K: キャッシュ回収または保持ポリシーを適用

プリフィルは入力プロンプトのトークンを処理し、各層のKV状態を作る。長い入力は多くの演算とアクティベーションメモリを必要とし、GPU演算使用率が高くなる場合がある。また大きなキャッシュを作り、他利用者のデコード処理と資源を競合する。

デコードは、生成済みトークンも含む文脈を使って次のトークンを一つずつ計算する自己回帰段階である。各ステップは文脈に対するアテンションを行いモデル重みを繰り返し使用するため、多くの場合、演算量ではなくメモリ帯域幅やトークンごとの逐次遅延がボトルネックとなる。ただし実際のボトルネックはワークロードとモデルに依存し、測定で確認する。

最初のトークンまでの時間（TTFT）は入力待ち時間とプリフィルの影響を受ける。トークン間遅延（ITLまたはTPOT）はデコード速度とスケジューリングに敏感である。両者を分けて計測すれば、長いプロンプトによるTTFT悪化と、トークン生成の遅さによるITL悪化を区別できる。

3. KVキャッシュとメモリ管理

A. キャッシュの原理と規模

Transformerは各トークンでアテンションに用いるKeyとValue表現を生成する。過去のK・Vを再利用すれば、新トークンの生成時に過去トークンのK・V射影を再計算する必要がない。ただし過去のK・Vを読み出して新しいQueryとのアテンションを計算する処理は残るため、キャッシュがすべての演算をなくすわけではない。

全アテンションを使うモデルの1要求当たりキャッシュメモリは、概ね次式で見積もれる。

KVキャッシュのバイト数 ≈ 2 × 層数(L) × KVヘッド数(Hₖᵥ) × ヘッド次元(d) × トークン数(T) × 要素当たりバイト数(b) × 同時要求数(N)

係数2はKeyとValueを両方保存するためである。グループ化Queryアテンション（GQA）やマルチQueryアテンション（MQA）はQueryヘッドよりKVヘッドを少なくでき、キャッシュを削減する。長い文脈、高い同時実行性、高精度は必要キャッシュを増加させる。

例として、32層、KVヘッド8、ヘッド次元128、文脈8,192トークン、FP16（要素当たり2バイト）の仮想モデルは、1要求当たり約1GiBのキャッシュを必要とする。実際の値はアテンション構造、ウィンドウ、キャッシュ精度、ランタイム実装によって変わる概算である。

これは重みメモリとは別である。大規模モデルでは重みだけでGPUメモリの大半を使う場合があり、キャッシュとアクティベーションを含めると要求の同時実行数が制約される。重みが載るかどうかだけでサービング可能性を判断してはならない。

B. ページ型キャッシュと共有

要求ごとのキャッシュを連続メモリに長さに合わせて割り当てると、要求長のばらつきで外部断片化が生じる。最大長を事前確保すると未使用領域が無駄になる。ページ型方式はキャッシュを固定サイズブロックに分割し、トークン生成に必要なブロックのみを要求へ結び付ける。論理トークン順序と物理メモリブロックを対応表で分離するのが要点である。

PagedAttention系の方式は、このようなブロック単位のKVメモリ配置に関連する。ブロックが小さいと無駄を減らしやすい一方、ブロック管理やアドレス変換の負荷が増える。大きいブロックは管理が簡単になる可能性があるが、系列末尾の内部浪費と共有粒度が変化する。

多くの要求が共通システムプロンプトや反復するRAG指示を使用する場合、共通プレフィックスのキャッシュブロックを共有するとプリフィルの重複を減らせる。キャッシュ共有には内容の一致だけでなく、テナント、認可、モデル版も一致することを確認するキー設計が必要である。

GPUメモリが不足したとき、どのブロックを解放するかは退去ポリシーで決まる。最近使用時刻（LRU）、優先度、再利用可能性、保持時間などを基準にできる。キャッシュヒット率を上げるため特定利用者のデータを長く保持すると、セキュリティや削除ポリシーと衝突する可能性があるため、運用方針と一緒に定義する。

C. 圧縮・量子化・オフロード

KVキャッシュ量子化はキャッシュ表現のビット幅を下げ、メモリ使用量を削減する。FP8などの低精度表現はより多くのトークンや要求を収容できる可能性がある一方、量子化スケールや値域が出力品質・安定性に影響する場合がある。モデル重み量子化とキャッシュ量子化は別々の品質検証項目にする。

オフロードは利用頻度の低いキャッシュブロックをCPUメモリなど別のメモリ階層へ移動する。GPU容量を空ける一方、転送遅延、CPUメモリ、PCIeまたはネットワーク帯域を消費する。再利用の時期を予測できないと、戻す時間が再計算より遅くなる可能性がある。

スライディングウィンドウアテンションを使うモデルでは、一部の層が無制限の文脈を必要としないため、トークンを早く回収できる場合がある。しかしハイブリッドアテンションや状態を保持する構造では層ごとのキャッシュ寿命とプールサイズが異なることがある。モデル固有の配置を理解せず一律にキャッシュを縮小すると、精度や実行互換性が損なわれる可能性がある。

4. バッチングとスケジューリング

A. 静的バッチングと連続バッチング

静的バッチングは固定グループの要求を実行する。同程度の入力を処理するオフライン処理では実装・運用が簡単だが、生成長が要求ごとに異なる場合、バッチ全体が最長要求に拘束されることがある。空いたスロットもバッチ完了まで使用できない。

連続バッチング（continuous/in-flight batching）は生成ステップの境界で完了要求を除き、待機要求を追加する。要求ごとの進行を分離し、GPUのアイドル時間を減らして継続的に到着するサービスのスループットを高められる。ただしスケジューラの受付制御と公平性が重要となり、長いプリフィルがデコード要求を無期限に遅らせないようにする。

連続バッチングが必ず遅延を下げるわけではない。要求を多く追加すると処理量は増えるが、各要求が次の生成ステップを待つ時間は長くなり得る。平均処理量だけでなくキュー待ち時間、TTFTとITLのp95/p99も計測する。

B. チャンクプリフィルとスケジューリングポリシー

チャンクプリフィルは長いプロンプトをトークンチャンクに分け、段階的に処理する方式である。プリフィルとデコードを交互にスケジューリングでき、一つの長い入力が他利用者のトークン生成を長時間占有する事態を減らせる。ただしチャンク切替とスケジューリングの負荷が追加され、プリフィルの総完了時間が変わる場合がある。

スケジューラはトークン予算、空きキャッシュブロック、要求優先度、期限、推定出力長を考慮できる。処理量を優先する方式は短い要求を素早く処理する一方、長い要求を飢餓状態にする恐れがある。公平性を保つにはテナント重みや最大待ち時間を適用する。

最大バッチトークン数や最大同時シーケンス数を増やすと並列性は向上するが、キャッシュとアクティベーションメモリを急速に消費する。小さな要求を過剰に受け入れると、後から来た長いプロンプトを繰り返し拒否する可能性もある。エラー発生後ではなく、キュー遅延とメモリ余裕を基に事前に受付制御する。

5. モデル実行の最適化技法

A. 量子化とカーネル最適化

モデル重み量子化はFP16・BF16より低い精度で重みを保存・演算し、容量と帯域幅の圧力を下げる。4ビットや8ビットがすべてのモデルやタスクで同じ品質を保つわけではないため、ドメイン別評価データで精度、幻覚、安全性の変化を検証する。

融合カーネルと最適化アテンションカーネルは複数演算をまとめ、中間データのメモリ往復を減らす。効果はGPUアーキテクチャ、入力長、バッチ形状、ライブラリ版に依存する。サービングエンジン変更時は演算子対応、デバッグ可能性、運用成熟度、ベンダー依存も評価する。

B. 並列化とモデル配置

データ並列化はモデル複製を複数GPUに配置し、異なる要求を処理するためスループット拡大に適する。ただし複製ごとにモデル重みが必要なので、モデルが単一GPUに収まらない場合は適用しにくい。複製数が増えるとGPU当たりのキャッシュ余裕が減り、長い文脈の処理容量に影響する。

テンソル並列化は層の行列演算を複数GPUに分割して大規模モデルを収容できるが、GPU間通信が増える。GPUを増やして計算を分割しても通信や同期で遅延が増える可能性がある。パイプライン並列化は層群をGPUごとに配置するが、パイプラインバブルと要求スケジューリングを考慮する。

並列化方式はパラメータ数だけでなく、目標遅延、ネットワーク構成、バッチサイズ、モデル構造から選定する。MoEモデルでは専門家並列化とトークンルーティングも考慮する。複数方式の組み合わせでは性能向上以上に障害分離やデプロイが複雑にならないか確認する。

C. 投機的デコード

投機的デコードは小型のドラフトモデルまたは補助予測器が次トークン候補を複数提案し、大型の対象モデルがまとめて検証する方式である。候補が受け入れられれば、一度の検証ステップで複数トークンを確定でき、逐次デコードの反復回数を減らせる。

対象モデルの分布を保つよう候補を受け入れ・修正するアルゴリズムを使用できるが、ドラフトとの適合が悪いと検証負荷が増す。ドラフト生成コスト、受理率、バッチ環境、メモリ使用量を測定する。すべての要求で同じ高速化が得られると仮定しない。

6. 技法の比較と選択

技法	主なボトルネック	期待効果	コスト・注意点
KVキャッシュ	過去トークンのK/V再計算	デコード重複計算の削減	キャッシュメモリ増加
ページ型キャッシュ	断片化・固定予約の無駄	ブロックの動的割当・共有	マッピング・退去管理の複雑化
連続バッチング	静的バッチの空きスロットと待ち	GPU利用率・処理量向上	キュー公平性・末尾遅延管理
チャンクプリフィル	長い入力によるデコード占有	プリフィルとデコードの調整	チャンク切替オーバーヘッド
キャッシュ量子化	KVメモリ容量	同時実行・文脈容量拡大	精度・品質の検証
投機的デコード	トークン逐次生成の遅延	受理トークン群の高速確定	ドラフトコスト・受理率への依存
重み量子化	重みメモリ・帯域幅	モデル搭載と実行効率の改善	タスク別品質低下の可能性

これらの技法は異なるボトルネックに対処するため、直接的な代替というより補完関係にある。連続バッチングは実行スロット利用を、ページ型キャッシュはKVメモリ配置を改善するため併用できる。ただし最大バッチサイズだけを先に増やすとキャッシュ圧迫が悪化し、効果が逆転する場合がある。

サービスのプロファイルに基づき段階的に技法を選ぶ。短いプロンプト・短い応答では小型モデルや複製拡張が重要な場合がある。長文脈RAGではキャッシュ容量と再利用可能なプレフィックスが中心となる。対話型サービスはTTFT・ITLのSLOを、オフライン推論は時間当たりトークン数とトークンコストを優先できる。

7. 産業適用事例

A. 顧客サポート対話サービス

顧客サポートでは共通システムプロンプトとポリシー指示を多くの要求に適用する。プレフィックスを安全に再利用すれば重複プリフィルを減らせるが、顧客別会話履歴は他テナントと混ざらないキャッシュキーに分離する。

夕方に要求が急増する場合、連続バッチングとキュー制限を適用し、優先度の高い問い合わせ対応が一般質問に押し出されないよう重み付きスケジューリングを用いる。観測指標にはp95 TTFT、p95 ITL、応答成功率、キュー超過拒否率、GPUメモリ余裕を含める。

B. 社内RAGナレッジ検索

社内ナレッジ検索では各質問で同じシステム指示と検索結果形式を使う一方、検索文書長は質問により異なる。共通プレフィックスキャッシュとチャンクプリフィルは重複計算と長い文脈による資源独占を減らすのに役立つ。

機密文書を扱う組織ではキャッシュ再利用を組織・権限単位に制限し、退職、権限変更、文書削除時の無効化も考慮する。ヒット率よりアクセス制御と情報分離を優先し、プロンプトと結果のログは最小限収集とする。

C. コード生成支援ツール

コード生成では長いファイル文脈と短い反復補完要求が混在する。短い提案は最初のトークンとトークン間遅延に敏感で、長い分析要求ではプリフィルコストとキャッシュ容量が重要である。要求種類ごとにキューやエンジンプールを分けると、相反するSLOを分離できる。

ドラフトと対象モデルのトークン分布が合うコード領域で、投機的デコードを試験できる。導入前にコード正確性、安全でないコード生成、受理率、平均遅延、推論コストを同じ入力分布でベースラインと比較する。

8. 性能測定と運用手順

単一要求の平均ではなく、同時要求、入力・出力長分布、到着率を含む負荷試験で比較する。本番ログを再利用できない場合は個人情報を除いた代表的なワークロードを生成し、プロンプトと応答長の分布を保つ。

主要指標にはTTFT、ITL/TPOT、要求全体の遅延、入出力トークン処理量、キュー遅延、成功・タイムアウト・拒否率、GPU使用率、重み・KVキャッシュメモリがある。利用の少ない時間帯の平均処理量だけでは、急増負荷でのSLO違反を見逃す。

コスト指標はGPU時間に加え、モデル規模、アイドル複製、CPUオフロード、ネットワーク転送、再試行、品質低下による後処理費用を考慮する。トークン当たりコストが下がっても精度や安全性が低下して人手の再作業が増えれば、総保有コストは増える可能性がある。

運用手順は基準値測定、最適化を一つずつ適用、品質回帰試験、負荷再現、カナリアデプロイ、SLO比較、段階拡大の順に設計する。ランタイム・カーネル・トークナイザの版を同時に記録し、改善が特定GPUや入力長だけに限られるか確認する。

9. 発展論点：プリフィルとデコードの分離、キャッシュ再利用

プリフィルとデコードでは資源特性が異なるため、大規模システムでは両者を別の処理プールまたは装置に分離する構成を検討できる。プリフィルプールは長い入力の処理に、デコードプールはキャッシュを保持したトークンストリーミングに最適化する。

分離すると各段階を独立して拡張できる一方、KV状態を装置間で転送しなければならない。データ量が大きければ、ネットワーク帯域やコピー遅延が利点を上回り、要求ルーティングと障害復旧も複雑になる。キャッシュ転送時間、各段階の待ち時間、ネットワーク混雑を含めてエンドツーエンドで比較する。

プレフィックスキャッシュと外部ルーティングを組み合わせれば、対象プレフィックスを既に保持するエンジンへ要求を送れる。これはクラスタ全体の処理量だけでなく、キャッシュ親和性と負荷分散を同時に考える問題である。一つのエンジンに集中するとホットスポットが生じるため、再利用利益とエンジン別キュー長を均衡させる。

要求間キャッシュ再利用はセキュリティ境界でもある。強いハッシュに基づくキャッシュキー、テナント・利用者分離、機密プロンプトの保持期間、退去・削除の証跡を設計する。キャッシュのサイドチャネルやプロンプト推測可能性も脅威モデルに含める。製品や版によって機能は異なるため、公式文書とデプロイ版を確認する。

10. 考慮事項と示唆

SLOに基づく目的設定：対話サービスは処理量だけでなく、TTFT・ITLの末尾遅延、エラー率、公平性を最適化する。業務優先度ごとに許容遅延と最大キュー待ちを定義する。
メモリ予算の統合管理：モデル重み、アクティベーション、KVキャッシュ、ランタイムバッファを一つのGPUメモリ予算で管理する。文脈長と同時実行数をともに制限し、OOM前の安全余裕を監視する。
品質・安全の回帰検証：重みやKVキャッシュの低精度化、投機的デコードでは代表業務の評価と安全性テストを並行する。平均点だけでなく言語、高リスク業務、長文脈での悪化を確認する。
テナント分離とデータライフサイクル：プレフィックス・キャッシュ共有は認可境界と保持方針に従って制限する。機密情報がキャッシュに残る時間、削除要求の反映、ログとキャッシュの違いを文書化する。
公平なスケジューリングと負荷制御：優先要求の遅延を守りながら一般要求の飢餓を防ぐため、最大待ち時間、重み、受付制御を設ける。容量超過時は明確な再試行方法と代替応答を示す。
エンドツーエンドのコスト最適化：GPUのトークン単価だけで改善を判断しない。品質、再試行、キャッシュ転送、アイドル資源、運用複雑性を含む業務単位コストを比較する。
ランタイム・ベンダー変更管理：キャッシュ配置、スケジューリング機能、量子化形式は版により異なる。エンジンやGPU世代の変更前に標準ワークロードで互換性、性能、復旧手順を再検証する。

情報管理技術士はモデル選択やGPU規模算定にとどまらず、サービスSLOから導いた要求プロファイル、キャッシュ予算、バッチング方針、情報保護統制を一つの容量計画に結び付けるべきである。この体系により短期的な性能数値を持続可能なサービス品質とコスト効率へ転換できる。

参考資料

NVIDIA TensorRT-LLM, KV Cache System: https://nvidia.github.io/TensorRT-LLM/features/kvcache.html
Hugging Face, Continuous batching from first principles: https://huggingface.co/blog/continuous_batching
Hugging Face Transformers, Cache strategies: https://huggingface.co/docs/transformers/main/kv_cache
vLLM Documentation, Paged Attention（原論文に基づく歴史的説明であり、現在のコードと異なる場合があると明記）: https://docs.vllm.ai/en/stable/design/paged_attention/

一言まとめ: LLM推論の最適化とは、KVキャッシュ・バッチング・モデル実行をSLO、品質、セキュリティ、コストに合わせて一体設計し、実負荷で検証することである。