完全开源的语言模型学习记录--推理加速Domino

https://arxiv.org/pdf/2605.29707
Domino: Decoupling Causal Modeling from Autoregressive Drafting in Speculative Decoding
https://github.com/jianuo-huang/Domino
模型：https://huggingface.co/collections/Huang2020/domino

Domino

论文：Domino: Decoupling Causal Modeling from Autoregressive Drafting in Speculative Decoding
作者团队：上海交大EPIC实验室、华科、电子科大、复旦、华为，2026年arXiv发布；面向Qwen3系列模型提出全新投机解码框架，解决现有投机解码草稿质量与生成开销无法兼顾的核心矛盾，兼顾并行草稿的低延迟与自回归草稿的高接受长度。

一、研究背景与现存核心痛点

1. 投机解码基础原理

投机解码通过草稿模型预生成多候选token + 主模型一次性并行校验，减少昂贵主模型前向次数，提升推理吞吐。加速效果由两个核心指标决定：

1. 接受长度τ：单次校验能连续认可的草稿token数量，数值越高加速越强；
2. 草稿开销T_draft：生成草稿序列的计算耗时，开销越大抵消加速收益。

2. 两大主流草稿路线的固有权衡（论文核心矛盾）

1. 自回归草稿（代表：EAGLE-3）
   • 优势：逐token生成草稿，天然建模块内时序因果依赖，草稿分布贴合主模型，接受长度高；
   • 缺陷：生成γ个token需要γ次串行前向+全词表LM头投影，开销随草稿长度线性上涨，大幅稀释加速收益。
2. 并行块草稿（代表：DFlash）
   • 优势：单次前向生成完整草稿块，无串行重复计算，草稿开销极低；
   • 缺陷：并行生成丢失块内时序因果，草稿质量下降，接受长度显著降低，上限受限。

现有方案无法同时做到「低草稿开销」+「强因果建模、高接受长度」，这是本文要解决的核心问题。

二、核心创新：Domino解耦式因果校正框架

核心思路

将因果依赖建模与昂贵自回归草稿执行彻底解耦：

1. 主干复用DFlash并行块草稿，一次性产出整块草稿基础分布，保留极低并行计算开销；
2. 新增轻量Domino头，仅用极小参数量、极低延迟，给并行草稿补充时序因果信息，提升草稿匹配度与接受长度；
3. 整体仅增加56M参数（相对原草稿+5.3%），总草稿校验延迟仅上涨2.8%，几乎无额外成本。

1. 架构两大模块

（1）并行草稿主干（Parallel Draft Backbone）

基于DFlash块扩散架构：

• 输入：主模型上下文特征 + 掩码占位草稿块[x_t, [MASK], ..., [MASK]]；
• 输出：单次前向得到整块所有位置隐藏态，冻结主模型LM头计算基础logits；
• 优势：全程无串行循环，整块草稿仅一次网络前向，极致压低草稿计算成本。

（2）Domino轻量因果校正头（核心创新）

由因果编码器GRU+低秩校正头组成，在logit空间做残差修正，避免重复昂贵LM头：

1. GRU因果编码器：逐位置汇总块内前面已采样token嵌入，生成时序状态S_{i-1}，给后续位置提供前置token因果信息；GRU隐藏维度仅1024，极轻量；
2. 低秩校正分支：拼接基础隐藏态与因果状态，先映射到256维低秩瓶颈空间，再输出校正logits ΔL_i；
3. 最终草稿分布：L i = L i b a s e + Δ L i L_i = L_i^{base} + ΔL_iLi​=Libase​+ΔLi​，仅在logit层做修正，无需重新执行完整LM头，开销极低。

2. 配套专属训练方案（解决训练两大失效问题）

（1）Teacher-Forced 教师强制因果编码

不用EAGLE系列的自生成前缀训练（TTT），训练时给GRU输入真实标准token序列：

• 规避自生成错误前缀带来的噪声训练信号；
• 贴合投机解码校验逻辑：只有前面草稿全部正确时，当前位置校正才有意义，聚焦有效样本优化。

（2）Base-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​+λt​Lbase​

• λ_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，贪心解码T=0）

Qwen3-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，实现加速大幅跃升。

采样解码（T=1）下Domino同样全面领先，平均加速4.46×，高于DFlash 3.96×、EAGLE-3 1.95×。

（2）高并发线上服务（SGLang，工业吞吐场景）

以Qwen3-8B、GSM8K为例：

• 基线自回归并发32时TPS=1713；
• EAGLE-3并发越高加速衰减严重，32并发仅0.8×；
• DFlash 32并发1.6×；
• Domino 32并发2.1×，全并发档位TPS全面超越所有基线，高并发场景收益稳定。

（3）消融实验验证有效性

1. Domino头消融：关闭因果校正头平均加速2.84×，开启后升至3.31×，平均接受长度从3.49→4.19，证明轻量因果头是核心增益来源；
2. 训练策略消融：仅TTT训练效果最差；教师强制（TF）提升接受长度；TF+渐进课程损失效果最优，避免主干网络失效；
3. 统一训练数据对照：所有基线使用完全相同训练集，排除数据差异干扰，确认增益来自架构设计。

四、相关工作梳理

论文系统划分三类投机解码草稿方案，清晰定位Domino创新点：

1. 自回归草稿（EAGLE系列）：强因果、高开销；
2. 纯并行草稿（DFlash、DART、SpecDiffusion）：低开销、弱时序依赖；
3. 轻量化辅助校正（Medusa、Hydra）：多头并行但未解决块内长时序依赖；
   Domino首次做到并行主干+轻量时序校正，融合两类方案优势，无二者短板。

五、结论、局限与开源资源

1. 结论

Domino通过解耦因果建模与自回归草稿执行，仅极小参数与延迟增量，同时拥有并行草稿的低计算开销与自回归草稿的高接受长度；在Qwen3 4B/8B数学、代码、对话任务上，端到端加速、服务吞吐全面超越EAGLE-3、DFlash、DART等主流SOTA投机解码。

2. 研究局限

1. 当前实现主要适配SGLang，vLLM等主流推理框架兼容性未完整验证；
2. 不同GPU硬件带宽、算力差异会改变实际加速倍率，需硬件专属内核调优；
3. 仅聚焦推理加速，未优化草稿模块训练成本。

• usage

from transformersimportAutoModel, AutoModelForCausalLM, AutoTokenizer draft_model=AutoModel.from_pretrained("Huang2020/Qwen3-8B-Domino-b16",trust_remote_code=True,dtype="auto",device_map="cuda:0",).eval()target_model=AutoModelForCausalLM.from_pretrained("Qwen/Qwen3-8B",dtype="auto",device_map="cuda:0",).eval()tokenizer=AutoTokenizer.from_pretrained("Qwen/Qwen3-8B")prompt="How 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.text=tokenizer.apply_chat_template(messages,tokenize=False,add_generation_prompt=True,enable_thinking=False,)model_inputs=tokenizer([text],return_tensors="pt").to(draft_model.device)output_ids=draft_model.spec_generate(input_ids=model_inputs["input_ids"],target=target_model,max_new_tokens=2048,temperature=0.0,stop_token_ids=[tokenizer.eos_token_id],)generated_ids=output_ids[:, model_inputs["input_ids"].shape[1]:]print(tokenizer.decode(generated_ids[0],skip_special_tokens=True))