2026 年 6 月 27 日，DeepSeek 放出一篇新的技术论文，并开源 DeepSpec 项目。

这次主角不是一个全新大模型，而是一套让现有大模型跑得更快的推理系统 DSpark。

模型 " 脑子 " 没有换，但输出速度被重新优化了。

这件事的意义并不小。

大模型真正上线后，决定体验的往往不只是回答质量，还有每秒能吐出多少 token、用户等多久、同一批 GPU 能撑住多少并发请求。

能力是模型竞赛的上半场，推理效率正在变成下半场。

解决的核心问题很直白，大语言模型通常一个 token 一个 token 往外生成，每生成一步都要依赖前面的全部内容。回答越长，等待越明显，GPU 也会被这种串行流程拖住。

推测解码的思路类似 " 先打草稿，再让大模型批改 "。

一个更轻量的 draft model 先猜出一串候选 token，目标大模型再一次性验证这些 token。如果猜对了，就能一次通过多个 token；如果猜错了，就退回到目标模型继续生成。

理论上，输出内容不变，但用户等待时间会缩短。

问题在于，草稿模型并不总是靠谱。

一次猜得越长，后面的 token 越容易错。错得多，目标模型验证时就会拒绝，前面并行生成节省下来的时间，又会在无效校验里浪费掉。

DSpark 的第一个改动，是引入半自回归生成。它没有走完全并行的路线，而是在 block 内加入轻量串行模块，让候选 token 之间保留一定依赖关系。这样做的目的，是减少 " 前几个 token 能过、后面一串全废 " 的情况。

第二个改动更关键，置信度调度。

过去很多推测解码方案会将草稿模型生成的候选 token 直接全部送去验证。DSpark 则给每个 token 估一个通过概率，只将更可能被接受的前缀送去校验。系统负载高时，它会更保守；资源更宽松时，它可以验证更长的候选序列。

这一步看起来像算法细节，实际很接近线上工程的核心。因为在高并发场景里，GPU batch capacity 是稀缺资源。

将大量低概率通过的尾部 token 塞进 batch，本质上是在浪费吞吐。

DSpark 想做的，是让每一次目标模型校验都更 " 值 "。

DSpark 在数学推理、代码生成、日常对话等测试中超过 Eagle3 和 DFlash。

论文将 Qwen3 4B、8B、14B 和 Gemma4-12B 作为离线评测目标模型，并进一步在 DeepSeek-V4 Flash 和 Pro 的线上流量中验证效果。

论文对 9 个任务做宏平均后显示，DSpark 在 Qwen3-4B、8B、14B 上，相比 Eagle3 的 accepted length 提升 26.7% 至 30.9%，相比 DFlash 提升 16.3% 至 18.4%。

更重要的是线上数据。

DSpark 已部署到 DeepSeek-V4 Flash 和 Pro 的真实流量中。

相比上一代 MTP-1，在保持总体吞吐不变的前提下，Flash 版本用户生成速度提升 60% 至 85%，Pro 版本提升 57% 至 78%。

DSpark 解决的不是模型能不能做题、会不会写代码，而是同一个模型在真实服务里能不能更快、更便宜地交付答案。

对于 API 平台和高并发应用来说，这类优化会直接进入成本结构。

DeepSpec 的开源，则将这件事从一篇论文扩展成一套工具链。

DeepSpec 覆盖数据准备、训练、评估三步，内置 DSpark、DFlash、Eagle3 三类 draft model，并支持 GSM8K、MATH500、AIME25、HumanEval、MBPP、LiveCodeBench、MT-Bench、Alpaca、Arena-Hard-v2 等评估任务。

不过，DeepSpec 不是轻量级开发者玩具。

DeepSeek   特别提示，在默认 Qwen/Qwen3-4B 配置下，仅 target cache 就可能达到约 38TB，默认训练脚本也假设单节点 8 GPU 环境。这说明它更像是面向模型团队、推理服务商和研究机构的工程基础设施。

DSpark 盯上的是大模型上线后的真实账本。同样的 GPU，能不能跑得更快、服务更多人、少浪费计算。

云头条声明：如以上内容有误或侵犯到你公司、机构、单位或个人权益，请联系我们说明理由，我们会配合，无条件删除处理。