美团把训练和推理的概率做到逐位相同：分歧藏在一个加法顺序里

一句话定位：这不是"模型变聪明了没有"，而是"同一份权重换个并行切分，输出会不会飘"——被测对象是训练与推理两条路径的结果是否逐位相同。同样的验证思路可迁移到量化模型上线、混合云部署、多卡扩缩容等任何"换了配置但权重没变"的场景。

摘要

美团在 11 月 2 日发布的 LongCat-2.5 技术博客里，花了一整节讲训推精度一致性：训练、Prefill、Decode 可以各自选择并行配置，同时保持逐 token logprob 逐位一致，并把这套方案当作"算子与框架迭代的统一数值回归基准"。这篇把这件事翻译成测试团队能执行的动作：数值回归该在什么粒度上比、哪些配置组合必须覆盖、4 比特量化上线前该拿什么当证据。

同一份权重，同一个请求，同一个温度参数。你把张量并行的切分从 4 路改成 8 路，输出变了。不是那种一眼能看出的错乱，而是第三句开始措辞偏移，某个数值答案从 12.34 变成 12.35。

这类问题几乎不可能靠人工 review 发现，靠端到端用例也极难稳定复现，因为每次变化的幅度都在"看起来还算对"的范围内。但它会让一件基本的事失效：你无法判断线上那次质量下降，是因为模型换了，还是因为部署配置换了。

美团在 2026 年 11 月 2 日的 LongCat-2.5 技术博客里，专门用一节讲这个问题，标题是"训推精度一致性"。原文的核心表述是：构建了生产级训推一致性方案，使训练、Prefill 和 Decode 可独立选择并行配置，在性能接近无损的同时，保持逐 token logprob 的 bitwise 一致。

这篇要拆的就是这句话里的四个技术承诺，以及测试团队该用什么证据去接住它们。

为什么会不一致：不是精度不够，是加法顺序换了

先把机制说清楚，后面的验收才知道往哪打。

神经网络里大量的运算是求和：注意力里的加权、归一化前的累加、专家层的合并。浮点加法不满足结合律——(a+b)+c 和 a+(b+c) 在数学上相等，在浮点表示里可能差最后几位。当你把一次求和拆到不同的卡上分段计算再合并，分段边界一变，加法的结合顺序就变了，最低位就开始漂。

张量并行（TP）是最典型的场景：原先把某一维完整地算完再求和，切分之后每张卡各算一段，最后做一次跨卡归约。原文对修复方式的描述是：以完整 K 维计算替代分段求和，训练侧保留权重分片，通过权重 All-Gather 和输入 AlltoAll 独立完成完整 K 维 GEMM，无需对局部结果做 Reduce-Scatter 求和。

换句话说，不是"提高精度"，而是改变计算的组织方式，让不同切分下的加法顺序一致。这句话对测试的含义很直接：你要验的不是"误差在容忍范围内"，而是"结果逐位相同"。两者的验收标准差一个量级。

原文还提到另一条路径：DCP（解码上下文并行）。做法是在训练与 Prefill 中复现 Decode 的累加路径，接入配套的 sparse attention 算子，复现指定 DCP 配置下 Decode 的 KV 分块与归约顺序。

这句话里有个值得单独拎出来的思路：不是让三者各自更准，而是让三者对齐到同一个累加路径。 这跟很多团队的做法相反——我们习惯给每个环节设一个容差，然后比较谁偏得少。官方这套是把 Decode 当成基准，让训练和 Prefill 去模仿它。

逐 token logprob 一致，这句话怎么变成用例

原文的表述是"保持逐 token logprob 的 bitwise 一致"。这句话在测试上非常友好，因为它给出了明确的比较对象和明确的判定标准。

比较对象是逐 token 的 logprob 序列，不是最终文本。这很重要：最终文本在采样之后才产生，中间隔了一步随机数；logprob 是采样前的分布，是确定性的。拿文本比对，会把采样随机性混进数值比对里，结论不成立。

判定标准是 bitwise，不是容差。这也不难做到：把两边的 logprob 序列按 float32 或 float64 的位模式直接比较，而不是先算差值再看是否小于 epsilon。差值比较会放过"差别很小但确实不同"的情况，而这一类恰恰是累积漂移的起点。

我建议的用例结构是这样：

• 构造一组固定输入，覆盖长上下文（原文提到中训练阶段采用最长达 1M token 的序列）、多轮对话、含图像的多模态输入三类；
• 对每组输入，在两个不同的并行配置下各跑一次，关闭采样（温度 0 或直接取 logits）；
• 导出逐 token logprob，逐位比较；
• 任何一位不同，定位到具体 token 位置和具体层，再判断是哪个算子的归约路径没对齐。

第四条是这套方法真正的成本所在。逐位比较只能告诉你"第 137 个 token 不一致"，不会告诉你为什么。要定位到算子，需要能按层导出中间值，这要求部署侧留出调试通道。多数团队在这一步卡住，不是不想测，是拿不到中间值。

三个必须覆盖的配置组合，和一个容易被漏掉的

原文提到 TP 和 DCP 两条路径都做了扩展支持。从测试覆盖的角度，我建议至少跑这三组：

第一组，训练与推理整体对齐。这是最基础的一组，验证"训出来的东西能被推出来"。

第二组，Prefill 与 Decode 之间对齐。原文提到 Decode 把 o_proj/fc2 改为 column-parallel，通过输入 All-Gather、完整 K 维 GEMM 和输出 AlltoAll 完成计算。这种"两段用不同并行策略"的设计，天然存在对齐风险——预填充阶段和逐 token 解码阶段的算子组合不同，数值路径必须被证明一致。

第三组，同一阶段内换并行度。4 路换成 8 路，8 路换成 16 路，逐位是否仍然相同。这一组最容易被漏掉，因为团队通常在扩缩容时才改并行度，而这恰好发生在流量高峰，没人有空跑数值回归。

还有一组我建议加进去，虽然官方没有明确提到：跨硬件对齐。同构环境下逐位一致，不代表异构环境下也一致。国产加速器与通用 GPU 的归约顺序、指令融合策略都不同，如果生产环境是混合部署，这一组必须单独跑。

4 比特量化，先看它怎么给证据

原文还有一节讲 W4A4 推理：把专家权重和激活同时量化到 4 bit，通过原生 INT4 矩阵乘法单元执行，精度上以 FlatQuant 的可学习等价变换为基础并针对 MoE 优化，官方称在已评测的各项下游任务上保持与量化前相当的表现。

"相当"这个词在验收上是不够的。量化必然会引入误差，问题在于误差落在哪里、有多大、会不会被下游放大。所以量化上线前的验收，我建议按三步走：

第一步，先验数值回归。量化后的模型在固定输入集上的输出，与量化前相比偏移了多少，按任务类型分开统计，而不是给一个总平均。原文提到的下游任务评测就是这一步的官方版本，但它是自报的，测试团队应该在自己的任务上重跑。

第二步，验敏感任务。同一批输入，在"答案唯一"的任务（数值计算、结构化抽取、分类）和"答案开放"的任务（文本生成、建议）上分别看偏移。前者偏移超过阈值就是阻断，后者可以放宽。

第三步，验长尾输入。这一点原文没有展开，但很重要：量化误差在短输入、高频模板上通常很小，在超长输入、罕见字符、多模态混合输入上会被放大。原文提到长上下文是其重点优化方向，测试团队应该把长输入单独拉出来做一组。

顺便说一句线上压测的数字。原文给出：相对 W8A8 INT8 基线，Prefill 和 Decode 吞吐分别提升 43.3% 和 42.77%，TTFT 和 TPOT 分别降低 15.91% 和 19.72%。这些是"线上压测"口径下的性能数据，跟质量无关，不能用来证明量化没有代价。把它们和质量指标混在一张表里汇报，是很容易犯的错。

长序列训练里的那个 86%，跟质量无关但影响你的排期

原文还提到长上下文 SFT 的单卡吞吐较 DDP 基线提升 86%，并把这个数字用"相当于一张卡完成原来约 1.86 张卡的工作量"来解释。技术博客的口径里，这是训练侧的指标。

我把它放进来，是因为它会直接影响测试排期。当训练吞吐接近翻倍，模型迭代频率就会上升，同一套评测集在同样的日历时间里要跑更多轮。如果评测流水线是按旧节奏设计的（比如每晚跑一次全量），它很快会成为瓶颈，然后团队就会开始跳跑、抽样跑，评估结论的可比性随之下降。

所以训推一致性这类数值回归，从第一天就该设计成"增量可跑"的：每次迭代只跑受影响算子相关的比对集，全量比对按周跑。原文把这套方案形容为"为算子与框架迭代提供统一的数值回归基准"，这句话的潜台词就是它会高频运行，所以必须先解决运行成本。

本文部分内容参考了霍格沃兹测试开发学社整理的相关技术资料，主要涉及软件测试、自动化测试、测试开发及 AI 测试等内容，侧重测试实践、工具应用与工程经验整理。