arXiv'26 | PCTree：DSpark 的草稿链换成树，接受长度白赚 30%
arXiv’26 | PCTree：DSpark 的草稿链换成树，接受长度白赚 30%
原文：From Chains to Trees: Parent-Conditioned Drafting for Semi-Autoregressive Speculative Decoding
1. 前言：先把背景交代清楚
你有没有想过这样一个问题：同一个草稿模型，同一份计算预算，能不能在”草稿阶段”就把多点可能性留住？
接着上篇 DFlash 的坑说。投机解码的两条路线我们都很熟了：
- AR drafter（如 EAGLE-3）：逐 token 串行打草稿，质量高，但打草稿的时间随草稿长度线性涨；
- Parallel drafter（如 DFlash）：一个 block 一次并行算完，草稿极快，但 block 内部每个 token 都是”盲猜”——suffix decay，越靠后越不靠谱。
DSpark 走的是第三条路：半自回归——一次并行 backbone 前向给出 block 的 base logits，再用一个轻量 Markov head 逐位置串行修正，把”看着当前位置之前已知的 token”这个条件依赖补进去。思路很优雅，但 DSpark 有个没解决的结构问题：它打出来的是一根链。
链就链吧，有什么不好？问题在于投机解码的验收规则很残酷：一旦链上某个位置被 target 拒绝，后面所有草稿全作废（rejection sampling）。所以链越长，前面的一个错越贵；而 DSpark 又不得不把块设得长一点才划算——这就是 DSpark 里”草稿块越大 = 越划算的假象”背后埋的雷。
今天这篇 PCTree（arXiv 2608.02123）做的事一句话讲完：一个人可以靠修正头支持多条互不冲突的草稿路径，把它从”一条链”扩展成”一棵树”，且不重新训练、不多跑一次 backbone 前向。 在 Qwen3-4B/8B/14B、九个 benchmark 上，相对同配置 DSpark 的加速提升 3.1%–29.5%；GSM8K 上平均每轮接受的 token 从 9.41 涨到 11.16，端到端 AR 加速 6.14×→6.60×。听起来增益不大？注意：这是把别人已有的草稿白捡出 30% 的边际收益，不花一分训练钱。
先说清楚它的前提——”Markov head 可以按父节点分别打分”这件事，到底为什么成立。
2. DSpark 的限制：条件结构被当成了单链在用
DSpark 的打草稿流程：anchor token $x_t$ 输入并行 backbone，一步前向算出 block 的 base logits $L_0 \ldots L_{B-1}$；然后 Markov head 在第 $d$ 步做：
\[p_d(y \mid y_{<d}) = \mathrm{softmax}(L_d + W \cdot \mathrm{emb}(y_{d-1}))\]也就是只用前一个已选 token 修正当前位置的分布。这个公式看着平平无奇，但它有一个被 DSpark 浪费掉的特性：每个位置的分布，其实可以针对每一个具体父 token 分别计算——因为修正项只依赖父 token 的 embedding，而 embedding 是共享的、已经算好的。
DSpark 的用法是：第 $d$ 位只取前一个位置选中的那个 token 当父节点，一条路走到黑。而 PCTree 的观察是：父节点集合本质上是一个 batch，把 $L_d$ 广播开，Z_d = L_d + W^T P_{d-1} 一次矩阵算就能拿到”当前层所有父节点各自对应的子分布”。于是草稿从一条链，顺理成章变成一棵可以分叉的树——代价只是个 batch matmul。
想清楚这点的确挺妙：能力的载体（修正头）没变，变的是我们用它的方式。
3. PCTree：预算约束下的树构建
3.1 三个要点
- 父条件打分（Parent-Conditioned Expansion）：每个父节点 $p$ 对它自己的候选子节点计算条件概率 $\pi_d(\cdot \mid p)$，路径得分就是各步条件概率连乘——注意是真条件，不是把 block 的平行草稿缝起来那种伪条件；
- 预算约束：每层每个父只取 top-k 子节点（k=4 默认），层内再做全局 top-k 剪枝（frontier 不超过 k）；所有 B 层扩展完后，把所有节点按”路径得分降序、深度升序、稳定 ID”排序，截取 top-N（N=32 默认）作为最终验证树；
- 前缀闭合：由于子节点得分必低于父节点，top-N 集合天然前缀闭合（prefix-closed）——被选的节点要么是根路径上的，要么是根路径的祖先节点都在；于是可以生成一个祖先限制的 tree attention mask，target model 一次 forward 验证整棵树。
由于 k=1 时（每父节点只留一个孩子、每层不剪枝）PCTree 数学上完全退化回 DSpark——这篇论文的所有实验都以”k=1 即 DSpark”为对照点，非常干净。流程图如下：左边是 DSpark 的单链草稿，右边是 PCT 的树草稿与一次验收：
4. 效果：主要是”白赚”和”不亏”
4.1 主结果
论文表格的核心其实是“同配置 DSpark vs PCT 的差”。抽取三个代表性任务（Qwen3-4B, k=4, N=32）：
| 任务 | B | DSpark τ | PCTree τ | τ 增幅 | AR 加速 DSpark→PCTree |
|---|---|---|---|---|---|
| GSM8K | 7 | 6.31 | 7.24 | +14.8% | 4.24x→4.50x（+6.1%） |
| GSM8K | 16 | 9.41 | 11.16 | +18.6% | 6.14x→6.60x（+7.5%） |
| HumanEval | 7 | 5.60 | 6.78 | +21.2% | 3.74x→4.27x（+14.3%） |
| MT-Bench | 7 | 3.82 | 5.07 | +32.5% | 2.48x→3.20x（+29.3%） |
| MT-Bench | 16 | 4.28 | 5.50 | +28.8% | 2.82x→3.25x（+15.1%） |
所有数据来自论文 Table 3，速度为 AR baseline 的相对提速；τ 为平均接受长度。
不难看出规律：对话类任务（MT-Bench）增益最大——因为聊天场景分布更散、分支的空间更大；数学任务相对集中，但也稳定 + 6~7%。9 个 benchmark × 3 个模型规模的完整表在论文 Table 8。
4.2 机制隔离：真条件 vs 假联动
论文 Table 4 做了个很干净的实验：把”父条件”换成 block 共享分布（shared-Markov tree，即所有分支共享同一套位置分布，只是把 top-k 铺开）。结果非常有层次：
- 裸 DSpark 链：τ=9.410；
- 共享分布树：τ=10.225——有点涨，但这是”把 marginal 铺开”的自然结果；
- PCTree 真父条件树：τ=11.156（再 +9.1%），每 sample 的 round 数从 24.7 降到 22.6；
- 对照组 DFlash+DDTree（并行分布硬铺树）：τ=7.485，垫底。
注意共享树和真条件树在树形状（都一样稠密）下的差距，说明分支能不能生钱，取决于条件质量：父依赖的真条件 > 共享 marginal 树 > 并行分布硬铺树。这也是对”给 DFlash 加个树就有用”这类朴素想法的直接泼冷水。
4.3 结构消融
- k（每父节点的分支数）：k=1（=DSpark）9.41 → k=2：10.85 → k=4：11.16 → k=8：11.14。即 k=4 就是甜点，再大没有新东西——节点预算 N 是硬约束；
- 节点预算 N：τ 随 N 单调涨，但端到端加速在 N=32（B=7）或 N=64（B=16）附近达峰——树太大，验证成本反超（论文 Figure 5）；
- 成本分解（Table 6，GSM8K B=16）：PCT 每 round 的 Markov+tree 时间从 DSpark 的 1.09ms 升到 5.24ms，但 round 数从 26.8 降到 22.6，净赚 7.5% 的 AR 加速——这是拿增量验证开销换 τ 的正常生意。
4.4 一图流：生存曲线
论文 Figure 4 画了”草稿深度上的存活概率”：DSpark 到深度 8 就掉到 57.1%，PCT 不但整体抬高，尾部（深度 12）还能留下 46.8%——树把”链断即血亏”变成了”此路不通，另辟歧路”。
5. 我的 Take
这篇和 DARTree 是同一个大潮里的两块拼图：投机解码的 DRF 之争告一段落，改动都收敛到”草稿内部怎么结构”了。 DARTree 给 diffusion drafter 装 AR 树，PCTree 给 DSpark 这个”半 AR 链”扩展成真条件树——两者都主打”零训练、不碰 backbone”，把提速算盘打在草稿阶段的确定性上。
个人觉得 PCTree 最值得学的是它的”破题角度”：Markov head 的父条件能力是 DSpark 自己就已经具备的，只是被单链用法封印了。推理优化的高杠杆工作，往往不是引入新能力，而是把已有能力的表达方式解开恢复——这和当年的 MTP、EAGLE 用最后一层 hidden state 是同一个道理。
要说局限，也是诚实的：增益集中在分支丰富的对话/代码任务，最利的数学题（GSM8K 类）稳定但幅度有限；树验证在长上下文服务端会吃掉部分收益（N 达峰后回落）。但作为”上生产之前最后一块拼图”，DSpark + PCTree 这个组合已经足够体面了。
如果这篇文章涉及的投机解码、LLM 推理优化你想系统深入，可以看看我之前推出的《动手学AutoML：从 NAS 到大语言模型优化实战》，书里有专门一章讲 LLM 推理效率和 KV Cache 优化，和本文的加速思路是同一套工程背景。
