投机采样这两年几乎是推理加速圈的“标配话题”，而 Parallel Drafting 则是这波演进里最值得单独拎出来讲的一条线。从最早的单一草稿模型串行生成候选序列，到 P-EAGLE 在特征空间里做并行分支，再到 DFlash 把草稿阶段的注意力内核和“草稿文件”缓存一起优化，再到 DSpark 这种把多条草稿流当作任务来统一调度的运行时方案，背后其实都在解决同一个问题：投机采样的上限定死在“草稿质量 + 草稿速度”这两件事上，而并行恰恰是同时撬动两者的手段。这篇文章就从工程落地的角度，把我对这一系列方案的拆解、参数取舍和实际排查经验整理出来，给正在做推理服务优化的同学一个可以直接参考的思路框架。
1. 投机采样为什么这么火：先把“并行验证”这笔账算清楚
1.1 草稿-验证循环：用一个小模型换一个大模型的并行
投机采样（Speculative Decoding）的核心逻辑，一句话就能讲明白：让一个又小又快的草稿模型先自回归地“猜”出接下来的一串 token，然后让大模型一次性对这串 token 做并行验证。因为大模型一次前向可以同时处理多个位置，所以验证 k 个候选 token 的开销，约等于原来解码一个 token 的开销。只要草稿猜得够准，你就能用“一个前向换多个 token”的方式把吞吐拉上去。
这里有个量化感受一下。假设草稿长度 l=4，单 token 平均接受率 α=0.75，那么每一轮“草稿+验证”周期里，期望能接受的 token 数是：
(1 - α^(l+1)) / (1 - α) = (1 - 0.75^5) / 0.25 ≈ 3.05
也就是说，原本一次前向只能得到 1 个 token，现在同样一次前向平均能拿到约 3 个 token。哪怕草稿模型的推理耗时占掉一些收益，实际加速比通常也能落在 2 到 3 倍这个区间。而且草稿模型越小、与大模型越“同源”，收益越稳。这也是为什么 EAGLE 这类方案在社区里讨论度那么高——它本质上是把“草稿模型猜得准不准”这件事从架构层面直接优化了。
但注意一个细节：这个公式成立的前提是草稿长度恒定，而且接受率不随位置衰减。真实场景里，越往后的 token 被接受的概率越低，因为草稿模型越往后越容易“跑偏”，所以单纯拉长 l 的边际收益会迅速下降。这也是后面 Parallel Drafting 要解决的第一个痛点。
1.2 单条草稿的瓶颈：草稿错了，整条链就断了
单条草稿的最大问题，在于它的生成是串行的，而且是一条链走到黑。草稿模型在第 3 个位置猜错了一个 token，那么第 4、第 5 个位置即使“原本能猜对”，也因为前面的错误输入而被带偏，整条草稿链直接报废。大模型验证后只能接受前 2 个 token，剩下的计算全部白费。
在代码生成、数学推理这类对 token 精确度要求极高的场景里，这个问题会被放大。自然语言生成里，同义词、近义表达还能靠采样兜底，但代码里一个变量名写错，后面整段都废了。我实测下来，这类任务单条草稿的接受率经常只有 0.5 上下，投机采样的加速比直接从理想的 3 倍掉到 1.5 倍以下，甚至出现负收益。
另外一个容易被忽略的瓶颈是：草稿模型本身也是自回归的，它的耗时随草稿长度线性增长。你要用更长的草稿去博更高的接受率，草稿阶段耗时也在涨，这个矛盾靠“把草稿模型做得更小”是有极限的。于是很自然就会想到：与其让一个草稿模型串行地赌一条路，不如同时让它或它们并行地试几条路，哪条路走通了就用哪条。这就是 Parallel Drafting 的出发点。
2. Parallel Drafting 的思路：与其赌一条路，不如同时试几条路
2.1 多草稿并行到底在并行什么：前缀共享与批量验证
Parallel Drafting 的“并行”有两层含义。第一层是草稿生成阶段的并行分支：在当前已接受前缀的基础上，同时扩展多条候选分支。比如第 1 个位置选 Top-3 候选 token，每个 token 后面继续展开自己的草稿序列，最终形成一棵宽度为 B、深度为 l 的草稿树。第二层是验证阶段的并行：大模型把这 B 条分支放在同一个 batch 里做一次前向，一次性完成所有候选的评分。验证之后，取“与目标模型分布匹配且长度最长”的那条分支作为本轮接受结果，其余分支丢弃。
这个过程的直觉很好类比：单条草稿像一个面试官只面一个候选人，候选人表现不好就只能重来；Parallel Drafting 相当于同时面几个候选人，谁回答得最符合预期就录谁。因为多条分支共享前缀，草稿模型在分叉点之前只需要算一次，真正多出来的成本只是分叉之后的增量计算，所以分支越多、前缀越长，共享带来的节省越明显。
将分支数和接受率挂钩的话，第一位“至少有一个分支被接受”的概率是 1-(1-α)^B。假设 α=0.5，B=3，这个概率是 0.875，比单分支的 0.5 高了将近一倍。当然，后面位置的接受概率会逐位衰减，因为分支之间在前缀上有相关性，不能简单地把第一位公式套用到后面，但整体收益方向是明确的：分支数增加，首 token 被接受的概率显著提升，链条断掉的风险被摊薄了。
2.2 收益与代价的权衡公式：分支数 B、草稿长度 l、接受率 α
Parallel Drafting 不是免费的。每条分支在验证阶段都要占用 batch 中的一个序列槽位，在草稿阶段都要占用草稿模型的批量计算资源。所以这里必须有一套权衡逻辑。我习惯用三个变量来控制收益边界：
- 草稿长度 l：决定单轮能博到的最大 token 数。l 太大，草稿阶段串行步数变多，草稿耗时上升，且后段接受率衰减，收益不划算。
- 分支数 B：决定验证 batch 的宽度。B 太大，验证阶段显存带宽和计算压力上升，边际收益递减。
- 接受率 α：决定任何策略的实际收益。α 太低时，增加 B 和 l 都是往无底洞扔钱。
按我的经验，B 取 2 到 4 通常就够用。B 从 1 提到 2，首 token 接受率提升最明显；B 到 4 之后，多出来的分支基本在重复探索相似路径，白占显存。l 则建议控制在 4 到 8，然后根据实测接受率动态调整。后面 DSpark 那类方案做的“动态调度”，本质上就是在运行时根据最近一段时间的接受率，自动决定下一轮用多大 l、多少 B。
验证阶段的开销也要算清楚。批量验证的耗时约等于一次大模型前向，无论 B=1 还是 B=4，前向本身的固定开销差异不大，但 batch 变大会增加显存带宽压力。如果你的服务本身并发就高，每个并发序列都乘一个 B，验证 batch 会被瞬间撑大，这时候宁可降低 B，也不要盲目追求单个序列的加速比。
3. 三条技术路线的拆解：P-EAGLE、DFlash、DSpark 到底在解决什么问题
3.1 P-EAGLE：在特征空间做草稿，并行分支不重复计算
EAGLE 系列的核心思想，是让草稿模型不再“从 token 到 token”地做语言建模，而是“从特征到特征”：把目标大模型最后一层的隐藏状态作为草稿模型的输入特征，在这个特征空间里做外推和下一 token 预测。因为草稿模型和目标模型共享同一套语义特征空间，草稿分布与目标分布天然对齐，接受率比普通小语言模型高一大截。
P-EAGLE 则可以理解为 EAGLE 思路与 Parallel Drafting 的结合：在特征空间里并行展开多条草稿分支。它的工程关键点在于“特征共享”——所有分支在当前时刻的特征计算只做一次，分叉只发生在 token 采样阶段。这意味着你增加一条分支，草稿阶段的额外成本只是“从共享特征出发，多算一条后续特征链”，而不是“重新算一遍所有前缀”。配合 KV cache 和特征 cache 的复用，B=2 或 B=3 时，草稿阶段的成本增幅远小于线性增长。
这条路线适合的目标场景非常清晰：你手上已经有 EAGLE 系列的草稿模型，且目标模型和草稿模型都基于相同 tokenizer 和类似训练分布。P-EAGLE 想解决的是单条 EAGLE 草稿在长序列、精确语义任务上“后继无力”的问题。它在分支策略上偏保守，通常只对前 1 到 2 个位置做分支，后面保持单链，这样既能提升首段接受率，又不至于把显存撑爆。
3.2 DFlash：把草稿阶段也做成“Flash”级内核 + 草稿文件落地
DFlash 这条线，关注点从“草稿猜得准不准”转向了“草稿出得快不快、可不可复现”。它至少包含两块工程内容。第一块是把 FlashAttention 那套 IO 感知的内核优化思路搬到草稿模型的注意力计算上，减少 HBM 读写量，压缩草稿模型每一步的延迟。草稿模型虽然小，但它是串行跑的，每一步的延迟都会乘上草稿长度，所以“把草稿模型的每一步做快”对端到端延迟的帮助，往往比把草稿模型换大一点更实在。
第二块就是社区里常说的“草稿文件”。实际部署里，草稿模型需要冷启动加载，草稿阶段的中间特征、每轮分支的 token 序列、接受率统计这些信息，如果只能在内存里临时存在，那么每次进程重启、每次调参实验都要重新热一遍，排障和调优都很难做。草稿文件就是把这一层信息落盘：记录草稿模型的版本与量化参数、每一轮草稿的候选序列和中间特征、最终接受结果，形成可回放、可对比、可离线分析的文件产物。调试时可以拿同一份草稿文件反复验证不同验证策略，而不必反复跑推理。
我理解草稿文件的价值，拿草稿纸来类比最贴切：你打草稿的时候把试算过程写在纸上，后面发现算错了，能顺着草稿纸回溯是哪一步出了问题。如果没有这张纸，错了就只能重头再来。DFlash 式的草稿文件在分布式推理和长稳测试里尤其有用——它让推理过程的“过程数据”变得可审计，而不是只有输入输出两个端点。
3.3 DSpark：把多条草稿流“编排”起来，像任务调度器一样管理
DSpark 更像一个端到端的运行时方案，它的名字本身就带着“调度、编排”的暗示。实际落地中，DSpark 做的事是把多条草稿分支看作一组可调度的任务，利用 GPU 上的多个 CUDA stream 或设备端的并行执行单元，让草稿阶段的某条分支计算与验证阶段的另一部分计算重叠起来；同时维护一个滑动窗口统计最近 N 轮的接受率，动态调整下一轮的草稿长度、分支数和接受阈值。
调度器的核心策略并不复杂：接受率高的时段，拉长草稿长度，甚至可以临时增加分支数；接受率掉的阶段，立刻收缩 l 和 B，避免草稿成本和验证 batch 浪费。它相当于把“调参”这件事从人工离线分析变成了在线自适应。这个思路在长对话、多轮生成这类负载波动大的场景里价值很高，因为静态参数很难同时适配“开头平稳”和“中途发散”两种状态。
这三条路线其实可以放在同一张表里对比，方便你按场景选型：
| 方案 | 核心关注点 | 主要手段 | 典型代价 | 适合场景 |
|---|---|---|---|---|
| P-EAGLE | 草稿质量与分支多样性 | 特征空间草稿 + 前缀特征共享的并行分支 | 特征 cache 占显存，分支策略需调优 | 已有 EAGLE 系草稿模型，追求更高接受率 |
| DFlash | 草稿速度与过程可复现 | Flash 级注意力内核优化 + 草稿文件落盘 | 内核适配工作量，文件读写与磁盘占用 | 草稿阶段延迟敏感，需要离线调参与排障 |
| DSpark | 多草稿流的在线调度 | 多 stream 重叠 + 滑动窗口动态调参 | 调度器实现复杂度高，需监控体系配合 | 长对话、负载波动大、需要自适应策略 |
4. 落地实操：Parallel Drafting 的参数配置、工程要点与代码化流程
4.1 核心参数速查与初始化建议
如果你要在自己的推理服务里接 Parallel Drafting，我建议先把下面这几个参数定下来，再谈细节：
| 参数 | 含义 | 建议初始值 | 调整方向 |
|---|---|---|---|
| draft_length | 每条草稿分支的最大长度 | 4 到 6 | 接受率高则上调，草稿延迟高则下调 |
| num_branches | 并行分支数 B | 2 到 3 | 显存充足且首 token 接受率低时上调 |
| top_k / temperature | 草稿分支采样的多样性控制 | top_k=8, temperature=0.7 附近 | 分支过于趋同时提高 temperature |
| 接受阈值 | 验证时 token 被接受的概率门限 | 0.6 到 0.8 | 追求长接受链时下调，追求稳定时上调 |
| 滑动窗口大小 | 统计近期接受率的轮数 | 64 到 128 | 负载波动大时缩小，平稳时放大 |
初始化建议很简单：先按上表保守值跑一轮离线评测，记录接受率和端到端加速比，再逐步调。不要一上来就追求大 B 和长 l，多试几组组合，画出“加速比随 B、l 变化”的曲线，比任何经验值都靠谱。另外，草稿采样分支时不要把 temperature 调太低，否则多条分支高度趋同，并行就失去了“探索不同路径”的意义——这个我在下一节展开说。
4.2 数据流：从草稿生成、批量验证到分支选择
把整个流程代码化，大概是下面这个骨架：
# 伪代码骨架，示意 Parallel Drafting 的主循环 prefix_cache = init_kv_cache(prompt) for step in range(max_steps): # 1. 草稿阶段：基于共享前缀并行扩展 B 条分支 branches = draft_model.expand_branches( prefix=prefix_cache, num_branches=B, draft_length=l, temperature=0.7, top_k=8 ) # 2. 验证阶段：大模型一次前向，同时给所有分支打分 scores = target_model.score_branches(branches) # 3. 分支选择：按接受规则找到最长可接受前缀 best_prefix, accept_len = select_longest_accepted( branches, scores, threshold=0.7 ) # 4. 更新前缀 KV cache，并将接受率统计写回调度器 prefix_cache = extend_kv_cache(prefix_cache, best_prefix) scheduler.report_acceptance(accept_len)这个骨架里最容易被忽略的，是第 3 步“最长可接受前缀”的语义。很多实现只用“概率是否超过阈值”来判断是否接受，这不够。更稳的做法是结合目标模型的分布做随机接受（EAGLE 和投机采样原论文里的做法），也就是一个 token 即使不是 argmax，只要它的概率落在目标分布的覆盖范围内，也有机会被接受。这样能避免草稿分支因为“不是最高概率”而被全部拒掉，白白浪费并行算力。
还有一点：分支扩展时一定要做前缀共享。分叉点之前的 KV cache 和特征 cache 是共用的，新增分支只需要计算分叉点之后的增量。如果实现里没有做这个共享，B 条分支就是 B 份完整序列的重复计算，Parallel Drafting 的成本会直接翻倍，加速比大概率变成负数。
4.3 显存、批处理和延迟的三角关系
Parallel Drafting 的显存代价可以用一个具体例子算清楚。假设目标模型 hidden_size=4096，层数 32，KV cache 每 token 的占用大约是：
2（K和V） × 32（层） × 4096（维度） × 2（fp16 字节数） = 512KB / token
一条长度为 4 的草稿分支，KV cache 增量就是 2MB。B=4 时，单序列的草稿分支额外占用约 6MB。看着不大，但如果服务并发是 32，那就是 192MB 的额外显存，而这还不算草稿模型自身的前向中间激活。在 40GB 级别的 GPU 上，这个量级通常还能接受；如果同时叠加长上下文，KV cache 本身已经吃掉了大量显存，就必须用量化草稿模型或降低 B 来换空间。
延迟方面要盯住两件事。第一，草稿模型每一步的延迟会乘上 l，所以草稿模型的内核效率（DFlash 那条路线的主攻方向）和推理框架的调度开销都会放大到端到端延迟里。第二，验证 batch 变大后，大模型前向的耗时不是严格不变的，batch 从 1 到 4 可能只增加 10% 到 20% 的耗时，但 batch 从 16 到 64 的增幅就会明显变大。在线服务里，建议把 B 控制在 2 到 3，除非你能确认 GPU 的算力和显存余量都很充足。
5. 常见问题与排查技巧实录
5.1 典型问题速查表
把我在实际部署和调优中遇到的典型问题整理成一张表，方便你直接对照：
| 现象 | 可能原因 | 排查手段 | 解决方案 |
|---|---|---|---|
| 加速比忽然下降一半以上 | 草稿模型与目标模型 tokenizer 版本不一致，草稿“牛头不对马嘴” | 检查模型配置中的 tokenizer hash 和 model hash | 统一草稿与目标的 tokenizer，加载前做版本校验 |
| 增加分支数 B 后加速比反而下降 | 分支之间高度趋同，并行探索形同虚设 | 打印各分支首 token 的分布，看是否集中在同一个 token | 提高草稿采样 temperature，降低 top_k 的截断 |
| 草稿长度 l 拉长后收益变差 | 后段接受率衰减太快，草稿成本盖过收益 | 按位置统计接受率曲线，看拐点在哪一位 | 剪短 l，或在接受率拐点之前停止扩链 |
| 显存超限 | B 太大或并发数过高，分支 KV cache 叠加 | 用上述公式估算草稿分支显存增量 | 降 B、降 l，或对草稿模型做量化 |
| 草稿文件缓存命中但结果错误 | 落盘时只存了 token，没存模型版本特征 | 检查草稿文件头部的版本与 hash 信息 | 草稿文件强制携带模型版本、tokenizer 版本、量化参数 |
| 首 token 延迟变大 | 草稿模型的前向没有被隐藏，串行叠加到了首 token 延迟 | 打点统计草稿阶段每条分支的耗时 | 用多 stream 重叠草稿与验证，或做 pre-decode 预热 |
5.2 我踩过的三个坑，写出来给你避雷
第一个坑是前缀共享没做彻底。早期我实现并行分支时，只在 token 层面做了共享，KV cache 还是每条分支独立存。结果 B=4 时显存直接爆了，而且草稿阶段慢了一倍。后来改成“分叉点之前共用一份 cache，分叉之后才为每条分支单独开增量缓存”，显存立刻降下来。这个优化必须在设计阶段就定好，否则后面重构很痛苦。
第二个坑是拿静态接受率去调参。上线初期我按离线评测的接受率把 l 和 B 定死，结果线上负载一波动，接受率掉到离线值的一半，加速比全面失效。后来接了一个 128 轮的滑动窗口，每轮实时统计接受率，低于阈值就自动把 l 降 2、B 降 1，问题才缓解。我的体会是：Parallel Drafting 的参数不是一个固定值，而应该是一个自适应区间。
第三个坑和草稿文件有关。我把草稿文件设计成了只存 token 序列和接受结果，没存模型版本信息。结果目标模型做了一次小版本升级，草稿文件命中缓存后，回放的中间特征和线上模型完全对不上，排障排了一整天，最后发现是缓存数据过期。从那以后，草稿文件的头部强制写入模型版本 hash、tokenizer 版本和量化参数，读文件时先比对再使用。这个教训也印证了 DFlash 那套“草稿文件必须可审计”的设计逻辑是有道理的。
我个人在实际操作中的体会是，Parallel Drafting 并不是投机采样的替代，而是投机采样的增强器。它把单条草稿链的脆弱性摊薄了，但也把显存、调度和调参的复杂度抬上来了。如果团队刚接触投机采样，先把单条草稿的接受率和延迟摸清楚，再加上 P-EAGLE 这类特征级草稿提升质量；等基础收益稳定了，再考虑引入 DFlash 的内核优化和草稿文件机制、DSpark 的动态调度。最后提醒一句：所有参数调整，都建议用草稿文件先在离线环境回放验证几轮，再推到线上，别让线上流量的波动替你做实验。
