论文基本信息 (Bibliographic Information)

• 标题 (Title): Evolution of Aegis: Fault Diagnosis for AI Model Training Service in Production (Aegis的演进：生产环境中AI模型训练服务的故障诊断)
• 作者 (Authors): Jianbo Dong*, Kun Qian*, Pengcheng Zhang*, Zhilong Zheng, Liang Chen, Fei Feng, Yichi Xu, Yikai Zhu, Gang Lu, Xue Li, Zhihui Ren, Zhicheng Wang, Bin Luo, Peng Zhang, Yang Liu, Yanqing Chen, Yu Guan, Weicheng Wang, Chaojie Yang, Yang Zhang, Man Yuan, Hanyu Zhao, Yong Li, Zihan Zhao, Shan Li, Xianlong Zeng, Zhiping Yao, Binzhang Fu, Ennan Zhai, Wei Lin, Chao Wang, Dennis Cai
• 隶属机构 (Affiliations): Alibaba Cloud (阿里巴巴云)
• 发表期刊/会议 (Journal/Conference): NSDI 2025 Fall (根据提供的链接 nsdi25fall-aegis.pdf 推断，应为USENIX Symposium on Networked Systems Design and Implementation 2025年秋季会议)
• 发表年份 (Publication Year): 2025 (根据会议推断，但论文内容涉及2023-2024年的生产数据，表明是近期工作)
• 摘要 (Abstract): Despite the success of diagnosis systems in traditional cloud computing, these systems are not suitable for pinpointing faults in AI model training cloud scenarios due to the differences in computing paradigms between traditional cloud computing and model training. As one of the largest cloud providers, we present Aegis, a fault diagnosis system specifically designed for AI model training service. We share our experience in the motivation, design, and evolution of Aegis. Keeping easy-to-deploy as the primary principle, Aegis Phase-1 started by enhancing existing general-purpose diagnosis systems. After several months of evolution, Aegis Phase-2 cogitatively customized the collective communication library for sophisticated failure localization in runtime without modifying customer code. Besides the failure localization, we further equipped Aegis with the capabilities on handling performance degradation and failure checking before delivery. Aegis has been deployed in our production training cloud service for one year. Aegis decreases more than $9 7 \%$ of the idle time wasted by diagnosis, $84 \%$ of the training task restart count, and $71 \%$ of the performance degradation.
• 原文链接 (Source Link): https://ennanzhai.github.io/pub/nsdi25fall-aegis.pdf （发布状态：预印本或会议录用稿，待正式发表）

整体概括 (Executive Summary)

研究背景与动机 (Background & Motivation - Why)

随着人工智能 (AI) 技术的飞速发展，大规模 AI 模型训练已成为云计算服务中的关键组成部分。然而，在生产环境中对 AI 模型训练服务进行故障诊断面临着独特的挑战。传统的云故障诊断系统在 AI 模型训练场景下表现不佳，主要原因在于：

1. 计算范式差异 (Computing Paradigm Differences): AI 模型训练（特别是大规模分布式训练）与传统云计算任务在计算模式上存在显著差异，例如高度依赖 集体通信 (collective communication)。
2. 硬件特点与故障率 (Hardware Characteristics & Failure Rates): 大规模 AI 训练集群通常配备数万个高性能 GPU，以及高速网络连接（如 NVLink 和 rail-optimized network）。这些高性能组件的故障率远高于传统计算硬件（如 CPU 和 Clos network），且单点故障容易通过同步机制扩散至整个训练任务。
3. 缺乏直接根因指示 (Lack of Direct Root Cause Indicators): 故障往往从一个单点扩散到整个集群，导致所有节点同时报告错误（如 CCL timeout），从而难以定位真正的根因。
4. 现有解决方案的局限性 (Limitations of Existing Solutions):

   • 传统的通用云诊断系统（如 Pingmesh）侧重于网络本身或单次请求-响应模式，难以应对 AI 训练中跨设备关联的故障传播。

   • 现有针对 AI 训练的诊断系统（如 SuperBench 和 MegaScale）也存在局限性。SuperBench 主要用于部署前的灰度故障检查，难以在运行时诊断故障；而 MegaScale 虽能运行时诊断，但需要监控或修改客户代码中的“关键代码段”，这对于公共云服务提供商来说是不可接受的，因为它侵犯了客户隐私且不易于通用化。

     因此，迫切需要一个专门为 AI 模型训练服务设计的、能够在生产环境中高效、准确且不修改客户代码的故障诊断系统。

核心贡献/主要发现 (Main Contribution/Findings - What)

本文提出了 Aegis，一个针对 AI 模型训练服务的故障诊断系统，并分享了其动机、设计和演进经验。Aegis 的核心目标是在不修改客户代码的前提下，诊断服务运行时的故障根因。其主要贡献和发现包括：

1. 分阶段演进的诊断系统 (Phased Evolution of Diagnosis System): Aegis 经历了两个主要阶段的演进：
   • Aegis Phase-1: 通过增强现有通用诊断系统，并结合训练日志和专门的诊断流程，初步实现了对大多数故障的定位，并设计了全面的离线诊断作为兜底方案。
   • Aegis Phase-2: 为了减少对离线诊断的依赖，显著提高了运行时诊断能力，通过巧妙地定制 集体通信库 (Collective Communication Library, CCL) 来获取运行时状态，实现了更复杂的故障定位，且不需修改客户代码。
2. 全面的故障处理能力 (Comprehensive Fault Handling Capabilities): 除了故障定位，Aegis 还扩展了能力以处理 性能退化 (performance degradation) 问题，并引入了 交付前检查 (Check Before Delivery, CBD) 机制来预防故障。
3. 显著的生产效益 (Significant Production Benefits): Aegis 已在生产训练云服务中部署一年，取得了令人瞩目的效果：
   • 将诊断导致的 闲置时间 (idle time) 减少了超过 $97\%$。
   • 将训练任务的 重启次数 (training task restart count) 减少了 $84\%$。
   • 将 性能退化 (performance degradation) 减少了 $71\%$。
4. 实际经验与教训 (Practical Experience & Lessons Learned): 分享了在部署和演进 Aegis 过程中遇到的实际问题，如批量链接故障、多样化的销售模式、异构设备管理以及拥塞控制问题，并总结了解决方案。

预备知识与相关工作 (Prerequisite Knowledge & Related Work)

基础概念 (Foundational Concepts)

• AI 模型训练 (AI Model Training): 指利用大量数据通过特定的算法（如神经网络）训练 AI 模型的过程。在大规模场景下，这通常涉及将模型和数据分布到多个计算设备（如 GPU）上并行处理。
• 分布式训练 (Distributed Training): 将 AI 模型的训练任务分解，在多个计算节点（通常是带有 GPU 的服务器）上并行执行。这要求节点之间进行频繁的数据交换和同步。
• 集体通信 (Collective Communication): 分布式训练中的关键环节，指多个计算节点之间协同完成的通信操作，例如所有节点共享梯度、广播模型参数等。常见的 CCL (Collective Communication Library) 包括 NVIDIA 的 NCCL (NVIDIA Collective Communications Library)。
• GPU (Graphics Processing Unit): 图像处理器，因其并行计算能力而成为 AI 模型训练的核心硬件。
• NVLink: NVIDIA 专有的高速互连技术，用于 GPU 之间以及 GPU 与 CPU 之间的高带宽、低延迟通信，特别是在单个服务器内部或 DGX SuperPOD 等高性能计算集群中。
• PCIe (Peripheral Component Interconnect Express): 一种高速串行计算机扩展总线标准，用于连接 CPU 与其他外围设备，如 GPU 和网卡 (NIC)。
• 传统云诊断系统 (Traditional Cloud Diagnosis Systems): 指为通用云计算场景设计的故障诊断系统，通常关注网络连通性、服务器健康状况、应用响应时间等。
  • Pingmesh: 一种大规模网络延迟测量和分析系统，通过主动探测网络来诊断连通性和高延迟问题。
  • 带内网络诊断 (Inband Network Diagnosis): 在网络数据包中嵌入诊断信息，随数据包一同转发，从而实现对数据路径中每个跳 (hop) 的精细化监控和故障定位。
• 5-tuple (五元组): 在网络通信中，指源 IP 地址、目标 IP 地址、源端口号、目标端口号和传输层协议这五个参数的组合，用于唯一标识一个网络连接。
• ECN (Explicit Congestion Notification): 显式拥塞通知，一种 TCP/IP 协议的扩展，允许网络设备在发生拥塞时向发送方发出信号，而无需丢弃数据包。

前人工作 (Previous Works)

• 通用云故障诊断系统 (General Cloud Abnormality Diagnosis Systems): 论文提到了大量针对主机和网络的通用诊断系统 [23–26, 28, 29, 31, 32, 34, 35, 37–43, 46–48, 50–59, 61, 63, 64]。这些系统主要通过跟踪系统组件调用序列来定位故障根因，例如通过 5-tuple 或特定故障设备。
  • 局限性: 由于 AI 模型训练的同步特性，单点故障会扩散到整个集群，导致所有主机同时报告错误，使得这些系统难以在模型训练场景中有效定位根因。它们通常无法捕捉到集体通信相关的特定问题。
• 大型 AI 模型训练诊断系统 (Large-scale AI Model Training Diagnosis Systems):
  • SuperBench [60]: 微软部署的系统，提供全面的基准测试套件，用于在集群部署前进行灰度故障检查。
    • 局限性: 难以定位运行时发生的故障根因。运行一次完整的基准测试耗时数小时，不适合作为唯一的运行时诊断方法，会造成巨大的计算资源浪费和用户体验差。
  • MegaScale [36]: 字节跳动部署的系统，通过监控客户模型中“关键代码段”的 CUDA events 来诊断训练问题。
    • 局限性:
      1. 需要清晰定义“关键代码段”，这对于公共云服务提供商来说不切实际，因为客户模型多样且代码保密。
      2. 监控 CUDA events 需要在客户模型代码中显式调用定制的监控模块，这涉及到修改客户代码，同样不适用于公共云场景。
  • 其他基于基础设施日志和统计的诊断方案 (e.g., monitor_train_log [2] and SageMaker [11]): 只能覆盖有限范围的故障。
  • Dynolog [10]: 集成 PyTorch profiler 以获得代码块级别的跟踪，但无法定位 GPU 内核执行中的根因。

技术演进 (Technological Evolution)

从传统的云服务（如 CPU 密集型或存储密集型任务）到大规模 AI 模型训练服务，底层计算范式、硬件需求和网络架构都发生了显著变化。

• 硬件演进: 从传统的 CPU 和 Clos network 到高性能 GPU (A100, H100) 和高速互连技术 (NVLink, rail-optimized network)。
• 故障模式演进: 高性能硬件带来更高的故障率，且分布式同步训练使得单点故障具有更高的破坏性和更复杂的传播路径。
• 诊断需求演进: 需要从关注单一组件或简单网络连接的故障，转向能够理解分布式同步行为、识别集体通信瓶颈和计算故障根源的更复杂的诊断机制。

差异化分析 (Differentiation)

Aegis 与上述前人工作和相关系统的核心区别在于：

• 非侵入性 (Non-Intrusive): Aegis 能够在不修改客户代码或训练框架的前提下进行深度诊断，这对于公共云服务提供商至关重要，解决了 MegaScale 的核心痛点。
• 运行时诊断 (Runtime Diagnosis): Aegis 专注于运行时故障和性能退化诊断，弥补了 SuperBench 在这方面的不足。
• 全面性与实用性 (Comprehensiveness & Practicality): Aegis 通过分阶段演进，整合了对主机侧关键错误、分布式错误、网络问题、性能退化以及交付前检查的全面处理，是一个为实际生产环境设计且经过验证的系统。
• 定制化 CCL (Customized CCL): 创新性地利用定制 CCL 作为获取训练过程特定信息的桥梁，实现了对计算和通信故障的精确定位，同时保持了低开销和易部署性。

方法论 (Methodology - Core Technology & Implementation Details)

Aegis 是一个为 AI 模型训练服务设计的故障诊断系统，其设计核心原则是“易于部署 (easy-to-deploy)”，并旨在不修改客户代码的情况下，诊断运行时故障和性能退化。系统经历了两个主要阶段的演进，并增加了交付前检查能力。

该图像是论文中图6的示意图，展示了Aegis故障诊断系统的整体架构，包含任务失败和性能下降的多阶段诊断流程，以及在线和离线日志数据的利用，体现系统的演进和错误定位机制。

Figure 6: Aegis overview.

如图 6 所示，Aegis 主要关注两种异常类型：训练故障 (training failure) 和性能退化 (performance degradation)。

Phase-1: 增强现有系统 (Enhancing Existing Systems)

Aegis Phase-1 的目标是通过增强现有诊断系统，并结合训练日志，构建一个初步的训练特定运行时诊断流程。

基本错误诊断 (Basic Error Diagnosis)

在早期阶段，故障定位主要依靠人工分析日志。通过总结数百个线上故障案例，作者团队将关键错误模式转化为自动化的任务故障诊断系统。

• 挑战一：并非所有报告的错误都至关重要 (Not all reported errors are critical)。

  • 问题: 日志中存在大量错误，但并非所有都会导致任务失败或性能退化。例如，ECC errors 中只有双比特错误 (XID 48 Error) 和不可纠正错误 (XID 94/95 Error) 是故障根因，而单比特错误 (XID 92 Error) 或可纠正错误 (XID 63/64 Error) 仅表示 HBM memory errors 但不触发故障。如果直接隔离所有报告错误的机器，将严重损害集群利用率。
  • 解决方案: 首先识别那些会导致任务异常的关键错误 (critical errors)，例如 GPU 丢失、PCIe 通道掉线或 NVLink 问题。当检测到这些问题时，直接隔离相应主机。
    • CriticalError() 函数：识别主机侧的关键错误，包括硬件故障（双比特 ECC 错误、链接断开、GPU/NVLink/NIC 丢失、风扇错误、电源错误）、不可恢复的软件故障（GPU/NIC 驱动错误）和不可承受的性能退化（GPU/主机过热）。

• 挑战二：并非所有关键错误都指向明确位置 (Not all critical errors point to a clear location)。

  • 问题: 许多错误（如“连接被对端重置 (connection reset by peer)”）是分布式性质的，可能导致 NCCL 错误处理程序触发，进而导致级联的线程崩溃。这些错误不直接指向特定节点。
  • 解决方案: 构建一个分布式错误列表 (distributed error list)，即 DistError()。

• 故障诊断流程 (Failure Diagnosis Procedure): 结合上述经验，形成了一套诊断流程（参见附录 A 的 Algorithm 1）。

  1. 关键错误检查 (Critical Error Check):
     • 如果 CriticalError(T) （其中 $T$ 是训练任务中使用的所有主机集合）返回非空的关键错误位置列表 $L_{cE}$，则直接隔离 $L_{cE}$ 中的主机并重启任务。
  2. 分布式错误检查 (Distributed Error Check):
     • 如果关键错误列表为空，则检查 DistError(T) 返回的分布式错误位置列表 $L_{DE}$。
     • 如果 $L_{DE}$ 的大小小于或等于 2，即只有一两个主机报告分布式错误，则认为错误源自这些主机，直接隔离 $L_{DE}$ 中的主机并重启任务。这是在诊断效率和资源浪费之间的权衡。
     • 如果 $L_{DE}$ 的大小大于 2，则调用 RootDiag(LDE)。RootDiag() 分析报告的错误，试图根据来源或目的地进行聚类。如果 GPU $G_j$ 是根因，那么所有与 $G_j$ 相关的连接都会首先崩溃。如果 RootDiag() 能确定故障 GPU $G_j$，则隔离 $G_j$ 并重启任务。
  3. 系统性问题检查 (Systemic Problem Check):
     • 如果错误分布没有清晰模式，则可能存在系统性问题（如网络或配置问题）。调用 ConfigCheck(LDE) 和 NetDiag(LDE) 进行进一步诊断。
       • ConfigCheck(): 维护一个检查列表和脚本来识别配置错误。
       • NetDiag(): 使用 §2.2 中描述的现有数据中心网络 (DCN) 诊断系统（结合 网络监控与分析 (Network monitoring and analysis)、RDMA Pingmesh 和 带内网络诊断 (Inband network diagnosis)）进行网络诊断。如果 ConfigCheck() 或 NetDiag() 发现根因，则进行修复。
  4. 离线诊断 (Offline Diagnosis):
     • 如果所有上述步骤都无法定位根因，则隔离训练任务中使用的所有主机，并进行离线诊断 (OfflineDiag(T))。

• 经验教训: 在大规模模型训练中，主机侧问题可能被误解为网络问题。实践表明，$71\%$ 的分布式故障与网络无关。因此，在混合故障环境中，优先解决主机侧问题是最有效的方法。

离线故障诊断 (Offline Failure Diagnosis)

当运行时诊断无法定位根因时，系统将触发离线诊断机制。

• 并行化离线故障定位 (Parallelized Offline Failure Localization):
  • 隔离所有可疑主机，并并行执行一系列自检，包括 CPU、GPU、PCIe 和 NVLink 的压力测试。
  • 如果单主机自检发现问题，则标记为主机故障。
  • 如果单主机测试无问题，则进行多主机故障诊断。选择类似 SuperBench 的典型模型（包括 MoE models 和 Multimodal models）作为参考模型。集群被划分为更小的段，参考模型在不同段上独立训练以定位问题主机。一旦某个子集被确认正常，其主机将返回在线服务。
• 拓扑感知并行定位 (Topology-aware Parallel Localization):
  • 为避免不同诊断任务在共享网络链路上相互干扰或隐藏故障，主机根据物理网络拓扑（如 Pods 和 ToR groups）进行划分。
  • 这样可以确保并行诊断任务的流量在网络中不会相互干扰，提高了诊断的准确性。
  • 如果离线诊断过程中发现无法在任何子集中复现故障，而故障存在于整个集群，这可能表明核心交换机（Tier-2/3）存在问题。例如，文中提到了一个静默丢包 (silent packet loss) 案例，仅丢弃大于 1KB 的数据包，导致传统 RDMA Pingmesh 无法检测。通过这个案例，系统增强了对静默丢包的检测能力，并扩充了 RDMA Pingmesh 的探测包长度范围。

Phase-2: 过程感知诊断 (Procedure-aware Diagnosis)

Aegis Phase-1 仍需依赖离线诊断处理许多复杂情况，导致计算资源浪费。为了提高运行时诊断比例，Aegis 演进到 Phase-2，目标是获取更多训练过程特定的信息。

理想解决方案的特点 (What is the ideal solution?)

1. 高保密性 (High confidentiality): 在获取详细诊断信息的同时，要保护客户代码、模型、数据等敏感信息的隐私。
2. 最小化客户修改 (Minimal customer modifications): 诊断系统应尽可能对客户透明，避免修改客户代码或训练框架。这是公共云服务提供商的核心要求。
3. 低开销 (Low overhead): 信息收集和处理应引入最小的开销，避免影响主要训练任务的性能。

定制 CCL 是桥梁 (Customizing CCL is the bridge)

为了满足上述要求，Aegis Phase-2 选择了定制集体通信库 (CCL) 作为获取增强运行时诊断信息的桥梁。

• 原因:

  1. 模块化 (Modularized): 在主流训练框架（如 Megatron 和 DeepSpeed）中，集体通信是独立的模块化组件，可以被替换。通过替换 CCL，可以在不修改客户模型代码的情况下收集诊断信息。
  2. 边界位置 (Boundary Position): CCL 处于计算和通信的边界，可以提供关于主机侧处理时间（计算）和网络侧处理时间（通信）的清晰信息，这对于定位故障设备至关重要。

• 信息收集 (Information Collection): 定制的 CCL 记录每个 GPU ($G_j$) 中每个通信操作 ($C_i$) 的以下统计信息：

  • 集体启动计数 (Collective launch count) ($CL_{i,j}$): 记录 $G_j$ 启动 $C_i$ 的次数。

  • 工作请求计数 (Work request count) ($WR_{i,j}$): 记录 $G_j$ 中 $C_i$ 启动的工作请求数量。

  • 工作完成计数 (Work completion count) ($WC_{i,j}$): 记录 $G_j$ 中 $C_i$ 完成的工作请求数量。

    该图像是图7的示意图，展示了通过定制集体通信库(CCL)实现故障诊断的三种情况：(a)正常训练迭代，(b)计算故障，(c)通信故障。图中使用 $CL_{i,j}=m$ 等公式标注迭代与通信状态。

  Figure 7: Customizing CCL for failure diagnosis.

• 故障定位场景 (Failure Localization Scenarios):

  • 场景 1：计算故障 (Failure in computation) (图 7b):
    • 当某个 GPU ($G_n$) 在计算阶段发生故障时，它将无法启动后续的集体通信操作 ($C_i$)。
    • 结果是，通信器中的其他工作节点将在 $C_i$ 处停滞并因 CCL timeout 而崩溃。
    • 诊断依据: 此时，$CL_{i,n} < CL_{i,j \neq n}$ （即 $G_n$ 启动 $C_i$ 的次数少于其他正常 GPU），从而将 $G_n$ 精准定位为故障根因。
  • 场景 2：通信故障 (Failure in communication) (图 7c):
    • 如果故障发生在通信阶段，某个 $C_i$ 中的特定工作请求传输失败，导致所有 GPU 遭遇 CCL timeout。
    • 诊断依据: 此时，需要更详细的统计信息 $WR_{i,j}$ 和 $WC_{i,j}$。在正常情况下，$WR_{i,j} = WC_{i,j}$。如果 $WR_{i,n} < WC_{i,n}$（即 $G_n$ 发出的工作请求数少于已完成的请求数，这在实际中是错误的表述，应为 $WR_{i,n} > WC_{i,n}$，表示发出未完成，或者 $WC_{i,n}$ 明显低于其他节点），则表明 $G_n$ 与根因相关。然后，对与这些异常工作请求相关的所有源和目的地执行 NetDiag()。

• 局限性: 尽管定制 CCL 是一个易于部署的折衷方案，但仅凭集体通信信息不足以找到所有故障根因。然而，CCL 位于计算和通信的边界，这对于定位故障源（是计算问题还是通信问题）是至关重要的。

性能退化诊断 (Performance Degradation Diagnosis)

除了完整的训练任务故障，一些设备异常可能不会导致训练崩溃，但会引起显著的性能退化。Aegis 也设计了相应的退化诊断系统，因为此时无法使用离线诊断作为最终回退方案。

基本关联诊断 (Basic Correlating Diagnosis)

类似于 Phase-1，首先利用现有运行时统计数据检测潜在的性能退化。

• 关键指标选择 (Key metric selection):
  • 异常运行指标 (Abnormal operating metrics): 直接指示组件运行异常的指标，如 Retran (重传次数)。正常情况下应为零。
  • 性能指标 (Performance metrics): 反映特定组件执行效率的指标，如 Actual TensorFLOPS。
  • 选择 $20+$ 个指标，包括主机指标（CPU 利用率、GPU 利用率、GPU 温度、PCIe 利用率）和网络指标（带宽利用率、重传计数、交换机端口队列长度、ECN 计数）。
  • 为这些指标设置阈值以过滤明显的异常信号。但由于静态阈值不适用于各种训练场景（资源利用率在正常训练中也会有很大波动），因此需要更复杂的机制。
• 跨主机关联诊断 (Cross-host correlating diagnosis):
  • 基本思想: 性能退化通常由少量异常节点引起，并伴随某些指标的异常变化。
  • Z-Score 异常值分析器 (Z-Score outlier analyzer): 对不同指标使用 Z-Score 方法检测异常值。
    • 对于每个选定的指标，异常值分析器计算在一个周期 $T$ 内的平均值 $λ$ 和标准差 $δ$。
    • 如果单个主机的指标值持续 $T$ 时间高于 $λ + 2δ$，则该主机被定义为异常值。在生产环境中，$T$ 设置为 10 分钟。
  • 案例研究 (Case study): 某个 LLM 训练中，一个网卡的 ECN 统计值从零急剧增加到 10-30K/秒，同时训练迭代时间增加了 $26\%$。Aegis 识别出该网卡 ECN 指标超过 $λ + 2δ$，定位根因为连接到该网卡的某个链路存在静默丢包，导致流量重路由并引发网络拥塞。隔离异常主机后，性能恢复正常。
• 局限性: 这种关联诊断适用于单个或几个主机指标显著不同于其他主机的情况。但当所有主机上的多个指标同时发生变化时，它无法精确定位根因。

增强过程感知诊断 (Enhancing Procedure-aware Diagnosis)

为了解决基本关联诊断的局限性，Aegis 再次选择定制 CCL 以获取更多信息用于退化诊断。

• 收集的额外统计信息: 在每次迭代 $I_k$ 中，为每个集体操作 ($C_i$) 和每个 GPU ($G_j$) 记录以下信息：

  • $I_k$ 中 $G_j$ 执行 $C_i$ 的持续时间 $TD_{i,j,k}$。

  • $I_k$ 中 $C_i$ 的平均持续时间 $\overline{TD}_{i,k}$。

  • $I_k$ 中 $G_j$ 执行 $C_i$ 的最后 $L$ 个工作请求（实践中 $L=5$）的网络吞吐量 $N_{i,j,k}$。

  • $I_k$ 中 $C_i$ 的平均网络吞吐量 $\overline{N}_{i,k}$。

    该图像是图表，展示了批处理故障期间的失效链接数量随时间（天）的变化趋势。从图中可以看出，失效链接数在前几天达到峰值，随后整体呈下降趋势。

  Figure 9: Customizing CCL for performance diagnosis.

• 退化定位场景 (Degradation Localization Scenarios) (图 9):

  • 计算退化 (Computation degradation) (图 9a): 如果 GPU ($G_j$) 的集体操作持续时间 $TD_{i,j,k}$ 显著低于平均值（例如 $TD_{i,j,k} < \alpha \overline{TD}_{i,k}$，实践中 $\alpha = 0.8$），则表明 $G_j$ 在计算阶段存在异常长时间的停顿，导致计算退化。这是由于集体操作结束是同步的，因此可以推断出计算时间。
  • 通信退化 (Communication degradation) (图 9b): 如果 GPU ($G_j$) 的网络吞吐量 $N_{i,j,k}$ 显著低于平均值（例如 $N_{i,j,k} > \beta \overline{N}_{i,k}$，实践中 $\beta = 1.5$ 似乎是笔误，应是 $N_{i,j,k} < \text{某个阈值}$ 或 $N_{i,j,k}$ 相对于 $\overline{N}_{i,k}$ 异常低），则表明存在通信退化。根据这些信息，过滤出直接受退化影响的 GPU 组 $\mathbb{G}$，然后使用类似于 Algorithm 1 中 RootDiag() 的原理，进一步确定通信退化的源或目的地。

解决交付前的问题 (Solving Problems Before Delivery)

通过分析失败训练任务的运行时长，发现 $73\%$ 的任务在最初 10 分钟内失败（图 10），这表明许多故障在初始化阶段就已存在。

该图像是图表，展示了生产环境中空闲时间的演变（图11）。图中通过柱状图表示空闲时间（小时），折线图表示任务规模（GPU数），显示了Aegis两个阶段实施前后空闲时间和任务规模的变化趋势。

Figure 10: Durations of training tasks in production.

• 原因:
  1. 频繁的组件更新 (Frequent component updates): 训练框架、CCL、容器网络、NIC 驱动、交换机等组件频繁更新，可能引入新的故障。
  2. 使用后故障 (Post-usage failures): 主机在上次使用后出现故障，导致新任务在初始化阶段失败。在云环境中，主机动态分配，故障复现困难，且交付给客户后难以任意诊断。
• Check Before Delivery (CBD) 过程 (CBD Procedure):
  • 在资源交付给客户之前执行的检查。
  • 优势: 不打断现有工作流；在整个环境设置完成后进行，能捕获更多问题（如容器网络配置错误导致的连接问题）。
  • 挑战: 必须高效，避免影响用户体验。
  • CBD 操作列表 (Table 1): 包括并行配置检查、单主机测试和多主机测试，总时长小于 10 分钟。
    • 轻量级 CBD (Lightweight CBD): 对于 PaaS 模式，提供一个 1 分钟内完成的轻量级版本，仅包含并行配置检查和关键本地主机测试。
  • 效果: 成功拦截了 $1\%$ 的问题主机。当大量机器在 CBD 中失败时（达到阈值），会自动回滚近期更新，防止大规模服务中断。

实验设置 (Experimental Setup)

• 数据集 (Datasets): 本文的评估基于阿里巴巴云内部模型训练团队的真实生产数据，该团队负责训练世界顶级的 LLM (Large Language Model)。评估时间跨度为 16 个月。

  • 数据来源: 生产训练云服务中的日志、诊断信息、任务运行状态、GPU 闲置时间、任务重启计数、性能指标等。
  • 特点: 数据来自大规模、高复杂度的真实 AI 模型训练任务，具有极高的现实意义和挑战性。
  • 具体样本示例: 论文中未直接给出具体的模型训练数据样本示例，但提到了 LLM 训练项目、MoE models 和 Multimodal models 等。这些模型训练过程中会产生大量的日志信息、系统级和网络级性能指标，以及训练迭代时间等。

• 评估指标 (Evaluation Metrics):

  1. 诊断导致的闲置时间 (Idle Time Wasted by Diagnosis)

     • 概念定义 (Conceptual Definition): 指 GPU 在等待故障诊断期间处于闲置状态的总时间。这个指标量化了诊断过程对计算资源利用率的影响，目标是尽可能减少这个时间，以提高集群的整体效率。
     • 数学公式 (Mathematical Formula): 论文中未给出明确的数学公式，但其含义为所有 GPU 在等待诊断期间闲置时间的累加。可以概括为： $$T_{\text{idle}} = \sum_{g \in \text{GPUs}} \sum_{t \in \text{diagnosis periods}} \Delta t_{g,t}$$
     • 符号解释 (Symbol Explanation):
       • $T_{\text{idle}}$: 诊断导致的 GPU 总闲置时间。
       • $\text{GPUs}$: 所有参与训练任务的 GPU 集合。
       • $\text{diagnosis periods}$: 某个 GPU 在等待故障诊断时所经历的时间段。
       • $\Delta t_{g,t}$: GPU $g$ 在诊断时间段 $t$ 内的闲置时长。

  2. 训练任务重启次数 (Training Task Restart Count)

     • 概念定义 (Conceptual Definition): 指由于故障或诊断过程导致训练任务需要从头开始或从上一个检查点重启的次数。这个指标反映了训练任务的稳定性，目标是减少重启次数，以避免时间、资源和进度的损失。
     • 数学公式 (Mathematical Formula): 论文中未给出明确的数学公式，通常直接统计任务重启事件的总次数。 $$N_{\text{restart}} = \text{Count}(\text{Training Task Restart Events})$$
     • 符号解释 (Symbol Explanation):
       • $N_{\text{restart}}$: 训练任务的总重启次数。

  3. 性能退化 (Performance Degradation)

     • 概念定义 (Conceptual Definition): 指训练任务的实际迭代时间超过其标准迭代时间的部分占总迭代时间的比例。这个指标量化了由非崩溃性问题（如硬件性能下降、网络拥塞等）引起的性能损失，目标是尽可能减少这种退化。
     • 数学公式 (Mathematical Formula): $$P_{\text{deg}} = \frac{\sum_{k: T_k > T_S} (T_k - T_S)}{\sum_{\text{all}} T_k}$$
     • 符号解释 (Symbol Explanation):
       • $P_{\text{deg}}$: 性能退化百分比。
       • $T_k$: 第 $k$ 次迭代的实际迭代时间，从模型训练日志中测量。
       • $T_S$: 标准迭代时间，定义为 $1.2 \times \overline{T_k}$。
       • $\overline{T_k}$: 所有迭代的平均迭代时间（或基线迭代时间）。
       • $\sum_{k: T_k > T_S}$: 对所有实际迭代时间超过标准迭代时间 $T_S$ 的迭代求和。
       • $\sum_{\text{all}} T_k$: 对所有迭代的实际迭代时间求和。

  4. 运行时诊断百分比 (Runtime Diagnosis Percentage)

     • 概念定义 (Conceptual Definition): 指在无需触发耗时且耗费资源的离线诊断的情况下，能够通过运行时机制直接诊断出故障的比例。这个指标衡量了诊断系统的即时性和效率，目标是趋近 $100\%$，以最大化 GPU 利用率和用户体验。
     • 数学公式 (Mathematical Formula): 论文中未给出明确的数学公式，但其含义为运行时成功诊断的故障案例数占总故障案例数的比例。 $$P_{\text{runtime\_diag}} = \frac{\text{Number of failures diagnosed at runtime}}{\text{Total number of failures}} \times 100\%$$
     • 符号解释 (Symbol Explanation):
       • $P_{\text{runtime\_diag}}$: 运行时诊断百分比。

• 对比基线 (Baselines): 本文的评估主要聚焦于 Aegis 系统在生产环境中的演进式改进。因此，其主要“基线”是 Aegis 各个阶段（即 Aegis Phase-1 之前、Aegis Phase-1 之后、Aegis Phase-2 之后以及 CBD 部署之后）自身的表现。论文没有与 SuperBench 或 MegaScale 等其他系统进行直接的量化对比，而是通过定性分析（在相关工作部分）指出了这些现有方案的局限性，从而衬托 Aegis 在特定生产场景下的优越性。这种方法论反映了在真实生产系统中，性能提升更多是通过迭代优化和与自身历史数据对比来体现的。

实验结果与分析 (Results & Analysis)

核心结果分析 (Core Results Analysis)

7.1 训练稳定性演进 (Evolution of Training Stability)

该图像是图表，展示了生产环境中空闲时间的演变（图11）。图中通过柱状图表示空闲时间（小时），折线图表示任务规模（GPU数），显示了Aegis两个阶段实施前后空闲时间和任务规模的变化趋势。

Figure 11: Evolution of idle time in production.

• 图 11 (GPU 闲置时间演变):

  • 该图展示了内部模型训练团队的训练任务规模（折线，GPU 数量）和每月因故障诊断导致的 GPU 累计闲置时间（柱状图，小时）。

  • Aegis Phase-1 于 2023 年 9 月上线。次月，尽管训练规模翻倍，但闲置时间立即减少了 $71\%$，效果显著。

  • 2023 年 11 月，训练规模增长 4 倍，导致闲置时间有所增加，这表明快速的规模扩张会引入新的意外问题，延长诊断时间。

  • Aegis Phase-2 于 2024 年 6 月部署。部署后，训练闲置时间进一步节省了 $91\%$。这主要得益于更多故障可以在运行时解决，减少了对耗时离线诊断的依赖。

    该图像是图表，展示了生产环境中重启次数的演变（图12）。图中显示从23年5月到24年8月，重启次数经历了显著变化，尤其在23年11月CBD推广后重启次数大幅下降，直到24年8月任务变更为微调时有所上升。

Figure 12: Evolution of restart counts in production.

• 图 12 (训练任务重启次数演变):
  • 该图展示了训练任务的重启次数随时间的变化。
  • 2023 年 11 月，训练规模的增加也导致了重启次数的增加，同时初始化阶段的故障也增多。
  • CBD (Check Before Delivery) 于 2023 年 12 月上线。上线后，下一个月的重启次数减少了 $44.8\%$。通过持续优化，最终使重启次数减少了 $84.6\%$。CBD 在交付前发现并拦截了大约 $1\%$ 的问题主机，有效减少了任务重启。
  • 2024 年 8 月，重启次数再次增加，原因为模型训练团队从预训练切换到微调，引入了计划中的实验和测试。这表明即使有 Aegis，新的工作负载和实验性质的变化仍然可能导致重启。

7.2 运行时故障诊断 (Runtime Failure Diagnosis)

该图像是图13，展示了不同日期的运行时诊断百分比，柱状图清晰反映了诊断覆盖率随时间的变化趋势。

Figure 13: Runtime diagnosis percentage.

• 图 13 (运行时诊断百分比):
  • 该图显示了运行时诊断的故障案例占总故障案例的百分比。这个指标的重要性在于，每次离线诊断都会对 GPU 利用率和用户体验造成巨大损害。
  • 随着 Aegis Phase-2 的部署，运行时诊断百分比逐渐趋近 $100\%$。这意味着训练任务几乎可以自动从所有类型的故障中恢复，减少了人工干预。

7.3 处理性能退化 (Handling Performance Degradation)

该图像是图14，展示了性能退化百分比的柱状图。柱状图显示从24/01到24/05期间性能退化较高，之后从24/06到24/08显著降低，表明性能退化明显减少。

Figure 14: Performance degradation percentage.

• 图 14 (性能退化百分比):
  • 该图展示了训练任务的性能退化百分比。
  • Aegis 的性能退化诊断功能于 2024 年 6 月部署。部署后，性能退化显著减少了 $71\%$。这表明 Aegis 在识别和解决导致训练任务变慢的非崩溃性问题方面是高效的。

数据呈现 (表格)

由于系统未提供 Table 1 的图像，以下是原文中 Table 1: CBD task list 的完整转录：

消融实验/参数分析 (Ablation Studies / Parameter Analysis)

论文没有进行传统的消融实验，但 Aegis 的分阶段演进本身就体现了对不同组件和策略有效性的验证过程：

• Phase-1 验证了增强现有系统和结合训练日志在初步诊断中的有效性。
• Phase-2 验证了定制 CCL 在提高运行时诊断比例和减少对离线诊断依赖方面的关键作用。
• CBD 验证了交付前检查在预防初始化阶段故障和减少任务重启方面的有效性。
• 性能退化诊断 验证了基于 Z-Score 的关联诊断和定制 CCL 的过程感知诊断在解决性能瓶颈方面的作用。

关键参数选择:

• Z-Score 异常值分析器: 持续时间 $T$ 设置为 10 分钟。异常值阈值为 $λ + 2δ$。
• 过程感知性能退化诊断:
  • 计算退化阈值 $\alpha = 0.8$ ($TD_{i,j,k} < 0.8 \overline{TD}_{i,k}$)。
  • 通信退化吞吐量阈值 $\beta = 1.5$（原文表述为 $N_{i,j,k} > \beta \overline{N}_{i,k}$，这似乎是笔误，根据上下文应是 $N_{i,j,k} < \text{某个较低的阈值}$，或者与 $\overline{N}_{i,k}$ 相比显著偏离，表示吞吐量下降）。
  • 网络吞吐量统计中，最后 $L$ 个工作请求的平均吞吐量，$L=5$。

总结与思考 (Conclusion & Personal Thoughts)

结论总结 (Conclusion Summary)

本文详细介绍了 Aegis，一个为大规模 AI 模型训练服务设计的故障诊断系统，并分享了其在生产环境中的演进和部署经验。Aegis 的核心在于其能够在不修改客户代码的前提下，有效诊断运行时故障和性能退化。通过分阶段的演进，Aegis Phase-1 增强了现有通用诊断系统并引入离线诊断作为补充；Aegis Phase-2 则通过定制 集体通信库 (CCL) 显著提升了运行时故障定位的精确度和覆盖率。此外，Aegis 还集成了 交付前检查 (CBD) 机制以预防故障，并设计了针对性能退化的专门诊断方案。 在实际生产部署中，Aegis 取得了显著的成果：诊断导致的 GPU 闲置时间减少了 $97\%$ 以上，训练任务重启次数减少了 $84\%$，性能退化减少了 $71\%$。这些成果验证了 Aegis 在提升 AI 模型训练服务稳定性、资源利用率和用户体验方面的巨大价值。

局限性与未来工作 (Limitations & Future Work)

论文中明确指出了 Aegis 的一些局限性，并间接引出了未来的研究方向：

1. 定制 CCL 的妥协 (Compromise of Customizing CCL): 尽管定制 CCL 是在不修改客户代码前提下的最佳实践，但仅凭集体通信信息不足以找到所有故障的深层根因。它主要侧重于定位故障发生在哪一侧（计算或通信），而非详尽的根因分析。

2. “重启或修复”的开放问题 (Reboot or Repair as an Open Issue): 对于已被隔离的故障主机，如何准确高效地判断是简单重启即可恢复，还是需要进行耗时的硬件维修，仍是一个开放问题。目前的 SOP 虽然实用，但仍有改进空间。

3. 复杂故障的挑战 (Challenges of Complex Failures): 尽管 Aegis 极大地提高了运行时诊断能力，但在极端复杂或罕见的故障场景下，仍可能需要人工干预或更深入的分析（例如文中提到的静默丢包和拥塞控制 bug）。

4. 异构环境的持续挑战 (Ongoing Challenges of Heterogeneous Environments): 生产环境中 GPU、NIC、交换机等硬件的快速迭代和多样化的销售模式导致了复杂的配置和管理挑战，需要持续投入精力进行兼容性测试和配置检查。

   未来工作可以包括：

• 进一步增强 CCL 诊断的深度，使其能更接近真正的根因。
• 开发更智能的“重启或修复”决策机制，可能结合机器学习或更高级的故障模式识别。
• 针对新出现的硬件故障模式和训练范式（如新的模型架构、通信模式）进行持续的诊断系统迭代和优化。
• 加强对新型网络故障（如静默丢包的变种、拥塞控制交互问题）的自动检测和根因分析。

个人启发与批判 (Personal Insights & Critique)

这篇论文提供了在超大规模、真实生产环境中构建和演进故障诊断系统的宝贵经验，对云计算和 AI 基础设施领域的研究者和工程师具有很强的启发性。

个人启发:

1. 生产导向的演进 (Production-Oriented Evolution): Aegis 的成功在于其始终以生产环境的实际需求（易部署、不修改客户代码、高效率）为指导，并采用分阶段、迭代式的方法进行建设。这比一次性设计一个完美系统更为务实有效。
2. “桥梁”策略的巧妙运用 (Clever Use of "Bridge" Strategy): 通过定制 CCL 这一位于计算与通信边界的模块，巧妙地解决了在不侵犯客户隐私和不修改客户代码前提下，获取关键运行时诊断信息的难题。这种设计思路在其他类似场景下也有借鉴意义。
3. 数据驱动的优化 (Data-Driven Optimization): 论文中大量的数据分析（如 73% 的任务在 10 分钟内失败）直接驱动了 CBD 等关键功能的开发，体现了在真实生产数据中挖掘问题和解决方案的价值。
4. 挑战的复杂性与动态性 (Complexity and Dynamism of Challenges): 论文揭示了大规模 AI 训练环境中的故障并非静态的，而是随着规模扩张、组件更新和工作负载变化而不断演变的。诊断系统本身也需要持续学习和适应。

批判:

1. 更深层根因的识别 (Deeper Root Cause Identification): 尽管 Aegis 在故障定位方面表现出色（例如识别出是计算故障还是通信故障，并指向特定设备），但对于更深层次的根因（如导致 GPU 计算故障的具体软件 bug、驱动问题或特定硬件模块损坏），论文中未详细展开其识别能力。CCL 作为一个中间层，可能难以提供足够细粒度的信息来诊断所有类型的底层问题。

2. 通用性与特定性 (Generality vs. Specificity): Aegis 的许多设计是针对其阿里巴巴云的特定大规模 LLM 训练场景。尽管其核心思想（如定制 CCL）具有通用性，但具体实现细节、阈值设置以及故障模式识别可能需要根据不同的云提供商或训练集群进行调整。

3. 拥塞控制问题的处理 (Congestion Control Issue Handling): 论文提到通过提高速率限制和周期性重置拥塞控制状态来“临时解决”NIC 拥塞控制 bug。虽然这是实用的生产补丁，但从学术角度看，关于如何更智能地、自适应地处理这类底层网络协议交互问题，或者如何设计更健壮的拥塞控制机制，可以有更深入的探讨。

4. 数据开放性 (Data Openness): 尽管由于保密原因无法发布外部客户数据是合理的，但如果能提供更多关于故障类型分布、诊断准确率/召回率等详细数据，将进一步增强其学术贡献。

   总的来说，这篇论文是系统构建和运维经验的结晶，其价值在于将理论创新与生产实践紧密结合，为大规模 AI 训练基础设施的可靠性保障提供了宝贵的经验和方法论。