DeepSeek再放大招，推理速度狂飙85%，怎么做到的？

发布时间：2026-07-18 01:49:02 来源：安智兰德资讯网 作者：热点

出品 | 网易智能
作者 | 小爪
编辑 | 王凤枝

6月27日，再放DeepSeek正式公开了DSpark技术报告及DeepSpec代码库。大招需要明确的推理是，DeepSeek-V4的速度底座模型并未发生变动，此次更新的狂飙核心在于新增了一个服务端推测解码模块——DSpark。

DeepSeek在Hugging Face模型页面上给出了直白的再放定义：V4-Pro-DSpark和V4-Flash-DSpark“并非新模型”。这两个页面指向的大招是同一个模型检查点，仅是推理在原有模型基础上叠加了推测解码模块后的服务版本。

这一举措表明，速度DSpark并未赋予模型新的狂飙“智力”，其核心目标在于优化模型上线后的再放生成效率与经济性，即如何更快、大招更低成本地输出答案。推理

根据技术报告，速度DSpark已部署于DeepSeek-V4的狂飙线上服务系统。在真实用户流量测试中，相较于上一代线上推测生成方案（MTP-1生产基线），在匹配吞吐条件下：
* V4-Flash的每用户生成速度提升 60% - 85%
* V4-Pro的每用户生成速度提升 57% - 78%

注意：这里的“快”主要指生成阶段（即模型持续输出Token的过程），并不等同于端到端响应时间的同步缩短。长提示词的预填充、检索、工具调用、排队及网络延迟等因素，依然会影响用户的实际等待体验。

模型上线后，还有一笔推理账

此次发布虽无新模型发布的喧嚣，却更贴近AI公司面临的现实困境：模型训练结束并非成本终点。

聊天机器人、代码助手、智能体及搜索产品等应用场景，每一次调用都在持续消耗GPU算力。模型生成速度慢，用户等待时间长；推理成本高，厂商便难以将高质量模型开放至更多场景。

过去两年，行业焦点多集中于训练成本（如GPU采购、集群规模、训练费用）。然而，当模型转化为产品后，推理成本这一隐性支出开始凸显。

• 训练是一次性的大工程；
• 推理则是持续的水电费。

只要用户提问、智能体运行、代码生成，模型就必须持续消耗算力。大模型服务的最终竞争指标回归至两点：速度与单位Token成本。API定价通常按输入/输出Token计费，企业内部则需拆解模型、缓存、路由及上下文长度等成本项。

DSpark虽不直接等同于降价，但若同等GPU集群能在相近吞吐下让用户更快获取答案，则意味着：
1. 同等硬件可服务更多用户；
2. 同等用户体验所需硬件更少。

“先猜，再验”：推测解码的核心思路

推测解码（Speculative Decoding）的核心逻辑可概括为“先猜，再验”。

传统大模型生成文本时，采用自回归方式，即一个Token接一个Token输出。这种方式稳定但缓慢。推测解码引入一个更轻量的草稿模型（Draft Model），提前预测一段候选Token序列，随后由目标大模型进行批量验证：
* 猜对的部分：直接接受；
* 猜错的位置：进行修正。

关键在于，小模型不能替代大模型做最终决定。最终接受的Token仍由目标模型校验。在正确实现下，推测解码改变的是生成方式，而非目标模型的输出分布。加速的本质在于让大模型从“逐步生成”转变为“批量验证候选”。

DSpark的创新：优化草稿生成策略

DSpark并未止步于通用的推测解码概念，而是重点解决了草稿如何生成这一难题。

现有的草稿策略主要分为两类：
1. 自回归草稿器：稳定性高（后一个Token可见前一个），但草稿变长会导致延迟增加。
2. 并行草稿器：速度快（可一次性猜测整段），但各位置独立猜测易导致前后脱节，接受率随长度增加而下滑。

DSpark采取了一种折中方案，论文关键词为“半自回归生成（Semi-Autoregressive Generation）”：
* 首先使用并行方式提出一段候选；
* 随后通过一个轻量级顺序层修正后续Token的条件关系。

这种设计既保留了并行生成的速度优势，又确保了后续候选能感知到前面已生成的内容，从而保持连贯性。

另一个关键优化在于验证长度的动态调整。

候选Token猜测越多，并不一定越节省资源。若后半段大概率被拒绝，强行验证只会浪费GPU算力。DSpark引入了“置信度调度（Confidence-Scheduled）”机制：
* 结合候选置信度与当前系统负载，动态决定验证长度；
* GPU空闲时，增加验证长度；
* 负载高时，聚焦于高接受率部分，将算力留给更有价值的验证。

DSpark：站在已有技术路线之上

DSpark并非凭空创造，而是DeepSeek将推测解码技术推向线上服务后的公开参照。

推测解码领域已有诸多先驱：
* SpecInfer (2023)：将小模型预测、Token树及并行验证引入大模型服务；
* Medusa (2024)：提出多解码头，一次预测多个后续Token；
* EAGLE系列：围绕草稿模型和动态草稿树提升接受率；
* 推理框架：vLLM、SGLang、TensorRT-LLM等早已将推测解码作为降低延迟的重要工具。

DSpark的独特价值在于系统性解决了生产环境中的多个痛点：草稿生成策略、候选连贯性、负载感知的验证长度调整，以及在真实流量下的速度增益。

论文关键词从“模型能力提升”转向了每用户生成速度（per-user generation speed）、匹配吞吐（matched throughput）和服务等级协议（SLA）等服务侧指标。

此外，需理性看待论文中的高倍吞吐数据（如661%、406%）。这些极端数据源于更严苛的每用户速度目标设定，此时旧基线已接近服务能力边界，DSpark的相对优势被放大。真正反映常态收益的，仍是前文提到的匹配吞吐与真实流量对比数据。

DeepSpec开源：能复现什么？

DeepSeek同步开源了DeepSpec代码库，涵盖推测解码草稿模型的数据准备、训练及评估流程，并放出了Qwen3、Gemma等模型上的相关检查点。

但开源不等于“下载即复现”。

项目文档提示，默认Qwen3-4B配置下，目标模型缓存可能接近38TB；默认训练脚本假设单节点8张GPU。若要严格对齐论文结果，训练设置必须完全一致，特定领域还需对草稿模型进行额外微调。

外界可验证方法逻辑或将DeepSpec移植至其他开源模型，但DeepSeek-V4线上服务中的速度提升数据，仍依赖于DeepSeek自身的硬件规模、流量分布及生产系统调度。

开源的是方法，不是环境。

社区关注焦点：复现边界与工程现实

X（原Twitter）上的讨论并未止步于赞誉，工程师们更关注实际落地能力：

1. 技术边界：AI研究者Ravid Shwartz Ziv指出，DSpark是并行与自回归草稿器的折中，并强调其关键组件（置信度判断头、负载感知调度器）使其保持无损特性。
2. 工程复现：vLLM贡献者Rafael Caricio在双DGX Spark GB10上成功运行DSpark模式，单流解码约60 tok/s（约为MTP-1的1.5倍）。但他指出，真实代码会话暴露了合成基准测试未涵盖的问题：长上下文下草稿接受率明显下滑，瓶颈不仅是计算核心速度。
3. 环境依赖性：Tech2Wild等测试显示，结果高度依赖硬件型号、框架版本、上下文长度及并发设置。AcingAI提醒，高倍数增益仍基于“自家硬件、自家基线、匹配吞吐”条件，外部完整复现尚需时日。

这提醒我们，DSpark的部分优势源于负载感知调度，而调度效果天然依赖生产环境的流量规模与硬件配置。

同样的能力，更少的算力

《南华早报》在6月28日的报道中，将DSpark置于推理瓶颈、芯片压力及用户等待时间的语境下审视。这一视角比单纯讨论“新模型”更贴近产品现实。

当AI模型的能力差距逐渐缩小，交付效率（更快、更便宜）将成为新的竞争壁垒。

DeepSeek一贯强调低成本与高效率。DSpark延续了这一战略：它不证明V4更聪明，而是证明V4在服务用户时可以减少推理算力的浪费。

从更宏观的开源生态来看，推理优化至关重要。开源模型虽易获取，但部署时的显存、吞吐、并发、延迟及运维复杂度均构成成本。一个模型能开源，仅说明可获取；能否低成本服务海量用户，取决于推理栈的成熟度。

DeepSpec放出Qwen3、Gemma等检查点，表明该技术路线已超越DeepSeek-V4自身。迁移程度将取决于社区适配、框架支持及硬件兼容性。

DSpark的价值在于：它为V4增加了一层贴近生产系统的推理服务工具，而非仅仅是一个新能力标签。

未来值得关注的，不仅是DeepSeek自身的速度表现，更是这条技术路线能否被更多人走通。随着DeepSpec的开源，推测解码正从单一公司的工程选择，转变为开源推理降低成本的通用手段——前提是其他框架和硬件能跟上这一演进。

相关文章