Fireworks AI的CTO Dmytro Dzhulgakov，写了条系列推文来解释DeepSeek新发布的DSpark 系统。大佬直接把相关的技术都给串起来了，方便理解一些：
------------------
DSpark 来自 DeepSeek，它巧妙整合了许多 speculative decoding（推测解码）的思路，在真实生产系统中实现了 1.5 倍到 5 倍的吞吐提升。
我们可以从 10 个思路来理解它，先从最基础的概念讲起。
1. LLM 解码中的 batching
生成 token 的瓶颈，主要在于从内存 / 显存中读取模型权重。
所以，并行解码 10 个 token，通常只会比解码 1 个 token 稍微慢一点。Continuous batching（连续批处理）正是利用了这个特点。
2. 推测解码（图2）
对同一个请求来说，第 N+1 个 token 依赖第 N 个 token，所以不能直接并行解码。
但如果我们能先“猜”出后面可能是什么 token，也就是推测，那么就可以让主模型快速验证：这些猜测里，从开头算起有多少个 token 是对的。
3. Draft model（图3）
那怎么做推测呢？当然是用模型。
最简单的方式，是运行一个更小的模型，而且这个小模型和主模型在同一类数据分布上训练。
比如，用 Qwen 0.8B 去给 Qwen 397B 做 draft。
这里的小模型就叫 drafter，或者 draft model，也就是“草稿模型”。
4. 推测不是免费的（图4）
可以粗略写成这个公式：
time_per_token = (num_tokens_drafted * drafter_time + verify_time(num_tokens_drafted)) / num_tokens_accepted
意思是：
每个 token 的平均耗时，取决于你草拟了多少 token、草稿模型跑得有多慢、主模型验证这些 token 要花多久，以及最终有多少 token 被主模型接受。
如果推测解码跑得太慢，或者一次 draft 太多 token、但猜中率很低，反而会拖慢整体速度。
所以这里需要找到合适的平衡。
5. EAGLE 和 MTP（图5）
一种改进方式是，把 drafter 做成主模型的额外 Transformer 层。
也就是说，drafter 不只看前一个 token，还会利用主模型内部丰富的 latent representation，也就是最后一层激活等隐藏表示。
这样就不需要再跑一个完整的小模型了，通常只用 1 到 2 层就够。
结果是：speculator 会更快，也更准确。
6. DFlash （图6）
MTP 需要走 N 步，才能生成 N 个 draft token。
DFlash 则借鉴了 diffusion 的思路，可以在一次前向传播里生成全部 N 个 token。
这样 speculative decoding 会快得多。不过 draft 的质量有时比 MTP / Eagle 更好，有时也会更差。
7. DSpark ≈ Eagle + MTP （图7、图8）
DFlash 在开头几个位置的预测更强。
Eagle3 在较长 draft 生成中更连贯，但一开始的猜测质量较低。
DSpark 把并行块生成和自回归生成两种思路结合起来，因此超过了单独使用任一方法。
8. 更便宜的顺序块（图9、图10）
Eagle3 / MTP 在每一个 draft 位置都要运行完整注意力。
而 DFlash 已经通过并行块捕捉了前文上下文，所以后续的顺序步骤可以做得便宜得多，比如用 RNN，甚至 Markov 模型。
这些设计最终会带来一个更快、但仍然准确的 drafter。
9. 可变长度 draft 与硬件感知调度器（图11、图12）
num_draft_tokens 应该设成多少？答案是：它会变化。
有些请求更容易预测，比如代码任务；有些请求则更难预测。
最优 draft 长度也取决于服务器负载，也就是 batch size。
低负载时，GPU 计算资源比较空闲，可以多做一些 speculative drafting；高吞吐负载下，则应该少推测一些。
有些推理引擎只有一个静态的 --num-draft-tokens 参数。但更好的做法是，根据 drafter 的置信度和当前服务器负载，动态调整 draft 长度。
实现起来并不容易。推理引擎里的 CPU / GPU 通常是高度流水线化的，而改变 draft 长度往往意味着要改变张量尺寸，并回到 CPU 处理，这会拖慢速度。
但如果实现得足够精细，再配合很多优秀的 CUDA kernel，就可以把这一切都放在 GPU 上完成，不增加额外开销。
10. 在线 drafter 校准（图13）
模型在预测下一个 token 时，往往会过度自信。
这会导致一个问题：很难设定“什么时候停止 draft 生成”的阈值。
但我们可以观察运行时 drafter 的实际表现，并动态调整这些阈值，也就是在线校准。
整合起来看（图14）
DeepSeek 的厉害之处，在于优秀的系统工程能力，以及和模型设计之间的紧密协同。
这里面很多想法之前都已经有人发表过。但令人印象深刻的是，DeepSeek 把它们很好地整合到一起，做出了巨大的端到端改进，并且系统还能自动适配。
我们在 Fireworks AI 做了大量 speculative decoding 研究和自适应系统工程，包括为客户工作负载持续训练和校准 drafter。
期待继续构建 DSpark 相关思路，并把更好的推理能力分享给世界。
