让 KV Cache「按头分家」：小红书 RedKnot 如何重做长文本推理新引擎

长文本正在成为大模型服务的常态。RAG 会把大量检索片段拼进 prompt，编程 agent 会连续调用工具并积累历史上下文，长会话系统也会把记忆、工具结果和历史状态放进同一个输入里。问题随之出现：输入越长，KV Cache 越大，显存占用、首字延迟（TTFT）、并发能力和分布式 KV 传输都会被拖住。传统推理系统通常把 KV Cache 看成一个稠密的 `[B, H, L, D]` 张量：同一段 token 里，所有 head 被一起存、一起搬、一起算。RedKnot 换了一个视角：KV Cache 的价值不是按 token 均匀分布的，而是强烈按 head 分化的。有些 head 真的需要看完整上下文，有些 head 主要只看局部窗口。既然 head 的职责不同，缓存系统也不应该把它们绑在一起。基于这一点，RedKnot 把 KV Cache 沿「注意力头」这个维度拆开，配合一套专门的存储与计算机制，在保持输出质量的同时显著提升了效率。论文实验显示，RedKnot 最高可带来 1.6–3.54× 的 TTFT 加速、4.7–7.8× 的单卡并发提升，并把预填充阶段的算力（FLOPs）削减 67%–79.5%。

关键词：LLM 推理，KV Cache，长文本，注意力稀疏，推理加速

论文地址：

https://arxiv.org/abs/2606.06256

工程项目持续在开源社区维护：

https://github.com/rednote-machine-learning/RedKnot

在长上下文服务里，预填充阶段需要为输入 token 生成 KV Cache。上下文越长，KV Cache 越大，后续注意力计算需要读取的历史状态也越多。需要极大的算力消耗，显著降低吞吐量。同时长文本输入会引入一定程度的噪音，即使对文本进行标准的推理也会因为模型输入自身的噪音导致推理精度下降。为了应对这一问题，我们主要沿两条路线优化：

位置无关 KV 复用（Position-Independent Cache, PIC）：相同文档片段即使出现在不同位置，尽量复用预先算好的 KV cache，打破前缀的限制。
稀疏化：利用注意力天然稀疏的现象，只保留或重算一部分重要 KV 头的注意力。

利用把 kv cache按照头进行解耦，解决使用 kv cache 和计算 kv cache 粒度不匹配：算法知道有些 head 不重要，存储却还是把所有 head 绑在同一个 token block 里；算法想表达稀疏，执行时却往往变成稠密布局加 attn_mask。

RedKnot 的目标就是把算法、存储和内核的粒度统一到同一个事实：不同 KV head 有不同的上下文需求。

RedKnot 总结了现有方案的三个核心错配：

图1

1. 稀疏其实是「按头」的，而恢复却是「按 token」的。现有 PIC 方案在 token 粒度上挑选要重算的子集，但不同的头关注的 token 子集并不相同。要同时满足所有头，系统只能取各头重要 token 的并集——这个并集往往覆盖了片段中很大一部分 token，复用的意义随之被抵消。如图一所示，我们统计了多个模型在多个数据集 LongBench 推理的每个 head 的最重要 tokens (注意力分数大于 95%）的并集，图中清晰显示在模型的浅层基本上需要重算所有的 token，而深层需要重算的 token 则显著减少。现有的方法CacheBlend，Epic 和 ProphetKV 这些预先挑选一部分 token 的方法并不可靠的原因。

图2

2. 短上下文里，真正的瓶颈是 FFN，而不是注意力。PIC 默认注意力主导预填充开销，但在 agent 场景常见的 2–8K 片段长度下，前馈网络（FFN）贡献了 57%–62% 的 TTFT（图2）。即使把注意力重算降到零，FFN 这块成本也动不了。

3. 算法上省了字节，工程上没省算力。即便算法只保留了每个头的一小部分 KV，存储上仍用稠密的 `[B, H, L, D]` 布局，并在运行时通过 `attn_mask` 表达稀疏。这会让 PyTorch SDPA 无法走上 FlashAttention 的快速路径，带来 4.9–7.6× 的内核惩罚（论文 3.4 节）。

三者的共同根源是：现有方法在恢复、计算、存储这三个粒度，都没有和工作负载真实的「按头、按通道」稀疏结构对齐。

图3

RedKnot 用三个沿正交维度协同设计的机制，把上述三处错位同时对齐（图 3）：

头分类稀疏（Head-Class Sparsification）

离线对每个 `(层, 头)` 做一次分类：少数为「全局头」（约占 12%–15%，复用时重新预填充），多数为「局部头」（约占 85%–88%，在滑动窗口内直接复用）。论文图 4 进一步显示，在 Mistral-7B、Qwen3-32B、Llama-3.3-70B、Qwen3.5-397B、DeepSeek-V4-Flash 等代表性模型上，局部头占比为 83.4%–96.8%，全局头仅 3.2%–16.6%。由于分类在请求间是稳定的，离线做一次即可，在线零额外开销。
稀疏 FFN（Sparse FFN）

只对注意力得分最高的 top-k token 执行稠密 FFN，其余 token 走残差恒等路径。这条维度与上下文长度无关，因此是加速短上下文 agent 负载的唯一抓手——而这恰恰是注意力侧优化够不着的地方。
SegPagedAttention（存储与执行底座）

它把稠密布局换成「按 `(层, 头)` 分段」的分页 KV 存储，并用一个融合的变长（varlen）注意力内核，物理上只保留每个头真正需要的 token。这样每个头都能留在 FlashAttention 快速路径上，全程不构造 `attn_mask`，内核加速比还会随上下文变长而单调增长——这与「稠密 + mask」方案收益递减的趋势正好相反。

三个机制作用在「头、存储、通道」三条正交维度上，因此它们的收益是相乘叠加，而非互相争抢同一份余量。

图4

Elastic Sparsity（弹性稀疏恢复）

RedKnot 把恢复拆成三步：RoPE 位置对齐、按头注意力恢复、部分稀疏 FFN 恢复。其中浅层保守——用局部注意力恢复 + 稠密 FFN，保护早期残差流；深层才启用全局头重算 + 稀疏 FFN，因为深层语义选择性更强、注意力更集中，如图4所示。

SegPaged Attention(段页注意力）

RedKnot 在存储层面尝试不按照 token-level 来存储 kv cache，而是按照 head 来存储，因为不同的 head 的 IO 频率不一样。

架构无关的运行时，RedKnot 不是某个模型专用的稀疏内核，而是围绕「可复用状态对象」构建的通用运行时。通过 `PROFILE` / `BUILDSTATE` / `SELECTVISIBLESTATE` / `EXECUTE` 四个适配器接口，同一套高层策略可以覆盖标准 GQA 模型、Qwen3.5 这类混合注意力 + MoE 模型，以及 DeepSeek-V4 这类 MLA 压缩注意力模型(详见论文第四章节)。

RedKnot 基于 SGLang 实现，在 8 卡 NVIDIA H800（80 GB）服务器上，跨 3 个模型、6 个 QA 数据集、8K–128K 上下文做了评测。论文报告的主要结果包括（数据仅供参考，以开源社区实测为准）：

图5

质量优秀。在 Llama-3.3-70B HotpotQA 上，RedKnot 把精确匹配（EM）从稠密基线的 0.60 提升到 0.80；首字 top-1 / top-10 与稠密路径的一致性达到 0.93 / 0.87，远高于 token 级基线（≤ 0.5）。整体精度通常 ≥ 稠密 F1 的 95%。
稀疏即降噪。上下文越长，注意力越集中。RedKnot 在长上下文区间的准确率反而能「反超」稠密计算——因为它在抑制低价值 token 噪声的同时保留了高质量的注意力结构。

图6

速度更快。TTFT 加速在长上下文下尤为明显，DeepSeek-V4-Flash 上从 16K 的 3.51× 升到 128K 的 5.16×，且加速比随上下文增长而提升，而 token 级基线则趋于饱和。
系统收益。SegPagedAttention 在内核微基准上把 64 层预填充从 5.42 s 降到 0.23 s（128K，约 23.3×）；PD 分离场景下，KV 传输字节最多省 6.3×；单卡并发会话数在 32K 上下文下从 4 提升到 31。

RedKnot 给出的更大启示是：下一代推理引擎不应再围绕「稠密层、稠密序列、仅前缀命中」来组织。不同的头需要不同的上下文范围，不同的片段有不同的复用寿命，不同的 token 贡献的有效信号也截然不同。论文把方向归纳为：让 head-aware KV 成为引擎一等公民、让位置无关 KV 复用成为默认缓存契约、引入跨注意力与 FFN 的「噪声感知调度」，并最终走向一个统一的稀疏服务栈。有望打造下一代以「稀疏层、稀疏序列、任意位置可复用KV」为核心的推理新架构。