阿里云 SkeletonHunter：诊断与定位大模型训练中的网络故障

一、背景

网络互联是大规模集群不可或缺的一部分，也是大规模模型训练中影响任务稳定性和效率的关键因素，然而网络相关问题的诊断和修复又是个老大难问题。本文我们介绍清华大学和阿里的 SkeletonHunter 系统，其提供了一个不错的思路。

对应的论文为：SkeletonHunter: Diagnosing and Localizing Network Failures in Containerized Large Model Training [1]

相关工作可以参考我们之前的文章：

• LLaMA 3 背后的大规模 GPU 集群 RoCE 网络建设
• HPN 7.0：阿里云新一代万卡集群网络架构
• 万卡 GPU 集群互联：硬件配置和网络设计
• 大规模 GPU 集群运维实践：假装万卡 GPU 集群经验
• Meta 万卡 GPU 集群稳定性剖析与最佳实践

二、摘要

灵活性和可移植性使得容器技术成为近年来大规模模型训练备受青睐的基础设施。然而，这些优势也会面临诸多挑战，比如容器的高动态性、Underlay（物理网络）和 Overlay（虚拟网络） 网络的复杂交互作用，以及故障检测与定位的高要求。现在的数据中心调试工具依赖全面性或机会性的监测，在此场景下效率较低，并且准确度不足。

本文中，作者提出 SkeletonHunter —— 一种容器网络监控诊断系统，其利用大模型训练产生的网络流量的固有且规律的稀疏特征，采用 Traffic Skeleton 机制（持续追踪训练流量传输的关键网络路径集合），从而实现快速可靠的网络故障检测和定位。

该系统在生产环境部署 6 个月，成功检测到 4816 次网络故障，准确率 98.2%，召回率 99.3%，并以 95.7% 的高精度完成故障定位。在修复 98% 的问题网络组件后，月均故障率显著下降 99.1%。

三、引言

3.1 大模型训练的网络需求

大模型训练对网络有极高的要求，比如：

• 低时延：RoCE 网络 RTT 需要低于 20μs。
• 高同步性：训练任务高度同步，10μs 的 RTT 增加就可能导致 20% 的性能下降（Alibaba HPN: A Data Center Network for Large Language Model Training [2]）。
• 零丢包：任何丢包或时延抖动都有可能导致训练任务同步失败。

3.2 容器化的挑战

根据作者经验，在大规模容器化模型训练 Infra 中准确及时地定位网络问题，会面临 3 大挑战：

高动态性：如下图所示，容器生命周期短，超过 50% 容器的生命周期小于 60 分钟，并且状态变化频繁。

端点（Endpoint）复杂：如下图所示，每个容器可绑定多个 RNIC（RDMA NIC，如 8 个），形成复杂端点拓扑。

Overlay/Underlay 交织：多租户隔离引入虚拟网络层，导致故障定位困难。如下图 Figure 6 所示为生产环境中每台机器上 Flow Table 数量的分布情况，每台机器平均 Flow Table 数量超过 40 条，最大达到 9355 条。实际上这只是网络协议栈中虚拟组件的一种。

除此之外，容器化网络会对网络故障的排查难度产生倍增效应。假设某个训练任务涉及 X 个容器，每个容器平均绑定 Y 张 NIC，而每个 NIC 平均关联 Z 个虚拟网络组件，那么每个训练 Step（通常几十秒），需要探测 X*Y*Z（比如 1K * 8 * 16 = 128K）个网络组件，成本非常高。

这些挑战使得传统的网络监控手段（如 Pingmesh）在容器化大模型训练场景中效率低、准确性差。

3.3 核心洞察

尽管容器网络复杂，但大模型训练的网络流量具有以下两个关键特征：

空间稀疏性（Spatial Sparsity）：训练任务通常会采用 DP、TP、PP 等分布式策略，每个 GPU/NIC 只与特定组内的其他 GPU/NIC 通信。因此，实际通信路径远小于全互联拓扑，形成稀疏但规则的 “Traffic Pattern”。

如下图 Figure 8 所示为 512 GPU 的 Dense 模型训练，TP=8、PP=8、DP=8。机内 8 个 GPU 通过 NVLink + NVSwitch 实现高速互联，可以将 TP 放在机内。每个 GPU 对应一个 RDMA NIC，通过轨道优化的网络互联（如下图 Figure 10 所示）。

如下图 Figure 9a 展示了上述训练任务中各 NIC 间对应的流量矩阵，该矩阵呈现出高度稀疏性。这一特性提供了高效监控网络连接状态的可能性——只需聚焦于实际存在连接的 <源，目的> 节点对（而非所有节点对）。除 Dense 模型外，MoE 模型会引入 EP 并行策略。如下图 Figure 9b 所示，EP 可能产生不同的流量模式，但其空间分布稀疏性特征依然成立。

时间周期性（Temporal Burstiness）：训练是迭代式的，每 Step 迭代结束时会有参数同步（如 AllReduce），引发周期性流量突发。这些突发流量在 NIC 上表现为周期性的吞吐量峰值。如下图 Figure 7 所示：

四、SkeletonHunter 系统设计与实现

4.1 系统架构

SkeletonHunter 的核心思路是通过推断训练任务的 “Traffic Skeleton”，只监控真正可能通信的路径，从而大幅降低监控开销并提升故障定位精度。如下图 Figure 11 所示，其包含 3 个关键组件：

• Traffic Skeleton Inference
• Connectivity Anomaly Detection
• Optimistic Overlay-Underlay Disentanglement

4.2 流量模式推断（Traffic Skeleton Inference）

Traffic Skeleton Inference 的目标是：在不感知用户模型结构的前提下，仅凭 NIC 上的吞吐量规律，反推出训练任务实际通信的 “Traffic Skeleton”，从而把探测矩阵压缩 95% 以上。整个过程分 为三步：Preload → Initialization → Runtime，依次在控制面和数据面进行。

4.2.1 Preload：Basic Ping List 生成

如上图 Figure 10，集群采用轨道优化拓扑：每个机器 8 个 GPU，对应 8 个 NIC，同号 GPU 对应的 NIC 连接在同一个 ToR Switch 下。

NCCL 会自动将跨 Rail 流量转换为 “节点内 GPU 通过 NVLink 通信 + 节点间 Rail 通信（PXN）”，因此跨 Rail 网络路径永远不会被使用。因此 SkeletonHunter 可以在任务启动前将跨 Rail 连接删除，生成 Basic Ping List，对于常见 8-Rail 集群，探测项可以降低到 1/8。

4.2.2 Initialization：增加 Ping List 激活

容器启动时间差异较大，如果立即探测，会把还没有 Ready 的容器判断为网络不可达。为了避免这个问题，SkeletonHunter 的 Controller 将 Ping List 激活下放到数据面容器。

具体来说，当容器创建时，其 Agent 首先从 Controller 获取 Basic Ping List，但暂不启动实际的连通性探测，知道其他容器完成注册并激活已经创建容器中记录的对应 Ping 目标。通过这种方式，可以有效避免容器初始化阶段的误报。

4.2.3 Runtime：基于推断的 Traffic Skeleton 优化

此优化基于以下关键洞察：

• 并行组内 GPU 执行完全相同的计算图，只是输入数据不同 → NIC 流量突发周期在时域上几乎重合。
• 不同并行组的突发在相位上存在固定滑移（Pipeline Parallelism 引入）。
• 实际通信只发生在同一并行组内部，因此 95% 以上的 <源, 目标> 对永远无流量。

Traffic Skeleton 推断的具体流程如下所示：

提取容器 NIC 吞吐量突发周期的频域特征：具体来说，使用 STFT（短时傅里叶变换）将时域吞吐量突发周期转换到频域。（PS：也试过小波变换和离散傅里叶变换，不过 STFT 计算复杂度最低），如下图 Figure 13 所示，经转换，A 与 B 具有相似特征，C 与 D 具有另外的相似特征，表明 A/B，C/D 分别在不同数据平面的相同拓扑位置。

聚类：对提取的 STFT 特征进行层次聚类，通过度量 NIC 流量突发 STFT 特征的相似性进行分组。

约束推导：进一步对分组过程施加以下约束条件，根据训练任务分配的 GPU 数量，使分组结果更具可解释性。其中 k 表示训练任务中 NIC 组的总数；ci 表示第 i 个组，[c-] 表示各组 NIC 数量平均值取最接近整数；N 是 NIC 的总数，ri 表示机器 Hr 中的第 i 个 NIC。

• 公式（1）：最小化各组间 NIC 数量方差 → 保障各 DP 组规模一致。
• 公式（2）：总 NIC 数 N 必须能被 k 整除 → 符合 N 是 DP 组的整数倍。
• 公式（3）：同一物理机上的 NIC 不能分在同一组 → DP 通常不会分在机内。

上述过程有助于推断出 DP 组，其值等同于 [c-]。接下来基于 TP x PP = N / [c-] 推断出 TP 和 PP 配置。利用吞吐量突增周期的时间偏移特性，可以进一步区分不同的 PP Stage。比如，第一个 PP Stage 1 相比 PP Stage 2 更早经历相同的流量突增。最后可以推断出任务的并行策略，并确定每个任务的 Traffic Skeleton。MoE 模型的 EP 也可以采用类似方式探测。

经过一系列手段，SkeletonHunter 将 Ping List 进一步缩减 95% 以上。如下图 Figure 15 和 Figure 16 所示，探测目标和成本相比 Full Mesh 都大幅下降，比如 512 GPU，Full Mesh 需要探测 560s，SkeletonHunter-Basic 需要 64.85s，而最终 SkeletonHunter 只需要 8.23s：

4.3 异常检测（Anomaly Detection）

高丢包率可明确归因于网络问题，但突发的高时延可能因为瞬时拥塞或网络资源竞争，需要通过数据分析来过滤这些瞬时时延突增。为此，作者核心思路是采用最先进的序列分析技术，以评估通信模式是否随时间发生变化。

具体而言，SkeletonHunter 的 Analyzer 会聚合采集数据，并通过统计检验进行短期与长期时延异常检测，其理论基础是大数定律。

短周期异常检测：以每 30s 为粒度进行短期分析，通过 25 分位、中位数、75 分位、最小值、均值、标准差和最大值来描述时延分布。随后，基于局部离群因子（LOF）对每个时间窗口的时延分布进行异常检测。并设置回溯 5 分钟作为参考值，若新的 5 分钟窗口具有较高的 LOF 值且无法与先前窗口聚类，则判断出现异常。

长周期异常检测：以每 30 分钟聚合并分析时延数据。旨在检测网络性能的渐进式退化（通常在短周期检测中很难发现）。由于长期分析可收集海量时延数据，因此采用统计检验方法检测时延异常，长期运行正常的两种 NIC 的时延数据始终遵循对数正态分布。如下图 Figure 14 所示，在时间 T 内对每个 <源、目标> NIC 对的时延数据进行参数估计，并推导出估计的对数正态分布，以验证数据是否遵循估计的对数正态分布。图中所示，T+0.5 小时的时延数据仍符合估计分布，而 T+1 小时和 T+1.5 小时的数据则偏离了估计分布。因此，T+1 小时和 T+1.5 小时判定为时延异常。

4.4 故障定位（Optimistic Overlay-Underlay Disentanglement）

在检测到高丢包率或时延异常后，SkeletonHunter 仅能确定两个容器间存在网络问题，但无法精确定位导致该问题的具体网络组件。为此，作者基于“Overlay 和 Underlay 的根因分布属于软件和硬件问题，且不会相互传导”的假设进行问题定位。

如下图 Algorithm 1 所示，该机制首先将容器间的传输路径分为独立的 Underlay 和 Overlay 链路（1-6 行），随后分别通过 Overlay 逻辑可达性分析（7-15）和 Underlay 交集分析（16-21 行）实现双层级故障定位。

Overlay 网络故障：SkeletonHunter Analyzer 通过中继数据转发过程，系统验证数据包是否正确转发到目的地或是否存在循环路由。当检测到不可达时，可在断点处精确定位故障 Overlay 链路。若数据包被转发至已经访问过的组件，则判断转发规则存在错误，形成路由循环。

物理网络故障：SkeletonHunter 采用网络扫描技术对可能发生故障的物理链路进行投票筛选。此外，每个物理机部署 Agent 程序，通过 Traceroute 探测实现底层路径分析，与 R-Pingmesh 和007 类似。

验证 NIC：进一步验证 NIC，此过程涉及人工操作。物理机 Agent 将卸载至 NIC 的 OVS Flow Table 进行转存，初步检测网络间的配置一致性，但可能导致临时性的网络性能下降，但对确保网络配置正确性至关重要。若未检测到不一致情况，则需人工核查 NIC 与 OVS 的配置以定位故障。

通过上述方式，SkeletonHunter 能有效定位 Overlay 与 Underlay 网络故障，并将其分类归因于物理交换机、NIC 网卡、虚拟交换机或主机配置等问题。

实际上，作者也曾遇到 Overlay 和 Underlay 同时出现问题的案例。例如，底层 NIC 的异常行为可能导致 Overlay 虚拟交换机配置错误，进而加剧网络故障。此类情况下只能依靠领域知识与经验进行人工干预。

五、关键结果 & 局限性

在 4K 个物理节点的生产集群部署，每个节点 8 个 RDMA NIC（200 Gbps 或 400 Gbps），128 Core，2TB 内存。每个 NIC 都运行在 SR-IOV 模式，包含 128 个 VF（Virtual Function）。从 2024 年 3 月到 8 月，共 6+ 月，涉及 2M+ 任务。

5.1 关键结果

如下图 Table 1 所示总结了 SkeletonHunter 检测到的代表性网络问题，所有问题可以归纳为 19 种不同类型，主要涉及模型训练的 6 个核心组件：

• 物理交换机
• NIC 网卡
• 主机板卡
• 虚拟交换机
• 容器运行时
• 配置项

链路/交换机异常：针对主机间网络出现的问题（问题 1-4），SkeletonHunter 能筛选所有异常探测结果，并采用网络扫描技术精准定位故障设备。大多数链路/交换机异常可通过对应交换机的告警日志即时验证，从而快速确定根本原因。

主机相关异常：实践经验表明（问题 5-13），多种因素可能导致主机侧异常。出现时立即隔离故障主机/模块以消除其对模型训练的影响。如下图 Figure 18 所示，展示了一个生成环境遇到的典型案例。90s 前，两个容器 NIC 之间的时延稳定在 16us 左右；90s 后，时延上升到 120us 左右，Ping 数据包出现轻微丢包（< 0.1%）。

• 通过统计校验，SkeletonHunter 判定该时延存在异常。
• SkeletonHunter 最初并未发现 Overlay/Underlay 网络问题，因此转存了 NIC Flow Table。
• 随后检测到 Overlay 虚拟化 Flow Table 存在不一致性，立即隔离了该 NIC。
• 60s 后 NIC 恢复正常，所有指标回归常态。
• 深入分析发现，该问题源于 NIC 未能及时更新流计数器，致使控制平面将数据流判定为非活跃状态并从 NIC 中移除，导致相关数据包转由软件栈处理从而产生显著更高延迟。

虚拟交换机/容器异常。软件组件（如虚拟交换机、容器及其相关配置）也可能成为可靠性问题的根源（问题 14-19），不过通过重启或重新初始化相应软件组件即可快速解决此类问题。SkeletonHunter 通过这种方式将通常需要数小时的完整测试压缩至分钟级，直接执行恢复流程，显著降低了运维成本。

5.2 局限性

5.2.1 用户负载不确定性

SkeletonHunter 设计的核心假设是：大模型训练流量具有稀疏且规则的空间分布和周期性突增的时间模式。但这一假设并非对所有用户负载都成立，比如：

• 调试或测试任务：用户只是调试模型或者调试集合通信库，可能导致 SkeletonHunter 的推断错误。
• 非标准并行策略：EP、多模态训练、异步训练等，可能打破原有稀疏性模式，导致探测矩阵过大或失败。
• 未来模型演进：可能引入未知的并行模式，导致 SkeletonHunter 无法识别，适用性不足。

5.2.2 误报 & 漏报

SkeletonHunter 还无法覆盖 GPU 之间及 GPU 和 PCIe 间的连接问题 —— 这类问题与网络无关，属于硬件层面，只能通过其他硬件监控工具进行检测（比如 DCGM 或 dmesg 日志）。

此外，SkeletonHunter 自身的问题也可能导致误报，为了精确测量端到端时延，SkeletonHunter 采用精密时间协议消除时钟漂移，这要求 Agent 及时响应探测请求，但实践中多次遇到 Agent 程序崩溃导致无法响应探测的情况，致使 SkeletonHunter 错误地将对应链路判断为故障并出发报警。

5.2.3 乐观假设的局限性

SkeletonHunter 使用 “乐观解耦” 策略：假设 Overlay（软件）和 Underlay（硬件）故障不会同时发生，也不会互相影响。但作者也提到，现实中它们是可能同时出现的，这类问题只能人工排查。

5.2.4 探测机制的局限性

利用 Ping 进行连通性测试，可能无法暴露某些真实通信路径的问题。不过 Ping 探测也确实在监控开销与监控精度之间得到平衡。

5.2.5 部署与演化成本

SkeletonHunter 依赖 Sidecar 容器部署 Agent，会带来一定的开销，好处是实现了 Agent 部署更新与训练任务更新的解耦。

除此之外，由于大规模模型训练场景的快速发展，基础设施（如 GPU、NIC 及数据中心拓扑结构）与训练模型也会持续迭代，这也要求 SkeletonHunter 系统必须不断升级，作者声称完成了 20+ 次的更新，相应的维护成本也会比较大。

六、参考链接

1. ​​https://ennanzhai.github.io/pub/sigcomm25-skeletonhunter.pdf​​
2. ​​https://ennanzhai.github.io/pub/sigcomm24-hpn.pdf​​

本文转载自​​AI闲谈​​，作者：AI闲谈