DSpark.让每一轮计算，
多走几步。
大模型不必变小，回答也可以更快。
秘诀是：先快速打草稿，再让大模型验收。
DSpark 把“怎么写”与“验多少”一起改进了。[1]
重点不是让大模型“少把关”，
而是让一次把关，更有收获。
你只需知道：Transformer 会根据上文预测后文。
先别想整个模型。
只看一小句话。
这里把文字片段叫作 。模型每做一轮 ，就得到下一个 token 的概率，再从中选一个接到句尾。
试着点几次按钮，感受一下：新片段成了下一轮的上文。
为方便观察，本页的中文切分都是示意，不代表 DeepSeek 的真实分词。
已知文字可以一起处理；自由生成时，后面的选择依赖前面刚刚选出的 token。
我听过 KV cache，它不能解决吗？
缓存能复用历史 token 的部分计算，避免反复重算旧信息。但它不会提前告诉模型“下一个 token 到底选了什么”。因此，复用历史计算与消除新 token 的先后依赖是两件事。推测解码处理的是后者带来的等待。[2]
这里“通过”表示符合目标模型的选择规则，不是“句子合不合语法”。动画为方便理解采用贪心选择；随机采样的无损校正见第 6 站。
一处拒绝，后面的验证就失去原来的前提。留下已通过的部分，再补一个修正 token；若全部通过，则多补一个 token。[2]
等等，为什么能一次验证多个位置，却不能一次生成整句？
因为验收时，整段候选文字已经存在。每个位置的“假设上文”都已知，就能一起算。因果注意力仍然挡住未来：验证第 3 个候选时，只使用已确认上文与前两个候选，不偷看第 3 个及之后的文字。
这是把多个已知输入下的条件预测放进同一次前向，不是解除语言模型的因果约束。真正选中哪些候选，仍要看前面的验收结果。[2]
重活一起做，落笔时接上话。
纯并行草稿可以同时为多个位置给分，但采样时未必知道前面实际选了什么。比如“喝水”和“读书”都合理，分开选却可能凑出“喝书”。
DSpark 把大部分草稿计算留给并行主干，再加一个很小的顺序模块：在每次选 token 之前，根据已经选出的前缀调整分数。这就是半自回归。[1]
第一个位置选了“喝”，第二个位置并不知道。
为隔离机制，实验把基础概率固定为 50% / 50%，把顺序修正后的偏好设为 90% / 10%。这些不是论文实测，也不意味着真实模型一定消除搭配错误。
主干先把分数算好；小模块在从左到右采样时，给“接得上”的候选增加偏好。贵的部分没有跟着逐 token 重跑。
进一层：并行主干、Markov head、RNN 分别是什么？
并行主干基于 DFlash，利用目标模型提供的上下文特征，为一块待生成位置产生隐藏状态与基础分数。位置之间可以交换特征，但这不等于已经知道各位置最终会采样出哪个 token。[3]
默认的 Markov head：看刚刚选出的那一个
顺序修正默认只依赖前一个 token。用一张低秩的转移表给当前词表加偏置，避免每一步再跑完整 Transformer。注意：仅修正头是“一步记忆”，并非整个草稿模型只能看前一个 token。历史语境已经在并行主干里。论文还讨论了能积累块内前缀信息的 RNN 头。[1]
本实验用两个基础分数 0、0；给合理候选加 ln(9)，便从 50% 变为 90%。
在公开的 Qwen3-4B 训练配置中，草稿长度为 7、主干为 5 层、Markov rank 为 256。这是该实验配置，不应当成所有 DSpark 部署的固定规格。[5]
写得长，不如验得值。
越靠后的草稿，越可能因为前面的拒绝而白验。DSpark 估计它们“能走到这里”的把握，再结合引擎的计算成本，决定每个请求到底送多少去验证。[1]
把草稿想成连续的几道门。第 2 道门只有在第 1 道门通过后才有意义。这里的 不是“内容真实的概率”，而是在前面已经通过时，这一处被大模型接受的估计概率。
拖低第 1 处，留意整条后缀如何一起变暗。其余各处的条件概率固定为 85%、75%、70%、65%。
卡片数字 = 前缀一路通过到此处的概率。
✓ 送去验证 — 提前不送；送去 ≠ 保证接受。
三类请求及概率均为作者构造，用于展示不同草稿质量；并不代表所有代码都比聊天好猜。负载滑块改变的是“多验一个位置有多贵”，不是生产服务器的实测并发人数。
同一个草稿，在空闲时可能值得验，繁忙时则未必。它关心的是单位时间能多产出多少被接受的 token，而不只是接受率高不高。[1]
想看清计算：这个实验怎样选出验证长度？
先把各处的条件概率相乘：aⱼ = c₁ × … × cⱼ。再把三个请求的候选扩展按 aⱼ 从高到低排序。因为同一请求的 aⱼ 不会上升，排在后面的 token 不会越过自己的前缀。
E = R + Σᵣ Σⱼ≤ℓᵣ aᵣ,ⱼ
期望输出速率 = E ÷ T(B)
本页为了展示成本变化，自己设定 T(B) = 12 + (0.06 + 0.04L)B + 0.0008LB² 毫秒，L 是滑块数值。按排序逐个加名额，期望速率不再上升时停止。真实系统使用测量得到的步频曲线 SPS(B)，而不是这个公式。表中比较也不包含完整的真实草稿与系统开销。[1]
| 草稿名额 | 总 B | 期望新输出 | 模拟毫秒 | 模拟 token/s |
|---|
两个严谨补丁：置信度要校准，调度不能偷看未来。
校准。一个估计器即使能给候选排好坏，也可能整体过于自信。DSpark 用独立验证集上的 Sequential Temperature Scaling 校准累积的前缀存活概率；这不等于降低生成温度，也不是改变大模型的回答偏好。
因果性。当前 token 能否被送验，不能靠偷看未来候选来反向决定，否则可能筛选出有偏样本。论文的同步算法使用早停；只有目标曲线满足单峰等条件时，早停才同时给出全局最优。生产实现还使用历史步的预测来设置容量，以适配异步执行和不平滑的硬件成本曲线。[1]
本页用预先固定、与候选词内容无关的概率和光滑成本曲线做演示，不是在浏览器里复现真实 DSpark 的在线调度器。
更快，不靠降低把关标准。
你也许会担心：“既然让小模型先猜，会不会把回答带偏？”把关机制的意义，恰恰就是不让草稿替目标模型作最终决定。
改变生成路径，
不改变目标分布。
在满足算法条件时，无损推测解码保留目标模型的输出分布。贪心模式可以直观看作“选得一样才接受”；随机模式则必须用接受概率 + 拒绝后的补偿采样校正。[2]
分布相同，不是每次随机运行逐字相同，
也不等于回答永远正确。
用一个只有两种选择的实验，看懂“无损”怎么成立。
假设下一步只有 A、B 两个 token。目标模型始终想要 A 占 60%、B 占 40%。你可以把草稿对 A 的偏好调得很偏，观察最后的分布。
拒绝后：按 max(p − q, 0) 归一化，再采样
如果当前块全部接受，就从目标模型对应的下一位置分布补出一个 token；若首次拒绝，则从该位置的修正分布补出一个 token。这个校正与合法的调度规则一起，才构成无损保证。[2]
以下是论文报告的生产流量结果，不是上面几个实验的输出。对照是原有 MTP-1 单 token 草稿方案，且比较时匹配了系统总吞吐水平。[1]
单用户生成速度提升
相同系统总吞吐下
单用户生成速度提升
相同系统总吞吐下
来源：DSpark 论文 §5.4、图 7。它们是特定模型、引擎与流量下的区间，不是所有显卡、所有请求的统一加速比。[1]
最后，只带走这一条线。
DSpark 不是让小模型代替大模型，而是让它们更好地分工：草稿尽量快而连贯，验证尽量花得值得，最终分布仍由目标模型决定。
原理有出处，演示有边界。
依据下列一手材料编写。DSpark 论文使用 2026 年 7 月 6 日的 arXiv v1；资料核对日期为 2026 年 9 月 6 日。本页为独立教学作品，不是 DeepSeek 官方网站。
Cheng 等，2026。§3.1 半自回归；§3.2 置信度与调度；§5.2 部署中的因果约束；§5.4 性能与限制。流程按图 1 重新设计，性能数字取自图 7 及正文。
Leviathan、Kalman、Matias，ICML 2023。自回归瓶颈、并行验证、接受规则与拒绝后的校正采样，参见 §2 与 Algorithm 1。
Chen、Liang、Liu，2026。理解一次前向的并行草稿，以及来自目标模型的上下文特征。
区分原有目标模型 checkpoint 与附加的推测解码模块。
草稿 block_size、num_draft_layers、markov_rank 等具体配置。仅用于说明一种公开实验设置。
涵盖草稿数据准备、训练与评估。不能仅凭本页的浏览器模拟推断实际部署性能。
交互中的语句、概率、成本曲线均为作者构造的教学模型；没有调用语言模型，没有测量本机 GPU。全文可阅读，公式按需展开。除主动打开来源链接外，本文件无需联网，不加载外部脚本或字体。