TL;DR大模型生成回复时是一个字一个字蹦出来的这是它慢的根本原因。DSpark 这篇新论文提出了一种先猜后验的加速方法让一个轻量模型快速草拟多个候选字大模型再一次性验货同时根据自信程度动态决定多猜几个还是赶紧验。这就像一个有经验的编辑和一个快手写手的配合——写手负责快速堆草稿编辑负责把关自信时多写几行再交没把握时写完一句就交。本文用人话拆解这套机制。1. 大模型为什么慢要理解 DSpark 在加速什么得先理解大模型生成文本的方式。GPT、Claude、文心一言这些大模型生成回复时是一个 token可以理解为一个字或一个词接一个 token 地生成的。每次生成下一个 token都要跑一遍整个模型的全部参数。这个过程叫做自回归生成Autoregressive Generation。用一个比喻你让一个大厨炒菜。这位大厨的规矩很奇怪——每切一刀菜就必须把整个厨房从头到尾检查一遍确认所有调料、锅具、火候都对才切下一刀。菜最终很好吃但慢得令人发指。大模型的厨房检查就是跑一遍几十亿甚至上千亿参数的神经网络。token 越多越慢这是物理规律。过去两年业界的加速思路主要有两条一条是优化硬件和模型本身量化、蒸馏、Flash Attention 等另一条是改变生成方式。DSpark 走的是第二条路它属于一个叫做推测解码Speculative Decoding的技术家族。2. 推测解码的核心思想“先猜后验”推测解码的基本思路其实很朴素与其让大模型一个字一个字地写不如让一个小模型先草拟几个字大模型再一次性验货。具体流程是这样的用一个轻量级的小模型draft model快速生成 K 个候选 token。比如今天天气后面小模型猜是真不错。小模型参数少跑得快生成这 3 个字几乎不花时间。大模型一次性把这 3 个候选 token 和前面的上下文一起输入并行验证。验证的意思是大模型自己算一遍如果是我我会不会也生成’真不错’这三个字如果大模型认可了前两个“真不”但第三个“错”不认可那就只接受前两个第三个用自己的版本替换。这个过程相当于快手写手小模型疯狂堆草稿资深编辑大模型快速把关。写手猜对几个字就省了几次大模型跑一遍全部参数的时间。但这里有三个关键问题之前的方法没解决好一次猜几个字最划算猜少了浪费大模型的并行验货能力猜多了猜错的概率高浪费小模型的草稿。小模型的草稿质量怎么保证如果小模型猜得太离谱大模型验货时全部否决等于白猜。不同场景下策略要不要变写代码时模型很自信语法确定性高写诗时模型不自信创意空间大猜字策略应该不同。DSpark 的创新点就是在这三个问题上给出了更聪明的答案。3. DSpark 的两个核心创新创新一半自回归生成Semi-Autoregressive Generation传统推测解码中小模型也是一个字一个字猜的只是猜得快。DSpark 让草稿模型一次性猜出多个 token——比如同时猜真、“不”、“错三个字而不是先猜真”再基于真猜不。这叫做半自回归不完全是一个字一个字也不完全是整句话同时出而是一小段一小段地并发生成。效果是草稿阶段也加速了。创新二置信度调度Confidence-Scheduled Verification这是 DSpark 最核心的贡献。它的思路是根据大模型当前的自信程度动态决定一次验证多少个 token。怎么判断自信程度看大模型对前几个 token 的概率分布。如果大模型对下一个 token 的选择非常确定比如11“后面99.9% 的概率是2”说明这个位置确定性高可以多猜几个再验。如果概率分布很均匀比如我最喜欢的颜色是后面红蓝绿黄各有 20%说明不确定性高应该少猜、快验。DSpark 把这个过程自动化了不需要人工设置一次猜几个而是让系统根据实时的置信度信号动态调整草稿长度和验证频率。回到那个编辑和写手的比喻自信时写手多写几段再交稿“这章我很确定”不自信时写一句就交“这段我不太确定您先看看方向对不对”。4. 这对普通用户意味着什么你不需要看懂论文里的公式。作为大模型的使用者DSpark 这类技术落地后你会感受到几个变化对话更跟手。现在很多大模型聊天时有一种打字机的感觉——字一个字地往外蹦。推测解码成熟后回复会更像一段一段地弹出来体感更快。长文本生成不再煎熬。让大模型写一篇 3000 字的文章现在可能要等 20 秒。推测解码理论上可以把生成速度提升 2-3 倍同样的文章可能 7 秒就出来了。API 成本下降。对开发者来说更快的推理速度意味着同样的 GPU 可以服务更多用户API 调用的成本也会随之下降。DSpark 的论文特别强调了实时生产环境中的每用户生成速度和总吞吐量说明它的设计目标就是生产级部署。但不会改变模型智力。推测解码是无损加速——大模型最终输出的每个 token 都经过了自己验证不会因为加速而变笨。它只是省掉了大模型亲自写的时间没有省掉大模型亲自审的环节。5. 推测解码不是唯一的路但是最实用的路在大模型推理加速这个方向上有三条主流技术路线模型压缩量化、蒸馏、剪枝让模型本身变小。代价是可能损失精度。硬件优化专用芯片、更好的 GPU 调度从底层加速。代价是贵。推测解码不改变模型不换硬件只改变生成策略。DSpark 属于第三条路这也是它实用价值最高的地方——它不需要重新训练模型不需要买新 GPU只要部署一套草稿-验证机制就能提速。对于已经跑着大模型的服务来说这是一条零成本加速的路。当然推测解码也有代价需要额外部署一个草稿模型虽然很小而且草稿模型和主模型之间的协调本身也有开销。DSpark 的置信度调度本质上就是在最小化这个开销——让草稿和验证之间的配合更聪明减少无效劳动。6. 参考资料DSpark: Confidence-Scheduled Speculative Decoding with Semi-Autoregressive GenerationLeviathan et al., Fast Inference from Transformers via Speculative Decoding (ICML 2023) — 推测解码的开山之作Chen et al., Accelerating Large Language Model Decoding with Speculative Sampling (2023) — DeepMind 同期独立提出的类似方法
为什么大模型回复越来越快？一文读懂 DSpark 的“先猜后验“加速术
TL;DR大模型生成回复时是一个字一个字蹦出来的这是它慢的根本原因。DSpark 这篇新论文提出了一种先猜后验的加速方法让一个轻量模型快速草拟多个候选字大模型再一次性验货同时根据自信程度动态决定多猜几个还是赶紧验。这就像一个有经验的编辑和一个快手写手的配合——写手负责快速堆草稿编辑负责把关自信时多写几行再交没把握时写完一句就交。本文用人话拆解这套机制。1. 大模型为什么慢要理解 DSpark 在加速什么得先理解大模型生成文本的方式。GPT、Claude、文心一言这些大模型生成回复时是一个 token可以理解为一个字或一个词接一个 token 地生成的。每次生成下一个 token都要跑一遍整个模型的全部参数。这个过程叫做自回归生成Autoregressive Generation。用一个比喻你让一个大厨炒菜。这位大厨的规矩很奇怪——每切一刀菜就必须把整个厨房从头到尾检查一遍确认所有调料、锅具、火候都对才切下一刀。菜最终很好吃但慢得令人发指。大模型的厨房检查就是跑一遍几十亿甚至上千亿参数的神经网络。token 越多越慢这是物理规律。过去两年业界的加速思路主要有两条一条是优化硬件和模型本身量化、蒸馏、Flash Attention 等另一条是改变生成方式。DSpark 走的是第二条路它属于一个叫做推测解码Speculative Decoding的技术家族。2. 推测解码的核心思想“先猜后验”推测解码的基本思路其实很朴素与其让大模型一个字一个字地写不如让一个小模型先草拟几个字大模型再一次性验货。具体流程是这样的用一个轻量级的小模型draft model快速生成 K 个候选 token。比如今天天气后面小模型猜是真不错。小模型参数少跑得快生成这 3 个字几乎不花时间。大模型一次性把这 3 个候选 token 和前面的上下文一起输入并行验证。验证的意思是大模型自己算一遍如果是我我会不会也生成’真不错’这三个字如果大模型认可了前两个“真不”但第三个“错”不认可那就只接受前两个第三个用自己的版本替换。这个过程相当于快手写手小模型疯狂堆草稿资深编辑大模型快速把关。写手猜对几个字就省了几次大模型跑一遍全部参数的时间。但这里有三个关键问题之前的方法没解决好一次猜几个字最划算猜少了浪费大模型的并行验货能力猜多了猜错的概率高浪费小模型的草稿。小模型的草稿质量怎么保证如果小模型猜得太离谱大模型验货时全部否决等于白猜。不同场景下策略要不要变写代码时模型很自信语法确定性高写诗时模型不自信创意空间大猜字策略应该不同。DSpark 的创新点就是在这三个问题上给出了更聪明的答案。3. DSpark 的两个核心创新创新一半自回归生成Semi-Autoregressive Generation传统推测解码中小模型也是一个字一个字猜的只是猜得快。DSpark 让草稿模型一次性猜出多个 token——比如同时猜真、“不”、“错三个字而不是先猜真”再基于真猜不。这叫做半自回归不完全是一个字一个字也不完全是整句话同时出而是一小段一小段地并发生成。效果是草稿阶段也加速了。创新二置信度调度Confidence-Scheduled Verification这是 DSpark 最核心的贡献。它的思路是根据大模型当前的自信程度动态决定一次验证多少个 token。怎么判断自信程度看大模型对前几个 token 的概率分布。如果大模型对下一个 token 的选择非常确定比如11“后面99.9% 的概率是2”说明这个位置确定性高可以多猜几个再验。如果概率分布很均匀比如我最喜欢的颜色是后面红蓝绿黄各有 20%说明不确定性高应该少猜、快验。DSpark 把这个过程自动化了不需要人工设置一次猜几个而是让系统根据实时的置信度信号动态调整草稿长度和验证频率。回到那个编辑和写手的比喻自信时写手多写几段再交稿“这章我很确定”不自信时写一句就交“这段我不太确定您先看看方向对不对”。4. 这对普通用户意味着什么你不需要看懂论文里的公式。作为大模型的使用者DSpark 这类技术落地后你会感受到几个变化对话更跟手。现在很多大模型聊天时有一种打字机的感觉——字一个字地往外蹦。推测解码成熟后回复会更像一段一段地弹出来体感更快。长文本生成不再煎熬。让大模型写一篇 3000 字的文章现在可能要等 20 秒。推测解码理论上可以把生成速度提升 2-3 倍同样的文章可能 7 秒就出来了。API 成本下降。对开发者来说更快的推理速度意味着同样的 GPU 可以服务更多用户API 调用的成本也会随之下降。DSpark 的论文特别强调了实时生产环境中的每用户生成速度和总吞吐量说明它的设计目标就是生产级部署。但不会改变模型智力。推测解码是无损加速——大模型最终输出的每个 token 都经过了自己验证不会因为加速而变笨。它只是省掉了大模型亲自写的时间没有省掉大模型亲自审的环节。5. 推测解码不是唯一的路但是最实用的路在大模型推理加速这个方向上有三条主流技术路线模型压缩量化、蒸馏、剪枝让模型本身变小。代价是可能损失精度。硬件优化专用芯片、更好的 GPU 调度从底层加速。代价是贵。推测解码不改变模型不换硬件只改变生成策略。DSpark 属于第三条路这也是它实用价值最高的地方——它不需要重新训练模型不需要买新 GPU只要部署一套草稿-验证机制就能提速。对于已经跑着大模型的服务来说这是一条零成本加速的路。当然推测解码也有代价需要额外部署一个草稿模型虽然很小而且草稿模型和主模型之间的协调本身也有开销。DSpark 的置信度调度本质上就是在最小化这个开销——让草稿和验证之间的配合更聪明减少无效劳动。6. 参考资料DSpark: Confidence-Scheduled Speculative Decoding with Semi-Autoregressive GenerationLeviathan et al., Fast Inference from Transformers via Speculative Decoding (ICML 2023) — 推测解码的开山之作Chen et al., Accelerating Large Language Model Decoding with Speculative Sampling (2023) — DeepMind 同期独立提出的类似方法
双梁正问题 【 torch 实战】（Python代码实现）)
