6月份都快过完了，DeepSeek的新模型还是没影儿。不过，昨天在官网对话时，一个细节让我有些惊讶：刚敲下回车键，回答就跟流水一样哗哗地流出来了，几乎感觉不到延迟。

仔细一查，原来是DeepSeek放出了一个叫DSpark的框架。它直接把推理生成速度提升了60%到85%。这到底是个什么黑科技？

简单说，DSpark是一个“推测性解码”模块。这个思路非常巧妙：想象你是一位总工程师，每写一行代码都得亲自审批。而推测性解码的做法是，先派一个实习生快速写出几行草稿。你扫一眼，对的直接通过，错了再自己动手改。这样一来，审批次数从100次直接降到20次。这个框架的核心，就是找来一个轻量的“草稿模型”快速生成候选token，然后让大模型批量做验证。

---

两个关键创新点

投机解码本身算是个老概念了。但真正把它做到生产环境里大规模部署，DSpark确实做了两件以前没人搞定的事。

第一件：半自回归生成架构

传统的草稿模型泾渭分明地分成两派。一派是“并行派”，一次猜一整排字，速度快，但后面的字容易跑偏。另一派是“串行派”，一个字一个字地猜，准确率高，但速度慢。DSpark的策略就一个字：我全都要。它主体上依然是并行生成。但在每个小模块（block）内部，让token之间先互相确认一下再输出。这样既保留了并行的速度，又把错误率降下来了。

第二件：置信度调度验证

原来的投机解码有个通病：草稿猜出来的字，无论好坏，全都得送进大模型去验证。但在高并发的时候，GPU算力是最金贵的资源。如果一堆大概率会被退货的字也排着队去验证，那就是赤裸裸的算力浪费。DSpark为此加了一个“置信度头”。让草稿在猜字的同时，给每个字打个分——这个字活下来的概率有多大？接着，一个实时调度器会监控着GPU的负载情况，动态决定这次到底要验证几个字。高负载时少验，保住整体吞吐量；低负载时多验，榨干单个请求的性能。它根据当前那几毫秒的硬件状态，为每个请求量身定制最优方案。

---

架构如何运作

DSpark 架构图

我们来看一下它的工作流程：

• 步骤1：目标模型先走一步，生成第一个token D，作为草稿阶段的“锚点”。
• 步骤2：以D为输入，DSpark启动并行主干网络，一口气生成草稿token EFGH。同时通过轻量级的串行头，计算每个token的置信度c1-c4。
• 步骤3：硬件感知的前缀调度器（Hardware-Aware Prefix Scheduler）评估这些置信度，决定哪些保留，哪些丢掉。从图上可以看到，EF被保留了，G被拒绝，H直接丢弃。最后，目标模型并行验证被调度的前缀。E和F顺利通过，G被拒后模型生成修正版G*来完成这一轮。整个流程不断循环，每轮都有新token被确认。

---

实测数据

相比前一代的单Token基准（MTP-1），在维持总体吞吐量不变的情况下：

• Flash模型：生成速度提升 60%-85%
• Pro模型：生成速度提升 57%-78%

和其他投机解码方案（在Qwen3系列4B、8B、14B上的测试）相比：

• 比Eagle3提升 26.7%-30.9%
• 比DFlash提升 16.3%-18.4%

这里有个关键指标叫“平均接受长度”。它衡量的是草稿模型生成的token中有多少被目标模型采纳。接受率越高，无效计算就越少，速度自然越快。DSpark已经部署在官网，也难怪我昨天跟它对话时，感觉它几乎是不假思索就开始回答了。

为了实现这种效果，DSpark的调度器采用了异步机制。它兼容零开销调度（ZOS）和连续CUDA图回放。它利用前两步的历史预测来决定当前的动态截断长度。这样一来，既隐藏了调度延迟，又避免了GPU流水线停顿。同时，它保证了目标模型输出分布的完全无损还原。

在涵盖数学推理、代码生成和日常对话等多个领域的测试中，DSpark大幅超越了目前最先进的自回归模型（Eagle3）和并行草稿模型（DFlash）。例如，在Qwen3系列（4B、8B、14B）目标模型上，其平均接受长度比Eagle3提升了26.7%到30.9%，比DFlash提升了16.3%到18.4%。

图片

相比于前一代部署的单Token生产基准（MTP-1），在维持相同总体吞吐量的情况下，DSpark将用户的生成速度分别提升了60%-85%（Flash模型）和57%-78%（Pro模型）。

图片

图8 | 负载自适应吞吐量和验证预算。顶行（a，b）展示了不同系统并发水平下的聚合输出吞吐量；底行（c，d）展示了每个请求分配的平均目标验证预算。随着并发负载的增加，动态调度器会自动限制每个请求的验证长度，以防止资源争用。

---

配套基础设施：DeepSpec

和DSpark一起开源的还有DeepSpec。这是一个训练和评估投机解码草稿模型的全栈代码库。它把整体流程拆成三个阶段：数据准备、训练、评估。

数据准备阶段需要下载提示词数据，用推理引擎对目标模型重新生成答案，并构建好目标缓存。

训练阶段可以通过一段简单的bash脚本启动。脚本会调用train.py，并为每张可见GPU启动一个工作进程。用户可以通过指定config_path，在config/目录下选择不同算法和目标模型配置。项目也支持覆盖配置路径和缓存目录，以及使用--opts修改单个配置字段。

在硬件方面，DeepSpec的默认配置面向单节点8卡环境。如果GPU数量较少，需要相应调整可见GPU数量。

评估阶段则通过另一个bash脚本启动。它会使用训练好的草稿模型，在多个投机解码基准任务上进行测试。目前列出的评估数据集涵盖了数学推理、代码生成、对话能力和综合问答等不同类型。

项目内置了三种草稿模型：DSpark、DFlash、Eagle3。支持的目标模型系列有Qwen3和Gemma。需要注意，以Qwen3-4B配置为例，目标缓存体积大约38TB。准备跑之前，得先评估一下存储资源是否充裕。

DeepSpec的价值在于，它将此前散落在各家团队内部的工程经验，收拢成了一套标准化工具链。对于想给自己的模型加速推理的团队而言，这意味着可以直接在成熟框架上训练定制草稿模型，跳过大量重复的基础设施搭建工作。

---

最后

观察最近各家大模型的更新路径，能发现一个有趣的分化。DeepSeek似乎在围绕大模型的技术底座做深度优化。而其他家更多地在往应用下游发力，比如通过后训练让Agent能做更多现实世界的任务。像阿里的语言世界模型、智谱让大模型持续长时间运行来执行复杂任务，都是这个方向的代表。

这种状态其实挺有意思。国内各家在不同的方向投入资源，且都保持开源。这样一来，每个模型团队在训练时都能各取所长。任何一家的技术突破，都会迅速变成全行业的“公共养料”。大家默契地打着一场分布式攻坚战，合力追赶国际前沿水平。

你也在等DeepSeek的新模型发布吗？欢迎评论区聊聊。

参考资料

技术报告：《DSpark: Confidence-Scheduled Speculative Decoding with Semi-Autoregressive Generation》

GitHub：https://github.com/deepseek-ai/DeepSpec/blob/main/DSpark_paper.pdf