文章目录Domino一、研究背景与现存核心痛点1. 投机解码基础原理2. 两大主流草稿路线的固有权衡论文核心矛盾二、核心创新Domino解耦式因果校正框架核心思路1. 架构两大模块1并行草稿主干Parallel Draft Backbone2Domino轻量因果校正头核心创新2. 配套专属训练方案解决训练两大失效问题1Teacher-Forced 教师强制因果编码2Base-Anchored 渐进式课程损失3. 工程运行时优化三、实验设置与基线对比1. 实验基础配置2. 核心实验结果1低并发单请求Transformers贪心解码T02高并发线上服务SGLang工业吞吐场景3消融实验验证有效性四、相关工作梳理五、结论、局限与开源资源1. 结论2. 研究局限https://arxiv.org/pdf/2605.29707Domino: Decoupling Causal Modeling from Autoregressive Drafting in Speculative Decodinghttps://github.com/jianuo-huang/Domino模型https://huggingface.co/collections/Huang2020/dominoDomino论文Domino: Decoupling Causal Modeling from Autoregressive Drafting in Speculative Decoding作者团队上海交大EPIC实验室、华科、电子科大、复旦、华为2026年arXiv发布面向Qwen3系列模型提出全新投机解码框架解决现有投机解码草稿质量与生成开销无法兼顾的核心矛盾兼顾并行草稿的低延迟与自回归草稿的高接受长度。一、研究背景与现存核心痛点1. 投机解码基础原理投机解码通过草稿模型预生成多候选token 主模型一次性并行校验减少昂贵主模型前向次数提升推理吞吐。加速效果由两个核心指标决定接受长度τ单次校验能连续认可的草稿token数量数值越高加速越强草稿开销T_draft生成草稿序列的计算耗时开销越大抵消加速收益。2. 两大主流草稿路线的固有权衡论文核心矛盾自回归草稿代表EAGLE-3优势逐token生成草稿天然建模块内时序因果依赖草稿分布贴合主模型接受长度高缺陷生成γ个token需要γ次串行前向全词表LM头投影开销随草稿长度线性上涨大幅稀释加速收益。并行块草稿代表DFlash优势单次前向生成完整草稿块无串行重复计算草稿开销极低缺陷并行生成丢失块内时序因果草稿质量下降接受长度显著降低上限受限。现有方案无法同时做到「低草稿开销」「强因果建模、高接受长度」这是本文要解决的核心问题。二、核心创新Domino解耦式因果校正框架核心思路将因果依赖建模与昂贵自回归草稿执行彻底解耦主干复用DFlash并行块草稿一次性产出整块草稿基础分布保留极低并行计算开销新增轻量Domino头仅用极小参数量、极低延迟给并行草稿补充时序因果信息提升草稿匹配度与接受长度整体仅增加56M参数相对原草稿5.3%总草稿校验延迟仅上涨2.8%几乎无额外成本。1. 架构两大模块1并行草稿主干Parallel Draft Backbone基于DFlash块扩散架构输入主模型上下文特征 掩码占位草稿块[x_t, [MASK], ..., [MASK]]输出单次前向得到整块所有位置隐藏态冻结主模型LM头计算基础logits优势全程无串行循环整块草稿仅一次网络前向极致压低草稿计算成本。2Domino轻量因果校正头核心创新由因果编码器GRU低秩校正头组成在logit空间做残差修正避免重复昂贵LM头GRU因果编码器逐位置汇总块内前面已采样token嵌入生成时序状态S_{i-1}给后续位置提供前置token因果信息GRU隐藏维度仅1024极轻量低秩校正分支拼接基础隐藏态与因果状态先映射到256维低秩瓶颈空间再输出校正logits ΔL_i最终草稿分布L i L i b a s e Δ L i L_i L_i^{base} ΔL_iLiLibaseΔLi仅在logit层做修正无需重新执行完整LM头开销极低。2. 配套专属训练方案解决训练两大失效问题1Teacher-Forced 教师强制因果编码不用EAGLE系列的自生成前缀训练TTT训练时给GRU输入真实标准token序列规避自生成错误前缀带来的噪声训练信号贴合投机解码校验逻辑只有前面草稿全部正确时当前位置校正才有意义聚焦有效样本优化。2Base-Anchored 渐进式课程损失联合监督基础并行logits与最终校正logits损失函数L ( 1 − λ t ) L f i n a l λ t L b a s e L (1-\lambda_t)L_{final} \lambda_t L_{base}L(1−λt)LfinalλtLbaseλ_t从1线性退火到0训练初期强制主干并行网络学好基础分布防止校正分支“走捷径”导致主干失效训练后期逐步侧重带因果校正的最终输出平衡并行主干与因果头效果每个位置损失带指数衰减权重优先优化块前端token前端校验决定整块是否被接受。3. 工程运行时优化使用Triton融合内核CUDA Graph封装Domino头串行校正循环大幅减少Python内核调度开销Domino头延迟从2.64ms降至1.20ms落地生产友好。三、实验设置与基线对比1. 实验基础配置目标模型Qwen3-4B、Qwen3-8B评测数据集数学GSM8K、MATH、AIME25、代码HumanEval、MBPP、LiveCodeBench、对话MT-Bench、Alpaca硬件A100-SXM4-80GB推理后端Transformers低并发、SGLang高并发线上服务统一草稿块大小16对比基线原生自回归、EAGLE-3、DART、DFlash、FR-Spec。2. 核心实验结果1低并发单请求Transformers贪心解码T0Qwen3-8B基准自回归为1倍速EAGLE-3平均加速仅1.97×GSM8K最高2.21×接受长度高但串行开销拖累吞吐DFlash平均4.66×GSM8K 5.21×并行开销低但接受长度不足Domino平均5.49×GSM8K最高7.92×接受长度从DFlash的6.59提升至10.03实现加速大幅跃升。采样解码T1下Domino同样全面领先平均加速4.46×高于DFlash 3.96×、EAGLE-3 1.95×。2高并发线上服务SGLang工业吞吐场景以Qwen3-8B、GSM8K为例基线自回归并发32时TPS1713EAGLE-3并发越高加速衰减严重32并发仅0.8×DFlash 32并发1.6×Domino 32并发2.1×全并发档位TPS全面超越所有基线高并发场景收益稳定。3消融实验验证有效性Domino头消融关闭因果校正头平均加速2.84×开启后升至3.31×平均接受长度从3.49→4.19证明轻量因果头是核心增益来源训练策略消融仅TTT训练效果最差教师强制TF提升接受长度TF渐进课程损失效果最优避免主干网络失效统一训练数据对照所有基线使用完全相同训练集排除数据差异干扰确认增益来自架构设计。四、相关工作梳理论文系统划分三类投机解码草稿方案清晰定位Domino创新点自回归草稿EAGLE系列强因果、高开销纯并行草稿DFlash、DART、SpecDiffusion低开销、弱时序依赖轻量化辅助校正Medusa、Hydra多头并行但未解决块内长时序依赖Domino首次做到并行主干轻量时序校正融合两类方案优势无二者短板。五、结论、局限与开源资源1. 结论Domino通过解耦因果建模与自回归草稿执行仅极小参数与延迟增量同时拥有并行草稿的低计算开销与自回归草稿的高接受长度在Qwen3 4B/8B数学、代码、对话任务上端到端加速、服务吞吐全面超越EAGLE-3、DFlash、DART等主流SOTA投机解码。2. 研究局限当前实现主要适配SGLangvLLM等主流推理框架兼容性未完整验证不同GPU硬件带宽、算力差异会改变实际加速倍率需硬件专属内核调优仅聚焦推理加速未优化草稿模块训练成本。usagefrom transformersimportAutoModel, AutoModelForCausalLM, AutoTokenizer draft_modelAutoModel.from_pretrained(Huang2020/Qwen3-8B-Domino-b16,trust_remote_codeTrue,dtypeauto,device_mapcuda:0,).eval()target_modelAutoModelForCausalLM.from_pretrained(Qwen/Qwen3-8B,dtypeauto,device_mapcuda:0,).eval()tokenizerAutoTokenizer.from_pretrained(Qwen/Qwen3-8B)promptHow many positive whole-number divisors does 196 have?messages[{role:user,content:prompt}]# The Domino draft model is trained for Qwen3 with thinking mode disabled.texttokenizer.apply_chat_template(messages,tokenizeFalse,add_generation_promptTrue,enable_thinkingFalse,)model_inputstokenizer([text],return_tensorspt).to(draft_model.device)output_idsdraft_model.spec_generate(input_idsmodel_inputs[input_ids],targettarget_model,max_new_tokens2048,temperature0.0,stop_token_ids[tokenizer.eos_token_id],)generated_idsoutput_ids[:, model_inputs[input_ids].shape[1]:]print(tokenizer.decode(generated_ids[0],skip_special_tokensTrue))
)
