"要是哪天像DeepSeek这样的成果先在华为平台上出现，那对我们国家会是非常糟糕的结果。"
4月中旬，英伟达CEO黄仁勋在播客中的这句担忧，很快有了回响。4月24日，DeepSeek V4正式发布，包含1.6万亿参数的V4-Pro和2840亿参数的V4-Flash，上下文长度扩至1M。这对国产算力提出了严峻考验。
6月5日，深圳河套学院联合哈工大（深圳）、深圳市大数据研究院及华为团队宣布：依托1000颗昇腾910C组成的集群，成功完成DeepSeek-V4-Pro的全参数后训练。全程1500余步无中断，故障率仅0.3‰，模型算力利用率（MFU）稳定在30%以上。
这是国产算力首次在这一量级的训练中站稳脚跟。然而，30%的MFU并非唾手可得，它意味着在千亿参数规模的集群中，通信、显存和算子效率必须达到极高的平衡。
迁移：从"能跑"到"跑通"
团队面临的第一个难题是PyTorch到昇腾CANN的迁移。虽然昇腾910C支持原生PyTorch接口，但底层依赖CANN异构计算架构。据鲲鹏昇腾开发者社区2026年5月的实测数据，直接通过torch_npu迁移时，约15%-20%的自定义算子需要重新编译。
DeepSeek V4-Pro采用的混合精度训练（FP8和BF16切换）在NPU上需要特殊处理。团队没有盲目追求100%兼容，而是采取了两步走策略：
- 算子扫描与替换：使用
Ascend Profiling Tool扫描原代码算子分布。对于CANN不支持的复杂Attention Mask等逻辑，提前准备C++ Native算子或寻找替代方案。 - 环境隔离与版本匹配：2026年最新的CANN 8.0.RC3对MoE（混合专家）路由算子有显著优化。团队严格使用官方Docker镜像，避免依赖冲突，确保MoE路由的高效执行。
通信：千卡集群的"拥堵治理"
1000张卡的训练中，通信开销往往占据大头。昇腾910C通过HCCS互联，单链路带宽40GB/s，但若拓扑配置不当，带宽优势无法发挥。
深圳河套学院的实战数据显示，初始部署因节点通信链路未对齐，MFU一度跌至20%以下。后续通过调整HCCL（Huawei Collective Communication Library）通信拓扑，将同一机柜内的卡划分为独立通信组，最大限度减少跨机柜通信，MFU才回升至30%。
此外，针对MoE结构导致的梯度稀疏问题，团队采用了异步梯度同步策略。实测表明，将异步参数设置为0.8（即20%频率同步），在收敛速度与通信开销之间取得了最佳平衡。同时，在节点间RoCEv2网络上启用ECN（显式拥塞通知），有效减少了丢包重传。
显存：长序列的"碎片战"
1M Token的上下文长度让KV Cache显存占用呈指数级增长。昇腾910C单卡32GB显存，在1.6万亿参数分片下压力巨大。训练初期，动态Shape的频繁变化导致NPU显存碎片化严重，甚至引发OOM。
解决思路聚焦于"确定性"与"复用"：
- 静态Shape预热：正式训练前，使用Dummy Data进行多次Forward/Backward预热，固定计算图Shape，减少动态内存分配。
- 梯度检查点：启用CANN显存复用机制，对中间激活值进行梯度检查点存储。实测显示，此举可降低约30%的显存占用，以少量计算时间为代价换取空间。
- 定期碎片整理：华为官方建议每100个Step执行一次轻量级碎片清理，防止长周期训练中的累积效应。
运维：透明化监控
千卡集群的稳定性依赖于对数据的掌控。团队建立了实时硬件健康监测，任何一颗卡的温度波动或ECC错误都会触发自动隔离和任务迁移，这也是将故障率控制在0.3‰的关键。
此外，MFU超过30%被视为一个重要里程碑，标志着计算与通信重叠做得较好。通过将1000个节点的日志汇聚至中央存储，并利用算法分析日志模式，团队能够提前预测潜在硬件故障，变"被动维修"为"主动预防"。
这次突破，证明国产算力在处理万亿参数大模型全参数训练时，已具备工程落地能力。从"能用"到"好用"，中间隔着无数细节的打磨。对于正在构建国产算力集群的团队而言，昇腾910C的这套实战经验，提供了可参考的"硬解法"。
