EROICA: Online Performance Troubleshooting for Large-scale Model Training

Each language version is independently generated for its own context, not a direct translation.

这篇论文介绍了一个名为 EROICA 的系统，它的任务是给正在“疯狂学习”的超级人工智能（大模型）做在线体检和故障诊断。

为了让你更容易理解，我们可以把训练一个大模型想象成指挥一支拥有 10 万人的超级交响乐团进行一场史无前例的演奏。

1. 为什么需要 EROICA？（之前的困境）

场景：
想象一下，10 万名乐手（GPU 显卡）在演奏一首极其复杂的交响曲（大模型训练）。如果演奏变慢了，或者有人跑调了，指挥家（工程师）该怎么办？

以前的方法有两个，但都有大毛病：

方法 A：看宏观仪表盘（在线监控）
- 做法：指挥家只看大屏幕上显示的整体音量（硬件指标，如温度、电流）。
- 缺点：太粗糙了！如果整体音量低了，你只知道“出问题了”，但不知道是哪一把小提琴（某个具体的代码函数）拉错了，还是哪根琴弦（某根网线）断了。就像你知道乐团慢了，但不知道是第 3 排第 5 个乐手在发呆。
方法 B：给每个人发录音笔（离线分析）
- 做法：让每个乐手都带上高精度的录音笔，记录每一秒的演奏细节。
- 缺点：数据量太大了！10 万人同时录音，产生的数据会把指挥部的电脑撑爆。而且，录音笔本身很重，戴上后乐手演奏会变慢（产生性能开销），甚至没法在正式演出（生产环境）中使用。通常只能在排练室（小测试环境）用，但排练室的问题往往和正式演出不一样。

结果：工程师们经常面对“乐团变慢了”的警报，却找不到具体是谁在拖后腿，只能干着急，浪费昂贵的算力资源。

2. EROICA 是怎么工作的？（核心魔法）

EROICA 的聪明之处在于它发明了一种"智能摘要法"，既不用给每个人发笨重的录音笔，又能精准定位问题。

第一步：只在大脑“卡壳”时启动（按需触发）

EROICA 平时不工作，它像一个敏锐的哨兵。只有当它发现乐团演奏速度突然变慢（比如原本 3 秒一个乐章，突然变成了 5 秒）时，它才会瞬间启动。

第二步：收集“行为指纹”而非“原始录音”（核心创新）

这是 EROICA 最厉害的地方。它不需要记录每个人每一秒的原始动作（那样数据量太大）。

传统做法：记录“乐手 A 在 10:00:01 拉了 A 弦，力度 50，持续 0.5 秒..."。
EROICA 做法：它只记录行为模式摘要。
- 比如：“乐手 A 在演奏时，平均用了 80% 的力气，波动很小。”
- 或者：“乐手 B 在演奏时，平均只用了 20% 的力气，但波动很大（一会儿用力，一会儿停）。”

比喻：这就好比你要检查 10 万个学生的作业。

传统方法：把 10 万本作业本全部复印下来，堆成山，然后慢慢看。
EROICA 方法：只让每个学生写一行字总结：“我这道题平均用了 5 分钟，最慢用了 10 分钟，最快用了 2 分钟。”
- 这行字（摘要）只有 30KB 大小，而原始作业本（原始数据）有 3GB。
- 好处：数据量缩小了 10 万倍！而且不需要大家的时间完全同步（不需要大家手表时间分秒不差），只要看“平均”和“波动”就能对比。

第三步：找“害群之马”（差异定位）

系统把所有乐手的“行为指纹”放在一起对比：

正常情况：大家的“平均用力”和“波动”应该差不多。
异常情况：
- 如果所有人都慢了：可能是指挥（代码逻辑）有问题，或者舞台灯光（硬件配置）太暗。
- 如果只有几个人慢了：
  - 有人“用力”但“波动大”：可能是网线（网络）接触不良，一会儿通一会儿断。
  - 有人“用力”但“平均很低”：可能是他的琴弦（显卡）坏了，或者他在发呆（代码死锁）。

EROICA 能在几分钟内，从 10 万个乐手中精准指出：“第 7 号乐手，你的琴弦松了”或者“第 3 排所有乐手，你们的乐谱（代码）写错了”。

3. 实际效果如何？（实战案例）

论文中提到，EROICA 已经在阿里巴巴的 10 万张显卡集群上运行了 1.5 年，解决了 97.5% 的疑难杂症。

案例 1：代码写得烂

现象：乐团演奏太慢。
EROICA 发现：大部分乐手在“等待数据”时， CPU 占用率异常高。
真相：乐手们在等外卖（数据加载），但外卖员（代码逻辑）走错了路，或者在门口吵架（垃圾回收机制乱跑）。
解决：换了个外卖平台（并行文件系统），并让乐手们统一时间吃饭（同步垃圾回收），速度立刻提上去了。

案例 2：硬件坏了 + 代码不平衡

现象：演奏时断时续，甚至经常崩溃。
EROICA 发现：
1. 有 40 个乐手的声音特别小（网卡坏了）。
2. 有 3 个乐手在疯狂整理乐谱（内存操作），导致其他人干等。
3. 有的乐手要拉 10 分钟，有的只拉 1 分钟（负载不均）。
解决：拔掉坏掉的网线，调整乐谱分配，让每个人工作量均衡。

案例 3：AI 自动修 Bug

现象：乐团突然停摆，卡住了。
EROICA 发现：有一个乐手在“锁门”（死锁），导致大家进不去。
解决：EROICA 把“锁门”的代码片段直接发给一个 AI 助手（Cursor）。AI 一看就懂：“哦，这里有个打印语句触发了死锁，我帮你改好。”
结果：代码自动修复，乐团继续演奏。

4. 总结：EROICA 的三大优点

快：不需要等演出结束，演出过程中就能实时诊断。
准：能精准定位到是“哪根网线”、“哪行代码”还是“哪个显卡”出了问题，而不是只告诉你“系统慢了”。
轻：对正在演奏的乐团几乎没有干扰（开销极低），因为它只收集“摘要”，不收集“原始录音”。

一句话总结：
EROICA 就像是一个拥有上帝视角的超级乐评人，它不需要听每个人演奏的每一秒，只需要听每个人演奏的“节奏感”和“用力程度”，就能在一秒钟内从 10 万人的乐团中，揪出那个拖后腿的“捣蛋鬼”，让 AI 的训练像丝滑的交响乐一样顺畅。

Each language version is independently generated for its own context, not a direct translation.

1. 研究背景与问题 (Problem)

随着大模型训练（LMT, Large Model Training）规模的急剧扩大（涉及数万甚至十万级 GPU），性能故障排查变得极具挑战性。现有的排查手段存在以下主要痛点：

现有工具的局限性：
- 在线监控 (Online Monitoring)：通常基于硬件计数器（如 DCGM, Nsight），采样粒度较粗（秒级），只能发现宏观症状（如整体吞吐量下降），无法定位细粒度的根因（如具体哪行代码、哪个网络链路或哪个函数导致）。且容易受误报干扰。
- 离线分析 (Offline Profiling)：虽然能提供微秒级的细粒度数据（如 Torch Profiler, Nsight Systems），但数据量巨大（单节点每秒可达 100MB+），无法在大规模生产环境中实时开启。通常只能在小型测试环境或少数节点上运行，缺乏时效性，且难以复现生产环境的复杂问题。
生产环境的矛盾：工程师需要在“全集群覆盖”和“细粒度观测”之间做艰难取舍。全量开启细粒度分析会导致巨大的性能开销和数据传输压力，而粗粒度监控又无法定位深层问题。
故障复杂性：LMT 性能问题通常由硬件（GPU、NVLink、NIC）、软件（PyTorch 代码、数据加载器、配置）或两者的混合引起。据统计，生产环境中约 44.4% 的问题源于硬件，48.2% 源于软件。

2. 核心方法论 (Methodology)

EROICA 是首个面向生产环境的在线性能故障排查系统。其核心思想是利用大模型训练架构的同质性 (Homogeneity)，通过差分可观测性 (Differential Observability) 技术，将海量原始 Profiling 数据压缩为极简的“运行时行为模式 (Runtime Behavior Patterns)"，从而实现高效诊断。

2.1 系统架构与流程

EROICA 的工作流程分为三个主要阶段（如图 6 所示）：

性能退化检测与触发 (Performance Degradation Detection)：
- 无需访问用户代码，EROICA 通过包装 PyTorch 的 dataloader.next() 和 optimizer.step() 函数来监控训练迭代时间。
- 当检测到迭代时间异常（如超过历史最短时间的 5% 或长时间阻塞）时，自动触发全集群的同步 Profiling。
- 利用迭代 ID 确保所有 Worker 在相同的训练步骤开始和停止 Profiling。
运行时行为模式总结 (Summarizing Behavior Patterns)：
- 关键路径识别：仅关注对端到端性能有贡献的“关键路径”函数（GPU 计算核、通信、内存操作、Python 函数）。
- 模式定义：对于每个 Worker 上的每个函数 $f$ $f$ ，提取一个三维向量 $P_{f,w} = (\beta, \mu, \sigma)$ $P_{f, w} = (β, μ, σ)$ ：
  - $\beta$ (占比)：函数在关键路径上花费的时间比例。
  - $\mu$ (平均资源利用率)：函数执行期间的硬件资源（如 GPU SM 频率、CPU 利用率、NIC 带宽）平均利用率。
  - $\sigma$ (波动性)：资源利用率的波动标准差。
- 数据压缩：原始 Profiling 数据约为 3GB/Worker，而行为模式仅约 30KB/Worker（压缩比达 $10^5$ 倍）。
- 去时间戳化：模式计算不依赖绝对时间戳，仅需相对时间差，因此无需全网时钟同步即可进行跨主机比较。
根因定位 (Localization)：
- 基于差分可观测性，计算两个距离指标：
  - 期望距离 ( $D_{f,w}$ )：当前行为模式与“预期正常范围”的距离（基于生产经验设定阈值）。
  - 差分距离 ( $\Delta_{f,w}$ )：当前 Worker 的行为模式与其他 Worker 的偏离程度（基于中位数和绝对中位差 MAD 计算，识别离群点）。
- 结合这两个指标，系统能精准定位是全局性问题（如配置错误、代码低效）还是局部硬件/节点问题（如某台机器网卡故障）。

2.2 关键技术挑战的解决

开销控制：仅在检测到性能下降时触发，且数据汇总在独立进程/容器中进行，不阻塞训练主线程。
大规模扩展：数据汇总和定位算法极其轻量，支持扩展到百万级 GPU 集群（定位 100 万 GPU 仅需 7 分钟）。
容器权限：利用 Kubernetes emptyDir 共享目录，在特权管理容器中采集硬件数据并传递给用户容器，无需降低用户容器权限。

3. 主要贡献 (Key Contributions)

首个生产级在线 Profiling 系统：提出了 EROICA，首次实现了在大规模生产环境中同时具备“离线 Profiling 的细粒度”和“在线监控的全覆盖”。
高效差分可观测性技术：发明了基于统计指标（ $\beta, \mu, \sigma$ ）的运行时行为模式总结方法，在保留诊断能力的同时，将数据量降低了 5 个数量级，解决了大规模数据实时分析难题。
生产验证与 AIOps 集成：在拥有约 10 万 GPU 的阿里云生产环境中部署运行 1.5 年，成功诊断了多种复杂问题，并展示了将诊断结果直接作为 Prompt 输入 AI 助手进行自动修复（Auto-fix）的可行性。

4. 实验结果 (Results)

EROICA 在阿里云生产环境（约 10 万 GPU）中部署了 1.5 年，取得了显著成效：

诊断成功率：针对 80 个现有工具无法定位的严重性能问题，EROICA 成功定位了 78 个，成功率高达 97.5%。
性能提升：帮助客户将训练吞吐量提升了 20% 到 100%。
诊断效率：
- 3400 GPU 集群的诊断仅需 3 分钟。
- 理论可扩展至 100 万 GPU 集群，端到端分析时间仅需 7 分钟。
开销极低：
- Profiling 仅在异常时触发，且数据生成仅阻塞约 20 秒。
- 模式总结和根因定位在训练进程外进行，对训练任务零额外开销。
- 内存占用相对于生产服务器（1-2TB）可忽略不计。

典型案例：

代码级问题：定位到数据加载器中的 socket recv 阻塞、Python 函数 CPU 瓶颈以及异步垃圾回收导致的等待。
混合问题：同时发现网络流调度低效、单张网卡故障（NIC down）、以及因输入数据长度不均导致的负载不平衡。
AI 自动修复：在机器人模型训练卡死案例中，EROICA 定位到死锁函数，AI 助手（Cursor）根据诊断结果自动修复了代码中的分布式死锁 bug。

5. 意义与影响 (Significance)

填补了技术空白：解决了大规模 LMT 中“细粒度观测”与“生产环境可用性”不可兼得的长期难题。
推动 AIOps 落地：EROICA 将复杂的性能数据转化为结构化的“行为模式”，为 AI 模型提供了高质量的诊断上下文（Prompt），使得自动化修复代码和配置成为可能。
工业界价值：该系统已在阿里云大规模 GPU 集群中稳定运行，直接服务于众多大模型客户，显著降低了算力浪费和故障恢复时间（MTTR），为未来超大规模 AI 基础设施的运维提供了标准范式。

总结：EROICA 通过创新的“行为模式总结”和“差分观测”技术，成功将大模型训练的性能排查从“大海捞针”转变为“精准定位”，是 AI 基础设施运维领域的一项突破性成果。