{"id":"IL-0476","org":"ByteDance","date":"2025-04-26","docs":[],"title":{"en":"PCIe downgrade on one machine slowed a 128-machine V100 training job for 40 minutes through a PFC surge","ko":"ByteDance의 128대 V100 학습 작업이 머신 한 대의 PCIe 저하로 40분 동안 크게 느려졌다"},"domain":["ai-infra","networking"],"impact":{"scope":"128-machine training task on thousands of V100 GPUs slowed severely for 40 minutes; NIC throughput on all machines fell from 6.5Gbps to 4.9Gbps","users":"unknown","region":"unknown"},"review":{"written_by":"session","reviewed_at":null,"reviewed_by":null},"lessons":{"en":"Some faults slow a task without stopping it, and alerting that waits for a halted task misses them. Logs alone are incomplete because they do not contain monitoring metrics such as PFC packet rates, and no single metric reveals every fault type, so ByteDance compares machines with each other on several metrics and treats a difference that lasts for minutes as a fault.","ko":"작업이 완전히 멈출 때만 알리는 방식으로는 학습을 느리게만 하는 고장을 잡지 못한다. 엔지니어가 경험에 기대 볼 로그를 고르면 일부 내용을 빠뜨린다. 게다가 로그에는 GPU 전력, 온도, NVLink 대역폭, PFC 패킷 비율 같은 모니터링 지표가 없다. 여러 팀이 함께하는 수동 진단은 시간이 오래 걸린다. 분산 학습에서는 머신마다 부하가 고르게 나뉘므로 모니터링 지표도 비슷하게 움직이고, 한 머신만 다른 패턴을 몇 분 넘게 보이면 그 머신이 고장 났을 가능성이 높다."},"related":[],"sources":[{"url":"https://arxiv.org/abs/2411.01791","kind":"paper","archived":"https://web.archive.org/web/20260820154622/https://arxiv.org/abs/2411.01791"}],"summary":{"en":"The Minder paper by ByteDance describes faulty-machine detection for its production training clusters, where seven months of data show about two faults a day and manual diagnosis that took over half an hour on average and sometimes days. Its example is a 128-machine training task in which one machine's PCIe link, the intra-host bus that connects devices such as GPUs, NICs and SSDs, degraded from 6.4Gbps to 4Gbps. The machine's NIC buffer filled, the resulting bottleneck in inter-host communication made it send a surge of PFC packets, and the congestion raised ECN and CNP counts and cut NIC throughput on all machines from 6.5Gbps to 4.9Gbps. With less data, GPU tensor core usage fell and the whole task ran slower for 40 minutes. The task did not stop, so no alert fired, and engineers from the training, network, storage and hardware teams needed 40 minutes to find the machine.\n\nByteDance built Minder to replace this manual process. It pulls per-second monitoring metrics of every machine from the data APIs, denoises each metric with its own model, and flags the machine whose metrics stay different from the other machines for a period, checking the metrics most sensitive to faults first. In the paper's table of fault types, PCIe downgrading made up 6.6% of faults over seven months and the PFC metric showed an abnormal pattern in 100% of its instances; it was 8.6% of the 150 fault instances in the evaluation dataset. Minder has run in production for over a year and reacts to faults within 3.6 seconds on average.","ko":"ByteDance의 운영 환경에서 128대 머신으로 돌던 분산 학습 작업이 PCIe 저하 때문에 40분 동안 심하게 느려졌다. PCIe는 그래픽 카드, NIC, SSD 같은 장치를 잇는 호스트 안의 고속 직렬 버스다. 고장 난 머신의 PCIe가 6.4Gbps에서 4Gbps로 떨어지자 그 머신의 NIC 버퍼가 가득 찼다. 머신 사이 통신에 병목이 생겨 PFC Tx 패킷이 급증했고, 혼잡 때문에 ECN 수신과 CNP 송신도 늘었다. 그 결과 모든 머신의 NIC 처리량이 6.5Gbps에서 4.9Gbps로 떨어졌고, 계산할 데이터가 줄어 GPU 텐서 코어 사용률이 내려가 학습 성능이 떨어졌다.\n\n작업이 계속 돌았기 때문에 작업이 멈출 때만 울리는 알림은 오지 않았다. 담당 엔지니어와 네트워크, 스토리지, 하드웨어 팀이 각자 영역을 손으로 뒤졌고, 고장 난 머신을 찾기까지 모두 40분이 걸렸다. PFC 패킷 비율 같은 결정적인 모니터링 데이터는 로그에서 제때 확인되지 않았다. ByteDance는 이런 수동 진단을 대신할 Minder를 만들어 모든 분산 학습 작업에 배포했다. Minder는 머신마다 모니터링 지표를 비교해, 다른 머신과 다른 패턴이 한동안 이어지는 머신을 찾는다."},"trigger":{"en":"The PCIe link of one machine degraded from 6.4Gbps to 4Gbps during the training task.","ko":"머신 한 대의 PCIe 링크가 6.4Gbps에서 4Gbps로 떨어졌다."},"severity":"unknown","symptoms":["throughput-degraded"],"timeline":{"detected_after":"40m","resolved_after":null},"date_kind":"published","detection":{"en":"No alert fired because alerts came only when a task stopped. Engineers from several teams found the faulty machine by manual diagnosis, which took 40 minutes.","ko":"작업이 멈추지 않아 알림이 오지 않았다. 여러 팀이 40분 동안 손으로 진단한 끝에 고장 난 머신을 찾았다."},"components":["pcie-link","infiniband"],"root_cause":"hardware-failure","remediation":[],"action_items":[{"text":{"en":"Detect faulty machines automatically during training by comparing each machine's per-second monitoring metrics with the other machines (Minder)","ko":"모니터링 지표로 고장 난 머신을 자동으로 찾는 Minder를 설계하고 구현해 모든 분산 학습 작업에 배포한다."}}],"contributing":["no-alert-on-limit"],"recurrence_of":null,"symptoms_text":{"en":"A distributed training task on 128 machines in ByteDance's production environment slowed down severely for 40 minutes but kept running, holding thousands of V100 GPUs at reduced speed. The alerting in place notified engineers only when a task stopped completely, so the slowdown itself raised no alert.\n\nThe NIC throughput of all machines in the task dropped from 6.5Gbps to 4.9Gbps, and GPU tensor core usage fell because less data reached the GPUs. On one machine the PFC Tx Packet Rate, the count of Priority-based Flow Control (PFC) packets sent by its RDMA devices, surged far above the other machines, whose PFC patterns had been uniform before the fault. Explicit Congestion Notifications (ECN) received and Congestion Notification Packets (CNP) sent also rose.\n\nFinding the faulty machine took 40 minutes and several teams. The engineer in charge checked model information, parallelism settings, dependencies and environment and Megatron-LM parameters; the network team checked intra-host throughput, RDMA traffic, packet loss, congestion indicators, drivers and routing; the storage and hardware teams checked HDFS and SSD usage, GPU and CPU usage, NIC health and machine scheduling. The PFC packet rates that pointed at the machine were not inspected promptly, because the logs engineers read do not contain monitoring metrics of that kind.","ko":"128대 머신으로 돌던 분산 학습 작업이 멈추지는 않고 40분 동안 심하게 느려졌다. 수천 개의 V100 GPU가 그동안 계산 자원을 다 쓰지 못한 채 느리게 돌았다.\n\n모든 머신의 NIC 처리량이 6.5Gbps에서 4.9Gbps로 떨어졌고, GPU 텐서 코어 사용률도 내려갔다. 혼잡 지표인 ECN 수신과 CNP 송신이 함께 늘었다.\n\n처음에는 모든 머신의 PFC Tx Packet Rate가 비슷했다. 그러다 고장 난 머신 한 대에서만 PFC Tx Packet Rate가 다른 머신보다 훨씬 높은 상태가 한동안 이어졌다.\n\n작업이 멈추지 않았기 때문에 알림은 오지 않았다. 기존 방식은 작업이 완전히 멈춰야 엔지니어에게 알렸다. 그래서 작업을 멈추지는 않고 MFU만 떨어뜨리는 저하는 잡지 못했다. MFU는 모델 FLOPs 사용률이다.\n\n고장 난 머신을 찾는 데 40분이 걸렸고 여러 팀이 매달렸다. 담당 엔지니어는 모델 정보, 병렬화 설정, 의존성, 환경 변수, Megatron-LM 같은 프레임워크 매개변수를 살폈다. 네트워크 팀은 호스트 안 처리량, RDMA 트래픽, 패킷 손실, 혼잡 지표, 드라이버, 라우팅을 봤다. 스토리지 팀과 하드웨어 팀은 HDFS와 SSD 사용량, GPU와 CPU 사용률, NIC 상태, 머신 스케줄링을 확인했다. 결정적인 단서인 PFC 패킷 비율을 로그에서 제때 확인하지 못해 고장 난 머신을 찾기 어려웠다."},"updated_at":"2026-11-14T12:34:12.267119Z","url":"https://benchlet.com/incidentlib/app/cases/IL-0476","org_slug":"bytedance"}