RidgeFill无需训练跳过上层计算，长上下文预填充提速最高1.6倍

摘要：RidgeFill 是一种无需重新训练模型的长上下文预填充优化方法：仅精确计算底层至分割层，再利用闭式岭回归预测后续各层输入，并将预测结果写入 KV Cache。方法不丢 Token，尾部的指定行、最后数千 Token 及解码阶段仍执行完整模型。在 A100 与 vLLM 环境中，公开实验报告 16K—120K Token 的首 Token 延迟改善约 1.25—1.31 倍，部分配置达到 1.50—1.60 倍，但长文档困惑度及基准得分存在小幅回退风险。

---

核心思路：把部分预填充改写为可缓存的近似计算

RidgeFill 面向长上下文推理中最昂贵的 prefill 阶段。标准 Transformer 必须依次计算所有层，注意力复杂度通常随上下文长度近似二次增长；GQA、MQA 或线性注意力虽然可以降低 KV Cache 规模，却未必能消除标准注意力对提示 Token 的完整计算成本。

RidgeFill 在某一层设置分割点：

• 分割层以下的层按原模型精确执行；
• 从分割层状态出发，为每个后续层拟合一个独立映射；
• 映射结果替代后续层的精确输入，并直接用于填充该层的 Key 与 Value Cache；
• 尾部的指定行、最后数千 Token 以及所有解码步骤仍执行完整模型。

因此，RidgeFill 并不是删除 Token，也不是简单地跳过若干层，而是以预测状态换取更高比例的 Prompt KV Cache 填充速度。

映射机制：闭式岭回归，无需模型训练

RidgeFill 的核心映射通过岭回归拟合。设分割层状态为 (X\in\mathbb{R}^{d\times n})，目标层输入为 (Y\in\mathbb{R}^{m\times n})，线性映射为 (W\in\mathbb{R}^{m\times d})，其闭式解为：

[ W=(Y X^\top+\lambda I)^{-1}X X^\top ]

引入 (\lambda) 可抑制校准样本之间的共线性，并控制预测方差。与在线逐层猜测不同，该映射只需使用校准文本进行一次前向传播即可离线拟合并缓存；对每个后续层分别拟合后，上层输入可以依据分割层状态直接预测。

论文指出，YOCO 和 DeepSeek-V4.1-Flash 已将类似投影直接训练进模型；RidgeFill 的差异在于可以后验装配到未针对该机制训练过的模型上，并保留各层自身的投影与注意力实现。它还支持特定注意力架构，其中错误可能集中于 Key、Value 或循环状态，而不只是标量损失所显示的平均误差。

为什么必须改变评测方法

论文最有价值的部分之一不是速度数字，而是对 KV Cache 近似误差的测量方法。常规做法是在全部 Token 上计算平均损失，但这会稀释填充区域的误差：一个上层缓存即使无法准确检索某条关键信息，只要其他大量 Token 的损失仍然较低，整体指标就可能几乎不变。

RidgeFill 因此组合了三类诊断：

1. 填充区域内的 Needle Retrieval：直接测试被近似写入的上下文能否被准确召回；
2. 依赖远端上下文的 Token Loss：评估当前 Token 是否受到长距离信息影响；
3. Splice Test：把近似缓存中的 Key 或 Value 替换为精确值，定位误差究竟来自哪个组件。

在 Llama-3.1-8B 上，主要误差来自 Key，其规模约为相关误差的一半；在 Qwen3.5-9B 上，Value 与循环状态承担了更明显的误差。该结果说明，RidgeFill 并非对所有 Transformer 都具有同等适用性：注意力实现、归一化位置、状态维度以及上层对前层状态的敏感度都会影响映射质量。

实测表现：长上下文预填充获得显著收益

在 Qwen3.8-27B 的 llama.cpp 分支中，当映射表驻留 VRAM 时，16K—120K Token 的首 Token 延迟改善约 1.25—1.31 倍。代价是 RULER 得分下降约 1.2—1.4 分，LongBench v2 下降约 1.4 分。相关 95% 置信区间包含零，因此不能断言质量必然退化，但也不能排除若干分数点的损失。

在 Qwen3.8-Flash-Next 的 vLLM 实现中，9K—32K Token 场景报告 1.50—1.60 倍加速。RULER Needle 任务得分为 99.8，对照的精确计算为 100.0；新 Token 上的困惑度平均高 2.65%，报告区间为 -0.02% 至 +4.93%。这表明速度收益并非来自测试样本完全失真，但误差上界仍不够紧。

在三个 8B—9B 参考模型上，与相同分割点和尾部配置的 identity fill 相比，拟合映射在两个稠密模型的填充区域 RULER 得分分别提高 49.1 和 49.6 分。不过，其中一个 Llama 配置的损失更差；与已发布 SwiftKV checkpoint 相比，长文档损失差异约为 ±0.03 nat。

工程权衡：更早的 TTFT，不等于免费的计算

RidgeFill优化的是首 Token 延迟，而不是解码阶段。生成阶段的每个新 Token 仍依赖完整模型计算，因此对于短提示、少量输出或已经以批处理吞吐为目标的场景，收益可能有限。长提示、低并发 TTFT 敏感服务，以及文档问答和上下文摘要类工作负载更可能受益。

部署时还需考虑：

• 映射表需要占用额外显存，模型规模、隐藏维度、目标层数量和序列长度共同决定成本；
• 闭式求解的数值稳定性依赖 Gram 矩阵求逆或 Cholesky 分解，生产实现宜使用阻尼、QR/SVD 或分块计算，避免显式求逆带来的精度问题；
• 校准数据必须覆盖目标模型的上下文分布、语言和任务类型，否则映射可能只在分布内有效；
• 同一映射未必能跨模型、跨量化格式或跨注意力后端直接迁移。

最稳妥的部署方式是从较晚的分割层开始，使更多关键交互发生在精确计算区域，再通过线上指标寻找速度与质量的 Pareto 前沿。

开发者落地建议

RidgeFill最适合作为推理引擎中的可选快速路径，而不是无条件替代精确 prefill。部署前应同时记录首 Token 延迟、端到端延迟、吞吐、峰值显存、RULER/Needle、LongBench、困惑度以及真实业务任务成功率，并为高风险查询保留精确回退路径。

验证时不要只比较平均 token loss。至少应覆盖填充区域检索、长距离依赖问答、代码或表格中的精确符号召回、跨语言提示，以及大量用户共享前缀的批处理场景。若业务依赖精确引用或审计，建议限制近似 Token 范围或只对低风险任务启用。

总体而言，RidgeFill 提供了一条务实的长上下文优化路径：通过少量离线校准换取 25%—60% 的预填充延迟改善，并以可控但尚未完全消除的检索和困惑度损失为代价。

---

消息来源：Hugging Face Daily Papers (2026-11-06)

—— 完 ——

主题标签： #长上下文推理 关注 #KV Cache 关注 #预填充优化 关注 #岭回归 关注 #推理加速 关注