「深度研究」DeepSeek 放出一个没有新模型的「发布」：吞吐飙到 400%，权重却一个字节没改

参数一点没涨，跑分也没挪窝。可同一个 DeepSeek-V4，吐字突然快了一大截。乍看像营销话术。但 2026 年 6 月 27 日凌晨那条推文，让不少工程师对着屏幕愣了几秒。

一条推文，蹦出俩吓人的数

发推的是 Unsloth 联合创始人 Daniel Han。

> DeepSeek just released DSpark for V4 Flash & Pro, a new speculative decoding method boosting throughput by 51% to 400%!

「DeepSeek 刚为 V4 Flash 和 Pro 发布了 DSpark，一种新的推测解码（speculative decoding）方法，吞吐提升 51% 到 400%！」

配的是一张信息量很足的官方海报：左边架构示意，右边表格列着「接受长度」，中间几根曲线，底部是吞吐对延迟的性能边界图。右上角还特意加粗印了一行：+51% to +400% throughput vs MTP。

推文最后看了 43.6 万次，点赞 3.6K。评论区先冒出来的，倒不是「怎么做到的」，而是一连串「这数字能信吗」。51% 和 400%，差了快八倍。同一项技术，凭什么同时甩出两个数？

答案后面给。两个数都没撒谎，只是分别站在两条完全不同的曲线上。不过拆之前，得先弄明白一件更基础的事：DeepSeek 这回，到底发布了个啥。

DeepSeek DSpark 种子推文与官方技术海报（分段 1）DeepSeek DSpark 种子推文与官方技术海报（分段 2）

▲ Daniel Han 发布的种子推文与 DeepSeek 官方海报，43.6 万次浏览，标注「+51% to +400% throughput vs MTP」

模型卡上那句加粗提醒

Hugging Face 上，DeepSeek-V4-Pro-DSpark 的模型卡页面开头，用加粗字体写着一段提醒：

> Note: DeepSeek-V4-Pro-DSpark is not a new model. It is the same checkpoint with an additional speculative decoding module attached.

「请注意：DeepSeek-V4-Pro-DSpark 用的还是原来那份 checkpoint，只是额外挂了个推测解码模块，没训新模型。」

这句话轻描淡写，却把整件事的性质给定了。V4 Pro 还是那份 1.6 万亿参数（激活约 490 亿）的混合专家模型，V4 Flash 仍是 2840 亿参数（激活约 130 亿）的版本。知识没变，能力边界没变，连脾气都没变。

真正动过手脚的，是这颗大脑往外吐字的方式。

HuggingFace 模型卡明确标注 DSpark 并非新模型 ▲ HuggingFace 模型卡：DeepSeek-V4-Pro-DSpark 被明确标注为「并非新模型」，只是原 checkpoint 挂载了推测解码模块

大模型为啥说话总这么慢

想搞懂 DSpark 干了啥，得先明白大模型平时是怎么「开口」的。

答案有点反直觉：它是一个字一个字往外蹦。每吐一个 token，模型得把自己几十上百层参数完整算一遍。业内管这叫自回归解码。

问题出在效率。生成阶段，GPU 大把时间都耗在从显存搬那几十上百 GB 的权重上，真用来算题的时间少得可怜。更像是翻书找答案，算力利用率低到让人心疼。

对策早有了，叫推测解码。找个更小更快的「草稿模型」，先斗胆猜出接下来好几个字，再让大模型一次性核对这一整段。猜对的留下，猜错的从第一个错处推倒重来。

打个比方，像老师改默写。没推测解码时，老师每次只听一个字，念完才让念下一个，时间全耗在翻词典核对上。有了它，学生先一口气写完一整句草稿，老师扫一眼，对的地方一笔勾过，错的从第一个错字起改。翻词典的成本已经付过一次，顺手多看几个字，几乎是白捡。

更关键的一点：这套流程数学上分毫不差。验证用拒绝采样，按目标模型和草稿模型的概率比例决定收还是拒，最终吐出的每一个字，分布上和大模型自己一步步生成的结果完全一致。速度变了，答案没打折扣。

三条曲线，各自的坐标系

弄懂底层逻辑，回头拆开头的「51% 到 400%」，会发现它压根不只是一个数：背后站着三条完全不同的坐标轴，量出三种结果。

论文《DSpark: Confidence-Scheduled Speculative Decoding with Semi-Autoregressive Generation》（arXiv 编号 2607.05147，由 DeepSeek-AI 与北京大学联合完成）摘要里，写得最谨慎的一句是：

> Compared to the established production baseline (MTP-1), DSpark accelerates per-user generation speeds by 60 to 85 percent at matched throughput levels.

「相较于已上线的生产基线 MTP-1，在匹配的聚合吞吐水平下，DSpark 让单个用户的生成速度提升 60% 到 85%。」

这是第一层：同样多用户在线、系统总吞吐不变的前提下，每个人感受到的生成速度快了六到八成。这数最稳，坐标系没变，谁都没占便宜。

第二层出现在中等交互目标下。比如每用户 80 token/秒的服务标准，系统能多接住的用户数，即聚合吞吐，提升约 51%。这是产能视角：同一批显卡，能同时服务更多人。

第三层最容易误读。当延迟要求严到极点，老基线会出现容量「塌方」，排队请求暴增，服务能力直线下滑。DSpark 省下了大量本该白白浪费的验证算力，还能撑住场。悬崖边的这个区间，相对提升的比值被急剧放大，406% 乃至更高的数，正是从这来的。

三条曲线，三种含义。60–85% 能写进任何严肃报告，51% 适合讲产能，400% 那一档，只在「延迟要求极严、基线已崩」的前提下才成立。脱离这个前提单拎出来说，就成了一句好听却站不住的口号。

拆开发动机盖：草稿为啥「越猜越离谱」

数字拆完，进技术细节。DSpark 到底改了啥。

DSpark 之前，推测解码大体分两派。

一派是「自回归浅层草稿」，代表 MTP、EAGLE 系列。草稿模型一个字一个字往外猜，字与字之间有清晰依赖，猜得准，但本质还是串行，草稿做不深，第一个字反而容易掉链子。

另一派是「并行草稿」，代表 Medusa、DFlash。一次前向一口气吐出整块候选，速度快得离谱，草稿延迟几乎不受块长影响。代价是块内每个位置预测相对独立，容易前言不搭后语。论文管这叫「后缀接受率衰减」：第一个字猜得挺准，越往后越离谱。

DSpark 的论文画了一张位置条件接受率曲线，把两派的毛病摆得明明白白：纯并行的草稿在第一个位置最强，之后掉得快；纯自回归的草稿全程稳，却因为串行成本，第一个位置反而没吃到该有的深度红利。

DSpark 把两派拼一块了。草稿分两段：

并行骨干先来一次前向，一口气拿到整块的隐层表示和基础 logits，把最宝贵的算力砸在第一个位置——第一个位置一旦猜错，整块草稿就废，这儿的杠杆最大。

一个极轻的顺序头紧跟其后，默认结构叫 Markov head，把「刚采样出来的上一个字」注入当前预测，缓解并行预测时各说各话的冲突。论文一句话能概括：继承并行草稿在第一个位置的优势，再补一点自回归的顺序性，换来很长的有效接受长度。

光有好草稿还不够。生产环境成败，真看验证怎么做。

高并发下，目标模型每一步要验的 token 数，大约 = 批大小 × 草稿长度，量级不小。一段几乎注定被拒的草稿还全验了，等于白白占了本该分给其他用户的计算槽位。

DSpark 给每个草稿位置配了个置信度头，输出这个位置能活到最后的概率；再用一种叫 Sequential Temperature Scaling 的校准把置信度拉准，原始误差能到 3%–8%，校准后压到 1% 左右。系统结合引擎实测的「验证速度–批大小」曲线，动态决定每个请求验多长的前缀，目标是让「接受的 token 数 × 每秒验证速度」这个乘积最大化。

翻译成大白话：系统闲时，多验一点几乎不花钱，那就往长里验；系统忙时，只验有把握的部分，省下的算力让给排队的用户。

两周之内，从论文变成能跑的服务

一篇论文算不算真的基础设施事件，不看发了多少页 PDF，看两周内有没有人真把它接进自己的服务。

DSpark 的答案是：接得飞快。

vLLM 大约 7 月 2 日宣布原生支持，配置里多了个 method: dspark 选项。官方实测：8 卡 B300 上，V4-Pro-DSpark 批大小为 1 时跑到约 250 token/秒，平均接受长度约 5，接受率比原 MTP 方案高 12%–42%。

vLLM 宣布原生支持 DSpark（分段 1）vLLM 宣布原生支持 DSpark（分段 2）

▲ vLLM 官方宣布原生支持 DSpark：8×B300 上约 250 tok/s，接受长度约 5，接受率较 MTP 提升 12%–42%

SGLang 团队 7 月 6 日发了一篇工程向长文，标题直叫《DSpark in SGLang: Speculative Decoding with Confidence-Driven, Variable-Length Verification》。他们做事很实在：不追论文数字到小数点，重点复现「曲线的形状」——同样是聚合吞吐对每用户生成速度的性能边界曲线，DSpark 全程压着 MTP 和没加推测解码的方案。为了把算法优势真变成实打实的速度，他们还搞了套「变长验证」机制：同批次里每个请求验的长度可以不同，配合 CUDA graph 按实际总 token 数分层捕获，裁剪后真跑一张更小的计算图，不是把短的补齐成长的再跑。B300 上 TP8、批大小 1，V4-Pro 跑到了 383.7 token/秒。

SGLang 博客展示 DSpark 吞吐-延迟曲线 ▲ LMSYS/SGLang 博客的 Figure 1：DSpark（橙色）在整条吞吐-延迟曲线上都压制 MTP（蓝色）与不加推测解码的方案（灰色）

最有说服力的一份证据，来自一个压根不做聊天机器人的公司。

fal 在 7 月 8 日发了篇复盘，标题《How We Achieved ~1000 tok/s and 16x Throughput with DSpark for Ideogram V4 Prompt Expander》。他们的场景是给 Ideogram V4 的图像生成流水线做「提示词扩写」：用户随手一句简单描述，模型补全成一段详细英文提示词，再喂给图像模型。这类任务对速度极敏感，用户多等一秒都嫌久。fal 在 Qwen3.6 + SGLang + DSpark 的组合上，把这个环节吞吐做到了原来的 16 倍，速度冲到约 1000 token/秒。

得泼句冷水：16 倍是这个特定业务场景、特定负载形状下测的数，不能套到「所有大模型对话都能提速 16 倍」上。但它证明了一件更要紧的事——DSpark 已经跳出 DeepSeek 自家 API 的边界，变成一个能随便搬到别处的通用组件。任何对延迟敏感、又能批量处理的文本中间环节，理论上都能吃到类似红利。

fal 博客展示 DSpark 在生产场景的 16 倍吞吐 ▲ fal 博客：为 Ideogram V4 的提示词扩写环节，用 DSpark 做到约 1000 tok/s，相对基线约 16 倍吞吐

技术圈怎么接这个话茬

Fireworks 的 CTO Dmytro Dzhulgakov 看完论文，发了条十连推，开头就定调：

> DSpark from @deepseek_ai ingeniously integrates many speculative decoding ideas to achieve 1.5x to 5x higher throughput in a real production system

「DeepSeek 的 DSpark 巧妙整合多种推测解码思路，在真实生产系统里实现 1.5 倍到 5 倍的吞吐提升。」

他用十个台阶，从「解码为什么是内存瓶颈」讲到「推测解码要付出多少代价」，再讲到 EAGLE、MTP、DFlash，最后落到 DSpark 怎么把并行块和自回归思想拼起来、怎么用更便宜的顺序模块建模块内依赖、怎么做变长草稿和设备感知调度、怎么在线校准。他归纳得很坦白：里面大部分单个想法此前都被单独发过，DeepSeek 的强项，是把它们拧成一套能在真实流量上跑通的完整系统。

Hacker News 上，这消息冲到 797 分、362 条评论。第一条高赞评论提到，DeepSeek 持续发「怎么做到的」这种详细论文，是不少美国实验室现在很少做的事。底下立刻有人反驳：Google 其实还在发，包括 2022 年的推测解码原始论文，以及今年给 Gemma 4 发的 MTP 代码。争论一路延伸到「MTP 权重该不该和主模型一起打包发布」，热闹，但没跑偏。

比起长篇论战，另一条短评更让人会心一笑。Noé Flandre 只回了一句：

> MTP at training time, DSpark at inference time.

「训练时用 MTP，推理时用 DSpark。」

这句话精准点出 DeepSeek 这两年的打法：训练阶段让模型提前学会「预测未来好几步」的结构，推理阶段就能把这份能力兑现成实打实的服务速度。两件事看似各做各的，其实一直在互相铺路。

Fireworks CTO 十点线程解析 DSpark ▲ Fireworks CTO Dmytro Dzhulgakov：DSpark 实现 1.5x 到 5x 的生产吞吐提升，十个概念从零讲清楚

藏在 README 里的 38TB

DSpark 配套开源了个叫 DeepSpec 的训练评测框架，README 里写着一句挺打击人的提醒：按默认配置，给 Qwen3-4B 这样的模型完整训一套草稿模型，光是目标模型重新生成答案后建的缓存，就能到 38TB 量级。

这话没半分夸张，是真门槛。想复现整套训练流程，得先扛住数据和存储两座大山。也正因如此，大部分中小团队更现实的选择是拿官方放的 checkpoint，或者在垂直场景里对草稿做局部微调——比如专门给代码补全、客服对话训一版更贴合的草稿，投入产出比反而更高。

大厂和云厂商付得起为头部模型重训的成本；剩下的人，捡现成权重，一样能让同一张显卡多接住几个用户。这大概也是 DeepSeek 这次把论文、代码、权重一起放出来的用意——一份能跑起来的仓库，比一篇只能读的 PDF 分量重得多。

比赛换了赛道

回头看整件事，真正值得记住的，压根不在 51% 还是 400% 这两个数本身。

过去两年，衡量一次模型发布够不够劲爆，习惯性看参数涨了多少、跑分榜又爬了几名。DSpark 这次没往这条赛道上加码，它没让模型多懂一分知识，却让同一批 GPU 多接住不少用户，让每个正等着回答出现的人，等得更短。

论文里有句话，大意是：草稿架构堆得更深，不如学会依赖前一个字来得划算，两层 DSpark，能打过五层 DFlash。背后藏着一个更普遍的道理：算力预算优先花在哪儿，或许比「模型该堆多大」这个问题，更值得被反复追问。

从 6 月 27 日种子推文发出，到 vLLM、SGLang、HN、fal 依次跟进，只花了不到两周。一份 MIT 协议的仓库、几份权重、几个引擎里的开关，就够让一项技术从「读论文」走到「今天就能上线」。

同一颗大脑，换了一副更快的嘴巴。这话听着轻巧，落在每个正等模型回答的人身上，就是实打实缩短的那几百毫秒。