DeepSeek开源DSpark，一个可将LLM推理速度提升高达85%的新框架（阅读时间18分钟）

# DeepSeek 开源 DSpark，一个可将大语言模型推理速度提升高达 85% 的新框架 来源：https://venturebeat.com/orchestration/deepseek-open-sources-dspark-a-new-framework-to-speed-up-llm-inference-by-up-to-85 尽管围绕 AI 的地缘政治讨论因美国政府限制 Anthropic (https://venturebeat.com/technology/anthropic-blocks-all-public-access-to-claude-fable-5-mythos-5-following-us-government-order-what-enterprises-should-do) 和 OpenAI (https://venturebeat.com/technology/openai-unveils-gpt-5-6-sol-terra-and-luna-models-but-only-accessible-to-limited-preview-partners-for-now-per-us-gov) 新模型而愈发紧张，但中国的开源宠儿 DeepSeek 再次发布开源成果，这可能会再次改变全球的 AI 开发格局。 上周末，该公司发布了 DSpark (https://huggingface.co/deepseek-ai/DeepSeek-V4-Pro-DSpark)，这是一个采用 MIT 许可的新系统，旨在让大语言模型回答更快，同时不改变底层模型想要表达的内容。 理解它的最简单方式是：大多数 AI 聊天机器人写作就像一个人涉水过河，一次踩一块石头。它们先选择一小块文本，然后是下一块，再下一块。 DSpark 为系统配备了一个“侦察兵”，它提前跑几步，猜测可能的路径，然后让更大的模型快速检查哪些步骤是安全的。当猜测正确时，模型移动得更快。当猜测不准确时，DSpark 会尽量避免浪费时间检查它们。 DeepSeek 发布了这项工作的技术论文 (https://github.com/deepseek-ai/DeepSpec/blob/main/DSpark_paper.pdf)、模型检查点和 DeepSpec (https://github.com/deepseek-ai/DeepSpec)——一个用于训练和评估推测解码系统的代码库。该版本可通过 DeepSeek 的公共 GitHub (https://github.com/deepseek-ai) 和 Hugging Face (https://huggingface.co/deepseek-ai/DeepSeek-V4-Pro-DSpark) 页面获取，均采用宽松、友好且常见的 MIT 许可，使这项新技术能被开发者、研究人员和希望研究或采用该方法的商业企业运营广泛使用。 该系统针对 AI 部署中最昂贵的问题之一：在硬件效率足够高的前提下，快速服务于大型模型以满足真实用户需求。这对于消费级聊天机器人、编码助手、代理工作流以及企业 AI 系统至关重要，因为这些场景中用户期望长答案能快速流式输出，而非逐字缓慢生成。 DeepSeek 正在将 DSpark 应用于其最新的前沿开源模型 DeepSeek-V4 (https://venturebeat.com/technology/deepseek-v4-arrives-with-near-state-of-the-art-intelligence-at-1-6th-the-cost-of-opus-4-7-gpt-5-5)。 具体来说，DeepSeek 在其新的 DSpark 框架上应用于 DeepSeek-V4-Flash（一个已有速度优化的 2840 亿参数混合专家模型，拥有 130 亿激活参数）和 DeepSeek-V4-Pro（一个更慎重且更强大的 1.6 万亿参数模型，拥有 490 亿激活参数，两者均支持高达 100 万 token 的上下文窗口）。 但更广泛的意义在于，DSpark 在概念上并不局限于 DeepSeek-V4。DeepSeek 自己的测试和发布的检查点覆盖了其他开源模型家族，包括阿里巴巴开源权重的 Qwen 和谷歌开源权重的 Gemma。 这意味着运行开源权重模型的企业团队，原则上可以为自己目标模型训练或微调 DSpark 风格的草稿模块。这不是任何 API 客户可以从外部打开的一个开关，但当操作者控制权重和服务堆栈时，这是一种可以迁移到其他模型的方法。 VB Transform · 7月14-15日 · 门洛帕克 · 代理编排 Intuit 在 60 天内重建了其多代理系统。他们改变了什么——以及为什么？ 在 Transform 大会上，来自 Intuit、Target 和 Instacart 的工程负责人将详细剖析他们如何为可靠性、规模和真实客户重新设计编排架构。 查看完整议程 → (https://venturebeat.com/vbtransform2026) ## **推理期间生成 token 的惊人速度提升** 在 DeepSeek 的实时生产测试中，对于 DeepSeek-V4-Flash（每个用户每秒 80 token 的服务目标），DSpark 将总吞吐量提升了 51%；对于 DeepSeek-V4-Pro（每个用户每秒 35 token 的目标），提升了 52%。在匹配的系统容量下，DeepSeek 报告称，相对于之前的 MTP-1 生产基线，每个用户的生成速度提升：V4-Flash 为 60% 到 85%，V4-Pro 为 57% 到 78%。 不同的速度指标衡量不同的事物。V4-Flash 的 60% 到 85% 以及 V4-Pro 的 57% 到 78% 描述的是，当 DeepSeek 在匹配的实际系统容量下将 DSpark 与 MTP-1 进行比较时，单个用户接收生成 token 的速度有多快。 DeepSeek DSpark 技术白皮书速度提升截图 来源：DeepSeek，《DSpark: Confidence-Scheduled Speculative Decoding with Semi-Autoregressive Generation》 这些是更清晰的“生成速度”数据。DeepSeek 还报告了更大的 661% 和 406% 的提升，但这些衡量的是在非常严格的速度目标下的总吞吐量：V4-Flash 为每个用户每秒 120 token，V4-Pro 为每个用户每秒 50 token。 在这些目标下，DeepSeek 表示其旧的 MTP-1 基线接近运营悬崖，意味着它只能保持少量并发请求运行，同时维持该级别的响应能力。 DSpark 避免了更多这种崩溃，因此总系统输出量的百分比差异变得更大。简单来说：85% 的数字更接近于“在可比条件下用户感觉体验快了多少”，而 661% 和 406% 的数字更接近于“当旧系统已经瓶颈时，道路还能承载多少额外流量”。 ## **为什么推测解码很重要** LLM 通常一次生成一个 token。一个 token 可以是一个词、词的一部分、标点符号或其他小块文本。每个新 token 依赖于已生成的文本，因此模型必须不断暂停、检查完整上下文并选择下一个部分。 这很准确，但很慢。这就像让一位资深编辑在作者继续下一步之前审批每一个词。编辑可能很出色，但这个过程造成了瓶颈。 推测解码（Speculative decoding）发展于早期的 Transformer 时代，试图解决这个瓶颈。系统不是要求大模型逐个生产每个 token，而是使用一个更小或更轻量的草稿组件来建议几个可能的后续 token。然后大模型并行检查这批猜测。如果草稿猜对了，系统会一次前进多个 token。如果草稿猜错了，系统拒绝错误的 token 及其后面的内容，添加一个纠正后的 token，然后重试。 关键在于在不改变大模型预期输出的前提下提高速度。在标准的推测解码设置中，草稿模型并不是替代目标模型。它更像一个助手，为资深编辑准备一个粗略的下一句话供批准或拒绝。 这个想法并非随着今天的大语言模型凭空出现。一个关键先驱出现在 2018 年 (https://arxiv.org/abs/1811.03115)，当时 Mitchell Stern、Noam Shazeer 和 Jakob Uszkoreit 为深度自回归模型提出了块级并行解码。他们的方法并行预测多个未来步骤，然后保留由主模型验证的最长前缀。那篇论文奠定了后来推测解码工作中草稿与检查的大部分直觉。 这一研究方向在 2022 年变得更加明确。夏鹤鸣、Tao Ge 及其合著者引入了 SpecDec (https://arxiv.org/abs/2203.16487)，一种用于序列到序列生成的草稿与验证方法。同年晚些时候，Yaniv Leviathan、Matan Kalman 和 Yossi Matias 发布了《通过推测解码实现 Transformer 快速推理》(https://arxiv.org/abs/2211.17192)，帮助定义了该技术针对基于 Transformer 的语言模型的现代版本。DeepMind 研究人员在 2023 年跟进了一种密切相关的称为推测采样的方法 (https://arxiv.org/abs/2302.01318)。 这些 2022 年和 2023 年的论文是当前 LLM 推理工作中讨论推测解码最清晰的源头：一个更快的草稿过程提出 token，更大的目标模型以旨在保留目标模型输出分布的方式进行验证。 此后，该领域通过几个变体迅速发展，包括独立的草稿模型、多 token 预测头、树状验证、特征级方法如 EAGLE (https://arxiv.org/abs/2401.15077)、自推测、Medusa 风格的额外头以及并行/块级草稿器如 DFlash。 关键指标不是草稿模型能猜对多少 token，而是大模型实际接受了多少这些猜测。只有足够多的提议 token 通过验证，长的推测块才有帮助。否则，系统会花费计算资源检查最终被丢弃的猜测。 这就是 DSpark 出现的背景。在 DeepSeek 发布之前，推测解码已经是一种成熟的推理技术，得到了主要服务堆栈的支持，并有多种竞争的研究方法。但它仍然不是一个已解决的问题。加速效果高度依赖于草稿模型、工作负载、服务设置和当前的流量水平。DSpark 的贡献在于改进权衡的两方面：它试图草稿出更连贯的 token 块，然后在实际服务条件下只验证这些块中可能产生回报的部分。 ## **DSpark 改变了什么** DSpark 解决两个相关问题：糟糕的猜测和浪费的检查。 首先，该系统使用了 DeepSeek 所谓的半自回归生成。简单来说，这意味着 DSpark 试图将速度与对序列的更多感知结合起来。 完全并行的草稿器可以一次猜测多个 token，速度很快，但其后面的猜测可能变得不太连贯，因为每个位置是过于独立预测的。纯粹的逐步草稿器可以更好地跟踪一个 token 如何导向下一个，但它失去了大部分速度优势。 DSpark 试图保留两者的优点。它使用并行主干完成大部分草稿工作，然后添加一个轻量级的顺序头，让草稿考虑相邻 token 之间的关系。在论文的例子中，并行草稿器可能会混淆可能的短语结尾，如“of course”和“no problem”，产生笨拙的组合，因为它是过于分开地猜测位置。DSpark 的顺序组件帮助系统使后面的 token 贴合前面的 token。 其次，DSpark 增加了置信度调度的验证。DSpark 不是总要求目标模型检查相同数量的草稿 token，而是估计草稿的哪个前缀可能存活。然后，一个硬件感知调度器根据模型置信度和当前服务负载调整每个草稿应被验证的比例。 一个简单的类比：当餐厅安静时，主厨可以检查更多预备厨师的工作。当厨房忙碌时，主厨只关注最可能准备好的菜肴。DSpark 将类似的想法应用于 AI 服务。在流量较轻时，系统可以负担检查更长的草稿前缀。在流量较重时，它会修剪低置信度的尾部猜测，以避免消耗本可用于其他用户的批量容量。 DeepSeek 将此视为对常见生产权衡的回应。静态的多 token 草稿在孤立看起来可能很有吸引力，但在高并发下会损害吞吐量，因为系统一直在检查可能被拒绝的 token。DSpark 的调度器使验证预算变得灵活而不是固定。 ## **离线结果：在 Qwen 和 Gemma 上更好的草稿接受率** DeepSeek 在 Qwen3-4B、Qwen3-8B、Qwen3-14B 和 Gemma4-12B 目标模型上，在数学、编码和聊天基准测试中进行了离线测试。 在这些测试中，团队将 DSpark 与并行草稿器 DFlash 以及自回归草稿器 Eagle3 进行了比较。论文报告了每个解码轮次的接受长度，这是衡量平均有多少 token 通过验证的指标。 DSpark 在 Qwen3-4B、Qwen3-8B、Qwen3-14B 和 Gemma4-12B 上相对于 Eagle3 和 DFlash 的速度提升 DSpark 在 Qwen3-4B、Qwen3-8B、Qwen3-14B 和 Gemma4-12B 上相对于 Eagle3 和 DFlash 的模型速度提升。来源：DeepSeek，《DSpark: Confidence-Scheduled Speculative Decoding with Semi-Autoregressive Generation》 在三个 Qwen3 模型尺寸上，DSpark 相对于 Eagle3 的宏观平均接受长度分别提升了 30.9%、26.7% 和 30.0%。与 DFlash 相比，接受长度分别提升了 16.3%、18.4% 和 18.3%。论文还表示，这些增益也泛化到了 Gemma4-12B。 这支持了开发者 Daniel Han 提出的观点，他在 X 上强调 DeepSeek 展示了 DSpark 在 DeepSeek 自己的 V4 模型之外，包括 Gemma 和 Qwen 上的工作。我会将 Han 作为社区反应的一部分，但并非该声明的唯一证据。更强的支持来自 DeepSeek 自己的基准测试和发布的检查点。 离线结果还显示了为什么工作负载很重要。数学和编码等结构化任务往往比开放式的聊天任务有更高的接受长度。这很直观：代码补全或数学步骤通常比自由形式的对话拥有更少的合理后续步骤。 **对于企业而言，**这意味着**DSpark 风格的方法可能对编码助手、数据分析代理、结构化工作流自动化**以及其他输出遵循更可预测模式的场景尤其有吸引力。 ## **企业如何在不使用 DeepSeek-V4 的情况下使用 DSpark** 最重要的问题之一是 DSpark 是 DeepSeek 专属优化，还是一种可应用于其他模型的更广泛方法。答案是：更广泛的方法，但并非自动即插即用。 对于开源权重模型，路径相对清晰。运行 Qwen、Gemma、Llama、Mistral、Granite、Command 风格开源权重或其他自托管模型的企业，可以针对该目标模型训练或微调一个 DSpark 风格的草稿模块。 然后团队需要在其自身工作负载上衡量接受率，并将验证调度器集成到其推理堆栈中。 这与简单地下载 DeepSeek 的 DSpark 模块并将其附加到任何模型上不同。推测解码依赖于草稿模块和目标模型之间的对齐。草稿模块必须学习目标模型可能接受什么。为 DeepSeek-V4 训练的草稿器不会自动成为不同模型的正确草稿器，尤其是当该模型已经在公司内部数据上微调过或配置了不同的推理行为时。 DeepSpec 的工作流程反映了这一点。过程涉及准备数据、重新生成目标模型的回答、构建目标缓存、训练草稿模型以及评估推测解码接受率。对于特定领域的用途，草稿模型可能需要额外的微调，特别是如果目标模型以思考或推理模式运行时。 对于专有模型，答案取决于企业控制什么。如果公司拥有或完全托管模型权重和服务堆栈，理论上它可以训练和部署 DSpark 风格的草稿器。如果模型仅通过供应商的托管 API 可用，则客户无法从外部直接添加 DSpark。API 提供商可以在内部实现类似的优化，但客户通常无法访问使 DSpark 工作所需的 token 验证循环、logits、批处理行为或服务调度器。