MTP 与投机解码：接受率、每步产出和加速收益的区别

问题起点与证据

来自北京时间 2026-09-18 15:08、17 时段的追问：MTP 是什么，和投机解码有什么关系，rank 指什么，45% 接受率是否正常？

用户提供的日志摘要：rank0 接受 12,726 / 草拟 28,302，约 45.0%，平均接受长度 2.33；rank1 为 11,428 / 27,435，约 41.7%，长度 2.24。位置接受率分别为 76.6%/42.2%/16.2% 与 74.0%/37.5%/13.4%。这些是当次摘要，不是所有模型或工作负载的常数。

从机制到指标

投机解码是一类先提出候选 token、再由目标模型验证的执行方法。MTP 是多 token 预测机制，可以作为候选生成方式；二者不能当作完全同义词。推理实现还涉及候选构造、验证与拒绝后的处理。具体支持组合按模型和后端版本核对。vLLM 投机解码文档（核查 2026-09-20）

接受率 = 被接受的候选 token 数 / 提出的候选 token 数。每轮实际输出长度还可能包括目标模型额外产生的 token，故不能直接将 45% 当作“只输出了45%的文本”。

教学算例：若每轮固定草拟3个 token，接受比例为0.45，且每轮另有1个目标 token，则平均输出约为 1 + 3×0.45 = 2.35。日志2.33接近这一量级，但草拟长度变化、计数定义及统计窗口不同都会造成差异；这不是对底层计数实现的证明。

接受率不是加速比

一个有用的成本模型：投机每轮耗时 = 草拟成本 + 目标验证成本 + 调度/通信成本；平均每 token 成本 = 每轮耗时 / 每轮实际输出数。与无投机的同负载基线比较，才得到收益。高接受率仍可能被额外计算抵消。

各位置越往后接受率下降符合前缀连续验证的直觉，但两个 rank 数值接近只能排除明显的单侧失衡线索，不能证明输出正确、MTP 无缺陷或缓存路径正常。

rank 是进程/通信组编号，必须看日志前缀和组定义。不能仅凭 rank0/1 就断言它们分别代表两张物理卡；DP2×TP8 下可能看到两个 DP 组级汇总。

实验方法与知识联系

同一模型权重、prompt、采样、并发下分别关闭/开启投机，记录 TTFT、TPOT、吞吐、接受 token 总数及轮数。先验证输出质量与缓存正确性，再优化吞吐。

9月18日另一份 random 性能日志的接受率约1%，与这里约42%–45%的摘要不是同一工作负载，不应合并求平均。人工自然语言、随机 token、上下文长度与设置差异均需记录。

如果出现“2+2读到1+1”一类输入/缓存串扰，优先保留最小复现并检查缓存键和请求隔离；此前助手将其归因为 prefix cache 的说法仍需原始复现实验支撑。