ZHA 用树形稀疏注意力改造现有大模型

Zyphra 提出的 ZHA，想解决长上下文推理里一个容易被忽略的开销：即使只读取少量 token，寻找这些 token 的索引器，也可能还在扫描全部历史。它把检索改成逐层搜索树，让「找什么」这一步也有机会减少计算。

结果值得看，但要分开读：在 Qwen3.6-35B-A3B 上，256K 上下文的质量测试接近完整注意力；标题里更吸引人的超长上下文加速，则来自硬件模型推算，还没有优化内核的实测支撑。

稀疏注意力为什么还会被索引拖慢

稀疏注意力的思路，是让每次查询只读取部分历史内容。但如果筛选阶段仍要给所有历史 token 打分，上下文越长，筛选本身就越贵。原文引用的研究称，接近 1M tokens 时，索引可能占到单层耗时的 60% 到 90%。

ZHA 改的是这个环节。它保留完整 KV cache，也就是模型保存的历史键值缓存，只改变每个 query 查找、读取哪些 key 的方式。因此，不能把它理解成压缩掉了整份历史缓存。

具体做法是把连续的 key 分块，生成摘要 key，再把摘要分组、继续压缩，形成树。分块大小为 4、树深为 6 层时，一个顶层节点覆盖 4,096 个 token。

摘要由少量可训练的参考查询生成。论文用切平面估算每块内容的对数注意力质量，再取多个估算面的最大值。直观理解，就是先估计「这一整块里有没有值得读的内容」，再决定要不要往下找。

解码时，query 先给顶层节点打分，通过 top-p 保留累计估计注意力质量达到比例 p 的最小节点集合，再展开这些节点的子节点，直到访问原始 KV 条目。查单个事实可以少走几条分支，需要拼接分散信息时则多展开一些。第一个 token 始终保留，作为注意力汇点（attention sink）。

ZHA 的关键，是让筛选历史内容的过程也变得稀疏。

256K 的质量结果，哪些最有说服力

作者团队在冻结的 Qwen3.6-35B-A3B 上测试了两种树：深树采用 chunk 4、6 层；宽树采用 chunk 256、1 层。两者都用 16 个参考查询，p = 0.95。

下面是团队自报的七项结果，来源为 arXiv 2610.42112 的 Figure 5：

基准	完整注意力	ZHA 深树	ZHA 宽树	MSA
AIME 2026	93.1	91.2	90.8	91.7
SWE-bench Verified	67.4	67.4	68.4	63.6
Terminal-Bench 2.1	49.9	46.7	53.3	46.1
MMLU-Pro	84.9	85.3	85.2	85.3
GPQA Diamond	84.8	85.0	85.0	83.1
RULER-13（256K）	96.0	93.3	96.2	77.1
LongBench v2（thinking）	58.0	63.4	62.4	49.3

最突出的结果来自检索。深树在 LongBench v2 中读取约 1.1% 的 key，MSA 约为 1%，但前者高出 14.1 个百分点。宽树在 RULER-13 上达到 96.2%，略高于完整注意力的 96.0%。

这支持「可以少读很多内容，同时保住部分长上下文任务质量」，还不能推导成普遍优于完整注意力。比如深树的 Terminal-Bench 2.1 得分就从 49.9 降到了 46.7。

训练方式也有吸引力：骨干模型冻结，只训练参考查询，在每层通过 KL 损失匹配完整注意力分配给各块的质量。Qwen 和 Nemotron 实验使用 32K 上下文，训练 1,900 步、共 3.98B tokens，约为 4B。Qwen 新增可训练参数只有 81,920 个，约占 0.00024%。

但少量参数不等于低成本即插即用。作者报告，低于 1B 参数的模型转换困难，4B 及以上才明显改善；在采用 NoPE 的 Nemotron-3.5-Lightning-30B-A3B 上，深树的 RULER-13 比完整注意力低了 25.3 个百分点。能迁移到冻结模型，不代表换个模型就能保住效果。

几百倍加速，离实际部署还有多远

质量分数是实验结果，加速倍数是模型预测，不能合并成同一种证据。

团队没有发布优化内核。延迟分析基于 H100 BF16 的 roofline 模型，评估对象是 batch size 1 下的单层解码，并非整个模型的端到端响应时间。他们还测试了 FP4 路由器变体，但原文没有给出足够细节来判断收益。

轻量配置采用 1 个参考查询、chunk 8、p = 0.75。预测中，ZHA 在约 48K tokens 后超过完整注意力，在约 0.48M tokens 后超过 MSA。到了 10M tokens，博客预测分别加速 32 到 35 倍、4.7 到 5.1 倍；到了 1B tokens，预测值扩大到 373 到 417 倍、52 到 58 倍。

这些数字不能拿来承诺今天的服务性能。在实际测试覆盖的 256K 长度，帕累托前沿配置的预测加速只有 1.93 到 2.28 倍，对应 RULER-13 为 92.7% 到 96.4%。路由、节点选择都有成本，树搜索也需要合适的内核才能跑出收益。

作者另测了 28 种树形结构：读取 10% 到 30% 的 key 时，RULER 准确率较稳定；固定压缩率下，更深的树能在更高稀疏度下保持质量。一个四参数模型预测几何结构对应的准确率，RMSE 为 1.44 个百分点。这说明树形状值得调优，但还不是跨任务通用的配置公式。

我的判断

我认可它对问题的定位：只减少最终读取量，却保留全量扫描的筛选器，长上下文下仍可能遇到瓶颈。ZHA 把优化推进到搜索阶段，比单纯争论「读取多少 token」更进一步。

不过，「真正次二次」仍要连同查询会展开多少分支一起理解。top-p 的预算会随内容变化，原文没有给出足够信息，让我们据此认定所有输入都能获得相同复杂度收益。

和其他方法相比，它的优势是展示了冻结骨干后改造的可行性。MSA 使用平坦块索引，DSA 对缓存 key 打分，NSA 组合压缩、选择与滑动窗口，各自的训练路径和运行条件不同。此次 MSA 对照训练了 40B tokens，是 ZHA 的 10 倍；比较表里的 MSA 持续预训练预算则是 400B tokens，两者不能混用。

因此，七项自报分数是有价值的初步证据，还不足以排出方法优劣榜。尤其是 1B tokens 的外推，没有对应规模的质量验证和真实内核测量。对国内前端、全栈团队，它目前更适合作为理解长上下文成本的技术线索，原文没有提供可直接接入 Node 服务的部署路径。

能拿来做什么

• 给长上下文 AI 编程助手做评估时，把代码修改、终端操作和跨文件检索分开测试；ZHA 在这些任务上的收益并不一致，单个总分容易掩盖退步。
• 如果团队自部署模型，评审稀疏注意力方案时同时追问索引耗时、实际读取比例和 KV cache 占用，避免把少读 key 当成显存已经减少。
• 比较推理加速方案时，先对齐上下文长度、batch size、硬件和测量范围，再看端到端延迟。单层解码的预测倍数不能直接换算成用户等待时间。
• 若计划复现 ZHA，先在目标模型验证转换后的质量，尤其关注小模型和 NoPE 模型，再决定是否投入内核优化。