Agent 应用把大模型推理拖进了一个尴尬区间:上下文越滚越长、多轮交互越来越密,而主流加速手段——投机解码——恰恰在这种负载下失灵。上海交大团队发布的 DLite 框架(arXiv:2610.23787)给出了一份诊断:问题不在草稿模型不够强,而在它背着的历史包袱。

两个问题,一个根因

投机解码的常规做法,是让一个轻量草稿模型先生成候选 token,再由目标模型批量验证。论文观察到,在 Agent 工作负载下,现有草稿模型的接受长度最多衰退 80%;与此同时,草稿模型自己维护一份历史 KV cache,也带来可观的系统开销。

作者把两个问题归结到同一个根源:不断膨胀的历史上下文。上下文越长,草稿模型要建模的依赖关系越复杂,预测质量随之下滑;缓存也随轮次持续增长,两头一起恶化。

DLite 的解法:不维护历史,直接复用

DLite 的思路是彻底绕开历史上下文:直接复用目标模型的上下文隐状态,在局部做投机预测,不再显式维护草稿侧的历史信息,把一个越滚越复杂的序列建模问题降维成局部预测问题。块内的因果依赖交给一个轻量序列头,以低开销恢复;训练侧配套两阶段策略,对齐这个异构的无历史架构。

跑分:SWE-Bench 2.74 倍,压过 DSpark

按论文 Table 2/3(硬件 NVIDIA H800,目标模型 Qwen3-4B/Qwen3-8B,投机块大小 K=7):

  • Agent 负载:端到端加速 2.07–2.74 倍;SWE-Bench 上 Qwen3-8B 达 2.74 倍,对比 DSpark 的 1.60 倍,高出约 71%
  • 长上下文(LongBench v2):多文档问答、长程上下文学习、代码库理解、长对话历史四类场景 2.18–3.96 倍
  • 通用负载:数学/代码/聊天基准平均接受长度 3.64–6.48 token
  • 演示中 46,704 token 的长输入也能保持加速

值得点出的是,8 月 Liquid AI 的 LFM2.5-DSpark 曾以 300M 草稿模型把端侧投机解码推到 2.87 倍;两个月后,上交大在 Agent 场景把这条 SOTA 线又抬了一截——这条细分赛道的迭代速度可见一斑。

开源与限制

框架以 MIT 协议开源,GitHub 提供 Python API、CLI 和吞吐基准,配套训练评测框架 LiteSpec 还打包了 DFlash、DSpark 等对比方法;Qwen3-4B/8B/14B 与 Qwen3.5-4B 四档草稿 checkpoint 权重均已放出。

但 README 的路线图同样诚实:SGLang、vLLM 集成还在待办清单上,更大目标模型的支持也未落地。想在生产 serving 栈里直接吃到这 2.74 倍,还得等工程化跟进——这是评估现在能不能用的关键边界。

回到更根本的问题:当 Agent 把上下文滚到几万 token,任何为单轮对话设计的加速方案都得重新答卷。DLite 的答案是干脆把历史包袱扔掉——草稿模型不再自己记历史,而是搭目标模型的便车。这个方向值得所有做推理优化的人盯住。

参考:arXiv:2610.23787(https://arxiv.org/abs/2610.23787);代码 github.com/SJTU-DAI-Sys/DLite