PAPER DEEP DIVE
DSpark:置信度调度的半自回归投机解码
DeepSeek 与北大提出的投机解码框架,同时清理草稿侧与验证侧的两笔浪费。草稿侧用「重的并行主干 + 极轻的串行头」补回块内 token 依赖,缓解并行草稿的后缀衰减;验证侧让草稿模型顺带预测每个位置的条件存活概率,经 STS 后验校准后,由读硬件吞吐曲线 SPS(B) 的调度器把验证长度当作全局吞吐最大化变量逐请求求解。离线接受长度比 Eagle3 高 30.9%/26.7%/30.0%、比 DFlash 高 16.3%/18.4%/18.3%,串行头只增加 0.2%-1.3% 整轮延迟。已在 DeepSeek-V4-Flash 与 V4-Pro 预览版生产系统上线并替换 MTP-1:同等吞吐下每用户生成速度快 60%-85%,严格交互性 SLA 下仍维持非退化的服务能力。代码与全部草稿权重已在 DeepSpec 开源(MIT)。
论文元信息
| 项目 | 内容 |
|---|---|
| 标题 | DSpark: Confidence-Scheduled Speculative Decoding with Semi-Autoregressive Generation(DSpark:置信度调度的半自回归投机解码) |
| 作者 | Xin Cheng、Xingkai Yu、Chenze Shao、Jiashi Li、Yunfan Xiong(五人同等贡献)等 33 人 |
| 机构 | DeepSeek-AI、北京大学 |
| arXiv | arXiv:2607.05147v1(2026-07-06,主分类 cs.AI,交叉 cs.CL) |
| 代码 | github.com/deepseek-ai/DeepSpec,MIT 许可,已发布:含数据准备、训练、评测全链路,以及 Table 1 所用的 Eagle3 / DFlash / DSpark 全部草稿模型权重(HuggingFace deepseek-ai/dspark_qwen3_{4b,8b,14b}_block7 与 dspark_gemma4_12b_block7) |
| 部署状态 | 已在 DeepSeek-V4-Flash(preview)与 DeepSeek-V4-Pro(preview)生产服务系统中上线,于 V4-preview 发布两周后替换原 MTP-1 基线 |
| 评测基准 | 数学(GSM8K、MATH500、AIME25)、代码(MBPP、HumanEval、LiveCodeBench)、日常对话(MT-Bench、Alpaca、Arena-Hard) |
一句话总结
这篇论文把投机解码的两笔浪费一次清掉:草稿侧用一个并行主干加一个极轻的串行头补回块内 token 依赖,缓解并行草稿的后缀衰减;验证侧让草稿模型顺带预测每个位置的存活概率,再由一个读硬件吞吐曲线的调度器决定每条请求该验多长。离线接受长度比 Eagle3 高 30.9%/26.7%/30.0%、比 DFlash 高 16.3%/18.4%/18.3%,串行头只带来 0.2%–1.3% 的整轮延迟;生产环境同等吞吐下每用户生成速度快 60%–85%。
研究背景与动机
大语言模型的自回归生成让推理延迟与输出长度成正比:每生成一个 token 就要走一遍完整前向,而单 token 解码的算术强度极低,GPU 大部分时间在等显存。投机解码(speculative decoding)给出的是一个原理上无损的解法——用一个轻量草稿模型提出 $\gamma$ 个候选 token,目标模型在一次前向里并行验证整个块,按拒绝采样接受与自己分布一致的最长前缀,再补一个 bonus token。因为接受规则严格保持目标分布,加速不以质量为代价。
论文用式 (1) 把这件事的成本结构写死:
$$L=\frac{T_{\text{draft}}+T_{\text{verify}}}{\tau}$$
$L$ 是每生成一个 token 的平均墙钟延迟,$\tau$ 是每轮被接受的 token 数。作者指出提速只剩三个杠杆:把 $T_{\text{draft}}$ 压下去(草稿更快)、把 $\tau$ 抬上来(草稿更好)、把有效的 $T_{\text{verify}}$ 降下来(验证更聪明)。整篇 DSpark 就是把这三个杠杆同时拉动,而多数已有工作只动其中一个。
草稿模型的两条路线在这三个杠杆上是互斥的。自回归草稿器(EAGLE 系列、Medusa 的树式扩展等)逐 token 条件于已采样的前缀,建模能力强、$\tau$ 高,但 $T_{\text{draft}}\propto\gamma$,于是被迫用小块和浅网络。并行草稿器(Medusa、DART、DFlash 等)一次前向出全部 $\gamma$ 个位置,$T_{\text{draft}}$ 几乎与块长无关,理论上可以把块开到很大;代价是每个位置相互独立,无法建模块内 token 之间的依赖,接受率沿块长快速衰减。论文把后者称为「后缀衰减」(suffix decay),并用一个具体例子说明失效模式:当上下文允许多种合理延续时(例如「of course」与「no problem」),并行草稿器会产出「of problem」「no course」这类跨模式拼接,因为每个位置是对所有可能前驱做边缘化,而不是条件于真正被采样出来的那一个。这一现象在非自回归翻译文献里叫 multi-modal collision。
第二个瓶颈在系统侧,而且论文的表述比算法侧更值得记:即使草稿质量修好了,「把所有草稿 token 都送去验证」本身就是浪费。理想验证长度沿两个轴变化。数据轴上,代码这类结构化请求天然比开放式对话更容易被接受;系统轴上,轻载时多验一个 token 几乎免费,重载时每一个高拒绝风险的 token 都在占用本可服务其它活跃请求的批容量。静态验证长度对这两个轴都是盲的,因此论文主张验证长度必须是一个按当前引擎负载实时求解的调度变量,而不是一个超参。
这两点合起来定义了 DSpark 的设计目标:保留并行主干的草稿速度,同时把自回归的依赖建模以尽可能小的代价补回来;再让草稿模型顺带产出一个可信的、经过校准的存活概率,把验证预算只投给期望回报为正的 token。作者的措辞是「verify smarter, not longer」——不是验得更长,而是验得更准。
预备知识:并行草稿器 DFlash 的接口
DSpark 的并行主干直接实例化为 DFlash,所以要先弄清 DFlash 吃什么、吐什么。它的关键设计是从目标模型里抽富上下文特征注入草稿层。prefill 阶段,目标模型若干层 $\{l_1,\ldots,l_m\}$ 的隐状态被拼接后投影到草稿隐空间(式 2):
$$H_{\text{ctx}}=\mathrm{RMSNorm}\bigl(W_c\,[H^{(l_1)};\,\ldots;\,H^{(l_m)}]\bigr)$$
其中 $W_c\in\mathbb{R}^{d\times md}$ 是共享投影。这些上下文特征再沿 key/value 的序列维与草稿块表示拼接,注入每一个草稿层(式 3):
$$K_i=[W_i^K H_{\text{ctx}};\;W_i^K H_d],\qquad V_i=[W_i^V H_{\text{ctx}};\;W_i^V H_d]$$
块内所有位置彼此双向注意,同时也注意到注入的目标上下文。草稿模型共享目标模型的 embedding 层与 language modeling head,两者都冻结;输入是一个 anchor token(上一轮目标模型生成的最后那个 token,论文里 anchor 与 bonus token 互通)后接 $\gamma$ 个 mask token embedding,一次前向产出全部 mask 位置的 logits。因为草稿只需一次前向,DFlash 在同等延迟预算下可以养得起比自回归草稿器更深的网络和更长的块。
DSpark 对这个主干只做了一处修改:不再「anchor 加 $\gamma$ 个 mask、只预测 mask 位置」,而是把 anchor 本身当作第一个预测位置,于是 $\gamma$ 个输入 token(anchor 加 $\gamma{-}1$ 个 mask)产出 $\gamma$ 个草稿 logits。少一个位置的输入,草稿计算量下降,草稿质量基本不变。这条修改在开源配置里可以直接核对:config/dspark/dspark_qwen3_4b.py 写死了 block_size=7、num_draft_layers=5、target_layer_ids=[1, 9, 17, 25, 33](对应式 2 的 $m=5$ 层)、mask_token_id=151669、num_anchors=512。
图1:DSpark 架构与一个完整解码周期(论文 Figure 1)。给定提示 ABC,目标模型走一步生成 D 作为 anchor;以 D 为输入,重型并行主干与轻量串行头产出草稿 EFGH 及对应置信度 $c_1$–$c_4$;硬件感知前缀调度器据分数保留前缀 EFG、丢掉低置信度的 H;目标模型并行验证被调度的前缀,E、F 接受、G 拒绝,于是生成修正 token G* 收尾本轮。
方法详解
半自回归生成:把块拆成并行与串行两段。并行主干(DFlash)一次前向跑完整个块,产出隐状态 $h_1,\ldots,h_\gamma$ 与基础 logits $U_1,\ldots,U_\gamma$。串行段不重算表示,只在这些基础 logits 上叠加一个依赖前缀的转移偏置 $B_k(x_0,x_{<k},x_k)$,得到块内联合分布(式 4):
$$P(X\mid x_0)=\prod_{k=1}^{\gamma}p_k(x_k\mid x_0,x_{<k}),\qquad p_k(v\mid x_0,x_{<k})=\frac{\exp\!\left(U_k(v)+B_k(x_0,x_{<k},v)\right)}{\sum_{u\in\mathcal{V}}\exp\!\left(U_k(u)+B_k(x_0,x_{<k},u)\right)}$$
$x_0$ 是上一轮验证留下的 anchor token,$\mathcal{V}$ 是词表。这个式子的结构很关键:偏置是加在 logits 上再统一 softmax,所以每个位置的概率仍然是精确的 softmax 求值。论文在相关工作里专门用这一点把自己与 CRF-NAT、CTC-drafter 区分开——后两者同样在并行隐状态上放串行模块,但 CRF 的全局归一化配分函数与 CTC 的对齐路径边缘化都拿不到精确的逐 token 概率,而投机解码的拒绝采样规则恰好强制要求这个概率。作者的说法是「把串行修正保持在局部」,于是 per-token 概率不失真,CTC-drafter 只能退回贪心验证的限制在这里不存在。推理时串行段按 $p_k(\cdot\mid x_0,x_{<k})$ 从左到右采样。
Markov 头:一阶转移的低秩分解。最简单的实例化把 $B_k$ 限制为只依赖紧邻前一个 token,退化成一阶转移 $B(x_{k-1},x_k)$。原则上这是一个完整的 $V\times V$ 矩阵,作者用低秩分解 $B=W_1W_2$ 近似,$W_1\in\mathbb{R}^{V\times r}$、$W_2\in\mathbb{R}^{r\times V}$,于是位置 $k$ 的转移偏置是(式 5):
$$B(x_{k-1},\,\cdot\,)=W_1[x_{k-1}]\,W_2\;\in\;\mathbb{R}^{V}$$
$W_1$ 充当 embedding 查找表,$W_2$ 充当 logit 投影。默认 $r=256$(配置里的 markov_rank=256),存储与每步计算都很小,即使词表很大串行循环也跑得动。回到前面那个例子:位置 1 一旦采样出「of」,Markov 头就在位置 2 抬高「course」、压低「problem」,跨模式碰撞被直接掐掉。源码里这条路径就是 deepspec/modeling/dspark/markov_head.py::VanillaMarkov.sample_block_tokens——一个 for step_idx in range(proposal_len) 的循环,每步 apply_step_logits(base_logits[:, step_idx, :], token_ids=prev_token_ids, ...) 后采样,再把采样结果赋给 prev_token_ids 进入下一步,正是式 (4)(5) 的逐字实现。
RNN 头:带块内记忆的替代方案。Markov 头一步之外无记忆,位置 $k$ 看不到 $x_{k-1}$ 之前的 token。RNN 头放松这一条,维护一个在块内累积全部前缀历史的循环状态 $s_k$。每步把当前状态 $s_{k-1}\in\mathbb{R}^r$、前一 token 的 embedding $W_1[x_{k-1}]\in\mathbb{R}^r$、主干隐状态 $h_k\in\mathbb{R}^d$ 拼成 $z_k=[s_{k-1};\,W_1[x_{k-1}];\,h_k]\in\mathbb{R}^{2r+d}$,然后做一次门控更新(式 6):
$$s_k=\sigma(W_g z_k)\odot s_{k-1}+\bigl(1-\sigma(W_g z_k)\bigr)\odot\tanh(W_c z_k),\qquad B_k(x_{<k},\,\cdot\,)=W_2^\top\tanh(W_o z_k)$$
$W_g,W_c,W_o\in\mathbb{R}^{r\times(2r+d)}$ 由单个线性层参数化后切成 gate / candidate / output 三份,$s_0$ 初始化为零。源码 RNNHead._rnn_step 与式子一一对应:z = torch.cat([state, prev_embeddings, hidden_states], dim=-1) → proj = self.joint_proj(z) → chunk(3) → new_state = gate * state + (1 - gate) * candidate。实验结论是 RNN 头相对 Markov 头只有边际增益(主要出现在更长草稿上),考虑到实现复杂度与部署特性更差,论文默认用 Markov 头。这个「更强的串行模块并不划算」的负面结果,本身是本文最有信息量的架构判断之一。
置信度头:预测的是条件存活概率,不是接受率。置信度头为每个草稿位置输出一个标量 $c_k\in(0,1)$,语义被精确定义为:在块内所有更早 token 都已被接受的前提下,位置 $k$ 的草稿 token 能通过目标模型验证的条件概率。结构是线性投影加 sigmoid(式 7):
$$c_k=\sigma\bigl(w^\top[h_k;\,W_1[x_{k-1}]]\bigr)$$
特征里同时含主干隐状态 $h_k$ 与来自 Markov embedding 的前一草稿 token 表示——这使 $c_k$ 依赖于已经采样出来的 $x_{k-1}$,也正是后文因果性讨论的根源。监督标签不是硬 0/1,而是解析接受率 $c_k^*$,由草稿分布与目标分布的总变差距离直接算出(式 8):
$$c_k^*=1-\tfrac{1}{2}\lVert p_k^d-p_k^t\rVert_1$$
源码 deepspec/modeling/dspark/qwen3/modeling.py::predict_confidence_step 就是这条式子:prev_embeddings = self.markov_head.get_prev_embeddings(prev_token_ids),features = torch.cat([hidden_states, prev_embeddings], dim=-1),再过 self.confidence_head(features).float();标签侧 loss.py::_compute_accept_rate_3d 写的是 1.0 - 0.5 * (draft_probs - target_probs).abs().sum(dim=-1) 并 clamp 到 $[0,1]$,与式 (8) 完全一致。
后验校准:为什么阈值启发式不够,需要 STS。基于阈值的验证启发式只要求置信度分数能正确排序草稿 token 的质量;而本文的硬件感知调度要用累积接受概率的绝对数值去算期望接受长度 $\tau$,排序对而幅度错就会把吞吐估计算歪。神经置信度估计普遍过度自信,于是论文引入 Sequential Temperature Scaling(STS,顺序温度缩放):因为每个 $c_i$ 都是条件概率,链式法则给出前缀被接受的联合概率是累积乘积 $\prod_{i\leqslant k}c_i$;STS 在留出验证集上从左到右逐位置校准这个联合概率,在每个位置 $k\in\{1,\dots,\gamma\}$ 做一次一维网格搜索,找出使累积乘积的期望校准误差(ECE)最小的温度标量,并保持所有更早位置已校准的分数不动。温度缩放是保序变换,因此它纠正幅度而不打乱置信度头学到的相对排序。源码侧的评测器 deepspec/eval/dspark/confidence_head.py::PerPositionConfidenceMetrics 正是按位置统计累积乘积预测的 ECE / AUROC / Brier,并产出论文里的可靠性图。
硬件感知前缀调度器:把验证长度写成全局吞吐最大化。先前方法对置信度分数施加静态阈值来决定验证长度,这在单请求假设下有效,在高并发生产系统里却次优,因为验一个草稿 token 的效用强依赖当前负载。论文把问题重述为全局优化(Algorithm 1):一个批次里有 $R$ 条活跃请求,请求 $r$ 的逐位置置信度为 $c_{r,1},\dots,c_{r,\gamma}$,调度出的验证长度为 $\ell_r\in\{0,\dots,\gamma\}$。因为投机解码只接受连续前缀,位置 $j$ 的存活概率是累积乘积
$$a_{r,j}=\prod_{i\leqslant j}c_{r,i}$$
单次验证步送给目标模型的批大小(按 token 计)与期望接受 token 数分别是
$$B=\sum_{r=1}^{R}(1+\ell_r),\qquad \tau=\sum_{r=1}^{R}\Bigl(1+\sum_{j=1}^{\ell_r}a_{r,j}\Bigr)$$
再把引擎吞吐记为 $\text{SPS}(B)$(每秒步数,给定前向批大小 $B$),调度目标是最大化系统级期望 token 吞吐
$$\Theta=\tau\cdot\text{SPS}(B)$$
这条容量曲线在引擎初始化时离线 profile 一次,存成一张轻量代价表。$\text{SPS}$ 只依赖 $B$ 是一个简化假设,论文用脚注给了理由:实际服务中平均上下文长度远低于极端值,对 DeepSeek-V4 这类高度优化架构的解码延迟影响可忽略;而在 prefill-decode 分离部署里,decode 侧负载均衡器会让各 DP rank 的请求数与总上下文长度大致均衡,从而摊平序列长度方差。
贪心为什么是全局最优,以及 early-stop 为什么不可省。$\Theta$ 看似组合搜索,但结构允许高效贪心:因为 $a_{r,j}$ 关于 $j$ 单调不增,把请求 $r$ 的验证长度从 $j-1$ 延到 $j$ 的边际收益恰好就是 $a_{r,j}$,于是按 $a_{r,j}$ 全局降序排序天然尊重块内前缀依赖。若 $B$ 固定,最优分配就是从所有 $\{a_{r,j}\}$ 组成的全局池里贪心取存活概率最高的那些草稿 token。调度器沿这条贪心准入路径增量地决定 $B$:全局排序后逐个准入,每步用代价表查一次 $\text{SPS}$ 更新 $\Theta$,一旦 $\Theta\leq\Theta_{\text{best}}$ 就 break。
这个 break 不是工程偷懒,而是无损性的必要条件。无损投机解码严格要求非预期性(non-anticipating):准入决策不得依赖未来的候选 token。而置信度头用了前一采样 token 的 Markov 特征,要算 $a_{r,k+1}$ 就必须先有 $x_{r,k}$ 的实现值;一次回溯式全局搜索会因此把 $x_{r,k}$ 泄漏进步骤 $k$ 的准入决策,造成选择偏差。论文在附录 A 给了一个极简反例:取 $R=1$、$\gamma=2$、$a_1=0.8$,profile 出的容量曲线为 $\text{SPS}(1)=1.0$、$\text{SPS}(2)=0.5$、$\text{SPS}(3)=0.45$,于是 $\Theta_0=1\times1.0=1.0$、$\Theta_1=(1+0.8)\times0.5=0.9$。若没有 early-stop,调度器会先评估 $\Theta_2$:当 $x_1$ 导致 $c_2=0.9$ 时 $a_2=0.72$,$\Theta_2=(1+0.8+0.72)\times0.45=1.134$ 是全局最大,返回 $\ell=2$,第一个草稿 token 被准入;当 $x_1$ 导致 $c_2=0$ 时 $\Theta_2=(1+0.8+0)\times0.45=0.81$,全局最大仍是 $\Theta_0=1.0$,返回 $\ell=0$,第一个 token 不被准入。也就是说「是否准入 $x_1$」取决于 $x_1$ 自己是什么。把它变成分布偏差:设词表 $\{A,B\}$,$p_t(A)=0.7$、$p_t(B)=0.3$、$p_d(A)=p_d(B)=0.5$,标准接受概率 $\min(0.7,0.5)+\min(0.3,0.5)=0.8$ 与假设的 $a_1$ 吻合;回溯调度器下 $x_1=A$ 以 $\min(1,0.7/0.5)=1$ 被接受故输出 $A$,$x_1=B$ 不被准入而由目标模型重采,于是 $\Pr(Y=A)=0.5+0.5\times0.7=0.85$、$\Pr(Y=B)=0.15$,与目标分布 $(0.7,0.3)$ 不符,回溯调度不是无损的。逐步 early-stop 把截断决策限制在当前步已处理的前缀上,隔开了未来 token,从而精确恢复目标分布。代价是:这种逐步 early-stop 当且仅当 $\Theta$ 单峰(隐含假设硬件容量曲线平滑衰减)时才达到全局最大,第 5.2 节要处理真实 SPS 不平滑的情况。
训练目标:三项损失与位置衰减权重。训练时从每条目标序列里随机采样多个 anchor 位置组成 $\gamma$-token 块。目标模型全程冻结,草稿模型共享其 embedding 与 LM head 并保持冻结,只更新并行主干、串行块与置信度头。三项损失都乘位置权重 $w_k=\exp(-(k{-}1)/\gamma)$,强调在前缀验证下对期望接受长度贡献更大的早期位置。交叉熵项训练草稿器预测正确的下一个 token(式 9),分布匹配项惩罚草稿分布与目标分布的总变差距离(式 10):
$$\mathcal{L}_{\text{ce}}=-\sum_{k=1}^{\gamma}w_k\log p^d_k(x^*_k),\qquad \mathcal{L}_{\text{tv}}=\sum_{k=1}^{\gamma}w_k\lVert p^d_k-p^t_k\rVert_1$$
因为总变差距离就是接受率的直接代理(逐步接受概率等于 $1-\frac{1}{2}\lVert p^d-p^t\rVert_1$),最小化 $\mathcal{L}_{\text{tv}}$ 等价于直接最大化期望接受率。置信度项是对软标签 $c_k^*$ 的二元交叉熵(式 11),总目标按默认权重 $\alpha_{\text{ce}}=0.1$、$\alpha_{\text{tv}}=0.9$、$\alpha_{\text{conf}}=1.0$ 组合(式 12):
$$\mathcal{L}_{\text{conf}}=-\sum_{k=1}^{\gamma}w_k\bigl[c_k^*\log c_k+(1-c_k^*)\log(1-c_k)\bigr],\qquad \mathcal{L}=\alpha_{\text{ce}}\mathcal{L}_{\text{ce}}+\alpha_{\text{tv}}\mathcal{L}_{\text{tv}}+\alpha_{\text{conf}}\mathcal{L}_{\text{conf}}$$
开源实现里这三项逐条可核:loss.py::_build_loss_weight_mask 用 torch.exp(-positions.float() / loss_decay_gamma) 构造 $w_k$(注意配置里 loss_decay_gamma=4.0 而 block_size=7,即代码用的是 $\gamma$ 的一个独立超参而非严格等于块长);_compute_local_l1_term 算 $\lVert p^d-p^t\rVert_1$ 并按同一权重掩码归一化;置信度目标 confidence_targets = accept_rate_3d.detach() 被显式 detach,避免置信度损失把梯度回灌进草稿分布。ce_loss_alpha=0.1 与 l1_loss_alpha=0.9 对应式 (12) 的前两项权重,confidence_head_alpha=1.0 对应第三项。训练超参:lr=6e-4、warmup_ratio=0.04、weight_decay=0、bf16、global_batch_size=512、10 个 epoch、max_length=4096、Qwen chat template。
把整条流水线连起来。下图按论文的真实连接关系重画了解码周期,注意三个容易被忽略的点:串行头只加 logits 偏置而不重算隐状态;置信度头与串行头共享 $W_1[x_{k-1}]$ 这一份 Markov embedding(这是它必须依赖已采样 token、从而引出因果性问题的原因);调度器读的是离线 profile 出的 $\text{SPS}(B)$ 代价表,因此它的决策同时依赖数据侧的置信度和系统侧的负载。
flowchart TD P[Prompt tokens] --> T1[Target model one step
emits anchor token x0] T1 -->|target hidden from layers 1 9 17 25 33
Eq2 RMSNorm Wc concat| CTX[H_ctx context features] CTX -->|Eq3 KV injection into every draft layer| BB[Parallel backbone DFlash
5 layers, single forward pass
anchor counts as position 1] T1 --> BB BB --> HK[hidden states h_1..h_gamma] BB --> UK[base logits U_1..U_gamma] HK --> SEQ[Sequential head, Markov default
Eq5 bias B = W1 of x_{k-1} times W2
rank r = 256, left to right loop] UK --> SEQ SEQ --> DK[draft tokens x_1..x_gamma
Eq4 softmax over U_k plus B_k] HK --> CONF[Confidence head
Eq7 c_k = sigmoid of w dot concat h_k and W1 of x_{k-1}] SEQ -->|shares Markov embedding| CONF CONF --> STS[Post-hoc STS calibration
per position 1D grid search minimizing ECE
order preserving] STS --> SCH[Hardware-aware prefix scheduler
a_{r,j} = cumprod c, B = sum 1+l_r
tau = sum 1 + sum a, Theta = tau times SPS of B
global sort by a plus early stop] SPS[Profiled SPS of B cost table
built once at engine init] --> SCH SCH -->|scheduled lengths l_r| VER[Target model parallel verification
reject sampling, longest accepted prefix plus bonus] VER -->|accepted prefix and bonus token| OUT[Output tokens] OUT -->|last token becomes next anchor| T1 VER -.->|Eq8 analytic label c_k star = 1 minus half TV distance| LOSS[Training only: L = 0.1 Lce + 0.9 Ltv + 1.0 Lconf
position weights w_k = exp of minus k-1 over gamma] LOSS -.-> BB LOSS -.-> SEQ LOSS -.-> CONF
图2:DSpark 的解码周期与训练回路(依据论文第 3 节与 Algorithm 1 绘制)。实线是推理期的数据流,虚线是训练期由目标模型分布提供的监督信号;目标模型、共享 embedding 与 LM head 全程冻结。
实验结果
实验设定。目标模型覆盖四个规模与两个模型家族:Qwen3-{4B, 8B, 14B} 与 Gemma4-12B。草稿器对照两个代表:并行路线的 DFlash 与自回归路线的 Eagle3(基于 Training-Time Test)。为了严格公平,三个草稿器都在同一训练框架、同一数据上重训:Eagle3 的 TTT horizon 对齐到 7,与 DFlash、DSpark 使用的 block size 一致;所有草稿器用同一组目标模型特征层;层数上 Eagle3 取 1 层,DSpark 与 DFlash 取 5 层。训练数据是 Open-PerfectBlend(PerfectBlend 的开源版,130 万样本,chat 17.6% / math 39.4% / code 38.9% / instruction-following 4.1%),只用其中的 prompt,回复由各目标模型按推荐采样参数重新生成,全部草稿器训 10 个 epoch 以确保收敛,数据生成与评测都采用 non-thinking 模式。评测口径是每轮解码的接受长度 $\tau$(含目标模型产出的 bonus token),采样温度 1.0,链式草稿。
主结果:接受长度全面领先。为了把原始草稿质量与系统级调度策略分离,离线评测关闭置信度调度器,强制所有草稿器提出固定长度的块。这一点必须记住——表 1 度量的是草稿质量本身,调度器的收益要到第 5 节的生产环境才显现。
| 目标模型 | 草稿器 | GSM8K | MATH | AIME25 | MBPP | HumanEval | LCB | MT-Bench | Alpaca | Arena-Hard |
|---|---|---|---|---|---|---|---|---|---|---|
| Qwen3-4B | Eagle3 | 5.14 | 4.62 | 3.92 | 3.69 | 4.16 | 3.77 | 2.39 | 2.26 | 2.55 |
| DFlash | 5.40 | 4.85 | 4.15 | 4.40 | 4.74 | 4.18 | 3.07 | 2.96 | 2.83 | |
| DSpark | 6.11 | 5.70 | 4.89 | 5.13 | 5.38 | 4.86 | 3.64 | 3.54 | 3.29 | |
| Qwen3-8B | Eagle3 | 5.30 | 4.77 | 3.91 | 3.96 | 4.33 | 4.17 | 2.66 | 2.54 | 2.54 |
| DFlash | 5.33 | 4.91 | 4.07 | 4.36 | 4.64 | 4.39 | 3.11 | 2.98 | 2.81 | |
| DSpark | 6.17 | 5.78 | 5.01 | 5.16 | 5.52 | 5.17 | 3.72 | 3.58 | 3.21 | |
| Qwen3-14B | Eagle3 | 5.24 | 4.60 | 3.71 | 3.81 | 4.14 | 4.01 | 2.62 | 2.47 | 2.48 |
| DFlash | 5.41 | 4.84 | 3.98 | 4.44 | 4.59 | 4.33 | 3.10 | 2.94 | 2.72 | |
| DSpark | 6.21 | 5.74 | 4.94 | 5.26 | 5.43 | 5.02 | 3.70 | 3.58 | 3.13 | |
| Gemma4-12B | Eagle3 | 5.87 | 5.46 | 4.83 | 4.72 | 5.37 | 4.16 | 3.19 | 3.06 | 2.72 |
| DFlash | 5.45 | 5.04 | 4.22 | 4.39 | 4.95 | 3.70 | 2.98 | 2.84 | 2.59 | |
| DSpark | 6.05 | 5.78 | 5.12 | 5.11 | 5.64 | 4.51 | 3.49 | 3.35 | 2.92 |
表1:每轮解码的接受长度 $\tau$(论文 Table 1,越高越好)。宏观平均上,DSpark 在 Qwen3-4B/8B/14B 上分别比 Eagle3 高 30.9%、26.7%、30.0%,比 DFlash 高 16.3%、18.4%、18.3%。Gemma4-12B 上 DSpark 在九个基准里全部第一,且优势跨模型家族保持。
表 1 还暴露了一个很强的域效应:Qwen3-4B 上结构化任务的接受长度天然更高(math 宏观 5.57、code 5.12),开放式对话低得多(chat 3.49)。这种数据可预测性的内在方差,意味着静态验证长度必然在尾部 token 上浪费算力——它正是置信度调度验证的直接动机。值得一提的是 Gemma4-12B 那一组:DFlash 在这个目标上反而不如 Eagle3(GSM8K 5.45 对 5.87,九个基准里八个落后),说明纯并行草稿的优势并不跨家族自动成立;DSpark 把九项全部拉回第一,等于同时修复了两条路线各自的失效模式。
图3:位置级条件接受率(论文 Figure 2,Qwen3-4B,按域在各基准上平均)。分母只统计前 $k-1$ 个草稿 token 全部被目标模型接受的实例,因此这个指标剥掉了早期前缀错误的惩罚,单独反映位置 $k$ 的基础预测质量。自回归草稿器 Eagle3 平稳或上升,并行草稿器 DFlash 出现后缀衰减。
为什么并行能赢自回归:三段式拆解。表 1 里并行与半自回归草稿器的接受长度反而长于全自回归草稿器,这与「逐步自回归产出更高质量序列」的常规预期相反。论文用图 3 的条件接受率把它拆成三段。其一,位置 1 的容量优势:在第一个草稿位置,两类架构都只依据目标上下文预测下一个 token,差异纯粹来自架构容量——自回归模型受 $O(\gamma)$ 延迟约束只能做浅网络,$O(1)$ 的并行草稿器养得起深网络,于是 DFlash 在位置 1 明显高于 Eagle3(Math 0.88 对 0.81,Chat 0.72 对 0.53)。而投机解码是严格的前缀匹配存活过程,第一个 token 杠杆最大,这里被拒就整块作废,所以这个初始容量优势被不成比例地放大到最终接受长度上。其二,后续位置的独立性缺陷:位置 2–7 上,随着早期 token 锁定语义路径,后续 token 本应更可预测,Eagle3 有效利用了这种条件确定性(Chat 上从 0.53 升到 0.74),DFlash 却持续衰减(Code 0.87→0.78,Chat 0.72→0.63)。其三,DSpark 同时拿到两头:它继承深并行草稿器的高初始接受率(Math 上起点 0.93),轻量串行头又压住了并行生成典型的快速衰减,于是整块保持高而稳定的条件接受率。
一点自回归就够:深度、块长与延迟开销。论文沿两个维度扫设计空间。深度维度固定 block size 为 7,把 DSpark 层数从 1 变到 5,并与 5 层 DFlash 对比:接受长度随深度单调上升,边际收益最陡的是 1→2 层,而2 层的 DSpark 在全部三个域上都超过 5 层的 DFlash。这条结论的含义是参数效率——用一个轻量串行头注入局部自回归,比单纯堆更深的并行层换来更好的序列连贯性。
图4:草稿器深度的影响(论文 Figure 3)。固定草稿长度,在 math / code / chat 三个域上聚合的接受长度随 DSpark 层数单调上升;2 层 DSpark 已优于更深的 5 层 DFlash 基线。
图5:草稿长度与延迟开销(论文 Figure 4)。左三块:固定 5 层,草稿长度(proposal length $\gamma$ 加一个 anchor)在 $\{4,8,12,16\}$ 上扫描,DSpark 在每个长度都超过 DFlash,且差距随 $\gamma$ 增大而扩大。最右块:batch size 128 下的整轮引擎延迟(一次目标验证 + 并行草稿前向 + 串行采样循环),对上下文长度 $\{512,1024,2048,4096\}$ 取算术平均以消除序列长度偏置。
块长维度固定 5 层,把草稿长度扫到 $\{4,8,12,16\}$,DSpark 在每个长度都赢,且优势随 $\gamma$ 稳定扩大:$\gamma=7$ 时相对 DFlash 的接受长度增益是 math 16% / code 15% / chat 18%,$\gamma=15$ 时扩大到 30% / 26% / 22%。原因在图 3 已经给出——纯并行生成有快速后缀衰减,长块的边际效用递减;DSpark 缓解了衰减,所以块越长相对收益越大。RNN 头只在更长草稿上带来边际增益,因此默认仍用 Markov 头。延迟侧的结论是这篇论文最容易被低估的一组数字:因为该 batch size 下目标模型主导验证计算,串行块的开销可以忽略,草稿长度从 4 扩到 16 只给整轮延迟增加 0.2%–1.3%(相对 DFlash 基线),换来最高 30% 的接受长度提升。
置信度头的诊断:静态阈值扫描。要在离线隔离地检验估计器本身,论文用 Qwen3-4B 做阈值扫描(阈值 0 等价于标准定长验证),把硬件感知调度器留到第 5 节的生产评测。随阈值升高,整体接受率稳步上升,因为置信度头把最终会被拒的 token 提前剪掉了;剪枝在 chat 上最显著(高熵分布让定长验证效率最低),接受率从 45.7% 升到 95.7%,结构化任务的剪枝更温和、保留更多草稿 token,Math 从 76.9% 升到 92.5%、Code 从 67.6% 升到 92.0%。
图6:置信度阈值扫描(论文 Figure 5)。阈值为 0 即标准定长验证;随阈值升高,斜纹柱段(最终被拒的 token)被剪掉,整体接受率稳步上升。
图7:Alpaca 数据集上的可靠性图(论文 Figure 6)。背景直方图是各置信度分箱的样本频次。原始估计器判别力很强但系统性过度自信,后验校准把前缀存活概率对齐到经验接受率。
但静态阈值在动态服务环境里是次优的,因为它无视系统负载:低并发时验低置信度 token 的机会成本极小,高并发时却在浪费关键批容量。这正是硬件感知调度器的动机,而它要求置信度模型同时具备强判别力和精确校准。图 7 的可靠性图给出量化结论:原始模型判别力强(ROC-AUC 0.81–0.90)但过度自信(ECE 3%–8%),施加后验 STS 后平均 ECE 降到约 1%,存活概率估计变得可靠。
| 诊断维度 | 域 | 原始 / 静态阈值 | 校准或调度后 | 说明 |
|---|---|---|---|---|
| 阈值扫描下的整体接受率 | Chat | 45.7% | 95.7% | 剪枝最显著,高熵分布使定长验证效率最低 |
| Math | 76.9% | 92.5% | 剪枝温和,保留更多草稿 token | |
| Code | 67.6% | 92.0% | 结构化文本天然接受率高 | |
| 置信度判别力 ROC-AUC | 全部 | 0.81–0.90 | — | 排序能力已足够强 |
| 校准误差 ECE | 全部 | 3%–8% | 约 1%(STS 后) | 调度需要绝对幅度,故必须校准 |
| 串行头延迟开销 | batch 128,ctx 512–4096 | DFlash 基线 | +0.2%–1.3%($\gamma$ 4→16) | 目标模型主导验证计算 |
| 接受长度增益 | $\gamma=7$:+16/15/18% | $\gamma=15$:+30/26/22% | math / code / chat,块越长收益越大 |
表2:置信度头与串行头的关键量化结论(数据取自论文 4.3.2 与 4.3.3 节及 Figure 4–6)。阈值扫描与可靠性诊断均在 Qwen3-4B 上完成,且离线阶段刻意关闭调度器,只检验估计器本身。
真实部署:从离线算法到 DeepSeek-V4 生产线
第 4 节的成绩是在离线基准上测的,调度器被刻意关掉。论文用整整一节(第 5 节)交代把它塞进 DeepSeek-V4-Flash 与 DeepSeek-V4-Pro 预览版生产服务系统时碰到的工程障碍,这一节的信息密度比多数论文的「系统实现」段落高得多,因为它写的是一台已经在服务真实流量的机器。
生产版草稿模型与离线评测的配置并不相同:主干是 3 层 MoE 加 mHC,注意力滑窗 128,块长上限 $\gamma=5$(评测里用的是 7),串行建模用 Markov head,置信度头与草稿模型端到端联合训练,再用 STS 做后验校准以提供可靠的调度信号。
训练侧的两个瓶颈与两个解法。训练草稿模型需要目标模型的输出分布做监督,把两个模型都在整段上下文上跑一遍,显存与跨 worker 通信都吃不消。内部框架 HAI-LLM 里做了两件事。一是隐状态通信:跨并行 worker 传目标模型的全词表 logits($V\approx 10^{5}$)是带宽杀手,改成临时缓存目标模型前向激活,只传 LM head 之前的隐状态,把 LM head 投影放到草稿模型 worker 本地、且只对被采样的目标位置执行,于是每 token 的通信复杂度从 $O(V)$ 降到 $O(d)$,$d$ 是隐维度。二是锚点有界的序列打包:为了让草稿模型的计算量与目标模型的上下文长度解耦,从训练序列里采固定数量的草稿锚点,把这些彼此孤立的预测块打包成稠密 batch;打包靠 token 级注意力索引而不是标准 2D mask 实现,这样在多条独立序列与多个锚点之间仍保持精确的因果掩码,同时不必付 padding 的算力与显存代价。
调度器在生产环境里的两个根本冲突。Algorithm 1 在理论上无损,但直接部署会撞上两件事。第一,它假设容量曲线光滑单峰,而真实的硬件 $\text{SPS}(B)$ 是离散的、呈台阶状跳变(jagged cliff):批容量跨过某个阈值时吞吐突然掉一档。带早停的逐步贪心搜索会在第一个下降沿就停下来,被锁死在某个台阶前的局部最优里。第二,它要求每一步动态决定草稿 token 数,这与连续 CUDA graph 重放以及零开销调度(ZOS)冲突——ZOS 需要在当前步算完之前就知道下一步的 batch size,同步调度会把 GPU 流水线堵住。
论文的修法是把调度改成异步,而且这个改动同时解决正确性与利用率两个问题。具体地,用两步之前的置信度头输出来近似即将可用的验证容量;当前步的候选 token 仍然严格按它们真实的、最新的累积置信度排序,两步前的历史预测只用来决定动态截断长度,也就是批容量上限 $K$。这样准入过程被改写成一次动态 top-$K$ 选择:$K$ 有轻微时间偏移,但选择机制是保序的,置信度最高的草稿 token 永远优先进验证。调度延迟被完全隐藏,ZOS 集成无缝。
有了这条异步流水线,就可以把早停的 break 去掉,改成无约束全局搜索,从而跨过 SPS 断崖找到真正的最大吞吐。回溯搜索通常会泄漏未来 token 信息、破坏无损保证(这正是 Appendix A 反例要防的事),但异步设计恰好构成一道因果屏障:无约束搜索评估的只是两步之前的历史预测,准入决策与当前 token $x_{r,k}$ 的实现彼此隔离,截断长度天然只依赖两步前就已可得的信息。无损性保住了,硬件断崖上的吞吐也拿到了。
推理内核:变长查询。动态路由把一个难题推到物理执行层——推理框架必须在一个 batch 里高效支持变长查询。标准 decode kernel 是为定长查询重度优化的,硬塞变长已验证前缀会因 padding 与负载不均导致 GPU 利用率大幅下降。论文的解法是把物理执行与逻辑序列追踪解耦:所有请求的 token 在 kernel 里被展平成独立元素一视同仁地处理,序列内的复杂依赖则通过集成在稀疏注意力实现里的一个 marker tensor 严格表达。在 DeepSeek-V4 架构上,只有 index-attention 与 compress 两个 kernel 需要改动来支持这种变长路由,调度器因此不引入任何底层执行开销。
论文还澄清了延迟与吞吐这对经典矛盾在它这个场景里其实并不对立。生产环境中每步处理的请求数常被资源上限(每请求固定 KV-cache 容量)与可用流量池(RL 长尾负载)压住,有效 batch size 长期低于 GPU 的算力饱和阈值。在这种区间里,给定并发上限,最大化单 GPU 总 token 吞吐与最大化单用户生成速度(tok/s/user)从竞争目标变成了高度相关的目标。
图8:真实流量下的吞吐—交互性 Pareto 前沿(论文 Figure 7)。散点是从线上用户流量直接采样的原始遥测数据,覆盖复杂的真实请求分布;实线是拟合出的性能前沿。DSpark-5 相对 MTP-1 基线把整条前沿向外推。
线上真实流量的成绩。评测对象是 DSpark-5($\gamma=5$)对 MTP-1 基线,跑在 V4-Flash 与 V4-Pro 预览版的生产服务引擎里。MTP-1 是原来的生产配置,在 V4-preview 发布两周后被 DSpark 替换掉。单 token 配置之所以长期留在生产里,是因为静态多 token 草稿器(MTP-3/5)在高并发下会因过度验证开销严格劣化聚合吞吐——所以拿 DSpark 跟这个基线比,直接证明的是它能在动态服务环境里安全释放大草稿块的潜力。
| 引擎 | SLA(tok/s/user) | 聚合吞吐相对 MTP-1 | 同等吞吐下每用户提速 | 论文对数字的定性 |
|---|---|---|---|---|
| DeepSeek-V4-Flash(preview) | 80(中等) | +51% | +60% 至 +85% | 可比工况,代表性增益 |
| 120(严格) | +661%(名义值) | 基线已逼近运行边界、只能撑极小并发;该点主要说明 DSpark 扩展了可行的交互性前沿,而不是对一个被充分利用的基线的倍数加速 | ||
| DeepSeek-V4-Pro(preview) | 35(中等) | +52% | +57% 至 +78% | 同一模式复现 |
| 50(严格) | +406%(名义值) | MTP-1 再次进入低并发区间;应理解为在基线无法高效支撑的交互性目标下仍维持可用吞吐 |
表3:生产环境 SLA 锚点上的实测结果(数据取自论文 5.4 节与 Figure 7)。作者对两个名义百分比明确做了保守解读,这一点比数字本身更值得记。
图9:负载自适应的吞吐与验证预算(论文 Figure 8)。上排 (a, b) 是不同系统并发下的聚合输出吞吐;下排 (c, d) 是每请求分到的目标模型平均验证预算。并发升高时,动态调度器自动收紧每请求的验证长度以避免资源争抢。
图 9 解释了增益背后的机制。在生产部署常见的中等并发区间(V4-Flash 少于 200 并发请求、V4-Pro 少于 150),硬件感知调度器把闲置的目标算力用起来,将验证预算从 MTP-1 的静态 2 token 扩展到每请求约 4–6 token;更长的验证意味着每次前向接受更多 token,直接兑现为 Pareto 前沿上的吞吐增益。当并发继续上升、目标容量饱和,调度器反向收紧预算,平均验证长度随负载平滑下降,低置信度草稿 token 在消耗关键批容量之前就被剪掉。轻载时吃满空闲算力、重载时守住关键批容量,这条自适应曲线是生产部署能稳定跑下去的原因。
局限性
作者自述:草稿侧的固定成本无法回收。前缀调度器最小化的是目标模型那一侧的验证浪费,但 DSpark 仍然要为每个块付出一笔固定的草稿侧成本——并行主干必须先完整生成 $\gamma$ 个 token 的初始块。对于天然接受率就低的复杂请求,这笔前置草稿算力是收不回来的:调度器最多决定「不验」,决定不了「不草」。作者给出的后续方向是在草稿模型内部引入难度感知的提前退出,让这类请求直接跳过整块生成。
早停的全局最优性依赖单峰假设。Algorithm 1 的逐步早停只有在目标函数 $\Theta$ 单峰时才返回全局最大吞吐,而这隐式假设硬件容量曲线平滑衰减。论文自己在 5.2 节承认真实的 $\text{SPS}(B)$ 是台阶状跳变的,因此生产版本必须去掉早停、改用无约束全局搜索才拿到正确结果。换句话说,论文里那个形式上最干净的算法并不是线上真正在跑的那一个。
「两步之前」是一处未被量化的近似。异步调度用两步前的置信度输出决定当前步的容量 $K$,论文论证了它保序、且因因果屏障而无损,但没有给出这个时间偏移在多快的负载变化下会失准的实验:如果并发在两步之内发生剧烈跳变(突发流量、抢占、长上下文请求集中到达),用陈旧的容量估计去切当前步的预算会带来多大吞吐损失,文中没有数据。
离线评测与线上部署是两套配置,且 SPS 只建模了批大小一个自变量。离线结果用 $\gamma=7$ 的 DSpark、调度器关闭;线上用 $\gamma=5$、3 层 MoE 主干、调度器全开。两套数字不能互相印证,读者无法判断离线接受长度的增益有多少真正转化为线上吞吐。同时吞吐模型 $\text{SPS}(B)$ 只把 batch size 当自变量,而真实服务的每步耗时还受序列长度分布、KV-cache 命中率、prefill 与 decode 混排比例影响;在长上下文或强 prefill 干扰的负载下,这条曲线是否还成立,论文没有讨论。
生产结果的可复现性受限。5.4 节的全部数字来自 DeepSeek 内部的生产服务引擎、内部训练框架 HAI-LLM、DeepSeek-V4 预览版模型与真实用户流量遥测。开源仓库 DeepSpec 提供的是离线训练与评测链路,第三方无法重跑 Pareto 前沿,只能验证离线那半部分结论。
总结与展望
DSpark 的贡献可以拆成三层,而它的说服力也按这三层递减。算法层:半自回归草稿范式——计算重的并行主干加一个极轻的串行头——把并行草稿器的后缀衰减修好了,接受长度比 Eagle3 高 30.9%/26.7%/30.0%、比 DFlash 高 16.3%/18.4%/18.3%,代价只有 0.2%–1.3% 的整轮延迟。这一层是干净的、可复现的、开源权重齐全。校准层:把置信度头当成一个需要同时满足判别力与校准度的概率估计器来对待,用 ROC-AUC 0.81–0.90 与 STS 后 ECE 约 1% 说明「排序对」和「幅度对」是两件不同的事,而调度需要后者。这一层的方法论价值超出投机解码本身——任何想用模型自报置信度做资源分配的系统都会遇到同一个坑。系统层:把验证长度从一个超参提升为一个按实时引擎负载求解的调度变量,并在线上把 MTP-1 替换掉。
系统层也是最难独立检验的一层。生产数字漂亮,但它们绑死在 DeepSeek 自己的模型、框架与流量上;而论文在 5.2 节坦承线上跑的并不是 Algorithm 1 而是它的异步近似版本,这种坦诚值得肯定,同时也说明该算法的实际形态是被基础设施倒逼出来的,不是从理论推出来的。对其它团队而言,可直接迁移的是三条工程结论:容量曲线是台阶状的就别用早停贪心;把调度做成异步、用历史置信度定容量、用当前置信度定排序,可以同时拿到利用率与无损性;变长验证要靠展平 token 加 marker tensor,而不是靠给 kernel 打补丁式的 padding。
往后看,作者点出的难度感知提前退出是最直接的延伸:草稿成本目前对所有请求一视同仁,而请求难度的分布显然是长尾的,能在草稿阶段就退出的请求应该比能在验证阶段被剪掉的请求省得更多。另一个方向是把调度信号的来源从「草稿模型自报」扩展到「服务系统的全局观测」——当前 $\text{SPS}(B)$ 只看批大小,若把序列长度分布、KV-cache 压力、队列等待时间一并纳入,验证预算的分配可以做得比按并发数平滑收缩更细。还有一类问题是这篇论文没有触碰的:置信度校准是在与训练分布相近的评测集上做的,分布漂移(新领域、新语言、超长上下文)会让 STS 的等渗映射失准,而调度器对失准的反应是直接改变验证预算,这会把一个统计问题放大成服务质量问题。
对 RobotWorld 的读者来说,这篇论文的价值不在机器人本身,而在它示范了一种把「模型能力」与「服务系统」联合优化的完整工程闭环:算法改动(半自回归草稿)→ 可观测信号(校准后的存活概率)→ 调度决策(动态验证预算)→ 线上遥测验证(Pareto 前沿外推)。具身智能系统里实时控制回路对延迟的敏感度远高于文本生成,视觉语言动作模型的上车部署同样要面对「算力有限、请求突发、延迟硬约束」这三件事,这套方法论的迁移空间比它的具体数字更值得关注。
投机解码研究一直在问「怎么让草稿更准」,DSpark 补上了另一半问题:草稿准了之后,该验多少。前者的答案是架构,后者的答案是调度——而调度需要一个既会排序又敢说真话的置信度。
作者对 +661% 这个数字的处理方式,比数字本身更有参考价值:他们主动说明基线在该 SLA 下已逼近运行边界,因此这个点应被理解为前沿被扩展,而不是对一个被充分利用的基线的倍数加速。