DeepSeek-V4-Flash preview
+60–85%
单用户生成速度
比较条件：匹配实际系统总吞吐量。此处是生成阶段每用户 token/s 的提升，不是所有请求总耗时都减少 60–85%。
DEEPSEEK RESEARCH / EXPLAINED
先猜后验，
把等待变短。
DSpark 是一种投机解码加速框架：先快速准备一小段草稿，再由原来的大模型把关。它让草稿接得更连贯，也让每一份验证预算用得更划算。 [1]
ONE DECODING CYCLE 交互示意
已确定的上下文 早餐我准备喝
一杯热牛奶。
① 先把昂贵的活并行做完。
草稿骨干一次计算多个位置的基础分数；这还不是最终提交给用户的文本。
草稿骨干一次计算多个位置的基础分数；这还不是最终提交给用户的文本。
01 先补一块拼图 · AUTOREGRESSION
Transformer 会并行，
为什么生成时还要等？
这里讨论自回归文本生成。模型根据已经确定的文本预测下一个 token，再把它接回上下文。后一个位置需要知道前面究竟选了什么。 [3]
实验 01 · 亲手生成一句话
教学分词 · 非真实模型推理用户输入用一句话描述一只猫。
已生成的 token 0 / 7
点击一次，就让目标模型前进一步。
读取已确定的上下文
目标 Transformer
前向计算 0 次
关键区别：“模型内部能并行计算”，不等于“还没选出的未来文本也能直接确定”。token 是模型处理文本的片段，不必恰好等于一个字或一个词；这里人为切分以方便观察。 [3]
02 理解底座 · SPECULATIVE DECODING
小助手起草，
大模型最后把关。
先看一轮“草稿 → 调度 → 验证 → 输出”。下面采用固定的贪心参考结果演示；不相符的第一个候选会截断整段后缀。随机采样的严格规则放在第 05 节。 [4]
实验 02 · 观察一轮解码
可调参数 · 贪心教学版0 · 不投机5 · 验证全部草稿
已确定早餐我准备 喝 ← 本轮锚点
草稿
新输出
—
接受的草稿 token
—
本轮新增 token
—
送入目标模型的位置数
接受拒绝舍弃目标模型补出
注意：拒绝不等于“事实错误”，只是不满足该次解码的接受规则。首次拒绝时，从对应分布补出一个 token；全接受时再补一个 bonus token。一次目标前向可以推进多步，但不等于只付出一个 token 的计算量。 [4]
候选之间仍有依赖，为什么大模型能一次验证？
候选已经是已知输入，不需要等模型逐个生成。对“喝｜一｜杯｜热”，各位置能同时计算自己的下一 token 分布；因果注意力只让它们读取左边。
例如，“杯”对应的分布在假设前缀“喝一”成立时计算。如果“一”被拒绝，“杯”及后面的计算就不能沿用。计算可以并行，接受必须形成连续前缀。 [4]
| 输入位置 | 喝 | 一 | 杯 | 热 |
|---|---|---|---|---|
| 喝 → 预测一 | 可读 | × | × | × |
| 一 → 预测杯 | 可读 | 可读 | × | × |
| 杯 → 预测热 | 可读 | 可读 | 可读 | × |
| 热 → 预测牛奶 | 可读 | 可读 | 可读 | 可读 |
示意：省略更早上下文。一个前向同时计算多行。
03 DSPARK 创新一 · SEMI-AUTOREGRESSIVE
并行做重活，
顺序做轻活。
纯并行草稿虽然快，但后一个位置不知道前一个位置实际采样了什么，可能把两种合理说法拼坏。DSpark 加入很轻的顺序模块，补上块内依赖。 [1 §3.1]
实验 03 · 让后一个词接得上
目标模型的上下文特征 + 锚点 / 占位输入
并行草稿骨干 一次前向 · 计算多个位置的基础分数
U₁U₂U₃U₄
轻量顺序头：前一个 token → 当前分数偏置
x₁→x₂→x₃→x₄
重的 Transformer 不必逐位置重跑；只让很轻的头从左到右工作。
简化场景：回答对方的感谢，只允许两种搭配
“没｜问题” 或 “不｜客气”。下面的概率为人为设定。
① 假设第一个位置已经选中
② 第二个位置如何分配概率？
问题
90%
客气
10%
点一下抽样，看这次是否搭配连贯。
不是“整段猜完再纠错”。先并行得到基础分数，再由轻量模块依据前面已采样的 token 调整分数，并从左到右采样。骨干可以共享上下文，但这不同于知道同一块中前面实际选出的词。50% / 90% 仅用于教学，不是论文接受率。 [1 §3.1]
Markov 头：只补“紧邻前一个词”的影响。
并行骨干仍负责上下文信息；新增的顺序偏置依赖前一个 token，以低秩矩阵实现。不要误解成整个模型只记得一个词。 [1 §3.1]
RNN 头：给轻量模块再加一点记忆。
论文也讨论用递归状态保留块内前缀历史的版本；论文中的 DeepSeek-V4 生产配置采用 Markov 头。 [1 §3.1、§5.1]
多看一层：基础分数与“顺序偏置”怎样合起来？
qₖ = softmax(Uₖ + Bₖ)
Markov 版本：Bₖ = W₁[xₖ₋₁] W₂
Markov 版本：Bₖ = W₁[xₖ₋₁] W₂
Uₖ 是并行骨干对第 k 个位置算出的基础 logits（未归一化分数）；Bₖ 是轻量头补上的偏置；softmax 把两者相加后的分数变成概率。低秩分解避免直接保存巨大的“词表 × 词表”转移矩阵。 [1 式4–5]
上面的两词玩具例子从相同分数出发，给兼容搭配加 ln(9) 的偏置，于是概率由 1:1 变成 9:1。这是为了展示机制，真实偏置需要学习，并不保证每次都选中兼容词。
04 DSPARK 创新二 · CONFIDENCE SCHEDULING
猜得长，
不如验证得值。
把大模型看作一位同时服务多人的审稿人。空闲时多看几页划算；忙碌时，低把握的后缀会挤占别人的机会。DSpark 同时看前缀存活概率与硬件成本。 [1 §3.2]
实验 04 · 你来掌管验证预算
空闲拥挤
额外验证的代价正在变高
拖动负载，观察每条请求保留的长度。点击任意概率方块，查看“单步置信度”怎样变成“整段存活概率”。
候选位置 1 → 5 · 显示前缀存活概率 aⱼ送验长度
—
送入目标模型的位置数 B
3 个锚点 + 选中的草稿位置
—
预计本轮新增 token 数 τ
每条请求至少推进 1 个
—
预计未转化为输出的位置
B − τ · 不是实际拒绝记录
教学模型，不是实测。仅展示 3 条请求、每条最多 5 个候选；负载通过人为成本曲线体现，不对应真实并发人数。方块越靠后，必须同时满足的前缀条件越多。亮色为送验前缀，虚线为不送验后缀。
全部验证
固定 5 / 请求— 教学 token / 秒
—
DSpark 式调度
—— 教学 token / 秒
—
看懂数字：为什么不是只看每个词的置信度？
cⱼ 估计的是“前面的候选已接受时，当前候选也会被接受”的条件概率；它不是事实正确率。前 j 个全部存活的估计为：
aⱼ = c₁ × c₂ × … × cⱼ
单请求预期新增 = 1 + a₁ + … + aℓ
单请求预期新增 = 1 + a₁ + … + aℓ
例如 c₁ = c₂ = c₃ = 0.8，则第 3 个候选能被保留的概率是 0.512，而不是 0.8。前面的“1”来自目标模型补出的 token。置信度还需要校准，不能直接把“自信”当作准确概率。 [1 §3.2]
算法细节：怎样算“值不值得”？
把各请求的前缀扩展按 aⱼ 从高到低排列；在平滑成本假设下，沿此顺序增加验证位置，当预期吞吐量不再提高时停止。不是给每条请求设一个相同的固定置信度阈值。
B = Σᵣ (1 + ℓᵣ)
τ = Σᵣ (1 + Σⱼ≤ℓᵣ aᵣ,ⱼ)
吞吐估计 Θ = τ × SPS(B)
τ = Σᵣ (1 + Σⱼ≤ℓᵣ aᵣ,ⱼ)
吞吐估计 Θ = τ × SPS(B)
SPS(B) 表示对应 batch 大小时每秒能执行的步数，应来自实际引擎测量。本实验用合并固定开销后的玩具曲线 T(B) = 20 + (0.05 + 1.15ρ)B + (0.002 + 0.10ρ)B² 毫秒，ρ 为负载比例；SPS = 1000/T。
严格实现还有因果限制：不能偷看当前 token 的结果，再决定是否让它参评。论文的同步算法使用早停；生产方案用前两步的历史预测确定容量，并对当前候选排序，以适应异步流水线与不平滑硬件曲线。此处只演示平滑成本下的同步选择逻辑，不复刻生产服务。 [1 算法1、§5.2、附录A]
05 质量从哪里来 · EXACT SAMPLING
更快，不靠让草稿
“蒙混过关”。
严格投机采样保留的是目标模型的输出概率分布，不是保证两次运行得到完全相同的句子。置信度只帮助分配预算，真正把关的是接受与拒绝采样规则。 [4]
实验 05 · 草稿有偏，输出分布也能不偏
真实采样公式 · 三词玩具模型假设下一词只有 茶、咖啡、水。目标模型概率固定为 50%、30%、20%；让草稿模型偏爱“茶”，再观察校正。
20%90%
理论平均接受率 80%
已抽样 0 次 · 被拒后重采样 0 次
已抽样 0 次 · 被拒后重采样 0 次
草稿 q目标 p / 校正后理论值抽样后实际频率
调节草稿偏好，再点“模拟”。看看它最终是否仍接近目标的 50 / 30 / 20。
有限次抽样会有随机波动。这个实验运行离散分布上的标准拒绝采样，不调用 DeepSeek。它展示的是概率校正，不意味着目标模型本身不犯事实错误，也不是实际大模型输出质量测试。 [4]
展开接受 / 拒绝公式，以及一个容易忽视的条件
设 p 是目标分布，q 是实际使用的草稿分布（包括顺序头带来的调整）。先从 q 抽出 x，以如下概率接受：
α(x) = min(1, p(x) / q(x))
如果拒绝，不能简单再从 p 随便抽一次，而应从“目标相对草稿缺少的概率质量”中重采样：
r(v) = max(p(v) − q(v), 0) / Σᵤ max(p(u) − q(u), 0)
玩具例子中，草稿 q = (0.70, 0.18, 0.12)，目标 p = (0.50, 0.30, 0.20)。接受部分的总概率质量为 (0.50, 0.18, 0.12)，剩余 0.20 按 (0, 0.60, 0.40) 补回，最后正好恢复 p。若 q = p，全部接受，根本不会走拒绝分支。 [4]
调度也必须满足“不偷看未来采样结果”的因果条件；否则先挑“有利的候选”再验证，会引入选择偏差。无损来自完整算法的正确实现，不是来自一句“让大模型检查一下”。 [1 §3.2.2、附录A]
06 从玩具实验回到论文 · EVIDENCE
到底快了多少？
先问“在什么条件下”。
这一节才是论文报告的真实生产数据：DeepSeek-V4 预览版服务中，DSpark-5 与先前 MTP-1 基线比较。单用户出字速度和全系统吞吐量是两种不同指标。 [1 §5.4]
均相对 MTP-1；DSpark-5 最大草稿长度为 5。
DeepSeek-V4-Pro preview
+57–78%
单用户生成速度
比较条件：匹配系统容量。收益受模型、硬件、并发、草稿与目标的一致程度影响；不是本地部署的普遍承诺。
别把极端比值当日常加速。论文还报告在非常严格的速度要求下，相对吞吐量提升 +661%（Flash）与 +406%（Pro）。这时 MTP-1 已接近服务边界、只能支撑很小的并发；作者强调这些点说明可服务范围扩大，而非通用的数倍加速。 [1 §5.4]
DSpark 需要重新训练主模型吗？
为什么有时收益有限，甚至不划算？
草稿本身要花时间，也占资源。若接受率很低，即使剪掉后缀，已经付出的并行起草成本也无法收回。不同推理引擎对动态长度的支持也会影响收益；仅有草稿权重并不自动等于复现整套生产调度。 [1 §5.2–5.4]
✓ 带走真正重要的三件事
现在，让你来当审稿人。
已掌握 0 / 3
第 3 个候选被拒绝，
第 4 个看着没问题，能保留吗？
想想第 4 个候选的计算依赖了哪个前缀。
服务器很忙时，
为什么不干脆把草稿都验证完？
区分“能不能做”与“做了值不值”。
“不损失质量”的严格含义，
更接近下面哪一种？
回想最后那个三词概率实验。
DSpark = 半自回归草稿 + 置信度 / 硬件感知调度 + 严格目标验证。
让便宜的计算多做一点，让昂贵的计算少浪费一点，而不是降低最后的把关标准。 [1]