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

TL;DR: vLLM は、推論をより高速かつ低コストで実行することを目指しています。この 2 部構成シリーズでは、その目標達成のために GLM 5.3 に導入した新しい最適化手法について解説します。第 1 部では、ハイブリッド HiSparse が単一の 8× H200 ノードでの集約デプロイメントをどのように支援するかを示します。このハードウェアはモデルサイズに対してメモリが逼迫しており、ハイブリッド HiSparse を用いることで、GLM 5.3 の最大 100 万トークンのコンテキスト長での実行が可能になりました（従来はこのハードウェアでは不可能でした）。また、あらゆるコンテキスト長において、大幅に高い同時処理能力を実現しています。

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

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

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

• プリエンプションは、あるリクエストを選択してその KV キャッシュを破棄し、後で再プレフィルします。リクエストは、退去するたびに TTFT（Time To First Token）の全コストを支払うことになります。

• オフローディングはブロックをホストメモリへ移動させますが、密なアテンションではすべてのトークンが 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 はホスト上に残存するため再プレフィルは不要ですが、すべてのデータが GPU に収まるまで B は実行できず、その間は A だけがデコードを続けます。一方、ハイブリッド・ハイスパース・オフロードでは、各リクエストが最も使用頻度の低いページ（コールドページ）をその場で解放し、解放されたスロットは新しいテールとホットページとして再利用されます。これにより、両方のリクエストが同時にデコードを継続できます。

ハイブリッド・ハイスパース方式のみが、両方のリクエストのデコードを維持します。ホットページは KV ページと同じブロックプールからリースされ、さらに重要なのは、それらが同じ KV キャッシュテンソル上に存在するため、スパース MLA カーネルからは通常のページとして認識される点です。ハイブリッド・スパース方式独自の特徴として、一部のトークンがホットバッファに存在する一方で、他のトークンは GPU 常駐ページに残るため、CPU への再ロード量を削減できます。

仕組み

*各パネルで同じ 6 つの上位 K トークンが囲まれており、その所在（レジデンシー）のみが変化します。実線：ミス時に 1 行をホットページへコピー。点線：ホットヒット時はコピーなしで再利用。

レジデンシーはページ単位で追跡されるため、負荷の変動に応じてリクエストは以下の 3 つの状態間を移動します。

• フルレジデンシー: すべてのスパース MLA の KV が GPU に常駐し、完了したプレフィックスページは事前にホストメモリにマテリアライズされます。

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

「レジデンシーなし」では、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 キャッシュを採用し、 admission limit は 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 キャッシュは initially 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 と設定しています。ただし、バッファの縮小に向けた取り組みが進むにつれてこの数式は変更される可能性があります。現在、以下の計算機ではこの制約は考慮されていませんが、将来的にはこの制限を緩和する予定です。

クリックして展開

「並行計算シミュレーター」を全画面で開く

第2部

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

第2部では、大規模な展開に向けた最適化を統合し、新しい手法と既存の技術を組み合わせます。具体的には、「Prefill Context Parallelism (PCP)」、Decode Context Parallelism (DCP)、適応的検証、そしてハイブリッド 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 で広く利用可能になる予定ですが、それまでは上記の特定バージョン（pinned checkout）をビルドしてください。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]({{

「/assets/repro/2026-09-07-glm53-part1-hybrid-sparse-offloading/install_evalscope_deps.sh」および「evalscope-all-nodeps.txt」の 2 つのファイルを用意します。これら 3 つのファイルを同じディレクトリにダウンロードしてください。EvalScope のバージョンは acd09b44384d531768bb1063f675420f76fae9 に固定されています。 （原文の技術表記: 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) で計算されます。