AI 纪元 追踪人工智能最新进展,深度解读前沿技术

11520张昇腾910C并行,训练抖动先查哪条链路

11520张昇腾910C接入同一集群后,单个慢节点、端口错误或集合通信阻塞,都可能把等待扩散到整个任务。排查要把训练时间线、HCCL算子和交换机端口指标对齐,再决定是否调整通信算法、超时策略和任务编排。

0 次阅读 约 2267 字 5 分钟 AI 生成
Macro shot of fiber optic cables in a data center with one point highlighted in amber light.
Macro shot of fiber optic cables in a data center with one point highlighted in amber light.

粤港澳大湾区发布的国产智算集群配置了11520张华为昇腾910C。公开资料显示,网络侧采用自研高速互联架构,100T交换机配合极简二层组网,并依托韶广深100T空芯光纤干线。

卡数过万后,通信链路会直接影响整套集群的实际吞吐。训练抖动也很少明明白白地显示为“网络故障”。更常见的表现是单步耗时突然拉长、HCCL集合通信出现拖尾,设备完成计算后停在同步点等待;严重时,任务会因超时而中断。

万卡同步会放大局部延迟。某个rank慢下来,其他rank也要等待本轮集合通信结束。问题可能只出在一个节点或一条链路上,最终看到的却是整个任务掉速。

先把三条时间线对上

设备平均利用率只能看到表象。真正有用的是把训练、通信和网络指标放在同一时间轴上。

  • 训练时间线:记录单步耗时和设备利用率,找出抖动开始、恢复以及重复出现的时间点。不要只看长周期平均值,否则短时毛刺很容易被摊平。
  • 通信时间线:通过MindSpore Profiler等工具查看算子耗时,重点观察AllReduce、AllGather、All-to-All等集合通信。除了总耗时,还要比较各rank的结束时间,确认拖尾是否集中在固定设备。
  • 网络时间线:通过SNMP或交换机提供的API,采集对应端口的CRC错误、丢包和缓冲区溢出计数,再与训练抖动的时间点核对。

三组数据对齐后,排查范围会迅速收窄。同一rank反复拖尾,且对应端口的错误计数同步增加,应优先检查节点和链路健康状态;拖尾rank不断变化,但总在某类集合通信中出现,则要检查通信模式、rank映射和算法选择;如果HCCL耗时没有明显变化,问题还可能来自数据加载、主机调度或计算不均衡。

极简二层压低时延,任务仍可能制造热点

100T交换机和极简二层组网减少了网络层级,也为万卡并行提供了更高的通信基础。不过,AllReduce、AllGather和All-to-All的流量形态并不相同。rank分布与任务通信模式不匹配时,流量仍可能集中到部分端口。

多个大任务共用物理网络时,这个问题更明显。如果任务同时启动,或者通信密集阶段重叠,局部队列和链路压力会一起上升。调参数之前,先确认任务被分配到了哪些节点、rank如何排列,以及通信流量经过哪些端口。

《华为研究》在讨论AI网络时,将集群线性度、可用度与带宽、时延、规模、网络可用度联系起来,并涉及传输层、网络均衡、集合通信和网络拓扑等议题。对应用团队来说,算子时间线和物理网络需要一起看,最好建立清晰的“rank—节点—端口”映射。

改HCCL参数前,先留一份基线

HCCL参数可以改善特定场景下的表现,也可能暂时掩盖故障。每次只改一个变量,并保留相同模型、批次配置和rank映射下的对照结果。

通信算法

HCCL会结合消息规模和网络环境选择集合通信算法。如果当前版本支持通过HCCL_ALGO指定算法,可以对ring、tree等方案做受控测试。判断依据应包括端到端单步耗时和通信拖尾,不能只看一次带宽测试。不同消息规模和拓扑下,算法表现可能不同,没有一项设置适合所有任务。

超时与重试

适当放宽超时设置,可以避免偶发抖动立即终止任务,但它不会消除拥塞或降低通信时延。超时设得过长,还会延迟真正故障的暴露和恢复。参数名称、默认值及支持范围应以集群所安装的HCCL版本文档为准,不宜直接照搬其他环境的秒数。

计算与通信重叠

无论使用MindSpore还是PyTorch训练栈,打开相关配置都不等于重叠已经生效。Profiler时间线应能看到计算算子与通信阶段实际交叠。如果两者依然串行,需要继续检查计算图依赖和任务调度,而不是反复调整超时。

编排和断点续训,决定一次故障要付出多少代价

同一物理网络中,尽量避免多个大规模任务同时启动。调度系统可以设置资源隔离和启动间隔,减少通信峰值重叠。空闲时段则可使用HCCL通信基准工具扫描机内、机间带宽与时延,建立稳定基线。某个节点持续偏离基线时,应先隔离,再检查网卡、光模块和链路。

鲲鹏昇腾开发者社区发布的《万卡集群训练任务挂了?别慌,这本秘籍帮你解决!》将故障检测和缩短故障恢复时间MTTR列为大规模集群可用度的重要问题,并介绍了昇腾断点续训的检测与恢复能力。

断点续训不能修复网络拥塞,它的价值是缩小回滚范围。长周期训练应保留可恢复的检查点。任务中断后,先隔离异常节点或链路,再从最近检查点恢复,通常比原地反复重试更可控。

一套更稳妥的排查顺序

  • 截取一次完整的抖动时间窗,保留单步耗时和设备利用率。
  • 用Profiler确认是否由HCCL通信拉长,并找出拖尾rank。
  • 将rank映射到具体节点和交换机端口,核对同一时刻的错误与丢包计数。
  • 使用通信基准测试复现,区分持续性链路退化和任务流量热点。
  • 保持其他条件不变,每轮只调整一个HCCL参数或一项rank编排策略。
  • 故障风险较高时,先隔离异常资源并恢复训练,再继续做性能调优。

调优是否有效,应使用同一口径的单步耗时、任务吞吐、HCCL耗时占比和中断恢复情况判断。某段设备利用率升高,只能作为辅助信号。

11520张昇腾910C把局部链路问题放大得更快。100T交换机和极简二层组网打好了通信基础,上层任务仍要把每次抖动定位到具体rank、集合通信和网络端口。先对齐三条时间线,再动参数,排查会比盲目增加超时更有效。

参考资料

相关阅读