{"id":"IL-0418","org":"Google","date":"2024-04-16","docs":[],"title":{"en":"Machine, ICI link and optical circuit switch failures interrupted training jobs on Google's TPU v4 supercomputers","ko":"TPU v4 슈퍼컴퓨터에서 장비, ICI 링크, 광 회로 스위치가 고장 나 학습 작업 약 1% 가 멈추거나 느려졌다"},"domain":["ai-infra","networking"],"impact":{"scope":"About 1% of TPU v4 training jobs experienced hardware outages; jobs on a failed machine or ICI link were evicted, rescheduled onto healthy cubes and resumed from checkpoints, and jobs routed around an unavailable OCS ran 0.5% to 8.6% slower per step","users":"Google Cloud customers and internal Google users of TPU v4 supercomputers","region":"unknown"},"review":{"written_by":"session","reviewed_at":null,"reviewed_by":null},"lessons":{"en":"In a static pod every resource in a contiguous block must be healthy at once, which becomes less likely as jobs grow, so job availability falls with size. Reconfiguring at the granularity of 16-machine cubes keeps the blast radius of a failure small while letting jobs use any healthy cubes, and fault-tolerant routing keeps cubes usable through rare OCS outages at a small cost in step time.","ko":"정적으로 연결된 TPU v3 같은 포드에서는 작업에 필요한 연속된 노드가 모두 동시에 정상이어야 해서, 필요한 칩이 1,024개로 늘면 작업 가용성이 급격히 떨어졌다. 큐브 단위로 다시 구성할 수 있게 하자 약 50개 큐브, TPU 3,200개까지 가용성이 약 94% 로 유지되었다. OCS 장애를 견디는 장애 허용 라우팅을 더하자 가용성이 99.98% 가 되었다. 재구성이 없을 때 호스트 1,024대가 필요한 작업이 쓸 만한 가용성을 얻으려면 호스트마다 99.9% 가용성이 필요했지만, OCS 로 재구성하면 99% 로 충분했다. 장애 허용 라우팅의 성능 영향은 all-to-all 위주 작업에서는 작고 all-reduce 위주 작업에서는 더 컸으며, 계산과 통신을 더 잘 겹치면 줄일 수 있다."},"related":[],"sources":[{"url":"https://www.usenix.org/conference/nsdi24/presentation/zu","kind":"paper","archived":"https://web.archive.org/web/20260202043741/https://www.usenix.org/conference/nsdi24/presentation/zu"}],"summary":{"en":"The paper by Google engineers describes the software that has run TPU v4 supercomputers in production since 2020, for Google Cloud and internal users, and reports two years of fleet statistics. A supercomputer has 64 cubes of 64 TPU v4 chips each, 4096 chips in total; a cube is one rack of 16 machines with 4 chips each, linked by ICI in a 4x4x4 mesh, and 6144 optical ICI links from the cubes go to 48 optical circuit switches, MEMS mirror arrays that the Pod Manager service programs to cross-connect cubes into the torus or twisted torus a job asks for. The Borg scheduler places jobs on cubes, the Pod Manager sets up the OCS cross-connects and monitors OCS health over RPC, libtpunet sets up routing for each job, and healthd monitors each machine.\n\nIn the earlier TPU v3 static pods, where a job needed one contiguous block of healthy machines, job availability fell sharply as jobs grew towards 1024 chips; a 1024-host job needed 99.9% availability from every host, while OCS reconfiguration lowers that to 99%. When a machine or ICI link fails, its machines are marked unavailable, running jobs are evicted with notice so they can write a checkpoint if possible, and Borg reschedules them onto spare healthy cubes, where they resume from the latest checkpoint; with cube reconfiguration, availability stays high through about 94%, which the paper equates with about 50 cubes or 3200 chips. Beyond that, faults between cubes lower availability, and for OCS outages libtpunet uses fault-tolerant wild-first routing, precomputed offline with an integer linear program, which lets a packet take one extra hop in another dimension to avoid the broken links. With one OCS unavailable, measured all-to-all throughput was 70.0 GB/s against 75.9 GB/s on a 4x4x4 torus (92.2%), 63.2 against 62.1 GB/s on a 4x4x8 twisted torus (101.7%) and 53.7 against 54.3 GB/s on a 4x8x8 twisted torus (98.8%). 95% of jobs opt in to fault-tolerant routing, and fewer than 2% of jobs run with it at any time, a share that follows OCS maintenance events and their recovery time.\n\nFaulty hardware goes to a repair workflow that combines automatic diagnosis with technician input, and passes an automated QA process before rejoining the pool; ICI links are drained and repaired online while the TPUs stay usable by jobs that do not need those links. Google prioritises recovery time for OCS parts over other parts to keep the performance impact of OCS outages small, and a planned fleet-wide upgrade of OCS parts was made to improve reliability. The paper reports 99.98% system availability, with hardware outages experienced by about 1% of training jobs handled this way.","ko":"Google 의 TPU v4 슈퍼컴퓨터 한 대는 TPU 4,096개로 이루어진다. 큐브는 TPU 칩 64개를 4x4x4 로 배치한 하드웨어 단위이고, TPU 장비 16대로 이루어진다. 슈퍼컴퓨터 한 대에는 큐브가 64개 있다. 칩 사이를 잇는 고속 인터커넥트 ICI 는 TPU 끼리 CPU 를 거치지 않고 직접 통신하게 한다. 광 회로 스위치 OCS 48대는 서로 다른 큐브의 ICI 를 교차 연결해 사용자가 요청한 토러스 모양을 만든다. 클러스터 관리 서비스 Borg 가 작업을 받아 스케줄하고, Pod Manager 가 Borg 의 결정에 맞춰 OCS 연결을 설정하며 OCS 상태를 감시한다. ML 학습 작업은 모든 계산 자원이 동시에 정상이어야 돌아가므로 프로세스 하나가 실패하거나 중단되어도 학습 전체가 멈춘다.\n\n논문은 Google 이 지난 2년 동안 TPU v4 를 운영한 경험을 담았다. 평균적인 슈퍼컴퓨터에서 하루에 장비의 0.08%, ICI 케이블의 0.005%, OCS 의 0.04% 가 고장 났고, 학습 작업의 약 1% 가 하드웨어 장애를 겪었다. healthd, libtpunet, Pod Manager, 수리 자동화 시스템이 이상을 알리면 Borg 는 해당 장비를 쓸 수 없다고 표시하고 돌던 작업에 알린 뒤 내보냈다. 작업은 가능하면 최신 체크포인트를 쓰고, 다시 스케줄된 뒤 최신 체크포인트에서 이어 갔다. 장비와 ICI 장애는 작업을 남는 정상 큐브로 옮겨 자동으로 견뎠다. OCS 장애는 영향 범위가 컸다. Google 은 끊긴 링크를 피해 가는 장애 허용 ICI 라우팅으로 약간의 성능 손실을 안고 OCS 장애를 견뎠고, OCS 를 다른 부품보다 먼저 복구했다. 학습 작업의 95% 가 장애 허용 라우팅을 켰고, 실제로 장애 허용 라우팅으로 도는 작업은 어느 때든 2% 미만이었다. 8개월 동안의 기록에서 60일째 무렵에 이 비율이 치솟은 것은 신뢰성을 높이려고 OCS 부품을 전체적으로 업그레이드한 계획 작업 때문이었다. 이런 재구성으로 TPU v4 슈퍼컴퓨터는 시스템 가용성 99.98% 를 유지했다."},"trigger":null,"severity":"unknown","symptoms":["training-job-failed","throughput-degraded"],"timeline":{"detected_after":null,"resolved_after":null},"date_kind":"published","detection":{"en":"healthd on each machine monitors ICI links, PCIe channels and TPU chips against modelled values and thresholds, a PCIe MSI-X interrupt reaches libtpunet when a link goes down, a TPU errors or the driver panics and libtpunet notifies Borg, a preflight check runs before every job, and the Pod Manager queries OCS health over RPC.","ko":"각 TPU 장비의 healthd 데몬이 ICI 링크, PCIe 채널, TPU ASIC 을 실시간으로 감시했다. healthd 는 심각한 증상이 보이면 Borg 에 영향받은 작업을 내보내고 다시 스케줄하라고 알렸다. Pod Manager 는 RPC 로 모든 OCS 의 하드웨어 상태를 주기적으로 조회했다. libtpunet 은 작업 동안 ICI 세션을 지켜보다가 오류, 링크 다운, 드라이버 패닉이 나면 Borg 에 알렸다. 작업마다 시작 전에 작은 표본 워크로드를 돌리는 검사와 물리 계층 지표를 기준값과 비교하는 검사로 이루어진 프리플라이트 검사도 돌렸다."},"components":["tpu","network-link"],"root_cause":"hardware-failure","remediation":[{"text":{"en":"Marked the affected TPU machines unavailable and evicted running jobs with notice","ko":"Borg 는 문제가 생긴 TPU 장비를 쓸 수 없다고 표시하고, 돌던 작업에 알린 뒤 내보냈으며, 문제가 풀릴 때까지 대기 작업이 그 장비에 배치되지 않게 했다."}},{"text":{"en":"Notified affected jobs so they could write an up-to-date checkpoint, and resumed rescheduled jobs from the latest checkpoint","ko":"작업은 알림을 받으면 가능할 때 최신 모델 체크포인트를 썼고, 다시 스케줄된 뒤 최신 체크포인트에서 이어 갔다."}},{"text":{"en":"Reconfigured jobs through the optical circuit switches to use spare healthy cubes after machine and ICI link outages","ko":"장비와 ICI 장애는 작업이 남는 정상 큐브를 쓰도록 다시 구성해 자동으로 견뎠다."}},{"text":{"en":"Routed traffic around links broken by an unavailable OCS with fault-tolerant wild-first routing","ko":"고장 난 OCS 때문에 차원 순서 라우팅 경로가 끊긴 링크를 지나게 되면, 패킷이 각 차원에서 최대 한 번의 wild hop 을 먼저 한 뒤 차원 순서 라우팅으로 돌아가는 wild-first routing 으로 대체 경로를 만들었다. 경로는 정수 선형 계획법으로 오프라인에서 미리 계산해 두었다."}},{"text":{"en":"Drained broken ICI links and repaired them online while the TPUs stayed in use","ko":"끊긴 ICI 링크는 드레인해 사용자 애플리케이션이 쓰지 않도록 자동으로 빼고 온라인으로 수리했다. TPU 계산 자원은 그대로 두어, 고장 난 ICI 를 쓰지 않는 작업은 그 장비에 계속 배치되었다."}},{"text":{"en":"Sent faulty hardware to a repair workflow and returned it to the pool after automated QA","ko":"고장 난 하드웨어는 자동 진단과 필요할 때 기술자의 손을 거쳐 복구했고, 자동 QA 과정을 통과한 뒤에 자원 풀로 돌려보냈다."}},{"text":{"en":"Prioritised recovery time for OCS components over other components","ko":"OCS 장애의 성능 영향을 줄이려고 OCS 부품을 다른 부품보다 먼저 복구했다."}},{"text":{"en":"Upgraded OCS parts across the fleet in a planned upgrade to improve reliability","ko":"신뢰성을 높이려고 OCS 부품을 전체 플릿에서 계획적으로 업그레이드했다."}}],"action_items":[{"text":{"en":"Add randomized routing to ICI switches for better load balancing in the presence of faults","ko":"고장이 있을 때 일반 토러스와 트위스티드 토러스 모두에서 부하가 더 고르게 나뉘도록 ICI 스위치에 무작위 라우팅 기능을 넣는다. 특히 가장 가까운 이웃과 통신하는 패턴이 대상이다."}},{"text":{"en":"Provision a hot-standby cube on an outage and migrate accelerator state to it without writing a persistent checkpoint","ko":"장애가 나면 핫 스탠바이 큐브를 마련하고, 영구 체크포인트를 거치지 않고 가속기 상태를 새 TPU 로 바로 옮긴다. 그러면 작업이 장애에 거의 영향받지 않고 이어진다. 이를 위해 Borg 스케줄러, libtpunet, Pathways ML 런타임을 고친다."}}],"contributing":[],"recurrence_of":null,"symptoms_text":{"en":"On Google's TPU v4 supercomputers, a failed TPU machine, inter-chip interconnect (ICI) link or optical circuit switch (OCS) stopped the training jobs that used it, because a job's TPU processes all have to be up to update weights together over ICI collectives. Hardware outages hit about 1% of training jobs; jobs on a failed machine or ICI link were evicted, rescheduled onto healthy cubes and resumed from their latest checkpoint.\n\nThe failures were caught on the machines and in the network software. The healthd daemon on every machine watches the 24 unidirectional ICI links, the PCIe channels between TPUs and CPUs and the 4 TPU chips, and compares link connections and link quality with modelled values and thresholds; severe symptoms make healthd ask Borg to evict and reschedule the job. Inside a job, when a TPU sees an error, the link layer goes down or the driver panics, a PCIe MSI-X interrupt is raised to libtpunet, which notifies Borg to reschedule. A preflight check before each job runs a small sample workload and compares physical link metrics with golden thresholds, so substandard links are caught before the job starts.\n\nIn an average supercomputer, each day 0.08% of the TPU machines, 0.005% of the ICI cables and 0.04% of the optical circuit switches failed. A machine or ICI link failure removes the affected cube or cubes from the resource pool, but an unavailable OCS breaks one ICI link with the same position on every cube in the pod, so it can affect all cubes. Jobs that kept running around an unavailable OCS ran slower: step time grew by 0.5% to 8.6% across Google's recommendation, LLM and BERT workloads, and nearest-neighbour all-reduce traffic lost 50% of its throughput.","ko":"TPU v4 슈퍼컴퓨터에서 TPU 장비, 칩 사이를 잇는 ICI 링크, 광 회로 스위치 OCS 가 고장 나면 그 하드웨어를 쓰던 학습 작업이 중단되었다. 장비나 ICI 링크가 고장 난 작업은 남는 정상 큐브로 다시 스케줄되었다. 전체 학습 작업의 약 1% 가 이런 하드웨어 장애를 겪었다.\n\n평균적인 슈퍼컴퓨터 한 대에서 하루에 TPU 장비의 0.08%, ICI 케이블의 0.005%, OCS 의 0.04% 가 고장 났다. 비율은 작지만 슈퍼컴퓨터마다 장비, ICI, OCS 가 매우 많아 영향받는 작업 수는 적지 않았다.\n\n각 장비의 healthd 데몬은 ICI 링크 24개, TPU 와 CPU 사이의 PCIe 채널, TPU ASIC 4개를 실시간으로 감시하며 링크의 케이블 연결과 링크 품질을 모델 값, 임계값과 비교했다. 작업 중에 TPU 가 오류를 보거나 링크 계층이 내려가거나 드라이버가 패닉하면 PCIe MSI-X 인터럽트가 libtpunet 에 전달되었다. libtpunet 은 Borg 에 재스케줄을 요청했다. 작업 시작 전 프리플라이트 검사에서 걸린 작업은 다른 큐브로 다시 스케줄되었다.\n\nOCS 하나를 쓸 수 없게 되면 모든 큐브에서 같은 {dim, index} 를 가진 ICI 링크가 하나씩 끊겼다. 4x4x8 토러스라면 X 차원의 한 XZ 평면에서 링크 두 개가 끊기고, 끊긴 링크가 Z 를 따라 4홉마다 되풀이되었다. OCS 장애는 슈퍼컴퓨터의 모든 큐브에 영향을 줄 수 있어 장비나 ICI 장애보다 영향 범위가 컸다.\n\n고장 난 OCS 를 우회하는 장애 허용 라우팅으로 실행된 작업은 고장 링크 주변에 트래픽이 몰려 스텝 시간이 0.5% 에서 8.6% 늘었다. all-reduce 위주 작업은 가장 가까운 이웃과의 통신 처리량이 50% 떨어져 영향이 더 컸다. 일반 토러스에서 OCS 하나가 빠지면 이상적인 all-to-all 성능이 15/16, 약 93.4% 로 줄었다. 4x4x4 에서 잰 all-to-all 처리량은 75.9 GB/s 에서 70.0 GB/s 로 줄어 원래의 92.2% 였다."},"updated_at":"2026-11-14T12:34:06.889728Z","url":"https://benchlet.com/incidentlib/app/cases/IL-0418","org_slug":"google"}