系列目录 · 算子与布局 · Read in English
“数值错了。”
“你怎么知道？”
“Dump 告诉我的。”
这是一个值得暂停的时刻。Dump 能显示字节，不能自动保证解释字节的规则正确。布局标签、shape、量化比例、写回位置、采样时刻，任何一项不匹配，都能把正确的计算包装成错误的结果。调试器不会故意说谎，但它也会带着默认值上班。
先确认观察布局
假设教学张量按 HWC 排列，形状为 [2,3,2]。为每个元素赋予可读标签：
1 | x[h,w,c] = 100*h + 10*w + c |
连续读取时，前几个值是 0,1,10,11,20,21。如果经过 Permute 变成 CHW，解释方式就换了。继续把结果标签写成 HWC，比较工具会用错误的坐标去找参考元素。数据没丢，标签却把每个人叫成了隔壁同事。
三种修法与布局传播
已核实的一个历史方案只识别特定三维置换：追过一层 Store，若看见某个已知方向的 Permute，就改成通道在前；否则仍使用默认布局。它改动小，容易针对眼前问题验证，也明确暴露了边界：它不是通用布局推导，未知路径仍被默认标签覆盖。把这个方案写成“彻底解决布局跟踪”会超出证据。
第二个方案改变采样范围，排除 Store，也继续排除 Permute。这样可以绕开某些有歧义的观察节点，减少重复输出。但没有采样结果与确认结果正确不是一回事。它可能让调试路径安静下来，却也失去了直接看到置换之后数据的机会。选择哪些节点插入 Dump，本身就是可观测性设计的一部分。
第三个方案更系统：允许采样 Permute，排除 Store，并尝试从 IR 传播布局。它引入布局锚点、保布局算子以及置换应用规则；推断不了就返回未知。历史里同一个问题出现三种方向，提醒我们不要把 Git 日志当成线性小说。作者可能在不同分支上试验不同取舍，提交时间先后并不能证明方案 B 必然替代方案 A。
通用布局推导可以这样想。先给边界或明确的计算算子一个已知轴序，再沿数据流传播。例如输入标签为 [H,W,C]，Permute 顺序为 [2,0,1]，则输出标签为：
1 | output_labels[i] = input_labels[permutation[i]] |
这里并不需要硬编码所有排列。需要的是验证 permutation 真的是排列：长度相同、每项是整数、索引在范围内、没有重复。若 [2,2,0] 混进来，简单取数组也能得到三个字母，但那个字符串不代表合法的轴变换。校验不能交给字符串长度。
为什么传播还要有“锚点”？因为任意 rank 为 3 的边界参数，未必足以判断三根轴分别是谁。某些算子在特定阶段约定输出布局，可以作为可靠起点；编译器生成且带有明确来源信息的置换，也可能提供受控兜底。历史较系统的方案对无法确定的三维边界保持未知，而不是看见三维就默认它是图像。
“未知”有时比“看起来合理”更有用。它把事实与猜测分开，使比较工具可以选择仅做原始字节检查、要求额外描述，或者暂停跨布局比较。如果未知被悄悄换成常见布局，错误就会跨过接口边界，最后变成某个算子的数值嫌疑。
保布局算子也不能随意泛化。逐元素运算在某些约定下可以沿特征输入传播轴语义，但二元广播时，左输入可能是标量或较小张量；选第一个输入不总是充分。Reshape 更不保证保留原有轴的语义，哪怕总元素数没变。历史实现有受限制的算子白名单与 rank 检查，应把它当作有限推导，而不是布局类型系统的完整替代。
检查还发现一个值得做代码审查练习的细节：某分支中出现了 Reshape 的额外判断，但前面的保布局白名单并没有包含它。这样的代码路径可能到不了预想的分支。这也说明，阅读判断条件时必须沿实际控制流走一遍，不能只看“写了一个 if”。
观察节点的契约与测试
Store 和 Dump 的关系也很微妙。Store 的输入可能在片上内存，输出可能在另一内存空间；二者逻辑值相同，地址与布局描述却不一定相同。如果 Dump 建描述符时偷偷追溯到 Store 输入，而生成元数据时仍看 Store 输出，就会发生数据来源与解释对象不一致。较完整的历史方案同时调整候选节点、数据源处理与元数据推断，说明问题跨越了多个模块。
设计一个观察节点，至少应保证这四件事一致：读哪个 value 的字节，用哪个 value 的 shape，采用哪个物理布局与 stride，用哪个量化编码解释。采样时刻还应在生产完成、缓冲区复用之前。
教学回归可以用两次逆向置换夹一个逐元素操作：
1 | 输入 -> Permute(P) -> 加零 -> Permute(P_inverse) -> 输出 |
对每个采样点检查数量、shape 和布局标签，再用坐标标签验证值。加零既保持结果，又能测试布局是否穿过中间算子传播。历史测试包含类似的置换链和元数据断言。建议补充未知边界、非法排列、保布局链断开、二元广播及重复采样的案例。
性能上，更多 Dump 会增加数据搬运、存储空间和同步开销，还可能改变原本的调度或内存复用。因此“开 Dump 以后问题消失”也是线索，不能立即认定修好了。可以分别检查纯元数据输出和实际张量搬运的影响；采样全部中间值适合定位，最终性能测量则要按明确的模式进行。本篇不给无测量支撑的开销比例。
坐标映射与未知布局
布局传播也可以从“字母串推理”升级为一个简单的组合练习。设第一次置换为 P，第二次为 Q，且约定输出轴 i 取输入轴 P[i]。连续两次之后，输出轴 i 对应原始轴 P[Q[i]]。如果比较工具采用相反的置换约定，两个系统即使都声称记录了同一个数组，含义也不同。因此测试不仅要记录排列，还应规定这个数组描述的是“输出取输入”还是“输入去输出”。
对于单位维，纯数值测试又会变得狡猾。交换两个长度为一的轴，字节序列可以完全不变，布局语义却已经改变；某些 shape 恰好具有相同维度时，连打印后的形状也看不出差别。教学标签最好同时包含不同的轴长度和依赖各轴的数值模式。历史测试形状的选择能验证特定链路，但要系统验证所有传播规则，还需要有意识地覆盖这些对称退化情况。
再问一个容易混淆的问题：layout 标签说明的是逻辑轴序，还是完整的物理存储方式？“HWC”通常只表达轴顺序，不一定包含行距、通道填充、块内交错和位打包。把它当作完整物理描述，比较工具仍可能错误地按紧凑数组读文件。更可靠的观察协议应明确导出的字节已经去除了物理填充，还是需要消费者根据额外 stride 描述解码。
有时两个 Dump 的值相同，反而值得怀疑。比如一个 Permute 与其前驱意外引用同一处尚未更新的缓冲区，比较器可能报告“置换不改变结果”，尤其在全一输入上毫无异常。可以用带坐标编码的张量，在操作前后选择几个对应位置手算；同时核查每个采样记录指向哪个 SSA value 和哪块内存。观察数据与观察描述要相互制约，不能让两者独立猜测。
未知布局应该如何呈现，也影响调试效率。合理的界面可以保留原始字节摘要、shape 和未知原因，避免直接做需要布局假设的数值比较；对于能确定一部分轴语义的情况，可以记录部分信息，但不应为了生成一个漂亮字符串而填满缺失项。历史方案选择完整未知作为保守返回，这比默认值更诚实，但更细的解释链属于后续设计空间。
最后，采样集合变化应反映到测试期望中。排除 Store 可能让数量减少，纳入 Permute 又可能让数量增加。如果消费者只按序号寻找“第几个张量”，图优化一变，序号可能对应另一个值。按稳定的值身份、可读来源及结构信息联合定位，比仅依赖顺序更稳健。
下次比较工具指出“某层第一个错误”，先别忙着审判那一层。问清楚那个“第一个”是按什么布局、什么量化方式、从什么地址读出来的。一个可信的观察者，能让你少调试很多其实没有错的代码。
If you like this blog or find it useful for you, you are welcome to comment on it. You are also welcome to share this blog, so that more people can participate in it. All the images used in the blog are my original works or AI works, if you want to take it,don't hesitate. Thank you !