把1000颗昇腾910C跑起来，和让万卡集群连续稳定训练，是两件事。
据公开页面转述，深圳河套学院、哈尔滨工业大学（深圳）、深圳市大数据研究院及华为有关团队，使用1000颗昇腾910C完成了1.6万亿参数DeepSeek-V4-Pro的全参数后训练。页面披露的指标包括：算力利用率（MFU）稳定超过30%，关键训练算子效率提升14%，连续1500余步未中断或报错，故障率为0.3‰。
另一篇观察者网页面将相关消息标注为2026年6月5日，并提到这类任务对硬件算力、集群稳定性、算法适配和负载均衡都有严格要求。这些数字能说明千卡级任务已经跑通，但公开摘要没有给出完整测试配置，算子效率提升的对照基线也未展开。
规模继续放大后，通信参与者、拓扑层级和故障域都会增加。千卡结果回答了“能不能跑”，回答不了“万卡每一步慢在哪里、显存为什么持续上涨、故障后能否顺利恢复”。
别拿单卡参数替代HCCL压测
腾讯云文章列出的昇腾910C参数为：FP16算力800 TFLOPS、96GB HBM、1.8TB/s显存带宽、400GB/s HCCS，MFU约30%。同文列出的H100参数为FP16算力1979 TFLOPS、80GB HBM和3.35TB/s显存带宽。
这些参数能说明资源边界，不能直接代表分布式训练效率。还要分清HCCS和HCCL：前者是互联能力参数，后者是集合通信软件。把400GB/s直接视为AllReduce的可用带宽，会高估实际训练表现。
目前可引用的材料没有给出同模型、同并行策略、可比网络条件和同节点规模下的HCCL与NCCL对照。缺少这些前提，简单判断谁快多少没有意义。真正值得测的是三件事：
- 单机内、跨机和跨机架分别运行AllReduce、AllGather、ReduceScatter，记录有效带宽和尾部延迟；
- 在计划采用的数据并行、张量并行和流水线并行组合上运行完整训练step，看计算是否在等待通信；
- 固定模型、批大小、序列长度、进程绑定和CANN版本，每次只调整一个变量，否则profile很难解释。
如果使用PyTorch FSDP，还要把ReduceScatter和AllGather拆开观察。微基准很快，但完整训练step仍然变慢，问题可能出在通信与计算没有重叠，也可能是进程放置和并行切分不匹配。
华为在2025年全联接大会演讲中，把超节点互联作为AI基础设施的新方向。演讲还提到，相关团队从春节持续工作到4月30日，使Ascend 910B、910C的推理能力达到客户基本需求。这说明软硬件仍在快速迭代，但发布会上的技术路线不能替代现有集群的通信基线。已经部署的设备，仍要围绕当前拓扑、CANN版本和HCCL配置做实测。
96GB HBM，也可能卡在分配方式上
96GB显存容量不小，但容量只是显存问题的一部分。按照上述参数，910C的显存带宽为1.8TB/s，H100为3.35TB/s。长上下文任务中，张量生命周期、临时缓冲区和分配频率，都会影响这96GB能否被有效利用。
还需要把训练和推理分开。KV Cache主要是推理侧开销；在全参数训练中，长上下文更直接地推高激活、注意力中间结果和通信临时缓冲区。把两类问题混在一起，OOM定位很容易走偏。
遇到OOM，先区分几种情况：
- 模型参数、优化器状态和激活的真实峰值已经超过容量；
- 频繁申请、释放不同尺寸张量后，剩余显存无法组成足够大的连续空间；
- 集合通信在特定step申请临时缓冲区，短时间抬高峰值；
- 显存基线随训练step持续上升，存在张量未释放或缓存策略不合适的问题。
可执行的优化应从分配行为入手：
- 尽量固定张量形状，对不同序列长度分桶，减少尺寸频繁变化；
- 完成预热后复用显存块。当前CANN版本若提供可用的内存池接口，应先在目标负载上验证；
- 分开统计模型参数、优化器状态、激活和通信缓冲区，不要只看一条总占用曲线；
expandable_segments是否在当前PyTorch与昇腾后端组合中有效，要以回归测试为准，不能直接照搬CUDA侧配置；- 在固定间隔记录已分配、已保留和峰值显存，确认基线是否随着step推进不断抬升。
对CANN 8.0.RC系列也应采用同样原则。RC版本变化快，异步通信、内存池或碎片整理能力是否可用，应以对应发布日志和本机测试为准。没有同一负载下的前后对照，不要把版本升级直接写成固定收益。
万卡开训前，先留下一套可复现基线
- 拓扑基线：记录卡、服务器、机架和交换网络的对应关系，并保存进程绑定方式。出现慢节点时，先确认它位于哪一层通信路径。
- 通信基线：按不同集合通信操作和消息大小测试，保留有效带宽、平均延迟和尾部延迟。拓扑或版本变化后重新运行。
- 模型基线：使用正式训练计划中的并行切分跑完整step，不要只依赖通信微基准。
- 显存基线：让典型负载持续运行到显存曲线趋于稳定，同时验证保存与加载检查点后的占用是否回到同一水平。
- 恢复基线：验证任务重启、检查点恢复和异常节点处理流程。万卡集群不能只看无故障时的吞吐。
- 版本基线：记录CANN、驱动、框架、固件和HCCL配置。升级时只改变一个变量，并保留可回滚版本。
市场材料已经把话题推到“十万卡”。《探索昇腾910C 十万卡集群》的可见摘要回顾了2019年首代昇腾910的1+1+4架构和456平方毫米计算带，也提到2023年的后续架构，但没有提供可复核的万卡HCCL测试条件。
这恰好说明，规模越大，越不能用参数表和版本宣传替代现场数据。千卡案例是入场券，不是万卡验收单。先测通信，再看显存曲线，最后验证故障恢复；这些基线能够复现，才适合继续谈HCCL调优和并行切分。
