并非每个Token都要过FFNRedKnot Token选择性稀疏FFN与自适应专家Top-K执行策略详解【免费下载链接】RedKnotEfficient Long-Context LLM Serving with Head-Aware KV Reuse and SegPagedAttention项目地址: https://gitcode.com/gh_mirrors/re/RedKnotRedKnot 是一个面向长上下文大模型推理的加速方案基于 SGLang核心思想是按需计算通过Head-Aware KV 复用、Token 选择性稀疏 FFN 和自适应专家 Top-K三层策略让不重要的 Token 跳过 FFN 前馈计算、让每个 Token 只激活真正需要的专家。在 HotpotQA 长上下文场景下它减少了约71.9% 的 Prefill 计算量端到端首 Token 延迟TTFT提升2.2×3.1×且答案质量不降反升。 为什么 FFN 是长上下文的隐形瓶颈在长上下文推理中大家习惯盯着注意力Attention做优化但 RedKnot 的剖析文档给出了一个反直觉的事实在 2K8K Token 的 Prefill 阶段FFN前馈网络占到了总耗时的 57%62%比注意力还大。原因在于注意力的 KV 可以跨请求复用但 FFN 的矩阵乘法目前是对每个 Token 都要算一遍的硬性成本。RedKnot 的关键洞察是——并非每个 Token 都需要过 FFN。它的推理流程论文 Algorithm 1可以简化为四步S ← SelectImportantTokens(A)根据恢复的注意力信号选出重要 Token集合 SZ[S] ← FFN(Y[S])只有 S 中的 Token 真正执行 FFNZ[~S] ← 0其余 Token 走残差恒等路径FFN 输出置零等于直通X_next ← Y Z残差合并正常进入下一层这一机制的完整实现位于 sparse_ffn.py与 Head 分类配置、SegPagedAttention 共同组成 RedKnot 的 P0 核心组件。 Token 选择性稀疏 FFN怎么判断 Token重要判断 Token 重要性的信号来自上一层恢复的注意力输出每个 Token 取其注意力贡献向量的L2 范数作为重要性分数直觉很好理解一个 Token 如果注意力输出接近零说明它的隐状态没什么变化走残差直通几乎无损选 Token 的策略不是固定数量而是Top-P 式累计质量阈值mass threshold按重要性降序排列累计到覆盖总质量mass_thresh为止就停止。再叠加两道保险保护机制作用recent_n如 128最近 N 个 Token无条件保留保证局部上下文新鲜min_keep≥1每序列至少保留 1 个 Token防止整层退化为全直通、冻结残差流浅层/质量分数为全零的退化行会自动回退到密集 FFN保证数值安全当mass_thresh1.0时输出与密集 FFN逐位一致可以先验证等价性再开启稀疏。三层调度浅层密集、中层保守、深层激进SparseFFNSchedule把模型按深度分成三档稀疏力度逐级放大层级判定条件策略浅层layer_idx dense_until全密集 FFN保护早期残差流中层dense_until ≤ idx deep_layer_start稀疏使用保守阈值mass_thresh深层idx ≥ deep_layer_start稀疏使用更激进的mass_thresh_deep官方文档中还提供了四档开箱即用的 FFN 预设来自 FFN Presets预设dense_untilmass_threshrecent_n定位speed30.364速度优先balanced200.5128均衡quality320.7128质量优先dense801.0128等价密集基线想自己扫参数找甜点仓库提供了单模型加载、多配置扫描的脚本 sweep_sparse_ffn.py一次加载 Qwen3-32B遍历(dense_until, mass_thresh)网格直接输出每个配置的 F1/EM、TTFT、加速比和深层 Token 激活率。 自适应专家 Top-K每个 Token 激活多少个专家对 MoE 模型稀疏还可以发生在专家路由这一层。RedKnot 的 Pro-0813 配置策略见 scale_policy.py给出了两套机制1. 渐进式 Top-K 调度Progressive Top-K Schedule按层深度逐步收缩每 Token 激活的专家数0-15:6, 16-39:5, 40-60:4浅层0-15 层每个 Token 激活 6 个专家中层16-39降到 5 个深层40-60进一步降到 4 个——浅层承担更多特征提取工作深层则更惜算。2. 基于路由概率质量的自适应 Top-K不固定 K 值而是按每个 Token 的路由概率累计质量默认阈值0.50在候选桶(3, 4, 5, 6)中动态选择置信度高的 Token 激活少而精的专家概率分散的 Token 多激活几个专家兜底。相关硬件侧参数也随模型规模同步调整Pro-0813 版本有384 个路由专家Flash 版为 256 个在线索引 Top-K 从 512 提升到1024原生每 Token 专家数为 6。此外Token 级稀疏还配有上下界约束min_full_ratio0.10、max_full_ratio0.50配合固定预算块选择以 128 Token 为块做 Top-K让路由后的 MoE 行形成少量连续区间而非上千个零散索引——这直接决定了线上 gather/scatter 路径的效率且全程在 GPU 上完成不引入主机同步。 实测效果计算量 -71.9%TTFT 提速 2.2×3.1×RedKnot 团队记录了完整的优化账本TTFT_OPTIMIZATION.md基线是标准 FlashAttention-2 密集 PrefillH200 INT4 Qwen3-32B上下文长度标准 FA-2 TTFTRedKnot TTFT加速比16K3.4 s1.3–1.5 s2.2–2.6×40K10.4 s3.3 s3.1×算法级计算节省 71.9%3.56× FLOPs 减少注意力 −83.8%FFN −79.8%激进的 Sparse FFNmass0.2下深层层平均只有约 13% 的 Token真正执行 FFN加速比随长度增长——基线 Prefill 是 O(L²)而 RedKnot 的局部 Head KV 可复用质量不降HotpotQA 的 SQuAD F1/EM 上持平或反超密集基线早期 F1 下降已被定位为解码路径 Bug 并修复一个诚实的细节FLOPs 减少 3.56×墙钟只快 2.42×40K。差距来自全局 Head 重新 Prefill 时不可跳过的投影 GEMM——这是真实计算而非开销是墙钟加速的理论下限。 如何快速上手最简单的体验方式是跑 RAG 端到端 Demorag_redknot_demo.py加上--sparse-ffn相关参数即可对比稀疏 FFN 前后python examples/redknot/rag_redknot_demo.py \ --model-path Qwen/Qwen3-32B \ --dataset hotpotqa/hotpot_qa --dataset-config distractor --split validation \ --n-samples 1 --n-segments 6 --tokens-per-segment 5000 \ --sparse-ffn --ffn-dense-until 20 --ffn-mass-thresh 0.5 --ffn-recent-n 128 \ --output /tmp/redknot_rag_sparseffn.json输出 JSON 中会包含深层层选中 Token 比例、FFN FLOPs 节省与加速比。若将--ffn-mass-thresh设为1.0FFN 退化为逐位密集的基线适合先做等价性校验。也可以在正式服务中通过独立后端启用 Head 分类的 SegPaged 解码路径python -m sglang.launch_server \ --attention-backend redknot \ --redknot-head-config-path /path/to/head_config.json \ --redknot-segpaged-decode --redknot-page-size 64 总结一张表看懂 RedKnot 的按需计算机制解决什么浪费关键参数源码位置Token 选择性稀疏 FFN深层 FFN 对不重要 Token 的无效计算dense_until / mass_thresh / recent_nsparse_ffn.py渐进式 自适应专家 Top-KMoE 专家激活数量的僵化层间 K 值调度、路由质量桶scale_policy.pyHead 分类 KV 复用 SegPaged注意力对局部 Head 的全量重算Head 配置 JSONglobal/localexamples/redknot/README.md长上下文推理提速的下一步不在于算得更快而在于算得更聪明——RedKnot 用稀疏 FFN 与自适应 Top-K 证明只要选对 Token、选对专家省下的算力可以直接兑现为用户可感知的响应速度。【免费下载链接】RedKnotEfficient Long-Context LLM Serving with Head-Aware KV Reuse and SegPagedAttention项目地址: https://gitcode.com/gh_mirrors/re/RedKnot创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考