2026年夏天，北京一家AI公司的架构师在把70B模型从A100迁到昇腾910D集群时，第一步就卡住了——显存爆了（OOM）。这不是个例。随着华为910D芯片开始交付，许多团队发现硬件算力接近H100，但软件生态的迁移之路并不平坦。
经过追踪多个团队，我们总结了三个最常见的坑。
通信效率：默认拓扑拖后腿
一个电商推荐团队在128卡的910D集群上跑70B模型微调，发现训练吞吐只有理论峰值的45%。用hccl_tools分析后发现，跨节点的allreduce通信耗时异常。
问题出在默认配置上。昇腾节点内用HCCS高速互联，节点间用RoCE v2，但默认的环形拓扑在大梯度下延迟高，RoCE的默认MTU 1500也拖慢了大消息传输。
他们手动调整了三项：
- 用
hccn_tool将拓扑改为Recursive Halving-Doubling（RHD）。 - 在交换机上开启MTU 9000的jumbo frame，并调整PFC和ECN设置。
- 在代码中设置通信算法，小消息用Ring，大消息用Tree。
os.environ["HCCL_ALGO"] = "Ring:Tree"
os.environ["HCCL_BUFFSIZE"] = "256"
调整后，通信效率提升到80%以上。这与华为2025年3月在《构筑开放基础软件栈》白皮书中强调的通信组灵活定义方向一致。
显存：96GB也不够用
回到北京的那位架构师，他的70B模型用FP16训练时，参数、优化器状态和激活值加起来需要超过120GB显存，而910D卡是96GB。即使用ZeRO-3也吃不消。
更深的坑在于CANN的显存管理与PyTorch的pinned_memory配合不畅，导致本该卸载到CPU的优化器状态滞留在显存里。
解法组合拳：
- 调大ZeRO-3的
reduce_bucket_size，减少通信次数。 - 对每个Transformer层启用
activation checkpointing，用约30%的计算开销换取近50%的显存节省。 - 在训练循环中，每个微步后强制回收显存。
def cleanup_memory_hook(model, inputs, outputs):
torch.npu.empty_cache()
model.register_backward_hook(cleanup_memory_hook)
最终，单卡显存占用从95GB降到62GB，batch size也从1提升到了4。
算子缺失：自定义是必修课
长文本微调需要FlashAttention。当时910D的CANN版本（8.0.T11）不支持变长序列的flash_attn_varlen_func。退回标准SDPA，速度下降40%。
短期办法是升级CANN版本，或者参考华为samples仓库，用约500行AscendC代码实现一个自定义的FlashAttention算子。
长期来看，团队开始学习达芬奇架构的Cube/Vector单元，自己重写了Fused RMSNorm等关键算子。这条路门槛高，但要让国产算力真正好用，生态里的这些“边角”算子正在被一个一个补上。
调试与建议
昇腾的msprof工具功能全，但默认采样太细，开销不小。调试时建议按需开启。另外，CANN的报错信息有时比较模糊，团队里最好有一位熟悉Linux底层和华为计算栈的工程师。
华为在2025年成立了开发者社区，并定期发布算子补丁。据21财经2025年6月报道，由384个昇腾NPU和192个鲲鹏CPU组成的CloudMatrix 384超节点已经用于盘古Ultra的训练，这表明超大规模集群的稳定性在进步。
给迁移者的建议： 最稳妥的路径是从7B小模型开始。先跑通通信配置、显存回收和算子适配的全流程，再逐步挑战70B及以上的大模型。直接上大模型，问题会堆在一起，很难排查。
910D的算力和显存已经不是瓶颈，但软件生态的适配工作，建议预留至少两周时间。对于预算在百万级以上的团队，自建昇腾集群的经济性已可以考虑，但务必做好技术储备和时间规划。
