民生证券2023年报告援引《昇腾计算产业发展白皮书》称，从2012年开始的6年里，AI计算需求增加30万倍；报告援引IDC数据称，2021年中国智能算力规模达到155.2 EFLOPS。需求增长把国产算力迁移推到台前，但工程现场遇到的问题往往很具体：一个算子不支持、一处AICore异常、一次HCCL等待，都可能让训练停住。
把千卡级任务从英伟达集群搬到昇腾，最容易犯的错，是把迁移理解成依赖替换。代码能启动，只说明入口通了。原稿提到的 CoreDump、HCCL无响应和NPU显存溢出，分属算子执行、集合通信和内存管理问题，混在一起排查，只会不断扩大故障范围。
腾讯云开发者社区收录的一篇文章给出的昇腾910C指标包括：FP16算力800 TFLOPS、HBM容量96 GB、显存带宽1.8 TB/s、HCCS带宽400 GB/s。该文同时把软件栈称为最大的隐性成本。纸面规格说明硬件具备承载能力，却不能证明原有CUDA任务可以原样复用。910D也不宜照抄910C的适配结论，驱动、固件、框架和算子版本都要在目标环境重新验证。
先把CUDA基线钉死
迁移前需要留下一个可复现的CUDA基线，至少包括模型代码与权重版本、框架和依赖版本、输入shape、精度模式、batch size、序列长度、并行策略、关键输出、损失变化、单步耗时和显存峰值。
这一步常被省略，后果是迁移后即使任务跑完，团队也无法判断结果偏差来自平台、算子替换，还是配置已经改变。吞吐下降和显存上涨同样如此，没有同条件基线，所有结论都只能靠猜。
验收顺序应逐层推进：图编译、单卡前向、单卡反向、单机多卡、多机训练。每次只增加一个变量。直接在千卡规模上试错，会把算子、通信和资源问题叠在一起，日志也很难对应到真正的故障点。
算子适配，先查语义再查覆盖
迁移时不能只问“这个算子有没有”。同名算子还可能存在参数、dtype、shape或执行语义上的差异；CUDA融合算子和自定义算子则可能没有可直接替换的实现。动态图、动态shape进入图编译后，也可能暴露原环境没有出现的问题。
可以先把算子分成三类：框架已支持且可直接验证的算子；已有实现但输入条件受限的算子；需要替换、拆分或重新实现的CUDA自定义算子。每一项都记录输入shape和dtype，并分别核对前向输出、反向梯度、内存占用与执行时间。
只看任务是否报错远远不够。一个替换后的算子可能正常返回结果，却改变数值精度或梯度行为；融合算子拆开后也可能明显增加中间张量和调度开销。正确性确认后，再判断是否需要做性能改写，顺序不要颠倒。
CoreDump要从第一个异常往回找
出现AICore CoreDump 时，Python堆栈的最后一行往往只是错误暴露的位置，不能直接视为根因。更有效的做法是保留第一次异常的完整日志，退回单卡，把输入和执行路径缩减到能够稳定复现的最小范围。
排查时重点核对报错算子的shape、dtype和数据布局，确认问题发生在图编译阶段还是执行阶段。如果单卡就能复现，应继续围绕算子和输入检查；如果单卡稳定、进入多卡后才出错，再把范围转向通信、并行切分和不同rank的执行路径。
不要同时修改多个算子或配置。每次只改一项，并记录报错位置是否移动、显存峰值是否变化、输出是否仍然一致。否则一次“修好”很可能只是让异常延后出现。
HCCL卡住时，逐个确认rank走到哪里
HCCL无响应并不一定是通信库本身故障。某个rank提前发生OOM、算子异常或控制流分叉，其他rank仍进入集合通信，外部表现同样会像死锁。
因此，多机排查必须为每个rank保留独立日志，核对rank映射、进程数量、网卡和地址配置，并确认所有进程以相同顺序进入集合通信。只盯着主进程日志，通常看不到最早退出的那个rank。
扩容也要分阶段进行：先验证单机多卡，再进入多机；先用短任务确认通信链路和执行顺序，再恢复完整训练配置。如果固定卡数下稳定、扩容后挂起，问题范围便可以收敛到拓扑、配置、时序或资源压力，不必反复改动模型逻辑。
96 GB HBM也可能不够用
910C的96 GB HBM是容量起点，不能直接推出原CUDA配置可以照搬。同一个模型进入不同软件栈后，参数、梯度、优化器状态、激活、通信缓冲区和临时workspace的占用方式可能变化。只根据权重大小估算显存，很容易低估运行峰值。
定位OOM时，先记录峰值发生在初始化、前向、反向、优化器更新还是通信阶段。随后再选择缩小micro-batch或序列长度、启用激活重计算、调整精度和并行策略等手段，具体选项需要以当前框架与算子支持情况为准。
每次调整后都要重新记录峰值和吞吐。显存降下来了，不代表方案已经更优：如果重计算或算子拆分带来过多额外开销，训练速度仍可能明显下降。显存优化和性能测试必须放在同一张记录表里看。
性能账要算到端到端
腾讯云开发者社区的相关文章还给出了MFU约30%、推理速度6,688 tok/s/NPU等数据。这些数字只能视为特定任务与配置下的参考，不能直接当作所有910C项目的验收线。
平台间比较至少要固定模型、输入、精度、batch size、序列长度和并行策略，并把首次编译、预热阶段与稳定运行阶段分开统计。否则，一个包含编译开销的首步时间，很容易被误判为长期性能。
性能分析也不能只看芯片利用率。需要结合逐算子和逐步骤数据，判断瓶颈来自计算、内存访问、集合通信，还是主机侧调度。热点没有定位之前就大面积重写算子，投入很大，收益却未必落在端到端吞吐上。
上线前留一张验收表
| 验收项 | 至少要留下的证据 |
|---|---|
| 正确性 | 固定样本的关键输出、损失与梯度检查结果 |
| 算子 | 替换和拆分清单、输入限制、前向与反向验证记录 |
| 稳定性 | 单卡、单机多卡、多机环境下的可复现运行日志 |
| 通信 | rank映射、集合通信顺序及各rank独立日志 |
| 资源 | 各执行阶段的HBM峰值和OOM发生位置 |
| 性能 | 同配置下的吞吐、时延、通信等待和编译开销 |
| 环境 | 驱动、固件、框架、依赖与模型代码版本 |
迁移项目最危险的状态，是单卡偶尔跑通、多机偶发挂起、速度时快时慢，却没有基线和分层日志。对昇腾910C/910D，更可靠的路线很朴素：锁定CUDA基线，清点算子，再处理AICore错误；通信稳定后，才进入HBM和MFU优化。这套顺序会增加前期记录工作，却能把问题限制在单层，避免在千卡规模上反复试错。
参考资料
- 华为昇腾：国产AI算力“扛旗者”：AI计算需求和2021年中国智能算力规模数据来自该报告援引的白皮书与IDC数据。
- 华为昇腾910C不是最好的AI芯片，但它是中国AI产业唯一的选择——然后呢：910C规格、MFU和推理数据来自该文口径，使用时需结合具体模型、配置与软件版本。
