做推理加速的人几乎都会碰到同一个尴尬GPU 很贵、显存很大但生成 token 的速度就是上不去。自回归解码一步只出一个字剩下的时间基本都耗在把几百亿参数从显存搬到计算单元的路上。投机采样Speculative Decoding算是少数立竿见影的手段而 Parallel Drafting 则是这个方向上最容易被误解、也最值得搞清楚的一套思路。这篇文章想从 P-EAGLE、DFlash 到 DSpark 这三条典型路线把投机采样里的并行草稿机制拆开讲透顺带把哪些环节容易踩坑、哪些结论和直觉相反都摊开聊聊。1. 为什么投机采样能加速推理几十毫秒背后的算账逻辑1.1 大模型推理的瓶颈访存带宽与自回归的本质先说一个基本事实大模型解码时速度瓶颈通常不是计算量而是显存带宽。一个 70 亿参数的模型FP16 精度下光参数就有约 14GB每次生成一个 token理论上至少要把这些参数从显存读一遍。假设一张 GPU 的显存带宽是 2TB/s单次前向传播光是读参数就要 7 毫秒左右算上 KV cache 读写和中间激活实际单步延迟至少在 10~20 毫秒。一块几万块的卡跑起来每秒只能吐几十个 token用户体验当然不跟手。自回归的本质决定了这一步一个 token 的串行节奏。当前 token 依赖前面所有 tokenGPU 的并行计算能力在这个环节里被严重浪费。算力利用率往往不到 5%大部分时间都在等数据搬运。正因为这种算力富余、带宽受限的状态投机采样才有了操作空间与其逼着大模型一步步自回归不如让一个大模型一次算一批候选 token把所有候选一次验证掉。1.2 投机采样的核心原理草稿与验证的两阶段流水投机采样Speculative Decoding的思路其实很朴素先用一个更轻量的草稿模型快速生成 n 个候选 token再用目标大模型对这 n 个 token 做一次前向验证。验证过程的细节不展开核心是它不能直接贪心地接受全部候选而要按一定的拒绝采样规则逐个确认。目标模型会把草稿模型给出的每个 token 与自己的预测分布做对比概率足够一致就接受不一致就从当前位置用目标模型自己的输出替换。这样得到的分布严格等价于目标模型直接自回归的分布不会因为投机而改变模型本身的生成质量。加速比能不能赚到直接看两个数草稿模型的生成速度和候选 token 的接受率。可如果草稿模型本身也需要自回归地跑 n 步那它节省的只是每步前向传播的参数量变小——总步数没怎么少草稿阶段的时间占比很快会从可忽略变成吃掉了大部分收益。1.3 投机采样的隐含税草稿生成本身成了新瓶颈我实际测过一些轻量草稿模型方案印象很深在 7B 目标模型上一个 100M 左右的草稿模型每步延迟大约是目标模型的 15% 左右。粗看很划算但草稿模型同样要吃显存带宽只是吃得更少。当草稿长度加到 8 到 16 步时草稿阶段累计延迟就能到目标模型单步延迟的 1.2 到 2.4 倍。这个隐含税会直接吞掉投机采样原本想节省的时间最终加速比远低于理论值。Parallel Drafting 就是冲着这个税来的。它不是去压缩草稿模型的每一步耗时而是把草稿生成从串行变成并行一次并行算出 n 个候选 token草稿阶段的总耗时近似等于单个候选的耗时而不是 n 倍。这听起来有点反直觉因为生成 token 明明存在依赖关系。想真正理解它得先搞清楚这几条路线分别用什么方法绕开依赖。2. Parallel Drafting 的核心思路把串行草稿换成并行草稿2.1 从逐步生成到独立候选打破自回归依赖并行草稿的关键不是让自回归模型一次输出多个 token而是重新定义草稿的生成方式让 n 个候选 token 互不依赖。这样它们就可以在同一个前向过程里被一次性算出来甚至可以直接查表取出来。代价是候选质量不再像自回归那样逐 token 动态调整n 个 token 之间的一致性变弱。这里要澄清一个常见误解并行草稿不等于一步解码出 n 个 token 并直接当作答案。它只是提供了 n 个独立的候选真正是否被接受仍然由目标大模型验证。验证阶段还是自回归的只不过不是逐 token 验证而是用一个对未来 n 个位置的并行预测矩阵来一次验证全部候选。目标模型的前向计算被复用了所以总计算量大致等于跑一次 n 步的预填充而不是 n 次自回归。2.2 接受率与期望加速比的关系为什么质量比速度重要投机采样的期望加速比大致可以用这个式子估算期望加速比 ≈ (1 - α^(γ1)) / ((1 - α)(γ Δt_draft / Δt_target))其中 α 是平均接受率γ 是草稿长度Δt_draft 是生成草稿的耗时Δt_target 是目标模型单步前向耗时。式子里的核心信号是即使草稿生成时间降到接近 0在接受率低于某个阈值时加速比依然可能小于 1。比如 γ8 时α 掉到 0.5 以下理论加速比就很不乐观了。Parallel Drafting 最微妙的地方也在这它的草稿生成时间可以压得很低但候选之间的独立性会让接受率天然弱于自回归草稿模型。P-EAGLE 这类特征层外推方案实际上是在努力让并行候选也保留足够的条件概率信息DFlash 这类查表方案则在另一个方向上把草稿耗时压缩到极限赌的是被预测文本有较强的重复模式。2.3 三类并行草稿路线的整体对比为了后面讲起来不乱先给一个总览表把三条路线的关键差异摆出来。维度P-EAGLE特征外推DFlash表驱动/草稿文件DSpark系统级推测执行草稿生成方式轻量解码器在特征空间外推哈希/表查询直接取候选多草稿源统一调度草稿依赖关系并行外推弱依赖完全无依赖混合按策略配置草稿耗时增长随草稿长度增长较慢几乎不随长度增长取决于组合策略接受率天花板中到高中低取决于文本重复度可动态调整策略显存成本轻量解码器参数草稿文件本身各策略的叠加适合场景开放生成、通用对话代码补全、模板文本高吞吐服务化场景后面三个章节就围绕这个表展开分别说清楚每条路线是怎么实现的、边界在哪、实际落地时该注意什么。3. P-EAGLE在特征层外推的并行草稿3.1 为什么选择特征层做外推先回顾一下 EAGLE 系列的基本思路。EAGLE 系列的洞察是与其让草稿模型从头到尾跑一遍完整网络不如直接在目标模型的高层特征上做轻量外推。Transformer 每一层输出的特征向量已经编码了丰富的语义信息已知当前位置的最终隐藏状态去预测下一个位置的隐藏状态理论上比从 token 级硬猜要容易得多。因为特征空间的平滑性通常比词表空间好得多词表里一个词的变化可能对应完全不同的语义而特征向量的变化是渐进的。P-EAGLE 把 EAGLE 的这种外推过程做了并行化改造。传统 EAGLE 草稿依然是一个轻量自回归过程拿到第 t 步特征后预测第 t1 步特征再预测第 t2 步特征一步步往后推。P-EAGLE 的做法是用一个额外的轻量解码器一次性地基于当前位置特征输出未来 n 个位置的特征估计。这个解码器可以是几层 MLP也可以是一个小型 Transformer 解码器关键在于预测目标从下一步 token变成了未来 n 步的特征序列。3.2 P-EAGLE 的并行化改造一次解码、批量验证具体实操时可以这样理解 P-EAGLE 的流程目标模型执行正常前向得到当前位置的 hidden state。轻量解码器以这个 hidden state 为输入一次输出 n 个未来位置的特征向量。这 n 个特征向量各自通过目标模型的输出头LM Head映射成 n 个词表上的概率分布。从每个概率分布里采样出一个候选 token组成 n 个草稿 token。目标模型把这 n 个 token 拼接在已有序列后面做一次并行前向验证按投机采样规则接受或修正。第 2 步就是并行草稿的关键。轻量解码器一次输出 n 个特征不需要循环 n 次。得到的 n 个特征虽然来自同一个当前状态但彼此没有自回归更新所以是并行的。代价是第 3 步的概率分布少了真实历史条件候选 token 之间可能出现前言不搭后语的情况接受率会有一定损失。在实现层面P-EAGLE 的一个常见工程处理是让轻量解码器输出多个低维特征再把它们一次性映射到词表。因为特征维度远小于词表维度比如隐藏维度 4096词表 128k这个映射在计算量上比完整 transformer 层便宜得多。我做过的最优实现里草稿阶段延迟可以控制在目标模型单步延迟的 5%~10% 左右这比传统轻量草稿模型动辄 15%~20% 的开销要友好不少。3.3 P-EAGLE 的工程落地心得如果你想动手集成 P-EAGLE有几个地方比想象中容易出问题。第一个是采样一致性。投机采样必须保证草稿分布和目标模型验证时的分布对齐否则接受率会非常难看。我在早期版本里犯过错误草稿阶段用了 top-p0.8验证阶段用了 top-p0.95结果两个分布偏差很大几乎所有候选都被拒绝加速比直接崩到 0.7。排查了很久才发现不是模型问题而是采样参数不一致。第二个是草稿长度设置。P-EAGLE 的接受率一般不是均匀分布的前 1~2 个 token 接受率很高越往后越低。动态草稿长度在这里非常有用。可以按接受率实时调整下一轮草稿长度接受率高就加长连续几轮低就缩短。固定长度不是不能用只是浪费了最优区间。第三个是 KV cache 的维护。并行草稿阶段虽然没有自回归依赖但目标模型验证时是并行前向这部分计算量的 KV cache 要单独管理不能和主序列的 cache 混在一起。尤其在多 batch 场景下不同序列的已接受草稿长度不同KV cache 的拼接逻辑稍不注意就会索引错位。4. DFlash表驱动草稿与草稿文件机制4.1 DFlash 的核心逻辑草稿从推理变成查表DFlash 走了一条完全不同的路。它不打算让任何神经网络去预测草稿 token而是把草稿生成变成一次查表操作。这里的核心资产是一个预先构建好的草稿文件draft file里面存的是某种上下文特征到候选 token 序列的映射关系。在线推理时根据当前已有的上下文计算出查询键直接在表里取出一组候选 token连神经网络的前向都不需要。这正是热词里dflash 草稿文件指向的东西。草稿文件的构建通常离线完成在大量语料或领域数据上统计 n-gram 频次、聚类上下文特征、或者训练一个小型的哈希映射模型。然后把这些规则固化成一张查找表推理时加载进内存。因为查表操作没有循环依赖n 个候选 token 可以一次全部取出并行性天然成立而且没有任何神经网络执行开销。从硬件角度看DFlash 也更讨巧。查表的延迟主要看哈希计算和访存这些操作在 CPU 或 GPU 上都非常容易并行。做得好时取 n 个候选的耗时只有几十微秒和目标模型动辄十几毫秒的单步前向相比完全不是一个量级。把草稿阶段的开销压到接近零这是 DFlash 相比 P-EAGLE 最直接的优势。4.2 草稿文件的构造与缓存友好性草稿文件的具体形态可以有很多种但常见的做法是紧凑哈希表或前缀树。我见过一种比较实用的设计把上下文窗口里的最近 k 个 token 作为键使用类似 Bloom Filter 或 locality-sensitive hashing 的方法映射到表项每个表项里存一组候选 token 序列和对应的置信度。查询时先做一次哈希定位再把候选读出来整个流程可以控制在几微秒级。这里有一个工程细节值得注意草稿文件要放到访存友好的位置。如果表很大GPU 显存放不下要考虑放到主存并用 RDMA 或统一内存访问。如果表不大尽量放 GPU 共享内存或 L2 cache 附近避免每次查询都走一次 PCIe。实测下来把高频表项放在 GPU 端、低频部分留在 CPU 端的分片方案效果通常比单一大表更好因为热点很集中。草稿文件不是越大越好。表太大会稀释命中率表太小则覆盖率不足。构建时需要在数据分布上做权衡对代码模型常见 token 序列的重复度很高表可以做小一点对开放式长文本生成上下文变化太快表命中率会下降。我会在构建阶段先统计验证集上的 top-k 2-gram/3-gram 覆盖度再决定表的大小而不是凭感觉拍一个值。4.3 DFlash 与 P-EAGLE 的对比适用场景分明DFlash 的强项是草稿耗时极低、实现简单、可解释性强弱项是候选 token 之间没有任何语义建模接受率上限比较有限。在重复模式多的场景里比如代码补全、JSON 生成、SQL 生成、模板化文案DFlash 效果能非常好。我做过一个代码补全的对比实验DFlash 在这类场景的接受率可以到 60% 以上加速比甚至超过 P-EAGLE。但换到开放式对话里接受率可能掉到 20%~30%加速比就不太理想了。P-EAGLE 的优势在于候选质量更高因为它确实在建一个特征层面的条件模型对开放文本的适应能力更强。它的弱势是草稿阶段仍然有一些神经网络计算虽然比目标模型轻得多但终究不是纯粹查表。选型建议上我的经验是看任务类型如果文本模式规律性强优先 DFlash简单直接如果偏开放生成优先 P-EAGLE 这类质量优先的方案。但也别把两者对立起来实际框架里完全可以把它们叠加在一起作为两个草稿源用 DFlash 的高频候选打底、用 P-EAGLE 的动态候选补足长尾。5. DSpark把并行草稿变成推理框架的原生能力5.1 DSpark 想解决的问题系统级开销P-EAGLE 和 DFlash 解决的是草稿怎么生成DSpark 想解决的是草稿怎么被系统高效调度。在真实服务场景里一个请求可能同时存在多个草稿源、多个验证批次、动态序列长度、不同优先级这些乱七八糟的状态如果管理不好草稿阶段省下的时间会被调度开销和内存碎片重新吃掉。DSpark 本质上是一个推测执行引擎它不是某一种单一的草稿策略而是把多个草稿策略统一管理起来。你可以把它理解成一个调度层每个序列进入解码阶段后DSpark 会根据当前上下文和系统负载情况动态选择使用 P-EAGLE 外推、DFlash 查表、还是两者混合然后统一调度到目标模型的验证前向里。5.2 推测执行引擎的设计从我接触过的类似系统来看一个可用的 DSpark 类引擎至少要包含四个部分第一个是草稿源管理。每种草稿策略被包装成一个独立的草稿源暴露统一的接口给定当前上下文返回候选 token 列表和置信度。新加一种草稿策略就是新增一个源不用改动验证主链路。P-EAGLE 可以是一个源DFlash 可以是另一个源后面如果再出现更轻的草稿模型同样挂进来。第二个是策略选择器。它决定当前请求该用哪个草稿源、草稿长度该设多少。最简单的是基于规则文本重复度高的走 DFlash否则走 P-EAGLE。更进一步的可以做一个轻量决策模型把请求类型、最近接受率、当前 batch 大小都作为特征动态调整草稿长度和策略。第三个是统一验证器。目标模型的前向验证是所有草稿源共用的。无论候选来自哪里最终都要拼接到主序列后面做一次并行验证。验证器需要支持不同长度的候选对齐、合理的 attention mask 设置以及 KV cache 的高效更新。这里的实现质量直接决定实际加速比能兑现多少。第四个是性能反馈回路。系统每轮验证后统计每个草稿源的接受率、草稿耗时、真实加速比反馈给策略选择器。这个闭环非常关键因为没有一套策略能适配所有流量靠动态反馈才能长期稳定。5.3 实测效果与选型建议我参考了一些公开的性能数据和自己的对比测试把 DSpark 这类系统级方案和单独使用某一种并行草稿策略做了对比。单独用 P-EAGLE 时理想情况下的端到端加速比大约在 1.8~2.5 倍单独用 DFlash 在代码类任务上也可能到 1.8 倍左右但在对话任务上可能只有 1.1~1.3 倍。DSpark 这类调度引擎的价值不是拉高单任务的峰值而是保证不同任务混流时的整体吞吐实测混流场景里它能比单一策略稳定高出 20% 到 40% 的吞吐代价是工程复杂度明显上升。如果你的场景是单一任务、单一模型、追求极致延迟我建议先单独验证 P-EAGLE 或 DFlash没必要一上来就上一个调度引擎。如果你的场景是不同请求混在一起比如一个 API 网关同时面对代码补全和对话生成那 DSpark 的系统级调度会更值得投入。说到底并行草稿不是一个算法问题而是一整套工程取舍问题前期花一小时做数据分析和方案选型能省下后面几天的调试时间。6. 工程落地中的常见问题与排查技巧6.1 草稿接受率异常低的排查思路接受率掉到很离谱的水平时先别急着怀疑模型实现按下面这几项排查大概率能找到问题。采样参数是否一致是第一个要查的。temperature、top-p、top-k 任何一个不一致草稿分布和目标模型验证分布都会偏差。建议把采样参数抽成全局配置草稿阶段和验证阶段读同一份配置避免复制错。位置编码是否匹配是第二个容易踩坑的点。有些实现里草稿模型或草稿源拿到的上下文位置偏移和目标模型差了 1 位尤其是并行草稿拼接验证的瞬间RoPE 位置很容易对不上。这个问题非常隐蔽因为只有验证位置的 token 会出现系统性低接受率其他位置正常。第三个是 OOV 或特殊 token 处理不一致。草稿阶段如果对部分 token 做了过滤而验证阶段没有两边分布会有系统性偏差。建议统一 tokenizer 和词表过滤逻辑最好单独跑一次工具函数把草稿分布和目标分布打印出来做对比别全靠肉眼猜。6.2 草稿文件/轻量模型带来的显存代价投机采样的显存开销经常被低估。P-EAGLE 的轻量解码器参数量不大但要让草稿阶段跑得快还得考虑它自己的 KV cacheDFlash 的草稿文件如果到了几百 MB也不是完全无感。在显存紧张的环境里建议把草稿资源压缩到最小可用水平或者直接做显存外的映射访问。我踩过的具体坑是 DFlash 草稿文件默认加载到 GPU 显存结果 7B 模型加上 512MB 草稿文件直接 OOM。后来改成冷热分片把热点表放 GPU、冷数据放 CPUOOM 问题就消失了命中率只损失了几个百分点。这个做法值得一试。6.3 测量加速比时的常见误区另一个常见问题是加速比测不准。很多人直接对比开了投机采样前后的整体 wall-clock 时延忽略了几件事输入长度不同、输出长度不同、预热次数不足、GPU 频率波动。更靠谱的做法是固定输入输出长度用相同的随机种子跑多轮取中位数或多次平均值对比。还要注意 batch 效应。投机采样在 batch size 很小的场景收益明显随着 batch 增大目标模型的前向计算越来越饱和草稿阶段省下的比例会变小。我见过有人在 batch1 时测出 2 倍加速结果到生产环境 batch32 时加速比掉到 1.2 倍这不一定代表实现有问题而是场景变了。建议在目标 batch 范围里做几组对比别只看单点值。6.4 动态草稿长度与批处理对齐的一个实用技巧最后分享一个关于动态草稿长度的经验。投机采样在批处理场景里很容易被最长草稿长度拖累一个请求想要的草稿长度是 8另一个是 2系统为了对齐往往让所有人跑 8这纯属浪费。一个比较实用的做法是做截止时间感知调度每一轮验证前统计各序列当前的接受率接受率低的序列提前截断接受率高的序列继续加长然后用一个最大公倍数或分组方式把同批次序列按草稿长度相近的分到一组。这样浪费的 padding 最少验证矩阵也不算稀疏。我实测过这个做法在混流场景下能多出 10% 左右的吞吐虽然没有理论加速比那么惊艳但在贵价 GPU 上这 10% 已经是实打实的成本节省。如果你正在做一个高吞吐推理服务这个点值得优先优化比盲目调大草稿长度更有效。 
长河君 · 2026/11/4 13:16:14 · 阅读 1.2k 并行草稿机制解析：从P-EAGLE到DSpark的投机采样加速
做推理加速的人几乎都会碰到同一个尴尬GPU 很贵、显存很大但生成 token 的速度就是上不去。自回归解码一步只出一个字剩下的时间基本都耗在把几百亿参数从显存搬到计算单元的路上。投机采样Speculative Decoding算是少数立竿见影的手段而 Parallel Drafting 则是这个方向上最容易被误解、也最值得搞清楚的一套思路。这篇文章想从 P-EAGLE、DFlash 到 DSpark 这三条典型路线把投机采样里的并行草稿机制拆开讲透顺带把哪些环节容易踩坑、哪些结论和直觉相反都摊开聊聊。1. 为什么投机采样能加速推理几十毫秒背后的算账逻辑1.1 大模型推理的瓶颈访存带宽与自回归的本质先说一个基本事实大模型解码时速度瓶颈通常不是计算量而是显存带宽。一个 70 亿参数的模型FP16 精度下光参数就有约 14GB每次生成一个 token理论上至少要把这些参数从显存读一遍。假设一张 GPU 的显存带宽是 2TB/s单次前向传播光是读参数就要 7 毫秒左右算上 KV cache 读写和中间激活实际单步延迟至少在 10~20 毫秒。一块几万块的卡跑起来每秒只能吐几十个 token用户体验当然不跟手。自回归的本质决定了这一步一个 token 的串行节奏。当前 token 依赖前面所有 tokenGPU 的并行计算能力在这个环节里被严重浪费。算力利用率往往不到 5%大部分时间都在等数据搬运。正因为这种算力富余、带宽受限的状态投机采样才有了操作空间与其逼着大模型一步步自回归不如让一个大模型一次算一批候选 token把所有候选一次验证掉。1.2 投机采样的核心原理草稿与验证的两阶段流水投机采样Speculative Decoding的思路其实很朴素先用一个更轻量的草稿模型快速生成 n 个候选 token再用目标大模型对这 n 个 token 做一次前向验证。验证过程的细节不展开核心是它不能直接贪心地接受全部候选而要按一定的拒绝采样规则逐个确认。目标模型会把草稿模型给出的每个 token 与自己的预测分布做对比概率足够一致就接受不一致就从当前位置用目标模型自己的输出替换。这样得到的分布严格等价于目标模型直接自回归的分布不会因为投机而改变模型本身的生成质量。加速比能不能赚到直接看两个数草稿模型的生成速度和候选 token 的接受率。可如果草稿模型本身也需要自回归地跑 n 步那它节省的只是每步前向传播的参数量变小——总步数没怎么少草稿阶段的时间占比很快会从可忽略变成吃掉了大部分收益。1.3 投机采样的隐含税草稿生成本身成了新瓶颈我实际测过一些轻量草稿模型方案印象很深在 7B 目标模型上一个 100M 左右的草稿模型每步延迟大约是目标模型的 15% 左右。粗看很划算但草稿模型同样要吃显存带宽只是吃得更少。当草稿长度加到 8 到 16 步时草稿阶段累计延迟就能到目标模型单步延迟的 1.2 到 2.4 倍。这个隐含税会直接吞掉投机采样原本想节省的时间最终加速比远低于理论值。Parallel Drafting 就是冲着这个税来的。它不是去压缩草稿模型的每一步耗时而是把草稿生成从串行变成并行一次并行算出 n 个候选 token草稿阶段的总耗时近似等于单个候选的耗时而不是 n 倍。这听起来有点反直觉因为生成 token 明明存在依赖关系。想真正理解它得先搞清楚这几条路线分别用什么方法绕开依赖。2. Parallel Drafting 的核心思路把串行草稿换成并行草稿2.1 从逐步生成到独立候选打破自回归依赖并行草稿的关键不是让自回归模型一次输出多个 token而是重新定义草稿的生成方式让 n 个候选 token 互不依赖。这样它们就可以在同一个前向过程里被一次性算出来甚至可以直接查表取出来。代价是候选质量不再像自回归那样逐 token 动态调整n 个 token 之间的一致性变弱。这里要澄清一个常见误解并行草稿不等于一步解码出 n 个 token 并直接当作答案。它只是提供了 n 个独立的候选真正是否被接受仍然由目标大模型验证。验证阶段还是自回归的只不过不是逐 token 验证而是用一个对未来 n 个位置的并行预测矩阵来一次验证全部候选。目标模型的前向计算被复用了所以总计算量大致等于跑一次 n 步的预填充而不是 n 次自回归。2.2 接受率与期望加速比的关系为什么质量比速度重要投机采样的期望加速比大致可以用这个式子估算期望加速比 ≈ (1 - α^(γ1)) / ((1 - α)(γ Δt_draft / Δt_target))其中 α 是平均接受率γ 是草稿长度Δt_draft 是生成草稿的耗时Δt_target 是目标模型单步前向耗时。式子里的核心信号是即使草稿生成时间降到接近 0在接受率低于某个阈值时加速比依然可能小于 1。比如 γ8 时α 掉到 0.5 以下理论加速比就很不乐观了。Parallel Drafting 最微妙的地方也在这它的草稿生成时间可以压得很低但候选之间的独立性会让接受率天然弱于自回归草稿模型。P-EAGLE 这类特征层外推方案实际上是在努力让并行候选也保留足够的条件概率信息DFlash 这类查表方案则在另一个方向上把草稿耗时压缩到极限赌的是被预测文本有较强的重复模式。2.3 三类并行草稿路线的整体对比为了后面讲起来不乱先给一个总览表把三条路线的关键差异摆出来。维度P-EAGLE特征外推DFlash表驱动/草稿文件DSpark系统级推测执行草稿生成方式轻量解码器在特征空间外推哈希/表查询直接取候选多草稿源统一调度草稿依赖关系并行外推弱依赖完全无依赖混合按策略配置草稿耗时增长随草稿长度增长较慢几乎不随长度增长取决于组合策略接受率天花板中到高中低取决于文本重复度可动态调整策略显存成本轻量解码器参数草稿文件本身各策略的叠加适合场景开放生成、通用对话代码补全、模板文本高吞吐服务化场景后面三个章节就围绕这个表展开分别说清楚每条路线是怎么实现的、边界在哪、实际落地时该注意什么。3. P-EAGLE在特征层外推的并行草稿3.1 为什么选择特征层做外推先回顾一下 EAGLE 系列的基本思路。EAGLE 系列的洞察是与其让草稿模型从头到尾跑一遍完整网络不如直接在目标模型的高层特征上做轻量外推。Transformer 每一层输出的特征向量已经编码了丰富的语义信息已知当前位置的最终隐藏状态去预测下一个位置的隐藏状态理论上比从 token 级硬猜要容易得多。因为特征空间的平滑性通常比词表空间好得多词表里一个词的变化可能对应完全不同的语义而特征向量的变化是渐进的。P-EAGLE 把 EAGLE 的这种外推过程做了并行化改造。传统 EAGLE 草稿依然是一个轻量自回归过程拿到第 t 步特征后预测第 t1 步特征再预测第 t2 步特征一步步往后推。P-EAGLE 的做法是用一个额外的轻量解码器一次性地基于当前位置特征输出未来 n 个位置的特征估计。这个解码器可以是几层 MLP也可以是一个小型 Transformer 解码器关键在于预测目标从下一步 token变成了未来 n 步的特征序列。3.2 P-EAGLE 的并行化改造一次解码、批量验证具体实操时可以这样理解 P-EAGLE 的流程目标模型执行正常前向得到当前位置的 hidden state。轻量解码器以这个 hidden state 为输入一次输出 n 个未来位置的特征向量。这 n 个特征向量各自通过目标模型的输出头LM Head映射成 n 个词表上的概率分布。从每个概率分布里采样出一个候选 token组成 n 个草稿 token。目标模型把这 n 个 token 拼接在已有序列后面做一次并行前向验证按投机采样规则接受或修正。第 2 步就是并行草稿的关键。轻量解码器一次输出 n 个特征不需要循环 n 次。得到的 n 个特征虽然来自同一个当前状态但彼此没有自回归更新所以是并行的。代价是第 3 步的概率分布少了真实历史条件候选 token 之间可能出现前言不搭后语的情况接受率会有一定损失。在实现层面P-EAGLE 的一个常见工程处理是让轻量解码器输出多个低维特征再把它们一次性映射到词表。因为特征维度远小于词表维度比如隐藏维度 4096词表 128k这个映射在计算量上比完整 transformer 层便宜得多。我做过的最优实现里草稿阶段延迟可以控制在目标模型单步延迟的 5%~10% 左右这比传统轻量草稿模型动辄 15%~20% 的开销要友好不少。3.3 P-EAGLE 的工程落地心得如果你想动手集成 P-EAGLE有几个地方比想象中容易出问题。第一个是采样一致性。投机采样必须保证草稿分布和目标模型验证时的分布对齐否则接受率会非常难看。我在早期版本里犯过错误草稿阶段用了 top-p0.8验证阶段用了 top-p0.95结果两个分布偏差很大几乎所有候选都被拒绝加速比直接崩到 0.7。排查了很久才发现不是模型问题而是采样参数不一致。第二个是草稿长度设置。P-EAGLE 的接受率一般不是均匀分布的前 1~2 个 token 接受率很高越往后越低。动态草稿长度在这里非常有用。可以按接受率实时调整下一轮草稿长度接受率高就加长连续几轮低就缩短。固定长度不是不能用只是浪费了最优区间。第三个是 KV cache 的维护。并行草稿阶段虽然没有自回归依赖但目标模型验证时是并行前向这部分计算量的 KV cache 要单独管理不能和主序列的 cache 混在一起。尤其在多 batch 场景下不同序列的已接受草稿长度不同KV cache 的拼接逻辑稍不注意就会索引错位。4. DFlash表驱动草稿与草稿文件机制4.1 DFlash 的核心逻辑草稿从推理变成查表DFlash 走了一条完全不同的路。它不打算让任何神经网络去预测草稿 token而是把草稿生成变成一次查表操作。这里的核心资产是一个预先构建好的草稿文件draft file里面存的是某种上下文特征到候选 token 序列的映射关系。在线推理时根据当前已有的上下文计算出查询键直接在表里取出一组候选 token连神经网络的前向都不需要。这正是热词里dflash 草稿文件指向的东西。草稿文件的构建通常离线完成在大量语料或领域数据上统计 n-gram 频次、聚类上下文特征、或者训练一个小型的哈希映射模型。然后把这些规则固化成一张查找表推理时加载进内存。因为查表操作没有循环依赖n 个候选 token 可以一次全部取出并行性天然成立而且没有任何神经网络执行开销。从硬件角度看DFlash 也更讨巧。查表的延迟主要看哈希计算和访存这些操作在 CPU 或 GPU 上都非常容易并行。做得好时取 n 个候选的耗时只有几十微秒和目标模型动辄十几毫秒的单步前向相比完全不是一个量级。把草稿阶段的开销压到接近零这是 DFlash 相比 P-EAGLE 最直接的优势。4.2 草稿文件的构造与缓存友好性草稿文件的具体形态可以有很多种但常见的做法是紧凑哈希表或前缀树。我见过一种比较实用的设计把上下文窗口里的最近 k 个 token 作为键使用类似 Bloom Filter 或 locality-sensitive hashing 的方法映射到表项每个表项里存一组候选 token 序列和对应的置信度。查询时先做一次哈希定位再把候选读出来整个流程可以控制在几微秒级。这里有一个工程细节值得注意草稿文件要放到访存友好的位置。如果表很大GPU 显存放不下要考虑放到主存并用 RDMA 或统一内存访问。如果表不大尽量放 GPU 共享内存或 L2 cache 附近避免每次查询都走一次 PCIe。实测下来把高频表项放在 GPU 端、低频部分留在 CPU 端的分片方案效果通常比单一大表更好因为热点很集中。草稿文件不是越大越好。表太大会稀释命中率表太小则覆盖率不足。构建时需要在数据分布上做权衡对代码模型常见 token 序列的重复度很高表可以做小一点对开放式长文本生成上下文变化太快表命中率会下降。我会在构建阶段先统计验证集上的 top-k 2-gram/3-gram 覆盖度再决定表的大小而不是凭感觉拍一个值。4.3 DFlash 与 P-EAGLE 的对比适用场景分明DFlash 的强项是草稿耗时极低、实现简单、可解释性强弱项是候选 token 之间没有任何语义建模接受率上限比较有限。在重复模式多的场景里比如代码补全、JSON 生成、SQL 生成、模板化文案DFlash 效果能非常好。我做过一个代码补全的对比实验DFlash 在这类场景的接受率可以到 60% 以上加速比甚至超过 P-EAGLE。但换到开放式对话里接受率可能掉到 20%~30%加速比就不太理想了。P-EAGLE 的优势在于候选质量更高因为它确实在建一个特征层面的条件模型对开放文本的适应能力更强。它的弱势是草稿阶段仍然有一些神经网络计算虽然比目标模型轻得多但终究不是纯粹查表。选型建议上我的经验是看任务类型如果文本模式规律性强优先 DFlash简单直接如果偏开放生成优先 P-EAGLE 这类质量优先的方案。但也别把两者对立起来实际框架里完全可以把它们叠加在一起作为两个草稿源用 DFlash 的高频候选打底、用 P-EAGLE 的动态候选补足长尾。5. DSpark把并行草稿变成推理框架的原生能力5.1 DSpark 想解决的问题系统级开销P-EAGLE 和 DFlash 解决的是草稿怎么生成DSpark 想解决的是草稿怎么被系统高效调度。在真实服务场景里一个请求可能同时存在多个草稿源、多个验证批次、动态序列长度、不同优先级这些乱七八糟的状态如果管理不好草稿阶段省下的时间会被调度开销和内存碎片重新吃掉。DSpark 本质上是一个推测执行引擎它不是某一种单一的草稿策略而是把多个草稿策略统一管理起来。你可以把它理解成一个调度层每个序列进入解码阶段后DSpark 会根据当前上下文和系统负载情况动态选择使用 P-EAGLE 外推、DFlash 查表、还是两者混合然后统一调度到目标模型的验证前向里。5.2 推测执行引擎的设计从我接触过的类似系统来看一个可用的 DSpark 类引擎至少要包含四个部分第一个是草稿源管理。每种草稿策略被包装成一个独立的草稿源暴露统一的接口给定当前上下文返回候选 token 列表和置信度。新加一种草稿策略就是新增一个源不用改动验证主链路。P-EAGLE 可以是一个源DFlash 可以是另一个源后面如果再出现更轻的草稿模型同样挂进来。第二个是策略选择器。它决定当前请求该用哪个草稿源、草稿长度该设多少。最简单的是基于规则文本重复度高的走 DFlash否则走 P-EAGLE。更进一步的可以做一个轻量决策模型把请求类型、最近接受率、当前 batch 大小都作为特征动态调整草稿长度和策略。第三个是统一验证器。目标模型的前向验证是所有草稿源共用的。无论候选来自哪里最终都要拼接到主序列后面做一次并行验证。验证器需要支持不同长度的候选对齐、合理的 attention mask 设置以及 KV cache 的高效更新。这里的实现质量直接决定实际加速比能兑现多少。第四个是性能反馈回路。系统每轮验证后统计每个草稿源的接受率、草稿耗时、真实加速比反馈给策略选择器。这个闭环非常关键因为没有一套策略能适配所有流量靠动态反馈才能长期稳定。5.3 实测效果与选型建议我参考了一些公开的性能数据和自己的对比测试把 DSpark 这类系统级方案和单独使用某一种并行草稿策略做了对比。单独用 P-EAGLE 时理想情况下的端到端加速比大约在 1.8~2.5 倍单独用 DFlash 在代码类任务上也可能到 1.8 倍左右但在对话任务上可能只有 1.1~1.3 倍。DSpark 这类调度引擎的价值不是拉高单任务的峰值而是保证不同任务混流时的整体吞吐实测混流场景里它能比单一策略稳定高出 20% 到 40% 的吞吐代价是工程复杂度明显上升。如果你的场景是单一任务、单一模型、追求极致延迟我建议先单独验证 P-EAGLE 或 DFlash没必要一上来就上一个调度引擎。如果你的场景是不同请求混在一起比如一个 API 网关同时面对代码补全和对话生成那 DSpark 的系统级调度会更值得投入。说到底并行草稿不是一个算法问题而是一整套工程取舍问题前期花一小时做数据分析和方案选型能省下后面几天的调试时间。6. 工程落地中的常见问题与排查技巧6.1 草稿接受率异常低的排查思路接受率掉到很离谱的水平时先别急着怀疑模型实现按下面这几项排查大概率能找到问题。采样参数是否一致是第一个要查的。temperature、top-p、top-k 任何一个不一致草稿分布和目标模型验证分布都会偏差。建议把采样参数抽成全局配置草稿阶段和验证阶段读同一份配置避免复制错。位置编码是否匹配是第二个容易踩坑的点。有些实现里草稿模型或草稿源拿到的上下文位置偏移和目标模型差了 1 位尤其是并行草稿拼接验证的瞬间RoPE 位置很容易对不上。这个问题非常隐蔽因为只有验证位置的 token 会出现系统性低接受率其他位置正常。第三个是 OOV 或特殊 token 处理不一致。草稿阶段如果对部分 token 做了过滤而验证阶段没有两边分布会有系统性偏差。建议统一 tokenizer 和词表过滤逻辑最好单独跑一次工具函数把草稿分布和目标分布打印出来做对比别全靠肉眼猜。6.2 草稿文件/轻量模型带来的显存代价投机采样的显存开销经常被低估。P-EAGLE 的轻量解码器参数量不大但要让草稿阶段跑得快还得考虑它自己的 KV cacheDFlash 的草稿文件如果到了几百 MB也不是完全无感。在显存紧张的环境里建议把草稿资源压缩到最小可用水平或者直接做显存外的映射访问。我踩过的具体坑是 DFlash 草稿文件默认加载到 GPU 显存结果 7B 模型加上 512MB 草稿文件直接 OOM。后来改成冷热分片把热点表放 GPU、冷数据放 CPUOOM 问题就消失了命中率只损失了几个百分点。这个做法值得一试。6.3 测量加速比时的常见误区另一个常见问题是加速比测不准。很多人直接对比开了投机采样前后的整体 wall-clock 时延忽略了几件事输入长度不同、输出长度不同、预热次数不足、GPU 频率波动。更靠谱的做法是固定输入输出长度用相同的随机种子跑多轮取中位数或多次平均值对比。还要注意 batch 效应。投机采样在 batch size 很小的场景收益明显随着 batch 增大目标模型的前向计算越来越饱和草稿阶段省下的比例会变小。我见过有人在 batch1 时测出 2 倍加速结果到生产环境 batch32 时加速比掉到 1.2 倍这不一定代表实现有问题而是场景变了。建议在目标 batch 范围里做几组对比别只看单点值。6.4 动态草稿长度与批处理对齐的一个实用技巧最后分享一个关于动态草稿长度的经验。投机采样在批处理场景里很容易被最长草稿长度拖累一个请求想要的草稿长度是 8另一个是 2系统为了对齐往往让所有人跑 8这纯属浪费。一个比较实用的做法是做截止时间感知调度每一轮验证前统计各序列当前的接受率接受率低的序列提前截断接受率高的序列继续加长然后用一个最大公倍数或分组方式把同批次序列按草稿长度相近的分到一组。这样浪费的 padding 最少验证矩阵也不算稀疏。我实测过这个做法在混流场景下能多出 10% 左右的吞吐虽然没有理论加速比那么惊艳但在贵价 GPU 上这 10% 已经是实打实的成本节省。如果你正在做一个高吞吐推理服务这个点值得优先优化比盲目调大草稿长度更有效。