6 月 27 日，DeepSeek 在 GitHub 低调推了一篇新论文，署名里有创始人梁文锋和北京大学团队。论文介绍的是一套推测解码（Speculative Decoding）框架，名字叫 DSpark。

和这次同期刷屏的 GPT-5.6 Sol / Terra / Luna 不一样——那三个被美国政府要求”先给可信合作伙伴试用”——DSpark 是直接全栈开源，MIT 协议，代码、模型权重、训练工具链一次性放出来。

更值得看的是效果数据：DeepSeek 把它部署到 V4 在线服务系统里，相较于现有生产环境的 MTP-1 基线方案，在保持整体吞吐不变的前提下，单用户生成速度提升了 60% 到 85%。

换句话说，用同样的 GPU，你可以让用户少等一截；用同样的等待时间，你可以服务多一倍的用户。

这篇文章不讲论文公式，直接给一份实操路径：从克隆仓库、装环境，到在 DeepSeek-V4-Flash、Qwen3、Gemma 等模型上把 DSpark 跑起来。

DSpark 是什么：把”挤牙膏”改成”批量出货”

大模型自回归生成有个老问题：每生成一个新 token，都要基于前面所有 token 跑一次完整的前向传播。生成越长，等待越久，GPU 利用率还上不去——一句话聊下来，模型在大部分时间其实是在等显存，而不是在算东西。

推测解码的思路是先用一个小模型（草稿模型）”猜”出几个候选 token，再让大模型一次性验证这些候选是不是对。如果对，一次性接受多个 token，推理速度就快了。

但这条路上有两个主流方案各有缺陷：

• Eagle3（自回归草稿）：草稿生成阶段本身又是自回归的，候选越长，生成延迟线性增长。
• DFlash（并行草稿）：候选并行生成，但越到后面 token 接受率越低，长候选块的效率塌方。

DSpark 做的事，是把这两条路的优点拼起来，加上一个动态校验的调度器。

两大核心创新

半自回归架构：在并行主干网络上叠加轻量级顺序模块。不是纯并行（避免接受率塌方），也不是纯串行（避免延迟堆积），中间地带找平衡。

置信度调度的动态验证：不再无差别校验所有候选 token，而是根据请求的成功概率（置信度）和系统负载，实时调整校验窗口长度。高负载下少校验一些，低负载下多校验一些，GPU 算力用在刀刃上。

这两点单独看都不算颠覆，但合在一起，加上 DeepSeek 真实线上流量的验证，效果就出来了。

实际效果：跟谁比、提了多少

论文里给了三组实测数据，都是在”同等吞吐量”的条件下比较的（吞吐不变，单用户变快，这是生产环境最关心的指标）。

注意对比对象是 Eagle3 和 DFlash 这两个推测解码方案，不是裸的自回归生成——所以这是”已经很快”的方案上再提一截。

跨模型通用性也验证了：DSpark 不是只能给 DeepSeek 自己用，Qwen3-4B / 8B / 14B 和 Gemma 系列都能直接接。

DSpark 是不是新模型？适合谁用？

一个常被搞混的点：DSpark 不是新模型，它是一个推理加速模块。部署上去之后，原模型的能力完全保留——同样的输出分布，同样的回答质量，只是生成得更快了。

适合用的场景：

• 自建推理服务的中小团队：同样的 GPU 资源，多服务一倍的并发用户。
• 本地跑大模型的个人开发者：尤其是 24GB 显存以上、跑 7B ~ 14B 模型的人，每一轮对话的等待时间能砍掉一截。
• AI 编程工具链集成方：比如 Continue、aider、Cline 这类工具，后端接的是本地 vLLM 服务，DSpark 装上之后用户感知最明显的就是”代码补全更跟手”。
• API 服务商：想给同样的 API 价格挤出更多利润空间，DSpark 是开源方案里最值得评估的一个。

不适合用的场景：

• 模型只在云端用、自己拿不到权重的（比如 OpenAI GPT-5.6、Claude Opus 4.7）：用不上，OpenAI 自己的服务可能内部已经在用类似技术。
• 模型极小（< 3B）：草稿模型的相对成本反而会吃掉加速收益。
• 一次性生成极短输出（< 32 token）：加速窗口还没打开就结束了。

实操：把 DSpark 跑起来

DSpark 的代码全部在 DeepSeek 官方 GitHub 组织的 DeepSpec 仓库里，一次性拿到模型权重、训练代码、推理示例。

第一步：克隆仓库

git clone https://github.com/deepseek-ai/DeepSpec.git
cd DeepSpec

git clone https://github.com/deepseek-ai/DeepSpec.git
cd DeepSpec

仓库里包含三套推测解码算法的实现：DSpark、DFlash、Eagle3，外加训练和评估的完整工具链。

第二步：装依赖

pip install -r requirements.txt

pip install -r requirements.txt

DSpark 的核心实现依赖 PyTorch，训练工具链需要 transformers、accelerate 这些常规库。如果你之前用 Ollama 或 LM Studio 部署过本地模型，这套环境应该不陌生。

第三步：跑内置推理示例

DeepSpec 仓库里带了推理脚本，最快的验证方式是直接跑示例：

python examples/run_dspark_inference.py \
  --model deepseek-ai/DeepSeek-V4-Flash-DSpark \
  --draft-model-path ./checkpoints/dspark-draft \
  --prompt "Explain quantum entanglement in simple terms"

python examples/run_dspark_inference.py \
  --model deepseek-ai/DeepSeek-V4-Flash-DSpark \
  --draft-model-path ./checkpoints/dspark-draft \
  --prompt "Explain quantum entanglement in simple terms"

第一次跑会从 HuggingFace 自动拉取 DeepSeek-V4-Flash-DSpark 的模型权重。DSpark 版本是在 V4 基础上加了推测解码模块的版本，输出和原 V4 完全一致。

第四步：接到 vLLM 推理服务

如果你已经在用 vLLM 跑本地推理服务（参考之前的 Ollama MLX 加速方案 那套思路），DSpark 可以直接以插件方式接入：

from vllm import LLM, SamplingParams
from deepspec.runtime import DSparkDecoding

# 加载基座模型
llm = LLM(model="deepseek-ai/DeepSeek-V4-Flash-DSpark")

# 包装 DSpark 解码器
dspark = DSparkDecoding(
    draft_model="./checkpoints/dspark-draft",
    confidence_threshold=0.85,
    max_draft_tokens=8,
)

# 推理
sampling_params = SamplingParams(temperature=0.7, max_tokens=512)
outputs = llm.generate(["Write a Python quicksort"], sampling_params, decoding=dspark)
print(outputs[0].outputs[0].text)

from vllm import LLM, SamplingParams
from deepspec.runtime import DSparkDecoding

# 加载基座模型
llm = LLM(model="deepseek-ai/DeepSeek-V4-Flash-DSpark")

# 包装 DSpark 解码器
dspark = DSparkDecoding(
    draft_model="./checkpoints/dspark-draft",
    confidence_threshold=0.85,
    max_draft_tokens=8,
)

# 推理
sampling_params = SamplingParams(temperature=0.7, max_tokens=512)
outputs = llm.generate(["Write a Python quicksort"], sampling_params, decoding=dspark)
print(outputs[0].outputs[0].text)

confidence_threshold 控制置信度调度的严格程度——值越高，接受的候选越保守，校验开销越大；值越低，草稿被拒的概率越大。这个参数可以根据你的实际负载情况调。

进阶：给 Qwen3 和 Gemma 也装上 DSpark

DSpark 的真正价值不只是给 DeepSeek 自己提速，而是开源了训练工具链，让其他模型也能用上。

DeepSpec 项目里提供了完整的草稿模型训练代码，针对 Qwen3 和 Gemma 系列，可以自己训练一个适配的草稿模型：

python -m deepspec.train \
  --target-model Qwen/Qwen3-8B \
  --draft-arch dspark \
  --data-path ./training_data/ \
  --output-dir ./checkpoints/qwen3-8b-dspark-draft \
  --epochs 3 \
  --batch-size 8

python -m deepspec.train \
  --target-model Qwen/Qwen3-8B \
  --draft-arch dspark \
  --data-path ./training_data/ \
  --output-dir ./checkpoints/qwen3-8b-dspark-draft \
  --epochs 3 \
  --batch-size 8

训练完拿到草稿模型权重后，按上面 vLLM 接入的代码，把 draft_model 路径换成新训练出来的 checkpoint，就能给 Qwen3-8B 也用上 DSpark 加速。

这条路径对国内开发者尤其有用——之前部署豆包 Seed 2.1 Pro 和 GLM-5.2 那篇文章里就提过，国产模型本地部署最大的痛点之一是速度慢。DSpark 这种加速方案能让 7B-14B 的国产模型在消费级显卡上跑得更舒服。

性能调优的几个经验值

参考 DeepSeek 论文和社区反馈，DSpark 部署时几个关键参数的经验值：

在 24GB 显存的 RTX 4090 上跑 DeepSeek-V4-Flash-DSpark，启用 DSpark 之后实测首 token 延迟（TTFT）能降 30% 左右，长文本生成（> 256 token）整体吞吐提升更明显。

如果配合 AI 编程工具链 一起用，比如 Continue.dev 配上本地 DSpark 加速的 Qwen3-14B，体感上 Tab 补全的延迟能压到接近闭源模型的水准。这种”开源模型 + 开源加速 + 开源工具链”的组合，长期 token 账单能砍掉九成以上。

跟同期其他 AI 新闻的关系

6 月 27 日这一天 AI 圈信息密度很高，简单梳理一下：

• OpenAI 发布 GPT-5.6 Sol / Terra / Luna：应美国政府要求，首发只给”可信合作伙伴”，普通开发者暂时用不到。
• Anthropic Mythos 模型：类似情况，受控分发已成主流前沿模型的标配。
• DSpark：闭源模型越收越紧的同时，开源阵营在工程化层面继续拉低成本。

对个人开发者和中小团队来说，闭源模型的可访问性在变差（”可信合作伙伴”这几个字的具体名单不透明），而开源工具链在变好。DSpark 这种”不卷参数卷工程”的路线，恰好是开源阵营的差异化机会——同样花钱买 GPU，DSpark 能让你跑出闭源厂商才有的速度。

起步路径建议

如果你之前没接触过推测解码或者本地大模型推理，按这个顺序来最稳：

1. 先在 CPU/MacBook 上跑一遍 7B 模型，熟悉 vLLM 或者 Ollama 的基本用法。感受一下裸自回归推理的速度。
2. 加 DSpark 跑同一个模型，对比速度差异。建议先用 DeepSeek-V4-Flash-DSpark 而不是自己训练草稿模型，开箱即用。
3. 如果用 Qwen3 / Gemma：用 DeepSpec 工具链训练一个 DSpark 草稿模型。这一步对硬件有要求，建议至少 24GB 显存的 GPU。
4. 接到实际工作流：把加速后的推理服务接到 Continue、aider 或者自建聊天界面里，感受真实使用场景下的速度提升。

DSpark 不是那种”用了就再也回不去”的颠覆性技术，但它解决的是一个真问题——本地大模型用起来总是慢半拍，这一慢就劝退了一大批想自部署的开发者。把这一截补上，DeepSeek 的开源诚意才真正落地到日常使用里。