DeepSeek DSpark：推测性解码使LLM推理提速超80%

近期全球AI领域的地缘政治博弈持续升级，伴随美国政府对Anthropic和OpenAI的新型号模型推出使用限制，中国开源AI领域的代表性企业DeepSeek再度发布全新开源方案，有望再次为全球AI开发赛道带来新的变量。

就在近期，该公司正式推出了DSpark，一款采用MIT宽松开源协议的新型系统，核心目标是在不改变底层大语言模型原有输出逻辑的前提下，大幅提升模型的文本生成速度。

我们可以用一个直观的类比来理解这套系统的运作逻辑：绝大多数主流AI聊天机器人的文本生成过程，就像行人踩着 stepping stone 缓慢过河，每次只能迈出一小步，逐字逐句地拼凑出完整内容。而DSpark则为整个系统配备了一名先遣侦察兵，提前预判数步可能的前进路径，让主模型可以快速验证这些预判是否合理。当预判准确时，主模型就能直接跳过多个步骤快速推进；如果预判出现偏差，DSpark也会主动避免在无效的验证环节浪费计算资源。

DeepSeek同步公开了这项技术的学术论文、模型权重文件，以及名为DeepSpec的代码库，该代码库专门用于训练和评估投机解码类系统。整套开源资源都采用了MIT开源协议，开发者、科研人员以及有需求的商业企业都可以自由使用、学习和改造这项技术。

这套系统直击当前AI部署中成本最高昂的痛点之一：如何在为真实用户提供快速服务的同时，高效利用硬件资源，让商业化落地的经济模型成立。这一点对于消费级聊天机器人、编码辅助工具、智能代理工作流以及企业级AI系统尤为重要——用户期待长内容可以流畅快速地流式输出，而非逐字缓慢地“挤”出来。

目前DeepSeek已经将DSpark框架应用到了其最新的开源旗舰模型系列DeepSeek-V4中，包括已经过速度优化的2840亿参数混合专家模型DeepSeek-V4-Flash（激活参数130亿），以及更强大的1.6万亿参数模型DeepSeek-V4-Pro（激活参数490亿），两款模型均支持最长100万token的上下文窗口。

不过这项技术的更大意义在于，DSpark并非只能适配DeepSeek自家的V4系列模型。根据DeepSeek公开的测试结果和模型权重，这套方案已经覆盖了多个主流开源模型家族，包括阿里巴巴开源的Qwen系列以及谷歌开源的Gemma系列。这意味着运行开源权重模型的企业团队，原则上可以为自己的目标模型训练或微调适配的DSpark风格草稿模块——当然这并非任何API用户都可以直接一键开启的功能，只有当企业完全掌控模型权重和服务栈时，才能将这套方案迁移到其他模型上。

实测性能：看得见的速度提升

在DeepSeek的实际生产环境测试中，DSpark为DeepSeek-V4-Flash带来了51%的总吞吐量提升，该测试设定的目标是每秒为每个用户提供80个token；而在DeepSeek-V4-Pro上，总吞吐量提升达到了52%，测试目标为每秒每个用户35个token。在相同的系统容量下，相比此前的MTP-1生产基线，V4-Flash的单用户生成速度提升了60%至85%，V4-Pro则提升了57%至78%。

不同的速度数据衡量的是不同的维度：60%至85%和57%至78%这两组数据，描述的是在相同的实际系统容量下，单个用户收到生成token的速度提升幅度，这也是更贴近用户实际体验的指标。而DeepSeek还公布了更高的661%和406%的提升幅度，这两组数据衡量的是在更严格的速度目标下的总吞吐量：V4-Flash的目标是每秒每个用户120个token，V4-Pro则是50个token每秒。

在这类严格的速度目标下，旧的MTP-1基线已经接近性能瓶颈，只能维持少量并发请求来保证响应速度。而DSpark则有效避免了这种性能崩塌，因此总系统输出的百分比差异会变得更大。简单来说，85%这个数字更贴近“用户实际感受到的速度提升”，而661%和406%则更接近“在旧系统已经瓶颈的情况下，新系统还能承载的额外流量”。

溯源：投机解码的发展与DSpark的创新

大语言模型通常都是逐token生成文本的，一个token可以是一个单词、单词的一部分、标点符号或者其他小型文本片段。每一个新生成的token都依赖于已经生成的上下文，因此模型必须不断暂停、检查完整的上下文，再选择下一个片段。这种方式虽然准确，但速度较慢，就像每写一个词都需要资深编辑审核一遍，即便编辑能力出色，整个流程也会成为明显的瓶颈。

投机解码技术正是为了解决这个瓶颈而诞生的，早在Transformer早期就已经出现。与让主模型逐token生成不同，这套系统会使用一个更小、更轻量的草稿组件来预判多个可能的下一个token，然后由主模型并行验证这批预判结果。如果草稿预判准确，系统就能一次推进多个token；如果预判出现错误，系统会直接抛弃错误的token以及后续的错误内容，添加一个修正后的token后再次尝试。

这项技术的核心目标是在不改变主模型输出意图的前提下提升生成速度。在标准的投机解码流程中，草稿模型并不会替代主模型，更像是一名助理，先准备好一个粗略的下一段内容，供主模型审核通过或驳回。

这项技术并非随着当前的大语言模型突然出现，早在2018年就有了关键的先驱研究：Mitchell Stern、Noam Shazeer和Jakob Uszkoreit提出了针对深度自回归模型的块并行解码方法，该方法可以并行预判多个未来步骤，然后保留主模型验证通过的最长前缀，这篇论文奠定了后续投机解码工作中的“草稿-验证”核心逻辑。

到了2022年，这项研究路线变得更加清晰：Heming Xia、Tao Ge等人推出了SpecDec，一种用于序列到序列生成的草稿验证方法；同年晚些时候，Yaniv Leviathan、Matan Kalman和Yossi Matias发布了《通过投机解码实现Transformer的快速推理》，为基于Transformer的语言模型定义了现代版本的投机解码技术；2023年，DeepMind的研究人员又推出了 closely 相关的投机采样方法。

这些2022和2023年的论文，奠定了当前大语言模型推理领域中投机解码的主流讨论框架：通过更快的草稿流程预判token，再由主模型并行验证，同时保证主模型的输出分布不变。从那之后，这个领域快速发展出了多种变体，包括独立草稿模型、多token预测头、基于树的验证、特征级方法如EAGLE、自我预判、Medusa风格的额外头，以及像DFlash这样的并行/块级草稿器。

投机解码的核心指标并非草稿模型能预判多少个token，而是主模型实际接受多少个预判的token。只有当足够多的预判token通过验证时，更长的预判块才能真正提升速度，否则系统会在检查预判结果上浪费计算资源，最终得不偿失。

这也正是DSpark的研发背景：在DeepSeek发布之前，投机解码已经是一项成熟的推理技术，主流的服务栈都已经支持，同时也有多个竞争的研究方案，但这个领域仍然没有被完全解决。速度提升的效果很大程度上依赖于草稿模型、工作负载、服务设置和当前的流量水平。DSpark的贡献在于同时优化了这个权衡的两个方面：它不仅能生成更连贯的token块，还能只验证在实际服务场景中最有可能通过的部分预判结果。

两大核心优化：解决预判与验证的矛盾

DSpark主要解决了两个相关的问题：不准确的预判和浪费的验证资源。

首先，这套系统采用了DeepSeek称之为半自回归生成的技术。用通俗的话来说，就是DSpark尝试在速度和对序列的感知能力之间找到最佳平衡。

完全并行的草稿器可以一次预判多个token，速度很快，但后续的预判可能会变得不够连贯，因为每个位置的预测都过于独立。而完全逐步骤的草稿器可以更好地跟踪token之间的先后关系，但会失去大部分的速度优势。

DSpark尝试兼顾两者的优点：它使用并行主干来完成大部分的草稿工作，然后添加一个轻量的串行头部，让草稿可以考虑到相邻token之间的关系。在论文的示例中，完全并行的草稿器可能会混淆“of course”和“no problem”这类常见的短语结尾，生成 awkward 的组合，因为它对每个位置的预测过于独立。而DSpark的串行组件可以帮助系统让后续的token更好地适配前面的内容。

其次，DSpark加入了置信度调度验证机制。与始终要求主模型检查固定数量的草稿token不同，DSpark会估算草稿中哪些前缀最有可能通过验证，然后基于模型的置信度和当前的服务负载，由硬件感知的调度器来调整每个草稿需要验证的部分。

我们可以用餐厅的场景来类比：当餐厅客流量少时，主厨可以检查更多 prep cook 准备的菜品；当厨房繁忙时，主厨只会把精力放在最有可能按时出餐的菜品上。DSpark将这个思路应用到了AI服务中：在流量较轻的情况下，系统可以负担得起检查更长的草稿前缀；而在流量较大的情况下，系统会在低置信度的尾部预判消耗批量容量之前就将其裁剪掉，避免占用其他用户的资源。

DeepSeek将这个设计看作是对常见生产权衡问题的解决方案：静态的多token草稿在单独测试时看起来很有吸引力，但在高并发场景下反而会降低吞吐量，因为系统会持续检查那些大概率会被驳回的token。而DSpark的调度器让验证预算变得灵活，而非固定不变。

跨模型验证：Qwen与Gemma上的出色表现

DeepSeek在Qwen3-4B、Qwen3-8B、Qwen3-14B以及Gemma4-12B等目标模型上进行了离线测试，测试涵盖了数学、编码和聊天三类基准任务。

在这些测试中，团队将DSpark与DFlash（并行草稿器）和Eagle3（自回归草稿器）进行了对比，论文中采用的衡量指标是每轮解码的平均接受token长度，也就是平均有多少个预判token能通过主模型的验证。

在三款Qwen3模型上，DSpark相比Eagle3的宏平均接受长度分别提升了30.9%、26.7%和30.0%；相比DFlash，则分别提升了16.3%、18.4%和18.3%。论文还提到，这些性能提升同样适用于Gemma4-12B模型。

这一结果也印证了开发者Daniel Han在社交平台上提出的观点：DeepSeek展示了DSpark不仅能在自家的V4模型上生效，还能适配Gemma和Qwen等其他开源模型。当然，社区的反馈只是辅助佐证，更有力的证据还是DeepSeek自身的基准测试和公开的模型权重。

离线测试结果也解释了为什么工作负载会影响性能：结构化任务如数学和编码，通常比开放式聊天拥有更高的接受token长度，这符合直觉——代码补全或数学步骤通常比自由对话拥有更少的合理下一步选择。

对于企业来说，这意味着DSpark风格的方法特别适合编码辅助工具、数据分析代理、结构化工作流自动化以及其他输出模式更可预测的场景。

企业落地：无需依赖DeepSeek-V4的可行方案

一个最受关注的问题是：DSpark是否只能用于DeepSeek自家的模型，还是可以推广到其他模型？答案是：这是一种通用方法，但并非可以直接一键安装的插件。

对于开源权重模型，落地路径相对清晰：如果企业自行托管Qwen、Gemma、Llama、Mistral、Granite、Command等开源模型，就可以针对目标模型训练或微调适配的DSpark风格草稿模块。之后，团队需要在自身的工作负载上测试接受度，并将验证调度器集成到自己的推理栈中。

这与直接下载DeepSeek的DSpark模块并附加到任意模型上是不同的：投机解码依赖于草稿模块和目标模型之间的对齐，草稿必须学习目标模型的预判偏好。为DeepSeek-V4训练的草稿器，并不会自动适配其他模型，尤其是那些经过企业内部数据微调或针对特定推理行为优化的模型。

DeepSpec的工作流程也体现了这一点：整个流程包括数据准备、重新生成目标模型的回答、构建目标缓存、训练草稿模型以及评估投机解码的接受度。针对特定领域的使用场景，草稿模型可能还需要额外的微调，尤其是当目标模型运行在特定的思考或推理模式下时。

对于专有模型，能否使用DSpark则取决于企业的掌控程度：如果企业拥有或完全托管模型权重和服务栈，理论上可以训练和部署DSpark风格的草稿器；如果模型只能通过厂商的托管API访问，那么客户无法直接从外部添加DSpark。API提供商可以在内部实现类似的优化，但客户通常无法访问token验证循环、logits、批处理行为或服务调度器这些实现DSpark所需的核心组件。

这种区分对于企业买家来说非常重要：DSpark进一步强化了开源或自托管AI基础设施的优势，因为它为高级团队提供了另一个提升速度和成本效益的工具。但这也说明了为什么模型服务正在成为一个专业化的领域：价值不仅在于选择合适的模型，更在于如何智能地运行这些模型。

开发者工具箱：DeepSpec的价值与局限

对于开发者来说，DeepSpec提供了一个具体的训练和评估投机解码草稿模型的实现路径。它包含了数据准备、训练和基准评估的步骤，同时还公开了多个开源模型家族的模型权重。这使得这次开源发布不仅能让DeepSeek-V4配合DSpark使用，还能帮助科研人员和基础设施团队研究如何为其他开源模型添加更快的解码功能。

不过这套工具也有实际的部署限制：DeepSpec的自述文件提到，默认的Qwen3-4B数据准备设置需要大约38TB的目标缓存存储，而默认脚本假设使用带有8个GPU的单节点。这意味着这套发布更适合AI实验室、云服务团队和成熟的企业AI基础设施团队，而非普通的应用开发者。

尽管如此，公开训练管线仍然具有重要意义：许多推理优化技术只以论文、模糊的基准测试或封闭的生产声明的形式存在，而DeepSpec为开发者提供了更接近蓝图的资源——它并非现成的企业级产品，而是一套可以复现、适配和评估该方法的工具。

社区实测：真实场景下的表现

此次发布已经吸引了开发者的快速关注。开发者Rafael Caricio在代码托管平台提交了一个拉取请求，记录了单流DeepSeek-V4-Flash配合DSpark的测试结果：在预热后的基准测试中，未使用投机解码时的速度为26.33 tokens每秒，使用MTP-1时为39.88 tokens每秒，而使用DSpark时则达到了约60 tokens每秒——相比MTP-1提升约1.5倍，相比未使用投机解码的情况提升2.3倍。

后续的一次提交记录了五次测试的平均值为60.31 tokens每秒，相比MTP-1提升1.51倍，相比非投机解码提升2.29倍。

这项测试也指出了一个重要的实际限制：在真实的多轮编码会话中，随着上下文长度增加，草稿的接受度会下降，性能也会随之降低。换句话说，DSpark可以提升解码速度，但最终能实现多少速度提升，仍然取决于预判的接受质量。

这是一个很实用的现实校验：DSpark并非魔法，它仍然依赖于下一个token的可预测性，以及草稿模型与目标模型的对齐程度。但早期的实现工作表明，DeepSeek的声明并非纯学术研究，开发者已经在实际的服务环境中测试了这套方法，并报告了接近论文中单流测试预期的性能提升。

行业启示：推理层的下一场竞争

DSpark展示了，即便底层模型架构保持不变，推理层仍然存在大量的性能提升空间。随着AI企业在模型质量、上下文长度和定价上展开竞争，解码效率正在成为另一个重要的战场。

更快的生成速度意味着更低的用户延迟、更高的服务提供商吞吐量，以及大规模部署开源模型时更好的经济效益。

DeepSeek的此次发布之所以引人注目，是因为它结合了经过生产测试的方法、开源代码、公开的模型权重和详细的学术论文。其核心创新并非只是预判更多的token，而是让系统更有选择性地去验证那些最值得投入计算资源的投机预判。

对于企业团队来说，更广泛的启示是：AI性能的下一波增长并非只来自更大的模型，还来自更智能地运行企业已经拥有的模型——尤其是当企业能够完全掌控技术栈，包括调整模型、训练适配的草稿模块，并针对实际工作负载优化服务引擎时，这种优化的效果会更加显著。