Fathom:面向卸载 KV Cache 的稀疏解码的逐查询读取深度

TL;DR Fathom 以 per-query read depth 在 offloaded KV cache 上按通道重要性分配 bit 预算，利用 bit-plane 存储，以 1.67 倍 GPU 时间加速并降低 attention error。

问题

问题背景

长上下文 agentic 推理场景中，单个会话上下文可达百万 token 且多会话并发，KV cache 及其排名索引驻留 host memory，每个解码步骤的 top-k 扫描成为主要吞吐瓶颈。

现有方法局限

现有稀疏注意力方法如 Double Sparsity、Loki、SparQ 在扫描 K cache 时采用固定高位宽（如 136-bit），导致：

• 每次扫描需从 host memory 读取大量字节，内存带宽主导解码延迟；
• 未根据当前 query 与各 key 通道的相关性动态分配读取精度，造成带宽浪费；
• 这些方法假设索引驻留 GPU HBM，而实际 offload 场景中索引在 CPU 内存，未针对性优化，导致性能不理想。

为什么这个问题难且重要

核心挑战在于 如何在极低 bit 读取量下保持 top-k 选择的准确率。query-key 交互高维且数据依赖，静态分配 bit 预算会损失关键信息；而动态调整需要快速、低开销的决策机制。同时，Fathom 必须兼容已有 4-bit 量化 KV 存储格式，不能引入额外存储或复杂索引。

业界关注度极高：agentic 应用的普及推动上下文长度和会话并发数急剧增长，KV cache 规模膨胀导致内存带宽成本与解码延迟成为推理系统的关键瓶颈。高效且精确的稀疏扫描算法能直接降低单次解码的流量与时间，对云服务成本和用户体验有显著影响。

行业类比

这类似于 向量数据库 中的近似最近邻检索：当向量集合存储在远端内存时，通过查询自适应的 乘积量化 或 倒排索引剪枝，仅读取部分码本或倒排列表，在维持高召回率的同时大幅减少数据传输量。

核心洞察

• **按查询动态分配读取位深**：Fathom 让每个 query 在解码时决定每个 key 通道读取多少位，而非采用固定的 `r` 值。它将 4-bit K cache 储存为通道主序的 bit planes，前缀 t 个平面等价于该通道的 t-bit 量化器。与 SparQ、Loki、Double Sparsity 固定读取 68-bit 或 136-bit 的扫描相比，Fathom 通过逆注水根据通道方差加权重要性分配比特预算，在同 GPU 时间下可减少 18% 字节读取且获得更低注意力误差。这克服了静态剪枝无法适应不同 query 注意力结构的缺陷。
• **复用现有 4-bit 量化 KV 缓存，零额外索引开销**：Fathom 不需要构建独立索引或额外的低精度副本，直接利用量化 serving 堆栈中已有的 4-bit K 副本，按 bit-plane 组织存储。当 KV cache 与索引驻留在主机内存时，扫描流量成为瓶颈；Fathom 的按需读取前缀位平面实现了渐进式传输，适合主机内存带宽受限场景。该方法在 GPU 内存驻留索引时并不更快，凸显其针对 offloaded 场景的设计。这降低部署门槛，因为无需额外存储或预处理步骤。
• **方差加权的逆注水分配提供理论驱动的比特预算策略**：Fathom 对每个 query 的通道重要性使用方差加权，通过逆注水算法决定各通道读取深度。这类似通信中的功率分配，将有限比特预算分配给信息量最大的通道，而不是均匀分配或依据全局静态重要性。实验显示在 RULER 风格任务上每 token 扫描与精确 top-k 解码完全匹配，并在真实 coding-agent 会话中以 92 位达到最精确 136-bit 扫描的步骤一致性，验证了动态预算在保持解码质量的同时压缩流量。

方法

输入

• 查询向量 q 与 4-bit 量化后的 K cache,后者以 channel-major bit planes 存储(同一通道的 4 个 bit 平面连续排列)
• 每个查询 / 每层分配的 bit budget(读出预算),以及离线统计的 variance-weighted channel importance 权重

关键模块

1. Bit-plane store: 4-bit K cache 的每个通道保存为 4 个 bit plane。读取前 t 个 plane 等价于得到该通道的 t-bit 量化值,实现按需读取、节省字节。
2. Per-query read depth / reverse water-filling: 查询根据通道重要性权重,把总 bit budget 反向注水分配:高方差加权的通道获得更深读取(更多 bit plane),低重要性通道读很少甚至不读。该分配是逐查询动态决定的,不是固定模板。
3. Per-layer budgets: 不同 transformer 层分配不同的读出预算,以匹配各层对注意力误差的敏感度(而非全模型同一 budget)。
4. Basis rule: 在读取的 bit-plane 前缀上应用 basis rule(论文 3.5 节),用于从读出 bits 重建 / 校正每通道的量化值,降低近似误差。
5. Host-resident scan kernel: 扫描 kernel 只拉取预算内 bit planes,在 host memory 与 GPU 之间传输最少字节;扫描输出 top-k 索引。

输出

逐查询产生 top-k key indices,然后在对应 key 上计算真实注意力;与 exact top-k 相比,在相同 GPU 时间下读取更少字节且注意误差更低。

与 Double Sparsity / Loki / SparQ 的差异:这些方法每个 key 读取固定的 bit 数(如 68/136 bits),而 Fathom 让每个 query 按通道重要性自适应分配 bit 预算,在 offload 场景下用更少字节达到同等甚至更好的 top-k fidelity。

实验

实验设计

在 Qwen3-8B 模型上，构建了 1M tokens 上下文、多会话并存的 offloaded KV cache 场景。基线包括 Double Sparsity、Loki、SparQ（r=32 与 r=16）。评估指标包括 GPU 时间、读取字节数、attention error、step agreement，任务覆盖 RULER-style 与真实 coding-agent sessions。同时设置 HBM 索引作为对照条件。

关键发现

• Fathom 通过 per-query bit-plane 扫描与 reverse water-filling，在 Qwen3-8B 1M tokens 下，单步 decode GPU 时间比 136-bit scans（Double Sparsity/Loki/SparQ r=32）快 1.67x。
• 与 SparQ 68-bit read (r=16) 相比，在相同 GPU 时间下读取字节少 18%，且在 7 个 model/context settings 中 6 个 attention error 更低。
• RULER-style 任务上每个 per-token scan 精确匹配 exact top-k decoding；在真实 coding-agent sessions 上，Fathom 以 92 bits 达到 136-bit scan 的 step agreement。

与基线对比的解读

Fathom 的核心优势来自动态 per-query 位深分配，而非固定 read depth。相比 SparQ 68-bit，它用更少字节换取更低 error，说明 variance-weighted water-filling 能更有效地利用每个 bit。但该方法仅在 KV cache 与索引位于 host memory 时有效；当索引驻留 GPU memory 时，计算瓶颈转移，加速消失。这为异构存储层级下的稀疏解码提供了清晰的适用边界。

行业影响

落地场景

• 超长上下文 agentic 应用：例如 AI 编码助手、浏览器自动化代理、多会话企业知识库问答系统。这些应用需同时驻留大量会话，KV cache 可达到百万 token，且索引驻留在 host memory。
• 多租户 LLM 推理服务：为不同客户维护独立长会话状态，Fathom 可降低每步 KV 扫描流量，提升单卡并发会话数。

商业价值

• 降本：减少 host→GPU 数据传输，GPU 解码时间提升 1.67 倍（对比 136-bit 扫描），单位 GPU 吞吐提高，直接降低每 token 推理成本。
• 体验提升：长会话响应延迟降低；Fathom 在 RULER 任务上匹配精确 top-k 解码，精度损失小，对产品可用性影响低。
• 硬件灵活性：利用已有 4-bit K cache 存储，无需额外内存或定制硬件，可部署在现有量化推理栈上。

集成接口与 use case

• 作为一个 注意力扫描算子，可插入到已有的量化 serving stack（如 vLLM、TensorRT-LLM）中，替换当前的全量或固定稀疏扫描。需实现 channel-major 位平面存储和逐查询 bit 分配逻辑。
• 具体 use case 1：电商平台的 AI 购物助手。多轮对话累积长上下文（商品信息、历史偏好），Fathom 允许更多并发会话留在 host memory，降低尾延迟。
• 具体 use case 2：代码托管平台的 AI 编程代理。在大型代码库中导航和修改，会话长度常达百万 token，Fathom 可加速每步键扫描，提升交互流畅度并控制 GPU 成本。

局限

• **适用场景受限**: 论文明确承认方法仅在 KV cache 与索引驻留主机内存、GPU 无法容纳全部索引时才带来加速;当索引常驻 GPU 内存(如 HBM)时,其扫描速度并不快于现有方法。这意味着 Fathom 主要服务于大规模离载推理场景,对于常规 GPU 内存充足的服务部署帮助有限,限制了其作为通用稀疏解码组件的适用范围。
• **依赖特定量化与存储布局**: 方法要求 4-bit K cache 且以 channel-major bit-plane 形式存储,这需要服务栈预先持有符合该格式的量化副本。若现有系统使用 FP16 或 8-bit KV cache,则无法直接应用,需额外转换或重新量化。同时 bit-plane 存储虽然支持渐进读取,但增加了存储管理复杂度和可能的内存碎片,对非比特平面友好的硬件或框架不友好。
• **实验模型与任务覆盖有限**: 主要实验基于 Qwen3-8B 单个模型,虽包含 RULER 风格和 coding-agent 会话,但缺乏对更大规模模型(如 70B 及以上)或其他架构的验证。在更大模型上,通道方差加权重要性分布可能不同,reverse water-filling 策略的有效性未知。此外所有对比均基于 4-bit 量化下进行,未与更高精度 KV cache 的方法比较,泛化到其他精度设置存疑。