DeepSeek 新论文曝光：不加算力，直接快了 85%

★ 设为星标 | 只讲人话，带你玩转AIGC。

就在美国还在疯狂封锁各种前沿模型的时候，DeepSeek 又扔出了一篇重磅论文，并且继续同步开源了论文相关的代码框架。

这篇论文也由 DeepSeek CEO梁文峰亲自署名，讲的核心其实是一个叫 DSpark 的东西。

这是啥、又能干啥？

据论文介绍，用了这项技术之后，我们现在在用的 DeepSeek V4，在线服务的回答速度能提高 85%。

没有升级、也没有新增算力，直接通过算法优化，就让模型回答速度提升了将近一倍，他们到底怎么做的？

要回答这个模型，我们得先回顾一下，主流的大模型是怎么回答一个问题的。

比如你想让它写一句话，你先给输入一个「我」字，那么模型就会开始思考：「我」后面最有可能接什么？

它计算之后发现，我后面出现「喜欢」的概率是最高的，所以它会输出：「我喜欢」。

那再往后呢？它会发现「我喜欢」之后，「你」这个词出现的概率是最高的。

所以它最终可能会输出一句话：我喜欢你很多年了。

这就是所谓的自回归模型，意思就是：第二个字必须建立在第一个字已经确定的基础上。如果第一个字还没生成，第二个字根本没法计算。

不过注意，这里的「字」其实是指 token，中文叫「词元」。所以“我、喜欢、你”分别是一个 token（词元）。

现在几乎所有的大语言模型，包括 ChatGPT、Claude、Gemini、DeepSeek……都是这样工作的。

很多人会奇怪，为什么要这么做，它就不能一次性输出“我喜欢你”吗？

不能。

因为就像成语接龙，没有前一个，后一个它不知道怎么接。

但问题就来了。

如果每生成一个 token （词元），都要根据前面的内容来计算一次。那一句很长的话，或者一篇几百字的文章，就意味着模型要完整运行几百次。

毫无疑问，这样既慢，又非常消耗算力。

那有没有种办法加快这个速度呢？

聪明的工程师们想到了一个办法：既然大模型这么大，每运行一次都很贵，那我是不是可以先找一个小模型来猜？

然后再把这个小模型猜出来的结果，交给真正的大模型去验证。

你肯定会很懵逼，刚刚不是说，大模型必须一个 Token 一个 Token 地生成吗？为什么现在又可以一次验证好几个？

没错。

生成和验证是两回事。

正常情况下，后面的 Token 根本不存在，所以模型只能一步一步生成。

但现在，小模型已经提前把后面的 Token 写出来了，大模型不用再生成，它只需要检查这些 Token 对不对。

而 Transformer 本身就可以一次计算整段文本每个位置的概率，所以验证这个过程，本来就是可以并行完成的。

所以，整个系统就变成了这样：用户输入一句话->小模型先快速写一份草稿->大模型再统一审核。

这个小模型也叫草稿模型。

这样的话，在用户输入「我」之后，这个草稿模型直接猜，“喜欢 你 很多年 了”。

然后把这一堆全部丢给真正的大模型去验证，它的概率有没有算对，一次性验证这么多，速度毫无疑问飞起。

后来，谷歌给这个方法起了个名字叫推测解码。

现在你知道，就是先找一个小模型打草稿，再让大模型审核。

这个就好比我们在编辑部，如果让总编来亲自写每一篇文章，总编的时间太宝贵了、太不划算了，而且效率太低了。

所以一般是让小编先写，写完之后总编来做最终审核。只要草稿质量不错，整个效率就会高很多。

但，其实一开始事情并没有那么简单。

后来，研究人员又提出了一类新的并行草稿模型，其中一个代表性的工作，就是 DFlash。

它最大的变化就是：草稿模型不再一个一个猜，而是一次直接预测多个 Token。

比如：喜欢 你 很多年 了

一次全部预测出来。

速度进一步提升。

但大家仔细想想，这个方式有没有问题？

本来这是一个成语接龙的游戏。

后面一个词，是建立在前面一个词已经确定的基础上的。

现在一次猜四个，也就意味着：

第二个 Token 在预测的时候，并不知道第一个 Token 最终到底是什么。

第三个 Token，也不知道前两个最终到底是什么。

于是，越往后，准确率就开始下降。

论文里把这个现象叫：后缀衰减

也就是说：越往后的 Token，连续猜对的概率越来越低。

那怎么办？

这就是这篇论文，也就是 DSpark 真正解决的问题。

它并没有把前 DFlash 推翻掉。

第一步，它还是一次预测多个 Token。

真正的变化发生在第二步。

论文在并行预测之后，又增加了一个非常轻量的顺序模块。

它不是把草稿全部生成完以后，再统一修改。

而是在最终决定每一个 Token 的时候，把前面已经确定的 Token 也考虑进去。

举个例子。

草稿模型一开始可能同时给出了「我」之后四个位置的候选结果：喜欢 你 很多年 了

但真正决定第二个 Token （喜欢）时，它会参考第一个 Token （我）。

真正决定第三个 Token 时，它又会参考前两个 Token。

这样一来，后面的 Token 就不再是"各猜各的"，而是重新具备了一部分自回归能力。

论文把这种方法叫半自回归。

这种方法非常夸张，它只额外消耗了1%的计算时间，但最终的结果是让整个的这个准确率提升了接近30%。

好，那到了这一步，是不是说就可以直接把所有的候选词都交给大模型去做验证了？毕竟准确率已经提高了很多了。

其实并不是，即便如此，草稿里面并不是每个词都准确的、有把握的。

如果所有的都丢给大模型去验证，还是会很耗算力。

所以呢？

他们会根据每一个候选词的概率（置信度)来做判断。

如果当前服务器不忙，他们就会多提交一些去做验证。如果服务器已经很忙了呢，他们就会把低置信度的 Token 截断，不再送去验证，让大模型从前面已经接受的位置继续生成。

论文里面数据可以看到，在低并发的时候呢，它每次请求会验证5~6个字。高并发的时候呢，可能会自动缩减到2~3个字。

整个系统始终会保持在一个比较优的状态，不会因为验证太多低质量 Token 而拖垮吞吐。

所以整个这套算法，你可以发现：Token 的消耗并没有减少。

用户最终看到多少 Token，还是多少 Token。

真正减少的是大模型需要进行的计算次数。

最终带来的效果，就是输出速度大幅提升。

论文公布的数据也非常夸张。

部署到 DeepSeek V4 在线服务之后，模型回答速度提升了 60%～85%。

说实话，每一次看DeepSpec的论文都让人肃然起敬的感觉。

因为他们一直在死磕一些非常硬核、非常底层、非常工程化的问题。

一如既往的，他们不仅发布了 DSpark 论文，还同步开源了 DeepSpec。

把一整套训练和评测草稿模型的工程框架，把数据准备、训练、评测等完整流程都开放了出来。

大家也都知道，现在整个行业最卡脖子的地方，其实就是算力。

不管中国也好，美国也好，大家都在想办法减少对昂贵 GPU 的依赖。

比如最近 OpenAI 联合博通推进自研 AI 芯片，本质上也是为了这个问题。

在国内，这个问题就更突出了。算力不仅紧张，而且非常贵。

所以，怎么样减少对算力的依赖，或者说在有限算力的情况下让模型跑的更快，这应该是每一个致力于突破瓶颈的公司的必经之路。

DeepSeek 继续在这条路上引领行业，非常值得敬佩。

参考：

https://github.com/deepseek-ai/DeepSpec

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