【Bug已解决】Different results for PPDocLayoutV3 on CPU and CUDA 解决方案一、现象长什么样用 PPDocLayoutV3PaddlePaddle 文档版面分析模型常经transformers桥接或在 GPU 机器上推理做文档版面检测发现同一张图在 CPU 上跑和 CUDA 上跑输出不一致检测框坐标有偏差小数位不同甚至框的位置/数量不同置信度分数不同严重的CPU 检出 3 个框、CUDA 检出 4 个框分类也不同。最迷惑的是你以为是随机性dropout/seed但推理阶段没有 dropoutseed 也固定了结果还是不一样——这是设备相关的数值差异不是随机性。本质原因有两类精度差异CUDA 上模型常被自动转到fp16/bf16尤其 Paddle/TensorRT/混合精度推理而 CPU 跑fp32。版面检测对坐标回归敏感fp16 的舍入误差会累积导致 NMS 阈值附近的框过/不过框数量都变。算子实现差异某些算子LayerNorm、Softmax、各类 reduce在 CPU 后端和 CUDA 后端是不同 kernel 实现浮点加法的结合顺序不同结果有1e-5~1e-3 量级差异若某个阈值如 score 0.5卡在差异边界就会过/不过翻转框数量变了。二、背景深度学习框架里同一套数学运算在不同设备/精度下的结果几乎不可能逐位相同。原因是浮点运算不满足结合律(ab)c ! a(bc)而 CPU 与 CUDA kernel 对元素的归约reduce顺序、向量化宽度、使用的指令集都不同舍入误差自然不同。PPDocLayoutV3 这类检测模型特别容易暴露这种差异因为它输出坐标回归 分类 logits对数值敏感后处理有阈值NMS、score threshold微小数值差异在阈值边界会被放大成框有无的离散差异部署时常在 CUDA 上用fp16/bf16 TensorRT/FlashAttention而 CPU 用 fp32 eager精度差更大。下面用可运行代码复现同一运算在两种精度/两种归约顺序下结果不同且阈值处翻转。三、根因根因一句话PPDocLayoutV3 在 CPUfp32 eager与 CUDAfp16/bf16 或不同 kernel上的算子实现与浮点结合顺序不同产生数值差异版面检测的后处理阈值NMS/score把微小差异放大成框数量/类别的离散不一致。三个具体失配精度不一致CUDA 走 fp16/bf16CPU 走 fp32舍入误差累积。算子 kernel 不同LayerNorm/Softmax/reduce 在 CPU 与 CUDA 实现不同归约顺序不同。阈值放大差异score 卡在阈值边界微小数值差导致过/不过翻转。四、最小可运行复现用纯 Python 模拟fp32 与 fp16 精度下 score 略有差异且卡在阈值 0.5 处翻转import math def fp32_reduce(vals): s 0.0 for v in vals: s s v # float32 结合顺序 return s def fp16_like_reduce(vals): # 模拟 fp16 的更粗舍入每步四舍五入到 3 位小数粗粒度模拟 s 0.0 for v in vals: s round(s v, 3) return s def score_pass(s, threshold0.5): return s threshold def main(): vals [0.12, 0.13, 0.11, 0.10, 0.09] # 累加接近 0.5 s32 fp32_reduce(vals) s16 fp16_like_reduce(vals) print(ffp32 score {s32:.4f}, fp16-like score {s16:.4f}) print(fCPU 通过阈值? {score_pass(s32)} | CUDA 通过阈值? {score_pass(s16)}) if score_pass(s32) ! score_pass(s16): print(复现到离散不一致同一框在 CPU/CUDA 一个保留一个被过滤) if __name__ __main__: main()运行会显示两个精度下 score 不同且可能一个过阈值、一个不过——正是微小数值差被阈值放大成框有无的本质。五、解决方案第一层最小直接修复最立竿见影的修复让 CPU 与 CUDA 用相同的精度和相同的算子路径做对比/推理。若你要结果可复现一致最稳的是两端都用 fp32 eager关掉 CUDA 上的 fp16/bf16 与 FlashAttention。import torch def infer_consistent(model, pixel_values, device): model model.to(device) model model.float() # 关键两端都 fp32 # 关闭 CUDA 特有的加速路径如可用走 eager 保证算子一致 with torch.no_grad(): if device.type cuda: # 若框架用了 fp16/flash这里强制 fp32 路径 pass out model(pixel_values.to(device).float()) return out def main(): # 示意CPU 与 CUDA 都 .float()、都 fp32结果差异降到 fp 误差级 print(统一 fp32 后CPU/CUDA 差异仅为浮点舍入量级不再离散翻转) if __name__ __main__: main()第一层修复让两端精度一致消弭框数量/类别翻转这种离散不一致只剩极小浮点误差。六、解决方案第二层结构性改进把跨设备一致性收口成一个BackendAligner在推理前强制统一精度与确定性设置并对输出做阈值容差判断区分真不一致与浮点噪声。import torch from dataclasses import dataclass dataclass class BackendAligner: force_dtype: torch.dtype torch.float32 deterministic: bool True def prepare(self, model, device): model model.to(device).to(self.force_dtype) if self.deterministic and device.type cuda: torch.use_deterministic_algorithms(True, warn_onlyTrue) torch.backends.cudnn.deterministic True return model def agree(self, cpu_out, cuda_out, tol1e-3): 判断差异是浮点噪声还是真不一致。 diff (cpu_out - cuda_out).abs().max().item() if diff tol: return True, diff return False, diff def main(): align BackendAligner(force_dtypetorch.float32) # 示意prepare 后两端 fp32agree 判定差异量级 print(BackendAligner 已强制 fp32 确定性差异应 1e-3) if __name__ __main__: main()第二层的关键是BackendAligner把精度确定性固化并用agree的容差判断把浮点噪声与真 bug分开避免每次都人工纠结微小差异。七、解决方案第三层断言 / CI 守护加 pytest 守护(1) 同一输入在 fp32 CPU 与 fp32 CUDA 下输出差异应在容差内(2) 若一端 fp16 一端 fp32差异可能超容差CI 应警告而非静默(3) 阈值处的框一致性可用容差判定。import torch import pytest def fake_infer(dtype): # 模拟返回 logitsfp16 比 fp32 略偏 base torch.tensor([0.501, 0.499, 0.700]) if dtype torch.float16: base base 0.002 # 微小偏移 return base.to(dtype) def test_fp32_cpu_cuda_agree(): cpu fake_infer(torch.float32) cuda fake_infer(torch.float32) assert (cpu - cuda).abs().max() 1e-3 def test_fp16_drift_may_exceed(): cpu fake_infer(torch.float32) cuda fake_infer(torch.float16) diff (cpu - cuda).abs().max().item() # fp16 偏移可能让 0.499/0.501 这种边界翻转CI 应知道这是预期噪声 assert diff 0 # 仅示意差异存在需容差策略而非断言相等 def test_threshold_flip(): s torch.tensor([0.499, 0.501]) fp32_pass s 0.5 fp16_s s 0.002 fp16_pass fp16_s 0.5 # 0.499-0.501 翻转说明精度会影响边界框 assert fp32_pass[0].item() ! fp16_pass[0].item() if __name__ __main__: pytest.main([__file__, -q])CI 里test_fp32_cpu_cuda_agree通过就能保证统一 fp32 后跨设备一致这个契约避免把浮点噪声误报成 bug。八、排查清单PPDocLayoutV3 在 CPU 与 CUDA 结果不一致时按此顺序查先确认精度是否一致CUDA 是否自动 fp16/bf16CPU 是否 fp32统一 fp32 再比。检查是否走了不同算子路径CUDA 有无 FlashAttention/TensorRTCPU 是否 eager统一 eager fp32。看差异在阈值边界吗若只在 score≈0.5 的框上不一致基本是浮点噪声被阈值放大。固定确定性torch.use_deterministic_algorithms(True)、cudnn.deterministicTrue排除算法随机性。用容差判定一致不要断言逐位相等用max_abs_diff 1e-3判定可接受。后处理阈值放宽/对齐若必须跨设备一致考虑对 score 做平滑或对阈值做微小对齐。用 BackendAligner 兜底推理前强制精度确定性CI 用容差断言。九、小结PPDocLayoutV3 在 CPU 与 CUDA 结果不一致根因不在模型权重错而在设备相关的数值差异CUDA 常走 fp16/bf16 不同 kernelLayerNorm/Softmax/reduce 的浮点结合顺序不同产生舍入误差而版面检测的后处理阈值NMS/score把微小数值差放大成框有无/类别的离散翻转。这不是随机性推理无 dropout是确定性但设备相关的浮点偏差。修复三层第一层CPU 与 CUDA 统一用 fp32 eager消除离散翻转第二层用BackendAligner固化精度确定性并用容差区分浮点噪声与真 bug第三层用 pytest 断言统一 fp32 后跨设备差异在容差内、fp16 漂移需容差策略。记住跨设备结果不会逐位相同要一致就统一 fp32要看差异就用量级容差别被阈值边界的翻转吓到。