DLite：面向智能体长上下文的无历史投机解码

导语

投机解码的基本思路，是先让一个更小、更快的草稿模型生成一段候选 token，再由目标大模型一次性验证。只要候选序列有较高比例能够被接受，就可以减少目标模型逐 token 解码的次数，从而降低推理延迟。这个方法在相对稳定的对话或文本生成场景中已经较为成熟，但智能体工作负载带来了新的困难。

智能体通常会经历多轮交互，并不断把工具调用结果、环境反馈和新的任务状态加入上下文。上下文不仅越来越长，也会持续变化。论文指出，在这类场景下，现有草稿模型的接受长度最高可能下降 80%；如果继续为草稿模型维护完整的历史 KV 缓存，还会带来额外的显存和系统管理负担。

DLite 的核心思路

DLite 将问题归因于同一个来源：不断膨胀的历史上下文。与其让草稿模型反复理解和保存完整历史，不如直接利用目标模型在主推理过程中已经产生的上下文隐藏状态。基于这些状态，DLite 在局部范围内完成 speculative prediction，不再显式维护一套与历史上下文对应的草稿侧 KV 缓存。

这一设计把“根据越来越复杂的历史预测后续内容”的任务，转化为“基于当前上下文表示进行局部预测”。论文将其称为 history-free speculative decoding。它并非完全忽略上下文，而是复用目标模型已经编码过的信息，避免重复保存和处理历史序列。

DLite 还引入了轻量级 sequential head。投机解码通常希望并行生成一个候选块，但并行预测可能削弱块内 token 之间的因果关系。顺序头用于在较低额外开销下恢复这种依赖，使后续候选能够参考同一候选块中先前位置的预测结果。

训练与结果

由于 DLite 的结构同时包含目标模型隐藏状态、局部预测模块和顺序头，论文没有直接套用普通草稿模型的训练方式，而是设计了针对这一异构架构的两阶段训练策略。摘要未披露训练阶段的全部细节，但明确指出，该策略用于让历史无关的表示复用与块内顺序预测协同工作。

在通用任务、长上下文任务和智能体任务上的实验中，DLite 的接受长度达到 2—6。论文还报告称，相比当前先进的投机解码方法 DSpark，DLite 的性能最高提升 70%。这些结果表明，减少历史状态维护不只是工程层面的节省，也可能改善草稿预测在动态上下文中的稳定性。

意义与限制

DLite 的价值在于重新审视草稿模型的上下文需求：对智能体推理而言，完整历史未必需要由草稿侧再次保存和建模。复用目标模型的中间表示，有望降低长会话和连续任务中的缓存压力，并为推理服务系统提供更固定的草稿侧成本。

不过，摘要层面的结果尚不足以判断它在不同硬件、模型规模和任务分布下的实际端到端收益。接受长度也不等同于整体吞吐或延迟，真实部署仍需结合验证开销、隐藏状态传输、并发调度和显存占用进行评估。总体来看，DLite 为面向智能体的投机解码提供了一个清晰方向：减少对不断增长的历史状态的依赖，把优化重点转向目标模型已经计算出的上下文信息。

来源：Hugging Face Daily Papers