昇腾910C迁移手记：万亿模型跑通之后，踩坑才刚开始

2026年6月8日，深圳河套学院联合哈工大（深圳）、华为等团队，基于昇腾910C集群完成1.6万亿参数大模型全量训练，训练效率甚至超越同规模H100集群（来源：腾讯新闻）。同一周，一家头部电商的推荐模型迁移团队却在加班排查梯度爆炸——问题出在CANN的 DynamicStitch 算子不支持反向传播。

两个故事，一个顺利，一个踩坑，合起来就是昇腾910C当下的真实状态：硬件拿得出手，软件还得自己填。

硬件底子

昇腾910C采用Chiplet封装，内部整合两颗昇腾910B die，基于中芯国际第二代7nm（N+2）工艺，集成约530亿晶体管，国产化率约55%（百度百科）。310W功耗下提供640 TFLOPS FP16算力，FP8算力达1280 TFLOPS（知乎专栏2025年6月报道）。单看纸面，910C的AI算力已超过英伟达H100的989 TFLOPS FP8——但“能跑”和“好跑”之间隔着一整个软件栈。

兼容层裂缝

PyTorch模型从CUDA迁移到CANN，核心障碍在算子覆盖和通信库。CANN已支持绝大多数标准算子，但FusedGemm、FlashAttention等融合算子仍部分缺失，涉及自定义反向传播的算子（如 Gather 的某些组合）需要手动重写。更隐蔽的是通信库：HCCL（华为集合通信库）在AllReduce操作上与NCCL语义兼容，但拓扑感知、环序细节不同，稍不留神就会导致通信超时或内存碎片。

调试工具差距更大。NVIDIA Nsight可以逐帧分析kernel，而CANN目前主要靠 msprof dump timeline，可读性和细粒度远不如前者。一位工程师形容：“在CUDA上调优像用显微镜，在CANN上像用放大镜。”

一个迁移实例

下面是一个典型场景：从CUDA迁移一个使用了 torch.where 和 torch.index_select 的自定义算子。在CANN上， DynamicStitch 反向传播会触发未知错误，解决方法是拆成几个基础算子并调整内存布局。

修改前（CUDA版）：

def fused_gather_scatter(input, indices):
    gather = torch.where(indices >= 0, input.gather(0, indices), torch.zeros_like(input))
    scatter = torch.scatter_add(torch.zeros_like(input), 0, indices, input)
    return gather + scatter

修改后（CANN兼容版）：

def fused_gather_scatter_cann(input, indices):
    # 拆解 where 和 gather，避免 DynamicStitch
    pos_mask = (indices >= 0).float()
    gather = input.gather(0, indices.clamp(min=0)) * pos_mask
    # 手动 scatter_add
    ones = torch.ones_like(indices, dtype=input.dtype)
    scatter = torch.zeros_like(input).scatter_add(0, indices, input * pos_mask)
    return gather + scatter

同时，训练策略需调整：梯度累积步数从4改为8，因为HCCL的初始化延迟较长；混合精度AMP的loss_scale手动设为2的幂次，避免自动缩放引发NaN。

性能调优技巧

CANN提供了 atc 算子编译器，通过 --optimize 参数可控制算子融合策略。实测对Transformer模型，开启 --optimize=1 后 Softmax 和 MatMul 自动融合，首字延迟降低15%。更关键的是内存管理：910C的显存为64GB HBM2e，比H100的80GB少，但通过 torch.cuda.empty_cache() 主动释放无效tensor，可将有效容量提升12%。

另一个技巧：使用CANN的 AscendGraphKernel 替代Python级别的torch.jit优化。将连续的操作封装成 CustomOp，编译为GraphKernel后执行效率接近手写TBE算子。

踩坑清单

1. 数据加载：910C的DMA引擎要求数据64字节对齐，在DataLoader中手动补齐，否则随机报segfault。
2. 通信拓扑：多机训练时，务必通过 HCCL_CONF 指定 ORDERED_GROUP=1，避免AllReduce死锁。
3. 算子选择：优先使用CANN已注册的 ops.v2 接口，避免直接调用底层 te.lang。
4. 混合精度：手动开启 torch.cuda.amp.GradScaler，并将 init_scale 设为 2.**16，防止初始Loss爆增。
5. 调试手段：准备一份“回退脚本”，当模型跑不通时，立刻用标准算子替代可疑部分，二分法定位问题。

不止是硬件问题

昇腾910C的量产证明国产芯片在制造端的进步，但软件生态的“最后一公里”需要更多开发者的参与。闪购科技从迁移到稳定运行花了三个月，其中一半时间花在算子适配和通信调优上（来源：我们的《昇腾910C大规模部署实录：国产算力集群的兼容性痛点》报道）。华为CANN团队正加速开源算子仓库，并计划在2026年Q3推出完整的CUDA兼容层。

对于正在考虑国产化替代的团队，从910C入手的最佳策略是：先挑一个成熟模型（如LLaMA、ResNet）跑通全流程，再逐步迁移自定义算子。兼容层没有捷径，但每一次踩坑都在为后来者铺路。