如何做好网站宣传上海营销策划公司哪家好

如何做好网站宣传,上海营销策划公司哪家好,网络推广有,海外专线网络黄冈网站问题描述MindSpore 2.2.10Ascend 910环境#xff0c;同一份网络定义在GPU侧能完整跑通#xff0c;切到Ascend后端就卡在GraphCompile阶段#xff0c;日志只吐一行“BuildModel error 134”#xff0c;把MS_SUBMODULE_LOG_v调到DEBUG、export GLOG_v3、打开DUMP_GE_GRAPH、D…问题描述MindSpore 2.2.10Ascend 910环境同一份网络定义在GPU侧能完整跑通切到Ascend后端就卡在GraphCompile阶段日志只吐一行“BuildModel error 134”把MS_SUBMODULE_LOG_v调到DEBUG、export GLOG_v3、打开DUMP_GE_GRAPH、DUMP_OP_DEBUG文件夹里依旧只有空白json把动态shape全部改成固定640×640、关闭后处理Custom算子、把batch强制设1、把aipp配置删空、把insert_op.cfg里preprocess节点注释掉重新compile还是134用benchmark --model.om --dumpgraph.json对比隔壁工位能跑通的版本发现同样节点数同样dtype我的.om却小2.1MB怀疑某层融合被误杀可ge_optimizer.log里看不出pass名称把custom op的.so放到/usr/local/Ascend/lib64、在context里set_context(device_targetAscend, 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群记录只看到一句“134GE_GRAPH_OPTIMIZE_FAILED”没有定位办法现在已经连续三晚通宵眼睛通红咖啡续命如果哪位大佬曾经撞过同款error 134或者知道怎么把GE内部error code映射出来问题解答这个 134 折腾到这份上其实已经把绝大多数“表层配置问题”都排干净了日志级别开到 DEBUG、GLOG_v3、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_FAILED134 的笼统码再加上你对比了隔壁工位的 .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 或环境变量去禁用某类融合比如 ConvBNRelu 融合、特定 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 映射出来”目前公开渠道确实很有限134GE_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 拆代复杂 pattern3完全隔离 custom op确认 134 是否与自定义 kernel 有关4把可复现最小例子整理好提给官方让他们在 GE 内部做 error code 反查。至于你翻到的那句“134GE_GRAPH_OPTIMIZE_FAILED没有定位办法”严格说那只是“对纯外部用户没有现成映射表”但对掌握 GE 源码和内部日志的官方团队来说是可以从 134 再细分出具体原因的——这部分只能靠他们。