【ITニュース解説】Prefill e Decode Desagregados no vLLM: Como Eliminar Jitter em Clusters de IA

大規模言語モデル（LLM）は近年、様々なITシステムやAIアシスタントの根幹をなす技術として急速に普及している。しかし、これらのモデルを実際のサービスとして動かす「推論」の現場では、長らくエンジニアを悩ませる深刻な問題があった。それが「レイテンシージッター」、つまり応答速度のムラや遅延の急増である。

従来のLLM推論システムでは、ユーザーが入力する指示（プロンプト）の処理と、それに基づいてAIが次々に単語（トークン）を生成していく処理が、同じGPU（グラフィック処理装置）上で同時に行われていた。この仕組みを「モノリシックな共同配置アーキテクチャ」と呼ぶ。この方式では、特に長いプロンプト（例えば、数万トークンに及ぶコードや契約書のようなデータ）が来た場合に問題が発生した。長いプロンプトの処理が始まると、そのGPUが他の処理を中断し、大量の計算リソースを長いプロンプトの処理に奪われてしまう。その結果、同時に接続している他のユーザーが短いプロンプトで応答を待っていても、AIの応答が突然遅くなる、という現象が起きていた。例えば、通常15ミリ秒で次のトークンが生成されるはずが、一時的に600ミリ秒以上もかかることがあり、リアルタイムでの対話が重要なAIアシスタントや共同作業ツール（コパイロット）のユーザー体験を著しく損ねていたのだ。

この問題の根本原因は、LLMの推論プロセスが「Prefill（プリフィル）」と「Decode（デコード）」という、大きく異なる2つのフェーズから成ることにある。

まず「Prefillフェーズ」は、ユーザーが入力したプロンプト全体を一度に処理する段階である。この時、GPUは大量の並列計算を行い、プロンプトに含まれる全てのトークンを一気に分析する。このフェーズは計算能力（FLOPS、1秒あたりの浮動小数点演算数）が非常に重要で、計算リソースに強く依存するため「Compute-Bound（計算律速）」と呼ばれる。つまり、いかに高速な計算ができるか、いかに多くの計算を並行して行えるかが、このフェーズの速度を左右する。このフェーズが速いほど、最初のトークンが生成されるまでの時間（TTFT: Time to First Token）が短くなる。

次に「Decodeフェーズ」は、Prefillフェーズで生成された最初のトークンに続き、AIが次に生成すべきトークンを1つずつ順番に推論していく段階である。このフェーズでは、モデルの重み（学習済みの知識）と、それまでに生成されたトークンの履歴（KVキャッシュと呼ばれる記憶領域）をGPUの高速メモリ（HBM）から繰り返し読み出して利用する。この処理は計算自体はPrefillほど多くないが、大量のデータをメモリとGPUの間で頻繁にやり取りする必要があるため、メモリのデータ転送速度（メモリ帯域幅）が非常に重要となる。そのため、このフェーズは「Memory-Bound（メモリ律速）」と呼ばれ、メモリの転送速度が遅いと、次のトークンが生成されるまでの時間（ITL: Inter-Token Latency）が長くなってしまう。

従来のモノリシックなシステムでは、この特性の異なるPrefillとDecodeが同じGPUリソースを奪い合っていた。長いプロンプトのPrefillが始まると、GPUの計算リソースが完全にPrefillに集中し、Decodeの処理に必要なメモリ帯域幅が不足したり、優先度が下がったりする。これにより、すでに生成中の他の会話が停滞し、レイテンシージッターが発生していた。

この深刻な問題に対し、2026年9月にvLLM V1と分散フレームワークRay Serveの組み合わせにより、抜本的な解決策が提示された。それが「Disaggregated Prefill and Decode（Disagg P/D）」、つまりPrefillとDecodeを物理的に分離するアーキテクチャである。

このアーキテクチャでは、推論システムを大きく3つの役割に分割する。

1. グローバルルーター（Orchestrator Proxy）: ユーザーからのリクエスト（プロンプト）を受け付ける入り口となる部分。リクエストの内容（プロンプトの長さなど）を分析し、最適なPrefill専門ノードに振り分ける。
2. Prefill専門ノード（P-Nodes）: 高い計算能力を持つGPUを多数搭載し、Prefillフェーズの処理のみに特化したサーバー群。ここでは、ユーザーからの長いプロンプトでも、アグレッシブな並列処理によって超高速に最初の処理を行う。Prefillが完了し最初のトークンが選ばれると、このノードはそのセッションを保持せず、計算結果であるKVキャッシュをすぐにDecode専門ノードへ転送し、次のPrefillリクエストの処理に備える。
3. Decode専門ノード（D-Nodes）: 高いメモリ容量とメモリ帯域幅を持つGPUを多数搭載し、Decodeフェーズの処理のみに特化したサーバー群。P-Nodesから転送されてきたKVキャッシュを受け取り、中断することなく連続的にトークン生成を行う。Prefill処理に邪魔されることがないため、多数の会話セッションを並行して、非常に安定した速度（低レイテンシージッター）で処理できる。

この分離型アーキテクチャの鍵となるのが、P-NodeからD-NodeへのKVキャッシュの超高速転送である。この転送には、RDMA（Remote Direct Memory Access）という技術が使われる。RDMAは、CPUを介さずに、ネットワーク経由でP-NodeのGPUメモリからD-NodeのGPUメモリへ直接データを転送する技術（Zero-Copy Peer-to-Peer Transfer）である。InfiniBandやRoCE v2といった超高速ネットワークと組み合わせることで、5万トークン分のKVキャッシュでも4ミリ秒未満という驚異的な速度で転送が可能になり、分離によるオーバーヘッドを最小限に抑えることができる。

このDisagg P/Dアーキテクチャを導入した結果は劇的だった。実際のプロダクション環境でのベンチマークテストでは、レイテンシージッターが92%も削減され、p99（上位99パーセンタイルの遅延）のレイテンシーが従来の485ミリ秒から38ミリ秒へと大幅に改善された。これは、ユーザーが体感する応答の「詰まり」がほとんどなくなったことを意味する。また、最初のトークンが生成されるまでの時間（TTFT）も60%高速化し、6.4万トークンの文書処理で3.8秒かかっていたものが1.5秒に短縮された。さらに、ノードをPrefillとDecodeそれぞれに特化させることで、必要なGPUリソースを効率的に配置できるようになり、全体の処理能力（スループット）が最大3.5倍に向上し、システム全体のコストも58%以上削減されるという結果が得られた。

このアーキテクチャは、Pythonで実装された非同期ルーティングシミュレーターによって、そのメカニズムとパフォーマンスが検証されている。実際の運用では、vLLM V1とRay Serveを組み合わせ、ユーザーの利用パターンに合わせてP-NodeとD-Nodeの最適な比率を調整することが重要となる。例えば、一般的なチャットボットでは1つのP-Nodeに対して3つのD-Node、長文処理が多い場合は1つのP-Nodeに対して2つのD-Nodeといった具合である。また、RDMAをサポートする400Gbps以上の高速ネットワーク環境は、このアーキテクチャの性能を最大限に引き出すために不可欠である。Ray Serveのようなツールを使うことで、トラフィックの変動に応じてP-Nodesを動的に増減させるオートスケーリングも可能となり、ピーク時の処理能力を維持しつつ、コスト効率の良い運用が実現できる。

ただし、この分離型アーキテクチャは全てのケースに最適というわけではない。例えば、わずか1枚か2枚のGPUで動く小規模なシステムでは、モノリシックな従来の方式の方がシンプルで適している。Disagg P/Dは、8枚から16枚以上のGPUを使う中規模から大規模なクラスター環境で、その真価を発揮する。ネットワークの混雑はKVキャッシュ転送の遅延につながるため、強力なネットワークインフラが必須条件となる。また、システムの一部が故障した場合でも、グローバルルーターが健全性監視を行い、代替ノードへリクエストを再ルーティングすることで、サービスの継続性を確保する仕組みも備わっている。DeepSeek 4.1のようなMixture-of-Experts (MoE) モデルとも相性が良く、Prefillフェーズでの並列処理能力とDecodeフェーズでのメモリ効率を両立させ、大規模なAIモデルの効率的な運用を可能にしている。

このように、PrefillとDecodeを物理的に分離する「Disaggregated Prefill and Decode」アーキテクチャは、大規模言語モデルの推論におけるレイテンシージッターという長年の課題を克服し、AIサービスの安定性と効率を飛躍的に向上させる、今後のAIインフラの標準となる技術である。