RedKnot – 小红书、北大与华为云开源的长文本推理加速引擎，按注意力头省算力

RedKnot 是小红书机器学习团队于 2026 年 6 月开源的长上下文推理加速引擎，主要用于降低长文本场景下的重复注意力计算，支持按注意力头分层复用 KV Cache 与按段分页存储，适用于长文档问答服务的延迟优化、自建推理集群的算力压降与长上下文模型的效果回归验证等场景。

RedKnot 的核心能力

它要解决的是「长上下文里大部分注意力头实际上不需要整段提示」这件事：把不需要的部分离线算好，剩下的在线算。站内的 DSpark 走的是另一条推理加速路线，可以对照着看。

分层复用 KV 缓存

按长上下文中的行为把注意力头分成两类：可复用的局部头离线准备好，全局头、检索头与恢复头保持在线。两部分的投影贡献最后合并回原模型，接口不变；同一套抽象能映射到 MLA、MHA、GQA与原生滑窗注意力，实际支持程度依模型与分支而异。

按需稀疏执行 FFN

按 token 级的重要性决定哪些行进入开销大的 FFN 计算，MoE 模型上再按路由分布自适应调整专家 Top-K，必要时才多派专家。稠密的边界层与受保护的查询行保留在关键路径上，避免为了省算力把精度伤了。

按段分页存储 KV

KV 页与可见性按头、按段组织，让全局头、局部头、检索头各自吃不同范围的上下文，不必挤在同一份缓存布局里；长文本推理里「一种缓存布局适配所有头」的浪费在这里被拆开。

DeepSeek-V4-Flash 一键复现

可复现的一条路在 SGLang 分支上：DeepSeek-V4-Flash-0731 配 TP8，发布配置为 8 张 H200 或 8 张 B300，64K、128K、256K、440K 四档题集连输入、头策略与执行清单一并打包，一条命令跑完。440K 指 450,560 token 的文档预算，不是模型原生上下文承诺。

接 SGLang、vLLM 与昇腾

7 月放出的 Mistral、Qwen3、Qwen3.5 MoE 与 Llama 3.3 只有实验性基准入口，不像 V4-Flash 那样有打包好的发布配置；9 月迁完 vLLM 侧核心代码，模型级集成与端到端验证仍在推进。当前默认分支已从 SGLang 换成 DeepInfer，可这条分支上 RedKnot 的注意力复用优化还没实现，跑的是全量重算基线，除 V4.1-Flash 外其余模型待移植。昇腾 NPU 由华为云在推。

RedKnot 与 SGLang 的对比

RedKnot 最初建在 SGLang 之上，现默认分支转向 DeepInfer；两者不是替代关系：一个改缓存复用策略，一个提供推理运行时。下表按可核实的结构项并列。

差别集中在三处。加速思路：SGLang 的前缀缓存大致是「整段命中就省」，RedKnot 把复用粒度拆到注意力头，需要离线准备头策略。收益基线：前者看有缓存与无缓存的差，后者对的是全量重算，基线更明确，推不出收益一定更保守。使用前提：SGLang 要配好模型、硬件与运行参数，RedKnot 还多一步模型适配。

RedKnot 是挂在运行时之上的优化层，不重新实现调度与并行。两者叠着用时，收益能不能拿到取决于模型与上下文长度是否落在验证过的区间内，官方要求按套件结果 JSON 判断，别只看单一峰值。

后端推理框架的同类路线可以看站内的 DeepInfer（DeepSeek 开源的内部大规模推理框架），两边都在处理「长文本与高并发下的算力分配」。

RedKnot 的应用场景与适用人群

它的收益出现在「同一份长文档被反复问」的地方；短上下文或一问一答的场景，收益有限。若关注的是推理调度的另一头，站内的 WeKnora 把知识管理与推理放在同一个平台里；模型侧的长上下文能力，可对照站内的 DeepSeek-V4-Flash-Vision-Exp：

• 长文档问答服务：同一份合同、研报被反复追问时，热态首字延迟的改善最明显。
• 自建推理集群：省的是预填充阶段的计算量，账本降幅不等于机器数量降幅，实际要按显存与端到端延迟压测。
• 长上下文模型上线前回归：用冻结题集验证新策略有没有把质量拖下去。
• 多模型统一加速：设计上同一套头策略抽象覆盖 MLA、MHA、GQA 与滑窗注意力，落地程度依分支而异。
• 国产算力适配评估：昇腾 NPU 适配在推进，可作为迁移前的对照组。

适用人群：适合自建推理服务、上下文长度常年超过 32K 的团队，以及要在有限显卡上把长文本并发抬上去的平台方；只跑短对话、或用托管 API 的团队，拿不到这层收益。

RedKnot 的使用方法

可以走的三条路：打包路径最容易复现（在 SGLang 分支），按分支接入便于接进现有服务，读解释文章适合先判断要不要试。完整步骤与策略文件说明见 官方仓库。

打包路径：先把基准验证通过一遍

1. 准备一台 8 卡 TP8 节点，发布配置为 8×H200 或 8×B300，显存按 V4-Flash-0731 要求配齐。
2. 按仓库说明拉取打包好的输入、头策略、稀疏专家策略与执行清单。
3. 执行打包命令，依次跑 64K、128K、256K、440K 四档题集，记录首字延迟与质量分。
4. 对照仓库随附的结果 JSON 判断是否落在验证过的区间内。

按分支接入：先按官方 Quick Start 对齐环境

1. 确认用哪个分支（SGLang / vLLM / DeepInfer），按该分支 Quick Start 对齐 Python、PyTorch、CUDA 与模型环境。
2. 准备该模型的头策略文件，先在小流量上验证输出与重算路径一致。
3. 开启分页后端，观察显存占用与批处理吞吐的变化，再逐步放量。

自评：先判断值不值得改

1. 在项目主页读一遍图文解释，确认自家上下文长度与模型落在适配范围内。
2. 拿一小批真实请求做对照：重算路径与 RedKnot 路径各跑一遍，比延迟与答案一致性。
3. 把「质量回退 1 个百分点」当内部验收线，同时用自家业务题核正确率，超线别为速度上线。

账本不含访存、内核启动与张量并行通信，70–90% 是组件级数字，不等于端到端提速。想了解推理侧另一种中间件的做法，站内的 Open-RAIL 提供一个对照样本。

RedKnot 的项目地址

• 项目主页：https://rednote-machine-learning.github.io/RedKnot/
• GitHub 主仓库：https://github.com/rednote-machine-learning/RedKnot

RedKnot 的价格方案

代码按 Apache-2.0 协议开源，策略文件与基准脚本随仓库发布，不收费，也没有商业授权档位。协议含专利授权条款，使用、修改与分发按许可证条件执行，另需核对仓库内第三方组件声明。

开源免费不等于运行免费。成本主要落在跑基准与适配模型上：TP8 机时是主要支出，四档题集要连续占用同一组 8 卡；模型权重、部署调优与运维另算。

RedKnot 的常见问题