# DeepSeek：最新DSpark论文解读 AI智识录 · 2026-06-30 本期解读DeepSeek联合北京大学发表的DSpark论文：一套基于置信度调度推测解码与半自回归生成的框架，在真实部署中使单用户生成速度提升60%—85%，高并发场景下系统有效吞吐量提升4倍，两层DSpark即可匹敌此前五层架构。节目先剖析大模型推理瓶颈不在浮点算力而在显存带宽，推测解码虽以草稿模型猜加大模型验证的方式提速，却存在两大结构性困境——并行草稿越靠后token接受率衰减严重、固定长度草稿验证浪费算力。DSpark的应对是半自回归架构：在并行骨干上叠加极轻量的马尔可夫头，仅依赖前一个token重标定概率，经低秩分解将额外开销压缩至0.2%—1.3%，草稿有效接受长度最高提升30%。其次是置信度调度验证：草稿模型输出每个token的存活概率，硬件感知前缀调度器依据GPU吞吐曲线动态裁定验证范围并对低置信token早停，配合在线草稿器校准把预期校准误差从8%压至约1%。实验显示相比Eagle3平均接受长度提升近30%，相比DFlash提升16%—18%；DeepSeek已将含Eagle3、DFlash与DSpark的DeepSpec全栈训练库开源。 ## Questions this episode answers ### 什么是推测解码？它为什么能加速大模型推理？ 主播解释，推测解码是"猜+验"模式：轻量的草稿模型像小助理一样先快速猜出候选句子，再由大模型老板一次性验证，对的留下、错的划掉。输出质量与老板自己写的一模一样、没有任何损失，但速度起飞。核心公式是每字耗时等于草稿加验证时间除以通过字数。 [2:05](https://ai.podhood.com/d29478f3-247b-4891-8fe8-babe9352d011?t=125000) ### DSpark的半自回归架构是怎么解决并行草稿后缀衰减问题的？ 主播介绍，DSpark保留DFlash式并行骨干网络一口气生成底稿，再叠加极轻量的马尔可夫头，只依赖前一个token对当前token做概率重标定。通过低秩分解，草稿从4字扩到16字仅增加0.2%到1.3%延迟，老板可接受的字数长度最高提升30%，解决了越往后越瞎写的衰减问题。 [5:06](https://ai.podhood.com/d29478f3-247b-4891-8fe8-babe9352d011?t=306000) ### DSpark的置信度调度验证机制是如何工作的？ 主播讲解，草稿模型交稿时须用置信度头预估每个token的存活概率，硬件感知前缀调度器再结合离线测好的GPU吞吐曲线，用贪心算法按概率从高到低把候选词塞进验证批次，发现期望吞吐下降就果断早停砍掉低置信度token，实现可变长度验证，且全部在GPU内部执行，无需CPU插手。 [7:04](https://ai.podhood.com/d29478f3-247b-4891-8fe8-babe9352d011?t=424000) ### DSpark在线上部署的实际效果如何？ 主播引用论文数据：DeepSeek把该技术用于自家V4线上生产环境，相同系统吞吐量下V4/Flash的每用户生成速度提升60%到85%；高并发下系统有效吞吐量翻4倍；面对每秒120个字的SLA要求，硬件感知调度器稳住底线，把帕累托前沿往外推了一大圈。 [10:23](https://ai.podhood.com/d29478f3-247b-4891-8fe8-babe9352d011?t=623000) ## Key moments - **[0:00] 开场引入** - [0:13] DeepSeek发布DSpark推测解码方案：单用户生成速度飙升85%，高并发吞吐量翻4倍 - **[0:57] 算力瓶颈** - [1:10] 大模型推理瓶颈不在算力而在显存带宽：图书馆搬书比喻解释GPU为何算10个字只比1个字慢一点 - **[1:55] 推测解码** - [2:05] 推测解码的"猜+验"模式：草稿模型先猜词，大模型一次性验证，输出质量无损但速度起飞 - **[3:19] 前人方案** - [3:31] 并行草稿的后缀衰减问题：DFlash一口气生成十几个字，越往后越胡言乱语被大模型毙掉 - **[5:06] 半自回归** - [5:19] DSpark半自回归架构：马尔可夫头只看前一个字重标定概率，仅增0.2%—1.3%延迟却让接受长度提升30% - **[6:52] 置信度调度** - [7:04] DSpark置信度调度验证：硬件感知前缀调度器按存活概率贪心排序，低置信度token早停砍掉不浪费算力 - **[8:43] 在线校准** - [8:43] 在线草稿器校准技术：用顺序温度缩放把预期校准误差从8%压到约1%，防止草稿模型盲目自信 - **[9:27] 实验数据** - **[10:23] 线上部署** - [10:23] DSpark线上实测：V4/Flash每用户生成速度提升60%—85%，SLA高并发下吞吐量不再断崖式下跌 - **[11:18] 开源收官** - [11:18] DeepSeek开源DeepSpec全栈训练库：包含Eagle3、DFlash与DSpark，支持外部模型供全球开发者使用 - **[11:47] 结尾广告** ## Mentioned DeepSeek (company), Claude (product), DFlash (product), DSpark (product), DeepSpec (product), Eagle (product), Eagle3 (product), Gemma (product), GitHub (product), Unavi (product) ## Transcript ### 开场引入 **Host** [0:00] Hello， 各位听众朋友们大家好 。 如果你平时关注 AI 大模型的动向 ， 那你一定听说过 DeepSeek 最近搞出的大动作 ： 他们发布了一篇新论文 ， 提出了一个叫做 DSpark 的推测解码方案 。 这东西一出来就在 GitHub 上光速揽下了 1.4K 的 star。 为什么它这么火 ？ 我们先来看个数据 ： 用了 DSpark 之后， 单用户的生成速度直接飙升了 85%，而且在成千上万个人同时用的高并发场景下， 系统的有效吞吐量 ， 注意 ，是直接翻了 4 倍 。 两层的 DSpark 性能居然能打得过以前五层的架构 ？ 那这个 DSpark 到底是个什么神仙技术 ？ 它里面藏着什么黑科技 ？ 今天咱们就抛开那些晦涩难懂的学术术语 ， 原汁原味地顺着这篇论文的思路 ， 带大家一步步看懂这套被誉为 " 算法 、 调度 、 硬件三位一体工程闭环 " 的顶级设计 。 ### 算力瓶颈 **Host** [0:57] 首先 ， 我们在论文的开篇和背景里 ， 要先聊清楚 " 大模型 " 目前的痛点到底在哪 。 大家都知道 ， 咱们用大模型的时候 ， 字是一个一个蹦出来的 。 这主要是因为目前大模型推理的瓶颈 ， 根本就不在它的 " 脑子 "，也就是浮点运算的算力上 ，而是在 " 腿脚 " 上 ，也就是显存带宽 。 你可以这么理解 ： 这就好比你要去图书馆翻一本书 ， 看一页内容其实一秒钟就看完了 ，但你从书架上把这本厚厚的书搬到桌子上， 要花 1 分钟 。 所以 GPU 同时去算 10 个字 ，其实只比算 1 个字慢那么一点点 。 为了不让这来回搬书的时间白白浪费 ， 我们就得用上这篇论文提到的第一个概念 ： 批处理解码 。 就跟送外卖一样 ， 跑一趟送一单和一趟送十单 ， 路上的时间是差不多的 ， 所以咱们的外卖箱里塞的订单越多越划算 。 但是哪怕你批处理把箱子塞满了 ， 逐字生成的模式还是太慢了 。 于是业界就发明了一个骚操作 ， 叫做 " 推测解码 "。 ### 推测解码 **Host** [2:05] 这是 DSpark 这篇论文立足的根本 。 什么叫推测解码 ？ 我们可以把它理解为 " 猜 + 验 " 的模式 。 以前是大模型老板自己苦哈哈地逐个字写报告 ， 现在呢 ？ 我们给大老板配一个小助理 ， 叫 " 草稿模型 "。 小助理写字特别快 ， 它先噼里啪啦猜出后面好几个词 ， 形成一个候选句子 ， 然后一次性递给大老板 。 大老板作为力量型选手 ， 一眼扫过去 ， 用它庞大的知识库做一次验证 ： 对的字留下， 错的字直接划掉 。 然后老板亲自写上正确的那个字 ， 接着再让助理往下猜 。 这种方法能保证最终输出的质量和老板自己写的一模一样 ， 没有任何损失 ，但速度却起飞了 。 不过呢 ， 论文的背景介绍里也特别指出 ： 在这个世上， 推测并不是免费的 ， 小助理猜也是要花时间的 。 所以这背后的核心公式很简单 ： 你生成每个字耗费的时间 ， 等于助理写草稿的时间加上老板验证的时间 ， 再除以老板最后点头通过的字数 。 也就是说 ， 想要快 ， 只有 3 条路 ： 让助理猜得再快点 ； 让助理猜得再准点 ； 或者让老板验得再聪明点 。 在 DSpark 出现之前 ， 大家其实为了这 3 条路 ， 已经踩过很多坑了 。 比如以前的助理怎么写草稿 ： 有一派叫 " 自回归草稿 "， 就是一个字一个字接着写 。 ### 前人方案 **Host** [3:31] 这一派里有个典型叫 Eagle 架构 ， 它是站在巨人的肩膀上， 直接把大模型老板最后一点脑电波 （ 隐藏状态 ） 拿过来加个小脑袋接着猜 ， 又快又准 。 这套思路也是 DeepSeek 一直在用的基础 。 后来又出现了一派叫做 " 并行草稿 "， 典型的代表叫 DFlash 技术 。 这一派特别生猛 ， 助理直接 " 啪 " 一下， 一口气把十几个字的草稿拍在桌上 。 速度是极快的 ，但有个致命问题 ： 学术上叫 " 多模态碰撞 " 和 " 后缀衰减 "，是什么意思呢 ？ 因为助理是一次性把 10 个字憋出来的 ， 它在写第 8 个字的时候 ， 根本没参考它自己刚才写的第 7 个字是什么 。 结果就是 ： 一句话前两三个字还挺靠谱 ， 越往后越是胡言乱语 。 老板一看 ， 这后面写的什么狗屁不通的东西 ， 直接毙掉 。 所以越靠后的字 ， 被接受的概率就断崖式下降 。 更惨的是 ，以前大老板验证草稿的方式非常死板 。 哪怕小助理瞎写了 15 个字 ， 老板每次也得老老实实把这 15 个字全都看完 。 你想想 ， 平时不忙的时候也就算了 ， 一旦到了晚高峰 ， 服务器里全是几十万用户的并发请求 ， 老板每一分每一秒的算力都极其宝贵 。 这个时候你还让老板花大把时间去看那些注定会被毙掉的废话 。 这就严重浪费了刚才说的批处理容量 ， 拖垮了整个系统的吞吐量 。 好 ， 前人的痛点全清楚了 。 第一 ， 助理一口气猜出来的草稿 ， 越往后越不准 。 第二 ， 老板死板地验证所有草稿 ， 太浪费算力 。 ### 半自回归 **Host** [5:06] 接下来进入这篇论文最核心的 " 架构设计 " 环节 ：DSpark 到底是怎么把这两个死结解开的 。DSpark 放出的第一大绝招 ， 叫 " 半自回归架构 "。 这名字听着吓人 ，其实它的核心理念就四个字 ： 两头都要 。 它把 DFlash 的并行和 Eagle 的串行巧妙地缝合在了一起 。 具体是怎么干的呢 ？ 第一步 ，DSpark 先保留了 DFlash 那种一口气并行生成的骨干网络 ， 把速度拉满 ， 一瞬间把所有字的基础底稿给 " 变 " 出来 。 第二步 ， 它在底稿后面加了一个非常轻量级的顺序头 ， 从前往后快速地把这些字顺一遍逻辑 。 论文里特别提到 ，他们用了一个叫 " 马尔可夫头 " 的轻巧模块 ， 它极其专一 。 它在修改当前字的时候 ， 只看前一个字 。 比如前一个生成的字是 "off"， 它立马反应过来 ， 后面的字大概率是 "course"。 于是把 "course" 的概率拉高 ， 把什么 "problem" 的概率压下去 。 就是这么一个极低成本的串行小动作 ， 通过数学上的 " 低秩分解 "， 把计算量压到了几乎可以忽略不计的程度 。 有多夸张呢 ？ 论文里测算 ， 哪怕把小助理的草稿长度从 4 个字扩展到 16 个字 ， 用这个马尔可夫头顺逻辑 ， 系统只增加了 0.2% 到 1.3% 的延迟 ， 几乎没感觉 。 但是大老板能接受的字数长度 ， 最高提升了足足 30%。 这就完美解决了助理写草稿越往后越 " 瞎写 " 的衰减问题 。 论文里其实还试了另一种能记住更多历史信息的 RNN 头 ，但发现带来的好处抵消不了它多花的成本 ， 反而不如马尔可夫头实在 。 所以说 ， 大道至简 ， 解决了助理猜得准的问题 。 接下来 ， 老板的时间怎么管理 ？ 这就引出了论文里的第二大核心绝招 ： 置信度调度验证 。 ### 置信度调度 **Host** [7:04] 这套机制给小助理提了个新要求 ： 交草稿的同时， 你必须带个 " 置信度头 " 给自己打分 。 小助理要预估自己写的每个字存活下来的概率有多大 。 比如助理交了 10 个字 ， 上面标着 ： 老板 ， 前 4 个字我 90% 确定 ， 第 5 个字我只有 40% 把握 ， 后面几个大概率是我瞎蒙的 。 拿到这个存活概率之后， 系统里就登场了一位 " 神级管家 "， 叫做 " 硬件感知前缀调度器 "。 这个管家太聪明了 ， 它不仅知道助理有多自信 ， 它对 GPU 引擎在不同负荷下的吞吐能力更是了如指掌 。 系统提前在离线状态下就测好了引擎的吞吐曲线 。 管家会把全网所有用户的草稿全都拿过来排在一起 ， 算一笔经济账 。 管家会用一种 " 贪心算法 "， 根据存活概率 ， 从高到低把所有的候选词排个序 ， 优先把最靠谱的字塞进老板的验证批次里 。 当管家发现再往里塞那些不靠谱的字 ， 期望能赚到的吞吐量反而会下降的时候 ， 它会极其果断地 " 早停 "， 喊 " 卡 "， 停 ！ 后面概率低的字不看了 ， 直接砍掉 ，不浪费老板时间 。 这就是 " 可变长度 " 的草稿验证 。 这个调度逻辑精妙到了什么地步呢 ？ 它完全是在 GPU 内部自己执行的 ， 根本不需要 CPU 跑过来插手 ， 没有任何信息延迟和未来的信息泄露 ， 实现了真正的 " 动态无损 "。 但是呢 ， 这套完美机制还有一个小漏洞 ， 那就是助理有时候会 " 盲目自信 "， 对那些根本不对的词也打高分 。 ### 在线校准 **Host** [8:43] 为了防止小助理瞎吹牛 ，DSpark 又补上了一个杀手锏 ， 叫做 " 在线草稿器校准 "。在系统运行的时候 ， 系统会像个监考老师一样 ，不断观察助理真实的命中率 。 如果是写代码这种严谨的任务 ， 一出错全盘皆输 ， 系统就会对助理要求严格一点 ； 如果是平时闲聊 ， 可以稍微宽容一点 。 它在后台用了一个叫 " 顺序温度缩放 " 的技术 ， 像个微调旋钮一样 ，在不改变词语排序的前提下， 自动校准助理的自信心 。 论文里展示 ， 这一手直接把预期校准误差从之前吓人的 8% 硬生生压到了 1% 左右 ， 真正做到了 " 运行时自适应 "。 讲到这里 ， 整个 DSpark 从生成到调度的核心架构 ， 大家应该都清楚了 。 那这套精密的机器 ， 跑起来到底有多生猛呢 ？ ### 实验数据 **Host** [9:36] 我们最后跟着论文来看看实验数据和真实的线上部署 。在离线实验阶段 ， 团队拿它在 Claude 3 和 Gemma 4 这两大主流开源模型上跑了一圈 ， 无论是 4B、8B 还是 12B、14B 的大小 ，DSpark 都展现出了 " 统治级 " 的优势 。 相比纯串行的 Eagle3， 它的红平均接受长度提升了将近 30%； 相比纯并行的 DFlash， 提升了 16% 到 18%。 特别是在数学和代码这种逻辑严密的场景里 ，DSpark 那种 " 动态剪裁 " 烂尾草稿的能力 ， 发挥得淋漓尽致 。 大家要记住 ， 所有这些炸裂的数字 ， 都是以 DeepSeek 原本就已经优化得很好的 MTP 基线作为对比的 。 但这还不算最狠的 。 ### 线上部署 **Host** [10:23] 论文的最后一部分写到 ，DeepSeek 直接把这套技术丢到了自家的 V4 线上生产环境里 ， 去经受真实世界的毒打 。在真实的服务系统里 ，DSpark 交出的答卷是 ： 在相同的系统吞吐量下，V4/Flash 的每用户生成速度提升了 60% 到 85%。 更了不起的是 ， 对于那种有极其严格响应要求的任务 ， 比如规定每秒必须吐出 120 个字 （SLA）， 以前的基线系统遇到并发一高 ， 直接就崩溃卡壳了 ， 吞吐量断崖式下跌 。 但 DSpark 凭着它那个极其聪明的 " 硬件感知调度器 "， 稳稳地拖住了底线 。 这就相当于在不增加物理机器的情况下， 它硬是把整个服务系统的帕累托前沿 ，也就是性能天花板 ， 又往外推了一大圈 。 故事到这里 ， 本来已经很圆满了 ，但在论文的结论部分 ，DeepSeek 再次展现了顶级技术团队的格局 。他们没有把这套 " 压箱底的绝活 " 藏着掖着 ，而是把包含了 Eagle3、DFlash 和 DSpark 在内的整个 DeepSpec 全栈训练库一并开源了 。 ### 开源收官 **Host** [11:36] 而且代码写得非常通用 ，不仅支持自家模型 ， 还支持外部模型 ， 直接供全世界的 AI 开发者研究使用 。 难怪在 GitHub 上立刻就爆火了 。 好了 ， 今天的分享就到这里 ， 欢迎订阅 《AI 知识路 》， 获取最新鲜的 AI 领域最新知识 。 最后插播一个广告 ： 主播自己的 AI 创业产品 UNAVI， 一个能一键整合你的飞书 、 钉钉 、 腾讯会议 、Claude 和其他录音卡 、 录音豆 ， 随时随地帮您解读日常会议与沟通背后的深意 。 ### 结尾广告 **Host** [12:08] 锁定关键信息的 Agent 应用已经正式上线 ， 最新的版本也支持了直接给它播客链接 ， 它就能轻松完成转写 、 总结 、 分析 ， 甚至多个播客的关联解读和分析 。 如果你有兴趣 ， 欢迎在本播客的公告栏查看体验方式 ， 我们下期见 。 --- 本节目库由 PodHood（https://podhood.com）提供支持——播客网站平台。