当前位置：首页 > news >正文

融完500亿！DeepSeek创始人又又又亲自下场，把AI推理提速85%还全开源

news 2026/6/30 10:56:15

刚融完500亿，创始人亲自下场写代码：DeepSeek不卷参数，专治AI“嘴慢”

在AI圈，大家似乎都患上了一种“参数焦虑症”。模型越来越大，跑分越来越高，但真到了用的时候，那个转圈圈的光标还是让人等到心梗。

就在6月中旬刚拿下500亿融资的十几天后，DeepSeek没有像外界预期的那样发布一个万亿参数的新怪兽，而是联合北京大学甩出了一篇硬核论文——DSpark。更让行业震动的是，论文作者名单里，赫然写着创始人梁文锋的名字。

论文标题：《DSpark: Confidence-Scheduled Speculative Decoding with Semi-Autoregressive Generation》

论文链接：https://github.com/deepseek-ai/DeepSpec/blob/main/DSpark_paper.pdf

在资本狂欢的当下，创始人依然亲自下场啃工程硬骨头，这本身就是一个强烈的信号：DeepSeek正在从“实验室刷榜”转向“解决真实世界的痛点”。

为什么AI说话总是慢半拍？

要理解DSpark，先得搞懂大模型为什么慢。

大模型生成文字的方式叫“自回归”，说白了就是“一个字一个字往外蹦”。每蹦出一个字，大脑（GPU）都要完整地思考一遍。这就像一位老教授写评语，必须写完上一个字，才能想下一个字，写得越长，等得越久。

为了解决这个问题，业界发明了“推测解码”技术。你可以把它想象成“教授+实习生”的配合模式：先让一个轻量级的“实习生”（草稿模型）快速猜出一段话，然后“教授”（大模型）一次性批量检查。猜对了就采纳，猜错了就改。因为教授可以并行检查多个字，效率自然大幅提升。

听起来很完美，但现有的“实习生”都有毛病：

串行派（如Eagle3）：实习生一个字一个字猜，依赖关系建模能力强、接受率高，但猜得太慢，且只能使用短候选块和浅层网络，教授还是得干等。
并行派（如DFlash）：实习生一口气猜一整段，速度是快了，但因为每个位置独立预测、无法建模块内token依赖，经常出现多模态冲突。教授检查时发现后半段全是错的，接受率迅速衰减，白白浪费了算力。

DSpark的诞生，就是为了造出一个既快又准的“完美实习生”。

DSpark的两招“神技”：让实习生变聪明

DSpark没有改变大模型本身的智力，而是通过两项互补机制，把“猜测-验证”这个配合流程优化到了极致。

1. 半自回归生成：让实习生“边看前文边猜”

以前的并行猜测是“盲猜”，每个字独立生成，不管前后文。DSpark保留了并行主干的高吞吐优势，同时加入了一个轻量级顺序模块逐token注入前缀依赖信息。该模块提供两种实现：仅依赖前一个token的马尔可夫头，以及通过循环状态累积完整前缀信息的RNN头。

💡通俗解读
实习生不再闭眼瞎猜，而是会瞄一眼前面已经猜好的字，再决定下一个字怎么写。既保留了一口气猜一段的速度优势，又因为有了上下文参考，猜得更准了。

实验数据很惊人：仅用两层Transformer深度的DSpark，在所有测试领域上都超过了五层DFlash的接受长度。以Qwen3-4B/8B/14B为例，宏平均接受长度相对Eagle3提升30.9%、26.7%、30.0%，相对DFlash提升16.3%、18.4%、18.3%。少量“回头看”的能力，比单纯堆砌网络层数管用得多。

2. 置信度调度验证：教授学会“挑重点批改”

以前教授是把实习生猜的所有字都从头到尾检查一遍。DSpark引入置信度头评估每个token在给定前缀下的“存活概率”，并在训练完成后通过“时序温度缩放”后验校准方案修正原始置信头置信度过高的问题。在此基础上，硬件感知前缀调度器根据实时引擎吞吐量动态决定最优验证长度，优先将算力分配给预期回报最高的token。

💡通俗解读
教授不再傻乎乎地全批一遍，而是先看实习生最有把握的那几个字。如果发现后面几个字“自信分”太低，大概率是错的，就直接打住，不再浪费精力去验证后面的废话。系统忙的时候少查点，闲的时候多查点，始终让整体吞吐量保持在最优状态。

值得注意的是，论文实验还揭示了显著的领域差异效应：结构化任务（如数学推理、代码生成）的可接受长度天然更高（例如Qwen3-4B在数学任务上平均为5.57，代码任务为5.12），而开放式对话场景则明显偏低（仅3.49）。

不止是算法，更是“工业级”的系统魔改

如果DSpark只停留在论文里，那它顶多是个优秀的学术成果。但它真正的杀手锏是深入GPU底层的工程落地能力。在真实的高并发生产环境中，“动态验证”会引发两个致命的工程灾难，DeepSeek团队对此进行了底层改造：

工程痛点	问题本质	DSpark的解法	通俗理解
GPU流水线停滞	CUDA图重放要求下一轮批处理大小提前确定，同步调度会导致GPU干等。	异步调度器：用“两轮前的历史置信度”预测本轮截断长度，隐藏调度延迟。	不等当前结果出来再决定下一步干嘛，而是根据“上上次的经验”提前预判并准备好，让GPU永远有活干。
内核利用率暴跌	动态变长验证导致标准解码内核因填充和负载不均效率大减。	物理解耦+稀疏注意力：将所有token展平为独立元素处理，通过标记张量传递序列内依赖关系。	不再按“句子”排队处理，而是把所有字拆成“散装零件”统一加工，再通过标签拼回原句，彻底消除等待和浪费。

除了推理阶段的魔改，团队在训练阶段也做到了极致优化：并行训练时仅传递目标模型的隐藏状态而非完整词表logits，将通信复杂度从O(V)降至O(d)；采用锚点定长序列打包策略，将训练序列中随机采样的多个预测块压缩为密集批次，避免传统填充带来的计算和内存开销。

正是这些看不见的“脏活累活”，让DSpark在真实用户流量下交出了恐怖的成绩单：

在V4-Flash引擎上，当SLA收紧至120 token/s时，单token基线MTP-1已接近运行边界，DSpark在维持可用并发批处理的前提下实现了标称661%的吞吐量优势；保证单用户生成速度不低于80 token/s时，聚合吞吐量相比基线提升51%。
在V4-Pro引擎上，35 token/s的SLA下吞吐量提升52%，50 token/s的SLA下提升406%。
在匹配的实际吞吐量水平下，V4-Flash单用户生成速度提升60%-85%，V4-Pro提升57%-78%。
调度器在系统并发数较低时分配4至6个token的验证长度充分利用空闲资源，随并发数上升平滑缩减验证长度避免资源争用，表现出负载自适应的验证预算分配能力。

坦诚的局限与开源的诚意

DSpark并非完美无缺。团队坦言，对于本身可预测性极低、接受率偏低的复杂查询，即使后缀token最终被调度器截断，并行主干仍需为所有请求生成完整的初始候选块，这部分前置草稿算力无法回收。未来的优化方向可在草稿模型内部引入难度感知的早退出机制，使此类请求能够跳过完整块生成流程。但这恰恰体现了技术团队的务实——对短板有清晰认知，且已有后续优化路线图。

更重要的是，DeepSeek将这套方案连同DFlash、Eagle3一起，在DeepSpec项目中完全开源（MIT许可）。DeepSpec是一个用于训练和评估推测解码草稿模型的全栈代码库，包含数据准备工具、草稿模型实现、训练代码和评估脚本。这意味着，无论是缺乏底层算法团队的中小企业还是ToB服务商，无需投入巨额研发，就能复用这套成熟的推理优化方案。智能体、工业代码、金融舆情等场景的规模化落地门槛，被大幅拉低了。