{"id":"IL-0025","org":"Imbue","date":"2024-06-25","docs":["https://github.com/imbue-ai/cluster-health","https://docs.nvidia.com/deeplearning/nccl/archives/nccl_2114/user-guide/docs/troubleshooting.html#pci-access-control-services-acs"],"title":{"en":"Failed boots, InfiniBand link flapping, NCCL hangs and throughput sags while bringing up a 4,088-GPU H100 training cluster","ko":"H100 4,088개 클러스터를 구축하는 동안 InfiniBand 배선 오류, 링크 플래핑, GPU 와 PCIe 하드웨어 결함이 학습을 멈추거나 늦췄다"},"domain":["ai-infra","networking"],"impact":{"scope":"One training cluster of 4,088 H100 GPUs during bring-up and the training runs on it","users":"unknown","region":"unknown"},"review":{"written_by":"session","reviewed_at":null,"reviewed_by":null},"lessons":{"en":"Keep 10 to 20% more machines than a run needs, and network them so any working subset can be used. On the newest hardware expect about 3% of machines to break each week, mostly the same few machines breaking in different ways, so growing a set of known reliable \"golden\" hosts works better than chasing random failures. Write tests and automation for every kind of failure met, because each one comes back, and write tools that make opaque errors readable. Change only one thing at a time, and double-check the claims of new tools and people before building on them.","ko":"대형 GPU 클러스터에서는 연결 하나만 조금 불안해도 전체 학습이 느려질 수 있다. Imbue 는 학습에 필요한 것보다 10-20% 많은 기계를 두면 고장 난 기계를 쉽게 바꿔 다시 시작할 수 있다고 정리했다. 학습 중 겪는 문제는 모두 다시 일어나므로, 겪은 하드웨어와 소프트웨어 장애마다 테스트와 자동 처리를 만들 가치가 있다. 알아보기 어려운 오류 메시지마다 그 오류를 읽기 쉽게 만드는 도구를 만드는 것도 마찬가지다. Imbue 는 재현성을 지키려고 아주 단순한 일도 한 번에 하나씩만 바꿨다. 외부 도구를 들이거나 새 사람이 합류하면 그쪽이 내놓은 주장을 다시 확인했고, 다음 단계가 그 결과에 기댈 때는 특히 그렇게 했다. 고장은 고르게 나지 않고 소수의 문제 기계에 몰리므로, 그때그때 고장 나는 기계를 하나씩 고치기보다 믿을 수 있는 기계 묶음을 키우는 편이 낫다."},"related":[],"sources":[{"url":"https://imbue.com/blog/70b-infrastructure","kind":"blog","license":"unknown","archived":"http://web.archive.org/web/20261004002704/https://imbue.com/blog/70b-infrastructure"}],"summary":{"en":"Imbue's write-up is a guide to the infrastructure it built to train a 70B-parameter model, not a report on one outage. It covers one cluster of 4,088 H100 GPUs on 511 hosts, where each GPU has its own ConnectX-7 card at 400 Gbps on a three-tier, fully non-blocking InfiniBand network, set up with Voltage Park, Dell, H5 and NVIDIA. Training at full speed needed every one of over 12,000 connections to work.\n\nMachines were provisioned through Dell iDRAC and Ubuntu MAAS. The MAAS integration with the BMC was unreliable, so MAC addresses were collected through the iDRAC API in advance, and on the first provisions the clocks were so far off that HTTPS certificate validation stopped apt from installing anything. About 10% of hosts failed to boot for hardware reasons and were sent back to Dell or to data center staff. GPU errors were mostly fixed by reseating the cards, the internal PCIe cables had to be reseated on about a quarter of the hosts, Dell fixed a number of rarer faults with firmware upgrades, and a bad NVIDIA driver behind wrong temperature readings was downgraded to the previous version.\n\nThe top tier of the InfiniBand fabric had been designed as eight disconnected networks with no common routing paths. It was rewired, and checks were added that the physical connections matched the new design. Hot air recirculating through open spaces between switches in the same racks made ports run hot until the data center partners put in a workaround. Flapping and erroring ports were cleaned and reseated, and the remaining alerting transceivers were disabled while waiting for replacements. A brute-force burn-in that pushed as much data as possible through every port at once (over 97% of theoretical capacity on most ports, with some switches crashing) separated the ports robust enough to keep from those to disable or repair. GPUDirect RDMA needed an extra kernel module and PCIe Access Control Service (ACS) disabled to avoid immediate hangs. Later, large regressions came from firmware upgrades, especially ones applied to only half the cluster, and from mass restarts of GPU hosts, both of which could corrupt or flood the UFM state and require UFM restarts.\n\nFor training, Imbue wrote host health checks that answer yes or no for each machine, forked NCCL to log which operations were in flight when a run stalled, live-debugged stalled processes with Py-Spy and GDB, and relaunched crashed runs automatically from the last checkpoint on the healthiest hosts. Live debugging caught one hang caused by a misconfiguration in the Python threading settings that made the eight multi-threaded NCCL GPU processes hit a race condition during pre-PyTorch initialization on certain hosts. The gradual MFU sag came from automatic garbage collection: in synchronous FSDP training, one worker running garbage collection during a blocking operation slows every other worker, and disabling automatic collection in favour of collection at set intervals on all hosts removed the sags. Network failures are handled by parsing the UFM event log, disabling the implicated links and ports, filing maintenance tickets and re-enabling components after repair.","ko":"Imbue 는 연구자와 엔지니어 몇 명으로 몇 달 만에 자체 인프라에서 70B 모델을 처음부터 학습했다. 이 글은 H100 GPU 4,088개, 서버 511대로 된 클러스터를 베어 메탈에서 학습할 수 있는 상태로 만들기까지 겪은 문제와 해결 과정을 정리한다. 서버마다 GPU 가 8개 있었고, GPU 마다 400 Gbps ConnectX-7 카드가 하나씩 직접 연결돼 3단 InfiniBand 네트워크로 이어졌다. 연결이 12,000개가 넘어서 하나만 조금 불안해도 전체 학습이 느려질 수 있었다.\n\n장비 단계에서는 서버의 약 10% 가 주로 물리적 문제로 부팅되지 않았다. 단일 노드 학습에서는 GPU 를 다시 장착해야 고쳐지는 오류가 많았고, PCIe 스위치 버스 펌웨어를 올린 뒤에는 클러스터 호스트의 약 4분의 1 에서 내부 PCIe 케이블을 다시 꽂아야 했다. 온도 값이 틀려 팬이 계속 100% 로 돌았는데, 잘못된 NVIDIA 드라이버가 한 원인이어서 이전 드라이버로 내려 해결했다. 몇 대에만 나타난 나머지 문제는 Dell 이 펌웨어 업그레이드로 고쳤다.\n\nInfiniBand 에서는 최상위 패브릭이 하나로 묶이지 않고 서로 경로가 없는 네트워크 여덟 개로 잘못 설계돼 UFM 이 스위치를 찾지 못했다. 다시 배선한 뒤에는 같은 랙의 스위치 사이 빈 공간으로 뜨거운 공기가 앞쪽으로 되돌아와 포트 온도가 치솟았다. 많은 포트가 높은 오류율과 플래핑을 보였고, 데이터센터 파트너가 포트를 청소하고 다시 꽂았다. 팀은 모든 포트에 동시에 최대한 데이터를 밀어 넣는 번인 작업을 돌려 버틴 포트만 남기고 나머지는 끄거나 수리로 넘겼다. GPUDirect RDMA 를 켜면 곧바로 멈추는 문제는 커널 모듈을 추가하고 PCIe Access Control Service, 줄여서 ACS 를 끈 뒤에야 사라졌다.\n\n운영 중 큰 회귀가 생긴 원인은 주로 두 가지였다. 펌웨어 업그레이드, 특히 클러스터 절반에만 올린 업그레이드는 UFM 상태를 깨뜨려 모든 InfiniBand 스위치에서 UFM 을 재시작해야 할 수 있었다. GPU 서버를 한꺼번에 재시작해도 UFM 상태에 업데이트가 몰려 UFM 서비스를 재시작해야 할 수 있었다. 최신 하드웨어를 쓰는 GPU 클러스터에서는 매주 기계의 약 3% 가 고장 난다고 보는 것이 경험칙이다. 하지만 모든 기계가 고르게 3% 확률로 고장 나는 것이 아니라, 소수의 문제 기계가 제대로 고칠 때까지 계속 다른 방식으로 고장 났다.\n\n학습 단계에서는 NCCL 워치독 타임아웃으로 멈추는 문제와 MFU 저하가 가장 다루기 어려웠다. 팀은 NCCL 에 로깅을 더한 포크를 만들어 멈춤을 일으킨 호스트를 찾았다. 처리량이 주기적으로 처지는 원인은 프로파일링으로 자동 가비지 컬렉션이라는 것을 확인했다. FSDP 같은 동기식 분산 학습에서는 블로킹 연산 중에 워커 하나가 가비지 컬렉션을 돌리면 다른 워커가 모두 느려질 수 있다. 자동 가비지 컬렉션을 끄고 모든 호스트에서 정해진 간격으로 돌리자 처짐이 사라졌다. 팀은 헬스 체크, 자동 재시작, UFM 로그 처리 같은 도구를 만들어 사람이 손으로 고치는 일을 줄였고, 그중 상당수를 공개했다."},"trigger":{"en":"Bringing a new InfiniBand-connected H100 cluster into service and running the first multi-node training jobs on it.","ko":"새로 들인 H100 4,088개 클러스터를 베어 메탈 상태에서 처음 구축하면서, 잘못 설계된 InfiniBand 배선과 불량 하드웨어, 펌웨어, 드라이버 문제가 차례로 드러났다."},"severity":"unknown","symptoms":["link-flapping","nccl-timeout","throughput-degraded","gpu-unavailable","training-job-failed"],"timeline":{"detected_after":null,"resolved_after":null},"date_kind":"published","detection":{"en":"Automated hardware checks during provisioning, UFM alerts on temperature, error rates and flapping ports, Prometheus node exporter and DCGM metrics, per-batch MFU monitoring, and live debugging of stalled processes with Py-Spy, GDB and NVIDIA Nsight.","ko":"UFM 경고, 호스트 헬스 체크, DCGM 과 Prometheus 지표, 학습 중 MFU 와 NCCL 워치독 오류로 문제를 알아챘다. InfiniBand 포트 문제는 포트를 실제로 쓸 때만 드러나서, 모든 포트에 부하를 거는 번인 작업을 만들어 더 효율적으로 찾았다. 멈춤을 일으킨 호스트는 특정 로그를 남기지 않은 호스트를 찾는 방식으로 가려냈다. 팀은 배치마다 순간 MFU 를 살펴보고, MFU 가 떨어지는 곡선 모양으로 문제 종류를 구분했다."},"components":["infiniband","nccl","gpu-driver","pytorch"],"root_cause":"dependency-failure","remediation":[{"text":{"en":"Automated checks for broken machines and sent faulty ones back to Dell or to data center staff","ko":"고장 난 기계를 찾는 점검을 자동화하고, 일부 기계는 Dell 에 돌려보내 다시 시험받게 했으며 데이터센터 직원에게 티켓을 올렸다."}},{"text":{"en":"Reseated GPUs and internal PCIe cables and applied firmware upgrades","ko":"GPU 와 내부 PCIe 케이블을 다시 장착했고 펌웨어 업그레이드를 적용했다."}},{"text":{"en":"Downgraded the NVIDIA driver that caused wrong temperature readings","ko":"온도 값을 틀리게 만든 NVIDIA 드라이버를 이전 버전으로 내렸다."}},{"text":{"en":"Rewired the top tier of the InfiniBand fabric into a single network and added checks that the wiring matched the design","ko":"InfiniBand 패브릭의 최상위 계층을 하나의 네트워크로 다시 배선하고, 배선이 설계와 맞는지 확인하는 점검을 추가했다."}},{"text":{"en":"Cleaned and reseated alerting ports and disabled the remaining alerting transceivers","ko":"경고를 내는 포트를 청소하고 다시 꽂았고, 그래도 경고가 남은 트랜시버는 껐다."}},{"text":{"en":"Ran a burn-in workload through every InfiniBand port and disabled the ports that did not survive it","ko":"모든 InfiniBand 포트에 번인 작업을 돌려, 버티지 못한 포트를 껐다."}},{"text":{"en":"Enabled GPUDirect RDMA with an extra kernel module and PCIe ACS disabled","ko":"커널 모듈을 추가하고 PCIe ACS 를 꺼서 GPUDirect RDMA 를 켰다."}},{"text":{"en":"Disabled automatic garbage collection and scheduled it at set intervals on all hosts","ko":"자동 가비지 컬렉션을 끄고 모든 호스트에서 정해진 간격으로 가비지 컬렉션을 돌렸다."}}],"action_items":[{"text":{"en":"Release host-level health checks that confirm a host is free from known errors","ko":"호스트가 학습에 쓸 만한지 예 또는 아니오로 답하는 헬스 체크를 만들었다. GPU, 디스크 공간, Docker, dmesg, iDRAC, 디스크, InfiniBand, NVLink, GDR, VBIOS, Flint, PSB 점검이 들어 있고, iDRAC 과 PSB 점검을 뺀 나머지를 공개했다."}},{"text":{"en":"Release an NCCL patch that improves logging around errors and stalls","ko":"오류와 멈춤 주변의 로깅을 늘린 NCCL 패치를 공개했다."}},{"text":{"en":"Release a GPU stress test and NVLink and InfiniBand networking tests","ko":"GPU 스트레스 테스트와 NVLink, InfiniBand 네트워크 테스트를 공개했다."}},{"text":{"en":"Release a script that parses the UFM event log and decides which network ports to disable","ko":"UFM 이벤트 로그를 파싱해 어떤 네트워크 포트를 꺼야 할지 정하는 스크립트를 공개했다."}},{"text":{"en":"Release a script that generates a burn-in workload exercising every InfiniBand link","ko":"모든 InfiniBand 링크를 쓰게 하는 번인 작업을 만드는 스크립트를 공개했다."}},{"text":{"en":"Relaunch crashed runs automatically from the last checkpoint on the machines that pass health checks","ko":"학습이 죽으면 헬스 체크를 통과한 기계로 마지막 체크포인트부터 자동으로 다시 시작하게 했다."}},{"text":{"en":"Replace the disabled alerting transceivers","ko":"경고가 나서 꺼 둔 트랜시버를 교체품이 오면 바꾼다."}}],"contributing":["assumption-unverified","monitoring-blind-spot","partial-rollout"],"recurrence_of":null,"symptoms_text":{"en":"When Imbue brought up a cluster of 4,088 H100 GPUs on 511 hosts, about 10% of the machines failed to boot, mostly from physical problems: unconnected or miswired Ethernet cables, iDRAC hardware issues, broken power supplies, bad NVMe drives, missing internal wires, and network cards or GPUs that did not show up. In single-node GPU tests, Ubuntu server logs showed links between the GPUs and the PCIe buses or network cards reporting \"limited width: x4 < x16\". A few hosts had NVMe drives that locked up the whole machine when touched, drives that appeared in random order and got the OS installed on the wrong one, wrong temperature readings that kept fans at 100%, and CPUs limited to 2 GHz.\n\nOn the InfiniBand fabric the Unified Fabric Manager (UFM) at first could not detect any of the 320 switches. Once it could, almost every switch port reported temperatures sometimes above 70 degrees Celsius before carrying any data. Under real traffic many ports showed high error rates or flapped between working and broken, about eighteen hundred alerts, and these only appeared when the ports were in use. Once about 10% of the fabric had issues, adaptive routing could no longer route reliably around the dropping links.\n\nTraining runs crashed on startup with errors such as \"Forward order differs across ranks: rank 0 is all-gathering 43 parameters while rank 1228 is all-gathering 1 parameters\" and \"CUDA out of memory. Tried to allocate …\", and mid-run on Xid and SXid hardware faults that left no meaningful Python stack trace. The hardest were hangs, where every GPU worker printed at the same time a message like \"Watchdog caught collective operation timeout: WorkNCCL(SeqNum=408951, OpType=_ALLGATHER_BASE, … , Timeout(ms)=600000) ran for 600351 milliseconds before timing out\". One or more hosts had failed to finish an NCCL operation and all the others blocked until NCCL_TIMEOUT, and the nature of NCCL made it very hard to tell which host was at fault; finding it often meant looking for the host that did not produce log messages the others did.\n\nSlowdowns showed as model FLOPs utilization (MFU) below what had been reached before, and the shape of the per-batch MFU curve pointed to the kind of fault. Under a tenth of the expected MFU from the start was most often an InfiniBand hardware fault such as a dead T2 or T3 switch, or a fault between GPU and NIC; 30% could be one host with GDR set up wrongly; 60 to 80% was most commonly degraded or faulty InfiniBand links, and could also be CPU throttling. Dips to 70% every 15 seconds matched NVIDIA clock throttle reasons from heat or power supply faults, and a gradual sag over a run that returned to 100% on restart was traced to automatic garbage collection.","ko":"Imbue 는 H100 GPU 4,088개를 서버 511대에 나눠 담은 클러스터를 베어 메탈부터 구축하고 그 위에서 70B 모델을 학습했다. 처음 마주친 것은 장비 자체였다. 서버의 약 10% 가 주로 물리적 문제로 부팅되지 않았고, InfiniBand 네트워크를 관리하는 Unified Fabric Manager, 줄여서 UFM 은 처음에 스위치 320대를 하나도 찾지 못했다.\n\nInfiniBand 쪽에서는 경고가 끝없이 들어왔다. 배선을 고친 뒤에는 거의 모든 스위치 포트가 데이터를 보내지 않는 상태에서도 지나치게 높은 온도를 알렸다. 70도가 넘을 때도 있었고, 온도 경고는 1만 건에 이르렀다. 이어서 1,800건의 경고가 왔다. 많은 포트가 높은 오류율을 보이거나 정상과 고장 사이를 오가는 플래핑을 했고, 이 문제는 포트를 실제로 쓸 때만 드러났다. 패브릭의 약 10% 가 문제를 일으키자 adaptive routing 도 제멋대로 끊기는 링크를 제대로 피하지 못했다.\n\n서버 한 대 안에서도 문제가 많았다. GPU 오류가 났고, Ubuntu 서버 로그에는 GPU 와 PCIe 버스나 네트워크 카드 사이의 연결이 \"limited width: x4 < x16\" 으로 찍혔다. 결함으로 표시되지 않으면서 건드리면 기계 전체를 멈추게 하는 NVMe 드라이브가 있었다. 온도 값이 틀려 팬이 늘 100% 로 돌았고, CPU 동적 주파수 조절이 고장 나 활성 코어가 2 GHz 로 묶였다. GPUDirect RDMA, 줄여서 GDR 을 적용하는 것도 처음에는 실패했다.\n\n학습 중에는 모든 GPU 워커에서 동시에 다음 오류가 나며 학습이 멈췄다.\nWatchdog caught collective operation timeout: WorkNCCL(SeqNum=408951, OpType=_ALLGATHER_BASE, … , Timeout(ms)=600000) ran for 600351 milliseconds before timing out\n호스트 하나 이상이 NCCL 연산을 끝내지 못하거나 NCCL 과 InfiniBand 연결에서 떨어져 나가면, 나머지 호스트가 모두 NCCL_TIMEOUT 까지 기다렸다. NCCL 의 특성상 어느 호스트가 원인인지 찾기가 매우 어려웠다. Xid, SXid 오류처럼 의미 있는 Python 스택 트레이스 없이 작업을 죽이는 하드웨어 오류도 있었다.\n\n느려짐도 여러 모양으로 나타났다. MFU 는 모델이 GPU 의 이론 연산 성능을 얼마나 쓰는지 나타내는 지표다. MFU 가 처음부터 기대치의 10분의 1 아래에 머물면 대개 T2 나 T3 계층의 죽은 스위치 같은 InfiniBand 하드웨어 문제였다. 30% 에 머물면 GDR 설정이 잘못된 호스트가 하나 있을 수 있었고, 60-80% 면 성능이 떨어지거나 고장 난 InfiniBand 링크가 원인인 경우가 많았다. 학습이 진행될수록 MFU 가 서서히 처지다가 재시작하면 100% 로 돌아오는 현상은 자동 가비지 컬렉션 때문이었다. 처음에는 좋다가 15초마다 70% 로 떨어지는 현상은 DCGM 의 GPU clock throttle reasons 와 함께 나타났고, 열이나 전원 공급 장치 문제가 원인이었다."},"updated_at":"2026-11-10T00:00:37.775813Z","url":"https://benchlet.com/incidentlib/app/cases/IL-0025","org_slug":"imbue"}