6月5日上午，深圳发布官方账号确认了一个消息：深圳河套学院AI训练平台项目团队，联合哈尔滨工业大学（深圳）、深圳市大数据研究院及华为有关团队，依托由1000颗华为昇腾910C芯片组成的国产AI算力集群，成功完成了1.6万亿参数大模型DeepSeek-V4-Pro的全参数后训练。
这不是实验室里的Demo。根据6月11日对外公布的详情，这次训练全程1500余步，无一次中断或报错，故障率仅0.3‰，模型算力利用率（MFU）稳定超过30%。对于DeepSeek-V4-Pro这样的万亿参数模型，全参数后训练意味着要同时调整1.6万亿个参数，这对硬件算力、集群稳定性和算法适配的要求极其严苛。
算力数据的真实落差
昇腾910C在纸面参数上并不占优。其FP16算力约为800 TFLOPS，仅为NVIDIA H100（1,979 TFLOPS）的40%。虽然HBM容量达到96 GB，略优于H100的80 GB，但显存带宽1.8 TB/s落后于H100的3.35 TB/s。在这样硬件约束下，能把千卡集群的MFU拉到30%以上，且保持极低故障率，核心在于通信链路的稳定。
华为昇腾910C采用HCCS（Huawei Cache Coherency System）进行 chip-to-chip 互联，单链路带宽达400 GB/s。在千卡规模下，任何微小的链路抖动都会放大成全局通信阻塞。运维人员面对的不再是单纯的算法公式，而是物理层面的“墙”。
排查HCCS链路：不看自动拓扑，看日志跳变
在实际运维中，HCCS链路异常是最常见的“软故障”。它往往不会直接导致停机，而是表现为MFU突然下降，或者梯度不同步。
有案例显示，某头部厂商在部署初期曾花费两周排查梯度不同步问题，最终发现是某机架内一根HCCS线缆接触不良，导致局部通信延迟增加15微秒，累积效应引发严重负载不均。
解决这类问题，不能依赖自动拓扑发现。启动训练前，必须进行物理层级的全链路校验。除了使用mscheck工具做基础健康检查外，手动解析hccl日志更为关键。
可以通过设置环境变量开启详细日志：
export HCCL_LOG_LEVEL=3
python train.py --device_num 1000
在生成的日志中，重点监控HCCS_LINK_STATUS字段。如果看到任何Rank的链路状态在训练中途发生跳变（例如从UP变为DOWN再恢复），这就是隐性的通信瓶颈。此时，应配合npusmi命令查看每个NPU的PCIe和HCCS带宽利用率，快速定位那个“掉队”的卡。
MindSpore梯度同步：区分OOM与超时
DeepSeek-V4-Pro采用的架构使得通信模式复杂化。在MindSpore框架下，运维中常遇到“梯度爆炸”与“通信超时”混淆的情况。
当发生显存溢出（OOM）时，初学者往往怀疑模型过大。但实际上，很多时候是因为梯度同步步骤耗时过长，触发了Watchdog超时机制，导致进程被强制Kill。这种误判会浪费大量调试时间。
针对千卡集群的通信拓扑优化，建议修改hccl.json配置文件，将同一机架内的卡映射为连续的Rank ID。这样可以最大化利用HCCS的高速互联，减少跨交换机的高延迟通信流量。
此外，长序列训练容易导致显存碎片化。监控npu-smi info -g all中的Used Memory与Free Memory差异，若碎片率过高，需考虑重启进程或引入显存整理机制，以避免因碎片导致的隐性性能衰减。
从“能用”到“好用”的工程验证
华为云AI研发团队曾在2025年全联接大会上提到，为了应对DeepSeek带来的流量增长，团队从春节开始日夜奋战，通过多团队协同，使Ascend 910B/910C的推理能力达成了客户需求。如今，千卡集群完成万亿参数模型的全参数训练，进一步证明了国产算力在大规模场景下的可用性。
这项成果由深圳河套学院、哈工大（深圳）、深圳市大数据研究院和华为共同完成，并协同深智城AI算力平台进行攻关。它表明，国产AI芯片已经跨过了实验室验证阶段，进入了工业级运行标准的行列。
对于开发者而言，昇腾910C可能不是单项性能最强的芯片，但在中国AI产业当前的供应链背景下，它是实现大规模训练的关键基础设施。运维的重点已从单一的参数调优，转向对HCCS物理链路、MindSpore通信机制以及自动化日志分析的立体管控。只有稳住这30%的MFU，才能让每一分算力转化为真正的模型智能。