1. 本コラムの目的

このコラムでは、大規模言語モデル（LLM）を効率的に動かすための技術、特に分散環境での推論（Inference）に焦点を当てて詳しく解説します。LLMの推論処理には独特の特性があるため、従来のアプリケーションとは異なる最適化が必要になります。
このドキュメントは、Distributed Inference Servingのスライドで扱われている分散LLM推論基盤の仕組みを解説することを目的としています。

2. 背景 - なぜLLM推論処理を分散するのか

LLMの推論、つまりLLMを使って文章を生成したり質問に答えたりする処理は、その特性上、分散環境で行うことで大きなメリットが生まれます。

• リクエストの多様化: LLMへのリクエスト（ユーザーの入力）は非常に多様で複雑であり、入力の長さもリクエストごとに大きく異なります。また、多くのリクエストが過去の会話の繰り返しやテンプレートを含むという特性もあります。
• 応答生成の二つのフェーズ: LLMの処理は、大きく分けて2つの異なる計算フェーズに分かれ、それぞれ処理の特性が異なります（後述）。
• スケールの限界: 1台のGPUでモデル全体と推論に必要なキャッシュ（KV-Cache）を保持しようとすると、多くの場合メモリが先に枯渇してしまいます。
• 急増する要求: 単純にモデルへの要求が急激に増加しており、一台のサーバーでは処理しきれないという背景もあります。

これらの課題を解決するため、複数のGPUやノードに処理を割り振る「分散推論」が不可欠となります。

3. 基本概念をおさらい

3.1 Transformer と Attention

Transformerは、「自己注意 (Self-Attention)」という機構を用いて、入力された文章（トークン系列）内の単語間の関連性を計算するモデルです。この計算には Query (Q), Key (K), Value (V)と呼ばれる三つの行列が使われます。特に、現在のLLMの主流である自己回帰型（Autoregressive）モデルでは、新しいトークンを1つ生成するたびに、過去のトークンに対するAttention計算を再度行う必要があり、これが計算量の増大を招く一因でした。

3.2 KV-Cache とは

KV-Cacheは、このAttention計算の無駄を省くための仕組みです。一度計算したK（Key）とV（Value）の値を保存しておく専用のGPUメモリ領域を指します。
次回以降のトークン生成では、新しいトークンに対応するKとVだけを計算し、過去の分はキャッシュから再利用します。これにより、後述するDecodeフェーズの処理を大幅に高速化できます。

3.3 PrefillフェーズとDecodeフェーズ

LLMの推論処理は、KV-Cacheの扱いに着目すると、特性の異なる2つのフェーズに分けられます。

• Prefill（プリフィル）フェーズ: ユーザーの入力プロンプトをまとめて処理し、最初の出力トークンを生成する段階です。このとき、入力トークンに対応するKV-Cacheも一括で生成されます。主に行列計算が行われるため、GPUの計算能力がボトルネックになりやすいです。
• Decode（デコード）フェーズ: 直前に生成されたトークンと既存のKV-Cacheを基に、後続のトークンを一つずつ生成していく段階です。計算処理自体は軽いものの、GPUとメモリ間のデータ転送速度がボトルネックになりやすいです。

この2つのフェーズはボトルネックが異なるため、それぞれを別のワーカー（処理担当）に分離して効率を上げる Prefill-Decode (PD) Disaggregationというアプローチが有効です。ただし、これを実現するにはKV-Cacheをワーカー間でどう共有するか、リクエストをどう振り分けるかという新たな課題が生まれます。

4. vLLM が実装する主な最適化

vLLMは、UC Berkeleyで開発された高速なLLM推論・サービングエンジンです。以下の先進的な技術により、高いスループットを実現します。

詳細解説

• Paged Attention（ページド・アテンション）:
  OSの仮想メモリ管理（ページング）に着想を得たKV-Cache管理手法です。KV-Cacheを「KVブロック」という固定サイズの物理メモリページに分割し、「ブロックテーブル」で論理的な順序を管理します。これにより、動的なメモリ割り当てが可能となり、メモリの断片化を防ぎます。さらに、異なるリクエスト間でKVブロックを共有できるようになり、特に同じプロンプトから複数の出力を生成する場合にメモリ効率が大幅に向上します。安全な共有のため、参照カウントとCopy-on-Write（書き込み時コピー）の仕組みも利用されます。
• Automatic Prefix-Caching（自動プレフィックスキャッシング）:
  異なるリクエスト間でKV-Cacheを共有し、Prefillの再計算を避ける技術です。リクエストのプロンプトのPrefix（接頭辞、冒頭部分）からハッシュ値を計算し、対応するKVブロックをグローバルなハッシュテーブルに保存します。後続のリクエストで同じPrefixが検出されると、キャッシュされたKV-Cacheを再利用し、Prefill計算をスキップすることでTTFTを短縮します。
• Continuous Batching（連続バッチ処理）:
  従来の静的バッチ処理では、バッチ内で最も長い応答が終わるまで全リクエストが待たされる問題がありました。Continuous Batchingは、応答生成が完了したシーケンスの空きスロットに、待機中の新しいリクエストを即座に割り当てる「逐次入れ替えバッチ」方式です。これにより、GPUの遊休時間をなくし、システム全体のスループットを最大化します。

5. KV-Cacheを“みんなで”使い回す仕組み

PD Disaggregationを実現するには、分離されたワーカー間でKV-Cacheを高速に共有する仕組みが必要です。

5.1 KV Connector API

vLLM本体のコアロジックと、外部のキャッシュ基盤を切り離すためのプラグインインターフェイスです。これにより、様々なキャッシュ共有の仕組みを柔軟に導入できます。

5.2 LMCache

KV-Cacheの永続化と共有を実現するvLLMの拡張機能です。TTFTの削減とスループット向上に貢献します。

• 主な機能:
  1. Storage (永続化): KV-CacheをCPU RAMやNVMeストレージなどに退避・保存します。これにより、セッションをまたいだキャッシュの再利用や、GPUメモリからのオフロードが可能になります。
  2. Transport (転送): PD Disaggregation向けに、KV-Cacheを別ノードへリアルタイムにP2P（Peer-to-Peer）で直接転送します。
• 共有戦略: 中央のキャッシュサーバーを経由するCentralized共有と、ノード間で直接通信するP2P共有の両方をサポートします。
• P2P共有の仕組み:
  • Lookup Server (Redis): どのノードがどのKV-Cacheを持っているかという位置情報を記録する外部のRedisサーバーです。
  • Distributed Server: 各ノード内で動作し、P2PでのKV-Cache送受信を待ち受けるサーバーです。
    キャッシュを探すリクエストは、まずLookup Serverに問い合わせ、ヒットすればキャッシュを持つノードから直接データを受け取ります。

5.3 NIXL (NVIDIA Inference Xfer Library)

GPU間、あるいはGPUとストレージ間のデータ転送を抽象化し、高速化するためのNVIDIA製ライブラリです。LMCacheはNIXLを利用して、ハードウェアに最適化された最も効率的な方法でKV-Cacheを転送できます。

6. Kubernetes上の分散推論スタック - llm-d

llm-dは、vLLM、LMCache、NIXLといった技術群をKubernetesネイティブに統合し、大規模かつ最適な生成AI推論基盤を提供することを目的としたオープンソースプロジェクトです。

6.1 主な機能

• Prefill/Decode Podの自動デプロイとオートスケール
• Gateway API Inference Extension (GIE) に基づくLLM特化のインテリジェントなリクエストルーティング
• vLLMやLMCacheの最適化を最大限に活用する環境の提供

6.2 Gateway API Inference Extension (GIE) とルーティング

GIEは、LLM推論に特化したルーティングを実現するためのKubernetesの公式拡張プロジェクトです。llm-dはこれを採用し、EnvoyプロキシのExternal Processing機能を用いて、リクエストごとに最適なPodを選択します。この選択プロセスでは、以下のScorerがスコアを計算し、最もスコアの高いPodにリクエストを転送します。

• Session-aware Score: 同じセッション（`x-session-token`ヘッダーで識別）を以前担当したPodを優先します。
• Load-aware Scorer: 待機キューが短いなど、負荷の低いPodを優先します。
• Prefix-aware Scorer: リクエストのプロンプトのPrefixがキャッシュされているPodを優先します。
• KVCache-aware Scorer: 再利用できるKV-Cacheの量が最も多いPodを優先します。

6.3 llm-d-kv-cache-manager

KVCache-awareなルーティングを実現するための重要なコンポーネントです。LMCacheが利用するLookup Server (Redis) 上のKV-Cache所有情報をインデックス化し、どのPodにルーティングすれば最も長いPrefixでキャッシュにヒットするかを高速に検索・評価する役割を担います。

7. LLM推論の性能評価指標

LLM推論の性能は、以下の指標で評価されます。

ユーザーが応答全体を受け取るまでの体感時間は、おおよそ TTFT + (TPOT × 生成トークン数) で計算できます。

8. まとめ

分散LLM推論基盤を構築・理解するためのステップは以下の通りです。

1. 理論: まず、TransformerとKV-Cacheの基本的な仕組みを押さえる。
2. 単一ノード最適化: vLLMを使い、Paged AttentionやContinuous Batchingの効果を体験する。
3. キャッシュ共有: LMCacheとNIXLを導入し、ノード間でキャッシュを共有してPrefillの計算量を削減する。
4. オーケストレーション: llm-dを使い、Kubernetes上にPrefill/Decodeワーカーを分離配置し、インテリジェントなScorerによるルーティングを有効化する。
5. 計測と改善: TTFTとTPOTを継続的に計測し、ボトルネックを特定して改善サイクルを回す。

Tips:

• まずは 単一GPU × 小型モデル でvLLMを動かし、基本的な動作を確認することから始めるのがお勧めです。
• キャッシュ共有はネットワーク帯域を消費します。性能を測定しながら段階的に導入するのが安全です。