小红书 RedKnot

• 1. 概要 （共 280 字）

  RedKnot 是小红书（REDnote）引擎架构部 AI Infra 团队于 2026 年 6 月底开源的长文本大模型推理加速引擎，底层构建在开源推理框架 SGLang 之上，作为注意力层扩展集成。它的核心判断很朴素：并非每个注意力头都需要完整的键值缓存（KV），也并非每个词元（token）都要走完整的前馈网络（FFN）。沿这个思路，RedKnot 把长文本推理的预填充算力削减了约五到七成，首字延迟（TTFT）带来 1.35 倍到 2.2 倍的加速，且上下文越长收益越明显。它不是一个消费级 AI 应用，而是一套面向开发者和服务商的底层推理优化基础设施，采用 Apache-2.0 协议开源。

• 2. 产品背景 （共 376 字）

  RedKnot 由小红书主导研发，北京大学与华为云提供合作支持，核心研发工作由小红书引擎架构部 AI Infra 团队的萧逸、安兹等人完成，配套论文《RedKnot: Efficient Long-Context LLM Serving with Head-Aware KV Reuse and SegPagedAttention》由小红书、北京大学、华为云的多位作者共同署名，已同步发布于 arXiv（编号 2606.06256）。小红书做这件事并不偶然——它在推荐系统、搜索和多轮 Agent 调用场景有深厚积累，内部对长文档检索增强生成（RAG）、多轮 Agent 调度等需求极其迫切。随着大模型上下文窗口不断拉长，长文本推理的显存占用与首字延迟成了服务规模化落地的核心瓶颈，传统推理引擎在长上下文下预填充延迟过高、短上下文下 FFN 计算又成为瓶颈，RedKnot 正是为解这两个问题而生。

• 3. 产品功能与使用体验 （共 670 字）

  RedKnot 的技术骨架由四块拼成，三者作用在「头、存储、通道」三条正交维度上，收益相乘而非互相争抢余量。第一块是注意力头分类，它把每个「层 + 头」组合归入 global（全局）、local（局部）、retrieval（检索）、dense（稠密）四类，按类别决定 KV 的存储与复用策略。实测中局部头占比稳定在 83.4% 到 96.8%，也就是说绝大多数头其实只看局部窗口，不需要完整上下文。第二块是离线 KV 复用加 RoPE 重定位，可复用片段的 KV 离线存储，服务时只选择性重算必要 token，并用旋转位置编码重定位保证数值对齐。第三块是弹性稀疏或者说稀疏 FFN，基于注意力重要性做 token 级 FFN 选择，跳过低贡献 token 的前馈计算，这条特别针对 Agent 场景常见的 2K 到 8K 短片段——在那个长度下 FFN 才是预填充的真正瓶颈，占首字延迟的五成到六成。第四块是 SegPagedAttention 运行时，为每个头建立独立页表加分段 KV 存储，让不同类别的头拥有各自不同的可见窗口，全程留在 FlashAttention 快速路径上，不构造 attn_mask，从而避开了传统前缀缓存一旦传入掩码就退回慢核函数、带来 4.9 到 7.6 倍惩罚的老问题。   因为 RedKnot 是作为 SGLang 的注意力层扩展集成，它完整保留了 RadixAttention、零开销调度、PD 分离、连续批处理、量化等原生高性能能力，服务商无需重构原有架构即可接入。代码已公开维护在 GitHub（rednote-machine-learning/RedKnot），一行命令即可复现全部 RAG 基准测试。

• 4. 定价与商业模式 （共 185 字）

  RedKnot 本身开源免费，采用 Apache-2.0 协议，没有商业定价。它的价值不在直接变现，而在降低小红书自身及外部开发者运行长上下文模型的算力成本。对算力资源日益紧缺的推理服务商而言，这种通过底层架构精细化拆解来缓解长文本推理负担的思路，等于用更少的 GPU 干更多的活。团队表示 DeepSeek-V4 与完整 Qwen 3.5 系列将在下一版本完整适配，目前开源的是基础版本。

• 5. 用户评价 （共 236 字）

  作为刚开源的基础设施，RedKnot 的真实用户反馈主要来自开源社区和技术媒体，尚未形成大规模终端用户口碑。社区普遍认可它把 KV 缓存从「按 token 统一管理的被动数据块」变成了「按注意力头拆分的、模型感知的运行时基础设施」这一视角创新，认为它给长上下文服务提供了一个有价值的思考框架：复用的收益能不能落地，取决于复用与重算的粒度是否对齐了模型推理的内在结构。也有开发者指出，GitHub 仓库在初始化阶段内容尚不完整，配套文档和更多模型的适配还在路上，需要时间验证工程成熟度。

• 6. 行业评价 （共 344 字）

  多家中文科技媒体对 RedKnot 给出了偏正面的解读。行业观点认为，它将稀疏化粒度从传统的 token 级下沉到注意力头级，并引入与注意力正交的 FFN 稀疏化，与现有注意力优化方法形成乘法叠加收益，是长文本推理领域一次有代表性的系统级创新。在 8 卡 H800 的实测中，RedKnot 将 TTFT 加速 1.6 倍到 3.54 倍，单卡并发能力提升 4.7 倍到 7.8 倍，预填充阶段算力消耗削减 67% 到 79.5%；在 DeepSeek-V4-Flash 的 128K 超长上下文任务上，首字生成速度提升 5.16 倍，KV 数据传输效率优化 6.3 倍，推理精度仍保持在稠密模型性能的 95% 以上。有评测认为，RedKnot 在长上下文推理加速方向上与 vLLM、SGLang 原生优化形成了互补而非替代关系，更适合作为高性能推理栈的可选扩展。

• 7. 争议与风险 （共 272 字）

  RedKnot 当前最明确的已知风险来自团队自己的诚实披露：在 Llama-3.3-70B 的长文本场景下，RedKnot 的 decode 路径存在退化，仍待进一步排查。这意味着它并非对所有模型都即插即用，适配范围目前集中在 Qwen、Mistral、Llama 等已验证模型，DeepSeek-V4 与完整 Qwen 3.5 系列尚待下一版适配。此外，作为一项偏底层的系统优化，它的收益高度依赖具体模型结构、上下文长度与服务负载，通用场景下的稳定性仍需更多生产环境检验。稀疏化带来的是「近乎无损」而非「绝对无损」，在对精度极度敏感的金融、医疗等场景，仍需谨慎评估。

• 8. 适用人群与使用建议 （共 239 字）

  RedKnot 适合两类人：一是运行长上下文大模型服务的工程师与团队，尤其是做长文档 RAG、多轮 Agent 编排、长会话记忆系统、多 Agent 协作框架、实时流式长文本生成的服务商，它能直接缓解显存与首字延迟压力；二是研究推理系统优化的学者与基础设施爱好者，可基于其开源代码做二次研究。它不太适合只想用现成 AI 应用、不碰部署的普通用户。如果团队追求开箱即用的成熟方案，vLLM、SGLang 原生能力仍是更稳妥的默认选择；若长上下文成本已成痛点，RedKnot 值得作为补充扩展评估试用。

• 9. 总结 （共 129 字）

  RedKnot 是小红书把内部推理系统经验外溢为开源基础设施的一次扎实尝试，它用「按头拆分 KV」的朴素洞察撬动了长文本推理的效率天花板，在近乎不损精度的前提下把预填充算力砍掉大半。它未必会取代现有推理引擎，但很可能成为高性能长上下文服务栈里一个值得关注的拼图。

暂无深度报告

• 

  CYcoo

  —

  按头拆 KV 这个思路确实比 token 级稀疏更贴合模型结构，点赞。

---

• 

  Eric_SandersX

  —

  Llama-3.3-70B 长文本 decode 会退化，团队自己都写了，态度可以。

---

• 

  zure1yg

  —

  Apache-2.0 协议，商用无忧，准备 fork 一份研究。

---

• 

  Raymond.Rivera_888

  —

  小红书这次开源挺实在，论文和代码一起放，比只发博客强多了。

---

• 

  PhoenixFireColeman

  —

  GitHub 上 star 涨得很快，社区热度起来了。

---

• 

  h22n5dovn

  —

  仓库现在还是初始化阶段，文档不全，想直接上生产的话得自己啃代码。

---

• 

  PeytonKristensen

  —

  我们做长文档 RAG 的，之前 SGLang 跑 32K 上下文首字延迟经常过两秒，接上 RedKnot 的注意力头分类后稳定在 0.9 秒左右，精度几乎没掉，这周的 P99 指标好看了不少，已经准备推到预发环境再观察一周。

---

• 

  Jack220

  —

  单卡并发能从 4 路提到 30 路以上，长会话记忆场景太友好了。

---

• 

  urpzgze1y

  —

  我们主要在短上下文的 Agent 场景用，2K 到 8K 的片段里 FFN 才是瓶颈，RedKnot 的稀疏 FFN 跳过那些低贡献 token 的前馈，TTFT 直接砍掉一截，多轮工具调用顺滑很多，这块收益比长文本还明显。

---

• 

  DDiaz_7

  —

  认真读了论文，位置无关 KV 复用（PIC）以前加速不明显，是因为传入掩码就退回慢核函数、带来四到七倍惩罚，RedKnot 用 RoPE 重定位加 SegPagedAttention 把这个问题绕开了，工程上很聪明，难怪精度能保住。

---

• 

  haSAN

  —

  在 8 卡 L20Y 上复现了 Qwen3-32B 的 HotpotQA，16K 到 32K 下 F1 确实不低于基线，TTFT 从 1.39x 涨到 1.93x，FLOPs 省了七成左右，和官方数据对得上，没有虚标。

---

• 

  琉璃

  —

  论文署名有北大和华为云，产学研结合，质量有保障。

---

• 

  天涯573

  —

  和 vLLM 的实测对比过，RedKnot 不是替代而是补充，它作为 SGLang 的注意力层扩展存在，保留了 RadixAttention、连续批处理、量化这些能力，接入成本不高，适合已经被 SGLang 栈绑定的团队。

---

• 

  nODElINK

  —

  深度用了两周，结论是长上下文越长越划算，我们 128K 的检索任务首字速度翻了五倍多，KV 传输也优化了不少，不过要注意它目前对 Qwen、Mistral、Llama 适配最好，别的模型得自己验证。

---

• 

  Larry.Moore_202218

  —

  踩了个坑提醒一下：DeepSeek-V4 和完整 Qwen 3.5 系列官方说下一版才完整适配，现在基础版跑这两个模型要自己改配置，别直接照着 README 的默认参数上，容易在 decode 阶段退化。

暂无评论