显存占用直降30倍！大模型稀疏注意力解码KV缓存方案HiSparse夯爆了

智猩猩AI整理

编辑：BugMaker

长上下文大模型推理，正撞上一堵看不见的墙。

不是算力不够，而是显存放不下。

智能助手需要处理超长文档，Coding Agent需要读取完整代码库，而模型上下文窗口正在迈向百万Token。可每个在线解码请求，都拖着一个随上下文长度线性膨胀的KV Cache。

但服务系统为了随时能选到任意位置，仍把整个 KV 压在 GPU 高带宽内存（HBM）里。

128K token 的 GLM-5.1 请求要占13.09 GB BF16 KV，一个1M Token请求仅KV Cache就可能超过单张H200显存容量。

32K 时几十个并发就耗尽 HBM，128K 时只能容下约 15 个请求。

解码在算力耗尽前，早就撞上了"容量墙"（capacity wall）。

来自斯坦福、Meta、阿里巴巴、蚂蚁集团、上海交通大学、北京大学以及 NVIDIA Research 的研究团队提出了HiSparse。

值得注意的是，论文作者之一马瑞阳（Ruiyang Ma）来自北京大学，主要研究大模型系统优化与 KV Cache 管理，此次 HiSparse 正是围绕长上下文推理中的缓存效率问题展开设计。他也将作为2026全球AI芯片峰会的报告嘉宾，参与智猩猩在同期主办的，进一步交流这一方向的最新探索。

HiSparse不是新的模型，而是一套大模型推理优化技术，它重新设计了KV Cache的存储方式，让长上下文推理不再被GPU显存卡住。

HiSparse 的思路很直接，把每个请求的完整 KV 历史放进主机内存（host memory），GPU 上只留一个小的固定大小缓存。解码时的 HBM 占用随缓存大小走，而不是随上下文长度走。

结果上，它在 H200、B200、GH200 三种硬件上跑 DSA、NSA、Quest 三种稀疏注意力，长上下文负载下峰值生成吞吐最高提升4.7 倍，每Token生成延迟（TPOT）基本持平，高负载下首 token 延迟（TTFT）反而更低。

01

算力还剩，显存先满

稀疏注意力让"读"变便宜，却没让"存"变便宜。

每步选中的集合在不同 token、不同层之间漂移。当前未被访问的位置，下一刻仍可能重新进入选择集合。所以系统干脆把全部 KV 常驻 HBM。

代价就是那堵墙。32K 输入时，一个 GLM-5.1 请求最多占 4 GB KV。全KV基线约在60个并发时达到饱和，此时KV占用约240GB，这是扣掉权重、激活和 CUDA graph 状态后，HBM 剩下的全部。

再往上加并发，调度器放不进新请求，吞吐原地踏步。注意力内核却还有算力余量。

到 128K，同样的算术只能容下约 15 个请求。

更扎心的是，稀疏选择器在每一步都会明确给出“当前需要哪些KV位置”的需求信号。这是一个现成的、逐位置的需求信号，全 KV 服务却白白浪费了。

而且这个需求有结构，相邻解码步大量重选同一批位置，相邻层的选择高度相关。

部分新型稀疏注意力机制进一步利用层间相关性，让多层共享索引器输出。

这正好符合计算机系统中经典的“小缓存+大后端”设计思路。

HBM 应该为注意力真正读的东西付费，而不是为"可能被读到"的所有东西付费。

02

把 KV 搬出 HBM，再用

缓存补回来

HiSparse 把 KV 组织成两级。主机内存（pinned DRAM）存每个活跃请求的权威完整 KV 副本。GPU 上只留一个固定大小的热点缓存（hot device buffer），每个请求、每层 B 个槽位，缓存最近被选中的 KV 记录。

一个页表把每个逻辑位置映射到缓存槽或"仅在主机"标记，LRU 元数据驱动替换。

但真正困难的是，如何在降低显存占用的同时，不拖慢解码过程。

第一，驻留什么。只暂存当前 top-k（B=k）会漏掉每步 30% 的选择，因为选中集合会漂移。HiSparse 用 LRU 管理，在 B=2k 时把 87% 的选择变成设备命中。

第二，把剩余的 miss 藏起来。每个 miss 都要让那一层的注意力等一次主机内存取数。

HiSparse 把命中检测、LRU 替换、元数据更新、主机取数全部融合进一个 CUDA 内核 RESOLVE。每个稀疏层启动一次，直接捕获进 SGLang 的解码 CUDA graph 里。

第三，让解析本身几乎不花时间。RESOLVE 只消费发出的逻辑位置和自己的元数据，对 DSA、NSA、Quest 一视同仁——逻辑索引进、物理槽位出，像一个软件管理的 TLB。

因为它只改 KV 放在哪，选中位置、注意力分数、输出都不变，所以是精确的（exact）。

03

吞吐最高 4.7 倍，

延迟基本不涨

差距随上下文长度放大。

4K 时基线还能在 HBM 里塞下有用的 batch，HiSparse 几乎没空间发挥。一旦上下文变长，基线被容量绑死，HiSparse 让解码显存只随配置的缓存大小走。

为验证通用性，团队进一步测试了三类代表性稀疏注意力模型。

Qwen3+Quest 在 GH200 上，32K 提升3.6 倍（511 到 1824 tokens/s），200K 直接4.7 倍（111 到 520）。

GLM-5.1+DSA 在 H200 上，32K 提升3.1 倍（624 到 1919），160K 提升2.9 倍（232 到 680）。

DeepSeek-V4-Flash 在 2×B200 上，并发 64 时从600 涨到 1257 tokens/s（2.1 倍），如果只统计解码阶段吞吐，提升可达到2.9倍。

HiSparse的主要收益来自更大的解码Batch规模，HiSparse 没让单个解码步更快，而是让同样 HBM 能塞进更大的解码 batch。128K 时每请求 KV从 13.09 GB 压到约 0.4 GB（B=4096），大约 30 倍缩减。

不需要更多吞吐的运营方，可以将省下的容量转化为更少的 GPU 数量，或改用 HBM 更小、成本更低的型号。

延迟这边，重叠区间内每 token 延迟基本持平。以 DeepSeek-V4-Flash 为例，并发16时，基线与HiSparse的 TPOT分别为15.9 ms和16.0 ms。

而在 GLM‑5.1‑FP8 的高负载测试中，高负载下 TTFT反而更低，并发 64 时从 829s降到 171s。

在 GLM-5.2 上开了精确预取后，基线 618 → 无预取 HiSparse 1515 → 开预取后 1727 tokens/s。端到端提升 2.8 倍，其中仅预取一项就把 TPOT 再降 13–15%、吞吐再提 14–17%。

在理想的零主机 IO 情况下，HiSparse 已接近理论性能上界的85%。这说明，系统新增开销主要来自GPU与主机之间的数据传输，而不是缓存管理本身。

HiSparse 全部的代价，就是主机 IO。

04

容量墙换成可调的

延迟问题

HiSparse 不是免费午餐。它用主机 IO 换 HBM 容量，同步解析时每 token 暴露 7 到 8 ms IO，开了预取压到约 3 ms。

短上下文或低并发场景里，它没收益可抵消这份开销，直接关掉就行。

当然，HiSparse也不是所有场景都适用。它更适合长上下文、高并发推理场景，而短上下文任务中收益有限。

因此，HiSparse并不是简单地消除成本，而是把不可控的显存瓶颈，转化为系统可以优化的IO开销。

实验表明，仅依赖投机预测很难稳定隐藏miss，而模型提供更准确的选择信息，才能进一步提升预取效果。

LRU 的选择本身有数据支撑。在 GLM-5.1 的 LongBenchV2 选择轨迹上，B=4096 时 LRU 平均 13.4% miss，稳稳低于 FIFO（17.2%）和随机（16.1%）。而且贴着离线最优 Bélády（8.2%）的走势，说明"近期是否被选"是未来稀疏选择的一个好的在线近似指标。

把缓存翻倍到8192，miss 再砍半到 6.7%。

HiSparse说明，当模型已经知道“需要什么”时，推理系统就不必为“可能需要什么”提前支付全部显存成本。

关注+星标，获取AI前沿进展与开源一线动态