用大模型最烦什么？等。
问一句话，盯着光标闪三秒；让它写段代码，够你去倒杯水。DeepSeek 显然也烦了——他们在 V4 上线两周后，直接甩出一个叫 DSpark 的加速方法，生产环境实测吞吐量暴增 51% 到 400%，用户侧生成速度提升 60% 到 85%。
而且，代码、论文、checkpoint 全开源。
说的直白一点：DeepSeek 没有换更好的 GPU，没有加更多机器。他们靠一个算法创新，让 V4 跑出了之前根本达不到的交互速度。
谁干的？怎么干的？
先说背景。大模型生成文字是一个字一个字往外蹦的——每蹦一个字，就要跑一次完整的前向计算。这导致 GPU 利用率极低，用户等得心烦。
投机解码（Speculative Decoding）是行业里公认的解法：用一个轻量级「草稿模型」先猜出一串候选 token，然后让完整模型一次性验证整串。猜对了就全收，猜错了就扔掉重来。
DeepSeek 之前的生产方案叫 MTP-1，每次只猜 1 个 token——很保守，不出错，但也快不到哪去。为什么不敢猜更多？因为猜得越多，猜错率越高，浪费的算力反而拖慢整个系统。
DSpark 做了两件事，把这个问题拆了。
第一件事：半自回归架构。
传统的并行草稿模型（比如 DFlash）确实能一口气猜出 7 个甚至 16 个 token，问题是每个位置独立预测，互相不通气。就像让 7 个人同时猜下一句歌词，第一个人猜"后来"，第二个人猜"终于在眼泪中明白"——但第一个人万一猜了"再见"，后面全废。
DSpark 的做法很巧妙：重活让并行骨架干（保持速度），但在上面加了一个极轻量的串行模块（Markov Head），让后面的 token 能看一眼前面抽出了什么再决定自己猜什么。论文里管这叫「半自回归」。
重点：DSpark 继承了并行模型的第一 token 高准确率（深网络带来的容量优势），同时用串行头抑制了后面位置的接受率衰减。两头的好处都占了。
第二件事：置信度调度验证。
就算草稿质量好了，全部验证也不划算——特别是在高并发的时候，验证低把握的 token 等于抢别人的算力。
DSpark 训练了一个置信度头，给每个候选 token 打分：这个 token 有多大概率被目标模型接受？然后一个硬件感知调度器根据当前系统负载动态决定验证多长——负载低的时候多验几个（反正 GPU 闲着），负载高的时候只验最有把握的前缀。
这一套组合拳的效果，论文里的离线 benchmark 说得很清楚：在 Qwen3-4B/8B/14B 和 Gemma4-12B 四个目标模型上，DSpark 的接受长度比 DFlash 高出 16% 到 18%，比 Eagle3 高出 27% 到 31%。
但真正狠的在线上。
生产环境：从 51% 到 400%
论文第 5 章是把 DSpark 部署到 DeepSeek V4 真实服务集群后的实测数据。
在 V4-Flash 引擎上：
中等交互要求（80 tok/s/用户）下，系统总吞吐量提升 51% 严格交互要求（120 tok/s/用户）下，MTP-1 基线已经撑不住了，DSpark 相对提升 661%——主要是基线自己掉到地板了，DSpark 勉强撑住了 在匹配吞吐量下，单用户生成速度提升 60% 到 85%
在 V4-Pro 引擎上：
中等 SLA 下吞吐量提升 52% 严格 SLA 下相对提升 406% 单用户速度提升 57% 到 78%
（原文："DSpark shifts the Pareto frontier of LLM serving outward."）
翻译成人话：以前 V4 在高并发下为了保证交互速度，只能牺牲吞吐量；现在 DSpark 把整条「速度 vs 吞吐」的边界往外推了一截。
怎么做到的？关键在那套动态调度。并发请求少的时候，调度器给每个请求分配较长的验证预算（4-6 个 token）；并发一上来，自动收紧预算——不让低把握的 token 抢 GPU。这套机制在生产环境跑通了，而且没有引入额外的调度延迟（用了异步+ZOS 集成）。
开源了什么？怎么上手？
DSpark 的训练代码、checkpoint、论文全部公开。
GitHub 仓库 DeepSpec 是一个完整的投机解码训练框架，包含三种算法：DSpark、DFlash、Eagle3。目前 1,836 star，MIT 协议。
三条路跑起来
如果你只是想用现成的加速效果：
V4 用户什么都不用做。DSpark 已经替代了 MTP-1，部署在 DeepSeek V4 的生产服务端。你感受到的"V4 好像变快了"——不是错觉。
如果你想给 Qwen/Gemma 接上 DSpark：
DeepSeek 在 HuggingFace 上发布了已训练好的 checkpoint，直接覆盖 Qwen3-4B/8B/14B 和 Gemma4-12B：
deepseek-ai/dspark_qwen3_4b_block7deepseek-ai/dspark_qwen3_8b_block7deepseek-ai/dspark_qwen3_14b_block7deepseek-ai/dspark_gemma4_12b_block7
每个 checkpoint 都是对应目标模型的 draft model，接上就能用。
如果你想自己训练草稿模型：
DeepSpec 仓库提供了完整的训练管线：
# 1. 安装依赖
python -m pip install -r requirements.txt
# 2. 准备数据（下载 + 用目标模型重新生成答案）
# 详见 scripts/data/README.md
# 注意：默认 Qwen3-4B 设置下缓存约 38TB
# 3. 训练
bash scripts/train/train.sh
# 通过 config_path 选择算法和模型，例如：
# config/dspark/dspark_qwen3_4b.py
# 4. 评估
bash scripts/eval/eval.sh
# 设置 target_name_or_path 和 draft_name_or_path
配好之后，每次使用只需要做一件事：用训练好的 draft checkpoint 替代原来的 draft model，推理框架会自动跑投机解码流程。
训练默认配置假设单机 8 卡。卡少的话调 CUDA_VISIBLE_DEVICES。
最容易出错的地方在数据准备阶段——目标模型重新生成答案时缓存可能极大（默认 38TB）。建议先拿小数据集验证流程跑通，再上全量。
核心概念速查
- DSpark：半自回归草稿模型，并行骨架 + Markov Head 串行修正
- DFlash：纯并行草稿模型（DSpark 的骨架就是基于它）
- Eagle3：自回归草稿模型，采用 TTT（Training-Time Test）
- Confidence Head：预测每个 draft token 被接受的概率
- Hardware-Aware Prefix Scheduler：根据系统负载动态决定验证几个 token
重点：DSpark 真正适合的是有推理服务部署需求的团队——不管是自建还是用 DeepSeek 的 API，本质收益都是"同样的硬件，服务更多人，响应更快"。
DeepSpec GitHub：https://github.com/deepseek-ai/DeepSpec
DSpark 论文：https://github.com/deepseek-ai/DeepSpec/blob/main/DSpark_paper.pdf
HuggingFace Checkpoints：https://huggingface.co/deepseek-ai/DeepSeek-V4-Pro-DSpark
点赞、转发、小心心 ❤️ 欢迎在评论区留下你的想法！
— 完 —
免责与版权声明：本文资讯及观点仅供技术交流参考。文中引用图片均源于网络公开渠道（如官方博客、社交平台等），著作权归原作者所有。本文旨在分享与评述技术进展，符合“合理使用”原则。如相关图片/内容涉及版权侵权，请联系我们（留言或私信），我们将核实后立即删除。
