大模型为什么总像「挤牙膏」？从推测解码到 DSpark，一次讲透 LLM 推理提速的底层逻辑与工程取舍

本文由 莫潇羽@无忆研习社（www.wuyi.wiki）撰写，转载请注明出处。

快速摘要

这次 DeepSeek 联合北大团队放出的 DSpark，本质不是一个新模型，而是给已有的 DeepSeek-V4 权重挂上去的一套"推理加速模块"，同时配套开源了训练与评测代码库 DeepSpec（MIT 协议）。它干的事只有一件：在不改变模型输出、不损失回答质量的前提下，让大模型把字"吐"得更快。核心是两招——半自回归生成（并行打草稿的同时补上一个很轻的顺序模块，缓解候选越往后越不靠谱的"后缀衰减"），加上按置信度和硬件负载动态决定"这次验证几个 token"的智能调度。公开数据里，在系统总吞吐不变的情况下，单用户生成速度在 Flash 版本上提升约 60% 到 85%，Pro 版本约 57% 到 78%，而且输出无损。

我自己把这篇论文和配套仓库翻了一遍，最大的感受是：大模型这场仗，已经从"谁的模型更聪明"，悄悄打到了"谁能把同样聪明的模型，更快、更便宜、更稳地送到用户面前"。这篇文章不堆术语，我尽量用大白话，把推测解码是什么、老办法卡在哪、DSpark 这两招到底巧在哪、实测数字该怎么读，一层层拆给你看。想看完整拆解，往下翻。

一、先聊个体感问题：为什么 AI 回复总在"一个字一个字往外蹦"

你大概率有过这种体验：问大模型一个稍微复杂点的问题，它的回答像老式打字机，一个字一个字慢慢"蹦"出来，遇到长回答还得盯着屏幕等上好一会儿，急性子的人甚至会忍不住反复刷新。很多人吐槽这是"挤牙膏",其实背后不是模型故意藏着掖着，而是它生成文字的底层方式决定的。

主流的大语言模型，生成文本走的是一种叫自回归（autoregressive）的路子。说人话就是：模型一次只能往外吐一个 token，吐完这一个，得把前面已经写出来的内容全部当成"已知条件"重新过一遍，再算下一个该吐什么。这里插一句白话解释——所谓 token，你可以粗略理解成"模型眼里的一个最小语言单位",有时是一个汉字，有时是一个词，有时是一个词的片段，模型不是按"字"思考的，是按 token 思考的。

问题就出在"一个接一个"这五个字上。模型每多写一个 token，就要完整地做一次前向计算（可以理解成让整个神经网络从头到尾算一遍）。回答越长，要算的次数就越多，延迟一点点累加，等到几百上千个 token 的长回答写完，时间自然就拖上去了。我自己写长文初稿、让模型帮忙改一大段代码的时候，这种"等待感"是最明显的——不是它不会，是它"说话"的节奏被这套机制锁死了。

更要命的是高交互的场景。实时聊天、需要来回好几轮的智能体（Agent，可以理解成会自己调工具、分步骤干活的 AI 助手）工作流、代码补全助手，这几类应用对"出字速度"特别敏感。用户盯着光标等，多一秒都嫌长；而在服务方那一侧，生成速度还直接牵动着 GPU 这种贵价硬件的利用率——同样一块卡，吐字越慢，单位时间内能服务的人就越少，成本就越高。

这里面有个容易被忽略的"放大效应"。普通的一问一答，慢一点你顶多多等几秒；可一旦进了多轮智能体的活儿——它要先想一步、调个工具、读段返回、再想下一步——每一步都卡在出字速度上，几十步串起来，慢就不是线性叠加，而是肉眼可见地拖成一条长尾。我自己搭过几个自动跑流程的小助手，最折磨人的从来不是某一步算错，而是它"想得对但说得慢"，整条链路被一点点磨蹭掉。对要赶时间的人来说，这种慢比偶尔出错还劝退。

所以，"让大模型回答更快"从来不是个锦上添花的小优化，它一头连着用户体验，一头连着服务成本。推测解码（speculative decoding），就是专门冲着这个痛点来的一类技术。

二、推测解码到底在解决什么：让小模型打草稿，大模型来审稿

推测解码的思路，用一句话概括特别好懂：让一个又小又快的模型先把草稿写出来，再让真正负责质量的大模型快速审稿。

这套方法不是这两年才冒出来的新东西。行业内公认的源头，是 2023 年前后的两篇工作——一篇提出了通过"草稿 + 验证"两个模型协作来加速 Transformer 推理的思路，另一篇几乎同期独立给出了非常接近的"投机采样"方案。从那以后，推测解码就成了大模型推理提速的主流方向之一，常见的加速幅度在 2 到 5 倍这个区间。

具体怎么运作？这里有两个角色要先认清：

• 草稿模型（draft model）：又小又轻，跑得快，负责"先猜"。它一口气快速生成一串候选 token。
• 目标模型（target model）：就是那个真正决定回答质量的大模型，负责"把关"。它把草稿模型猜出来的那一串候选，一次性并行验证。

关键的巧妙之处，就在"一次性并行验证"这六个字。验证这件事，是可以把好几个候选 token 摆在一起、一次前向计算同时检查的。检查的规则也很干脆：从头往后看，连续对的部分（最长的正确前缀）全部接受；一旦碰到第一个不对的位置，它后面的候选 token 不管对错全部作废，目标模型当场补一个修正 token（也就是常说的 bonus token）顶上。

草稿模型猜的一串：  T1  T2  T3  T4  T5
目标模型验证结果：  ✓   ✓   ✓   ✗   —
最终采纳：          T1  T2  T3  +  目标模型补的修正 token
（T4 之后全部丢弃，下一轮重新开始）

这么一来，原本大模型"一次前向只能确认一个 token"，现在变成"一次前向有机会确认好几个 token"。省下来的，就是大模型那些本来要一步步重复做的前向计算。

它为什么真能提速？因为现实里，一段文字中相当一部分 token 其实很"好猜"——前文已经把话头铺得很顺，接下来该说什么几乎是顺理成章的，连一个小得多的草稿模型都能猜对。这些容易的部分被一次性接受，大模型就能"跳着走"；只有遇到真正难猜、草稿和大模型意见不合的地方，才退回到老老实实一个一个来的速度。

还有一个特别重要、也特别容易被忽略的点：推测解码是无损的。 它那套接受规则（学名叫拒绝采样）在数学上保证了，最终输出的概率分布，和大模型自己一个一个老实生成时一模一样。也就是说，它只让模型变快，不让模型变"笨",回答质量不打折。这一点是它能被工业界大规模采用的前提。

很多人第一次听会犯嘀咕：天下哪有这种又快又不掉质量的好事？关键在于它没动"判分的人"。最终拍板每个 token 的，始终是那个大模型；草稿模型只是个"提速器",它猜得好就帮你省一大截算力，猜得不好也不过是退回原速、多算一次验证而已，绝不会让大模型违心地接受一个它本来不会选的 token。所以它的下限是"和原来一样慢"，上限是"快好几倍"，质量这条线从头到尾焊死。换句话说，它赌的是"猜对的概率"，而不是"质量的底线"——这也是为什么它敢叫无损，而不是用质量换速度的折中。

我自己最爱用的一个类比是审批：草稿模型像个手脚麻利的助理，先把方案一口气拟好；目标模型像个经验老到的负责人，方案拿过来一眼扫到底，前面对的部分大笔一挥直接签字通过，扫到第一处不对劲的地方就停下，把那里改对，后面重写。助理写得越贴合负责人的思路，被一次性放行的篇幅就越长，整件事就越快。

为了让你对"省在哪"更有数，我们拿一个具体的小例子走一遍。假设上下文已经是"今天我打算去图书馆"，草稿模型一口气猜出后面五个 token：「看」「会」「书」「然」「后」。目标模型一次前向并行验证，发现前四个都对，第五个"后"它本来想接的是别的，于是在第五个位置喊停：前四个「看会书然」全部接受，第五个作废，目标模型当场补上它认可的那个 token。这一轮，大模型只做了一次前向，却一口气敲定了五个 token（四个草稿 + 一个修正）。换成老办法，这五个 token 得让大模型老老实实跑五次前向。省下来的四次，就是提速的来源。

反过来，如果草稿模型第二个 token 就猜歪了，那这一轮就只能接受第一个，后面全作废、重来——这时候推测解码不但没占到便宜，还因为多做了一次验证，略微比老办法还慢一点点。所以你看，整套机制的胜负手，全压在"草稿能被一次性接受多长"这件事上。这也是后面 DSpark 拼命要把草稿打得又准又长的根本动机。

整个流程，画成图大概是这样：

flowchart LR
    A[已有上下文] --> B[草稿模型<br/>快速生成一串候选 token]
    B --> C[目标模型<br/>一次前向并行验证]
    C --> D{从头检查<br/>到哪个位置出错?}
    D -->|全部通过| E[整串接受<br/>+ 补 1 个 token]
    D -->|中途出错| F[接受出错前的部分<br/>+ 目标模型补修正 token]
    E --> A
    F --> A

把这套机制吃透，你就能理解 DeepSeek 这次为什么不去练一个更大的新模型，而是在"草稿怎么打、审稿怎么审"这两件事上做文章了——莫潇羽@无忆研习社 看下来，DSpark 的全部聪明劲，恰恰都长在这两个环节的缝里。下面接着拆。

三、一个公式看清提速空间：能拉的杠杆只有三根

把推测解码讲透之后，有个公式能帮你一眼看清"提速到底从哪来"。论文里给出的单 token 平均延迟，可以写成这样一个很朴素的式子：

单 token 平均延迟 L = ( T_draft + T_verify ) / τ

T_draft  ：这一轮打草稿花的时间
T_verify ：这一轮验证花的时间
τ（tau） ：这一轮里平均被目标模型接受了多少个 token

这个公式别看简单，它几乎把所有提速思路都框死了。分子是"一轮要花的总时间"，分母是"一轮换来的有效产出"。想让单 token 的平均延迟变小，能动的地方就三处，我习惯叫它"三根杠杆"：

这三根杠杆之间，其实是互相牵制的，不能各拉各的。你想让草稿更准（拉高 τ），最直接的办法是把草稿模型做得更大更深，可那样打草稿就更慢（T_draft 又涨上去了）；你想验证时一口气多验几个省事，可万一这些候选大多被拒，验证时间就白花（T_verify 被浪费）。所以真正难的，从来不是单独把某一根杠杆拉到极限，而是在三者之间找到一个动态的平衡点——尤其是这个平衡点还会随着系统忙闲不停地漂移。看懂了这层相互牵制，你才能体会到后面 DSpark 那套"该快的地方快、该省的地方省"的调度，到底巧在哪儿。

老一辈的推测解码方案，往往只死磕其中一两根。要么拼命让草稿模型更准（把 τ 顶上去），代价是草稿自己变慢；要么图省事一口气验证一长串，结果一堆注定被拒的候选白白吃掉算力。DSpark 真正不一样的地方，是三根杠杆一起拉：用半自回归把草稿打得又快又准，把前两根杠杆同时往上抬；再用置信度调度把验证做得精打细算，专攻第三根。

用一段示意性的伪代码，把一轮推测解码的骨架摆出来，你会对"时间花在哪、产出有多少"更有体感：

# 仅为示意，帮助理解一轮推测解码的结构，非真实实现
def one_round(context):
    # 1) 打草稿：又快又轻地猜一串候选（对应 T_draft）
    candidates = draft_model.propose(context, block_size=5)

    # 2) 验证：目标模型一次前向并行检查（对应 T_verify）
    verdicts = target_model.verify(context, candidates)

    # 3) 接受最长正确前缀，遇到第一个错就截断
    accepted = take_longest_correct_prefix(candidates, verdicts)
    bonus = target_model.sample_one(context + accepted)  # 补一个修正 token

    # 这一轮的"有效产出"就是 len(accepted) + 1，约等于 τ
    return accepted + [bonus]

记住这三根杠杆，你再去看后面那些花里胡哨的设计，就会发现它们全都是在围着这三处使劲。

四、老办法卡在哪：自回归草稿与并行草稿的两难

推测解码这套框架虽好，但"草稿到底怎么打"这件事，过去一直在两种思路之间拉扯，各有各的硬伤。把这两种思路讲清楚，才能看懂 DSpark 那一招"半自回归"妙在哪。

自回归草稿：连贯但慢

第一种叫自回归草稿模型，代表是 Eagle3 这一类。它打草稿的方式和正常语言模型一样，也是一个 token 接一个 token 地往外写。好处很直接：因为是顺着前文一步步生成的，候选 token 之间前后关系自然，逻辑连得上，被大模型接受的概率高，而且越往后越不容易"翻车"。

但它的毛病也长在这里。既然要一步步来，草稿模型自己写草稿的时候就快不起来——候选要的越多，草稿阶段就越慢。为了不让打草稿这一步拖后腿，工程上通常不敢把草稿模型做得太深、太复杂，这又反过来压低了它对第一个 token 的预测能力。一句话：连贯性是它的长板，速度和首字预测力是它的短板。

并行草稿：快但"串味"

第二种叫并行草稿模型，代表是 DFlash 这一类。它能一次性把一整块候选 token 全吐出来，速度飞快，也更适合一口气生成较长的候选块。但快是有代价的——一整块 token 是"同时"蹦出来的，彼此之间缺少真正的先后依赖，谁也没参考谁。

这就埋下了一个隐患。我举个自己常用的通用例子：模型写到"今天天气"，后面接"很不错"或者"挺好的"都通顺。可并行草稿因为不是真按顺序生成的，很容易把两条路各取一半，拼出"很挺好"这种前后串味、读着别扭的组合。这种"多条合理路径被并行硬拼到一起"的现象，业内有个形象的说法叫多模态碰撞。

碰撞的直接后果是：并行草稿开头那一两个 token 往往还挺准，但越往块的后半段走，被大模型接受的概率掉得越快。论文把这种"越靠后越不靠谱"的衰减，称为后缀衰减（suffix decay）。你可以理解成：草稿模型开了个好头，但越往下越像在硬编，大模型自然就越不买账。

为什么"第一个 token 准不准"和"后段稳不稳"这两件事都要紧？我换个生活化的说法。打草稿就像接龙写一句话，第一个词定调，后面跟着走。并行草稿的强项是第一个词往往拍得很准（因为它能用更深的网络专门把首位算扎实），可一旦后面几个词各写各的、互不照应，整句就容易散架，大模型一看后半截不通顺，就把那截全退了。自回归草稿正相反，它一个词接一个词地写，整句连得顺，可惜为了不拖慢速度又不敢把网络做深，第一个词反而没那么稳。一个赢在开头、一个赢在连贯，谁也没能两头都占。DSpark 想做的，恰恰就是把这两家的长板拼到一块儿去。

把这两类老方案摆在一起对比，差别一目了然：

一个慢而稳，一个快而飘。DSpark 想做的事，说白了就是"既要又要"——既要并行草稿的速度，又要补上自回归草稿那份前后连贯。它是怎么把这对矛盾捏到一块儿的，下一章细讲。

五、DSpark 第一招：半自回归生成，让草稿又快又连贯

DSpark 解决"快与连贯"这对矛盾的办法，叫半自回归生成（semi-autoregressive generation）。名字听着玄，拆开看其实很朴素：一半走并行的快路子，一半补一点点顺序的连贯性。

为什么叫"半"自回归？因为纯自回归是一个 token 接一个 token、严格按顺序生成，慢但连贯；纯并行是所有 token 一把抓、互不照应，快但容易散。DSpark 取了个中间态——主体仍然并行（所以快），但在出口处让每个 token 临门一脚时回头看一眼前面的结果（所以又有那么点顺序的味道）。它不像纯自回归那样把"看前文"贯穿到底，只在最关键的相邻衔接处补一手，既没丢掉并行的速度，又把最容易出岔子的那一环管住了。这个"半"字，拿捏的正是速度和连贯之间那个微妙的平衡点。

它的做法是这样的——主干仍然沿用并行草稿那一套（DSpark 论文里就是拿 DFlash 当并行底座），让绝大部分计算还是一次性并行完成，速度的优势先稳稳保住。然后在输出那一端，挂上一个很轻量的顺序模块，让后面要采样的每一个 token，都能回头参考一下前面已经定下来的 token，再决定自己该是什么。

打个比方：原来并行草稿是一桌人同时下笔、互不通气；现在 DSpark 让大家还是基本同时动笔（保速度），但在落笔前给每个人加了一道"瞄一眼左边邻座写了啥"的小动作（补连贯）。这一瞄，串味的概率就大大降下来了。

默认的 Markov head：便宜又够用

这个轻量顺序模块，论文默认用的是 Markov head。它的特点是只盯着紧挨着的前一个 token，专门建模"上一个 token 到当前 token"的转移关系。听起来好像看得很短，但对压制串味已经够用了——回到上一章那个"今天天气"的例子，只要第一个位置定下了"很"，这个 Markov head 就能顺手把"不错""挺好"往上推、把容易拼错的组合往下压。

为了让它足够便宜，论文还用了低秩分解（一种把大矩阵拆成两个小矩阵、大幅省参数省算力的常见手法，这里的秩取 256），哪怕词表很大，这个顺序头的开销也压得很低，部署起来不费劲。

论文也试过更"重"的 RNN head，它能记住整块草稿里更长的历史，理论上更全面。但实测下来收益有限，复杂度却高了不少，性价比不划算。所以最后拍板：Markov head 当默认方案。这一步取舍特别能体现工程思维——不是越复杂越好，而是用最小的代价把关键问题解决掉。

训练时的小心思：冻结大模型，只练草稿

训练这个草稿模块的时候，DSpark 有个很省事的设计：目标模型（那个大模型）整个冻住不动，连它的词嵌入（embedding）和输出头都直接拿来复用，只训练新加的草稿部分。这样既省训练成本，也保证了不会把原本的大模型练"歪"。

训练里最关键的一项损失，是总变差距离（total-variation loss）。这里不用纠结数学细节，记住一个直觉就行：最小化这个距离，等价于直接把"草稿被大模型接受的概率"往最大里推。换句话说，DSpark 在训练阶段优化的目标，和它在线上真正想要的效果（草稿尽量被一次性放行）是严丝合缝对齐的。

它到底强在哪个位置

把这一招的效果落到"逐个位置"上看，特别清楚：

• 第一个 token：继承了并行草稿的强预测力，开局又快又准。
• 后面的 token：靠那个轻量顺序头，把后缀衰减摁住，越往深处接受率掉得越慢。

flowchart TD
    A[当前上下文] --> B[并行主干<br/>一次性给每个位置出基础候选]
    B --> C[轻量顺序头 Markov head<br/>逐位置参考前一个 token 做微调]
    C --> D[最终草稿块<br/>开头准 + 深处稳]
    D --> E[送目标模型验证]

一个有意思的对照实验是：2 层的 DSpark，效果已经超过 5 层的 DFlash。这说明，与其单纯靠堆并行层数硬提性能，不如补上这么一个轻量级的顺序建模来得划算。莫潇羽@无忆研习社 翻到这组数据的时候印象很深——很多时候，工程上的"巧"，比单纯的"大"更值钱。

这背后其实藏着一种很值得借鉴的设计哲学：找准瓶颈，用最小的结构去补它，而不是无脑加规模。并行草稿的瓶颈不在"层数不够多"，而在"块内没依赖"，那就专门加一个建模依赖的小模块去补，而不是把整个并行主干越堆越厚。这种"哪里漏补哪里、能轻量绝不重量"的克制，恰恰是工程做到一定火候才有的判断力。对我们做内容、做产品的人也一样有启发——很多问题不需要推倒重来，找到那个真正卡脖子的环节，往往一个小巧的改动就能撬动全局。

六、DSpark 第二招：按置信度和硬件负载，动态决定"这次验证几个"

如果说第一招是"把草稿打得更像样"，第二招就是"审稿要更会挑重点"。这一招叫置信度调度验证（confidence-scheduled verification），也是 DSpark 比传统推测解码更贴近真实生产环境的关键。

先说为什么需要它。前面讲过，草稿打得多不等于一定更快。在真实的高并发服务里，把一长串候选 token 全都塞给大模型验证，未必划算——那些大概率会被拒的尾部 token，验证它们要白白占用批处理容量（batch capacity，可以理解成大模型一次能同时处理的请求/token 的总额度）。系统空闲时这无所谓，可一旦系统繁忙，这些无用验证就会挤占其他用户的请求，拖累整体吞吐。

DSpark 给这件事配了两个部件来收拾。

我把这事翻译成一个更有画面感的场景。你可以把大模型这一侧想象成一个固定座位数的检票口，每一轮只能放进来一批人（也就是批处理容量）。系统清闲、队伍短的时候，你让每个人都多带几个"待核验的候选"进来无所谓，反正座位有富余；可一到高峰，队伍排到门外，你还坚持让每个人都拖着一长串大概率验不过的候选进闸，结果就是真正等着办事的人被挤在门外。聪明的做法显然是：高峰期对那些"一看就悬"的候选直接别让它占座，把宝贵的座位让给更可能办成的事。DSpark 这第二招，干的就是这个"看人下菜碟"的活儿——而要做到精准地"看人下菜碟"，前提是得先有一把准的尺子去衡量每个候选到底悬不悬。

置信度头：先估一估"这个候选靠不靠谱"

DSpark 给每个候选位置都预测一个置信度分数。这个分数的含义很具体：在前面的 token 都已经被大模型接受的前提下，当前这个位置继续被接受的概率有多高。训练时，这个分数是用"逐步接受率"的解析值来监督的，等于给它一把标尺去对齐。

不过这里有个老问题：神经网络给出的原始置信度，往往过度自信，说自己有九成把握，实际可能只有七成。DSpark 的处理办法是加一道事后校准，叫顺序温度缩放（Sequential Temperature Scaling）。校准之后，衡量"自信程度和真实准确率差多少"的期望校准误差（ECE），从原来的 3 到 8 个百分点，压到了大约 1 个百分点。说人话就是：经过这道工序，模型说自己有几成把握，就真的差不多有几成把握了——这一步对后面要靠置信度做决策至关重要。

别小看这道校准。它直接决定了第二招靠不靠谱。试想，如果置信度本身就虚高，调度器拿着一份"注水"的把握去做决策，就会被忽悠着去验证一堆其实没把握的候选，高峰期照样把座位浪费掉；反过来如果它过度悲观，又会把本该放行的好候选误杀，白白丢掉提速空间。只有当"自报的把握"和"真实的命中率"基本对得上，后面那个看脸色分配验证预算的调度器，才有一把准的尺子可用。所以这看似不起眼的一步事后校准，其实是把第一招的"会猜"和第二招的"会调"真正咬合到一起的关键齿轮。

硬件感知调度器：闲时多验，忙时少验

有了靠谱的置信度，接下来就是那个硬件感知前缀调度器（hardware-aware prefix scheduler）登场。它会综合三个因素，动态决定每个请求这一轮到底该验证多少个 token：

• 当前系统的整体负载（闲还是忙）；
• 每个候选位置的置信度（值不值得验）；
• 引擎在不同批大小下的吞吐曲线（论文里记作 SPS(B)，在服务启动时测一次就够，相当于提前把"这台机器在不同负载下能跑多快"摸清楚）。

于是 DSpark 不会再机械地验证固定长度的候选块，而是随行就市：

为了不破坏推测解码"无损"这条底线，调度器还配了一个早停规则（early-stopping），保证动态调长度也不会改变最终输出分布。论文附录里甚至专门给了一个反例，说明如果图省事直接做朴素的全局搜索，反而可能"泄露信息"、破坏无损性——这种把边界情况都抠到的严谨，恰恰是它敢往生产环境上线的底气。

把两招合起来看：第一招让草稿"质量"更高，第二招让验证"预算"更省。一个负责把蛋糕做大，一个负责别浪费。这也是 DSpark 区别于"只追求一次多生成几个候选"的老思路最本质的地方——它同时把系统负载这个变量，正儿八经地纳进了决策里。

我特别想强调"协同"这两个字。这两招不是各管一段、简单相加，而是环环相扣：第一招把草稿打得又长又稳，等于给第二招准备了一批"值得验"的优质候选；第二招的置信度又反过来告诉系统，这批候选里哪些该放、哪些该收。少了第一招，第二招手里没好牌可调；少了第二招，第一招打出来的长草稿在高峰期照样会变成负担。正是这种"打草稿"与"挑重点"的咬合，才让 DSpark 在又快又稳又省之间走出了一条以前难走通的路。

七、实测数据怎么读：离线评测和线上部署是两回事

讲完原理，得看真章。这部分我把论文的数据分成"离线评测"和"线上部署"两块来读，因为这两块的意义完全不同——离线像在标准考场里比分数，线上才是真刀真枪跑生产流量。

先认识一个核心指标：接受长度

看数据前，先记住一个最关键的指标——接受长度（accepted length）。它表示每一轮推测解码里，平均有多少个 token 能被大模型一次性接受。这个数越大，说明草稿写得越合大模型的胃口，能"跳着走"的步子越大，提速空间也就越大。后面几乎所有比较，都是围着它转的。

离线评测：和两类代表方案掰手腕

离线部分，论文挑了四个目标模型来测——三个不同尺寸的 Qwen3（4B、8B、14B）加一个 Gemma4-12B，对手是两类老方案的代表：自回归阵营的 Eagle3 和并行阵营的 DFlash。场景覆盖数学推理、代码生成、日常聊天三大类，用到的都是业内公开的标准数据集（像 GSM8K、MATH500、AIME25、MBPP、HumanEval、LiveCodeBench、MT-Bench、Alpaca、Arena-Hard 这些）。

结果是 DSpark 全面领先：在三个 Qwen3 尺寸上，接受长度相对 Eagle3 提升约 27% 到 31%，相对 DFlash 提升约 16% 到 18%；Gemma4-12B 上也保持领先。

更有意思的是不同任务之间差距很大。还是拿那个 4B 模型举例，数学任务的平均接受长度