问题描述
MindSpore 2.2.10+Ascend 910环境，同一份网络定义在GPU侧能完整跑通，切到Ascend后端就卡在GraphCompile阶段，日志只吐一行“BuildModel error 134”，把MS_SUBMODULE_LOG_v调到DEBUG、export GLOG_v=3、打开DUMP_GE_GRAPH、DUMP_OP_DEBUG，文件夹里依旧只有空白json；把动态shape全部改成固定640×640、关闭后处理Custom算子、把batch强制设1、把aipp配置删空、把insert_op.cfg里preprocess节点注释掉，重新compile还是134；用benchmark --model=.om --dump=graph.json对比隔壁工位能跑通的版本，发现同样节点数同样dtype，我的.om却小2.1MB，怀疑某层融合被误杀，可ge_optimizer.log里看不出pass名称；把custom op的.so放到/usr/local/Ascend/lib64、在context里set_context(device_target="Ascend", plugin_path="./lib")、ldd确认符号全绿、nm -D又能看到自定义kernel函数，134依旧阴魂不散；试过回退CANN 5.1.RC3→5.0.4、回退Driver 23.0→22.0.2、把opp包整包替换、把mindspore昇升包降级到2.1.1，现象完全一致；甚至把整台机器重刷Ubuntu 20.04.5，只装官方一键包，134照旧；翻完官方issue、gitee、知乎、CSDN、QQ群记录，只看到一句“134=GE_GRAPH_OPTIMIZE_FAILED”，没有定位办法；现在已经连续三晚通宵，眼睛通红，咖啡续命，如果哪位大佬曾经撞过同款error 134或者知道怎么把GE内部error code映射出来？
问题解答
这个 134 折腾到这份上，其实已经把绝大多数“表层配置问题”都排干净了：日志级别开到 DEBUG、GLOG_v=3、DUMP_GE_GRAPH / DUMP_OP_DEBUG 打开、动态 shape 改成固定 640×640、batch 拉到 1、关掉自定义后处理、删 aipp、注释 insert_op.cfg 的 preprocess、跨版本回退 CANN/Driver/MindSpore，甚至重装系统，说明这既不是简单的环境残留，也不是典型的 shape 推导失败，更像是 GE 在某个特定子图或 FusionPass 上直接掉进“内部未捕获异常”，然后对外只给了一个 GE_GRAPH_OPTIMIZE_FAILED=134 的笼统码；再加上你对比了隔壁工位的 .om，节点数和 dtype 一样但你的小 2.1MB，很大概率是“某个 Fusion 或图变换在你这边多走了一步/少走了一步，生成了一个 GE 自己也搞不定的 IR”，结果在 BuildModel 内部直接崩掉，而现有日志体系又没把具体 pass 名称打出来。就现状而言，想完全靠外部黑盒排查 134 几乎是不现实的，你已经把能动的开关都摁了一遍，接下来只能走两条路：一条是工程上“逼 GE 摊牌”，也就是强制弱化/分割图优化，让出问题的那一小块图暴露出来；另一条是“走官方后门”，想办法把 GE 内部堆栈和错误信息拿出来。第一条路的思路大致是：尽可能缩小出问题的子图范围，同时限制某些优化 pass 参与。你已经验证“整个网络换后端就挂”，但其实可以做二分：从最小可复现子网开始，比如只保留 backbone 前几层，看是否能 compile，如果能，逐段往后加 block；一旦某一段一加就 134，那基本可以锁定是那几层里有算子组合/shape/pattern 触发了 GE 的 bug。因为你在 GPU 上是完全能跑的，所以这里不是语义问题，而是“某种 pattern + Ascend 编译器版本”的组合。第二，MindSpore 侧可以尝试关掉部分图优化/算子融合，例如使用 `jit_config` 或环境变量去禁用某类融合（比如 Conv+BN+Relu 融合、特定 layout 转换 pass），或者在图构建时拆成多个子图（如将某些复杂分支或自定义算子前后用 `stop_gradient`/`ms_function` 包一层，或者用 CellList 的方式强行打断连续模式），让 GE 不再对整网做一次“地毯式”优化；经验上很多 134 都是因为一个特定的融合 pass 在复杂控制流或多分支下出错，切断那条融合路径后可以直接绕掉 bug。第三，既然你已经有一个“隔壁工位能正常跑通的 .om”，那可以反向对齐：完全拷贝那边的 CANN/MindSpore 版本和 OPP 包，连到你的 910 上试跑，看看是“整机环境差异”还是“网络定义/导出逻辑差异”；如果同一个训练脚本在那边导出的 .om 拿来你这边也能跑，那说明你本地的导出链路（from MindSpore graph 到 OM）在某个地方被不同的环境/选项影响了；反过来，如果那边导出的 .om 到你这里也 134，那问题更靠近 runtime 或某个特定硬件版本。对于你提到的“custom op 的 .so 放在 /usr/local/Ascend/lib64 + plugin_path + nm/ldd 全绿但仍 134”，这里一个经常被忽略的点是：很多时候 134 在 custom op 环节不是“符号找不到”，而是 GE 在做 shape/type infer 或 graph partition 时，对你的 op attr/schema 理解出错（比如 attr 描述和实际 kernel 接口不一致、kernel 注册信息里某个 dtype/format 组合不支持），导致它在内部的 KernelSelection / ImplMode 决策中掉坑；这类错误不会在 ldd/nm 层面暴露出来，而只会在 GE 优化时“走到这一步才崩”，所以可以尝试极端一点：完全注释掉 custom op 在网络中的调用（不仅是后处理），用等价的纯 Python/MindSpore 实现或者临时 dummy op 替代，看看 134 是否还在，如果没了，就能确定是 custom op 的 schema/注册或与某 pass 的交互导致的。至于“怎么把 GE 内部 error code 映射出来”，目前公开渠道确实很有限，`134=GE_GRAPH_OPTIMIZE_FAILED` 之外，细粒度的子错误基本都在 GE 的内部日志和调试符号里，外部文档不会给；这时最实际的办法就是准备一个最小复现工程（删到只剩 1–2 个可疑 block 的网络定义 + 固定输入 + 编译脚本），打包你当前的 CANN/MindSpore 版本号、`ge_optimizer.log`、`ms_compile.json`、环境变量列表，直接往官方工单 / Gitee issue/企业技术支持提，说明“同网络在 GPU / 隔壁环境 OK，在本环境稳定复现 134”，官方工程师可以在内部打开 GE 的更高等级日志和符号表，把具体挂在了哪个 pass、哪个算子、哪个 shape 上查出来——说实话，到你已经三晚通宵、系统都重刷过这个程度，再继续靠猜测开关只是在消耗身体。综合起来，你现阶段可以做的、相对有产出的动作是：1）用二分/缩网的方式定位触发 134 的最小子图；2）尝试在 MindSpore/GE 侧禁用部分融合/优化 pass 或改写该子图的结构（比如用更“朴素”的 Conv/BN/Activation 拆代复杂 pattern）；3）完全隔离 custom op，确认 134 是否与自定义 kernel 有关；4）把可复现最小例子整理好提给官方，让他们在 GE 内部做 error code 反查。至于你翻到的那句“134=GE_GRAPH_OPTIMIZE_FAILED，没有定位办法”，严格说那只是“对纯外部用户没有现成映射表”，但对掌握 GE 源码和内部日志的官方团队来说，是可以从 134 再细分出具体原因的——这部分只能靠他们。
