vLLM、GLM 5.3向けにHybrid HiSparseオフロードを導入

導入

長文脈モデルの推論では、単一リクエストを完了できるかよりも、複数のセッションが同時に成長したときのKVキャッシュ管理が難題になる。GPUのブロックプールは固定されているため、エージェントがツール呼び出しや会話を重ねるほど、同時実行中のリクエストが新しいKVブロックを確保できなくなる。

従来の選択肢にはトレードオフがある。プリエンプションはリクエストのKVを破棄し、後で再度プレフィルするため、追い出されるたびに初回と同じTTFTを負担する。一方、通常のオフロードはKVをホストメモリーに保存できるが、密なAttentionでは履歴全体をGPUへ戻さなければならず、並列数はGPU容量に制限される。

vLLMはGLM 5.3向けの最適化としてHybrid HiSparseを導入し、Sparse MLAのアクセス特性をメモリー管理に利用する。

主なポイント

• 圧迫時だけオフロードする。 空き容量がある間はKVをGPUに置き、共有ブロックプールが逼迫した段階で古いページを段階的に解放する。通常時の不要なCPU-GPU転送を抑えられる。
• Top-K参照を活用する。 Sparse MLAのインデクサーは履歴から少数のトークンを選ぶ。HiSparseはそれ以外のKVをCPUに置き、必要な行だけをGPUのホットバッファーへ取り込む。インデクサーKVは対象外で、従来のオフロード機構を利用できる。
• 通常のKVページと資源を共有する。 ホットページは専用の別メモリーではなく、Hybrid Memory Allocatorから通常のKVブロックと同じプールを借りる。1つのリクエストがGPU常駐ページ、CPU上のページ、ホットページを同時に持つことも可能だ。
• 再プレフィルを避ける。 GPUにある行はその場で読み、ホットバッファーのヒットは再利用する。ミス時だけ固定されたホストメモリーから1行をコピーするため、履歴全体がGPUに戻るまで待つ必要がない。
• 既存のvLLM機能と共存する。 プレフィックスキャッシュ、ほかのキャッシュグループ、P/D分離からの取り込み、推測デコード、通常のKVオフロードはそれぞれ既存の経路を利用できる。

3つの常駐状態

Hybrid HiSparseは大きく3つの状態を管理する。完全常駐ではSparse MLAのKVをGPUに保持し、完成したプレフィックスページを先回りしてホストへコピーする。混在常駐になると、リクエストの末尾はGPUに残し、古いページはCPUだけに置く。そのページからインデクサーが選んだ行をホットバッファーへ配置する。CPUにしかないプレフィックスを再利用する新規リクエストは、プレースホルダーとホットページから開始し、モデルが実際に参照する行だけを読み込む。

ホットバッファーは通常のKVページと同じテンソルに存在し、同じブロックプールから割り当てられる。このため、解決処理は常駐行とホット行を統一した行IDで扱える。あるリクエストが解放したブロックを、別のリクエストのホット領域として再利用することもできる。

実装ではSparse MLAの各層に対するコピーをフォワード後の1回の起動にまとめ、モデルのGPUストリーム上で順序付ける。デコード中にCPUの判断を待たないため、CUDA Graphへの対応も維持できる。テンソル並列ランク間でMLA KVが同一であることを利用し、ピン留めホストプールをデータ並列レプリカ単位で共有する設計も採用している。

評価と意味

評価は8基のH200、GLM 5.3、MTP3、FP8 KVキャッシュ、OpenHandsのマルチターン・エージェントワークロードで行われた。長い初回ターンと短い後続ターンを含む設定で、同じホストメモリー予算を使う通常のKVオフロードと比較し、インタラクティビティ、スループット、実行中リクエスト数を測定した。

素材が示す重要な点は、KVの一部しかGPUにない状態でもリクエストがデコードを続けられることだ。これにより、テスト環境ではより高い並列性と長いコンテキストへの対応が可能になった。ただし効果は、Sparse MLAの参照分布、ホットバッファーのヒット率、CPU-GPU帯域、ワークロードに左右される。Hybrid HiSparseはすべてのモデルに適用できる万能策ではなく、モデルが実際に読むトークンを基準にKVの価値を判断するための新しい推論メモリー戦略といえる。

出典：vLLM Blog