一句话定义：Parallel Drafter（并行草稿器）是一种为大模型推理加速的草稿生成方式——它不再让一个小模型逐字猜出后续 token，而是一次前向就并行抛出多个候选 token，交给大模型一次性核对。
它要解决的瓶颈
投机解码（AI 词典：Speculative Decoding">Speculative Decoding）的思路很朴素：让一个又小又快的草稿模型先猜出后面若干个 token，再让大模型（target model）一次前向把猜测全部核对，猜对多少收多少，第一个猜错处截断。大模型的验证确实是并行的，但草稿模型自己仍然是自回归的：猜第 1 个 token，喂回去，再猜第 2 个……想草拟 8 个 token 就得跑 8 次小模型前向。整个循环里，只剩下草稿这一环还在排队。
上下文越长，这个瓶颈越明显：那 8 次前向里，每一次都要重新读一遍不断变长的 KV 缓存（KV cache）。并发一高，验证阶段本就吃满了算力，草稿的串行步骤就成了纯叠加的延迟。
打个比方
你在抄一段英文，想提前敲出后面的字。串行草稿像一个人：猜一个词，回头看一眼前文，再猜下一个。并行草稿则像八个人同时站在第 1 到第 8 个位置上，每人只依据"已经确定的前文"各写一个词，写完交给主编。主编一次性核对全部答案，从前往后读，读到第一个错为止。
代价很明显：写第 5 个位置的人看不到第 4 个位置写了什么，所以单个候选的命中率比串行草稿低一些。但整轮只花"一次前向"的时间，而且八份答案天然构成一棵候选树（tree），主编可以用树状注意力掩码（tree attention）在同一次前向里把所有分支一起打分。于是每轮成本 ≈ 一次草稿前向 + 一次验证前向，与草稿长度几乎脱钩。并行草稿器一般不是单独用的，它和并行验证、树状候选一起，组成常说的"并行投机解码"这套方案。
和传统投机解码的区别
| 维度 | 传统投机解码 | 并行草稿器 |
|---|---|---|
| 草稿生成 | 小模型逐 token 串行 | 一次或少数几步前向并行产出多候选 |
| 草稿耗时 | 随草稿长度线性增长 | 基本不随草稿长度增长 |
| 单候选质量 | 依赖链完整，命中率较高 | 候选彼此看不到，命中率偏低 |
| 最合适的场景 | 低并发、短上下文、延迟敏感 | 高并发、长上下文、吞吐敏感 |
实际意义
对做推理服务的人，这意味着优化目标从"草稿模型多准"转向"步数多不多"：草稿长度、候选树宽度、接受率是三个要一起调的旋钮，还要和连续批处理（continuous batching）、KV 缓存分页管理配合。它是笔交易，不是免费午餐——草稿质量太差，接受率下滑，验证白跑反而更慢。
对普通人，感受是聊天和写代码时首字更快、长文吐字更稳，尤其在长文档问答、整库代码这类长上下文场景里。具体支持情况以各家官方页面和对应论文为准。