DeepSeek 在开源路线上再落一子。这家正大规模扩张团队的 AI 公司，今日与北京大学团队联合发布论文，推出新的大模型推理加速框架 DSpark，并已将其部署到 DeepSeek-V4-Flash preview 和 DeepSeek-V4-Pro preview 的生产服务中，替代此前的 MTP-1 方案。
线上真实用户流量的测试数据显示，在系统总吞吐水平相同的情况下，DSpark 将 V4-Flash 的单用户生成速度提升了 60% 至 85%，将 V4-Pro 的单用户生成速度提升了 57% 至 78%。这意味着用户在对话、代码生成等高交互场景下，等待模型回复的时间将显著缩短。
大模型生成文本的“挤牙膏”感，根源在于主流的自回归解码方式——模型每生成一个新 token，都需以前文为条件做一次前向计算，输出越长延迟越高。业界为此引入推测解码，思路是让一个轻量级草稿模型先生成候选 token，再由目标模型并行验证，从而在不改变输出分布的前提下提高生成速度。
但现有方案各有短板。自回归草稿模型虽候选质量高，但自身生成速度慢；并行草稿模型虽快，却因候选 token 间缺乏依赖关系，越往后被目标模型接受的概率越低，论文将这种现象称为后缀衰减。更关键的是，在高并发线上服务中，机械地验证固定长度的候选块会浪费目标模型的批处理容量，挤压其他用户请求。
DSpark 的解法可概括为“草稿写得更像样，审稿更会挑重点”。在生成侧，它采用半自回归架构，保留并行草稿模型的主干速度，同时在输出端加入轻量级顺序模块，让后续 token 能参考已采样 token 的衔接关系，减少后缀衰减。论文默认使用计算成本低的 Markov head 来建模相邻 token 转移关系。
在验证侧，DSpark 引入基于置信度调度的验证。系统为每个候选位置预测置信度分数，再由硬件感知前缀调度器根据当前系统负载、各位置置信度及引擎在不同批大小下的吞吐曲线，动态决定每个请求该验证多少 token。系统空闲时验证更长前缀以产出更多有效 token，负载升高时则缩短低置信度请求的验证长度，减少资源占用。
离线实验覆盖 Qwen3-4B、Qwen3-8B、Qwen3-14B 和 Gemma4-12B 四个目标模型，以及数学推理、代码生成和日常聊天三类场景。结果显示，DSpark 的宏平均接受长度相比自回归草稿模型 Eagle3 提升 26.7% 至 30.9%，相比并行草稿模型 DFlash 提升 16.3% 至 18.4%。接受长度越高，意味着草稿被大模型认可的比例越大，推理加速空间也越大。
不同任务间差异明显。以 Qwen3-4B 为例，DSpark 在数学任务上的平均接受长度为 5.57，代码任务为 5.12，聊天任务仅为 3.49。数学和代码更结构化，续写路径稳定；开放式聊天不确定性更高，候选 token 更易被拒绝。这印证了固定验证长度会浪费计算资源，动态调度确有必要。
线上部署数据更凸显 DSpark 的工程价值。在 V4-Flash 每用户每秒 80 token 的服务目标下，DSpark 较 MTP-1 将系统总吞吐提升 51%；在更严格的 120 token/s/user 目标下，MTP-1 已接近承载边界，DSpark 的名义吞吐优势达到 661%。V4-Pro 在 35 token/s/user 目标下吞吐提升 52%，在 50 token/s/user 严格目标下名义优势达 406%。
DeepSeek 同步宣布开放 DSpark 模型权重，包括 V4-Flash 和 V4-Pro 预览版对应的模型检查点，并开源了面向推测解码训练的代码库 DeepSpec，内含 Eagle3、DFlash 和 DSpark 实现。
从产业视角看，DSpark 的发布揭示了大模型推理优化的一个关键转向：单纯让草稿模型一次生成更多 token 已非最优解，如何根据任务特性与系统负载动态分配验证资源，才是提升真实服务效率的核心。这对依赖大模型 API 的应用开发者而言，意味着更低的延迟与更高的吞吐上限；对基础设施层，则指向更精细的 GPU 利用率管理。在 AI 应用加速落地的当下，推理引擎的系统工程能力正成为模型竞争力的重要一极。