2025年6月20日的华为开发者大会上，华为云计算CEO张平安宣布，新一代昇腾AI云服务全面上线。几个月后，徐直军在华为全联接大会演讲中披露，为了承接DeepSeek增长的用户和流量，AI研发团队从春节持续忙到4月30日，Ascend 910B/910C的推理能力才达到客户的基本需求。前一条来自证券时报网转载报道，后一条见华为官网演讲实录。
这段公开经历给运维团队的提醒很直接：机器上架、卡被识别，并不代表集群已经具备持续交付能力。版本、算子、通信、监控、数据和机房条件，少一项都可能把排障拖成多人协作。
上架前，先锁住版本组合
九方智投整理的昇腾产业资料，把昇腾计算拆成处理器、CANN、AI框架、应用使能、开发工具链和管理运维工具等环节。各环节可以单独安装，但若没有一份可复现的组合表，后续排障会很被动。
部署前至少记清这些字段：
- 服务器型号、NPU型号和固件版本；
Ascend-Driver、CANN版本及安装包来源；- 训练框架、昇腾适配插件和算子库版本；
- 容器镜像、模型代码提交记录；
- 网卡、交换机固件及网络配置快照。
驱动、固件、CANN和框架插件不要各自追新。同一任务涉及的节点尽量保持一致；确实需要混合版本时，先在小规模环境验证，并把例外节点单独标出。
兼容关系以项目所用版本的文档为准。项目采用CANN 8.0，就查对应的Release Notes；更换CANN后，驱动、固件和框架插件也要重新核对。升级前保留原安装包、配置和回滚步骤，比出问题后临时找包可靠得多。
算子能跑，只完成了一半
自动迁移结束后，还要补两轮验收：结果核对和性能画像。如果使用MindConverter，先用代表性输入比对模型输出，再通过MindStudio或Ascend Profiling查看执行情况。
Profile至少要回答三个问题：
- 时间主要耗在哪些算子上；
- 是否存在频繁的数据格式转换或额外搬运；
- 显存峰值、通信等待和计算时间是否符合预期。
遇到性能偏低的算子，先查官方算子和当前版本的适配说明，再决定是否编写TBE或DSL算子。自定义算子会带来后续升级和回归测试成本，不能只看眼前一次跑分。
验收负载也要固定。模型版本、输入长度、批次设置和精度模式一旦变化，前后两次Profile就失去可比性。每次改动都留下基线，才能分清收益来自算子、框架，还是测试条件变了。
HCCL排障先画清拓扑
HCCL负责多卡集合通信。扩到多机后，第一份排障材料不该是参数截图，而应是一张能核对到物理端口的拓扑表：主机名、业务IP、Device ID、Rank ID、网卡、交换机端口和机架位置一一对应。
rank table生成后最好再做一次人工复核。IP、设备编号或网卡绑定出错，最终可能表现为连接失败、通信超时或任务挂住，日志却未必直接指出是哪一行配置有问题。
通信测试可以逐级放大：
- 先测单机多卡；
- 再测同机架跨节点；
- 最后加入跨机架链路。
每一级都使用相同的AllReduce测试方法并保存结果。性能在哪一级开始变化，排查边界就能缩小到服务器、机架网络或跨机架路径。
NCCL与HCCL的变量名和语义并不完全一致，迁移配置时要逐项核对当前CANN和HCCL文档。算法、缓冲区、超时参数也不宜一次改一批，否则很难判断哪项改动产生了影响。
如果网络侧采用CloudEngine交换机，ECN、DCQCN和自适应路由是否启用，要结合具体型号、网卡能力和网络方案确认。若使用hccn_tool检查链路，输出也应随测试记录一并保存。
告警要落到具体卡、具体任务
规模上来后，靠人逐台登录查看日志很快会失效。看板解决的是发现问题，告警还得带上足够的上下文：主机、Device ID、Rank ID、任务ID、错误码、首次出现时间以及最近一次配置变更。
npu-smi输出、CANN日志、HCCL日志和训练框架日志应集中留存。团队可以使用Prometheus配合Exporter采集设备与任务指标，再结合MindInsight查看训练过程。工具选什么可以调整，日志和指标能否按同一任务串起来更关键。
自动恢复也要先演练。重启任务、摘除异常卡或缩减节点，都依赖训练框架的弹性调度和检查点机制。没有验证过检查点恢复，自动化只会反复拉起同一个故障。
演练时至少覆盖进程退出、节点失联和通信超时，并记录几个结果：任务能否恢复、从哪个检查点恢复、集群规模是否变化、数据采样状态是否保持一致。生产环境真正需要的是可验证的恢复流程。
利用率低，输入链路也要查
NPU利用率下降时，计算侧和输入侧要同时排查。用iostat查看存储等待，再结合Profiling确认DataLoader、CPU预处理和设备计算之间有没有明显空档。
Lustre和OceanStor都可以作为并行存储方案的候选，但文件系统名称不会直接带来吞吐。小文件数量、数据切分方式、缓存、预取和并发读取设置，都会影响实际表现。
一个实用办法是固定同一批数据和训练参数，分别测试本地盘与共享存储。若本地数据运行稳定，共享存储下等待时间明显增加，排查重点就应转向存储路径和数据组织。
FlashAttention解决的是模型侧计算与访存问题，不能替代输入链路排查。把算子优化和数据加载混在一起，很容易改了很多参数，却没有碰到真正的瓶颈。
功耗和散热只认设备配置
功耗核算要覆盖服务器整机、网卡与交换机、存储、供电损耗和冷却系统，单卡TDP只是其中一个输入。机房方案应以设备厂商提供的配置表和最终服务器形态为准，缺少出处的估算值不适合直接拿来做容量设计。
进场前需要确认：
- 单台服务器的输入功率范围；
- 每个机柜的设备数量和供电上限；
- PDU、UPS及制冷系统的余量；
- 进风条件、回风路径和故障降额方案。
是否采用液冷，要结合设备形态、机柜密度和机房条件判断。若要做CFD热仿真，输入数据应采用最终机柜布局和送回风条件。设备上电也应分批进行，持续观察降频、温度、硬件告警和回路负载。
扩容前，先过这张验收表
上一阶段的基线、日志和回滚材料不齐，就别急着放大规模。
| 阶段 | 必须留存 | 放行条件 |
|---|---|---|
| 单卡 | 软件版本、模型输出、Profile基线 | 结果可复现，异常算子有归因 |
| 单机多卡 | HCCL测试、显存占用、任务耗时 | 相同负载重复运行稳定 |
| 小规模跨节点 | 拓扑表、rank table、网络测试记录 | 无法解释的超时已排除 |
| 扩容运行 | 监控指标、集中日志、检查点演练 | 告警能定位到Rank，恢复流程通过验证 |
| 生产变更 | 变更记录、前后基线、回滚材料 | 性能回退可追踪，版本可恢复 |
规模上升后，排障成本主要耗在三个问题上：哪一层发生了变化，故障从哪里开始，当前状态能不能回退。把版本、算子、拓扑、故障、数据和机房这六本账留全，昇腾910C从单卡扩到多机乃至千卡时，团队就不必靠猜。
