vLLM、GLM 5.3 のハイブリッド HiSparse オフロード技術で推論高速化とメモリ効率向上を実現

要約

vLLM は、推論をより高速かつ低コストで実行することを目指しています。本記事は 2 部構成のシリーズ第 1 弾として、GLM 5.3 のための新しい最適化手法について解説します。第 1 回では、ハイブリッド HiSparse が単一の 8× H200 ノード上での集約デプロイメントをどのように支援するかを実証します。このハードウェア構成は、本モデルのサイズにとってはメモリが逼迫しています。ハイブリッド HiSparse を採用することで、GLM 5.3 を最大 100 万トークンのコンテキスト長で実行可能となり、以前はこのハードウェアでは不可能でした。また、あらゆるコンテキスト長において並行処理能力を大幅に向上させることに成功しました。

必要な時にスパーシティ（疎性）を活用する

エージェントワークロードの特徴は、多数の同時リクエストが発生し、それぞれが成長し続ける長いコンテキストを持つ点にあります。GPU のブロックプールは固定されているため、KV キャッシュにはやがて新しいブロックを割り当てるための空き領域がなくなります。

これまでこの課題に対処するための主な選択肢は 2 つあり、それぞれにトレードオフが存在しました。

• プリエンプション：あるリクエストを選択し、その KV キャッシュを破棄して後で再プレフィルします。ただし、リクエストは.eviction（退去）されるたびに TTFT を完全に支払う必要があります。

• オフローディング：ブロックをホストメモリへ移動させますが、密なアテンションではすべてのトークンが GPU 上に存在している必要があるため、並行処理可能なリクエスト数は GPU メモリの容量によって制限されたままです。

スパース MLA の KV キャッシュでは、インデクサーが上位 K トークンを選択し、そのトークンのみにアテンションを向けます。HiSparse はこの挙動を活用し、選択されたトークン以外のすべての KV キャッシュを CPU へオフロードします。これにより、各リクエストが GPU メモリで必要とする上限値を実質的に抑えることが可能になります。

インデクサー用の KV は GPU に残存し、コンテキスト長に応じて成長しますが、全体としては非常に小さくなります。さらに GLM 5.3 の IndexShare により、4 つのスパース MLA レイヤーにインデクサー層が 1 つだけ配置されるため、そのサイズはさらに抑制されます。

そこで提案するのが Hybrid HiSparse です。これは、GPU に十分な容量がある限り KV キャッシュを GPU に保持し、圧力がかかった場合にのみ前述の HiSparse オフロードメカニズムを適用する手法です。ホットバッファページはトークン単位でインデックス化されるため、1 つのページに多数の異なる CPU ブロックから取得されたトークンを格納できます。これにより、広範なコンテキスト範囲にわたって削減効果が発揮されます。

このように Hybrid HiSparse は、システムが KV キャッシュの圧力下にある場合、つまり並行処理数が高い場合にのみ CPU と GPU 間のメモリ転送コストを負担します。

プリエンプションが発生すると、リクエスト B のスロットは解放され、その KV キャッシュも消去されます。従来のオフロード方式では、B の KV はホスト上に残存するため再事前充填（re-prefill）は不要ですが、すべてのデータが GPU に収まるまで B は実行できず、結果として A だけがデコードを続けます。

一方、ハイブリッド・ハイスパース・オフロードでは、各リクエストが最も使用頻度の低いページをその場で解放します。解放されたスロットは新しい末尾（tails）とホットページとして再割り当てされ、両方のリクエストが同時にデコードを継続できます。

ハイブリッド・ハイスパース方式だけが、両方のリクエストを同時にデコード状態に保つことが可能です。ホットページは KV ページと同じブロックプールからリースされます。さらに重要なのは、これらが同じ KV キャッシュテンソル上に存在するため、スパース MLA カーネルからは通常のページとして認識される点です。ハイブリッド・スパース方式特有の利点として、一部のトークンをホットバッファに保持しつつ、他のトークンは GPU 常駐ページに残すことができます。これにより、CPU からの再読み込み量を大幅に削減できます。

仕組みの詳細

*各パネルで同じ上位 K トークンがリングで囲まれています。重要なのは、それらの居住状態（residency）のみが変化することです。実線の矢印は、1 行をホットページへコピーするミスヒットを表します。破線の矢印は、ホットヒットによりコピーなしで再利用されることを示しています。

居住状態はページ単位で追跡されるため、負荷の増減に応じてリクエストは以下の 3 つの状態間を移動します：

• 完全居住（Full residency）: すべてのスパース MLA の KV が GPU に常駐し、完了したプレフィックスページは事前にホストメモリ上にマテリアライズされます。

「Mixed residency（混合リデンス）」では、リクエストの末尾部分は GPU 上に残存し、古いページは CPU メモリのみで管理されます。インデクサーが参照する行はホットバッファーに配置され、ブロックテーブルには実在するブロックと null プレースホルダーが併存します。末尾部分は決して退去しないため、1 つの融合カーネルでトップ K の解決が可能です。残存トークンはその場で読み出され、ホットなトークンは読み出されると同時に LRU エントリが更新されます。キャッシュミスが発生した場合は、ピン留めされたホストメモリから単一の行を LRU スロットへコピーします。デコードパス上の何者も CPU の判断を待たないため、CUDA グラフのキャプチャ対象として維持されます。

「No residency（非リデンス）」では、CPU メモリにのみ存在するプレフィックスを再利用する新しいリクエストが開始され、最初はプレースホルダーとホットページから始まります。行はインデクサーが選択したタイミングで順次到着するため、モデルが注目する部分に対してのみコストが発生し、履歴全体に対して課金されることはありません。

これら 3 つの状態が機能するのは、ホットバッファーが独立した割り当てではないからです。ホットバッファーページは通常の KV キャッシュブロックであり、vLLM のハイブリッドメモリアロケーター（HMA）を通じて残存ページと同じプールからリースされます。リクエストが初めて必要とした時に取得され、不要になった時点で返却されます。行が残存ページにある場合もホットバッファーにある場合も、レゾルバーは HMA 行 ID を渡し、HMA はストライドを 1 つとしてそれらを収集します。あるリクエストによって解放されたブロックは、別のリクエストのホットバッファ容量として再利用可能です。

HiSparse は、圧力がかかる前に準備を整えます。キャッシュ可能なプレフィックスページが完成すると、HiSparse はそのページの CPU へのコピーをキューに積む一方、GPU から引き続きサービスを提供し続けます。もし GPU キャッシュがいっぱいになった場合でも、そのページは別のコピーなしで GPU スロットを解放できます。仮に圧力が新しいページに先に到達しても、コピーがキューに積まれた瞬間から GPU スロットは再利用可能になり、転送が完了した時点で CPU 上のコピーがプレフィックスの再使用のために利用できるようになります。

hisparse-glm ブランチでは、フォワードパス後にすべてのスパース MLA レイヤーを一度の起動でまとめてコピーすることで、この処理経路を軽量に保っています。コピーはモデルの GPU ストリーム上で順序付けられており、同期をシンプルかつ安全に保ちます。

vLLM の他の部分との統合

ハイブリッド HiSparse は、共有 HMA プールに対するレジデンシーポリシーであり、vLLM の他の KV 機構と並列して動作するコネクタです。そのため、スタックの残りの部分はこれまで通り機能し続けます。他のキャッシュグループは通常のプレフィックスキャッシング、転送、オフローディングを引き続き利用します。特にインデクサー KV は HiSparse の影響を受けず、標準的な OffloadingConnector が通常ブロック粒度のストレージで独立してオフロードできます。P/D 非集約からのインポートは、プレフィックスがリジデント領域に収まらない場合にホスト側に配置され、スペキュレーティブ・ディコーディングも、リクエストのホット状態を共有するステップごとの再生可能解決計画を通じて機能します。

ホットバッファはデフォルトでリクエストあたりトップ K 行の 2 倍に設定され、バッファサイズを小さく保ちつつ高いヒット率を実現します。MLA の KV キャッシュは TP ランク間で同一であるため、ホスト側のピン留めプールは DP レプリカごとに割り当てられ、そのローカル内の TP ランク間で共有されます。TP ランク 0 が共有コピーの書き込みを担当し、他のすべてのランクが読み取り可能です。CUDA イベントによってストリームの順序性が保証されます。

数値について

GLM 5.3 のベンチマークは、8× H200 を用いた OpenHands のマルチターンエージェントワークロードで実施しました（ソース）。会話の最初のターンでは 74,160 トークン、その後のターンは各 753 トークン、出力は固定で 220 トークンとする 13 ターンの対話です。両方の TP8 デプロイメント設定では、MTP3、FP8 の KV キャッシュ、142K のアドミッション制限、max_num_batched_tokens=32768、max_num_seqs=256、gpu_memory_utilization=0.92 を採用しました。オフローディングのベースラインでは 512 GiB のプールを用意しましたが、ハイブリッド HiSparse では同じホスト予算を 384 GiB の HiSparse プールと 128 GiB のオフローディング領域に分割して使用しました。

上段：インタラビリティとスループットのトレードオフ。インタラビリティは「1000 ÷ 平均 TPOT」で算出されます。論理的な総トークン処理量は、プレフィックスキャッシュされたプロンプトトークンを含み、8 台の GPU で割った値です。下段：各ベンチマークポイントで収集した vllm:num_requests_running の非ゼロ値の平均です。

ハイブリッド HiSparse: e8ef1e07bd

オフローディングベースライン: 80cb71c9ff

Hybrid HiSparse は、vLLM v0.30 で広く利用可能になる予定です。その間、本記事で示した結果を再現するために使用した起動コマンドやベンチマーククライアントの設定については、以下の再現付録をご参照ください。

必要な場所のみでオフローディングを行う

Hybrid HiSparse は、必要な箇所でのみ KV キャッシュのオフローディングを行います。KV は GPU に配置され、空きがある限りそこに留まりますが、プールが逼迫するとページ単位で退去していきます。ホットバッファと定在ページは同じプールとテンソルを共有するため、負荷のかかるリクエストでもスロットの解放を待ったり、再度プレフィックス処理を行ってコストを支払ったりすることなく、部分的な定在状態のままデコードを継続できます。

設定に応じた効果の見積もり

以下の計算機では、利用可能な HBM を同じく用いた場合の、通常の GPU 定在 KV とハイブリッド・スパースオフローディングの容量を見積もることができます。ワークロード、GPU、並列化、ホットバッファ、ホストプールなどのパラメータを調整して、実際のデプロイ環境に近いシミュレーションを行ってください。値を変更することで、並行処理能力がどの程度向上する可能性があるかを把握できます。

この計算機は、GPU 側のインデクサとホットバッファが維持できる並行処理能力を CPU メモリが制限しないために必要な HiSparse ホストプールの最小値を示します。ネイティブ・インデクサのオフローディングは、独立した CPU プールとしてモデル化されます。これはプレフィックスキャッシュを拡張するものですが、アクティブなインデクサ履歴は依然として HBM を消費するため、実行中のリクエスト制限の一部として残ります。

このプロットは、HiSparse ホスト容量がボトルネックにならないと仮定して、シーケンス長ごとの HiSparse と通常の GPU 常駐型の並行処理能力を比較しています。ホットバッファはリクエストごとに固定の GPU コストを要するため、短いコンテキストでは通常型の常駐の方がより多くのリクエストを収容できます。一方、長いコンテキストでは、スパース MLA の常駐領域を制限することで、HiSparse 型の方がより多くの並行リクエストを維持できるようになります。ホットバッファを増やすことは、その容量の一部と引き換えに、ホットキャッシュのカバレッジを高めることを意味します。

注: これらは計画段階の見積もりであり、保証されたサービング限界ではありません。ランタイムワークスペース、リクエスト長さの偏り、スケジューリングの挙動などにより、実際の運用では到達できる並行処理数は低下する可能性があります。

注: MTP（Multi-Token Prediction）はさらに並行処理を制限する要因となります。その理由は、MTP のホットバッファがすべての検証トークンを同時に収容しなければならないためです。公開時点では、各ホットバッファのサイズは (num_speculative_tokens + 2) × top-K と設定されています。ただし、バッファサイズの削減に向けた取り組みが進むにつれてこの数式は変更される可能性があります。現在、以下の計算機ではこの制約を緩和する予定であるため、まだ考慮されていません。

GLM 5.3 の最適化、第 1 部：vLLM におけるハイブリッド HiSparse オフロード

第 2 部

本シリーズは vLLM で GLM 5.3 を運用するための記事の最初の投稿です。ハイブリッド HiSparse は、P/D（Prefill/Decode）デプロイメントにおいて、コンテキストが最も長く KV キャッシュへの負荷が高まる「デコード側」で特に重要な役割を果たします。

第 2 部では、大規模なデプロイメントにおける最適化の全体像をまとめます。ここでは新しい手法と既存の技術を組み合わせます。具体的には、「Prefill Context Parallelism (PCP)」、Decode Context Parallelism (DCP)、適応的検証 (adaptive verification)、そしてハイブリッド HiSparse です。

謝辞

vLLM のハイブリッド HiSparse 実装は、Matthew Bonanni 氏 (Red Hat)、Lucas Wilkinson 氏 (Red Hat)、Fares Obeid 氏 (Prime Intellect) によって開発されました。この設計は、Chao Lei 氏 (Huawei) と Nicolò Lucchesi 氏 (Mistral) との緊密な協力を通じて形作られました。Simon Veitner 氏 (Red Hat) は、本ブログ記事における性能評価と開発に貢献しました。また、本研究で採用されたスパースオフロードの概念を開発した HiSparse の著者方にも感謝いたします。

付録：結果の再現方法

上記の結果は、vLLM `e8ef1e07bd` を使用しています。Hybrid HiSparse の機能を vLLM v0.30 で広く利用可能にする予定ですが、それまでは上記の特定バージョンをビルドしてください。

8 基の H200 GPU を備えたノード上で Hybrid HiSparse 設定を実行するには、以下のコマンドを使用します：

vllm serve zai-org/GLM-5.3 \
  --served-model-name glm-agentx \
  --trust-remote-code \
  --host 0.0.0.0 \
  --port 8000 \
  --tensor-parallel-size 8 \
  --kv-cache-dtype fp8 \
  --gpu-memory-utilization 0.92 \
  --max-model-len 142000 \
  --max-num-batched-tokens 32768 \
  --max-num-seqs 256 \
  --enable-prefix-caching \
  --attention-config '{"hisparse_config":{"host_pool_gib":384}}' \
  --kv-transfer-config '{"kv_connector":"OffloadingConnector","kv_role":"kv_both","kv_connector_extra_config":{"spec_name":"TieringOffloadingSpec","cpu_bytes_to_use":137438953472}}' \
  --speculative-config '{"method":"mtp","num_speculative_tokens":3}' \
  --enable-auto-tool-choice \
  --tool-call-parser glm47 \
  --reasoning-parser glm45

host_pool_gib は DP レプリカごとに設定され、ホストブロック単位に丸められます。128 GiB のオフローディングプールには、HiSparse が管理しないキャッシュグループ（インデクサー KV など）が格納されます。MTP を含まない HiSparse の再現を行う場合は、--speculative-config オプションを省略してください。

図に示す HiSparse を無効化した MTP3 ベースラインでは、--speculative-config を指定し、--attention-config は省略して、cpu_bytes_to_use の値を 549755813888（512 GiB）に変更してください。

MTP ベースラインでは、HiSparse と --speculative-config の両方を省略します。

HiSparse は現在、NVIDIA GPU のみで実装されています。

パディング付きの OpenHands スイープ再現

ベンチマーククライアントに必要なすべての要素は本ブログに含まれているため、レシピは完結しています。: `build_openhands_padded_dataset.py`

install_evalscope_deps.sh および evalscope-all-nodeps.txt を用意し、これら 3 つのファイルを同じディレクトリにダウンロードしてください。

EvalScope は、acd09b44384d53174768bb1063f675420f76fae9 に固定されています。

以下は、決定論的な 128 件の会話データセットを構築し、各ポイントで新鮮な会話を用いて c1/c8/c16/c24/c32 を実行する処理です。

python3.12 -m venv client-venv
source client-venv/bin/activate
bash install_evalscope_deps.sh
pip install 'modelscope[datasets]==1.34.0' 'lxml==6.0.2'
pip install 'evalscope[perf] @ git+https://github.com/modelscope/evalscope.git@acd09b44384d53174768bb1063f675420f76fae9'

python build_openhands_padded_dataset.py \
  --model zai-org/GLM-5.3 \
  --pad-source openscience \
  --first-turn-length 74160 \
  --subsequent-turn-length 753 \
  --num-turns 13 \
  --number 128 \
  --output-path openhand-zai-org-GLM-5.3.json

evalscope perf \
  --model glm-agentx \
  --url http://127.0.0.1:8000/v1/chat/completions \
  --api openai \
  --dataset swe_smith \
  --dataset-path openhand-zai-org-GLM-5.3.json \
  --dataset-offset 52 \
  --max-tokens 220 \
  --multi-turn \
  --number 4 16 32 48 64 \
  --parallel 1 8 16 24 32 \
  --extra-args '{"ignore_eos":true}' \
  --name tp8-hisparse384-native128 \
  --outputs-dir results \
  --no-timestamp

図におけるインタラクション性は 1000 / mean_TPOT_ms で計算されます。GPU あたりの論理トークンスループットは、EvalScope の総トークンスループットを 8 で割った値です。各測定ポイントでは、30 秒ごとに /metrics エンドポイントをスクレイピングしました。

リクエストの占有率は、非ゼロの vllm:num_requests_running サンプルの平均値として定義されます。また、MTP の受容長は、1 + Δ(vllm:spec_decode_num_accepted_tokens_total) / Δ(vllm:spec_decode_num_drafts_total) で計算されます。