Fathom：让每个查询按需读取KV缓存，降低长上下文解码开销

长上下文推理的瓶颈，未必发生在模型权重或注意力计算本身。当智能体会话延伸到百万级Token、多个会话同时驻留时，KV缓存及用于排序的索引往往需要放入主机内存。此时，每次解码都要扫描大量键向量来选出Top-k候选，数据搬运可能比读取最终命中的KV行更耗时。

Fathom的核心思路不是为所有查询设定统一的扫描精度，而是让每个查询自行决定不同通道需要读取多少比特。论文将4比特K缓存按通道组织成位平面：读取某个通道的前t个位平面，就等价于使用该通道的t比特量化值。这样，部分读取既能保持连续内存访问，也能直接形成逐步增加精度的近似。

在给定总比特预算后，Fathom通过“反向水填充”策略，把更多读取资源分配给对当前查询更重要的通道。相关分配可以用闭式形式计算，并由单个Triton内核执行，避免引入复杂的额外调度。

核心结果包括：

• 在Qwen3-8B、百万Token上下文和A100测试中，相比每Token读取136比特的Double Sparsity、Loki及SparQ配置，Fathom的GPU解码时间达到1.67倍加速。
• 在相同GPU时间下，相比SparQ的68比特读取配置，Fathom少读取18%的字节，同时在六个模型与上下文设置中取得更低的注意力误差。
• 在RULER风格任务中，每Token扫描结果与精确Top-k解码一致；在真实OpenHands编码智能体会话中，读取92比特即可达到最准确136比特扫描的步级一致性。

这项工作的价值在于，它把稀疏注意力的优化目标从“统一压缩索引”推进到“按查询分配读取预算”。对于KV缓存确实位于主机内存的服务系统，减少无效内存流量可能比单纯降低算术量更重要。不过，Fathom并非普适加速方案：当索引已经驻留GPU时，扫描主要受算术运算限制，少读比特并不能同步消除乘加操作，因此收益并不明显。论文还报告，校准数据域对结果影响很小，并公开了代码、结果文件和实验运行链，便于复现。

来源：Hugging Face Daily Papers