@dzhulgakov：来自 @deepseek_ai 的 DSpark 巧妙融合了多种投机解码思路，将吞吐量提升 1.5 到 5 倍…

DSpark 来自 @deepseek_ai 巧妙地融合了多种推测解码思想，在真实生产系统中实现了 1.5 至 5 倍的吞吐量提升

让我们从最基础出发，通过 10 个概念来理解它

1. LLM 解码中的批处理

生成 Token 受限于从内存读取权重的速度。因此，并行解码 10 个 Token 仅比生成 1 个略慢。持续批处理正是利用了这一洞察

2. 推测解码

对于同一请求，Token N+1 依赖 Token N，因此无法并行解码。但如果我们能猜出这些 Token（“推测”），就能从主模型角度快速验证其前缀中有哪些是正确的

3. 草稿模型

如何推测？当然是用模型。最简单的方法是运行一个在同一分布上训练的更小模型，例如使用 Qwen 0.8B 为 Qwen 397B 提供草稿

4. 推测并非免费

time_per_token = (num_tokens_drafted * drafter_time + verify_time(num_tokens_drafted)) / num_tokens_accepted

推理器运行缓慢，或猜测率过低导致草稿生成过多，都会带来负面影响。需要找到恰当的平衡点

5. EAGLE 与 MTP

将推理器设计为主模型的一个额外 Transformer 层，即除了前一个 Token 外，它还消耗丰富的潜在表示（最后激活）。这样仅需 1-2 层而非完整模型即可实现

推理速度更快、准确度更高的推理器

6. DFlash

MTP 需要 N 步生成 N 个草稿 Token。DFlash 利用扩散思想在一次前向传播中生成所有 N 个 Token

推测速度大幅提升，但草稿质量有时优于 MTP/Eagle，有时则不如

7. DSpark ≈ Eagle + MTP

DFlash 在初始位置更强 Eagle3 在长草稿生成时更连贯，但初始猜测质量较低

DSpark 结合了并行块与自回归思想，超越了任意单一方法

8. 更廉价的顺序块

Eagle3/MTP 在每个推理位置运行完整注意力。由于 DFlash 拥有并行块来捕获先前上下文，顺序步骤可以借助 RNN 甚至马尔可夫模型变得非常廉价。最终得到更快且依然准确的推理器！

9. 可变长度草稿与硬件感知调度器

草稿 Token 数量应为多少？它随情况变化：

• 某些请求（例如编码）比其他请求更容易预测
• 最优长度取决于服务器负载（批大小）。低负载时（GPU 计算空闲）多推测，高吞吐时少推测

有些引擎使用静态的 --num-draft-tokens 参数。根据推理器的置信度和当前服务器负载动态调整要更好

实现起来有难度。推理引擎中 CPU/GPU 高度流水线化，改变长度通常需要改变张量尺寸并返回 CPU，从而拖慢速度

通过精心的实现（以及大量酷炫的 CUDA 内核），所有操作可在 GPU 上完成，无需额外开销

10. 在线推理器校准

模型在预测下一个 Token 时倾向于过度自信，使得难以确定停止草稿生成的阈值

但我们可以观察运行时推理器的性能，并实时调整（“校准”）阈值

整合起来

DeepSeek 的魔力在于卓越的系统工程与紧密的模型协同设计。其中许多思想此前已被发表。令人印象深刻的是，他们将这些思想整合在一起，通过自适应系统实现了巨大的端到端改进

我们在 @FireworksAI_HQ 从事大量推测解码研究和自适应系统工程，包括为客户工作负载持续训练和校准推理器

期待构建 DSpark 的思想，并与世界分享更优质的推理服务