静的
固定サイズのバッチが埋まるまで待つ方式です。オフライン処理には向きますが、全員がバッチを待つため対話型のトラフィックには不向きです。
AI推論ガイド
サービング最適化
GPUのフリートがどれだけのリクエストをどれだけ速く捌けるかを決める、システムレベルの技術です。バッチング、KVキャッシュのメモリ管理、decodeの高速化、フェーズの分離、並列化、ルーティングを扱います。レイテンシ、スループット、コストは互いに引き合うため、どこを取るかはワークロードが決めます。
バッチング：スループット最初のレバー
リクエストが1本だけではGPUの大半が遊びます。リクエストをまとめれば、重みの読み出し1回を多数のトークンで分担できます。まとめ方が重要です。
動的
時間枠かサイズ上限でバッチを締め切るので、待ち時間に上限が付きます。改善されますが、バッチはなお最も遅いメンバーのペースで終わります。
継続的
スケジューラがトークン単位で動きます。完了した系列は途中で抜け、待機中のリクエストはすぐに加わります。これが主流の既定方式（vLLM、SGLang、TensorRT-LLM）であり、単独で最大の稼働率改善をもたらします。
chunked prefillはこれをさらに洗練させます。長いプロンプトを細片に分割してdecodeステップと交互に処理するため、巨大なプロンプト1本が他の全員のトークンストリームを止めることがなくなります。バッチングの方針はレイテンシの方針です。毎秒トークン数だけでなく、TTFTとトークン間レイテンシを測ってください。
KVキャッシュのメモリ：ページング、再利用、オフロード
PagedAttention
素朴なサービングは、各リクエストが取り得る最大長ぶんのKVメモリを連続領域で確保し、その大半を断片化として無駄にします。PagedAttentionは仮想メモリの発想を借ります。キャッシュを固定サイズのブロックとして必要に応じて確保し、各系列の論理位置を物理ブロックへ対応づけるブロックテーブルを持ちます。無駄は最後の部分ブロック程度まで減り、同一のプレフィックスは物理ブロックを共有でき、回収されたメモリは実効バッチサイズの拡大に回ります。vLLMが導入し、いまやサービングエンジンの標準です。これは高速なカーネルではなく、メモリ管理上の勝利です。
prefix caching
2つのリクエストがバイト単位で同一のトークン列から始まる場合（同じシステムプロンプト、同じ例、同じ会話履歴）、そのプレフィックスのprefill処理を一度だけ計算して再利用でき、ヒットのたびにTTFTとprefillの計算量を削減できます。完全一致が条件なので、プロンプトの規律が重要になります。静的な内容を先頭に、変動する値（タイムスタンプ、ユーザーデータ、リクエストID）はできるだけ後ろに、シリアライズは決定的に。ヒット率を監視してください。低い場合はたいてい、プロンプトテンプレートの先頭部分に変動要素が漏れています。
KVキャッシュのオフロード
キャッシュはコンテキスト長と同時実行数に比例して増え、GPUのHBMが先に尽きます。オフロードは、冷えたキャッシュをCPUのRAM、ローカルSSD、リモートストレージへ退避し、必要になったら戻します。これによって、待機中のチャットセッションや長い共有コンテキストがHBMを占有し続けることがなくなります（LMCacheが代表的なオープンソース実装で、vLLMと統合されています）。長いコンテキストや再開可能なセッションでは価値があります。トレードオフは転送時間と再計算の比較なので、自分のストレージ階層で両方の経路を計測してください。
投機的デコーディング：同じ分布のまま、トークンを速く
decodeはメモリ律速なので、各ステップには計算の余力があります。安価なドラフトモデルが複数のトークンを提案し、ターゲットモデルがそれらを1回のパスで検証して、正しく続く最長の並びを採用します。採用されたトークンはわずかなコストで得られ、却下されたドラフトは通常のデコーディングに戻ります。厳密な検証方式はターゲットモデルの出力分布を保ちます。
- ドラフト側の選択肢：小さな別モデル、ターゲットに追加したデコーディングヘッド（Medusa系）、特徴量レベルでのドラフト（EAGLE系）、あるいはプロンプトからの単純なn-gram検索などです。実装では複数の候補継続をまとめてドラフトし、木構造全体を1回のバッチパスで検証することがよくあります。
- 効き目を決める変数は採択率です。予測しやすいテキスト（コードや構造化出力）でよく整合したドラフトモデルは大きく効きますが、噛み合わないドラフトモデルはサービングをかえって遅くします。
- 他要素との関係：ドラフトモデルはメモリとスケジューラの複雑さを消費し、計算の余力が消えるほど大きなバッチサイズでは利得が縮みます。研究動向は高度な最適化で概観しています。
スケールアウト：分離、並列化、ルーティング
prefillとdecodeの分離
prefillは計算律速でバースト的、decodeは帯域律速で定常的です。同居させると互いに干渉し、長いprefillが全員のトークンストリームを止めます。分離すると、2つのフェーズを別々のワーカープールで動かし、それぞれ独立に増減・調整できます。prefillワーカーは高速なファブリック経由でKVキャッシュをdecodeワーカーへ送ります。この転送が代償なので、フリート規模では見合いますが、小規模や短いプロンプトでは不利になります。対応フレームワークにはvLLM、SGLang、NVIDIA Dynamoがあります。
並列化の戦略
データ並列はモデルを複製してトラフィックを分けます。テンソル並列は個々の層を複数GPUに分割して大きすぎるモデルを収めますが、毎ステップの通信を伴います（NVLink級のリンクが望まれます）。パイプライン並列は層の範囲をステージへ割り当て、マイクロバッチングでパイプラインの気泡を埋めます。エキスパート並列はMoEのエキスパートを複数デバイスに分散します。実際のデプロイではこれらを組み合わせますが、最適な配合は経験的に決まります。テンソル並列は帯域への圧力を増やし、複製はGPUあたりのKVの余裕を減らすため、第一原理から推論するのではなく構成ごとに計測してください。
推論のルーティング
レプリカが多くなると、ルーターは最適化の対象になります。ラウンドロビンはLLMで重要な要素をすべて無視します。より良い信号は実負荷、メモリの余裕、そして何よりキャッシュの局所性です。プレフィックスを考慮したルーティングやセッション固定のルーティングは、そのKV状態がすでに置かれている先へリクエストを送ります（プロンプトのプレフィックスに対するコンシステントハッシュが定番の手法で、llm-dのようなプロジェクトで使われています）。分離構成のフリートはフェーズごとにルーティングし、優先度やSLAのクラス、アダプタの局所性も同じスコアリングに組み込めます。これは、モデルの階層をまたいでモデルを選ぶルーティングとは別物です。後者はエージェント型パターンで扱います。
オフラインのバッチ推論
すべてのワークロードが対話的なわけではありません。コーパスの埋め込み生成、分類の遡及適用、要約の一括処理、評価の実行は数時間のレイテンシを許容でき、最適化の目標がまるごと変わります。ハードウェアを飽和させ、余剰やオフピークのキャパシティを使い（プロバイダーはまさにこの用途に割安なバッチ枠を売っています）、結果を利用する前に後処理と品質チェックを挟みます。バッチ処理を対話用のフリートから切り離しておくことは、レイテンシのSLOを守ることにもなります。
信じる前に計測する
- TTFT、トークン間レイテンシ、エンドツーエンドのレイテンシ（中央値とP99）、固定同時実行数でのスループット、リクエストあたりコストを測ってください。数値1つだけの結果はトレードオフを覆い隠します。
- 自分のトラフィックの形を使ってください。プロンプトと出力の長さの分布、同時実行のパターン、キャッシュヒットの見込みです。均一な合成ワークロードは、どんな最適化も実力以上に見せます。
- LLMサービング向けの負荷生成ツール（GenAI-Perf、LLMPerf、あるいはk6/Locustのスクリプト）は、汎用のHTTPツールが取りこぼすトークン単位の指標を報告します。
- どの結果にもモデル、量子化、ハードウェア、エンジンのバージョン、設定を記録してください。ラベルのないベンチマークは比較も再現もできません。
- 品質のベンチマーク（MMLU系のスイート）と性能のベンチマークは別の問いに答えます。サービングの変更は、レイテンシ目標と精度評価の両方に照らして検証してください。