让大模型"跑得更快"的一招：读懂 DeepSeek 的 DSpark
2026 年 6 月 27 日，DeepSeek 发布了一篇由创始人梁文锋署名、联合北京大学完成的论文，标题是《DSpark：基于半自回归生成的置信度调度推测解码》。论文以 PDF 形式开源在 DeepSeek 官方 GitHub 仓库（deepseek-ai/DeepSpec），同时放出了配套的训练框架 DeepSpec，以及两个挂载了加速模块的模型检查点——DeepSeek-V4-Pro-DSpark 和 DeepSeek-V4-Flash-DSpark。这是 DeepSeek 在完成首轮外部融资之后拿出的第一个开源成果，发布当天就冲上了 Hacker News 前排。
需要先说清楚一件容易被误会的事：DSpark 不是一个新的大模型，它不会让 DeepSeek 变得”更聪明”，benchmark 分数也不会因此提高。它解决的是另一个问题——让已经训练好的 V4 模型，在不增加一张显卡、不重新训练、不损失任何输出质量的前提下，回答得更快。按 DeepSeek 自己公布的数据，在真实线上流量下，单用户的生成速度比上一代方案快了大约六到八成。
顺带一提，这个名字很容易和英伟达的 NVIDIA DGX Spark 搞混。后者是一台桌面级的”个人 AI 超算”小主机，2025 年开售、起售价约 4000 美元，能在本地跑两千亿参数级别的模型——那是硬件产品，和这篇论文毫无关系。DSpark 是 DeepSeek 一个推理加速算法的代号。
大模型为什么慢
要理解 DSpark 的价值，得先知道大模型生成文字时卡在哪里。
大语言模型是”一个字一个字往外蹦”的，术语叫自回归解码。每蹦出一个字，都要把整个庞大的模型完整地跑一遍。对像 V4-Pro 这样有 1.6 万亿参数的巨型模型来说，这个过程的瓶颈不在算力，而在内存带宽——GPU 的计算单元大量闲置，时间都耗在反复把模型权重从显存搬进搬出。换句话说，撞上的是”内存墙”，而不是”算力墙”。这就是为什么你用大模型时，长回答会一段一段地”挤牙膏”，高峰期还容易转圈。
业内有一个用了好几年、却一直”差口气”的老办法来对付这个问题，叫推测解码（Speculative Decoding）。它最早由 Google 团队在 2023 年正式提出。思路像”师傅带徒弟”：先让一个又小又快的”草稿模型”一口气猜出后面好几个字，再让真正的大模型这位”老师傅”一次性批改这一串草稿。猜对的直接采用——相当于一次完整计算白赚了好几个字；猜错的丢掉重来。
这里有个关键细节：批改用的是数学上的”拒绝采样”，能严格保证最终输出和大模型逐字生成的结果完全一致。所以推测解码是无损加速，只快不傻。
问题在于，这个”草稿模型”很难伺候——要同时做到又快、又像、又准，三年来始终顾此失彼，所以这项技术一直处在”快能用却总没用好”的状态。
DSpark 聪明在哪
过去的草稿方法卡在一个两难里。一种像 Eagle3 那样”串行”地一个字一个字猜，质量高，但慢；另一种像 DFlash 那样”并行”地把后面几个字一次全猜出来，快，但越往后越乱——前面的字还行，后面的字因为缺少上下文依赖，会逐渐跑偏，论文里管这叫”后缀衰减”。
DSpark 走的是一条中间路线，核心有三招。
第一招叫半自回归生成。它用并行的方式快速出草稿主干来保速度，再在上面叠加一个极其轻量的串行小模块，专门给后面几个字补上”看前文”的能力，让句子不至于散架。这个小模块用了低秩分解，成本压得很低，既留住了并行的快，又找回了串行的准。
第二招叫置信度调度校验。它给每个草稿字配了一个”打分器”：对那些自己都没把握的草稿，干脆直接剪掉、不浪费算力去送审；同时还会观察 GPU 当前忙不忙——空闲时就多验几个字，繁忙时就少验，把资源用在刀刃上。
第三招是零开销调度，通过异步的方式把调度本身的延迟藏起来，不让它拖后腿。
三招合起来，就是在不动模型、不加硬件的情况下，把 V4 的吐字速度显著抬高，而且因为底层还是拒绝采样，输出质量分毫不差。对普通用户，体感就是回答更快、长文本更顺、高峰期更稳；对做 Agent、代码生成、长文档处理的开发者，等待时间的下降会很直接。
数据怎么看
DeepSeek 公布了两类结果。
在离线基准上（覆盖数学、代码、对话三类共九个数据集），DSpark 每轮被接受的草稿长度比此前最强的 Eagle3 高出约 27% 到 31%，比 DFlash 高出约 16% 到 18%；甚至只用两层的 DSpark 就能超过五层的 DFlash。在真实生产环境里（DeepSeek-V4 线上流量），单用户生成速度的提升是：Flash 版约 60% 到 85%，Pro 版约 57% 到 78%；随着并发用户增多，聚合吞吐量的提升幅度更大。
这些数字很亮眼，但读的时候要留几分清醒。
一是全部来自 DeepSeek 自报，截至发稿还没有第三方独立复现。二是比较的基线是自家上一代技术（叫 MTP-1，本身已经能一次出两个字），跑在自家的基础设施上——所以”快 60% 到 85%“是相对这个已经不慢的起点而言；如果对照最传统的单字生成模型，等效加速约是 1.8 到 2.7 倍。三是网上偶尔流传的”提速 400%“甚至”661%“这类极值，都有非常严格的前提（特定的服务延迟约束、高并发、且旧方案恰好接近它的运行极限），不是普遍能拿到的倍率。更有技术博客从底层原理指出，对 DeepSeek 用的那类注意力机制，一旦开始推测，注意力会很快进入”计算受限”状态，推测出来的字”几乎要付全价”——也就是说，收益没有表面看上去那么”免费”。
对 AI 行业意味着什么
把 DSpark 放回大背景，它的分量主要体现在”推理经济学”上，而不是模型智力的天花板。
行业的重心正在从”训练更大的模型”转向”更便宜、更快地服务模型”。据德勤 2026 年的预测，推理（也就是模型上线后实际响应用户的环节）将占到 AI 总算力的约三分之二，而 2023 年这个比例还只有三分之一。在这样的趋势下，谁能把”每生成一个字的成本”压得更低、把 GPU 利用率抬得更高，谁就握住了商业化的关键。DSpark 是一条纯软件的路径——不靠买更多卡，而是靠算法把现有硬件的潜力榨出来。这和 DeepSeek 一路以来的混合专家、多 token 预测、稀疏注意力是同一条主线，连起来看，是一套连贯的”算力效率”打法。
这一点对中美 AI 格局也有现实含义。出口管制的底层假设之一是”芯片数量大致等于 AI 能力”。如果中国的实验室能靠纯软件，从手上现有的芯片里再榨出六到八成的推理提速，那么这个假设就会变得没那么牢靠。这不等于管制失效，但确实削弱了”单靠卡的数量”作为政策工具的充分性。
对开源生态来说，DSpark 连同训练框架 DeepSpec 一起以 MIT 协议放出，意味着不只是 DeepSeek 自家的模型，Qwen、Gemma 这类主流开源模型也能用同样的方法训练自己的草稿模型、获得加速。这会把整个行业推测解码的”基线水平”往上抬一截。
谁该关心，怎么用
如果你已经在自己部署或调用 DeepSeek-V4，DSpark 基本是”白捡的提速”，值得评估——用 vLLM 或 SGLang 直接拉起带 DSpark 的检查点即可，不必重训模型。但有个判断标准：先在你自己的真实流量上测一下草稿接受率，如果你现有的加速方案接受率已经很高、延迟也达标，DSpark 在原始延迟上未必更优（不过在显存占用上几乎一定更省）。
如果你想给 Qwen、Gemma 等模型训练定制的草稿模型，DeepSpec 提供了完整工具链，但门槛不低——需要多卡节点和数十 TB 的存储空间，普通本地用户或用 Ollama 的个人玩家暂时还用不上。
无论哪种情况，都别照搬营销数字。把”60% 到 85%“理解成”同等吞吐下的单用户速度”，把那些三位数百分比的极值当成”严苛条件下的边界值”，上线前一定在自己的负载上压测。
最后两点提醒。一是企业如果走 DeepSeek 的托管 API，要注意其数据存储在中国境内、受当地法律约束，多个国家和地区对其在政府设备上的使用有限制——自托管开源权重可以规避数据路由的问题，但这和”速度”是可以分开评估的两件事。二是网上把 DSpark 标成 “arXiv
.19348” 的说法是误植——那个编号其实是 DeepSeek-V4 模型本身的论文，DSpark 这篇目前只有 GitHub 上的 PDF，没有独立的 arXiv 号。说明：本文中的性能数据均来自 DeepSeek 官方论文与配套材料，截至 2026 年 6 月底尚无第三方独立复现，引用时请留意这一点。