vLLM GLM 5.3 最適化: Hybrid HiSparse オフローディング

vLLM は、GLM 5.3 のサービングを最適化するために Hybrid HiSparse オフローディングを導入しました。これは、特に単一の 8× H200 ノードのようなメモリ制約のある環境をターゲットにしています。この最適化により、GLM 5.3 は 100 万トークンのフルコンテキスト長で動作可能になり、コンテキストが時間の経過とともに増大するエージェント的ワークロードにおける並列実行数を大幅に増加させることができます。

エージェント的ワークロードにおける KV キャッシュ圧迫の解決

エージェント的ワークロードは、通常、長く増大するコンテキストを持つ多くの同時リクエストを伴います。標準的な GPU サービングでは、固定された GPU ブロックプールが最終的に KV キャッシュ用のスペースを切れ、以下の 2 つの伝統的な解決策（それぞれに大きな欠点があります）に直面します。

Preemption (プリエンプション): リクエストの KV キャッシュを破棄し、後で再プリフィル（re-prefilling）を行うこと。これにより、リクエストは再びフル TTFT (Time to First Token) のペナルティを支払うことになります。
Offloading (オフローディング): ブロックをホストメモリに移動すること。しかし、高密度アテンション（dense attention）はすべてのトークンが GPU 上に存在することを必要とするため、並列実行数は GPU メモリによって制限されたままとなります。

Hybrid HiSparse は、sparse-MLA KV キャッシュのスパース性を利用することで、これらの制限に対処します。インデクサーがアテンションのために top-K トークンのみを選択する場合、Hybrid HiSparse は容量がある限り KV キャッシュを GPU 上に保持します。システムが KV キャッシュの圧迫に直面した際、最も「コールド」なページを CPU にオフロードし、選択された top-K トークンのみを GPU 上の「ホット・バッファ」に保持します。

Hybrid HiSparse の技術的実装

Hybrid HiSparse は、システムの負荷状況に基づいて、3 つの異なる状態を通じて KV の滞留（residency）滞留管理を行います。

1. Full Residency (フル・レジデンシー)

すべての sparse-MLA KV が GPU 上に保持されます。完了したプレフィックス・ページは、圧迫フェーズにおける追加のコピーを必要とせずに、将来的な退避（eviction）に備えて、事前にホストメモリへコピーされます。

2. Mixed Residency (ミックス・レジデンシー)

GPU メモリが不足している場合、リクエストの末尾（tail）は GPU 上に残り、古いページは CPU メモリに移動されます。システムは、top-K トークンを解決するために融合（fused）カーネルを使用します。滞留しているトークンはその場で読み込まれ、ホット・バッファ内のトークンは LRU エントリが更新されるとともに読み込まれ、ミスが発生した場合は、ピン留めされたホストメモリから単一の行を LRU スロットにコピーします。このプロセスは、デコード・パスの決定が CPU を待機しないため、CUDA-graph-capturable です。

3. No Residency (ノー・レジデンシー)

CPU メモリにのみ存在するプレフィックスを再利用する新しいリクエストの場合、システムはプレースホルダーとホット・ページで開始します。インデクサーが選択したときのみ行がロードされるため、システムはモデルが実際にアテンションをを向けるトークンに対してのみメモリコストを支払うことになります。

メモリ管理と統合

ホット・バッファは個別の割り当てではなく、vLLM の Hybrid Memory Allocator (HMA) プールからリースされた通常の KV キャッシュ・ブロックです。これにより、あるリクエストによって解放されたブロックを、別のリクエストのホット・バッファ容量として再利用することが可能になります。効率を維持するため、ホット・バッファはデフォルトでリクエストあたり 2× top-K 行に設定されます。

8× H200 でのパフォーマンス・ベンチマーク

vLLM は、OpenHands マルチターン・エージェント的ワークロード（13 ターン会話、最初のターンは 74,160 トークン、その後のターンは 753 トークン）を使用して GLM 5.3 のベンチマークを行いました。セットアップは TP8、MTP3、FP8 KV キャッシュ、および 142K admission limit を使用しました。

Hybrid HiSparse（384 GiB HiSparse プールと 128 GiB オフローディング・プールを使用）を標準的なオフローディング・ベースライン（512 GiB プール）と比較した結果、Hybrid HiSparse はより高い並列実行数と、より優れたインタラクティビティとスループットのトレードオフを実現することが示されました。リクエストがスロットの空きを待つ必要がある標準的なオフローディングとは異なり、Hybrid HiSparse はリクエストが部分的な滞留状態でデコードを継続することを可能にします。

vLLM エコシステムとの統合

Hybrid HiSparse は、共有 HMA プール上の滞留ポリシーとして設計されており、既存の vLLM の機能と統合されます。

Prefix Caching (プレフィックス・キャッシング): 他のキャッシュ・グループは、標準的なプレフィックス・キャッシングおよびオフローディングを継続して使用します。
P/D Disaggregation (P/D 分離): プレフィックスが滞留メモリに収まらない場合、Prefill/Decode 分離からのインポートはホスト側に着地します。
Speculative Decoding (投機的デコーディング): リクエストのホット・ステートを共有する、ステップごとの再試行可能な resolver プランを通じて動作します。

Hybrid HiSparse は、vLLM v0.30 での広範な利用が可能になる予定です。現在は NVIDIA GPU 用に実装されています。