HiSparse: Turbocharging Sparse Attention with Hierarchical Memory

发表时间: 2026-04 · Blog post by Zhiqiang Xie, Zhangheng Huang, Tingwei Huang (lmsys.org)

原文: https://lmsys.org/blog/2026-04-10-sglang-hisparse

作者/机构：Zhiqiang Xie, Zhangheng Huang, Tingwei Huang
发布日期：2026年4月10日

速读

一句话结论
提出了一种名为 HiSparse 的分层内存系统，通过将不活跃的 KV Cache 卸载到主机内存并在 GPU 上维护热点缓存，打破了稀疏注意力的显存容量瓶颈，在长上下文和高并发场景下实现了最高 5 倍的吞吐量提升。

要解决什么问题
随着大语言模型向长上下文扩展，标准自注意力的计算量和显存与 I/O 开销会呈二次方急剧增长，这使其成为模型扩展的主要卡点。为了应对这一问题，稀疏注意力（Sparse Attention，即在生成过程中只对选定的部分 KV Cache 子集进行注意力计算）成为一种极具前景的替代方案，它能在保持强大建模能力的同时，避免计算和 I/O 开销的激增。然而，传统的稀疏注意力（通常基于 top-k 选择机制）并没有真正消除显存容量瓶颈。在实际的系统运行中，尽管在任何一个特定的解码步骤里，只有极小一部分的 KV Cache 条目处于活跃状态，但为了保证底层硬件能够快速访问，整个长上下文的完整 KV Cache 依然必须全部驻留在 GPU 的高带宽内存（HBM）中。这种机制导致稀疏注意力在实际部署时，往往受限于显存容量，而不是受限于计算能力。显存容量的硬性限制直接卡死了系统能够支持的最大批处理大小，导致在并发请求增加时，系统的 KV Cache 占用量会迅速触及 GPU 显存的物理上限，使得 Token 生成的吞吐量过早地陷入停滞，无法进一步扩展。

怎么做的
核心思路是引入分层内存架构来打破 GPU 显存对完整 KV Cache 的强制绑定。HiSparse 主动将当前不活跃的 KV Cache 条目卸载到主机内存中，从而大幅降低 GPU 的显存压力。同时，系统在 GPU 的高带宽内存中开辟并维护一个热点设备缓冲区，专门用于存放被频繁访问的 KV Cache 区域，以此将关键路径上的数据搬运开销降到最低。由于显存被大量释放，系统能够支持大得多的解码批处理大小，进而在长上下文场景下实现吞吐量的扩展。无论是 Prefill（预填充）与 Decode（解码）分离的部署架构，还是两者同置的实例，该设计均能适用。该设计的关键由一个专门定制的 CUDA kernel 构成，它在底层承担了三个核心职责：首先，它负责在设备缓冲区中快速识别 top-k 检索时的缓存未命中情况；其次，当缓冲区空间不足时，它会严格按照最近最少使用（LRU）策略来挑选需要被驱逐的缓存候选者；最后，它负责更新页表，并高效地将所需的 KV Cache 数据从主机内存拉取到 GPU 显存中。系统的实际表现高度依赖于热点缓冲区的大小和驱逐策略，例如在配置中将设备缓冲区大小从 2048 个槽位扩大到 4096 或 6144 个槽位，并将主机与设备的内存比例设定为 8 或 10，配合 LRU 驱逐策略，能够大幅降低缓存未命中次数，这直接转化为关键路径上换入延迟的显著降低。

效果如何
实验在两种硬件部署环境下进行：一是单节点 8xH200 的 Prefill 与 Decode 同置部署，二是双节点 H20 的 Prefill 与 Decode 分离部署（张量并行度与数据并行度均设为 8，支持高达 480 的最大运行请求数和 65536 的分块预填充大小）。测试主要使用了 GLM-5.1-FP8 和 DeepSeek-V3.2 这两款采用了 DeepSeek 稀疏注意力（DSA）机制的模型，并在 LongBenchV2 等基准上进行了评估。对比的基线方法是未使用 HiSparse 的标准稀疏注意力机制（代表了将全部 KV Cache 强制保留在 GPU 显存中以换取访问速度的传统路线）。在 8xH200 硬件上处理 32K 输入和 8K 输出的查询任务时，基线方法的吞吐量因显存耗尽而过早停滞，而 HiSparse 展现出随并发量增加而近乎线性的吞吐量扩展能力，在 256 个并发请求时达到了基线吞吐量的 3 倍以上。在双节点 H20 的分离部署下，针对各种输入输出长度配置的全面测试表明，HiSparse 在长上下文场景中实现了最高 5 倍的吞吐量提升。该方法也存在明确的代价与局限性：在低并发场景下，由于节省下来的显存红利不足以抵消稀疏 KV 数据加载带来的额外 I/O 开销，HiSparse 会引入轻微的性能损耗；此外，top-k 缓存未命中引发的额外 I/O 依然是当前的主要开销来源。作者坦言该系统专为追求极致吞吐量的高并发场景设计，未来需要依赖更好的计算与通信重叠技术，或借助具备更高 CPU-GPU 带宽的新一代硬件平台（如 Grace Blackwell 系统）来进一步缓解这一问题，并计划将此分层内存管理方法扩展至混合模型等更广泛的架构中。

1. 主要贡献

核心问题：
随着大型语言模型（LLMs）向长上下文扩展，自注意力（Self-attention）机制因其呈二次方增长的计算量和内存/IO开销而成为主要瓶颈。尽管稀疏注意力（Sparse Attention）机制通过仅关注键值（KV）缓存中被选定的子集，能够在避免计算和I/O成本急剧增加的同时保持强大的建模能力，但它并未消除内存容量瓶颈。在实际应用中，尽管在任何给定的解码步骤中只有一小部分条目处于活跃状态，但完整上下文的KV缓存仍必须保留在GPU的高带宽内存（HBM）中以实现快速访问。这导致稀疏注意力通常受限于内存容量而非计算能力，从而限制了可实现的批处理大小（batch size）和整体吞吐量。

研究目标与创新点：
为了解决上述内存容量受限的问题，本文提出了HiSparse。在基线测试中（未使用HiSparse的稀疏注意力），由于KV缓存的占用迅速达到GPU内存容量上限，其Token生成的吞吐量很早就进入了平台期。相比之下，HiSparse通过层次化内存管理，使得吞吐量能够随着并发请求数的增加实现近乎线性的扩展。在256个并发请求时，HiSparse达到了基线吞吐量的3倍以上。虽然在低并发情况下，由于稀疏KV加载带来的额外I/O开销超过了内存节省的收益，HiSparse会引入适度的开销；但随着并发量的增加和内存压力的主导，其性能优势变得极为显著。

GLM-5.1-FP8模型在PD共置的8×H200部署上使用32k输入、8k输出查询的基准测试结果。
GLM-5.1-FP8模型在PD共置的8×H200部署上使用32k输入、8k输出查询的基准测试结果。

2. 方法细节

层次化内存架构设计。与作者团队先前的工作HiCache（SGLang博客，2025年9月）一脉相承，本文提出了HiSparse：一种旨在克服稀疏注意力内存限制的层次化内存系统。HiSparse是如何工作的：它主动将不活跃的KV缓存条目卸载（offload）到主机内存（host memory）中，从而显著降低GPU的内存压力；同时，它在GPU的HBM上为频繁访问的KV区域维护一个热设备缓冲区（hot device buffer），以最小化关键路径上的数据移动。这种设计使得解码阶段能够支持大得多的批处理大小，在扩展到更长上下文的同时提高了吞吐量。该设计不仅适用于预填充-解码分离（prefill–decode disaggregated）的部署架构，同样也完全适用于预填充与解码共置（co-located）的实例。下图展示了HiSparse的工作流程。
HiSparse工作流程图。

高效的Swap-in内核实现。该系统的核心是一个专门设计的CUDA内核，该内核高效地执行以下过程性步骤：

  1. 首先，在设备缓冲区中识别出top-k的缓存未命中（cache misses）情况。
  2. 接着，通过最近最少使用（LRU）策略选择需要被驱逐（eviction）的候选条目。
  3. 最后，更新页表（page table），并将所需的条目从主机内存抓取（fetch）到设备内存中。
    热缓冲区的大小调整和驱逐策略对未命中率有直接影响。当使用更大的热设备缓冲区（例如4096个槽位对比2048个槽位）并结合LRU驱逐策略时，缓存未命中次数会大幅下降，这直接转化为关键路径上更低的换入（swap-in）延迟。
    DeepSeek-V3.2 (top-k=2048) 在LongBenchV2上的缓存未命中次数基准测试结果，未命中次数使用100步滚动窗口进行了平滑处理。

3. 实验环境与结果

实验环境：

  • 模型：最先进的开源模型 GLM-5.1-FP8。

  • 硬件配置：

    • 配置一：PD共置（PD-colocated）部署，单台 8×H200 实例。
    • 配置二：PD分离（PD-disaggregated）部署，两台 H20 节点（推荐配置，涉及Mellanox网卡 mlx5_0 到 mlx5_3 的IB连接）。

  • 软件配置：基于SGLang框架，依赖 flashmla_sparse 作为NSA解码后端，KV缓存数据类型为 bfloat16。

实验结果：
对多种输入和输出序列长度配置进行了参数扫描（sweeping）基准测试。结果表明，在长上下文场景下，HiSparse实现了高达5倍的吞吐量提升。

GLM-5.1-FP8模型在两台H20的PD分离部署上，跨多种输入和输出序列长度配置的基准测试结果。
GLM-5.1-FP8模型在两台H20的PD分离部署上，跨多种输入和输出序列长度配置的基准测试结果。

部署代码实现细节：
以下为实现上述基准测试的启动脚本代码细节：

# PD-disaggregation deployment (recommended) on two H20 nodes
# prefill instance:
python3 -m sglang.launch_server \
      --model-path "zai-org/GLM-5.1-FP8" --trust-remote-code --watchdog-timeout 100000 \
      --chunked-prefill-size 65536 --max-running-requests 480 --mem-fraction-static 0.8 \
      --tp-size 8 --dp-size 8 --enable-dp-attention --schedule-conservativeness 0.5 \
      --disaggregation-mode prefill \
      --disaggregation-ib-device mlx5_0,mlx5_1,mlx5_2,mlx5_3 \
      --dist-init-addr 127.0.0.1:5757 --nnodes 1 --node-rank 0

# decode instance:
python3 -m sglang.launch_server \
      --model-path "zai-org/GLM-5.1-FP8" --trust-remote-code --watchdog-timeout 100000 \
      --chunked-prefill-size 65536 --max-running-requests 480 --mem-fraction-static 0.85 \
      --tp-size 8 --dp-size 8 --enable-dp-attention \
      --load-balance-method round_robin --prefill-round-robin-balance \
      --kv-cache-dtype bfloat16 --nsa-decode-backend flashmla_sparse  \
      --disaggregation-mode decode --dist-init-addr 127.0.0.1:5757 \
      --disaggregation-ib-device mlx5_0,mlx5_1,mlx5_2,mlx5_3 --nnodes 1 --node-rank 0 \
      --enable-hisparse \
      --hisparse-config '{"top_k": 2048, "device_buffer_size": 6144, "host_to_device_ratio": 10}'


# PD-colocation deployment on a single 8xH200 instance
python3 -m sglang.launch_server \
      --model-path "zai-org/GLM-5.1-FP8" --trust-remote-code --watchdog-timeout 100000 \
      --chunked-prefill-size 65536 --max-running-requests 480 --mem-fraction-static 0.85 \
      --tp-size 8 --dp-size 8 --enable-dp-attention --disable-radix-cache \
      --enable-hisparse \
      --hisparse-config '{"top_k": 2048, "device_buffer_size": 4096, "host_to_device_ratio": 8}'

4. 结论与未来工作

当前支持与限制：HiSparse目前支持使用DeepSeek稀疏注意力（DSA）的模型系列，包括DeepSeek-V3.2和GLM-5.1。HiSparse专为高并发场景设计以最大化吞吐量，但在低并发时，由于top-k缓存未命中引发的额外IO，会引入一定的性能开销。

未来展望：

  1. 性能与覆盖面优化：作为一项实验性功能，团队将继续提升其性能并扩大模型覆盖范围。
  2. 降低开销：计划通过更好的计算与IO重叠（overlap）来减少当前存在的开销，并预期新兴硬件平台（如Grace Blackwell (GB) 系统）更高的CPU-GPU带宽将进一步缓解这一问题。
  3. 架构扩展：遵循早期HiCache工作的方向，计划将这种层次化内存管理方法扩展应用到更广泛的新兴模型架构中，包括混合模型（hybrid models）。

5. 补充细节：致谢

致谢对象：
作者对多个团队和个人在项目中的支持表达了感谢：

  • 企业团队：阿里云TairKVCache团队、蚂蚁集团SCT推理团队、百度Baige AI团队。
  • 个人贡献者：阿里云的Shangming Cai、Teng Ma、Xingyu Ling；SGLang社区的Ziyi Xu；斯坦福大学的Christos Kozyrakis和Kristopher Geda。