2026年2月9日，中国政府采购网的一则公告划定了算力市场的分水岭。深圳光明大装置算力服务支撑平台采购项目由中国移动广东公司以约1.55亿元中标，所有软硬件设备明确标注“拒绝进口”，全程聚焦国产化算力。
距离2025年4月英伟达H20被全面列入出口管制清单已过去近一年。这期间，英伟达在中国AI芯片的市场份额从2022年的95%跌至2025年上半年的54%。昇腾910C从备胎转正为主力，完成了从“能用”到“好用”的跨越。但在深圳光明大装置之外，无数中小模型团队面对昇腾910C时发现：这不是简单的“插拔更换”，而是一场从CUDA到CANN的底层重构。
算子适配：从自动兼容到逐行审计
在英伟达的CUDA体系里，开发者习惯了PyTorch的宽容。只要不调用极冷门的算子，通常能自动找到兼容方案。但昇腾910C搭载的CANN栈，要求更严格的确定性。
以最近流行的视频生成模型为例，基于DiT架构的扩散模型在原平台上可能只需要修改几个Device参数。但在昇腾910C上，常会遇到自定义算子缺失的问题。比如针对特定硬件优化的FlashAttention变体，在CANN上可能需要重新编译适配。这不仅是改几行代码的事，往往涉及整个算子库的更新周期。
python
昇腾 CANN 环境适配示例
import torch_npu import torch.distributed as dist
1. 必须前置初始化 torch_npu
torch_npu.npu.set_device(device_id)
2. 通信后端变更
dist.init_process_group(backend='hccl')
很多开发者在这里踩坑。如果忽略torch_npu的前置初始化，后续所有NCCL通信接口调用会直接崩溃。更隐蔽的问题在于内存管理。NVIDIA的CUDA内存分配器默认采用异步机制，而昇腾NPU内存在某些版本中强制要求同步刷新。这在处理动态形状输入时，容易导致显存溢出而非计算错误，排查难度极高。
HCCL通信：绕不开的拓扑感知
H20虽然单卡算力受限，但NVLink互连技术的成熟度极高。昇腾910C单卡算力强劲，其集群扩展却高度依赖HCCL（Huawei Collective Communication Library）与RoCEv2网络。
在企业级大规模训练中，NCCL擅长AllReduce的自动流水线并行，HCCL则需要更精细的拓扑感知配置。如果直接在原有的Kubernetes集群上替换显卡而不调整调度策略，跨机架通信极易产生拥塞，导致训练吞吐量不升反降。实际操作中，通常需要引入华为提供的网络拓扑工具重绘路由，并调整HCCL_CONNECT_TIMEOUT等参数，才能将吞吐量拉回基准线。
迁移策略：别急着拔掉H20
对于希望在2026年顺利过渡的团队，盲目切换并不可取。
首先，不要手动逐行检查代码。应利用华为提供的ATC（Ascend Tensor Compiler）工具链，在CI/CD流水线中加入算子兼容性扫描。对于未支持的算子，优先使用昇腾社区的PPL替代，或通过custom_op接口手动实现。
其次，昇腾910C对自动混合精度的支持与CUDA略有不同。建议使用torch.amp.autocast配合CANN特定的keep_batchnorm_fp32设置，避免数值不稳定导致的训练发散。初始配置耗时较长，但调优后的混合训练效率足以支撑大模型迭代。
最关键的是建立验证机制。在完全割舍H20之前，保留部分NVIDIA节点作为对照组。每次模型迭代后，同时运行两组集群，比对Loss收敛曲线和最终精度。这不仅是技术校验，更是为了给国产算力稳定性提供数据支撑。
算力芯片的物理替代只是第一步，软件底座的重构才是真正的考验。那些在2025年率先完成迁移的企业，已经在2026年的大模型竞速中，拿到了成本更低、自主权更高的入场券。
