Blog Tags GitHub
Back to blog
gpu-cluster performance-diagnosis tracing distributed-training llm-training observability

ARGUS: Production-Scale Tracing and Performance Diagnosis for over 10,000-GPU Clusters

针对万卡 GPU 集群的低开销、细粒度、常开追踪与实时分析系统，总开销 <2%，内核事件压缩 3,700x

ARGUS: Production-Scale Tracing and Performance Diagnosis for over 10,000-GPU Clusters

论文信息: arXiv:2606.20374 [cs.DC] 18 Jun 2026

作者: Jiasheng Zhou, Longbin Zeng, Clavis Chen, Ruiming Lu, Qinwei Yang, Leyi Ye, Ray Ying, Key Zhang

会议: 2026 ACM SIGOPS Annual Technical Conference (ATC)

许可: arXiv 非独占分发许可

一、论文概述

1.1 研究背景

大规模 LLM 训练需要全天候、细粒度的可观测性来进行有效的性能诊断。粗粒度的资源监控器无法定位根本原因，而细粒度的分析器会带来 5%-30% 的开销和海量追踪数据，使得在大型生产集群中常开部署变得不切实际。

核心挑战：

挑战说明
Fail-slow 问题性能降级拖慢整个训练作业，但不触发显式错误
开销权衡细粒度分析器开销 5%-30%，无法常开部署
数据量爆炸10,000 GPU 集群每小时产生数百 GB 原始追踪数据
诊断复杂性随规模增长，诊断难度超线性增加

1.2 核心贡献

贡献说明
低开销监控三层次分解监控，总开销 <2%
数据压缩内核事件压缩约 3,700x（10 MB → 2.7 KB/rank/step）
渐进式诊断五级诊断框架，自动隔离异常窗口、落后 rank 和退化内核
生产验证在 10,000+ GPU 集群部署超过 6 个月
案例研究覆盖计算落后者、链接退化、流水线气泡等典型异常

二、核心思想

2.1 问题定义

在 10,000+ GPU 的大规模 LLM 训练集群中，任何一个组件的性能降级都会拖慢整个同步训练作业，但不会触发显式错误。这种 “fail-slow” 问题具有隐蔽性、随机性和难以复现的特点，严重限制了大规模训练效率。

Fail-slow 现象示例：

Fail-slow 现象 图 1(a)：4096-GPU 训练作业中的迭代时间尖峰

累计进度损失 图 1(b)：累计进度损失，浪费约 23,758 GPU 小时（7% 总训练计算）

2.2 现有系统局限

系统类型代表系统局限性
常开监控Greyhound, Holmes, C4, Minder只能定位到机器或链路，无法回答哪个内核变慢及原因
细粒度分析MegaScale, EROICA, FLARE开销 5%-30%，无法常开部署；或依赖事后手动分析

2.3 解决方案概述

ARGUS 通过以下创新解决上述挑战：

  1. 分解观察：沿训练调用层次分解为 CPU 调用栈、框架语义和 GPU 内核执行三个互补信号
  2. 在线统计压缩：基于 KDE 聚类的内核事件压缩，压缩比达 3,700x
  3. 渐进式诊断：五级诊断框架，从异常时间窗口逐步缩小到具体内核

三、技术架构

3.1 整体框架图

训练执行层次结构 图 2：训练执行的层次结构，展示 CPU 调用栈、框架语义和 GPU 内核执行三个层次

ARGUS 整体架构 图 3：ARGUS 整体架构，包含 Trace Producer、Processor、Storage 和 Analysis 四个组件

架构组件：

组件说明功能
Trace Producer部署在每个训练进程中持续产生三种互补观察：CPU 调用栈、框架语义、内核执行
Processor每个主机一个独立进程过滤、归一化、转换事件为 Perfetto 格式；在线统计压缩内核追踪
Storage分层存储Metric Storage 支持 Grafana 可视化；Object Storage 持久化完整追踪
Analysis诊断分析服务自动检测异常窗口、落后 rank 和退化内核

3.2 数据流水线

数据流水线架构 图 4：数据流水线架构，展示 Vector 摄取、处理和存储流程

数据流：

  1. Vector 摄取三种本地观察日志
  2. 路径分离：Trace 路径（原始事件流）和 Metrics 路径（可量化指标）
  3. Processor 处理原始追踪，转换为 Perfetto 格式
  4. 在线统计压缩内核追踪，写入 Metric Storage
  5. Metrics 通过 Prometheus Remote Write 协议写入 Metric Storage

3.3 核心公式

KDE 密度估计：

f^(x)=1nh∑i=1nK(x−xih)\hat{f}(x) = \frac{1}{nh} \sum_{i=1}^{n} K\left(\frac{x - x_i}{h}\right)

其中 K(⋅)K(\cdot) 是高斯核函数，带宽 hh 由 Scott’s rule 自动确定：

h=1.06⋅σ⋅n−1/5h = 1.06 \cdot \sigma \cdot n^{-1/5}

CDF 重建（对数正态假设）：

对于每个聚类 cc，构建对数正态分量：

  • 位置参数：μc=ln⁡(p50c)\mu_c = \ln(p50_c)
  • 尺度参数：σc=ln⁡(p99c)−ln⁡(p50c)2.326\sigma_c = \frac{\ln(p99_c) - \ln(p50_c)}{2.326}

Wasserstein-1 距离：

用于衡量两个 rank 之间内核执行时间分布的差异：

W1(μ,ν)=∫−∞∞∣Fμ(x)−Fν(x)∣dxW_1(\mu, \nu) = \int_{-\infty}^{\infty} |F_\mu(x) - F_\nu(x)| dx

3.4 内核事件压缩

重复内核执行模式 图 5：重复内核执行模式，展示内核事件的统计特性

压缩原理：

  • 分布式训练中内核执行具有高度规律的重复模式
  • 同一 rank 上相同位置的内核持续时间高度一致
  • 相同并行角色的 rank 执行相同的内核序列

压缩流程：

  1. 时间窗口分割：将内核事件按时间窗口分割
  2. KDE 谷值检测：使用核密度估计检测聚类边界
  3. 统计摘要：每个聚类生成结构化统计摘要
  4. 压缩比：约 3,700x（10 MB → 2.7 KB/rank/step）

3.5 渐进式诊断框架

级别数据源模式目的延迟
L1迭代时间序列自动异常时间窗口分类秒级
L2语义阶段持续时间自动落后 rank 和瓶颈阶段秒级
L3内核统计摘要自动退化内核识别分钟级
L4执行追踪手动关键路径和根因确认按需
L5CPU 调用栈手动主机侧停顿定位按需

内核统计异常检测工作流 图 7(a)：CDF 重建

Wasserstein 距离 图 7(b)：Wasserstein-1 距离

距离矩阵 图 7(c)：距离矩阵

诊断流程：

  1. L1：检测异常时间窗口（滑动窗口比率门控 + 全扫描变化点检测）
  2. L2：定位落后 rank 和瓶颈阶段（CV 分析语义事件）
  3. L3：识别退化内核（内核统计摘要对比）
  4. L4/L5：手动深度分析（执行追踪 + CPU 调用栈）

四、核心创新

4.1 创新点总结

创新点说明理论/实验依据
分解观察三层次互补监控CPU 调用栈 + 框架语义 + GPU 内核
在线统计压缩基于 KDE 聚类的内核事件压缩压缩比 3,700x，保持诊断能力
渐进式诊断五级诊断框架从异常窗口到具体内核的逐步缩小
并行组感知路由基于并行维度的事件路由DP/EP/PP 组内比较，避免误报
流式架构无累积的内存管理内存开销恒定，不受训练时长影响

4.2 技术细节

并行组感知路由规则：

事件类型比较组
gated_mla_self_attention, self_attentionDP group
moe_layer, moe_expertsEP group
dp-allreduce, dp-reduce-scatterDP group
ep-alltoallEP group

五、代码实现分析

5.1 实现概览

组件语言代码量
Trace Producer (内核追踪)C++~2K lines
Trace Producer (语义插桩)Python + C++~3K lines
ProcessorGo~7.3K lines
Analysis 服务Python~24K lines
FT-Client (用户界面)--

5.2 部署架构

  • Trace Producer：CUDA_INJECTION64_PATH 环境变量注入
  • Processor：每个主机一个独立进程
  • Analysis：诊断分析服务
  • FT-Client：统一诊断接口，集成 Grafana 和 Perfetto

六、实验结果

6.1 运行时开销

训练时间对比 图 8(a)：8-GPU 训练时间对比

训练时间对比 图 8(b)：32-GPU 训练时间对比

工具开销内存稳定性
ARGUS<2%+2GB (8-GPU), +10GB (32-GPU)稳定，无 OOM
PyTorch Profiler20%-44%持续增长至 OOM不稳定，最终 OOM
nsysN/A高训练失败 (NaN/Hang)

关键发现：

  • ARGUS 语义插桩和栈采样开销可忽略
  • 内核执行追踪 (CUPTI) 开销约 1%-2%
  • 三者结合总开销 <2%
  • 随模型增大，GPU 计算主导，开销进一步降低

6.2 内存占用

内存占用对比 图 9(a)：8-GPU 内存占用

内存占用对比 图 9(b)：32-GPU 内存占用

关键发现：

  • ARGUS 内存占用稳定，不受训练时长影响
  • PyTorch Profiler 内存持续增长，最终 OOM
  • nsys 内存占用高，导致训练失败

6.3 数据量与压缩

处理阶段每 rank 每步数据量
原始内核事件~10 MB
统计压缩后~2.7 KB
压缩比~3,700x

七、案例研究

7.1 案例1：计算落后者定位

案例1：计算落后者 图 10(a)：self_attention 持续时间热力图

案例1：计算落后者 图 10(b)：mlp / grouped_mlp 持续时间热力图

项目详情
作业规模4,096 GPU，TP=2，EP=8
异常现象迭代时间从 4s 增加到 200s+
诊断结果DP=656,657 的 self_attention 退化 150x
根因本地 GPU 计算降级，非同步延迟
解决方案排除受影响节点，训练恢复正常

7.2 案例2：通信链接退化

案例2：Wasserstein 距离矩阵 图 11(a)：AllReduce 距离矩阵

案例2：Wasserstein 距离矩阵 图 11(b)：AllGather 距离矩阵

案例2：Wasserstein 距离矩阵 图 11(c)：ReduceScatter 距离矩阵

案例2：L4 Perfetto 追踪 图 12：L4 Perfetto 追踪，展示 rank 7 的通信内核异常

项目详情
作业规模512 GPU，EP=8
异常现象迭代时间稳定，但吞吐量持续低于基线
诊断结果L3 检测到三个通信内核类型的分布偏移
根因EDP 组内通信链接系统性降级
特征组内距离小 (17-23k)，组间距离大 (376k-2.73M)

7.3 案例3：流水线气泡放大

案例3：流水线气泡 图 13：PP 组内 L4 Perfetto 追踪，展示气泡放大模式

案例3：跨组对比 图 14：跨 PP 组对比，展示 rank 3760 的反向计算更密集

项目详情
异常现象迭代时间增加约 40%
诊断结果rank 3760 的反向计算事件密集，气泡小
根因流水线并行气泡放大效应
特征上游 rank 的气泡被放大，导致整体延迟

7.4 案例4：FlashAttention JIT 编译停顿

案例4：JIT 编译停顿 图 15：L4 Perfetto 追踪，展示 FlashAttention JIT 编译停顿

项目详情
异常现象单步迭代时间异常增加
诊断结果backward-compute-mb7 持续时间增加约 40x
根因FlashAttention JIT 编译导致主机侧停顿
特征稀疏内核启动，主机侧空闲

7.5 案例5：计算落后者被通信掩盖

项目详情
异常现象带外指标（如 GPU 利用率）显示正常
诊断结果计算落后者被通信同步掩盖
根因传统监控工具无法检测此类隐蔽异常
意义证明了细粒度内核级监控的必要性

八、相关工作

8.1 现有系统对比

系统类型粒度开销常开实时分析
Greyhound监控迭代级低是否
Holmes监控链路级低是否
C4监控机器级低是否
MegaScale分析阶段级高否否
EROICA分析内核级5-30%否部分
FLARE分析内核级5-30%否部分
ARGUS混合内核级<2%是是

8.2 技术差异

特性ARGUS其他系统
观察分解三层次互补单一或有限层次
压缩方法在线 KDE 聚类无或简单采样
诊断框架五级渐进式事后手动分析
部署模式常开生产部署按需或实验环境

九、总结

9.1 核心贡献

  1. 低开销监控：三层次分解监控，总开销 <2%，实现常开部署
  2. 高效压缩：基于 KDE 聚类的在线统计压缩，压缩比 3,700x
  3. 渐进式诊断：五级诊断框架，从异常窗口逐步缩小到具体内核
  4. 生产验证：在 10,000+ GPU 集群部署超过 6 个月
  5. 案例覆盖：成功诊断计算落后者、链接退化、流水线气泡、JIT 停顿等多种异常

9.2 技术影响

  • 运维效率：大幅减少大规模训练集群的性能诊断时间
  • 资源利用率：通过及时发现和修复性能问题，提高 GPU 资源利用率
  • 可观测性标准：为大规模分布式训练系统树立了新的可观测性标准

9.3 局限性

  • 诊断深度：L4/L5 仍需手动分析，自动化程度有限
  • 异常类型：主要针对 fail-slow 问题，对其他类型异常的覆盖有限
  • 部署复杂度：需要在训练代码中集成插桩，增加部署复杂度

十、参考资源

10.1 论文链接

10.2 关键图表

图表说明路径
图 1Fail-slow 现象展示figure-1-fail-slow-a.png, figure-1-fail-slow-b.png
图 2训练执行层次结构figure-2-hierarchical-structure.png
图 3ARGUS 整体架构figure-3-architecture.png
图 4数据流水线架构figure-4-data-pipeline.png
图 5重复内核执行模式figure-5-kernel-patterns.png
图 6KDE 聚类可视化figure-6-kde-clustering-a.png, figure-6-kde-clustering-b.png
图 7内核统计异常检测figure-7-anomaly-detection-a.png, figure-7-anomaly-detection-b.png, figure-7-anomaly-detection-c.png
图 8训练时间对比figure-8-training-time-a.png, figure-8-training-time-b.png
图 9内存占用对比figure-9-memory-footprint-a.png, figure-9-memory-footprint-b.png
图 10案例1：计算落后者figure-10-case1-straggler-a.png, figure-10-case1-straggler-b.png
图 11案例2：距离矩阵figure-11-case2-distance-a.png, figure-11-case2-distance-b.png, figure-11-case2-distance-c.png
图 12案例2：L4 追踪figure-12-case2-l4-trace.png
图 13案例3：流水线气泡figure-13-case3-pipeline-bubble.png
图 14案例3：跨组对比figure-14-case3-cross-group.png
图 15案例4：JIT 停顿figure-15-case4-jit-stall.png

10.3 相关论文

论文作者年份关系
GreyhoundWu et al.2025性能诊断
HolmesYao et al.2025异常检测
C4Dong et al.2025集群监控
MegaScaleJiang et al.2024大规模训练
EROICAGuan et al.2026性能分析
FLARECui et al.2026故障诊断
PerfettoGoogle2024追踪可视化

10.4 关键技术术语

术语英文说明
Fail-slowFail-slow性能降级但不触发错误
分解观察Decomposed Observation三层次互补监控
渐进式诊断Progressive Diagnosis五级诊断框架
内核事件压缩Kernel Event Compression在线统计压缩
观察者效应Observer Effect分析工具影响被观察系统
KDE 聚类KDE Clustering核密度估计聚类
Wasserstein 距离Wasserstein Distance分布差异度量

分析完成时间：2026年6月22日 分析工具：Claude Code + paper-analyzer skill + agent-browser