精度定位

结果是错的，不是慢。本章讲的是怀疑对象的排查顺序。

前置：执行 —— 编译、运行，以及本章要打开的那些 RunConfig 字段。另外还有教程 —— 具体说是 第一个算子 里那个 allclose 对比，本章假定你已经有了。

本章是什么

不是「某个 API 怎么用」，而是一套缩小范围的流程：五个步骤，排序原则是让花几分钟的那两步排在花几小时的那两步之前。

多数报上来的问题止步于第 2 步，因为「结果不对」里有很大一部分要么是容差设错，要么是本来就该有的差异。

目录

页面	覆盖内容
缩小精度差距	五个步骤、工具，以及「可接受差异」表
实例	流程的端到端应用

它的形状

1. golden 本身对吗？        ← 几分钟
2. 本来就该有差异吗？       ← 几分钟
3. 编译器警告过吗？         ← 几分钟
4. 是哪个 pass 引入的？     ← 几小时
5. 是哪个张量错了？         ← 几小时

前三步既便宜又能直接排除。 一个正确的 FP16 kernel 会在 1e-5 的容差下失败；split-K 按设计就会重排累加顺序。两者都不是 bug，而从外面看两者都长得跟 bug 一模一样。

最要紧的那个区分

有两种失效模式，它们需要不同的工具：

失效模式	症状	定位工具
语义	IR 本身就算错了	torch_codegen + validate_ir，二分各 pass（第 4 步）
数据	每个 pass 的 IR 都对，设备结果不对	张量 dump（第 5 步）

第 4 步是在主机上运行 IR 的含义，完全不涉及设备。如果它在每个 pass 都吻合，那这个 bug 就不是语义性的，再怎么读 IR 也找不到 —— 直接去第 5 步。这一个分叉能省掉大多数人在这里损失的时间。

参见

• 性能优化 —— 姊妹闭环，用于慢而不是错。
• LegalizeTileCast —— cast 链何时精确、何时不精确。
• 规约与 softmax —— 规约中的 padding，一个高频的静默错误来源。