SemiAnalysis：稀疏注意力没有消除内存瓶颈

来源 SemiAnalysis2026 年 9 月 28 日

本篇要点

稀疏注意力只减少每次 SDPA 读取的 KV 条目，top-k 筛选仍需要全上下文可访问；HiSparse 把未命中 KV 从 HBM 调入 DRAM，容量瓶颈是转移而非消失。
B200 并发从 8 升到 16 时，HBM 复用占比从 90.3% 降至 54.8%，主机缓存从 6.0% 升至 40.3%，总命中率仍超过 95%，DRAM 承担了更多长上下文复用。
150 tok/s 下的最低成本取决于首 token 门槛：2 秒上限时 MI355X ATOM 约 0.0607 美元/百万 token，10 秒上限时 GB300 约 0.0451 美元，成本结论不能脱离时延条件。

标题问 DRAM TAM，正文先否掉一个直觉

稀疏注意力确实减少了注意力计算当下的读取量，但并不代表 KV Cache 可以不存。报告最重要的变化是内存层级被重新分工：HBM 留最热数据，主机 DRAM 接住更大的长上下文，存储引擎决定怎么在两者之间搬运。报告没有给出可直接转成市场规模的 DRAM/NAND 金额，因此本篇也不自行外推 TAM。

稀疏注意力省带宽，不直接省容量

top-k 减少本次计算读取，但筛选过程仍要找到全部历史

密集注意力会让每个新 token 读取大量历史 KV Cache。DeepSeek Sparse Attention 先用轻量索引器为历史 token 打分，再只让核心注意力读取 top-k。这会减少 SDPA 环节的访存量。

问题是，top-k 选中谁之前，系统仍需要让全上下文处于可访问状态。所以注意力计算可以稀疏，KV Cache 的总容量需求不会按同一比例消失。

环节	稀疏后变化	没有自动解决的问题
top-k 索引	用低维 query/key 为历史 token 打分	仍要访问全文索引状态
SDPA 读取	只读取选中的 top-k KV	未选中 KV 仍要被保留
系统容量	HBM 可只保留热数据	冷数据转到 DRAM/NAND，并非删除

HiSparse 把 KV Cache 做成两级存储

HBM 是热缓存，主机 DRAM 是更大的后备层

SGLang 团队的 HiSparse 采用类似 LRU 的策略：某个 top-k token 不在 HBM 时，从主机 DRAM 调入；HBM 空间不足时，把最久没用的 KV 移出。

为了减少未命中时的停顿，HiSparse 把第 N 层的 KV 调入与第 N-1 层的计算重叠。这不会让 PCIe/主机内存 I/O 变成零，但会把一部分搬运延迟藏到计算时间下面。

选择

闪电索引器找 top-k

先确定这一层真正需要的历史 token。

命中

HBM 内直接读取

热 KV 不需要跨 PCIe 搬运。

未命中

主机 DRAM 调入

与前一层计算重叠，降低用户感知时延。

淘汰

冷 KV 退回 DRAM

容量从显存转到主机内存，不是被删除。

并发增加后，缓存复用向 DRAM 迁移

总命中率保持高位，但 HBM 已不再独自承担

B200 并发请求	HBM 缓存复用	主机/HiCache 复用	未复用	总命中率
8	90.3%	6.0%	3.7%	96.3%
12	76.5%	19.2%	4.4%	95.7%
16	54.8%	40.3%	4.9%	95.1%

并发从 8 升到 16 时，HBM 中直接复用的 prompt token 占比下降 35.5 个百分点，主机缓存占比则上升 34.3 个百分点。两者几乎一比一替代，所以总命中率仍在 95% 以上。

对内存产业的含义是：稀疏注意力不仅是“少用 HBM”，而是把更多 KV 留在便宜、大容量的主机 DRAM 中，再由引擎对热数据进行分层。

推理成本没有单一冠军

一旦加上首 token 时延，排名就会改变

$0.044

B200·150 tok/s·百万总 token

$0.0607

2 秒 TTFT 门槛下 MI355X

$0.0451

10 秒 TTFT 门槛下 GB300

不约束首 token 时延时，SemiAnalysis 在 150 tok/s 的测量曲线上估算 B200 每百万总 token 约 0.044 美元，比 MI355X ATOM 的 0.049 美元低约 12%。但 B200 附近配置的 p90 TTFT 约 14—19 秒，MI355X 只有约 1.1—1.2 秒。

若只比实测且 TTFT 不超过 2 秒的配置，MI355X ATOM 约 0.0607 美元，B200 约 0.0666 美元，AMD 低约 9%。若把上限放宽到 10 秒，GB300 的 0.0451 美元才进入可行集，比 ATOM 低约 26%。

比较条件	最优实测系统	每百万总 token	结论
150 tok/s，TTFT ≤2s	MI355X·ATOM	$0.0607	比 B200 低约 9%
150 tok/s，TTFT ≤10s	GB300·Dynamo-TRT-LLM	$0.0451	比 MI355X 低约 26%
150 tok/s，不加 TTFT 门槛	GB300·Dynamo-TRT-LLM	$0.033	最便宜，但必须另看等待时间

GLM-5 用索引器决定读哪些历史

多个注意力头共享同一组 top-k token

GLM-5 的闪电索引器先把 query 和 key 降维，只计算用于排名的关联分数，不计算 value 也不做 softmax。多个 query head 的分数被加权汇总，所有注意力头共享一组被选中的 token。

该模型有 7,440 亿总参数、400 亿激活参数，每个 token 路由到 1 个共享专家和 256 个专家中的 8 个。这种专家稀疏性和注意力稀疏性是两件事：前者少算专家，后者少读历史 token。

MHA 与 MQA 的选择取决于上下文长度

短上下文更像计算问题，长上下文才真正变成带宽问题

报告引用实现实验说明：MHA 模式的 FLOPs 较低，但内存开销可比 MQA 高 42 倍；MQA 内存更省，FLOPs 最高高 3.4 倍。在约 2K 到 5K 的较短序列上，MHA 反而可能更快；序列变长后，带宽支配性增强，MQA 才占优。

GLM-5 把 query head 数从 DeepSeek V3.2 的 128 减到 64，同时把 QK NoPE 维度从 128 提到 192。SemiAnalysis 由此怀疑它的算术强度是针对摩尔线程 MTT S4000 类硬件调整的。这是报告的推断，不是 Z.ai 公开确认。

IndexShare 用共享索引器换取吞吐

每四层共用一个索引器，省下的是索引缓存和计算

-75%

索引器缓存

-75%

索引器 FLOPs

1.5—1.8×

prefill/decode 吞吐提升

上下文变长时，索引器自身也会变成明显延迟来源。GLM-5.2 的 IndexShare 让每四个稀疏注意力层共享一个索引器，同时在各层缓存 top-k 索引。报告称它减少 75% 索引器缓存和 FLOPs，并在不同上下文与 prefill/decode 阶段提高 1.5—1.8 倍吞吐。

代价是训练和推理都更复杂：多层需要共享索引分布，推理时还要额外保存每层 top-k 结果。内存节省来自更复杂的系统协同，不是单个算子的免费收益。

对内存需求的结论是分层，不是消失

算法、引擎、HBM 和主机 DRAM 必须一起看

报告给出的数据支持一个很窄但重要的结论：稀疏注意力会降低某些环节对 HBM 带宽的压力，但长上下文和高并发会把更多 KV Cache 推到主机 DRAM。NAND 是否继续承接更冷的层级，取决于引擎是否实现存储后端以及未命中容忍度。

因此，仅用“注意力稀疏比例”去线性下调 HBM、DRAM 或 NAND TAM 都缺少系统层依据。真正需要跟踪的是 HBM 命中率、主机缓存占比、未命中 I/O、TTFT 和并发度。

数字的边界

InferenceX 成本来自 SemiAnalysis 的超大云厂自有运营模型，不是公有云报价；150 tok/s 中有些数字是从实测曲线内插，不是正好在 150 tok/s 独立测试；各系统使用的引擎不同，不能把差额全部归因于 GPU 硬件。