作者：钱宇阳，南京大学博士生

青稞社区为科研人员提供成果宣传支持，如有优秀研究成果分享推广，欢迎投稿联系：aiFreeCode

AdaFlash 让投机解码在线自我改进，同时减少大模型无效工作，大幅提升高并发下的推理速度

DeepSeek 的 DSpark 让“投机解码推理加速”成为行业热点，尤其是在高并发的工业生产场景中。几乎同期时间，南京大学与华为基础模型团队共同提出的 AdaFlash，从扩散草稿模型的高方差出发，给出了另一套在线适应方案。

投机解码（Speculative Decoding）提供了一条模型推理加速的实用路径：轻量级的草稿模型先提出一段草稿 Tokens，再由大尺寸的目标模型一次性验证，验证通过的前缀直接保留，从而提高大模型的推理速度。

近年来出现的扩散草稿模型 DFlash，又把 draft tokens 生成从多次自回归前向传播压缩到一次并行前向传播，进一步降低了草稿开销。

问题在于，并行生成带来了新的不确定性：同一个草稿模型，换一个任务领域，接受率可能大幅波动；同一个问题的不同阶段，草稿质量高低也不均匀。固定的草稿长度和固定的离线权重，很难适应工业生产部署中不断变化的请求。

南京大学与华为基础模型团队最新提出的 AdaFlash 正是为解决这一问题而设计：该方法使扩散草稿模型根据目标模型的反馈进行在线学习更新，并依据当前草稿序列的质量动态调整验证长度。

AdaFlash 在多种模型、任务和并发度下保持稳定加速：在 Qwen3-8B 上最高达到 5.32× 端到端加速；并且在高并发场景下，平均吞吐较此前 SOTA 最高提升 66%，并已适配国产昇腾计算平台。

📖 论文（arXiv）：https://arxiv.org/abs/2607.19223
💻 代码仓库：https://github.com/ZinYY/AdaFlash
🤗 Hugging Face 模型：https://huggingface.co/AdaFlash/Qwen3-8B-AdaFlash

论文发表于COLM 2026 Workshop on Efficient Reasoning，并入选Spotlight亮点论文。

投机解码的下一步：让大模型少做无效工作

标准自回归解码一次只生成一个 Token。对于长回答、复杂推理和多轮 Agent 任务，目标模型需要重复进行很多次昂贵的前向计算。

投机解码把过程拆成两步：

1、 草稿模型快速生成长度为 k 的草稿序列。

2、 目标模型并行检查这 k 个草稿，只保留从开头连续通过验证的部分，并在拒绝位置按目标模型分布修正。

只要草稿模型足够便宜、草稿序列的接受率足够高，系统就能在不改变目标模型输出分布的前提下获得加速。一次验证平均接受的 Token 数，通常记为接受长度 τ，是衡量草稿质量的关键指标。

扩散草稿模型采用并行解码机制和双向注意力，可以在一次前向传播中同时预测多个未来位置。以 DFlash 为代表的块扩散草稿模型，每轮可以一次生成 16 个草稿 Token，单个 Token 的草稿开销约是自回归草稿的 1/16。

但“生成得更快”并不自动等于“整体更快”。如果草稿中只有前几个 Token 能被接受，目标模型仍然会为整段草稿序列付出验证成本，省下来的草稿计算就会被无效验证抵消。

扩散草稿模型的高方差特性

扩散草稿模型的双向注意力和并行生成带来了高效的草稿生成效率，同时也让不同位置之间产生更强的全局依赖，从而导致了在以下两类情况下的接受长度的高方差：

换一个领域，接受率就可能换一个水平

在 Qwen3-8B 上，DFlash 的平均接受长度在不同任务之间差异明显：MathQA 为 7.09，ShareGPT 只有 3.40，约为 2.1 倍的跨度。作为对比，EAGLE-3 在相同任务上的接受长度大致落在 3.89 到 4.60 之间，跨度约为 1.2 倍。

这意味着，一个在数学题上表现不错的离线扩散草稿模型，换到代码或对话请求时接受率可能突然降低。对于数据分布持续变化的线上服务，固定权重很难覆盖所有领域。

同一段草稿序列，越靠后越容易浪费验证计算

扩散草稿在同一段草稿序列中的逐位置接受概率并不均匀：前部 Token 可能与目标模型高度一致，后部 Token 的接受概率却逐步下降。即使两个请求只有一个前缀 Token 不同，后续草稿的接受长度也可能明显分叉。

当系统固定使用 k=16 的验证长度时，目标模型仍会检查那些几乎不可能被接受的尾部 Token。并发请求越多，这类无效验证消耗的显存和算力越明显。

关键观察：把验证长度变成动态变量

几乎同期，AdaFlash 和 DeepSeek 的 DSpark 都注意到：当草稿生成已经足够便宜、多个请求需要共享目标模型的验证算力时，让所有请求固定验证同样长度，会把大量计算花在低置信度的草稿尾部。两项工作都把“验证多少 Token”从固定超参数改成了随请求状态变化的动态决策。

两者的切入点有所不同。DSpark 更偏向高并发服务中的置信度调度：它估计草稿各位置的条件接受概率，再结合硬件感知的调度策略，决定哪些位置值得继续验证。

AdaFlash 则把动态验证和草稿模型在线适应放在同一个闭环里：自适应长度头预测整段草稿的总体接受率，在线策略蒸馏持续修正扩散草稿模型，服务引擎再按每个请求的预测长度重新打包验证批次。

这也是两项同期工作的共同信号：投机解码的下一步，不只是把草稿生成得更快，还要让验证预算跟着草稿质量和系统负载一起变化。

AdaFlash：把线上反馈变成加速信号

AdaFlash 的核心思路可以概括为一个在线学习的闭环系统： 草稿模型先生成候选 Token，目标模型并行验证并返回每个位置的接受结果。

AdaFlash 一方面用这些线上反馈在线更新草稿模型，让它逐渐适应当前请求领域；另一方面根据候选质量预测下一轮应验证的长度，只把计算资源用在更可能被接受的前缀上。

更新后的草稿模型和验证长度会继续参与下一轮推理，形成“生成、验证、反馈、调整”的在线学习循环。

它包含两个互补组件：1）在线策略蒸馏（On-Policy Distillation，OPD）负责应对领域层面的变化，以及2）自适应长度头（Adaptive Length Head）负责应对草稿序列内部的位置差异。同时进行底层infra层面的优化适配。

在线策略蒸馏 OPD：让草稿模型跟着真实流量学习

每一轮推理中，目标模型都会给出草稿各位置上的分布和验证结果。这些信息本来只是用来决定哪些 Token 被接受，AdaFlash 进一步把它们作为训练信号，更新当前正在服务的草稿模型。

与离线蒸馏不同，OPD 使用当前模型自己生成的轨迹进行训练。训练样本来自当前部署域，因而能够直接修正模型在真实请求中犯下的错误，减轻训练分布和推理分布之间的偏差。

论文针对扩散草稿模型的分布特点设计了两处改动：

• • 反向 KL 与 Top-1 硬标签的混合损失。 双向注意力容易让草稿分布变得高熵，标准前向 KL 会要求模型覆盖大量低概率区域。反向 KL 更强调目标模型的高概率模式，再配合目标模型 Top-1 Token 的硬标签监督，既提高接受率，又提供稳定的梯度方向。
• • 逐词表项的散度裁剪。 反向 KL 是整个词表上各项贡献的求和，少数“草稿概率不低、目标概率极低”的词表项可能产生异常大的梯度。AdaFlash 在求和前对每个词表项单独裁剪，避免离群项主导更新。

自适应长度头：只验证值得验证的前缀

AdaFlash 在草稿模型旁边增加一个轻量级长度头。它读取草稿模型的中间特征，预测当前草稿序列的整体接受率，再把草稿长度从固定的 k=16 调整为期望接受长度。

验证结束后，系统会及时收到真实的接受率反馈，因此可以在线更新长度头，而不需要额外标注或额外的目标模型调用。

这一步解决的是“草稿质量不均匀”带来的浪费：高质量草稿可以保留更长的验证前缀，低质量草稿则及时缩短验证长度，把目标模型的计算预算留给更可能被接受的 Token。

异步训练和自适应调度：让在线更新不阻塞服务

要将在线学习要真正落地到大模型推理优化中，还需推理引擎配合。AdaFlash 基于 SGLang 实现了两项基础设施改动：

• • 训练与推理解耦：推理服务器把线上轨迹写入共享缓冲区，训练服务器在后台计算目标模型监督信号并更新草稿模型和长度头。新权重通过轻量级热加载替换，目标模型本身无需改动，训练也不会阻塞 Token 生成。
• • 可变长度请求打包： 传统验证批次假设所有请求共享同一个验证长度。AdaFlash 允许每个请求使用不同的验证长度，再将它们打包成紧凑的验证批次，并用指数移动平均估计下一轮可接纳的请求数，在提高 GPU 利用率的同时避免显存超预算。

实验结果：从单请求到 128 并发，AdaFlash 都能保持优势

论文在八个基准上进行评估，覆盖数学推理、代码生成、对话、混合领域和长序列推理任务：MathQA、GSM8K、OpenCodeInstruct、CodeAlpaca、ShareGPT、Blend、MATH-500、AIME25。

目标模型包括 Qwen3-8B、Qwen3-Coder-30B-A3B 和 Qwen3.5-9B，测试并发度为 1、32、64、128。

Qwen3-8B：单请求最高 5.32 倍，高并发仍高于标准解码

在六个基准数据集上的平均结果上：

在 MathQA 上，AdaFlash 的单请求加速达到 5.32×，平均接受长度从 DFlash 的 7.09 提升到 9.83。高并发时差距更加明显：并发度 128 下，AdaFlash 仍有 1.15× 加速，而 DFlash 和 OSD 分别降到 0.76× 和 0.83×，低于标准自回归解码基线。

论文还记录了在线适应过程中的吞吐变化：随着更新轮次增加，系统吞吐持续上升，并在整个过程保持在 OSD 基线之上。

从接受率分布看，AdaFlash 在 GSM8K 和 CodeAlpaca 之间的差距明显收窄；从位置维度看，草稿序列后部的接受概率提升最明显。这两点分别对应 OPD 对领域方差的缓解，以及长度头和在线更新对 Token 级方差的处理。

在 MoE 模型 Qwen3-Coder-30B-A3B 上，AdaFlash 在并发度 128 时仍取得 1.69× 平均加速，对比 DFlash 的 1.02×、OSD 的 1.14× 和 EAGLE-3 的 0.83×。

长序列推理：32K 上下文下仍然有效

在开启思考模式、最大输出长度设为 32,768 Token 的长序列任务上，AdaFlash 在 Qwen3-8B 上同样保持优势：

• • MATH-500：并发度 1 时 3.67×，并发度 32 时 3.52×。
• • AIME25：并发度 1 时 3.18×，并发度 32 时 2.77×。

这说明在线适应和自适应验证长度并不只适用于短回答，在长链路推理中也能持续减少目标模型的无效工作。

昇腾 NPU：跨硬件后仍能加速

论文还在华为昇腾 910C NPU 上使用 SGLang-NPU 进行跨领域测试。这里采用跨域固定权重设置，尚未进行在线更新。Qwen3-8B 上，跨域 AdaFlash 在并发度 1 时达到 3.69× 平均加速，并发度 128 时仍有 1.50×；对应的 DFlash 结果分别为 3.13× 和 1.11×。

从“固定草稿”到“会适应的推理系统”

AdaFlash 的价值不只是把某个草稿模型再训练一遍，而是把投机解码从静态组件变成了一个在线学习闭环：

• • 请求分布变化时，草稿模型通过目标模型反馈及时调整。
• • 草稿序列的后部质量下降时，长度头缩短验证预算。
• • 流量并发升高时，调度器按实际验证长度重新组织批次。

对 Agent 来说，这种持续的适应能力尤其重要。一个完整任务往往包含规划、检索、工具调用、代码执行和结果检查，模型会被连续调用很多次。只在离线基准上取得高接受率还不够，系统还要面对任务领域变化、请求突发和显存预算波动。AdaFlash 的设计目标，正是让加速策略随这些变化一起调整。

结语

扩散草稿模型把并行生成的成本降了下来，却也把“什么时候该相信草稿、验证多少 Token”变成了部署问题。AdaFlash 给出的答案是：让模型从每次验证中学习，并让验证长度随草稿质量和系统负载变化。

当大模型开始被 Agent 高频调用，推理加速的关键不再只是一次前向传播能生成多少 Token，还包括系统能否在真实流量中持续识别并跳过无效计算。AdaFlash 把这条思路落实为可在线更新的算法和服务引擎实现，也为扩散投机解码走向更复杂的生产环境提供了一个新的起点。

开源进展与作者团队

AdaFlash 代码、模型权重以及 SGLang 集成 PR 已公开，读者可以按仓库说明复现实验，或在自己的服务引擎中尝试。

论文题目为 AdaFlash: Adaptive Speculative Decoding via On-Policy Distilled Diffusion Drafters。

作者为 Yu-Yang Qian、Hao-Cong Wu、Chen Chen、Jiacheng Sun、Zhenhua Dong、Peng Zhao（通讯作者）和 Zhi-Hua Zhou，来自南京大学人工智能学院和华为基础模型部。

其中共同第一作者包括南京大学人工智能学院博士生钱宇阳（曾在UCSD Hao Zhang组进行访学，主要研究 LLM efficiency） ，以及南京大学人工智能学院本科生巫昊聪（主要研究投机解码及AI Infra）。

通讯作者为南京大学赵鹏副教授，从事在线学习与大模型推理优化研究。同时本工作的作者还包括中国科学院院士、南京大学周志华教授，是机器学习领域的国际权威学者、著名教材《机器学习》（网友昵称“西瓜书”）作者。

加入青稞AI技术交流群