# HiSparse: Turbocharging Sparse Attention with Hierarchical Memory > [!abstract] 概要 > 本記事は査読論文ではなく [[LMSYS]] の技術ブログ記事であり、abstract は存在しない。以下は記事の要旨。 ## 記事情報 - タイトル: HiSparse: Turbocharging Sparse Attention with Hierarchical Memory - 著者: Zhiqiang Xie、Zhangheng Huang、Tingwei Huang([[LMSYS]] Org) - 媒体: LMSYS Org 公式ブログ - 公開日: 2026-04-10 - 実装ガイド: https://github.com/sgl-project/sglang/blob/main/docs/advanced_features/hisparse_guide.md - 前作: HiCache([[SGLang]] の階層メモリシステム、2025-09-10 公開、本記事内で言及されるのみで本文未取得) ## 概要 スパース注意(sparse attention)は top-k 選択により計算・I/O コストの増大を抑えるが、フルコンテキストの KV キャッシュを GPU HBM 上に保持し続ける必要があるため**メモリ容量律速**に陥りやすい。HiSparse は不活性な KV キャッシュエントリをホストメモリへプロアクティブに退避し、GPU HBM 上に頻繁にアクセスされる領域のみを保持する hot device buffer を維持する階層メモリシステムであり、大きな decode バッチサイズを可能にし、長文脈でのスループットを改善する。[[SGLang]] に実装されている。 ## 問題設定 - 対象: [[SGLang]] 上で DeepSeek Sparse Attention(DSA)を用いる LLM のスパース注意による decode。 - 入力: フルコンテキストの KV キャッシュ(GPU HBM に置くとメモリ容量を圧迫)。 - 前提: top-k 選択によるスパース注意は、あるデコードステップで KV キャッシュの一部分のみが active であるにもかかわらず、フルコンテキスト分の KV キャッシュを高速アクセスのため GPU HBM に保持し続ける必要があるため、compute-bound ではなく capacity-bound になりやすい。これによりバッチサイズとスループットの上限が制約される。(Source: [[.raw/articles/sglang-hisparse-2026-04-10.md]]) ## 提案手法 - **アーキテクチャ**: Prefill instance の Model Executor が Staging KV Cache を Decode instance の Host Memory(Full KV Cache)へ渡す。Decode instance 内では Host Memory → Swap-in Kernel → GPU HBM(Hot Device Buffer)→ Model Executor という経路で KV キャッシュが供給され、新規生成分は Write back new KV Cache として Host Memory へ書き戻される。記事は PD(Prefill-Decode)分離構成で図解しているが、co-located インスタンスにも同様に適用できると明記している。 ![[_attachments/sglang-hisparse/fig01-architecture-overview.png]] (Figure: HiSparse のワークフロー概要図。Prefill instance の Model Executor から Decode instance の Host Memory(Full KV Cache)へ KV キャッシュがステージングされ、Swap-in Kernel を介して GPU HBM 上の Hot Device Buffer に読み込まれる。Decode 後の新規 KV キャッシュは Host Memory へ書き戻される。Source: HiSparse ブログ記事の図。) - **Efficient Swap-in Kernel**: 専用 CUDA カーネルが (1) device buffer 上の top-k キャッシュミスを特定し、(2) LRU 方針で退避候補を選定し、(3) ページテーブルを更新してホストからデバイスへ必要なエントリを取得する、という3段の処理を実行する。(Source: [[.raw/articles/sglang-hisparse-2026-04-10.md]]) - **hot device buffer サイズと退避方針の影響**: hot device buffer を 2048 スロットから 4096 スロットへ拡大し、かつ LRU 退避方針を用いることで、ミスカウントが大幅に減少し、クリティカルパス上の swap-in レイテンシが低下する。 ![[_attachments/sglang-hisparse/fig03-cache-miss-count-trend.png]] (Figure: [[DeepSeek-V3.2]](top-k=2048)を LongBenchV2 で評価したキャッシュミス数の推移(100ステップの移動窓で平滑化)。Swap-vanilla(2048スロット)が最もミス数が多く、FIFO(4096)・Random(4096)がこれに次ぎ、LRU(4096)が最もミス数が少ない。Source: HiSparse ブログ記事の図。) ## 新規性 記事は既存手法との直接比較を明示的には述べていないが、以下の設計判断を新規性として提示している。 - スパース注意の課題を「compute-bound ではなく capacity-bound」と定式化し、計算量削減ではなく**メモリ階層設計**で解く点。 - 前作 HiCache の階層メモリの考え方を、スパース注意に特化した top-k キャッシュミス処理・LRU 退避・専用 swap-in カーネルへ発展させた点。(Source: [[.raw/articles/sglang-hisparse-2026-04-10.md]]) ## 実験設定 - モデル: [[GLM-5.1-FP8]](Hugging Face: zai-org/GLM-5.1-FP8)、[[DeepSeek-V3.2]](Hugging Face: deepseek-ai/DeepSeek-V3.2、top-k=2048)。 - 環境: スループット vs 並行数のベンチマークは PD-colocated 8×H200 構成(32k 入力/8k 出力)。シーケンス長スイープのベンチマークは 2×H20 の PD-disaggregated 構成。 - データセット: キャッシュミスカウント評価は LongBenchV2。 - 比較対象: Baseline(HiSparse なしのスパース注意)。退避方針比較では Swap-vanilla(2048スロット)、FIFO(4096)、Random(4096)、LRU(4096)。 - 評価指標: トークン生成スループット(tokens/s)、top-k トークンミスカウント。(Source: [[.raw/articles/sglang-hisparse-2026-04-10.md]]) ## 実験結果 - **並行数に対するスループット**: Baseline は並行数32付近でスループットが約780 tokens/sで頭打ちになり、GPU メモリ容量上限に到達して以降は並行数を増やしても伸びない。HiSparse はほぼ線形にスケーリングし、並行数256で約2,650 tokens/sに達する(Baseline 比3倍超)。低並行数(8〜32)では、スパース KV ロードによる追加 I/O がメモリ節約効果を上回るため HiSparse の方がやや低いスループットになる場合がある。 ![[_attachments/sglang-hisparse/fig02-throughput-vs-concurrency.png]] (Figure: 並行リクエスト数(8〜256)に対するピークスループット(tokens/s)。GLM-5.1-FP8、32k入力/8k出力、PD-colocated 8×H200。Baseline は並行数32以降で約780 tokens/sに頭打ちし、HiSparse は並行数256で約2,650 tokens/sまでほぼ線形にスケールする。Source: HiSparse ブログ記事の図。) - **入出力シーケンス長構成でのスループット**: GLM-5.1-FP8、2×H20 PD-disaggregated 構成で、入力/出力長を20k/10k・20k/20k・40k/10k・40k/20k・60k/10k・60k/20kと変化させたところ、HiSparse は全構成で Baseline を上回った(それぞれ 752→2320、600→2280、472→2080、368→2050、360→1820、352→1720 tokens/s)。最大の改善率は 60k/20k 構成で 352→1720 tokens/s(約4.9倍)であり、記事本文の「長文脈シナリオで最大5倍」という主張と整合する。 ![[_attachments/sglang-hisparse/fig04-throughput-sequence-sweep.png]] (Figure: 入力/出力シーケンス長構成(20k/10k〜60k/20k)ごとの生成スループット(tokens/s)比較。Baseline(青)と HiSparse(オレンジ)。シーケンスが長くなるほど両者の絶対値は低下するが、HiSparse の相対的な優位性は拡大する。GLM-5.1-FP8、2×H20 PD-disaggregated。Source: HiSparse ブログ記事の図。) - **キャッシュミスとエビクション方針**: 上記「新規性」節の図(fig03)のとおり、hot device buffer 拡大と LRU 退避の組み合わせが最もミスカウントを低減する。(Source: [[.raw/articles/sglang-hisparse-2026-04-10.md]]) ## 考察 - 記事は、低並行数では HiSparse がわずかなオーバーヘッドを持つことを明示している。これはスパース KV ロードの追加 I/O が、まだメモリ圧力が支配的でない状況では節約効果を上回るためである。並行数が増えてメモリ圧力が支配的になるにつれてこの優位性が顕在化する。 - HiSparse は現状、DeepSeek Sparse Attention(DSA)を用いるモデルファミリ(DeepSeek-V3.2、GLM-5.1)のみを対象とする実験的機能であり、top-k キャッシュミスによる追加 I/O オーバーヘッドが残る課題として挙げられている。著者らは、より良いオーバーラップと、Grace Blackwell(GB)系のような CPU-GPU 帯域が高い新興プラットフォームによって、このオーバーヘッドがさらに緩和されると期待している。(Source: [[.raw/articles/sglang-hisparse-2026-04-10.md]]) ## 強み・弱点/課題 - **強み**: 並行数が大きい長文脈シナリオで、追加の計算量削減なしにメモリ階層設計のみで最大5倍程度のスループット改善を達成。PD 分離・co-located 双方の構成に適用可能。 - **弱点・課題**: 低並行数ではオーバーヘッドがある。対応モデルファミリが DSA 系(DeepSeek-V3.2、GLM-5.1)に限定される実験的機能であり、汎用性は未検証。ハイブリッドモデルへの拡張は Future Work として言及されるのみで未実装(https://github.com/sgl-project/sglang/pull/21206 として進行中)。定量結果は記事内のグラフ・数値のみに基づき、査読を経た論文としての検証は経ていない。(Source: [[.raw/articles/sglang-hisparse-2026-04-10.md]])