DeepSeek-AI与北京大学联手破局：AI聊天机器人"慢速打字"的终极解决方案

这项由DeepSeek人工智能公司与北京大学联合开展的研究，以预印本形式发表于2026年7月6日，论文编号为arXiv:2607.05147，有兴趣深入了解技术细节的读者可通过该编号查询完整论文。

每天有数以亿计的人在使用各类AI聊天助手——无论是问一道数学题、让它帮你写封邮件，还是请它帮你调试一段代码。你肯定注意到过一个现象：屏幕上的文字是一个字、一个字慢慢"蹦"出来的，而不是一下子全部出现。这种"一次出一个字"的工作方式，并不是设计师为了制造打字机氛围而特意设计的，而是大语言模型（AI文字生成系统）底层运作机制的天然结果。每生成一个字，模型都需要完整地"想一遍"，然后才能蹦出下一个字。这种逐字推进的方式，就像一位厨师每做一道菜都必须把整个厨房从头打扫一遍才能开始下一道，效率自然低得可怜。

这篇论文提出的"DSpark"系统，正是为了解决这个根本性的效率瓶颈。它不仅让AI生成文字的速度大幅提升，更关键的是，它在真实的大规模服务环境下——也就是成千上万用户同时使用同一个AI系统时——依然保持了出色的性能，把用户的体验速度提升了60%到85%。这不是一个实验室里的理想数据，而是在DeepSeek-V4这个真实运营的产品中，面对真实用户流量测量得到的结果。

一、AI为什么会"慢慢打字"，这到底是谁的问题

要理解DSpark解决了什么问题，我们得先搞清楚AI文字生成慢的根本原因。大语言模型的工作原理有点像一位极其谨慎的预言家：每次它只敢预测下一个最可能出现的词，然后把这个词纳入已知信息，再预测再下一个词。这个过程完全是串行的、线性的，没有任何并行可言。生成一段200个字的文字，模型就需要走200次完整的"预测循环"，每次循环都需要调用功能强大但计算量巨大的神经网络。

现代AI芯片（GPU）本来是为了并行计算而生的，就像一个拥有几千名工人的超大型工厂，最适合同时干很多件事。但逐字生成的方式却把这家工厂变成了一条只有一名工人在慢慢操作的流水线，绝大多数工人都在闲置等待。这种资源浪费既拖慢了每个用户的响应速度，也严重限制了系统能同时服务多少用户。

"投机解码"（Speculative Decoding）是解决这一问题的主流思路，它的核心逻辑类似于让一个助理先打草稿、再交给主厨审核。具体来说，先用一个小而快的"草稿模型"快速猜出接下来的若干个词，然后把这些猜测一次性交给大模型，让大模型在一次运算中同时审核所有猜测的词，接受猜对的部分，拒绝猜错的部分。由于大模型的"审核"操作天然支持并行，每一轮审核都能一次性确认多个词，整体速度便大幅提升。关键在于，这个过程并不改变大模型最终的输出质量——那些被接受的词，正是大模型自己也会生成的词；那些被拒绝的词，大模型会重新生成一个正确的替代。换句话说，速度提升了，质量却没有任何损失。

然而，投机解码在实践中面临两个相互缠绕的难题，而这两个难题正是DSpark要解决的核心挑战。

二、两道拦路虎：草稿质量和验证浪费

第一道拦路虎来自草稿质量。草稿模型有两种基本路线：一种叫"自回归草稿"，它和大模型一样逐字生成草稿，每个词都参考前面已经生成的词，因此草稿质量较高，前后文连贯性好。但问题在于，这种逐字生成的方式使得生成速度和草稿长度成正比——草稿越长，等待时间越长，和大模型慢慢打字的困境如出一辙，只是换了个稍微小一点的模型而已。

另一种叫"并行草稿"，它一次性同时预测出多个位置的词，生成速度极快，无论草稿有多长，生成时间几乎不变，就像一个可以同时预测整行棋局的棋手。然而并行草稿有个致命弱点：它预测每个词时，并不知道前面的词最终会被选择哪个。以一个简单的中文例子来说，假设第一个词既可能是"当然"也可能是"没问题"，并行草稿在预测第二个词时，不得不两种可能都考虑，结果就可能生成"当然问题"或"没然可以"这种前后矛盾的奇怪组合。随着草稿位置越来越靠后，这种"多模态碰撞"（即多种可能性相互混淆）越来越严重，草稿被大模型接受的概率急剧下降，越到后面的词越容易被拒绝，白白浪费了生成这些词的计算资源。

第二道拦路虎来自验证浪费。即使草稿模型生成了很长的草稿，把所有草稿词都送给大模型验证也不一定是明智之举。大模型验证操作本身消耗的计算资源与验证词的数量成正比。当系统负载很轻、同时只有少数用户在使用时，多验证几个词几乎没有额外成本，哪怕最后被拒绝了也无所谓。但当系统处于高并发状态——比如几百个用户同时提问——情况就完全不同了。大模型的计算资源是有限的，每多验证一个注定会被拒绝的草稿词，就意味着其他用户的请求要多等一会儿。换句话说，在系统繁忙时，盲目地把整段长草稿都送去验证，反而会拖累整个系统的吞吐量，适得其反。

DSpark正是为了同时攻克这两道难题而设计的。

三、半自回归生成：鱼和熊掌一起吃

DSpark的第一个核心创新叫做"半自回归生成"，这是它解决草稿质量问题的方案。用一个直观的比喻来理解：传统并行草稿就像一个合唱团，所有人同时开嗓，但由于彼此听不到对方在唱什么，很可能唱出乱糟糟的和声。传统自回归草稿则像一个接龙朗诵——上一个人说完，下一个人才能接着说，虽然衔接流畅，但速度太慢。DSpark的设计是让合唱团先各自快速哼出一个大致的旋律框架（并行阶段），然后再由一个轻量的指挥快速调整相邻音符之间的衔接关系（顺序阶段），兼顾了速度和连贯性。

在技术层面，DSpark的并行骨干网络与当前最先进的并行草稿模型DFlash结构相似：在一次前向计算中，同时为草稿序列中的所有位置生成初始预测（称为"基础逻辑值"）。不过DSpark对DFlash做了一个小而精妙的改动——它把锚定词本身也纳入第一个预测位置，使得相同数量的输入词能产出更多的草稿词，在降低计算量的同时保持相近的草稿质量。

并行阶段结束后，接力棒传给了一个极其轻量的"顺序模块"。这个模块的工作是给每个位置的基础预测加上一个"过渡偏置"——简单来说，就是根据前一个词是什么，微调当前位置的词语概率分布，让前后两个词之间的搭配更加合理。DSpark提供了两种顺序模块的实现方式。

第一种叫"马尔可夫头"，它的逻辑极为简单：只看紧邻的前一个词来调整当前词的概率。具体实现上，它维护了一个经过低秩压缩的"词语过渡表"——你可以把它理解为一个巨大的词语搭配词典，记录了当前词"of"之后最可能出现的词、当前词"no"之后最可能出现的词，等等。这个词典经过特殊的数学压缩，存储空间极小，查询速度极快，每一步的计算量几乎可以忽略不计。回到之前的例子：一旦第一个词被确定为"of"，马尔可夫头就会立刻增强"course"在第二个位置出现的概率，同时抑制"problem"的概率，从而避免"of problem"这种奇怪搭配的产生。

第二种叫"RNN头"，它的记忆比马尔可夫头更长：不只看前一个词，而是维护一个随草稿序列流动而不断更新的"状态向量"，这个状态向量压缩了整个草稿前缀的历史信息，让过渡偏置能参考更远的上下文。不过实验结果表明，RNN头相比马尔可夫头带来的额外提升有限，主要体现在较长的草稿序列上，而RNN头的实现复杂度更高、部署难度更大。综合考量后，DSpark选择马尔可夫头作为默认配置。

顺序模块虽然是逐步运行的（必须先确定第1个词，才能计算对第2个词的偏置，再确定第2个词，才能计算第3个词的偏置……），但由于每一步的计算量极小，整个顺序循环的总耗时远远小于并行骨干网络的一次前向计算。实测数据显示，在标准批处理规模下，加入顺序模块后整个草稿生成阶段的延迟增加仅为0.2%到1.3%，而换来的草稿接受长度提升却高达16%到30%——这个交换比可谓极为划算。

四、置信度调度验证：聪明地分配大模型的算力

草稿质量提升了，接下来需要解决验证浪费的问题。DSpark的第二个核心创新叫做"置信度调度验证"，可以理解为一套动态的"性价比过滤器"。

这套机制的第一个组成部分是"置信度头"。在草稿生成阶段，顺序模块在决定每个草稿词时，会附带输出一个介于0和1之间的置信度分数，代表"这个词通过大模型验证的概率"，更准确地说，是"在前面所有词都已被接受的前提下，这个词也被接受的条件概率"。这个置信度分数由一个极轻量的线性函数计算得出，输入是草稿模型的隐状态和前一个词的嵌入向量，输出经过一个Sigmoid函数压缩到0到1之间。训练时，这个置信度头被要求预测一个理论上可计算的"真实接受率"——即草稿词分布与大模型词分布之间的统计距离（用总变差距离衡量），两个分布越接近，这个词被接受的概率就越高。

有了每个位置的条件接受概率，把它们从左到右连乘，就能得到每个位置的"前缀生存概率"——即从草稿第1个词一直到第k个词，全部都被大模型接受的联合概率。这个概率随着位置的推进单调递减，位置越靠后，对应的前缀生存概率越低。

不过，神经网络输出的置信度分数往往存在"过度自信"的问题——它预测的接受概率系统性地偏高。如果直接使用这些原始分数，系统会高估草稿被接受的可能性，导致送出太多低质量的草稿词，适得其反。为此，DSpark引入了"序列温度缩放"（STS）作为事后校准手段：在一个独立的验证数据集上，从左到右逐个位置地搜索一个最优的温度系数，使校准后的联合概率分布与实测的真实接受率尽可能吻合。温度缩放是一种不改变排名顺序的变换——它只是把过高的概率适当压低，让绝对值更准确，同时保留原来各词质量高低的相对排序。实测数据显示，校准后各位置的"期望校准误差"（一种衡量概率预测准确性的指标）从校准前的3%到8%，大幅降低到约1%，同时各位置的区分能力（ROC-AUC指标）维持在0.81到0.90的较高水平。

第二个组成部分是"硬件感知前缀调度器"，这是整套机制的决策核心。它的任务很明确：在任意给定时刻，系统中有若干个并发请求，每个请求都有一组草稿词及其对应的前缀生存概率，调度器需要决定每个请求应该送多少个草稿词去验证，使得整个系统的"每秒成功生成词数"最大化。

这个问题的核心洞察在于：大模型每次前向计算能处理的总词数（批处理大小）直接决定了计算速度，但不同批处理大小下的每步计算速度（SPS，Steps Per Second）是预先可以测量的。DSpark在系统初始化时，对不同批处理规模逐一测量并记录这个速度曲线，形成一张轻量的"硬件容量表"。运行时，调度器结合每个请求的前缀生存概率（即每个草稿词能真正贡献到最终输出的期望贡献量）和这张硬件容量表，通过一个高效的贪心算法，找出全局最优的草稿词分配方案。

贪心算法的运作方式是：把所有请求的所有草稿词按前缀生存概率从高到低排成一个全局队列，然后逐个把词从队列头部"纳入验证"，每纳入一个词，就更新当前的预期总吞吐量（已接受词的期望数量乘以对应批处理规模下的每步速度），当预期吞吐量不再增长时立刻停止。这种"早停机制"不仅保证了最优性（在目标函数单峰的假设下），更有一个关键的理论意义：它确保了调度决策在采样具体草稿词之前就已完成，不会因为"看到某个词的具体取值后才决定是否接受它"而引入统计偏差——这是保证最终输出分布与大模型原始分布完全一致（即"无损"）的必要条件。论文的附录中还通过一个精心构造的反例证明：如果去掉早停机制、改用全局回溯搜索，就会出现"接受概率依赖于被接受词本身取值"的循环，导致输出分布系统性地偏离目标，破坏无损保证。

五、从实验室到真实服务器：部署中的工程挑战

理论上完美的算法，在真实工业部署中往往会遭遇意想不到的阻力。DSpark的研究团队诚实地记录了将调度器部署进DeepSeek-V4生产服务系统时遭遇的两大工程障碍，以及他们是如何绕过这些障碍的。

第一个障碍是硬件容量曲线的非平滑性。理论分析假设每步计算速度随批处理大小的增加平滑递减，但实际的GPU计算速度曲线因为底层张量核心利用率的变化而呈现出不规律的阶梯状下降——某些批处理大小会触发效率断崖，速度突然跌落，随后又趋于平稳。这种"锯齿状"曲线使得早停机制可能过早地陷入局部最优点。

第二个障碍是与"零开销调度"（ZOS）的兼容性冲突。现代高吞吐量大模型服务系统为了最大化GPU利用率，会提前预计算当前步骤的同时确定下一步骤的批处理配置，两步操作高度流水线化。这意味着下一步要处理多少个词，必须在当前步骤执行期间就确定好，不能等到当前步骤完成后再做决策。而DSpark调度器按照原始设计需要在当前步骤完成、新草稿词采样完成之后，才能计算出准确的置信度分数，进而决定下一步的验证长度。同步调度与流水线执行之间存在根本性的时序冲突。

DSpark的解决方案是引入"异步调度"：不使用当前步骤刚刚产生的置信度分数，而是使用两步之前的置信度分数来预测当前步骤需要的验证容量K。实际的候选词仍然按照最新的置信度分数从高到低排序，历史预测值仅用于确定截断阈值（即最多验证多少个词）。这种"容量用历史、排序用当前"的混合策略引入了一个两步的时间偏移，但由于截断决策依赖的是两步之前的信息，而不是当前草稿词的具体取值，因此不会引入基于"当前词取值"的选择性偏差，无损保证依然成立。

更妙的是，异步设计还自然地化解了第一个障碍：由于截断决策本身基于历史信息，已经不再依赖于"吞吐量目标是否单峰"这一假设，因此可以安全地去掉早停的break条件，改为无约束地全局搜索，从而绕过硬件容量曲线上的局部锯齿，找到真正的全局最优截断点。两个工程难题被一个设计改动一并解决，实属精巧。

在计算内核层面，可变长度验证也带来了挑战：不同请求被分配了不同数量的草稿词参与验证，标准的固定长度批处理内核无法高效处理这种可变长度的输入，直接处理会导致大量填充（Padding）和计算资源浪费。团队采用了扁平化处理策略：把所有请求的所有待验证词在计算内核层面铺平为连续序列，用一个专门的标记张量记录每个词属于哪个请求、在序列中处于哪个位置，注意力机制则通过读取这个标记张量来正确处理跨请求的边界。在DeepSeek-V4的稀疏注意力架构下，只有索引注意力和压缩注意力两个计算内核需要针对这种可变长度路由做修改，改动范围相当有限。

训练阶段同样面临独特的工程挑战。草稿模型的训练需要目标大模型的概率分布作为监督信号，但把大模型的完整词表概率分布（约10万个词的概率向量）传输给草稿模型的计算节点，会产生巨大的通信开销。团队采用了"隐状态通信"方案：只传输大模型语言建模头之前的隐状态向量（维度远小于完整词表），在草稿模型的本地节点上重新运行语言建模头的投影，仅为训练中实际采样到的位置计算概率值，通信量降低到与模型隐藏维度成正比。另一个训练优化是"锚点有界序列打包"：从长文本序列中随机采样固定数量的锚点位置，把每个锚点周围的短草稿块打包成密集的训练批次，通过词级别的注意力索引而非二维掩码来保证跨块的因果隔离，既避免了块间信息泄露，又规避了大量填充带来的计算浪费。

六、数据说话：DSpark的实验成绩单

在离线受控评测中，DSpark在四个目标模型（Qwen3-4B、Qwen3-8B、Qwen3-14B、Gemma4-12B）和九个基准测试集上，与两类顶尖竞争者进行了全面对比。竞争对手之一是Eagle3，代表当前最先进的自回归草稿方案；另一位是DFlash，代表当前最先进的并行草稿方案。所有参与比较的模型都在相同数据集、相同训练框架下重新训练，确保比较公平。数据集涵盖三个领域：数学推理（包括GSM8K、MATH500、AIME25）、代码生成（包括MBPP、HumanEval、LiveCodeBench）和日常聊天（包括MT-Bench、Alpaca、Arena-Hard）。评价指标是每轮解码的平均"接受长度"——即大模型每次一并验证时平均能接受多少个草稿词，这个数字越大，加速效果越好。

在Qwen3-4B上，DSpark的宏平均接受长度比Eagle3提升了30.9%，比DFlash提升了16.3%。在Qwen3-8B上，对应提升分别是26.7%和18.4%。在Qwen3-14B上，分别是30.0%和18.3%。在不同架构的Gemma4-12B上，DSpark同样超越了两位竞争对手，证明这种提升具有跨模型家族的普遍性。

一个有趣的深层分析是"逐位置条件接受率"曲线。研究团队追踪了在前k-1个草稿词全部被接受的前提下，第k个草稿词被接受的概率，按照k从1到7绘制曲线。结果清晰展示了三种架构的本质差异：Eagle3（自回归）的曲线随位置推进保持平稳甚至略有上升，说明它的草稿质量不随位置衰减，序列越长越有把握；DFlash（并行）的曲线则明显向下倾斜，每进一个位置接受概率就下降一步，印证了并行生成的多模态碰撞问题；DSpark（半自回归）的曲线从与DFlash相近的高起点出发（受益于深度并行骨干），随后保持平稳而不急剧下滑（受益于顺序模块的前后文约束）。

另一个令人深思的发现是：并行草稿模型在"第一个词的接受率"上显著优于自回归草稿模型（以Qwen3-4B为例，数学推理领域DFlash首位接受率约0.88，而Eagle3仅约0.81；日常聊天领域两者差距更大，分别约为0.72和0.53）。这看起来违反直觉——不是应该知道前文的自回归模型更准确吗？原因在于计算资源的分配：自回归草稿必须把草稿延迟时间保持在O(草稿长度)以内，因此只能使用非常浅的网络（Eagle3只用了1层Transformer）；并行草稿的延迟与草稿长度无关，可以使用深得多的网络（DFlash使用5层Transformer），深层网络对目标大模型的特征理解能力更强，首位预测自然更准确。由于投机解码是从左到右的前缀匹配过程，第一个词被拒绝后后面的词全部作废，因此首位准确率对整体加速效果的杠杆效应远超其他位置。这正是为什么即便并行草稿在位置3之后的接受率低于自回归草稿，它的总体接受长度依然更高——赢在了最关键的第一步。

在深度消融实验中，研究团队还测试了草稿模型层数对DSpark表现的影响。仅2层的DSpark（而非默认的5层）就已经在所有九个基准上超过了5层的DFlash基线，说明轻量的顺序模块带来的序列连贯性提升有着极高的参数效率，用更少的参数实现了更好的效果。随着草稿序列长度从4增加到16，DSpark相对于DFlash的优势持续扩大（数学领域：+16% → +30%，代码领域：+15% → +26%，聊天领域：+18% → +22%），这完全符合预期：草稿越长，多模态碰撞的累积效应越明显，顺序模块的纠偏价值也越大。

七、生产环境中的真实表现：Pareto前沿的移动

离线评测固然重要，但DSpark更值得关注的成果来自DeepSeek-V4真实生产环境下的部署结果。测试对象是DeepSeek-V4-Flash（预览版）和DeepSeek-V4-Pro（预览版）两个服务引擎，对比基准是此前在生产中运行的MTP-1系统——一次验证1个草稿词的单词投机解码方案，这个方案之所以是生产基线，正是因为更激进的多词方案（如一次验证3-5个词的MTP-3/5）在高并发场景下会因验证浪费而拖累整体吞吐量，反而不如MTP-1。DSpark的出现，让更长草稿块的验证在高并发下也变得可行，接替MTP-1成为新的生产基线。

评测使用的是真实用户流量产生的遥测数据，散点图呈现了系统聚合吞吐量（每秒每GPU处理的总词数）与用户侧生成速度（每秒每用户收到的词数，TPS）之间的关系曲线。这两个指标之间存在内在张力：吞吐量代表系统整体利用率，TPS代表单个用户的主观体验流畅度；通常情况下，为了提升吞吐量而增大批处理规模，会降低单个请求的TPS，两者此消彼长。

在V4-Flash引擎上，当系统在中等TPS约束（80词/秒/用户）下运行时，DSpark相比MTP-1实现了51%的聚合吞吐量提升。当约束收紧到120词/秒/用户时，MTP-1已经接近其可运行边界，并发批处理规模极小，系统吞吐量急剧萎缩；DSpark在这一约束下仍能维持实质性的服务能力，名义上实现了661%的吞吐量优势。研究团队特别说明，这个661%更多是"MTP-1能力边界崩溃"的体现，而非DSpark本身倍数级的性能提升，应主要解读为DSpark成功地把"120词/秒/用户"这个性能层级从"不可达"变为"可正常服务"。在等吞吐量的稳定比较点上，DSpark为每个用户带来60%到85%更快的生成速度。V4-Pro引擎的规律与此相同，中等SLA约束（35词/秒/用户）下吞吐量提升52%，严格SLA约束（50词/秒/用户）下名义提升406%，等吞吐量比较下每用户速度提升57%到78%。

动态验证预算的调度行为也被详细记录：在低并发阶段，调度器把每个请求的平均验证长度扩展到4到6个词（相比MTP-1固定的2词大幅增加），充分利用闲置的计算资源；随着并发请求数量增加，验证长度平滑下降，在高并发状态下自动收缩到接近MTP-1的水平，保护了其他等待服务的请求。这种自适应行为不需要任何手动调节，完全由硬件容量曲线和实时置信度分数自动驱动。

八、问题的边界：DSpark尚未解决什么

这篇论文的一个值得赞赏之处是，研究团队在最后坦诚地指出了DSpark当前方案的局限性。

核心局限在于草稿生成阶段的"固定成本"问题。无论调度器最终决定验证多少个草稿词，并行骨干网络都必须为完整的最大草稿长度（γ=5）做一次完整的前向计算，无法提前退出。对于那些本身接受率极低的请求（比如让AI生成高度创意性、极度开放式的内容），草稿被接受的概率本来就不高，这次骨干网络的计算实际上大部分都被浪费了，无法回收。研究团队提出了一个未来可能的优化方向：在草稿模型内部引入"基于难度的早退出"机制，对于那些显然会产生低质量草稿的请求，允许骨干网络在中间层提前终止计算，跳过剩余层次，直接输出基于当前层信息的草稿预测，以降低无效计算的绝对消耗。

归根结底，DSpark代表了一次系统性的工程与算法协同设计的成功实践。它没有单点突破，而是在草稿质量、置信度估计、调度策略和计算内核四个层面同时做出针对性的改进，让每个环节的改进都与其他环节形成正向协同。特别是它对"无损"这一理论约束的处理方式——不是绕开约束，而是通过精心的算法设计（早停机制、异步调度形成的因果屏障）在满足约束的前提下最大化性能——体现了严谨性与实用性的平衡，也为后续的研究工作提供了一个可复用的思路框架。

目前，团队已经开源了DSpark在DeepSeek-V4-Flash和DeepSeek-V4-Pro上的模型权重，以及包含Eagle3、DFlash和DSpark完整实现的训练代码库DeepSpec，有兴趣复现或继续研究的读者可通过论文编号arXiv:2607.05147找到完整信息和相关链接。

Q&A

Q1：投机解码（Speculative Decoding）是什么原理，为什么能加速AI生成文字？

A：投机解码的原理是"先猜后验"：用一个小而快的草稿模型提前猜出多个可能的词，再一次性交给大模型并行审核所有猜测。大模型的"审核"操作天然支持并行计算，所以一次审核可以同时确认多个词。只要草稿猜得足够准，每次大模型运算就能产出多个词，整体生成速度自然大幅提升，且最终输出质量与大模型直接生成完全一致。

Q2：DSpark的半自回归架构相比纯并行草稿有什么具体优势？

A：纯并行草稿预测每个词时不知道前面的词是什么，容易产生前后矛盾的组合（如"of problem"）。DSpark在并行骨干网络之后，加了一个轻量的马尔可夫过渡模块，根据前一个词微调当前词的概率分布。这个模块计算量极小，只增加约0.2%到1.3%的延迟，但能让草稿的前后文连贯性大幅提升，使接受长度比纯并行草稿提升16%到30%。

Q3：DSpark的硬件感知调度器如何决定每次验证多少个草稿词？

A：调度器在系统启动时，预先测量不同批处理大小下GPU每步的计算速度，形成一张容量表。运行时，它把所有并发请求的草稿词按"前缀生存概率"（即这个词及其前面所有词都被接受的联合概率）从高到低排序，逐个纳入验证，同时用容量表实时估算当前方案的预期总吞吐量，一旦吞吐量不再增长就立即停止，保证资源分配的全局最优。