你让 AI 写一段长回答，它通常不是整段一起写，而是一个词接一个词往下接。这里的词更准确地说是 token——模型处理文字时使用的小片段。后一个 token 依赖前面的结果，这条串行链很难完全并行，也成了回答速度和部署成本的一大瓶颈。
DSpark想改进的正是这个阶段。它不是新的基础模型，也不会让模型知道更多，而是附着在目标模型上的推理加速模块。推理，指模型训练完成后接收请求并生成答案的过程。据 DSpark 论文，北京大学与 DeepSeek 研究人员在 2026 年 6 月 27 日前后公开这项工作，并开放模型检查点和配套框架 DeepSpec。
先猜一批，再由主模型验收
DSpark采用投机解码（speculative decoding）：先让较轻的草稿模块一次猜出多个后续 token，再交给主模型并行验证。可以把它理解成助手先拟好几句话，负责人一次审阅。草稿猜得准，主模型便能一次接受更多内容，少走几轮逐字生成；猜错太多，草稿和验证所用的算力就会浪费。
问题在于，现有并行草稿方法虽然能同时猜出更长内容，但各个 token 之间的联系可能不够紧。就像多人各写一句再拼成一段，单句看着合理，连起来却未必通顺，主模型最终会拒绝更多草稿。
DSpark为此采用半自回归结构：保留并行生成的骨干，同时加入轻量级顺序模块，让相邻 token 继续参考前面的结果。它没有放弃并行带来的速度，而是补回一部分逐步生成时的连贯性，希望提高草稿被接受的概率。
验多少，不再固定
第二个关键设计是动态验证。DSpark根据草稿置信度——模块对自己猜测把握有多大——以及服务负载，动态选择一次验证多长的草稿。
这一步直接对应线上系统的现实矛盾。延迟是单个请求要等多久；吞吐量是系统单位时间能处理多少内容。请求较少时，多验证一些 token 可能有利于单次回答提速；高并发时，过长的低质量草稿会占用验证资源，反而拖累整体吞吐量。DSpark的做法，是按请求和负载调整长度，减少无效草稿及验证计算。
60%至85%，该怎么理解
论文报告称，在 DeepSeek-V4 线上系统中，相对 MTP-1 基线，DSpark将单用户生成速度提高约 60%至85%。这个数字值得关注，因为它指向实际回答阶段的等待时间与算力利用率，而不是又一次模型能力跑分。对于需要同时服务大量请求的系统，推理效率会直接影响可承载的用户量和部署成本。
但这不是“所有模型都能提速 60%至85%”的普遍结论。它是作者在特定线上系统、相对特定基线报告的结果。现有材料没有给出不同任务、硬件和并发规模下的完整数据，也没有展开额外草稿模块成本如何计入。
项目同时发布了 DeepSpec。根据 DeepSpec 官方仓库，它以 MIT 许可证开源，提供训练和评估草稿模型的代码，并包含 DSpark、DFlash、Eagle3 等投机解码方法的实现。相比只公布一个性能数字，这套工具更便于外部团队复现和比较。
局限与未知
- 60%至85%的提升目前应限定在论文所述的 DeepSeek-V4 线上系统和 MTP-1 基线，不能直接外推到其他部署环境。
- “离线测试显著提升可接受生成长度”和“降低高并发吞吐损耗”缺少材料可核对的具体指标。
- 公开代码有助于复现，但不同模型、硬件和请求负载下能否保持相近收益，仍需更多独立测试。