★ 设为星标 | 只讲人话，带你玩转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
热门跟贴