128K上下文，模型还没开始想，缓存就先爆了。这是所有做大模型推理的人最头疼的事。小红书技术团队扔出的RedKnot，直接把这个气球剪成了碎片——KV Cache不再按token整体存储，而是按注意力头维度拆开、稀疏化、分页管理。这一刀，砍出了数量级的性能提升。
缓存，怎么就成了瓶颈？
KV Cache的线性增长陷阱
传统Transformer推理中，每个token的Key和Value都会被缓存，以避免重复计算。上下文越长，缓存量线性增长。128K tokens，意味着数GB的显存占用，光是存这些数据就能把GPU显存吃干抹净。更麻烦的是，这些缓存还要在计算中频繁访问，带宽压力巨大。推理引擎优化了半天计算，最后卡在存储和搬运上，像开着跑车堵在乡间小道。
注意力头：被忽视的维度
但仔细看，每个注意力头处理的上下文范围其实不同。有的头关注局部信息，几句话内的关联；有的头负责长程依赖，跨段落的逻辑。传统方法对所有头一视同仁，缓存全部上下文，显然浪费。RedKnot的洞察在于：既然头之间行为差异大，为什么不分开管理？这个思路看似简单，却打开了优化的新维度。
拆解、稀疏、分页：一个都不能少
头分类稀疏：让多数头“轻装上阵”
RedKnot首先将注意力头分为两类：局部头和全局头。实验数据惊人——局部头占比高达83.4%到96.8%。这些头只需要缓存最近的一小段上下文，全局头才需要完整历史。光这一招，缓存量就砍掉一大半。分类的依据是注意力权重的分布模式，通过少量样本就能快速判定。这就像图书馆里，大部分书只需要放在手边，少数珍本才锁进特藏室。
稀疏FFN与SegPagedAttention的协同
前馈网络也跟着稀疏化。不是每个token都激活所有FFN参数，而是根据注意力头的分类动态调整：局部头对应的token只调用轻量FFN，全局头才走完整计算路径。存储上，采用分段分页机制，把连续的KV缓存拆成小段，按需加载到计算单元。算法与存储的粒度统一了，效率自然上来。三个机制像齿轮一样咬合，缺一不可。
实测：加速不是梦，精度没掉队
硬件上的飞跃
在8卡H800集群上，首token时间（TTFT）最高加速3.54倍。单卡并发吞吐提升4.7到7.8倍，意味着同样的硬件，能服务更多用户，响应更快。预填充阶段的FLOPs削减了近80%，这直接转化为能耗和成本的下降。数字背后，是无数工程细节的堆叠：缓存访问模式的优化、内存分配的精细控制、计算图的重编排。
DeepSeek-V4上的惊艳表现
在128K上下文场景下，TTFT加速达到5.16倍，KV缓存传输量最多节省6.3倍。这些数字不是实验室玩具，而是真实模型推理中的表现。更关键的是，精度损失控制在5%以内——通常不低于稠密模型F1分数的95%。效率提升没以牺牲效果为代价，这才是工程优化的真谛。有些激进稀疏方法会大幅降低质量，RedKnot走的是稳扎稳打的路子。
开源，带来什么？
推理引擎开发者的福音
RedKnot的开源，让整个社区都能受益。做推理优化的团队不再需要从头摸索，直接集成这套机制，就能显著提升长上下文场景下的服务效率。小红书作为内容平台，每天处理海量文本，他们的技术落地经验尤其宝贵。开源不是慈善，是生态建设——更多人用、更多反馈、更快迭代。
从KV Cache到整个推理栈
这个思路不止适用于KV Cache。它揭示了一个更一般的模式：识别模型中的异构计算单元，分别优化，可能带来整体性能的阶跃。未来，更多组件或许都能“拆开看”——比如注意力计算本身、激活函数、甚至优化器状态。RedKnot像一把钥匙，打开了细分优化的大门。当大模型越来越大，这种精细化管理的能力，会成为推理引擎的核心竞争力。
