刚刚，DeepSeek V4 进行了一次更新。

新推出了投机解码框架 DSpark，同步开源了支撑该版本的全栈推测性解码框架 DeepSpec。

先澄清一个容易误解的点。DeepSeek-V4-Pro-DSpark 不是什么全新架构的模型，而是在 DeepSeek-V4-Pro 基础上引入了推测性解码模块。这次更新的重点在于工程落地，不是模型能力本身的迭代。

说人话就是，模型还是那个模型，但让它跑起来的方法变聪明了，所以你用起来会感觉明显变快。

DSpark 已经部署在 DeepSeek-V4 的 Flash 和 Pro 两条线上，跑的是真实线上流量，不是什么实验室 demo。

论文作者阵容相当豪华，北大和 DeepSeek 联合出品。

我知道很多朋友看到「投机解码」四个字就头大，觉得又是个听不懂的技术名词。其实这个思路特别好理解。

大语言模型生成文字的方式，是一个字一个字往外蹦的。每蹦出一个字，都要做一次完整的计算，所以延迟跟输出长度成正比。这就是为什么有时候你等 AI 回复，看着它一个字一个字打出来，心里着急。

投机解码的思路特别巧妙。它找了一个轻量的小模型先打草稿，一口气猜好几个字，然后让大模型一次性批改。如果小模型猜得对，大模型就直接采纳，相当于一次计算输出了好几个字。如果猜错了，大模型就从猜错的地方开始纠正，顺便还能多送一个字。整个过程不损失任何输出质量，因为最终结果还是大模型说了算。

这个思路不是 DSpark 发明的，投机解码这两年一直有人在做。但之前的方案有两个老毛病，一直没解决好。

第一个毛病是草稿质量的问题。

早期的草稿模型是自回归的，也就是跟大模型一样一个字一个字猜。这样猜出来的质量确实高，但小模型自己猜也要时间，猜得多了草稿本身就变慢了，得不偿失。

后来有人想到了并行草稿，一次前向传播直接猜好几个字，草稿速度一下就上来了。但新的问题来了，因为每个位置是独立猜的，没有考虑字跟字之间的依赖关系。举个例子，「of course」和「no problem」都是合理的回复开头，但并行草稿可能会猜出「of problem」这种四不像组合。越往后猜，这种错误累积越严重，接受率断崖式下跌。大家把这个现象叫「后缀衰减」。

第二个毛病是系统层面的浪费。

就算草稿模型一口气猜了 8 个、10 个字，你也不能闭着眼睛全送给大模型验证。因为越往后的字越不靠谱，验证这些低置信度的字是要占用算力的。在高并发场景下，比如很多人同时用的时候，把宝贵的批处理容量浪费在那些大概率会被拒绝的字上，会让整个系统变慢。闲的时候无所谓，忙的时候这就是性能悬崖。

DSpark 的贡献，就是把这两个毛病一起治了。

先看第一个改进，半自回归生成。

DSpark 的思路很务实。它保留了并行骨干的速度优势，也就是大部分计算还是一次搞定，但在最后加了一个极轻量的序列模块，快速顺一遍，给并行猜测的结果注入局部的顺序依赖信息。就像你写完东西快速通读一遍改几个连接词一样，花不了多少时间，但连贯性好很多。

这个设计很聪明。重计算的部分全部并行，保证速度；只在输出头加轻量 RNN 来建模 token 之间的转移，用极小的额外延迟换来了显著更高的接受率。论文里的实验数据显示，相比之前最好的自回归草稿模型 Eagle3，DSpark 的平均接受长度提升了约 30%；相比之前最好的并行草稿模型 DFlash，提升了约 18%。

再看第二个改进，置信度调度验证。

这是我觉得论文里最有意思的部分。DSpark 给每个草稿位置加了一个置信度头，预测这个位置最终被接受的概率。然后有一个硬件感知的调度器，根据实时的系统负载和每个位置的置信度，动态决定这次到底送几个字给大模型验证。

简单说就是，闲的时候多验证几个，反正算力闲着也是闲着；忙的时候只验证那些高置信度的字，不做无用功。而且这个调度不是事后拍脑袋，是在生成草稿的过程中就做决定，保证不会引入选择偏差。

两个改进加在一起，效果是非常显著的。

离线测试就不说了，在数学推理、代码生成、日常对话等多个领域都超过了此前的 SOTA。真正有说服力的是线上数据，毕竟离线刷榜谁都会，真实流量才是试金石。

在 DeepSeek-V4 的生产环境里，跟之前的 MTP-1 生产基线相比，DSpark 在匹配吞吐量的前提下，把每个用户的生成速度提升了 60% 到 85%，V4-Flash 提速更猛一些，V4-Pro 也有 57% 到 78% 的提升。

更关键的是高并发场景。论文里提到，在严格的服务等级协议下，比如 Flash 120 TPS、Pro 50 TPS 这种之前基线容量会严重恶化的负载水平，DSpark 依然能维持稳健的吞吐量。其实就是，高峰期大家一起用的时候，你不会再感觉到明显的卡顿和等待。

这其实就是把整个服务系统的帕累托前沿往外推了，速度和并发承载能力同时上了一个台阶。之前做不到的性能档位，现在可以做到了。

当然，DSpark 也不是万能的。论文里也坦诚提到了局限性，对于那些本身就特别复杂、接受率天然低的查询，草稿阶段的固定计算开销是收不回来的。未来可能会引入难度感知的早停机制，让这类查询直接绕过完整的草稿生成。

---

最后说开源的事。

DeepSeek 这次不仅仅是发了一篇论文，他们把 DSpark 训练好的检查点也开源了，包括 V4-Flash 和 V4-Pro 的预览版。同时开源的还有 DeepSpec，一个算法驱动的投机解码训练仓库，里面包含了 Eagle3、DFlash 和 DSpark 三种方法的实现。

坦率的讲，这两年大模型推理优化的进展真的很快。从最初的投机解码概念提出，到自回归草稿、并行草稿，再到现在 DSpark 这种半自回归加置信度调度的系统级方案，整个领域在以肉眼可见的速度迭代。

而 DeepSeek 选择把这些东西开源出来，对整个社区都是好事。不是每家公司都愿意把生产环境验证过的技术细节和模型权重放出来的。

我自己的感受是，大模型的竞争已经不只是「谁的模型更聪明」了，推理效率、服务成本、用户体验这些工程层面的东西，权重越来越大。DSpark 这种技术，用户可能感知不到它的存在，但每次你用 DeepSeek 感觉回复变快了、高峰期不转圈了，背后就是这些工程改进在默默起作用。

说到底，好的技术就是让你感觉不到技术的存在。

它只是变得更快了而已。

感谢阅读。点个关注，不迷路，我们后续会持续跟进 DeepSeek、大模型推理优化、AI 开源生态等前沿技术动态，第一时间为你解读。