vLLM、16基のH200でGLM-5.3の100万トークン推論を実現

はじめに

エージェントはツールの結果、ファイル内容、過去の応答をターンごとに蓄積する。そのためGLM-5.3をH200で動かす場合、モデル重みが大きなメモリ領域を占める一方、長いプロンプトのプレフィルもボトルネックになる。vLLMはこの問題に対し、8基のH200を備えるノードをプレフィル用とデコード用に分け、複数の並列化とKVオフロードを組み合わせた。

構成の要点

• PCPはトークン単位でクエリを分割する。 8基のGPUがプロンプトの異なる部分を担当し、各GPUは64個すべてのアテンションヘッドを計算する。因果アテンションでは後半のトークンほど計算量が増えるため、プロンプトを16チャンクに分け、前半と後半を組み合わせて負荷を均衡化する。これにより、インデクサも全GPUで重複計算せず、各GPUが担当部分を処理できる。
• DCPはKVキャッシュを分割する。 PCPだけでは全GPUが完全なKVキャッシュを保持する。DCPはトークンをラウンドロビンで配布し、各GPUが8分の1だけを保存する。資料の例では、100万トークンのFP8 KVは53.4 GiBから、GPUごとに約6.7 GiBへ減る。
• 容量拡大の代わりに通信が増える。 クエリとKVの配置が一致しないため、プレフィルでは各レイヤーで分割キャッシュを一時的に集約し、計算後に解放する。報告された追加コストは短いキャッシュ文脈で約6%、248Kトークン付近で約15%まで増加する。DCPは無料の最適化ではなく、通信と引き換えにキャッシュ容量を得る方式だ。
• デコードはHybrid HiSparseで補う。 デコード側は8つのデータ並列ランクを使い、KVの一部をホストメモリに置く。プレフィル側にもCPU KVオフロードを用い、後続ターンでプレフィックスを再利用する。

TPとDPだけでは不十分な理由

データ並列では長いプロンプトを1枚のGPUが処理するため、残りのGPUでプレフィルを加速できない。KVもそのGPUに収める必要がある。テンソル並列ではヘッドを分割できるが、MLAの潜在KVは全ヘッドで共有されるため、キャッシュは複製される。また、過去トークンを評価するインデクサも各GPUで繰り返し実行される。PCPはクエリ計算を、DCPはキャッシュ保存を分散する点が異なる。

意義と限界

この実験は、100万トークン対応が単一の並列化方式だけでは実現しにくいことを示す。計算の配置、キャッシュの保存場所、ホストメモリ、GPU間通信を一体で設計する必要がある。vLLMによれば、AgentXでPCP8×DCP8のプレフィルとHybrid HiSparseデコードを組み合わせた構成は、同一スループットのデータ並列構成よりユーザー単位で1.7～3.2倍高速だった。

一方、DCPは各レイヤーでキャッシュ文脈を通信するため、長い文脈ほど相互接続への負荷が増す。計算と通信のオーバーラップで改善できる余地もある。したがって、この方式は万能ではないが、長い履歴と多くのツール呼び出しを扱うエージェントに対して、プレフィル、キャッシュ、デコードの制約を分担させる現実的な設計を示している。

出典：vLLM Blog