DeepSeek联手北大发布DSpark：AI回答不再“蹦字”，生成速度最高提升85%

大模型推理速度的瓶颈，正在被一项新的系统工程创新打破。 6月28日，DeepSeek与北京大学团队联合发布论文《DSpark: Confidence-Scheduled Speculative Decoding with Semi-Autoregressive Generation》，提出了一套名为DSpark的大模型推理加速框架。论文披露，DSpark已进入DeepSeek-V4-Flash preview和DeepSeek-V4-Pro preview的生产服务系统，并替代了此前的MTP-1方案。 在线上真实用户流量中，在系统总吞吐水平相同的情况下，DSpark将DeepSeek-V4-Flash的单用户生成速度提升了60%至85%，将DeepSeek-V4-Pro的单用户生成速度提升了57%至78%。这意味着，用户等待AI回复时的“挤牙膏”感将大幅缓解。

主流语言模型采用自回归（autoregressive）方式生成文本：每生成一个token，都需要以前文为条件进行一次前向计算。输出越长，解码步骤越多，延迟累积越明显。在实时聊天、多轮智能体工作流、代码助手等高交互场景下，这种延迟直接影响用户体验和GPU利用率。 推测解码（speculative decoding）是解决这一问题的关键方向。其思路是让一个轻量级的“草稿模型”快速生成候选token，再由主模型一次性验证这些候选。通过验证的token被接受，被拒绝的则被丢弃。由于验证阶段可以并行完成，推测解码能在不改变输出分布的前提下提升生成速度。 然而，现有方案存在明显局限。自回归草稿模型虽候选质量高，但草稿生成本身也需逐步进行，速度受限；并行草稿模型可一次性生成多个候选，但内部token之间缺乏依赖关系，容易产生前后不一致的组合，且越往后被主模型接受的概率越低——论文将这一现象称为“后缀衰减”。 更现实的问题在于线上服务：并行草稿模型往往生成很长的候选块，但在高并发场景下，验证那些大概率被拒绝的token会占用批处理容量，影响其他用户请求。换言之，问题已不仅是“能否一次生成更多token”，而是“哪些token值得验证”。

DSpark从生成和验证两侧同时入手。 在生成侧，DSpark采用半自回归架构（semi-autoregressive architecture）。它保留并行草稿模型的主干，让大部分计算一次完成，同时在输出端加入一个轻量级顺序模块，使后续token能参考前面已采样的token。论文默认使用Markov head（建模相邻token转移关系），也测试了RNN head（保留更长块内历史），最终因Markov head计算成本低、部署方便而作为默认方案。这种设计兼顾了并行草稿的速度和自回归草稿的连贯性。 在验证侧，DSpark引入基于置信度调度的验证（confidence-scheduled verification）。系统为每个候选位置预测一个置信度分数，表示在前面的token已被接受的前提下，当前位置继续被接受的概率。随后，硬件感知前缀调度器（hardware-aware prefix scheduler）根据三个因素动态决定每个请求的验证长度：当前系统负载、各候选位置的置信度、引擎在不同批大小下的吞吐曲线。 这意味着DSpark不会机械地验证固定长度的候选块。系统空闲时，它验证更长的前缀，让一次主模型前向计算产出更多有效token；系统繁忙时，它缩短低置信度请求的验证长度，减少对批处理容量的占用。这种动态调度更贴近真实生产环境——它不只追求单次生成更多候选，还根据负载调整验证预算。

离线实验中，论文在Qwen3-4B、Qwen3-8B、Qwen3-14B和Gemma4-12B四个目标模型上测试DSpark，并与自回归草稿模型和并行草稿模型两类代表方案对比，结果显示DSpark在生成速度和候选接受率上均取得显著提升。 从行业视角看，DSpark的发布标志着大模型推理优化正从单一算法创新走向系统工程整合。正如论文所暗示的，大模型的尽头是复杂的系统工程问题——如何平衡生成质量、速度与系统负载，已成为各厂商竞争的关键。 对于普通用户而言，DSpark带来的最直接感受可能是：AI回复不再“蹦字”，对话流畅度大幅提升。而对于开发者，这一框架的开源（论文及代码已发布于GitHub）意味着更高效的推理工具可供借鉴。 AI大狗（AIdadog.com）认为，随着DSpark这类兼顾算法与工程优化的方案成熟，大模型在实时交互场景下的落地门槛将进一步降低。无论是聊天机器人、代码助手还是智能客服，更快的推理速度都将直接转化为更好的用户体验。