DeepSeek发布DSpark：将V4生成速度提升60-85%

DeepSeek 发布了 DSpark，一个投机解码框架，并开源了检查点和训练代码。这是一项服务优化，而非新模型。检查点 DeepSeek-V4-Pro-DSpark 和 DeepSeek-V4-Flash-DSpark 复用已有的 V4 权重，并附加一个草稿模块。

DeepSeek 研究团队还开源了 DeepSpec，这是一个采用 MIT 许可的代码库，用于训练和评估投机解码的起草器。这项工作针对一个问题：在繁忙的生产服务中实现更快的大模型推理。

摘要

• DSpark 将并行起草主干与一个极轻量的顺序头配对，以减少后缀衰减。
• 一个置信度头和负载感知调度器在 GPU 空闲时验证更多 token，繁忙时验证更少。
• 离线状态下，接受长度相比 Eagle3 提升 26–31%，相比 DFlash 提升 16–18%。
• 在 DeepSeek-V4 的生产环境中，每位用户的生成速度比 MTP-1 基线快 60–85%。
• 输出保持无损，并且检查点与 DeepSpec 训练代码均已开源。

DSpark 是什么？

投机解码将生成过程分为两个角色。一个小型的草稿模型提出一个 token 块。完整的目标模型随后在一次前向传播中验证该块。

拒绝采样接受最长的有效前缀并附加一个奖励 token。由于该规则精确保持目标分布，因此没有质量损失。DSpark 保留了这一保证。它改变了 token 的起草方式以及被验证的数量。

它优化的延迟计算

每个 token 的延迟遵循论文中的公式：L = (Tdraft + Tverify) / τ。其中 τ 是每个周期接受的 token 数量。加速仅来自三个杠杆。

你可以更快地起草，降低 Tdraft；你可以更好地起草，提高 τ；或者你可以更智能地验证，减少浪费的 Tverify。DSpark 同时拉动这三个杠杆。

工作原理：半自回归生成

早期的起草器面临取舍。像 Eagle3 这样的自回归起草器会基于前一个 token 来条件化每个 token。这带来了很强的接受率，但起草成本随块大小增长。

像 DFlash 这样的并行起草器在一次前向传播中生成整个块。起草成本保持低廉，但每个位置忽略了相邻 token。结果是“多模态冲突”以及沿后缀迅速衰减的接受率。

DSpark 将起草分为两个阶段。一个重型并行主干（在它们的设置中即 DFlash）为每个位置生成基础 logits。然后一个轻量级的顺序头在采样每个 token 之前增加一个前缀相关的偏置。

默认的顺序头是马尔可夫头，它只关注紧邻的前一个 token。低秩分解（秩 256）使其保持低廉，即使词汇量很大。

一旦位置 1 采样出“of”，该头就会提升“course”并抑制“problem”。一个可选的 RNN 头会跟踪整个块前缀，但仅带来边际收益，因此默认使用马尔可夫头。

收益按位置逐步显现。DSpark 继承了并行主干的高首位 token 准确率，随后顺序头在块深处保持稳定的接受率。

训练冻结目标模型，并复用其嵌入和输出头。总变差损失是关键项，直接最小化该距离可以最大化起草的接受率。

工作原理：置信度调度的验证

更多的草稿 token 并不总是意味着更快的速度。在负载较重时，验证将被拒绝的 token 会浪费批处理容量。DSpark 增加了两个部分来解决这个问题。

一个置信度头为每个草稿位置输出一个分数，估计该 token 在给定已接受的前缀后通过验证的概率。它由分析出的每步接受率进行监督。

原始神经置信度通常过于自信，因此研究团队应用了顺序温度缩放——一种事后校准步骤，将期望校准误差从 3–8% 降低到大约 1%。

然后，一个硬件感知的前缀调度器为每个请求设置验证长度。它使用一个在启动时测量一次的性能曲线 SPS(B)。当 GPU 空闲时，它验证更多的 token；当 GPU 繁忙时，它验证更少的 token。

调度器使用一个提前停止规则来保持无损。附录部分给出了一个反例，说明为什么朴素的全局搜索会泄露信息。

指标

离线测试涵盖数学、代码和日常对话。目标包括 Qwen3-4B、8B、14B 和 Gemma4-12B。DSpark 在每个领域的接受长度上都优于两个基线。

与 Eagle3 相比，在三个 Qwen3 尺寸上，宏观平均接受长度分别提升了 30.9%、26.7% 和 30.0%。与 DFlash 相比，增益为 16.3%、18.4% 和 18.3%。一个 2 层的 DSpark 甚至击败了一个 5 层的 DFlash。

顺序头带来的成本很小。将草稿长度从 4 扩展到 16 仅增加 0.2–1.3% 的每轮延迟。作为回报，接受长度最多提升了 30%。

生产结果来自 DeepSeek-V4-Flash 和 V4-Pro 在实时流量下的表现。基线是 MTP-1，即之前的单 token 设置。在匹配吞吐量的情况下，每位用户的速度在 Flash 上提升了 60–85%，在 Pro 上提升了 57–78%。已部署的配置是 DSpark-5，一个带有马尔可夫头的五 token 草稿块。

用例与示例

结构化工作负载受益于更长的验证。在代码生成中，接受率自然很高，调度器可以验证长前缀且浪费很少，因此编码智能体可以更快地流式输出。

开放式聊天行为则不同。一次置信度阈值扫描将聊天接受率从 45.7% 提升到 95.7%。置信度头标记出不确定的后缀 token，以便它们可以被修剪。

数学推理介于两者之间。在相同的扫描中，其接受率从 76.9% 上升到 92.5%。长步骤推理轨迹受益于稳定的深入块接受率。

高并发服务是核心用例。在中等负载下，调度器每个请求大约验证 4–6 个 token。随着并发度上升，它会削减预算以保护吞吐量。

尝试它

DeepSpec 运行分为三个阶段：数据准备、训练和评估。通过配置文件选择算法和目标模型。评估在九个数据集上对训练好的草稿检查点进行基准测试。

默认配置假设一个节点有 8 块 GPU。减少 CUDA_VISIBLE_DEVICES 以使用更少的 GPU。注意目标缓存可能很大，在 Qwen3-4B 设置下接近 38 TB。

对于生产检查点，草稿模块附加到已有的 V4 权重上。Hugging Face 卡片在 inference 文件夹中包含一个最小推理示例。无需重新训练目标模型。

DSpark 解码模拟器

查看草稿块、置信度分数和负载感知调度器如何设置接受长度。数字是示例性的，基于论文报告的行为建模。

下面的交互式演示展示了该机制。选择一个起草器、一个领域和一个 GPU 负载级别，观察草稿块、置信度分数和调度器的验证预算如何实时变化。数字是示例性的，基于论文报告的行为建模。

DSpark 解码模拟器

查看草稿块、置信度分数和负载感知调度器如何设置接受长度。数字是示例性的，基于论文报告的行为建模。

示例性模拟器——忠实于 DSpark 论文中的趋势，而非精确引擎输出。由 Marktechpost 构建 · DeepSpec

查看 论文、GitHub 和 HF 上的模型权重。

• 原文链接： marktechpost.com/2026/06...
• 登链社区 AI 助手，为大家转译优秀英文文章，如有翻译不通的地方，还请包涵～