SpecExec 精读

核心定位

SpecExec 针对 target权重必须从 RAM/SSD搬到消费GPU的极端 I/O瓶颈：既然处理1 token和上千token的主要成本都是搬一次权重，就用小 draft搜索最可能的巨大 continuation tree，把它当 target probability cache；一次 target pass填满树，之后可以沿已缓存路径做多轮 sampling，直到走出树。

树构造把每个 prefix视为状态、延伸 token的边成本为负 log draft path probability；用并行 shortest-path/Dijkstra近似取全局概率最高的 B个 prefix，而非 K条固定beam。这样节点预算覆盖最高 q质量且共享 prefix。target tree forward后，每节点得到真实条件 p；generation从 target p采样，若下个 token有对应 child就继续使用缓存，否则触发新一轮，故输出来自 target而不是按 q接受，保持分布。

offload实验中预算可达1024/2048、每 target迭代最多约20 token；50B+模型消费设备4-bit约4–6 tok/s、16-bit约2–3 tok/s，某些A100 RAM-offload表约10–18× sequential。这里“massive tree”在常驻GPU会计算过量，论文自己用 forward input-size曲线说明最优预算由权重I/O与计算交点决定。

复现需要高效批量Dijkstra、tree mask、target层流式offload/量化、概率cache和miss处理；报告PCIe/RAM带宽、quantization、预算、cache hit/每轮生成量。局限包括 draft/target失配导致低coverage、巨大KV、prompt/output短时预热摊销差、仅适合低batch互动。它与Sequoia相同团队但更偏“硬件I/O换超大树”，不应作为普通GPU SD速度基线。

原文第 3–6 页硬件分析/算法，第 6–9 页树搜索实现，第 9–14 页概率覆盖/接受/速度，第 15–20 页补充。

概率缓存与系统实现

树中每个节点代表“到达该 prefix 后 target 对下一个 token 的分布”，所以缓存键至少包括祖先路径/节点标识，不能只按深度或末 token 复用。采样从根开始：从缓存的 target 分布抽样，若命中一条已物化 child 就移动到该 child 并继续；未命中时提交该 token、结束本轮并以新 prefix 重建树。由于每一步实际都直接取自 target 条件分布，proposal tree 只决定缓存覆盖率，这一点与接受—拒绝型 SD 的实现路径不同。

复现时应先测权重搬运一次的固定成本和随树节点增长的 attention/MLP 成本，预算最优点就是二者交叉附近。Dijkstra 队列需要批量弹出/扩展，路径概率用负 log 累加避免下溢；共享前缀后还要核对 tree mask、KV layout 和量化 scale。建议分别报告概率覆盖质量、一次 target pass 后的连续 cache hits、每轮实际产出 token、树构建 CPU/GPU 时间及峰值显存。若模型已完全常驻且 batch 较大，权重 I/O 假设不再成立，超大树很可能只是额外计算。