把一套 PyTorch 代码放到昇腾上，最容易制造误判的时刻，往往是第一个 Demo 跑通之后。
模型能够启动、标准算子没有报错，说明 torch_npu 已经接住了基础接口。但生产任务还要面对训练稳定性、性能和精度对齐。代码里只要夹着自定义 Attention、特殊 NMS（非极大值抑制）或融合算子，迁移工作就可能从框架适配一路下沉到算子开发。
先查算子，别急着改完整套代码
迁移前更实用的动作，是先把模型的算子清单拉出来：哪些已有 CANN 支持，哪些可以替换，哪些必须保留自定义实现。
CUDA 环境中的自定义算子，常见形态是 Python 接口加 C++、CUDA 内核。到了昇腾平台，原来的 CUDA 内核不能直接复用。如果 CANN 和 torch_npu 没有对应实现，团队就要选择拆分算子、改写模型，或者使用 Ascend C 重新开发。
这里费时间的通常不是接口名称，而是计算逻辑如何映射到 NPU。数据搬运、切分方式和计算单元调度都可能影响最终性能。算子即使能执行，也还要继续检查输出精度和运行耗时。FP16 等低精度计算在不同硬件上的结果可能出现差异，排查时需要定位到具体算子，不能只看模型最终输出。
华为昇腾开发者社区发布的《昇腾算子注册与模型迁移》也把模型结构和算子的重新审视列为迁移流程的一部分。对团队而言，算子覆盖率比“代码改了多少行”更能反映实际工作量。
单卡跑通之后，还有 HCCL
模型扩大到多机多卡后，问题会转向通信。CUDA 集群通常使用 NCCL，昇腾平台对应的是 HCCL（Huawei Collective Communication Library）。训练框架可以接入 HCCL，但接入成功不等于原有并行策略可以原样照搬。
需要重点检查的包括数据并行和模型并行的切分方式、集合通信调用，以及计算与通信能否重叠。单卡性能正常，多卡扩展效率却不理想，排查方向就不应继续停留在单个算子上，还要看节点拓扑和数据流动。
这类问题很难靠一次代码转换解决。原来针对 GPU 集群设计的分片方式，到了 NPU 集群上可能需要重新测量和调整。迁移验收也不能只记录“能否训练”，还要保留单卡、多卡和多节点的对照结果。
OOM 往往出现在临时张量上
内存峰值是另一个容易被 Demo 掩盖的问题。同一套 PyTorch 模型切换到 torch_npu 后，动态图执行、内存预分配和算子实现发生变化，原有的显存经验不一定继续适用。
模型平时占用看起来正常，却在某一步突然 OOM，常见排查对象包括临时张量、未及时释放的中间结果，以及可以融合却被拆开的算子。此时只看平均内存占用意义有限，更需要找到峰值出现在哪个算子、哪个训练阶段。
MindSpore 和 PyTorch 代表了两种不同的迁移路径。已有项目积累了大量 PyTorch 代码，通常会优先保留原框架，通过 torch_npu 完成适配，再处理缺失算子和性能热点。新项目如果需要较多昇腾原生开发，也可以评估 MindSpore，减少跨框架兼容层带来的工作。
CANN 开源后，迁移仍要算工程账
据观察者网报道，华为在 2025 年 8 月 5 日的昇腾计算产业发展峰会上宣布，CANN 全面开源开放，Mind 系列应用使能套件及工具链全面开源。CANN 位于 PyTorch、TensorFlow、MindSpore 等上层框架与昇腾硬件之间，开放相关工具有助于开发者排查问题和进行自定义开发。
但工具开放不会自动抹平迁移成本。准备把业务转到昇腾 910D 的团队，仍需逐项核对算子覆盖、精度基线、HCCL 通信、内存峰值和监控工具。团队是否具备 Ascend C 开发能力，也会直接影响项目进度。
比较稳妥的顺序是：先用真实业务模型验证标准算子，再挑出自定义算子和高频热点；单卡完成精度对齐后，再进入多卡通信测试；最后才讨论生产切换。这样至少能在投入扩大前，看清主要成本落在哪里。
CUDA 代码迁到昇腾，框架接口只是入口。真正决定项目能否落地的，是那批无法直接替换的算子，以及围绕它们展开的精度、通信和内存调试。
