昇腾910C千卡训练，通信瓶颈该怎么查
1000颗昇腾910C、1.6万亿参数模型、1500余步训练无中断——一则公开报道披露了这组训练结果：模型算力利用率（MFU）稳定超过30%，关键训练算子效率提升14%，故障率为0.3‰。
这些数字真正值得关注的，不只是集群规模，而是训练能否持续跑稳。卡数从几十扩到数百乃至上千后，单卡算力不再是唯一变量。梯度同步、跨节点传输、网络拥塞和故障恢复，都会直接拉长每一步训练的时间。
对使用昇腾910C和HCCL的开发者来说，排查通信问题可以先抓住四件事：物理拓扑是否清楚，集合通信是否匹配拓扑，通信能否被计算覆盖，以及扩卡后是否仍然稳定。
先分清：慢在计算，还是卡在通信
训练变慢时，最容易犯的错误是直接改通信参数。更稳妥的做法，是先拆开一个训练 step：前向计算用了多久，反向计算用了多久，AllReduce、AllGather等集合通信又占了多久。
如果单卡和小规模多卡运行正常，扩卡后step时间明显拉长，问题通常不在算子本身，而在跨卡同步。此时应重点查看三个现象：
- 通信算子耗时是否随卡数快速增加；
- 不同rank的等待时间是否差异明显；
- 通信与反向计算是否串行执行。
最后一项很关键。通信带宽即使没有跑满，只要大部分传输能藏在反向计算期间，对整体吞吐的影响也可能有限。反过来，如果所有梯度都等反向计算结束后再统一同步，网络空闲与计算空闲会交替出现，卡数越多，损失越明显。
CANN工具链提供性能分析能力。使用Profiler时，不要只盯着某个算子的绝对耗时，更要看时间线：通信什么时候开始、持续多久、是否与计算重叠，以及哪个rank最晚结束。
HCCL不是把NCCL接口换个名字
熟悉NVIDIA集群的团队，往往会沿用NCCL时代的配置经验。但换到昇腾后，真正需要重新确认的是硬件连接和通信路径，而不是先寻找一组“万能参数”。
昇腾社区列出的集群产品包括Atlas 900 A3 SuperPoD超节点和Atlas 900 A2 PoD集群基础单元。华为在2025年全联接大会上也把“超节点互联”作为AI基础设施的重点方向。对训练任务而言，这意味着节点内与节点间不是同一种通信环境，集合通信必须认识这种层级差异。
排查时可以先画一张最朴素的连接图：
- 每个节点有多少张卡；
- 卡与卡之间通过什么链路连接；
- 哪些流量留在节点内；
- 哪些流量必须经过跨节点网络；
- 每个rank实际绑定了哪张网卡。
这张图不需要漂亮，但必须和机器上的真实连接一致。很多所谓的HCCL性能问题，最后并不是算法失效，而是rank、设备和网卡没有正确对应：部分链路被闲置，另一些链路却持续拥塞。
hccn_tool可用于检查链路状态。检查时不要只看接口是否为“up”，还要逐卡核对设备IP和网卡绑定关系。只验证一张卡，无法代表整台机器，更不能代表整个集群。
拓扑配置先求准确，再谈参数优化
大规模训练中的拓扑配置，本质上是在告诉通信库：数据从哪里出发，经过哪条链路，到达哪个rank。
配置完成后，至少要做两类验证。
第一类是连通性验证。确认每个rank都能找到对应设备，节点内和跨节点链路均可用，没有IP重复、网卡索引错位或进程绑定错误。
第二类是集合通信压测。不要一开始就用完整模型试错，可以先单独运行AllReduce等通信任务，对比不同消息大小、节点数量和rank组合下的耗时。这样更容易判断问题来自网络，还是来自模型执行图。
压测结果也不能只看峰值。训练任务会反复执行通信操作，更重要的是耗时是否稳定。如果同一规模、同一消息大小的结果频繁抖动，应先检查链路拥塞、进程绑定和节点差异，再调整训练策略。
梯度同步不能只追求“少通信”
减少同步次数，确实可以降低通信开销。梯度累积就是常见做法：先执行多个微批次，再进行参数更新和梯度同步。
但它不是免费的性能开关。累积步数改变后，有效batch size也会变化，学习率和收敛表现可能随之改变。如果只看到step吞吐提高，却没有检查训练目标是否保持一致，最终得到的对比并不可靠。
同步策略的选择可以按任务要求收窄：
- 对收敛稳定性要求高的任务，先保留同步训练，再优化通信重叠；
- 显存允许时，可评估梯度累积，但要同步检查有效batch size；
- 如果通信集中在反向传播末尾，应优先调整梯度桶和调度顺序，让已完成计算的梯度尽早进入AllReduce；
- 异步更新会引入梯度延迟，不宜只凭通信耗时下降就直接采用。
公开报道中的1.6万亿参数模型采用全参数后训练，并实现1500余步无中断。这组结果说明，在千卡规模下，稳定性本身就是性能的一部分。一次通信异常导致任务重启，损失往往大于几个百分点的单步提速。
Profiler要回答三个具体问题
性能分析工具生成的数据很多，但开发者真正需要回答的通常只有三个问题。
谁在等？
检查不同rank的通信开始和结束时间。如果多数rank很早进入AllReduce，只有少数rank迟迟未到，通信算子只是表现为瓶颈，根因可能是前面的计算负载不均。
数据走了哪条路？
结合设备、rank和网卡绑定信息，确认跨节点流量是否经过预期链路。如果某个网卡长期满载，而同节点其他链路利用不足，应先检查映射关系，而不是继续增加并发。
通信有没有藏进计算里？
查看时间线中通信操作和反向计算是否重叠。完全串行时，可以从梯度桶大小、算子调度顺序和集合通信触发时机入手。这里没有适用于所有模型的固定值，参数规模、网络结构和并行方式都会改变结果。
每次只改一个变量，并保留修改前后的时间线。否则即使吞吐提高，也很难知道究竟是哪项配置起了作用。
千卡之前，先把扩卡曲线跑出来
直接启动千卡任务，定位问题的成本很高。更实用的办法是逐级扩卡，在每个规模记录同一组指标：单步时间、通信耗时、计算通信重叠情况、rank间耗时差异，以及任务是否出现抖动或中断。
如果扩卡后吞吐没有按预期增长，就停在出现拐点的规模排查。这样能够把问题限制在新增节点、交换网络或进程映射范围内，而不是面对整个集群猜原因。
RL任务还要额外留意训练之外的数据传输。昇腾开发者论坛的交流材料提到，TransferDock是一种分布式数据通信加速队列，用于处理经验数据量大、传输频繁带来的卡顿，通过异步缓存和传输减轻数据通路压力。这类任务中，模型梯度并不是唯一流量，经验数据传输也可能与集合通信争用资源。
昇腾910C千卡训练的公开结果给出了一个可参考的工程锚点：1000颗芯片完成1.6万亿参数模型全参数后训练，MFU超过30%，关键训练算子效率提升14%，1500余步无中断。对普通开发团队来说，更值得复用的不是某个孤立参数，而是一套排查顺序：先确认拓扑，再做通信压测；先看时间线，再改同步策略；每扩一档规模，都验证一次稳定性。
