为什么值得读
编译器 bug 的特点是「不报错但算错」，静默污染数值与显存，事后极难归因。这篇的价值不在某个新算法，而在把「怎么找到它」工程化：fuzz 语料要有真实 trace、定位要能二分到算子粒度、修复要有人审。做训练/推理基础设施的人可以把这套流程当检查表用。
问题：优化越激进，正确性的余量越薄
现代基础模型的加速把领域专用编译器推向多层优化流水线。论文指出这类深优化带来的是性能与正确性之间的细致权衡：微小的 codegen 缺陷会引发数值劣化、内存或缓冲区损坏，从而让数百万美元级别的训练任务作废、让线上服务静默掉质，而编译器本身往往不抛明显错误。
这也是为什么「编译器正确性」很难靠单元测试兜住——出错的是算子融合、缓冲区复用这类组合路径，而不是单条指令。
方法一：fuzz 语料要同时有合成程序与生产 trace
论文把合成程序生成与真实生产 trace 结合作为 fuzz 输入。纯合成程序覆盖不了真实模型里的形状、dtype 与融合模式；纯生产 trace 又难以系统性地扰动边界条件。两者并用，才有可能在超大规模负载上稳定产出可复现的失败用例。
方法二：Agent 群做三件重复劳动，人做判断
论文用 Agent 群自主生成压力测试、复现失败、起草修复。这里的分工值得注意：三件事都是「有明确成功判据、但人力成本高」的环节，而 bug 是否真实、补丁是否可合入仍由人判断。摘要把这套做法定位为验证与分诊（verifying and triaging）方法论，而非自动修复系统。
方法三：层级差分，把整图二分到融合核里的单个算子
定位环节用一条层级差分流水线：对完整 workload 逐步二分，直到把问题收敛到融合核（fused kernel）内部某个具体失败算子。没有这一步，fuzz 只能告诉你「这个模型算错了」，无法告诉你是哪一段 lowering 出的错。
结果与边界
生产部署后，该框架已推动解决 142 个以上编译器 bug，另有 103 项发现处于待审状态，论文据此总结了若干工程经验。
需要说清楚的是：142 与 103 都是项目内部的生产计数，摘要没有给出分母——总 workload 数、总缺陷数、fuzz 的检出率与误报率均未披露，因此无法换算成召回率或精确率；Agent 起草的补丁被实际采纳的比例，摘要也未说明。这些数字说明流程在用、有效果，但不能用来横向比较不同编译器测试方案。
本站仅据 arXiv 摘要页（E1）整理，未复现。142 个已修 / 103 个待审为作者自述生产数字，缺少分母（总 workload 数、总缺陷数），无法计算检出率与误报率；Agent 群使用的模型、prompt 设计与人工复核比例摘要未披露；摘要页检索未发现代码或数据集链接，且该框架与 Google XLA:TPU 内部基础设施强绑定，外部团队难以照搬。
本文基于论文原文摘要与方法章节整理，观点由编辑撰写；如与原文有出入，以 arXiv 原文为准。 内容为信息整理与技术评论，不构成投资或决策建议。 发现错误请通过站内纠错页提交（记录可查），修订记录只增不删。