2026年6月27日，一篇名为《DSpark：基于半自回归生成的置信度调度推测解码》的论文引发行业关注。该论文由DeepSeek创始人梁文锋署名，并与北京大学联合完成。论文披露了一组令人瞩目的数据：将DSpark部署在DeepSeek-V4线上服务系统、承接真实用户流量时，单用户生成速度出现了60%到85%（Flash版本）以及57%到78%（Pro版本）的大幅提升；在离线或高并发场景下，聚合吞吐量更是提升了51%至400%。
这组数据并非简单的硬件堆砌带来的线性增长，而是一次底层推理架构的质变。要理解这个数字的含金量，必须先看清大模型推理过程中的算力黑洞。
85%提速的真相：被“无效校验”吃掉的算力
当前主流的大模型大多采用自回归生成机制。简单来说，模型在生成文本时，是一个字一个字往外蹦的。每生成一个字，模型都需要把之前所有的上下文重新过一遍，计算出下一个字的概率分布。这种串行生成方式导致GPU的并行计算能力被严重闲置。更关键的是，大模型推理通常是“访存受限”的。
在硬件层面，这种访存瓶颈主要体现在KV Cache（键值缓存）的读写上。为了不重复计算历史上下文，模型会将之前每一步生成的隐藏状态以Key和Value的形式保存在显存中。随着序列长度的增加，KV Cache的体积呈线性增长。在生成每一个新词时，GPU的计算单元必须等待庞大的KV Cache从显存搬运到计算核心。这意味着，GPU绝大部分时间并没有在做矩阵乘法，而是在等数据。计算单元的空转，加上反复读写显存带来的带宽压力，构成了大模型推理最底层的成本黑洞。
为了打破这种串行瓶颈，业界引入了推测解码技术。其基本思路是引入一个体积更小、速度更快的草稿模型，让它先猜测接下来可能生成的几个字，然后再由目标大模型对这些草稿进行批量校验。如果草稿猜对了，大模型就能一次性确认多个字，从而大幅提速；如果猜错了，大模型就推翻重来。
然而，传统的推测解码方案在提速的同时，制造了新的算力浪费。早期的并行草稿方案（如Medusa）或自回归草稿方案（如Eagle3），往往采用盲目猜测的策略。以并行草稿为例，它让草稿模型在同一时间点并行猜测多个可能的下一个词，但这忽略了词与词之间的先后依赖关系。而自回归草稿虽然考虑了依赖关系，让草稿模型自己先生成一长串，但随着序列变长，草稿模型猜错的概率呈指数级上升。
当目标大模型对这些长串草稿进行校验时，问题就暴露了。目标模型发现前面几个词猜对了，但后面大部分都是错的。在传统的校验机制下，目标模型必须对整串草稿进行完整的前向传播计算。在这个计算过程中，模型不仅要加载自身的巨大参数权重，还要处理草稿带来的额外KV Cache。这意味着它在批改那些注定会被丢弃的废稿时，消耗了大量的GPU算力和显存带宽。这种“无效校验”在低并发时或许不明显，但在DeepSeek-V4真实流量的高压下，算力浪费被急剧放大，不仅拖慢了实际响应速度，更让本就高昂的推理成本雪上加霜。DSpark的出现，就是为了把这部分被吃掉的算力抢回来。
实习生与导师：DSpark如何让推测解码不再盲目
DSpark的核心技术机制可以概括为半自回归生成与置信度调度推测解码。这两个听起来晦涩的学术名词，其本质是重塑了草稿模型与目标模型之间的协作关系，从根本上改变了GPU显存读写与计算调度的逻辑。
我们可以用一个通俗的比喻来理解这个过程。假设目标大模型是一位严谨的导师，草稿模型是一位反应极快的实习生。在传统的推测解码中，导师让实习生盲目猜接下来要写的十句话。实习生虽然写得快，但往往写到第五句就开始跑题。导师拿过来一看，前四句可用，后六句全是废稿。导师在批改这六句废稿时花费的精力，就是被浪费的算力。
DSpark的半自回归生成机制，相当于给实习生配备了一个兼顾前后文逻辑的辅助大脑。实习生在猜测时，不再是完全脱离上下文的盲目发散，而是能够根据已生成的内容进行一定程度的自我修正。在技术实现上，这意味着草稿模型在生成多个候选词时，会利用前一步的隐藏状态来指导下一步的生成，从而提高了长序列草稿的命中率，减缓了末尾内容通过率衰减的问题。
更关键的创新在于置信度调度。在DSpark框架下，实习生在提交草稿时，会给每一部分内容打上一个置信度分数，表示自己对这部分猜测的把握程度。导师在批改时，会根据这个分数进行动态调度。
在具体的算法逻辑中，草稿模型的输出层除了输出词表上的概率分布外，还会输出一个额外的标量值作为该预测词的置信度。DSpark通过设定动态阈值机制，对草稿序列进行切分。如果某段草稿的置信度连续高于阈值，系统判定其大概率正确，将其归为高优先级；如果置信度跌落阈值以下，系统则认为后续草稿出错概率极大。
在底层的GPU计算逻辑中，这种调度改变了以往“一刀切”的批量校验模式。对于实习生高置信度（大概率正确）的部分，导师会将其分配到高优先级的计算流中，集中精力快速批改；对于低置信度的部分，导师直接选择丢弃，或者将其放入低优先级的计算流中减少校验资源投入。这就避免了目标模型在必错的废稿上浪费宝贵的显存带宽和计算周期。
通过这种机制，DSpark有效减少了无效校验带来的算力浪费。据智东西等媒体报道，在Qwen3系列模型上，DSpark的平均接受长度比前代Eagle3提升了26.7%至30.9%，比DFlash提升了16.3%至18.4%。这意味着在同样的时间内，目标大模型能够采纳更多正确的草稿，生成速度自然水涨船高。这种优化没有增加任何额外的硬件投入，纯粹依靠调度算法的改进抠出了算力。
算力账本：为什么减少浪费比单纯加卡更重要
从工程角度看，DSpark是一次漂亮的算法优化。但从商业角度看，这是大模型厂商在残酷成本战中的生存指南。
大模型行业的财务模型极其敏感于推理成本。在OmniTools此前关于OpenAI泄露账本的分析中，我们看到了一个令人震惊的成本结构：年入130亿却运营亏损209亿。这种烧钱换规模的背后，除了高昂的训练成本，更持续流血的是推理算力消耗。大模型的训练成本虽然庞大，但通常是一次性或阶段性的资本开支；而推理成本则是运营成本，每一次用户调用API，每一次模型生成回答，都在消耗真金白银的GPU算力、电费和折旧。
我们可以具体推演一次典型的API调用成本结构。假设用户输入1000个词的提示词，要求模型生成1000个词的回答。在传统的自回归模式下，Prefill阶段处理1000个输入词，随后Decode阶段进行1000次串行生成。每一次生成都要加载庞大的模型权重，并读写不断增长的KV Cache。在典型的千亿参数模型中，单次Decode步骤的计算可能只需几毫秒，但数据搬运可能耗时几十毫秒。
如果采用传统盲目推测解码，虽然草稿模型快速生成了200个词，但目标模型在校验时发现只有前50个是对的，后150个全错。那么在处理后150个词时，目标模型所调动的GPU计算单元、占用的显存带宽、消耗的电力，全部变成了沉没成本。当每天有数千万次API调用时，这种无效校验累积起的算力浪费，足以直接反映在厂商的季度财务报表上，成为吞噬利润的无底洞。
当用户量激增时，如果推理效率低下，厂商只有两条路可选：要么限制用户访问，要么疯狂采购显卡扩容。前者损失市场份额，后者拖垮现金流。在资本逐渐趋于理性的当下，靠无限融资来填补算力窟窿的模式已经难以为继。更致命的是，随着模型参数规模的增大和上下文长度的扩展，单次推理的算力消耗呈指数级上升。如果任由无效校验等算力浪费存在，大模型厂商的亏损缺口将随着用户规模的增长而无限放大。
DSpark所代表的推理优化路径，给出了第三种解法。通过减少无效校验的算力浪费，DeepSeek-V4在不增加硬件集群的前提下，将高并发场景下的聚合吞吐量提升了最高400%。这意味着同样的服务器群，能够承载数倍于以往的用户请求。
对于大模型厂商而言，这种工程优化的价值远胜于单纯堆砌算力。加卡是线性增长的成本与线性增长的产能，每增加一张卡，就增加一份采购成本、运维成本和能耗压力；而算法层面的效率提升，则是固定成本下的指数级产能跃升。当行业进入价格战阶段，谁能在单次API调用中压低算力成本，谁就能在保证毛利率的同时给出更具杀伤力的价格。DSpark不仅让模型变快了，更让大模型的商业闭环变得更加健康，为厂商在微利时代活下去提供了底气。
开源DeepSpec：把武器发给中小团队
在发布DSpark论文的同时，DeepSeek还开源了DeepSpec框架。据官方GitHub显示，DeepSpec采用MIT协议开源，包含了DSpark、DFlash以及Eagle3等推测解码算法模块，并且兼容Qwen3、Gemma等主流开源模型。
这是一个值得行业高度关注的动作。在当前的AI生态中，闭源巨头如OpenAI、Anthropic等也在底层使用推测解码或类似的推理加速架构，但他们极少将这些全栈的推理优化工具链开源。对于中小AI创业团队来说，想要为自己的微调模型训练一个高效的草稿模型，往往需要从零开始造轮子。
我们可以假想一个只有几张A100显卡的创业团队的真实处境。他们可能微调了一个垂直领域的模型，但在部署时发现生成速度极慢，用户体验极差。如果他们想自己搞推测解码，就需要懂CUDA算子开发，懂KV Cache的内存管理，还要自己设计草稿模型的训练流程。这不仅意味着高昂的人力成本，更意味着漫长的试错周期。很多中小团队正是在这个阶段耗尽了资金。
DeepSpec的开源，直接把最先进的推理优化武器发给了整个行业。在具体的框架设计中，DeepSpec提供了高度模块化的接口。开发者不需要从底层重写推理引擎，只需在配置文件中指定主模型路径和草稿模型路径，框架会自动接管草稿生成、置信度计算与目标模型校验的完整流程。
对于想要训练自有草稿模型的团队，DeepSpec提供了标准化的数据蒸馏模块，可以将目标大模型的隐藏状态蒸馏出来供草稿模型学习，大幅降低了数据准备的门槛。开发者不再需要自己去摸索如何构建半自回归的草稿模型，也不需要去反复调试置信度调度的参数。通过DeepSpec提供的标准化工具链，中小团队只需按照文档配置参数，就能为自己的模型接入推测解码能力，享受到生成速度大幅提升的红利。
这种开源策略不仅加速了行业整体的技术迭代，也在一定程度上削弱了闭源巨头在推理效率上的护城河。当最先进的工程优化能力成为行业公共基础设施时，大模型竞争的焦点将被迫向更上层的应用创新和更底层的数据质量转移。
主战场转移：模型之外皆属Harness
DSpark的发布及其在DeepSeek-V4上的成功部署，印证了一个不可逆的行业趋势：大模型竞争的主战场已经转移。
正如OmniTools在《模型之外皆属Harness：Deepseek下场，国内AI竞争主战场为何变了？》一文中所指出的，当各家厂商的基座模型参数规模都达到千亿级别，且在各类基准测试中的表现趋于同质化时，单纯拼参数已经无法拉开差距。决定一个AI产品生死和成本的，是模型之外的工具链、推理调度架构、API路由等系统级工程能力，也就是所谓的Harness。
对于不熟悉底层工程的人来说，“Harness”这个词可能比较抽象。在软件工程中，Harness通常指“测试线束”或“框架”，但在大模型语境下，它指的是包裹在基座模型外围的整套系统工程基础设施。它包括但不限于：管理用户请求的API路由分发系统、负责加速生成的推理调度架构（如推测解码和KV Cache管理）、让模型能够调用外部工具和联网搜索的工具链，以及保障高可用性的容灾监控系统。基座模型就像一台发动机，而Harness则是底盘、变速箱和传动轴。发动机再强，如果Harness拉胯，动力也传不到车轮上。
DSpark正是Harness层面的一次典型博弈。它不改变DeepSeek-V4的基座参数，不提升模型的智商，但它通过极致的工程优化，解决了真实流量下的算力浪费问题，直接改善了用户体验（响应速度）和厂商财务模型（推理成本）。未来的大模型竞争，将越来越多地表现为这种看不见的系统级工程博弈。谁的推理调度更智能，谁的KV Cache管理更高效，谁的推测解码命中率更高，谁就能在同样的算力储备下打出更多的输出。这种从“拼参数内卷”到“拼工程落地”的转向，要求厂商不仅要懂算法，更要懂系统、懂硬件、懂真实的业务流量特征。
局限与边界：DSpark不是万能药
尽管DSpark在长文本生成和高并发场景下展现出了惊人的优化效果，但它并非解决大模型推理问题的万能药。任何技术方案都有其适用的边界，DSpark也不例外。
首先是极高的存储门槛。根据DSpark论文披露的数据，训练一个适配中等规模模型（如Qwen3-4B）的草稿模型，所需的目标缓存体积高达38TB。这个数字对于拥有庞大算力集群的头部厂商来说或许只是常规配置，但对于资源有限的中小团队而言，38TB的高速存储访问本身就是一道难以跨越的门槛。这意味着DeepSpec虽然开源了代码，但中小团队想要完整复现并部署DSpark级别的优化，仍需克服硬件资源的现实阻碍。存储成本和I/O瓶颈，可能成为阻碍这项技术全面普及的现实鸿沟。
其次是优化阶段的局限性。大模型推理通常分为两个阶段：Prefill（预填充）和Decode（解码）。Prefill阶段是模型读取用户输入的提示词并生成第一个字的过程，这个阶段属于计算密集型，GPU算力被充分利用；而Decode阶段则是后续逐字生成的过程，属于访存密集型，也是推测解码主要发挥作用的阶段。DSpark主要针对的是Decode过程。对于用户极其敏感的首Token延迟（即Prefill阶段），DSpark的优化作用相对有限。在极短文本交互场景（如简单的问答或指令执行）下，由于生成内容本身就少，推测解码能够发挥的加速空间被压缩，DSpark的速度优势可能并不明显。
最后是异构算力的适配问题。目前DSpark的线上验证主要基于DeepSeek-V4的特定服务架构，其在非Nvidia硬件（如各类国产算力芯片）上的适配情况与实际加速比，尚缺乏公开的测试数据。在不同的硬件架构下，显存带宽和计算单元的调度逻辑存在差异，置信度调度策略是否需要重新调优，仍是一个待解的工程问题。
技术优化没有银弹。DSpark证明了通过算法调度消灭算力浪费的巨大潜力，为大模型行业打赢成本战提供了一把利器。但在实际落地中，开发者仍需根据自身的业务场景、硬件储备和延迟敏感度，理性评估这套方案的投入产出比。大模型的工程化之路，才刚刚进入深水区。
