Minder: Faulty Machine Detection for Large-scale Distributed Model Training
作者/机构: Yangtao Deng(1), Xiang Shi(2), Zhuo Jiang(2), Xingjian Zhang(1), Lei Zhang(2), Zhang Zhang(2), Bo Li(2), Zuquan Song(2), Hang Zhu(2), Gaohong Liu(2), Fuliang Li(3), Shuguang Wang(2), Haibin Lin(2), Jianxi Ye(2), Minlan Yu(4)
(1)Tsinghua University, (2)ByteDance, (3)Northeastern University, (4)Harvard University
A1 主要贡献
本文旨在解决大规模分布式模型训练中关键的故障机器检测问题。在生产环境中,训练任务平均每天可能遇到两次故障,导致任务暂停数小时,现有的人工排查方法耗时费力且效率低下。为解决此问题,本文提出了Minder,一个用于分布式训练任务的自动故障机器检测器。Minder的核心思想是自动且高效地检测故障机器上独特的监控指标模式,这些模式在整个训练任务停止前会持续一段时间。
核心问题与研究目标:
- 问题: 大规模分布式训练中的机器故障频繁发生,但手动诊断过程耗时(平均超过半小时,甚至数天)、耗费人力(涉及多个团队),且现有日志和工具存在通知不及时、内容不完整等缺陷,导致巨大的经济和时间成本。
- 目标: 设计一种能够快速响应运行时故障、准确检测故障机器的自动化方法,从而替代人工排查,提高系统可靠性。
核心创新点与贡献:
1. 深入的故障类型与指标关联研究: 本文对生产环境中发生的故障类型及其与各种监控指标的关联性进行了调查。通过经验性分析,解释了为何某些指标对特定故障更敏感,并明确了故障检测面临的挑战,如故障多样性、任务依赖的正常状态、故障与指标的非一对一关系以及监控数据的噪声问题。
2. Minder的设计思想: 提出了一个基于四个核心思想的故障检测框架:
- 相似性 (Similarity): 利用分布式并行训练中各机器在正常运行时监控指标数据应表现出相似行为的特性。当某台机器发生故障时,其指标模式会与其他机器产生显著差异。
- 连续性 (Continuity): 故障导致的异常性能通常会持续一段时间,而短暂的抖动或噪声则不会。通过检查异常模式的持续时间,可以有效过滤掉误报。
- 基于独立模型的去噪 (Denoising Models): 针对每种监控指标训练独立的学习模型(如LSTM-VAE),用于对原始数据进行去噪和重构,以应对监控数据中的噪声挑战。
- 指标优先级 (Metric Prioritization): 对监控指标按其指示故障的敏感度进行排序,优先使用最敏感的指标进行检测,从而加快检测速度。
3. Minder的实现与评估: 本文详细介绍了Minder的系统实现,并在生产环境中部署超过一年。通过对真实故障场景的评估,验证了Minder的高效性和准确性。消融实验也证明了其各项设计选择的合理性。
4. 实践经验与未来方向: 分享了在实际部署Minder过程中遇到的经验教训,并指出了未来的研究方向。
Minder已在生产环境中部署超过一年,监控着每天涉及数千台机器的分布式训练任务。在真实的故障检测场景中,Minder能够平均在3.6秒内做出响应,精确度达到0.904,F1分数为0.893,大大减少了人工调试时间。
A3 背景知识与关键洞察
2.1 真实生产环境中故障的负面影响
故障对大规模分布式训练任务的危害。 一旦机器出现意料之外的硬件或软件故障,就会在机器层面损害整个分布式训练任务。
故障的频繁性与规模相关。 故障与任务规模显著相关,长时间的训练和大规模的机器集群导致故障频发。图1展示了任务机器规模与每日故障数量之间的关系。根据七个月的统计数据,机器规模可远超1024台,在超过10000个GPU上进行训练。意外故障的发生与任务规模高度相关,平均每天发生两次故障。如果不能快速响应,这种频繁的故障将成为训练大型模型的负担。
单点故障导致大规模任务中断。 根据经验观察,训练过程中的故障通常源于主机问题(如CUDA错误,NVLink错误【5,GPU Metrics】),但这个问题最终可能引发级联效应,导致整个任务中断或显著减速。例如,通信过程中的硬件ECC错误会导致分布式系统中断(例如,在参数服务器【48,M. Li等人,Communication efficient distributed machine learning with the parameter server,NIPS 2014】或All-reduce【65,P. Patarasuk等人,Bandwidth optimal all-reduce algorithms for clusters of workstations,JPDC 2009】模式下运行时),原因是NCCL超时【12,Nvidia NCCL timeout】或网络断连,从而可能导致生产环境中超过五百台机器停止并处于空闲状态。
故障诊断耗时,增加人力和资源成本。 图2显示了2023年七个月的数据中,手动诊断出故障机器所需的时间。平均耗时超过半小时,最长可达数天。这最终导致GPU和NIC资源闲置,解决问题后还会带来额外的时间成本。更多的延迟会给用户带来显著增加的成本和时间需求。
案例:PCIe降级。 在一个真实案例中,一个128台机器的训练任务因PCIe降级(从6.4Gbps降至4Gbps)而被迫严重减速40分钟。通信拥塞最终导致计算资源利用不足,数千个V100 GPU被迫减速40分钟。根据NVIDIA V100的公开租用价格(每GPU 2.48美元【6,GPU Pricing】),这40分钟给客户造成的成本浪费可达650美元。
2.2 现行解决方案及其缺陷
现有手动诊断方法的局限性。 在发生意外故障后,直接的方法是检查机器上现有的软硬件日志,以及使用dmesg
【2,dmesg】,netstat
,top
等命令。然而,此过程存在三个局限性。
诊断触发通知不及时。 首先,工程师仅在任务完全停止后才会收到警报。某些故障会降低模型FLOPs利用率(MFU)从而减慢训练速度,但并未严重到停止任务。只要任务在运行,当前方法就无法检测到性能下降。在PCIe降级案例中,任务会以恶化的性能持续运行一段时间。
审查内容不完整或冗余。 收到故障通知后,会审查训练期间记录的日志或计数器。这些日志通常以纯文本形式维护,包括内置的软件层日志(如NCCL和CUDA日志)、硬件层日志和网络日志。依赖于过往的知识和经验来决定包含和检查哪些日志,导致某些日志内容被忽略。同时,日志不包括GPU功耗、温度和NVLink带宽等监控指标。在PCIe降级案例(2.1节)中,由于未及时从日志中检查到基于优先级的流量控制(PFC)包率等关键监控数据,识别故障机器变得困难。此外,日志内容常包含冗余数据,如环境参数和警告,这会延长检测时间。
诊断分析过程复杂且耗时。 多个团队的工程师参与诊断过程。图2展示了耗时的诊断过程,可能长达数天才能检测到故障机器。
PCIe降级案例的手动诊断流程与故障传播。 该案例的检测总共花费了40分钟,并涉及多个团队。负责人审查了模型相关信息、并行设置【40,Z. Jiang等人,MegaScale: Scaling large language model training to more than 10,000 GPUs,NSDI 2024】、依赖项、环境和框架(如Megatron-LM【68,M. Shoeybi等人,Megatron-lm: Training multi-billion parameter language models using model parallelism,arXiv 2019】)参数。同时,网络团队审查了主机内吞吐量、RDMA流量、丢包/随机性、拥塞指标、驱动和路由。存储和硬件团队检查了HDFS和SSD使用情况、GPU和CPU使用率、NIC健康状况和机器调度。故障从PCIe降级传播到PFC激增。故障机器的PCIe降级后,其NIC缓冲区被填满。随之而来的瓶颈——主机间通信导致PFC发送包激增。拥塞还导致接收到的显式拥塞通知(ECN)和发送的拥塞通知包(CNP)【17,Infiniband Trade Association,RoCEv2】都增加了。结果,所有机器的NIC吞吐量从6.5Gbps下降到4.9Gbps。计算数据的减少导致GPU张量核心使用率下降【7,GPU tensor core utility】,从而降低了训练性能。
2.3 真实世界故障案例研究
故障类型、频率及与监控指标的关联。 为了解决手动日志分析的缺点,我们对七个月内发生的故障类型进行了深入审查。表1显示了常见的故障类型、它们的频率,以及每种故障类型能被某个指标指示出的实例比例。这些比例是通过检查可用实例并量化在故障后监控数据中表现出异常模式的数量来凭经验确定的。监控数据包含多个指标,并每秒采样一次。
关键观察。 首先,硬件故障占大多数(55.8%),其中ECC错误占很大比例(38.9%)。发生在CUDA或GPU中的错误也占很大比例。不幸的是,这些错误难以预测或避免。其次,每个指标显示出指示某种故障类型的概率不同。没有单一指标能有效指示所有故障。ECC错误、NIC掉卡、GPU卡掉卡、NVLink错误、CUDA和GPU执行错误与CPU或GPU指标密切相关。同样,PCIe降级、NIC掉卡和机器不可达与网络指标(如PFC和吞吐量)最相关。对于CPU指标,一台机器上的故障会停止CPU进程,降低其CPU使用率,而其他机器由于Kubernetes管理、NCCL超时设置和心跳机制,会暂时保持进程,因此在任务停止前CPU使用率正常。对于GPU指标,计算过程中的GPU掉卡或进程被杀会导致GPU使用率降低,而其他机器在超时和心跳检查前继续运行CUDA核心,维持正常的GPU使用率。对于PFC指标,当NIC缓冲区因拥塞相关的网络错误而填满时,故障机器上的PFC信号会突然激增,而其他机器的PFC包数量很低。内存使用率也呈现相同趋势。然而,根据我们的经验,磁盘使用率没有表现出显著波动。因此,大多数故障类型与CPU、GPU、内存和PCIe指标密切相关。作为例外,AOC错误发生在交换机或机器侧的线缆上。如果发生交换机AOC错误,连接到该交换机端口的机器会立即受到影响。如此大规模的受影响机器会迅速将负面效应传播给其他机器,用秒级监控数据很难捕捉到异常模式。
2.4 挑战
需要解决的四个核心挑战。 基于以上观察,我们发现必须解决以下挑战:
1. 挑战1:任何机器都可能以多种方式发生故障。 高级机器(如Nvidia DGX-A100【11,Nvidia DGX-A100】)集成了多达8个Nvidia A100 GPU和4个Mellanox 200 Gb/s RDMA NIC(RNIC),所有这些都可能是故障点。如表1所示,故障可能发生在主机内计算、通信,到主机间网络,或从硬件(GPU、CPU、PCIe、NVLink、RNIC、内存和磁盘)到软件通信库(如NCCL)和训练框架(如CUDA)。在所有未知情况下检测故障机器是困难的。
2. 挑战2:监控指标的正常状态是任务相关的。 训练任务具有不同的机器规模、数据大小、模型和训练框架。因此,一个监控指标对于不同的任务可能有不同的正常状态。例如,GPU温度70摄氏度在GPU时钟频率为1350MHz时是异常的,但在GPU工作于1800MHz高时钟频率的任务中则被视为正常。传统的监督式异常检测不适用于区分正常和故障机器状态,因为相同的输入监控数据可能被标记为正常或异常。
3. 挑战3:故障类型与监控指标之间的关系不一定是一对一的。 一方面,一个指标异常可能由多种故障类型引起。例如,CPU使用率下降可能由ECC错误、NVLink错误和其他故障引起。另一方面,对于一种故障类型,没有单一指标必然会发出信号。如表1中的例子,ECC错误可能通过故障机器的CPU或GPU使用率被注意到,但两者都不能保证,也不一定两者都会出现异常。因此,单一故障类型可以通过多个异常指标表现出来,没有单一指标能提供保证性的指示。相反,这些指标对一种故障类型表现出“或”的关系。因此,我们不能简单地使用一个包含所有指标数据的模型,而是为每个指标使用单独的模型进行检测(分析见6.3节)。
- 挑战4:时间序列监控数据中存在噪声。 监控数据不可避免地包含由于抖动、不准确的传感器、温度、时间戳未对齐、网络中断或其他问题引起的噪声。短期噪声会误导我们将一台机器视为故障机器,导致额外的时间和人力负担。因此,原始数据不能直接用于检测(分析见6.3节)。
A2 方法细节
3 设计概览
本节介绍Minder的四个设计选择,旨在应对上述挑战。Minder是一个自动、响应迅速且准确的观察器,用于检测在分布式训练中导致任务停止的意外故障机器。我们首先检查机器间的相异性 (dissimilarity)(3.1),然后评估检测到的故障候选机器的连续性 (continuity)(3.2)以过滤掉突发抖动。由于指标数据含有噪声,我们使用模型对原始数据进行去噪和重构,具体地,为不同监控指标训练独立的模型,而不是将它们集成到一个模型中(3.3)。我们还对指标进行优先级排序(3.4),通过排名靠前的指标及其相应模型可以迅速检测到故障机器。
3.1 机器级相似性
利用并行训练中的行为相似性。 为了应对挑战1和2,我们注意到在并行分布式训练【68,M. Shoeybi等人,Megatron-lm: Training multi-billion parameter language models using model parallelism,arXiv 2019】中,机器级的指标数据在秒级粒度上表现出相似的行为。数据并行(DP)通过在存储重复模型参数和优化器状态的GPU之间平均分配数据来运作。流水线并行(PP)以流水线方式将模型层分配给多个GPU。在张量并行(TP)中,每个GPU执行计算过程的一部分以并行提高硬件利用率。通过将这些技术集成到3D并行框架中,可以有效地促进大规模模型训练,如LLM训练【40,Z. Jiang等人,MegaScale: Scaling large language model training to more than 10,000 GPUs,NSDI 2024】或多模态训练。TP通常限制在单台机器内,而DP或PP组涉及主机间通信。计算、存储和通信负载在秒级上均匀分布于各机器。因此,各机器会观察到相似的监控数据波动。在PCIe降级案例中,图3中所有机器初始的PFC Tx包速率模式非常一致。然而,如果一台机器出现故障,其监控数据将显示出明显的差异,为检测提供了机会。这一原则可以扩展到其他指标,如表1所示。因此,每台机器去噪后的指标数据用于计算与其他机器的相似性。与他者“距离”最远的机器可被假定为故障机,无论故障类型如何。
为何不使用监督学习模型。 与许多基于监督学习的异常检测方法【21, 27, 45, 53】不同,由于问题背景不同,Minder使用无监督学习和基于相似性的距离检查。首先,将数据标记为正常或异常是不切实际的。如挑战2所述,异常模式是任务相关的。不同任务在不同的工作条件下,对同一监控指标呈现出不同的正常范围。其次,我们的目标是识别哪台机器是意外故障的罪魁祸首,这不仅仅是一个区分正常或异常情况的分类问题。因此,通过监督训练开发一个通用模型是具有挑战性的。
3.2 机器级连续性
利用异常的持续性过滤噪声。 为了进一步解决挑战2,我们利用了异常连续性的概念。通常,故障发生后,异常性能会持续几分钟,但抖动通常只持续很短时间。如图3所示,PCIe降级的机器在一段时间内经历了比其他机器高得多的PFC Tx包速率。通过检查2023年七个月数据中的故障实例,图4描绘了故障发生后异常性能的持续时间。大多数异常模式持续超过五分钟。因此,如果我们识别出一台机器连续一段时间显示出这种相异性,那么这台机器可能就是故障机器。对于含有突发噪声的原始数据,它们将被过滤掉(分析见6.4节)。
3.3 为每个监控指标建立独立的基于学习的去噪模型
使用独立模型进行数据去噪和重构。 针对挑战4,除了基本的数据对齐和归一化外,我们利用简单的学习模型进行数据去噪和重构。变分自编码器(VAE)和其他生成式概率模型因其学习时间序列数据模式和特征的能力而受到认可【52, 70】。它们也因学习能够推断出大多数训练数据生成因素的嵌入方案而闻名。这使得无监督学习特别适合在异常检测任务中对正常行为进行建模。因此,原始数据在进入进一步检测之前,会由我们基于学习的模型进行去噪和重构(分析见6.3节)。
为每个指标训练独立模型的理由。 同时,基于挑战3,没有单一指标能为特定故障类型提供保证性指示。一个指标的指示概率在不同类型的故障中各不相同。因此,我们选择为每个监控指标训练独立的模型。这些模型及其对应的指标数据被独立用于去噪、相似性和连续性检测。我们不将所有潜在指标合并到一个模型中,主要有两个原因。首先,当故障发生时,多个指标的时间序列波动方式不同。其次,即使对于特定的故障类型,指标的指示能力也不同,而且一个指标的能力在不同类型中也有所变化。因此,将它们集成到一个模型中可能导致模型被众多指标误导或混淆(分析见6.3节)。
3.4 优先化的指标序列
通过指标优先级加速检测。 为了加速检测,我们对指标进行优先级排序,并仅使用排名靠前的指标的模型。由于可以收集大量指标(见附录B),且每个指标都可以训练一个模型,这样做可以确保我们更早地使用具有更高指示概率的指标,从而更快地检测到故障机器。如果一个模型及其关联的指标数据无法检测到故障机器,我们就按照优先级顺序移至下一个指标及其模型。我们重复此过程,直到识别出故障机器。
4 Minder框架
Minder的架构如图5所示。原始数据需要经过预处理(4.1)。每个指标的模型训练(4.2)和监控指标优先级排序(4.3)是两个独立的过程,分别训练模型并根据指标对故障的敏感度进行排序。这些模型和排序结果随后用于在线故障机器检测(4.4)进行实时检测。
4.1 预处理
数据对齐与归一化。 对于来自每台机器的监控数据流,Minder需要将其聚合成一系列时间窗口。在每个窗口内,Minder对一组指标进行数据去噪和机器级相似性检查。通过检查连续时间窗口的异常连续性,Minder检测出故障机器。因此,如果收集到的监控数据在某些指标间缺乏对齐,Minder会对其进行预处理。Minder首先根据相应的采样时间戳对齐所有机器的采样点。如果采样点缺失,Minder使用最近采样时间的数据进行填充。为了确保多维监控数据被整合到一个均匀的分布中,Minder采用Min-Max归一化技术,根据每个指标的上下限对监控数据进行归一化。
4.2 每个指标的模型训练
为每个指标训练独立的无监督模型。 如3.3节所述,我们训练模型用于后续检测的基于学习的去噪和重构。由于没有单一指标能提供保证性指示,且包含各种指标的模型可能会被误导,因此应为每个指标训练独立的模型。每个时间窗口内预处理后的机器数据被用作输入实例来训练一个无监督模型。例如,为了训练CPU使用率的模型,我们从任务的每台机器中使用长度为w(例如8)且步长为1的时间窗口内的CPU使用率样本数据。多个1×w的向量分别被送入模型进行训练。CPU使用率、PFC包速率等的模型被独立训练。模型中的参数包括hidden_size
(例如4)、latent_size
(例如8)和lstm_layer
(例如1)。通过一个模型,来自一台机器的某个监控指标的时间序列输入可以被重构为该机器的一个去噪向量。
模型选择:LSTM-VAE。 具体来说,Minder训练的是VAE模型。VAE广泛用于去噪【70,Y. Su等人,Robust anomaly detection for multivariate time series through stochastic recurrent neural network,KDD 2019】和高维特征压缩【71,M. Sun等人,Ctf: Anomaly detection in high-dimensional time series with coarse-to-fine model transfer,INFOCOM 2021】,其中正常向量将被重构为相似的嵌入,而异常向量将被重塑为更独特的离群点。这种高效的无监督深度学习技术可以将时间序列输入重构为任意的潜在表示,而不牺牲原始特征。因此,VAE可以提高在缺乏标签的异常检测中的准确性和鲁棒性【78,H. Xu等人,Unsupervised anomaly detection via variational auto-encoder for seasonal kpis in web applications,WWW 2018】。当输入主要由正常训练状态向量组成,只有一小部分对应于故障期时,VAE会学习向量分布并对抖动进行去噪。如图6所示,VAE由一个编码器和一个解码器组成。编码器将时间特征提取到一个潜在空间嵌入z中。随后,解码器利用z将数据恢复到一个新的维度输出,作为分布的重构。编码器和解码器中可以采用各种统计或机器学习技术来确定最优分布。鉴于我们的数据是时间序列,我们使用LSTM作为编码器和解码器来提取时间特征【52,S. Lin等人,Anomaly detection for time series using vae-lstm hybrid model,ICASSP 2020】。LSTM考虑时间序列的前向和后向信息以获得完整的对应信息,因此是VAE的理想选择。
4.3 监控指标优先级排序
使用最敏感的指标加速检测。 正如3.4节所述,我们的目标是仅使用最具代表性的指标及其模型来快速检测故障机器。在大量指标中,找出对故障更敏感的指标至关重要。通过首先使用排名靠前的指标及其相关模型,可以更快地检测到故障机器。因此,Minder通过以下步骤生成一个按对故障敏感度排序的指标列表。排序结果随后可用于运行时检测,指定首先使用哪些指标及其模型。请注意,此过程与4.2节中的模型训练过程并行运行。
步骤1:计算Z-score以评估指标敏感度。 为识别最敏感的指标,Minder利用Z-score【23,C. Cheadle等人,Analysis of microarray data using z score transformation,JMD 2003】,因为它描述了数据分布的离散程度。Z-score较高的指标与不平衡的分布有关,其中故障机器显示出与其他机器不同的模式。对于一个监控指标,在每个采样数据点上为每台机器计算Z-score。对于第j个监控指标:
$Z_{ij} = \frac{x_{ij} - \bar{x}_j}{s_j}$
其中,$Z_{ij}$是第i台机器的Z-score,$x_{ij}$是第i台机器的样本值,而$\bar{x}_j$和$s_j$分别是所有机器在第j个指标上的平均值和标准差。当故障发生时,受影响的机器表现出异常行为,导致具有高Z-score的离群样本。对于一个训练任务的时间窗口,我们使用所有机器上第j个监控指标的$max(Z_{ij})$,表示机器间的离散程度。
步骤2:监控指标的优先级排序。 基于每个监控指标的最大Z-score,Minder使用决策树【32, 60】来确定每个指标在识别故障机器方面的敏感度优先级。我们采用决策树主要有两个原因。首先,决策树的逻辑结构类似于网络监控系统中常见的基于规则的策略,例如某些监控器使用简单的阈值规则,如当CPU使用率降至接近零时【83,P. Zhao等人,Advanced correlation-based anomaly detection method for predictive maintenance,ICPHM 2017】。其次,决策树具有高表达性和忠实度,这归因于它们没有参数且能表示复杂的决策过程【22,H. Blockeel等人,Top-down induction of first-order logical decision trees,AI 1998】。为了构建决策树,Minder收集每个指标的最大Z-score(来自步骤1)作为该训练任务时间窗口的单个实例。根据该窗口内是否存在故障机器,该实例被手动标记为正常或异常。跨多个时间窗口和多个训练任务的实例被一起用于训练决策树。如图7所示,监控指标根据其对故障的敏感度进行优先级排序。决策树采用逐步方法,通过分析每个指标的Z-score来分类实例。靠近树根的节点表示相应的监控指标对故障的发生更为敏感。PFC、CPU、GPU和NVLink相关指标被识别为信息量最大的指标。具体来说,CPU使用率与运行进程状态相关,而四个GPU指标与计算状态相关。此外,NVLink带宽和PFC包速率分别指示了主机内和主机间的网络质量。这一结果与表1一致,其中CPU和GPU享有最高优先级。
4.4 在线故障机器检测
结合相似性和连续性进行实时检测。 在运行时检测期间,Minder利用机器级相似性(3.1)和连续性(3.2)的概念,因为故障机器倾向于在一段时间内表现出异常模式。给定每台机器的数据,Minder遵循决策树优先级排序结果的顺序选择一个指标。然后,该指标数据由相关的模型进行去噪。Minder接着运行下面介绍的步骤1和2进行检测。如果没有检测到,Minder选择下一个指标并重复步骤1和2,直到检测到一个为止。幸运的是,如果在遍历所有模型后仍未检测到任何异常,Minder则假定到目前为止没有异常发生。
步骤1:每个时间窗口内基于相似性的距离检查。 为了在一个时间窗口内检测故障机器,Minder比较所有机器在同一指标上的相似性(3.1)。在存在故障机器的情况下,其从LSTM-VAE得到的去噪数据将与其他的区分开来。为了在一个时间窗口内启动检测,每台机器的监控数据(例如,一台机器的一个1×w向量)被相继送入相应的模型。Minder捕获第i台机器的重构嵌入用于后续的距离计算。具体来说,Minder计算每两台机器之间嵌入的成对欧几里得距离,因为它能表达正常和异常样本之间的明显差异并提供各种记录类型的特征【76,D. J. Weller-Fahy等人,A survey of distance and similarity measures used within network intrusion anomaly detection,IEEE Communications Surveys & Tutorials 2014】。对于每台机器,Minder计算其到其他机器的距离之和,代表其相异性。由于距离大小随机器规模变化,我们为每台机器的距离总和值计算正常分数以进行归一化。正常分数最高的机器可能是故障机器。如果最大正常分数高于一个相似性阈值,该机器被假定为该时间窗口的候选者。
步骤2:连续时间窗口的连续性检查。 一个时间窗口检测到的候选者可能是由于瞬间的突发或暂时的计数器噪声引起的误报,因此连续性(3.2)的思想至关重要。这是因为故障通常会导致一段时间的性能恶化。Minder以一个步长移动时间窗口,为新的窗口检测潜在的故障机器。如果同一台机器被连续检测到的次数超过一个连续性阈值,它就被认为是真正的故障机器。一个合适的连续性阈值可以设置为4分钟,因为它足以过滤掉短期噪声,并且不会超过图3中恶化性能的典型持续时间。
5 实施
Minder的部署环境与工作流程。 Minder已在我们的机器学习系统中部署了一年。它运行在一台专用机器上,该机器配备两个双端口ConnextX-6 25G-RNIC【9,NVIDIA ConnectX-6 Dx Network Adapters】,128个Intel Xeon Platinum 8336C CPU,512G内存和1.6T磁盘。高速RNIC确保了监控数据的快速传输,而计算和存储资源足以进行实时检测。Minder在其整个生命周期内监控所有正在进行的训练任务。对于一个任务,Minder会按预定间隔(例如,每8分钟)被调用一次。每次调用时,Minder会从一个数据库中为与该任务相关的所有机器拉取附录B中所列指标的15分钟数据。这些指标涵盖了计算、通信和存储方面。该数据库每秒从所有机器更新监控数据。如果Minder识别出故障机器,会向一个驱动程序和相关工程师触发警报。驱动程序提交要屏蔽的机器IP和Pod信息给Kubernetes后,故障机器将被驱逐并由新机器替换,然后从最近的检查点快速恢复【40,Z. Jiang等人,MegaScale: Scaling large language model training to more than 10,000 GPUs,NSDI 2024】。重要的是,Minder的运行不会干扰在线的分布式训练任务,因为它作为一个后端服务工作。
任务工作负载。 被监控的训练任务分布在4到超过1000台机器上,一个任务的GPU数量可达10000个以上。Minder可以监控并发任务。每个任务都在具有同构GPU和RNIC架构的机器上运行,这些机器采用最多三层交换机的轨道优化拓扑。用于计算的TP、用于梯度计算和传播的PP以及执行梯度同步的DP被高效地用于我们的LLM预训练。这些3D并行策略【40,Z. Jiang等人,MegaScale: Scaling large language model training to more than 10,000 GPUs,NSDI 2024】、【68,M. Shoeybi等人,Megatron-lm: Training multi-billion parameter language models using model parallelism,arXiv 2019】(3.1)促进了跨机器的计算(GPU使用率、功耗、温度等)、存储(内存使用率等)和通信(主机内和主机间吞吐量)的平衡。在我们的机器学习系统中训练的模型包括Transformer【74,A. Vaswani等人,Attention is all you need,NeurIPS 2017】等。模型大小从小于32B到超过500B不等。
A4 实验环境与结果
实验环境总结
- 数据集: 包含150个来自线上分布式训练任务的运行时故障实例,数据跨度九个月。任务规模从4台到超过1500台机器(最多10,000个NVIDIA Ampere GPU),覆盖了图1中的所有规模组。30%的任务至少涉及600台机器。数据集覆盖了表1中列出的所有故障类型,主要包括ECC错误(25.7%)、CUDA执行错误(15%)、GPU执行错误(10%)和PCIe降级(8.6%)。数据集专注于单机故障,因为这占生产环境中99%的故障案例。监控指标(附录B)以秒级粒度收集。使用前三个月的数据进行LSTM-VAE训练,其余数据用于评估。
- 模型架构: Minder使用LSTM-VAE模型,其关键参数包括:
hidden_size
为4,latent_size
为8,lstm_layer
为1。 - 硬件配置:
- Minder服务器: 专用机器,配备2个双端口ConnextX-6 25G-RNIC,128核Intel Xeon Platinum 8336C CPU,512GB内存,1.6T磁盘。
- 训练集群: 机器配备NVIDIA V100或NVIDIA Ampere GPU,采用最多三层交换机的轨道优化拓扑。
- 软件配置:
- 训练框架: Megatron-LM【68】等。
- 并行策略: 3D并行(数据并行、流水线并行、张量并行)【40】。
- 通信库: NCCL。
- Minder系统: 作为后端服务运行,从数据库拉取监控数据,并通过驱动程序与Kubernetes交互以驱逐故障机器。
实验结果总结
6.1 总体性能
- 处理时间: Minder每次调用平均耗时3.6秒(包括数据拉取和处理),相比人工排查(图2)时间缩短了99%以上(快500倍)。(图8)
- 与基线对比: 与广泛用于离群点检测的马氏距离(MD)【30, 46, 57】相比,Minder的精确度(0.904 vs 0.788)和F1分数(0.893 vs 0.777)均更高。这表明Minder通过LSTM-VAE去噪能有效抵抗噪声干扰,优于MD的统计特征方法。(图9)
- 按故障类型划分的性能: Minder对ECC错误、CUDA执行错误、GPU掉卡、机器不可达等与CPU/GPU状态和网络性能相关的故障检测效果很好。对于GPU执行错误和PCIe降级,由于存在单机内并发故障(多个GPU或PCIe链路),故障会通过3D并行迅速扩散,导致秒级监控粒度不足,召回率较低。AOC错误由于缺少相关硬件计数器也部分被遗漏。(图10)
- 按任务生命周期内故障次数划分的性能: 任务生命周期内的故障次数不影响Minder的准确性,因为故障是随机的且故障机器会被立即替换。(图11)
6.2 监控指标选择分析
- 实验对比了使用更少或更多GPU相关指标的性能。结果表明,使用更多指标会引入干扰,降低精确度;使用更少指标则会因缺少关键信息而降低检测能力。Minder选择的指标集在精确度上达到了最佳效果,证明其指标优先级排序(4.3节)是有效的。(图12)
6.3 模型选择分析
- 将Minder与三种变体进行比较:直接使用原始数据(RAW)、合并所有模型嵌入(CON)、训练一个包含所有指标的集成模型(INT)。结果显示,Minder在召回率和F1分数上均优于其他方法。RAW的性能差证明了去噪的重要性。CON和INT的性能较差是因为它们平等对待所有指标,而不同指标对故障的敏感度不同,导致了相互干扰。Minder通过独立的LSTM-VAE模型有效避免了此问题。(图13)
6.4 连续性与阈值分析
- 移除连续性检查(3.2节)后,系统性能下降,误报增多,因为无法过滤掉由短期抖动引起的假阳性。这证实了检查异常持续性的必要性。Minder设置的4分钟连续性阈值是根据真实故障持续时间(图4)凭经验选择的,旨在平衡误报率和漏报率。(图14)
6.5 距离度量选择
- 将欧几里得距离与曼哈顿距离(MhtD)和切比雪夫距离(ChD)进行比较。结果显示,性能相似,表明LSTM-VAE生成的嵌入已经足够有代表性,使得离群点在任何距离度量下都很明显。Minder使用的欧几里得距离考虑了整体空间分布,效果稳健。(图15)
6.6 多台并发故障机器的性能
- Minder处理并发故障的能力取决于故障机器比例和监控数据粒度。在生产环境中,并发故障(如交换机重启导致32/600台机器离线)由于故障比例高、传播快和秒级监控粒度粗,难以被Minder检测。
- 然而,通过在4台机器中对2台注入PCIe降级故障,并使用定制的毫秒级监控,Minder成功检测到了两台故障机器。毫秒级数据显示,故障NIC的吞吐量模式与正常NIC显著不同(图16),证明了Minder在细粒度数据下的潜力。
A7 补充细节
Minder与其他监控工具的关系。 大规模模型训练需要多团队协作。除Minder外,还使用了其他监控工具,如交换机状态监控、周期性心跳消息、RDMA流量限制警报、类pingmesh的连接测试(RPingmesh【54】)以及用于GPU错误检测的自动文本分析。这些工具主要关注网络连接、抖动或GPU状态,而Minder覆盖了计算、存储和通信资源,它们的结合使用增强了检测效果。同时,DCGM【1】、EUD【3】等离线测试工具用于主机内瓶颈诊断,但不适用于运行时故障识别。与SuperBench【77】这类主动验证系统相比,Minder是实时监控系统。SuperBench通过运行基准测试来识别性能退化,主要关注硬件可靠性,而Minder也处理实时软件错误。将这类主动系统与Minder集成是一个有前景的调试解决方案。
Minder的通用性。 Minder可以扩展到更细的数据粒度(如毫秒级)和更广的指标范围。如6.6节所示,毫秒级监控数据能提升Minder对并发故障的检测能力,因为训练迭代仅持续数十毫秒,细粒度数据能揭示快速的故障传播过程。此外,Minder目前使用带外硬件计数器,未来可以利用其他指标(如AOC计数器)和带内追踪(如Torch Profiler【16】、Megatron-LM计时器或CUDA事件计时器【40】)来获取更精细的训练和通信操作信息。
Minder对其他故障的鲁棒性。 Minder能够检测训练中未覆盖的新或罕见故障类型,只要监控数据呈现出可辨别的相异性。对于并发故障机器,只要多台机器呈现出独特的相异性,Minder就能同时检测到它们。
机器级相似性。 大规模模型(如LLM和多模态任务)通常采用3D并行,导致机器间的计算、通信和存储趋于一致,这使得Minder能够检测故障机器。因此,我们专注于机器级检测而非更细的粒度。我们也考虑将Minder应用于其他工作负载,如大规模推理和微调,只要这些工作负载满足机器间指标相似性和故障连续性的要求。未来工作将探索Minder在其他工作负载中的有效性。
并非所有失败任务都有正确的标签。 尽管标记的机器是根本原因,但Minder检测到的机器也可能存在暂时的性能波动。有必要将此类性能抖动告知工程师。
根本原因分析。 Minder在机器级别检测故障,但由某个指标指示的故障根本原因是不确定的。需要额外的人力进行进一步的网络抖动和短期掉队者分析。未来,我们计划设计细粒度的运行时监控以进行根本原因识别。
A5 结论
本文介绍了Minder,一个解决分布式训练任务中故障机器检测问题的系统。Minder利用了训练期间机器间的相似性以及故障的连续性这两个核心概念。Minder已在我们的生产环境中部署一年,协助工程师进行训练诊断。评估结果表明,Minder显著减少了故障诊断所需的时间,并且其设计选择对训练任务是有效的。
A6 附录
A 故障类型
表1中列出的故障类型如下:
- ECC错误 (ECC error): (GPU)内存中数据损坏或丢失导致。
- PCIe降级 (PCIe downgrading): 链路故障导致PCIe发送/接收速率变慢。
- NIC掉卡 (NIC dropout): 操作系统中缺少一个NIC。
- GPU卡掉卡 (GPU Card drop): GPU卡断开连接。
- NVLink错误 (NVLink error): 两个Nvidia GPU之间的链路故障。
- AOC错误 (AOC error): 主机网卡或交换机侧的高速有源光缆(AOC)发生错误。
- CUDA执行错误 (CUDA execution error): 意外的溢出或配置错误导致CUDA程序失败。
- GPU执行错误 (GPU execution error): 意外的页错误、内存不足和其他不正确的处理导致GPU挂起或其他结果。
- HDFS错误 (HDFS error): 加载或保存检查点时发生HDFS连接超时、IO错误等。
- 机器不可达 (Machine unreachable): 主要由于SSH服务或虚拟机服务故障。
- 其他 (Others): 非法内存访问、调度失败、无磁盘存储、资源使用率低、交换机重启等。
B 收集的监控指标
表2包含了我们在生产环境中选择收集的监控指标,尽管只有一部分用于训练和检测。Minder也可以使用其他可用的主机指标。
参考文献引用汇总
- 【1, DCGM Diagnostics】: 引用自 A7 补充细节,作为离线诊断工具的例子。
- 【2, dmesg】: 引用自 A3 背景知识,用于描述当前手动检查日志的工具。
- 【3, Extended Utility Diagnostics (EUD)】: 引用自 A7 补充细节,作为离线诊断工具的例子。
- 【5, GPU Metrics】: 引用自 A3 背景知识,用于描述主机问题,如NVLink错误。
- 【6, GPU Pricing】: 引用自 A3 背景知识,用于计算PCIe降级案例中的经济损失。
- 【7, GPU tensor core utility】: 引用自 A3 背景知识,用于解释PCIe降级导致GPU利用率下降的现象。
- 【9, NVIDIA ConnectX-6 Dx Network Adapters】: 引用自 A2 方法细节,描述Minder服务器的硬件配置。
- 【11, Nvidia DGX-A100】: 引用自 A3 背景知识,作为高级计算节点的例子,说明其复杂性和潜在故障点。
- 【12, Nvidia NCCL timeout】: 引用自 A3 背景知识,用于解释硬件错误如何导致分布式系统中断。
- 【16, torch profiler】: 引用自 A7 补充细节,作为Minder未来可利用的带内追踪工具。
- 【17, Infiniband Trade Association. RoCEv2 (IP routable RoCE). 2014】: 引用自 A3 背景知识,用于解释拥塞通知包(CNP)的概念。
- 【21, B. Arzani, et al. {PrivateEye}. NSDI 20】: 引用自 A2 方法细节,作为监督学习异常检测方法的例子。
- 【22, H. Blockeel and L. De Raedt. Top-down induction of first-order logical decision trees. Artificial intelligence, 1998】: 引用自 A2 方法细节,用于解释选择决策树进行指标优先级排序的原因(高表达性和忠实度)。
- 【23, C. Cheadle, et al. Analysis of microarray data using z score transformation. The Journal of molecular diagnostics, 2003】: 引用自 A2 方法细节,用于解释使用Z-score评估指标敏感度的方法。
- 【27, J. Gao, et al. Scouts. SIGCOMM 2020】: 引用自 A2 方法细节,作为监督学习异常检测方法的例子。
- 【30, H. Ghorbani. Mahalanobis distance and its application for detecting multivariate outliers. Facta Universitatis, 2019】: 引用自 A4 实验结果,作为实验对比的基线算法。
- 【32, R. Guidotti, et al. A survey of methods for explaining black box models. ACM computing surveys (CSUR), 2018】: 引用自 A2 方法细节,作为使用决策树进行指标优先级排序的参考文献。
- 【40, Z. Jiang, et al. {MegaScale}: Scaling large language model training to more than 10,000 {GPUs}. NSDI 24】: 在全文多处引用,用于描述大规模LLM训练的3D并行框架、检查点恢复机制、以及Minder未来可利用的带内计时器。
- 【45, N. Laptev, et al. Generic and scalable framework for automated time-series anomaly detection. KDD 2015】: 引用自 A2 方法细节,作为监督学习异常检测方法的例子。
- 【46, C. Leys, et al. Detecting multivariate outliers. Journal of experimental social psychology, 2018】: 引用自 A4 实验结果,作为实验对比的基线算法。
- 【48, M. Li, et al. Communication efficient distributed machine learning with the parameter server. NIPS 2014】: 引用自 A3 背景知识,作为分布式训练中参数服务器(PS)架构的例子。
- 【52, S. Lin, et al. Anomaly detection for time series using vae-lstm hybrid model. ICASSP 2020】: 引用自 A2 方法细节,用于支持使用LSTM作为VAE的编码器和解码器来提取时间特征。
- 【53, D. Liu, et al. Opprentice. IMC 2015】: 引用自 A2 方法细节,作为监督学习异常检测方法的例子。
- 【54, K. Liu, et al. R-pingmesh. SIGCOMM 2024】: 引用自 A7 补充细节,作为与Minder协同使用的监控工具之一。
- 【57, P. C. Mahalanobis. On the generalized distance in statistics. Sankhya, 2018】: 引用自 A4 实验结果,作为实验对比的基线算法。
- 【60, Z. Meng, et al. Interpreting deep learning-based networking systems. SIGCOMM 2020】: 引用自 A2 方法细节,作为使用决策树进行指标优先级排序的参考文献。
- 【65, P. Patarasuk and X. Yuan. Bandwidth optimal all-reduce algorithms for clusters of workstations. JPDC 2009】: 引用自 A3 背景知识,作为分布式训练中All-reduce通信模式的例子。
- 【68, M. Shoeybi, et al. Megatron-lm. arXiv 2019】: 在全文多处引用,用于描述大规模模型训练框架和并行训练技术。
- 【70, Y. Su, et al. Robust anomaly detection for multivariate time series through stochastic recurrent neural network. KDD 2019】: 引用自 A2 方法细节,用于说明VAE模型在时间序列数据去噪和模式学习中的应用。
- 【71, M. Sun, et al. Ctf: Anomaly detection in high-dimensional time series with coarse-to-fine model transfer. INFOCOM 2021】: 引用自 A2 方法细节,用于说明VAE模型在高维特征压缩中的应用。
- 【74, A. Vaswani, et al. Attention is all you need. NIPS 2017】: 引用自 A2 方法细节,作为Minder监控的大规模模型之一(Transformer)。
- 【76, D. J. Weller-Fahy, et al. A survey of distance and similarity measures used within network intrusion anomaly detection. IEEE Communications Surveys & Tutorials, 2014】: 引用自 A2 方法细节,用于解释选择欧几里得距离进行相似性度量的原因。
- 【77, Y. Xiong, et al. SuperBench. USENIX ATC 24】: 引用自 A7 补充细节,作为相关工作进行比较,说明Minder与主动验证系统的不同。
- 【78, H. Xu, et al. Unsupervised anomaly detection via variational auto-encoder for seasonal kpis in web applications. WWW 2018】: 引用自 A2 方法细节,用于说明VAE在无标签异常检测中的准确性和鲁棒性。
- 【83, P. Zhao, et al. Advanced correlation-based anomaly detection method for predictive maintenance. ICPHM 2017】: 引用自 A2 方法细节,作为基于规则的监控策略的例子,以支持决策树选择的合理性。
💬 评论讨论
欢迎在这里分享您的想法和见解!