RedKnot – 小红书开源的长文本推理加速引擎

1. RedKnot是什么

RedKnot 是小红书技术团队开源的长文本 LLM 推理加速引擎，通过将 KV Cache 按注意力头维度解耦，离线分类为需全局重算的全局头与可局部复用的局部头，配合 SegPagedAttention 实现按头分页存储与融合变长注意力内核，避免 attn_mask 带来的内核惩罚。同时引入稀疏 FFN 机制，对高注意力分数的 token 执行稠密计算，解决短上下文下 FFN 占预填充延迟过半的瓶颈。该引擎在 128K 上下文下仍能保持低首字延迟与高生成稳定性，为长文本推理场景提供了系统级优化方案。

技术定位与领域： RedKnot 属于大语言模型推理加速领域，专注于长上下文场景下的 KV Cache 存储与计算优化。其核心创新在于将稀疏化粒度从传统的 token 级别下沉到注意力头级别，并引入正交的 FFN 稀疏化，与现有注意力优化方法形成乘法叠加收益。

研发背景： 由小红书机器学习平台团队研发，团队在推荐系统、搜索和 Agent 场景有深厚积累。RedKnot 的诞生源于小红书内部对长文档 RAG、多轮 Agent 调用等场景的迫切需求——传统推理引擎在长上下文下预填充延迟过高，且短上下文下 FFN 计算成为瓶颈。

核心价值： 解决了长文本推理中两个关键痛点：一是传统 KV Cache 稠密存储导致的内存爆炸和 attn_mask 带来的内核惩罚（4.9–7.6× 减速）；二是短上下文（2–8K）下 FFN 计算占预填充延迟 57–62%，而现有注意力优化无法触及。RedKnot 通过头级稀疏和稀疏 FFN 分别解决这两个问题，且在线零开销。

技术特点： 按头解耦的 KV Cache 管理系统，仅 12–15% 的全局头需重算，85–88% 的局部头直接复用；SegPagedAttention 分页存储消除 attn_mask，全程使用 FlashAttention 快速路径；稀疏 FFN 对 top-k 重要 token 执行稠密计算，其余走残差路径；架构无关的适配器接口（PROFILE、BUILDSTATE、SELECTVISIBLESTATE、EXECUTE），统一支持 GQA、MoE、MLA 等注意力架构。

2. 主要功能

• 头分类稀疏（Head Classification Sparsity）： 离线通过 needle-in-a-haystack 测试将每个 (layer, head) 对分类为全局头或局部头。分类结果在请求间高度稳定，在线运行时直接查表应用，不增加任何推理延迟。全局头仅占约 12–15%，局部头占 85–88%，大幅降低重算量。

• 位置无关 KV 复用（Position-Independent KV Reuse）： 支持相同文档片段在非前缀位置出现时复用预计算 KV Cache。通过 BUILDSTATE 接口将常用文档片段预计算为按头分页存储的 KV，在线时 SELECTVISIBLESTATE 根据查询语义动态选择复用，打破传统前缀匹配限制，适用于 RAG 片段拼接、多 Agent 上下文交换等场景。

• 稀疏 FFN 加速（Sparse FFN Acceleration）： 对注意力得分最高的 top-k token 执行稠密 FFN 计算，其余 token 走残差恒等路径。直接削减短上下文下占 TTFT 57–62% 的 FFN 瓶颈，与 KV 稀疏形成乘法叠加收益。通过注意力信号自然选择重要 token，无需额外分类网络。

• SegPagedAttention 存储： 将 KV Cache 从稠密 [B,H,L,D] 张量改为按分段的分页存储，物理上只保留每个头真正需要的 token。配合融合变长注意力内核，全程不构造 attn_mask，避免 SDPA 慢路径带来的 4.9–7.6× 内核惩罚，保持 FlashAttention 快速路径。

• 弹性稀疏恢复（Elastic Sparsity Recovery）： 模型浅层采用保守的局部注意力加稠密 FFN，保护早期残差流；深层才启用全局头重算与稀疏 FFN。这种分层策略平衡了精度与效率：浅层局部头占比高、语义选择性弱，保守恢复防止误差传播；深层全局头比例上升、注意力更集中，稀疏收益最大且精度损失最小。

• 架构无关运行时（Architecture-Agnostic Runtime）： 通过 PROFILE、BUILDSTATE、SELECTVISIBLESTATE、EXECUTE 四个适配器接口统一支持 GQA、MoE、MLA 等不同注意力架构。开发者只需实现这四个接口即可将 RedKnot 集成到现有推理服务栈，降低适配成本。

3. 如何使用

1. 环境要求与前置条件： 需要 Python 3.8+ 和 PyTorch 2.0+，建议使用 NVIDIA GPU（推荐 A100 或更高）。从 GitHub 仓库 `（链接待官方发布后更新） 克隆源码，该实现基于 SGLang 框架。

2. 离线画像分类（PROFILE 接口）： 对目标模型运行 PROFILE 接口，通过 needle-in-a-haystack 测试离线将每个 (layer, head) 对分类为全局头或局部头。生成稳定的 Head Class Map 供后续请求零开销复用。该过程只需执行一次，分类结果在模型版本不变时可长期使用。

3. 预构建可复用状态（BUILDSTATE 接口）： 使用 BUILDSTATE 接口将常用文档片段预计算为 KV Cache，并按头维度分页存入 Global / Local KV Pool。支持位置无关的离线预构造，后续任意位置出现该片段时均可直接复用。

4. 动态状态选择（SELECTVISIBLESTATE 接口）： 收到在线请求时，通过 SELECTVISIBLESTATE 接口根据查询语义和 Head Class Map，从缓存池中选择需复用的局部头 KV 与需重算的全局头范围。该步骤仅需查表操作，延迟可忽略。

5. 融合推理执行（EXECUTE 接口）： 调用 EXECUTE 接口，全局头走完整注意力重算并写入 Online KV Cache，局部头直接复用分页 KV 走局部注意力。同时对低分 token 跳过 FFN 计算走残差路径。融合 varlen 内核确保全程无 attn_mask。

6. 服务化部署集成： 将实现好的四个接口接入现有推理服务栈（如基于 SGLang 的 vLLM 服务），配置缓存池大小和稀疏策略参数后即可上线。建议在浅层设置较低的稀疏度以保护精度。

注意事项： 离线画像需覆盖典型上下文长度范围；BUILDSTATE 的预计算片段应与在线请求的片段一致；稀疏 FFN 的 top-k 比例建议从 10% 开始调优。

4. 优缺点分析

5. 同类工具对比

选型建议： 对于需要高精度且上下文长度在 32K 以内的场景，FlashAttention 是成熟选择，但无法利用 KV 复用。若应用涉及大量重复片段（如 RAG 检索拼接、多轮 Agent 调用），RedKnot 的位置无关 KV 复用和稀疏 FFN 可显著降低延迟，且精度损失可控。CacheBlend 同样支持位置无关复用，但 token 级稀疏导致在线开销和内核惩罚，在精度-延迟平衡上不如 RedKnot。RingAttention 适用于超长上下文（>128K）的分布式场景，但部署复杂且无稀疏优化。

6. 编辑点评

RedKnot 在长文本推理加速领域展现了系统级的创新思维。其核心贡献在于将稀疏化粒度从 token 下沉到注意力头维度，这一洞察源自对不同注意力头在长上下文中行为差异的深入分析——传统方法将所有头视为同质化的稠密结构，而 RedKnot 发现全局头与局部头的有效上下文范围高度分化。这种按头解耦的设计不仅避免了 token 级并集膨胀，还使分类结果在请求间稳定，实现了真正的在线零开销。

从实用价值来看，RedKnot 同时解决了长上下文和短上下文两个极端场景的瓶颈。长上下文下，SegPagedAttention 消除 attn_mask 惩罚，将预填充延迟降低数倍；短上下文下，稀疏 FFN 直接削减占 TTFT 过半的 FFN 计算。这种正交优化策略使其在 2K 到 128K 的广泛范围内都能获得收益，而非像某些方法仅针对特定长度。

适用人群定位为：需要部署长文本 RAG 系统的工程师、多轮 Agent 框架开发者、以及研究 LLM 推理加速的研究人员。对于追求极致延迟的线上服务，RedKnot 的零在线开销特性极具吸引力。

未来发展潜力方面，RedKnot 的架构无关接口设计使其容易适配新模型架构，如 MLA、MoE 等。随着长上下文应用（如代码库级 Agent、多模态长视频理解）的普及，这种系统级优化会越来越重要。不过，社区生态的建设仍是短板，需要更多文档和案例来降低使用门槛。

7. 应用场景

• RAG 长文档问答： 拼接数万检索片段进 prompt，通过位置无关 KV 复用与头级稀疏恢复，将长文本预填充延迟从数十秒降至数秒。具体使用时，先对常见文档片段执行 BUILDSTATE 预计算，在线查询时 SELECTVISIBLESTATE 自动匹配复用，大幅降低每次查询的预填充成本。

• 编程 Agent 多轮工具调用： 连续调用数十次工具并积累历史上下文，利用稀疏 FFN 直接削减短片段（2–8K）下占 TTFT 过半的 FFN 瓶颈。在 Agent 的每次调用中，注意力优化对短上下文无效，但稀疏 FFN 可显著加速，使 Agent 响应更及时。

• 长会话记忆系统： 将用户记忆、工具输出与历史状态统一纳入长上下文，按头复用使单卡并发从 4 路提升至 30 路以上。通过将固定记忆片段预计算为 KV 并复用，减少重复预填充，提升吞吐量。

• 多 Agent 协作框架： 多个 Agent 动态交换、重排上下文片段，位置无关 KV 复用打破“必须前缀匹配”的限制，避免重复预填充。Agent 之间共享的公共知识（如系统提示、工具定义）可预计算后全局复用。

• 实时流式长文本生成： 局部头直接复用近期分页 KV，全局头按需重算，在 128K 上下文下仍保持低首字延迟与高生成稳定性。适用于实时对话系统、长文档续写等场景，避免生成过程中的卡顿。

8. 常见问题FAQ

Q：RedKnot 的离线画像需要多长时间？需要哪些数据？
A：离线画像通过 needle-in-a-haystack 测试进行，通常需要数小时到一天，取决于模型大小和测试配置。需要准备一组覆盖不同上下文长度（如 2K、8K、32K、128K）的测试提示，并确保包含需要精确检索的“针”问题。建议在目标部署场景的典型数据分布上运行。

Q：稀疏 FFN 的 top-k 比例如何设置？是否支持动态调整？
A：top-k 比例通常从 10% 开始，根据精度-延迟 trade-off 调整。对于精度敏感场景可提高到 20–30%，对延迟敏感场景可降低到 5%。当前版本支持静态配置，未来计划支持根据上下文长度动态调整。

Q：RedKnot 是否支持批量推理（batch inference）？
A：支持。RedKnot 基于 SGLang 实现，继承了 SGLang 的批处理能力。但批量推理时，不同请求的 Head Class Map 可能不同，需注意缓存池的并发管理。目前单卡并发可支持 30 路以上（128K 上下文）。

Q：RedKnot 能否与 vLLM 或 TensorRT-LLM 集成？
A：目前 RedKnot 基于 SGLang 实现，但通过四个适配器接口设计，理论上可以适配其他推理框架。社区正在探索 vLLM 集成方案，预计 2025 年下半年提供官方支持。开发者也可自行实现适配器接口进行集成。

Q：RedKnot 在长文本下的精度损失如何？是否适用于金融、医疗等精度敏感场景？
A：在标准长文本基准测试中，RedKnot 通常能达到稠密基线 F1 的 95% 以上，长文本场景下甚至可反超（由于稀疏化减少了噪声）。对于精度敏感场景，建议在浅层保持较高稠密度（如弹性稀疏恢复中浅层用稠密 FFN），并适当增加 top-k 比例。总体而言，RedKnot 的精度损失可控，适合大多数生产场景。

Q：RedKnot 是否支持多模态模型（如 LLaVA）？
A：当前版本主要针对纯文本 LLM 优化，多模态支持正在开发中。由于多模态模型的视觉编码器与 LLM 的交互机制不同，需要调整 PROFILE 接口的测试流程。预计 2025 年第四季度提供多模态支持。

9. 项目地址

• GitHub 仓库： https://github.com/rednote-machine-learning/RedKnot
• arXiv 技术论文： https://arxiv.org/pdf/2606.06256
• 小红书机器学习平台官方组织： https://github.com/rednote-machine-learning