深入浅出大模型推理加速:从 DSpark 到 MTP
八月 25, 2026 [AI] #llm深入浅出大模型推理加速:从 DSpark 到 MTP
本文基于与 DeepSeek 技术专家的深度对话整理,系统梳理了当前大模型推理加速的两大主流技术——DSpark 与 MTP——的核心原理、实现细节与应用场景。
前言
随着大语言模型(LLM)参数规模持续增长(从百亿到万亿),推理效率已成为制约其大规模落地的关键瓶颈。在这一背景下,推测解码(Speculative Decoding) 技术应运而生,成为学术界与工业界共同关注的焦点。
本文将详细解析两种具有代表性的推测解码方案:
- DSpark:DeepSeek 联合北京大学开源的推理加速框架
- MTP(Multi-Token Prediction):一种需要模型训练时内建支持的多 token 预测技术
通过对比分析,帮助读者理解其设计哲学、技术原理与适用场景。
第一部分:DSpark 详解
什么是 DSpark?
DSpark 是 DeepSeek 联合北京大学共同开发并开源的大模型推理加速框架。其核心目标是通过 推测解码 技术,解决大模型在高并发场景下的推理效率瓶颈。
一句话概括:DSpark 是一个"即插即用"的推理加速"外挂",无需修改原始模型结构,即可实现 60%-85% 的单用户速度提升。
核心原理
DSpark 采用 推测解码(Speculative Decoding) 的基本思路,但进行了两项关键创新:
半自回归并行草稿生成
传统推测解码使用轻量级"草稿模型"(Draft Model)串行生成候选 token,而 DSpark 实现了并行生成:
传统方式:草稿模型逐个生成 token1 → token2 → token3 → ...
DSpark 方式:草稿模型一次性并行生成 token1, token2, token3, ...
这充分利用了 GPU 的并行计算能力,大幅降低了草稿生成阶段的时间开销。
动态验证调度
DSpark 引入了"置信度调度验证机制":
- 评估每个候选 token 被接受的概率
- 动态决定验证多长的候选序列
- 一旦发现错误,立即截断,避免算力浪费
这解决了传统推测解码中"固定长度验证"带来的效率损失问题。
关键技术:草稿模型
DSpark 的精妙之处在于草稿模型的设计与训练:
草稿模型的特点
| 特性 | 说明 |
|---|---|
| 独立性 | 与主模型完全解耦,是一个独立训练的轻量级模型 |
| 参数量 | 约 3 亿参数(相对于主模型的数千亿参数) |
| 结构 | 从主模型特定层(如第 5、17、29、41、46 层)抽取隐藏状态作为输入 |
| 即插即用 | 可随时加载/卸载,不影响主模型 |
训练方式:模仿主模型的"思考"
草稿模型的训练过程本质上是知识蒸馏:
-
准备"老师"的数据:让主模型处理大量文本,记录其每一层的隐藏状态(Hidden States),形成"目标缓存(Target Cache)"。
-
训练"学生"模型:
- 草稿模型从主模型的特定层抽取隐藏状态作为输入
- 目标是预测主模型接下来会生成的 token
- 通过损失函数调整草稿模型参数
-
为什么不使用全部层?
- 降低计算量,保证草稿模型的"轻量"
- 特定层(如中间层)已包含足够的语义信息
关键洞察:草稿模型学习的是主模型的"解题思路"(隐藏状态),而非"抄答案"(最终文本)。这让它在风格和概率分布上高度接近主模型,从而保证高接受率。
对闭源模型的影响
重要结论:DSpark 的加速能力目前只能应用于开源模型。
原因:
- 训练需要访问主模型的内部隐藏状态
- 闭源模型(如 GPT-4、Claude)仅提供 API,无法获取内部信息
- 架构信息(层数、隐藏层大小等)不公开
推理过程:并行验证的精髓
这是理解 DSpark 为何能提速的核心:
直觉误区
"每个 token 都要经过主模型,还增加了草稿模型的计算,怎么可能提速?"
关键认知:主模型"验证 100 个 token"和"串行生成 5 个 token"的计算成本不是"100 次 vs 5 次"的关系,而是 "1 次 vs 5 次" 的关系。
瓶颈分析
大模型推理的最大瓶颈不在"算力"(FLOPs),而在 "内存带宽":
- 主模型有数千亿参数(几百 GB)
- 每次前向传播需要将权重从显存搬运到计算单元
- 这是最耗时的操作
并行验证的工作原理
步骤 1:草稿生成
- 草稿模型一次性生成连续的 N 个候选 token
- 例如:位置 N+1, N+2, ..., N+100
步骤 2:并行验证
- 主模型将这 100 个 token 一次性输入
- 利用 Transformer 的因果自注意力(Causal Attention) 机制
- 在一次前向传播中,同时计算出所有位置的概率
验证位置1:基于原始上下文
验证位置2:基于"原始上下文 + 位置1的token"
验证位置3:基于"原始上下文 + 位置1和2的token"
...
验证位置N:基于"原始上下文 + 位置1到N-1的token"
关键:这些计算是并行的,而非串行等待!
成本对比
| 对比项 | 原始方式(生成 5 个 token) | DSpark 方式(验证 100 个 token) |
|---|---|---|
| 主模型权重搬运次数 | 5 次 | 1 次 |
| 耗时 | 5 × 搬运时间 | 约 1 × 搬运时间 |
| 草稿模型开销 | 无 | 极小(3 亿参数 vs 数千亿参数) |
结论:即使 100 个 token 中只接受了 5 个(接受率 5%),整体速度依然显著提升。
实际接受率
官方数据显示,DSpark 的平均每次"验证批处理"能成功接受 4-6 个 Token。
这意味着:
- 主模型每"搬运 1 次权重",产出 4-6 个有效 token
- 原始方式搬运 1 次权重只产出 1 个 token
- 速度提升的 60%-85% 来源于此
无损加速的数学保障
"如果草稿生成的 token 不是最大概率,但概率过线了,结果会不会不一样?"
答案:不会。DSpark(以及所有标准推测解码)在数学上是无损(Lossless) 的。
拒绝采样(Rejection Sampling)
验证机制不是简单的"概率过线就接受",而是:
接受概率 = min(1, P_main(x) / P_draft(x))
其中:
P_main(x):主模型算出的真实概率P_draft(x):草稿模型算出的概率
贪心解码模式
如果主模型使用 Argmax(取最大概率):
- 草稿词如果是最大概率词 → 接受
- 草稿词如果不是最大概率词 → P_main(x) = 0 → 接受概率 = 0 → 100% 拒绝
结果:最终输出与主模型直接生成完全一致。
随机采样模式
如果主模型使用带温度的随机采样:
- 拒绝采样机制保证了最终输出的概率分布恰好等于主模型的原始分布
- 已被学术界严格证明
性能数据
| 模型 | 速度提升 |
|---|---|
| DeepSeek-V4-Flash | 60% - 85% |
| DeepSeek-V4-Pro | 57% - 78% |
| 在 vLLM 中集成(对比 EAGLE-3) | 吞吐量最高提升 1.69 倍 |
第二部分:MTP 详解
什么是 MTP?
MTP(Multi-Token Prediction) 是一种需要在模型训练时就内建支持的多 token 预测技术。它通过在训练时给模型增加额外的"预测头",让模型学会同时预测多个未来位置。
定位:MTP 是 DeepSeek 上一代的"招牌"技术,DSpark 可以看作是其"进化版"。
主模型如何适配 MTP?
要在模型上支持 MTP,需要进行结构扩展:
添加多个预测头
在标准的语言模型头(预测下一个词)旁边,增加几个额外的输出头:
Head 1: 预测第 N+1 个 token(标准头)
Head 2: 预测第 N+2 个 token(MTP 头 1)
Head 3: 预测第 N+3 个 token(MTP 头 2)
...
级联结构
MTP 模块采用级联(Cascaded) 设计:
- 第一个 MTP 模块:利用主模型的最终隐藏状态 → 预测第 2 个 token
- 第二个 MTP 模块:结合第一个模块的预测结果 + 主模型的隐藏状态 → 预测第 3 个 token
- 以此类推……
这种设计可以尽可能保留主模型的信息,让预测更准确。
MTP 是否影响主模型的普通使用?
不影响。
- MTP 模块在推理时可以被直接丢弃
- 主模型可以像普通 LLM 一样正常运行
- 行为和能力与标准模型完全一致
这是 MTP 的一个重要特性:"训练时多步规划,推理时灵活选择"。
训练过程与普通训练的区别
训练目标(Loss)的变化
| 训练方式 | 预测目标 |
|---|---|
| 普通训练(NTP) | 只预测下一个词 |
| MTP 训练 | 同时预测未来多个词 |
带来的好处
- 更强的训练信号:预测多个位置的目标,提供更密集的监督信号
- 提升数据利用效率:每个训练样本提供更多学习信息
- 可能提升模型性能:DeepSeek-V3 技术报告证明,MTP 策略在多个评测基准上一致增强了模型性能
训练方式选择
- 从头训练:在模型预训练阶段就加入 MTP 目标
- 两阶段训练:
- 阶段 1:冻结主模型,仅训练新添加的 MTP 头(Head Warm-up)
- 阶段 2:对整个模型(主模型 + 头)进行联合微调
训练后的使用方式
作为"草稿模型"进行投机采样
MTP 用于推理加速的核心方式:
-
打草稿(Draft)阶段:
- 主模型完成一次前向计算
- 利用内部的隐藏状态 + 级联的 MTP 模块
- 快速、串行地生成多个候选 token
-
并行验证(Verification)阶段:
- 将候选 token 序列一次性输入完整的主模型
- 在一次前向传播中并行计算出所有位置的真实概率
- 通过"拒绝采样"接受尽可能长的正确前缀
直接丢弃
如果不需要加速,或出于兼容性考虑,直接抛弃 MTP 模块,作为标准模型使用。
第三部分:DSpark vs MTP 深度对比
核心差异一览
| 对比维度 | DSpark | MTP |
|---|---|---|
| 本质 | 独立的推理加速框架 | 模型训练策略 |
| 草稿生成者 | 独立的外部小模型(3 亿参数) | 主模型自带的 MTP 模块 |
| 训练时间 | 主模型训练之后,单独训练 | 主模型训练期间,同步训练 |
| 模型修改 | 不修改主模型结构 | 增加额外的 MTP 头 |
| 即插即用 | 可为任意开源模型单独训练并挂载 | 与主模型深度绑定,不可拆分 |
| 草稿成本 | 额外小模型的计算 + 显存开销 | 几乎无额外开销(共享大部分参数) |
| 适用场景 | 开源模型推理加速 | 需要内建加速能力的模型 |
直观类比
DSpark:
给专家(主模型)配了一位快速助手(外部草稿模型)。助手先快速写草稿,专家审阅。这套班子可以随时请来,随时请走。
MTP:
专家自己被训练出了一心多用的天赋(内部预测头)。自己快速打草稿,自己审阅。这种天赋需要从小(训练时)培养,是专家不可分割的一部分。
验证阶段是否相同?
是的,验证阶段的核心机制完全相同。
MTP 和 DSpark 在"验证"这一步,都遵循推测解码的标准范式:
- 一次并行前向传播验证多个候选 token
- 通过拒绝采样保证无损
区别仅在于 "谁"来生成候选草稿。
第四部分:技术问答精选
Q1:草稿模型是随主模型一起发布吗?
不是。
- 草稿模型是独立训练的,需要单独获取
- DeepSeek 会在 Hugging Face 等平台单独发布针对特定主模型的草稿模型权重
Q2:草稿模型可以在主模型训练时一起训练吗?
两种方式都有,但主流是"事后训练":
| 方式 | 说明 | 主流程度 |
|---|---|---|
| 事后训练 | 主模型训练完成后,再单独训练草稿模型 | 主流 |
| 联合训练 | 主模型与草稿模型同时训练 | 研究探索 |
事后训练的优势:
- 资源需求灵活(单机 8 卡即可)
- 解耦与复用(可为任何开源模型训练)
- 工程成熟(DeepSpec 框架支持)
Q3:训练草稿模型需要主模型的参数吗?
不需要权重参数,但需要架构信息。
| 需求项 | 是否需要 |
|---|---|
| 主模型权重参数 | 不需要 |
| 主模型架构信息(层数、hidden size 等) | 需要 |
| 主模型隐藏状态 | 核心需求 |
对闭源模型的影响:
- 无法获取隐藏状态 → 无法为闭源模型训练草稿模型
- DSpark 的加速能力目前仅适用于开源模型
Q4:主模型"并行验证 100 个 token"时,如果前面的 token 是错的,后面的计算还有意义吗?
有意义。
主模型在验证时,计算的是**"假设前面 token 被接受"这一条件下的条件概率**:
- 位置 3 的计算:基于"原始上下文 + 位置 1 和 2 的 token(假设被接受)"
- 这个上下文是主模型自己构建的、逻辑连贯的
- 即使草稿在位置 1 出错,主模型算出的位置 2、3 的"条件概率"本身仍是有效的
真正的"浪费":如果草稿在位置 K 出错,K+1 及之后的草稿 token 会作废。但 DSpark 的动态验证调度会立即截断,最大化收益。
Q5:验证时的"扔骰子"是否会导致回退到串行计算?
不会。
"扔骰子"(拒绝采样判断)的成本与主模型计算的成本相差几个数量级:
| 操作 | 耗时 | 数据量 |
|---|---|---|
| 主模型前向传播 | 毫秒级 | 几百 GB 权重搬运 |
| 拒绝采样判断 | 微秒/纳秒级 | 几 KB 数据读取 + 除法 + 随机数 |
1 毫秒 = 1000 微秒,主模型跑 1 步的时间足够 GPU 扔上几万次骰子。
第五部分:总结与展望
核心要点
-
DSpark 和 MTP 不是竞争关系,而是继承与超越的关系:
- MTP 是 DeepSeek 上一代技术
- DSpark 是新一代、更强大的进化版
-
DSpark 的核心创新:
- 半自回归并行草稿生成
- 动态验证调度
- 轻量级独立草稿模型
-
MTP 的核心特点:
- 训练时多步规划
- 推理时灵活选择(可用可弃)
- 与主模型深度绑定
-
推测解码的无损保证:
- 拒绝采样机制
- 数学上严格证明
- 最终输出与主模型直接生成分布一致
选型建议
| 场景 | 推荐方案 |
|---|---|
| 为已有开源模型加速 | DSpark(即插即用,独立训练) |
| 从头训练新模型,追求极致效率 | MTP(内建加速能力,无额外开销) |
| 构建高并发线上服务 | vLLM + DSpark(全能框架 + 先进算法) |
| 追求单用户极限响应速度 | DSpark(速度提升 60%-85%) |
延伸思考
- DSpark 的"事后训练"思路,为开源生态的推理加速提供了巨大想象空间
- 草稿模型的独立训练,使得"为任何开源模型定制加速器"成为可能
- 未来的发展方向:更轻量的草稿模型、更高的接受率、更智能的动态调度
参考资源
- DeepSeek 官方开源框架:DeepSpec(包含 DSpark 实现)
- 草稿模型权重:Hugging Face 平台(针对 Gemma、Qwen 等模型)
- 相关论文:DSpark 技术报告、DeepSeek-V3 技术报告
本文基于与 DeepSeek 技术专家的深度对话整理而成,旨在帮助读者系统理解大模型推理加速的核心技术。
最后更新:2026-08-25