H200/H800迁到昇腾910C，先查算子、通信和显存
卡已经进了机房，任务仍可能停在启动阶段。
把运行在H200/H800上的CUDA训练或推理代码搬到昇腾910C，API替换只占一部分工作。项目最容易耗时的地方，通常是算子覆盖、HCCL通信和内存分配。三处还会互相放大：算子回退拖慢单步，通信等待随之增加；动态shape改变内存峰值，又会让同一任务表现不稳定。
公开参数能划出硬件边界，无法替代同负载测试。
先把参数表读对
腾讯云开发者社区的对比文章给出了一组昇腾910C与H100的数据：
| 项目 | 昇腾910C | 同一来源中的H100 |
|---|---|---|
| FP16峰值算力 | 800 TFLOPS | 1,979 TFLOPS |
| HBM容量 | 96 GB | 80 GB |
| 显存带宽 | 1.8 TB/s | 3.35 TB/s |
| 卡间互联 | HCCS 400 GB/s | 摘要未给出 |
按该文口径，910C的FP16峰值约为H100的40%。同一摘要还给出MFU约30%、推理速度6,688 tok/s/NPU，但没有交代完整的模型、精度、批量、序列长度和并行配置。这些数字可以作为待复核线索，不适合直接拿来当项目验收线。
现有素材也没有H200、H800与910C在同一任务下的测试结果，因此没必要补一张看似完整的三卡性能表。迁移前后的软件版本和运行条件没有对齐，单卡参数再详细，也解释不了真实吞吐差距。
华为在2025年全联接大会演讲中提到，为承接DeepSeek快速增长的用户和流量，相关团队从春节持续工作到4月30日，最终使Ascend 910B/910C的推理能力达到客户的基本需求。这个表述透露出一个重要事实：从芯片可用到业务可用，中间还有大量软件和工程工作。“基本需求”也不能外推到所有模型、训练任务和集群规模。
算子问题，先盘点再动手
CUDA项目里往往同时存在框架标准算子、自定义CUDA算子和融合算子。迁到CANN后，主干路径能够启动，不代表所有分支都已覆盖。特定shape、精度或输入长度才会触发的算子，尤其容易漏掉。
华为云昇腾专区学习路径把迁移分为四个阶段：迁移分析、适配、精度调试和性能调优。这个顺序值得保留。先确认算子能否执行和结果是否正确，再谈融合与加速，返工会少很多。
比一段缺少环境信息的报错截图更有用的，是一份可追踪的算子记录：
模块/算子：
输入shape、dtype：
CUDA实现：
昇腾实现：
CANN及框架版本：
精度结果：
性能结果：
回退方案：
框架路线也要尽早定下来：继续使用PyTorch的昇腾适配，还是改用MindSpore；如果项目准备引入ATB，也要单独核对其支持范围和版本。框架或组件的切换不会自动补齐自定义算子，还会带来新一轮精度验证。
适配时可以先固定输入，在单卡跑通完整推理链路，或完整的前向与反向。输出、损失和关键中间张量能够核对后，再记录单步耗时。否则，速度提升可能只是来自计算路径缺失。
HCCL问题，先分清链路慢还是任务在等
910C公开资料中的HCCS带宽为400 GB/s，这是互联规格，不等同于业务侧实际得到的AllReduce吞吐。通信效率还会受到rank映射、跨节点链路、集合通信方式以及计算与通信调度的影响。
从H200/H800集群复制DDP配置后直接扩容，风险就在这里。更稳妥的排查顺序是：先在单卡确认计算正确，再上单机多卡定位卡间通信，最后进入跨节点测试。每扩大一层边界，都要留下对应基线。
遇到超时或慢rank，应优先保存第一次失败现场，包括rank、节点、集合通信类型、张量大小、发生步骤，以及CANN和框架版本。连续重试产生的大量日志，反而可能淹没最初的异常位置。
混合精度、梯度累积和通信重叠都可以进入测试清单，但一次只改一个变量。通信重叠的开关位置取决于框架和版本，不能把某个初始化参数写成通用解法。配置是否生效，最终要回到执行时间线和通信占比上确认。
96 GB显存，也要看怎么分
昇腾910C配备96 GB HBM，但总容量足够，不代表任意时刻都能拿到需要的连续内存。动态shape、输入长度变化以及频繁申请和释放内存，都会让峰值和碎片更难判断。
一次OOM也不能直接归因于碎片。排查记录至少应包含失败申请量、已分配内存、保留内存、峰值、当前输入shape和发生步骤。缺少这些信息时，“还有空闲显存却申请失败”只能算现象，无法确认原因。
处理时可以先稳定输入shape，通过分桶或Padding减少无规律变化；随后固定复现步骤，区分参数、优化器状态、激活值和通信缓冲区分别占用了多少内存。完成测量后，再根据当前CANN和框架文档启用内存复用或缓存清理。网上流传的环境变量不宜直接当成所有版本都适用的开关，切换到MindSpore也需要重新测量，而不是默认显存问题会自行消失。
按这个顺序迁，返工会少一些
迁移分析：固定H200/H800侧的基线，记录模型权重、输入、精度、批量、序列长度、并行方式和软件版本。没有可复现基线，后面的快慢都说不清。
适配：在910C单卡上跑通完整计算路径，列出缺失算子、替代实现和回退方案。先保证覆盖，再减少回退。
精度调试：使用固定输入，对比输出、损失和关键中间张量，找到最早出现偏差的位置。不要等到最终指标异常后再从头翻日志。
性能调优：分别看算子耗时、通信占比和内存峰值，再从单机多卡扩展到跨节点。一次只调整一个参数，并保留调整前后的测试条件。
H200/H800与910C只有在模型、输入、精度和并行策略一致时，结果才有比较价值。不同条件下的峰值算力、MFU或吞吐放在一起，容易得出错误结论。
能稳定复现，才算迁完
任务能够启动，只说明第一步完成了。上线前还要回答几个具体问题：未支持算子是否都有记录和回退方案，精度是否达到项目要求，目标规模下HCCL是否稳定，OOM能否复现和解释，性能测试条件能否由其他人重复。
现有来源可以支撑910C的部分硬件参数，也能确认华为曾投入多团队完成910B/910C的推理适配；它们不足以给出H200、H800与910C的通用胜负，也无法替代具体业务的验证。选型应落到目标负载PoC、软件版本和运维能力上，峰值参数只适合做第一轮筛选。
