DeepSeek 开源推理系统 DSpark，提升大模型输出速度 60-85%

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，能不能跑得更快、服务更多人、少浪费计算。

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

查看原文 →