1. ATC 转换卡住不动到底卡在哪从日志定位 CANN 模型转换慢的排查思路模型转换这件事最让人抓狂的不是报错而是它既不报错也不结束。你敲下 atc 命令终端光标停在那里十分钟、半小时过去日志文件大小纹丝不动CPU 占用却可能飙到满核。这种「假死」状态在 CANN 生态里其实有迹可循只是很多人第一反应是重装环境或者换机器反而把真正的问题掩盖了。ATCAscend Tensor Compiler做的事情是把 TensorFlow、ONNX、Caffe 这些框架的模型翻译成昇腾硬件能执行的 om 离线模型。这个翻译过程分好几个阶段图解析、算子融合、算子编译、内存分配、序列化。任何一个阶段资源不够或者依赖缺失都会表现为「卡住」。所以排查的核心不是猜而是让 ATC 把每个阶段的信息吐出来看它到底停在哪一步。这篇文章适合两类人一类是在 Atlas 200I DK A2 这类开发者套件上跑转换、被内存问题坑过的另一类是在服务器上转换大模型发现耗时从几分钟变成几小时、想搞清楚瓶颈在哪的。我会从日志、算子编译、环境依赖三个角度拆解给出可以直接复制的 ATC 命令参数以及每一步怎么验证卡点位置。你不需要一开始就理解 CANN 的全部架构跟着步骤走能判断出「是内存问题、是算子编译问题、还是环境变量没配对」就够了。先说一个判断原则ATC 卡住时先别急着 CtrlC。用top或者htop看进程状态。如果 atc 进程的 CPU 占用接近 0说明它在等 IO 或者等锁大概率是内存不足触发了 swap 抖动或者某个算子编译进程僵死如果 CPU 占用很高但日志不更新说明它在做算子编译只是并行度设置不合理导致单个算子编译时间过长。这两种情况的处理方式完全不同所以第一步永远是「看进程在干什么」而不是盲目调参。另外提醒一点ATC 的日志默认输出到终端但信息量有限。真正有用的阶段信息需要打开日志级别。很多人不知道 ATC 支持--log参数指定日志目录配合环境变量可以输出 DEBUG 级别的详细日志。这个后面会给出具体配置。先把「看进程 开日志」这两件事做了再谈优化顺序不能反。2. 用 TaoToken 准备排查环境与模型转换辅助链路排查 ATC 卡住这件事本身是本地环境问题但排查过程中经常需要查文档、比对算子支持列表、甚至让模型帮忙解读一段晦涩的日志。这时候一个稳定的模型调用入口能省不少事。我平时用 TaoToken 来做这类辅助工作它的官网是 https://taotoken.net/?utm_sourcetaotoken_aicg_blog_endutm_mediumcsdnutm_campaignrewriteutm_content API 地址是 https://taotoken.net/api 不额外加参数。为什么排查 ATC 会用到模型对话举个实际场景ATC 报了一个算子不支持的错误错误信息里只有算子名和数据类型比如Unsupported op type: SomeCustomOp, dtype: float16。你需要快速判断这个算子是 CANN 版本不支持还是需要配置自定义算子插件。把错误信息丢给模型让它结合 CANN 的算子约束给个方向比翻半天文档快。这时候走模型对话入口就行https://taotoken.net/models?utm_sourcetaotoken_aicg_blog_endutm_contentmodel_chatutm_campaignrewrite 。如果你是在做长期的模型转换和部署工作比如要反复转换不同版本的模型、维护一套转换脚本那用 Coding Plan 会更顺手入口在 https://taotoken.net/coding-plan?utm_sourcetaotoken_aicg_blog_endutm_contentcoding_planutm_campaignrewrite 。它适合把「转换命令生成、日志分析、参数调优」这些动作串成工作流。需要先拿到 API Key 才能调用。进控制台创建https://taotoken.net/console?utm_sourcetaotoken_aicg_blog_endutm_contentconsoleutm_campaignrewrite 然后在 API Keys 页面生成https://taotoken.net/api-keys?utm_sourcetaotoken_aicg_blog_endutm_contentapi_keysutm_campaignrewrite 。接入文档在 https://taotoken.net/doc?utm_sourcetaotoken_aicg_blog_endutm_contentdocutm_campaignrewrite 里面有各语言的调用示例。这里要强调TaoToken 是辅助排查和文档解读的工具不是替代 ATC 本身。ATC 的转换必须在本地 CANN 环境里跑模型对话只是帮你更快理解报错、生成排查命令。两者分工要清楚别指望用模型调用去「远程转换模型」那不现实。配置上如果你用 Claude Code 这类工具来辅助写转换脚本需要填三件套Base URL 填https://taotoken.net/apiKey 填你生成的 API KeyModel ID 按文档里列出的可用模型填。这三项缺一不可尤其是 Base URL 末尾不要多加斜杠否则会出现 404。我试过在 settings.json 里把 Base URL 写成带斜杠的形式结果请求一直失败排查了半天才发现是路径拼接问题。对于纯命令行排查场景你也可以直接用 curl 调 API 来问问题比如把 ATC 日志片段作为 prompt 发过去。这种方式适合脚本化但要注意日志里可能包含模型路径等敏感信息发之前自己脱敏。总之TaoToken 在这个场景里的定位是「加速你理解问题」而不是「替你解决问题」心态摆正用起来才顺。3. 可复制的 ATC 转换命令与参数配置定位慢转换的完整操作这一节是核心给出可以直接复制运行的 ATC 命令以及每一步怎么验证。先给一个「带完整日志和资源限制」的基础命令模板再逐项解释参数。export ASCEND_GLOBAL_LOG_LEVEL1 export ASCEND_SLOG_PRINT_TO_STDOUT1 export TE_PARALLEL_COMPILER1 export MAX_COMPILE_CORE_NUMBER1 atc --model./model.onnx \ --framework5 \ --output./model_out \ --input_formatNCHW \ --input_shapeinput:1,3,224,224 \ --logdebug \ --soc_versionAscend310B4 \ --precision_modeallow_fp32_to_fp16 \ --op_select_implmodehigh_precision \ --compile_log./compile_log逐项说明。ASCEND_GLOBAL_LOG_LEVEL1打开 INFO 级别日志ASCEND_SLOG_PRINT_TO_STDOUT1让日志直接打到终端方便实时观察。TE_PARALLEL_COMPILER1把算子编译的并行进程数降到 1这是解决开发者套件内存不足卡死的关键因为默认并行度是按服务器配置来的在内存小的板子上会直接 OOM。MAX_COMPILE_CORE_NUMBER1限制图编译可用的 CPU 核数进一步降低内存峰值。--logdebug让 ATC 输出调试日志--compile_log./compile_log把算子编译日志单独存到目录里后面排查算子问题就看这个目录。--soc_version必须和你实际硬件匹配Atlas 200I DK A2 一般是Ascend310B4填错会直接报错退出不会卡住所以这个不是卡住的原因但必须填对。如果你用的是服务器环境内存充足那TE_PARALLEL_COMPILER可以适当调大比如设为 4 或 8加快算子编译。但要注意并行度不是越大越好超过 CPU 核数反而会因为上下文切换变慢。可以用nproc看核数然后设为核数的一半左右。对于 ONNX 模型--framework5是固定值。TensorFlow 是 3Caffe 是 0。这个填错会报框架不支持不会卡住。现在说验证动作。第一步运行命令后立刻开另一个终端执行top -p $(pgrep -f atc)看 atc 进程的 CPU 和内存占用。如果内存占用持续上涨然后突然掉下来同时 CPU 掉到接近 0说明触发了 OOM Killer进程被杀了。这时候终端可能会看到Killed字样或者日志里有Process ForkServerPoolWorker-2相关的信息。这就是典型的内存不足。第二步观察compile_log目录。如果目录里不断有新文件生成说明算子编译在进行只是慢。如果目录长时间没有变化说明卡在某个算子编译上。可以ls -lt ./compile_log | head看最新文件的时间戳。第三步如果怀疑是某个特定算子卡住可以用--op_select_implmode和--precision_mode调整。比如把--precision_mode从allow_fp32_to_fp16改成force_fp32看是否某个算子在 fp16 模式下编译异常慢。这个不是万能药但能帮你缩小范围。还有一个实用参数是--disable_reuse_memory1关闭内存复用。默认 ATC 会复用内存来降低峰值但某些模型复用逻辑会出问题导致卡住关掉后内存占用会上升但能绕过卡死。这个参数在内存充足的服务器上可以用开发者套件上慎用。如果你需要把配置写成 JSON 文件比如在 CI 里跑可以这样{ model: ./model.onnx, framework: 5, output: ./model_out, input_format: NCHW, input_shape: input:1,3,224,224, soc_version: Ascend310B4, precision_mode: allow_fp32_to_fp16, op_select_implmode: high_precision, compile_log: ./compile_log }然后atc --config./atc_config.json。注意 JSON 里的 key 和命令行参数名一致但下划线形式。这个方式适合把转换配置版本化管理。最后强调所有环境变量要在同一个 shell 里 export或者写进~/.bashrc。如果你在脚本里跑记得source一下。环境变量不生效是「调了参数但没变化」的常见原因排查时先echo $TE_PARALLEL_COMPILER确认。4. 验证转换是否恢复从日志到 om 文件的成功判定参数调完之后怎么确认转换真的恢复了而不是「看起来在跑其实还是卡」这一节给出几个判定信号。第一个信号是日志节奏。正常的 ATC 转换日志会按阶段推进先是图解析然后是算子融合接着是算子编译最后是序列化。每个阶段之间会有时间间隔但不会长时间停滞。如果你看到日志停在Start to compile op: xxx超过几分钟没有下一条那就是卡在这个算子上。这时候可以结合compile_log里对应算子的日志看细节。第二个信号是 CPU 和内存曲线。用top观察正常转换时 CPU 会有波动内存占用在算子编译阶段会上升编译完会释放。如果内存一直居高不下且不释放说明有内存泄漏或者复用逻辑异常。如果 CPU 长期 100% 但日志不动说明在死循环编译某个算子。第三个信号是最终产物。转换成功的标志是输出目录里生成.om文件并且终端打印ATC run success, welcome to the next use.。这句话是昇腾工具链的固定成功提示看到它基本就稳了。如果只生成了中间文件没有 om说明转换中途失败。验证 om 文件是否可用可以用atc --mode1 --om./model_out.om来查看模型信息或者用msame工具跑一次推理。不过这一步是转换后的验证不是排查卡住必须的。如果你在开发者套件上创建 swap 分区是解决内存不足的兜底方案。操作如下sudo fallocate --length 8G /swapfile sudo chmod 600 /swapfile sudo mkswap /swapfile sudo swapon /swapfile free -hfree -h看到 Swap 那一行有 8.0Gi 就说明挂载成功。然后再跑 ATC内存峰值会被 swap 吸收不容易触发 OOM。但要注意swap 是磁盘模拟内存速度慢转换时间会变长但至少不会卡死。这是「用时间换成功率」的方案适合内存实在不够的板子。还有一个容易被忽略的点ATC 转换时的临时目录。默认会用/tmp如果/tmp空间不足也会卡住。可以用df -h /tmp检查必要时通过TMPDIR环境变量指定到大容量分区export TMPDIR/home/user/atc_tmp mkdir -p $TMPDIR这个改动对转换速度影响不大但能避免因磁盘满导致的假死。验证流程建议按这个顺序先确认环境变量生效再跑一次带 debug 日志的转换观察日志和资源占用确认卡点消失最后检查 om 文件生成。每一步都有明确的成功信号不要跳步。5. 常见报错对照排查401、local proxy failed、reading choices、OAuth 与 ATC 卡死这一节把排查过程中可能遇到的报错集中对照。注意有些报错是 TaoToken 调用侧的有些是 ATC 本身的要分清。先说 ATC 侧的典型报错。/usr/local/Ascend/ascend-toolkit/latest/bin/atc: line 17: 2723 Killed这个就是 OOM Killer 干的进程被系统杀了。解决办法就是降并行度加 swap。Process ForkServerPoolWorker-2相关的日志也是内存不足的伴随现象ForkServer 是算子编译的进程池内存不够时 worker 起不来或者被杀。如果日志里出现Unsupported op type那不是卡住是算子不支持需要换 CANN 版本或者用自定义算子。这个和卡住是两回事别混。再说 TaoToken 调用侧的报错。401一般是 API Key 无效或者没带。检查请求头里Authorization: Bearer key是否正确Key 有没有过期。local proxy failed通常是本地网络配置问题检查是不是设置了不该设的代理环境变量比如http_proxy、https_proxy把它们 unset 掉再试。reading choices这类报错一般是响应格式解析问题可能是 Base URL 填错导致返回了非预期内容确认 Base URL 是https://taotoken.net/api不要多加路径。OAuth相关报错一般是认证流程问题重新生成 Key 或者检查账号状态。这里要提醒TaoToken 的调用和 ATC 转换是两个独立链路。ATC 卡住不会导致 TaoToken 报 401反之亦然。排查时先定位是哪条链路的问题别把两边的错误混在一起看。如果你用 Claude Code 接入 TaoToken配置三件套要写全Base URL、Key、Model ID。缺任何一个都会报错。Base URL 是https://taotoken.net/apiKey 从 API Keys 页面拿Model ID 按文档填。这三个值建议写进配置文件而不是每次命令行传避免手误。对于 ATC 卡住的排查还有一个实用技巧用strace看进程在等什么系统调用。比如strace -p pid -f -e tracenetwork,read,write如果看到大量read阻塞在某个文件上说明在等 IO如果看到futex等待说明在等锁。这个工具需要 root 权限开发者套件上一般可用。不过 strace 输出量大建议重定向到文件再分析。最后给一个排查清单按顺序过一遍检查项命令预期结果环境变量echo $TE_PARALLEL_COMPILER输出 1内存free -hSwap 有空间临时目录df -h /tmp有足够空间进程状态top -p $(pgrep -f atc)CPU 有波动编译日志ls -lt ./compile_log文件时间戳更新最终产物ls -lh ./model_out.om文件存在按这个清单走基本能定位到卡点。如果全部正常但还是很慢那就是模型本身算子多、编译量大只能等或者换更高配置的机器。6. 长期做 CANN 模型转换的工程化建议与工具入口单次排查解决的是「这次卡住」但如果你要长期做模型转换比如每周都要转几个模型、维护一套转换流水线那就需要工程化的思路。第一把 ATC 命令参数化。不要每次手敲写成一个 shell 脚本或者 Python 脚本参数从配置文件读。这样环境变量、soc_version、input_shape 这些容易出错的地方都集中管理。脚本里加上日志重定向和超时检测超过阈值就报警。第二建立转换日志归档。每次转换的 debug 日志和 compile_log 按模型名和时间戳存起来出问题时可以对比「上次成功」和「这次失败」的差异。这个习惯能省很多排查时间。第三对于反复转换的场景用 Coding Plan 把「生成转换命令、分析日志、调参」串起来会更高效入口在 https://taotoken.net/coding-plan?utm_sourcetaotoken_aicg_blog_endutm_contentcoding_planutm_campaignrewrite 。它适合把排查经验固化成可复用的工作流。第四关注 CANN 版本和算子支持列表的更新。有些卡住问题在新版本里已经修复升级工具链比调参更直接。升级前先在测试环境验证别直接上生产。如果你在排查中需要快速查算子支持情况或者解读报错模型对话入口在 https://taotoken.net/models?utm_sourcetaotoken_aicg_blog_endutm_contentmodel_chatutm_campaignrewrite 接入文档在 https://taotoken.net/doc?utm_sourcetaotoken_aicg_blog_endutm_contentdocutm_campaignrewrite 。API Key 在 https://taotoken.net/api-keys?utm_sourcetaotoken_aicg_blog_endutm_contentapi_keysutm_campaignrewrite 生成。最后说一个我踩过的坑有次转换卡住我以为是内存问题调了半天并行度没用后来发现是模型里有个自定义算子ATC 在等一个不存在的插件日志级别不够没显示出来。打开 debug 日志后才看到Waiting for plugin: xxx。所以「开日志」永远是第一步别省这一步。转换成功后建议用msame或者ais_bench跑一次推理验证精度确保转换没有引入数值问题。这一步不是排查卡住必须的但工程化流程里不能少。整个链路跑通才算真正「恢复转换流程」。