{"id":"IL-0477","org":"Tencent","date":"2026-07-08","docs":[],"title":{"en":"Slow compute on 8 ranks pushed a 10,000-GPU MoE job from 30 s to over 90 s per step; an alert pointed at the network","ko":"Tencent의 1만 GPU MoE 학습에서 계산이 느려진 노드 때문에 스텝 시간이 30초에서 90초 넘게 늘었다"},"domain":["ai-infra"],"impact":{"scope":"MoE training job of about 10,000 GPUs: iteration time rose from about 30 s to over 90 s","users":"unknown","region":"unknown"},"review":{"written_by":"session","reviewed_at":null,"reviewed_by":null},"lessons":{"en":"Out-of-band infrastructure metrics can point at the wrong component: a communication anomaly or port event may be a secondary effect of compute degradation that propagates through collectives. Fine-grained tracing that separates compute operators from communication is what showed the network explanation was wrong.","ko":"인프라 수준에서 보이는 통신 이상이 꼭 네트워크 하드웨어에서 생긴 것은 아니다. 계산 성능 저하가 집합 통신의 의존성을 타고 번져 통신 이상처럼 보일 수 있다. 세밀한 가시성이 없으면 운영자가 문제를 잘못 진단하고 효과 없는 조치를 할 위험이 있다. 1만 GPU 넘는 학습 클러스터에서 느려지는 고장의 형태는 매우 다양해서 진단 단계 하나로는 모든 경우를 다룰 수 없다."},"related":[],"sources":[{"url":"https://arxiv.org/abs/2606.20374","kind":"paper","archived":"https://web.archive.org/web/20261030083923/https://arxiv.org/abs/2606.20374"}],"summary":{"en":"ARGUS is Tencent's always-on tracing and diagnosis system for training on a production cluster of more than 10,000 GPUs, deployed there for over six months. It traces CPU call stacks, framework semantics and GPU kernel execution with less than 2% overhead and diagnoses in levels: L1 finds anomalous windows in each rank's iteration time, L2 compares phase durations among ranks with the same parallel role using the coefficient of variation and z-scores, L3 compares kernel duration distributions, and L4/L5 are deep dives in Grafana and Perfetto on the few suspect ranks.\n\nCase 5 in the paper is an MoE training job of about 10,000 GPUs with TP=1, PP=9 and EP=32 whose iteration time rose from about 30 s to over 90 s. L2 pointed at 8 ranks whose compute ran about 5.7 times slower than the rest of their group, and the paper confirms compute degradation on those ranks as the root cause; the wait spread first through the EP dispatch and then through pipeline stage dependencies to the other stages of the same pipeline group. A \"server port down\" event from out-of-band monitoring on one affected node led operations to plan a network repair, but the slowdown showed only in compute operators. Training speed recovered immediately after the affected nodes were replaced. The paper concludes that communication anomalies seen at the infrastructure level can be a secondary effect of slow compute propagating through collectives, and that coarse metrics alone can lead to an ineffective fix.","ko":"ARGUS는 Tencent가 GPU 1만 개 넘는 운영 학습 클러스터에 배포한 실시간 추적·분석 시스템이다. ARGUS는 반복 시간을 보는 L1, 병렬 그룹 안의 랭크를 비교하는 L2 같은 단계를 거치며 진단 범위를 좁힌다. 이 클러스터에서 TP=1, PP=9, EP=32로 돌던 약 10,000 GPU 규모의 MoE 학습 작업이 느려졌다. TP는 텐서 병렬, PP는 파이프라인 병렬, EP는 전문가 병렬, DP는 데이터 병렬을 뜻한다. 반복 시간이 약 30초에서 90초 넘게 늘어 L1이 알림을 냈다. 이어서 L2가 DP 그룹 안의 랭크를 비교해 PP=7, DP=272~279에 있는 랭크 10352~10359의 mlp 계산 시간이 그룹 평균의 약 5.7배라는 것을 찾았다. 이 느린 랭크 8개는 랭크 10336~10367로 이루어진 32개짜리 EP 그룹에 속했다. EP 그룹 안의 dispatch 연산은 32개 랭크가 모두 참여해야 하므로 느린 8개가 이 집합 통신을 붙잡았고, EP 그룹 전체가 DP 단계의 ReduceScatter에 늦게 들어갔다. PP 단계 사이의 의존성 때문에 지연은 같은 PP 그룹의 다른 모든 PP 단계로 번졌다. 이로써 랭크 10352~10359의 계산 성능 저하가 근본 원인으로 확인되었다.\n\n대역 외 모니터링 시스템은 영향받은 노드 하나에서 \"server port down\" 이벤트를 보고했고, 운영팀은 처음에 이것을 원인으로 보고 네트워크 수리 일정을 잡았다. 그러나 ARGUS의 추적에서는 이상이 통신과 무관한 순수 계산 연산자에서만 나타났다. 영향받은 노드를 교체하자 학습 속도가 바로 회복되었다."},"trigger":null,"severity":"unknown","symptoms":["throughput-degraded"],"timeline":{"detected_after":null,"resolved_after":null},"date_kind":"published","detection":{"en":"ARGUS level L1 detected the iteration-time regression and raised an alert, and level L2's cross-rank comparison of phase durations located the 8 slow ranks.","ko":"ARGUS의 L1 단계가 반복 시간이 약 30초에서 90초 넘게 늘어난 것을 잡아 알림을 냈다. 이어서 L2 단계가 DP 그룹 안의 랭크별 mlp 단계 소요 시간을 비교해 랭크 10352~10359를 찾았다."},"components":[],"root_cause":"hardware-failure","remediation":[{"text":{"en":"Replaced the affected nodes, after which training speed recovered immediately","ko":"영향받은 노드를 교체했고, 교체 직후 학습 속도가 회복되었다."}}],"action_items":[],"contributing":["assumption-unverified"],"recurrence_of":null,"symptoms_text":{"en":"In an MoE training job of about 10,000 GPUs on Tencent's production cluster, iteration time rose from about 30 s to over 90 s and the ARGUS iteration-level detector raised an alert. At the same time the out-of-band monitoring system reported a \"server port down\" event on one of the affected nodes.\n\nARGUS compared phase durations across the ranks of the same data-parallel group. The compute-only mlp phase on ranks 10352–10359 (PP=7, DP=272–279) had a coefficient of variation above 0.8, with durations about 5.7 times the group mean. On the Grafana heatmap of per-rank maximum operator duration, most ranks ran mlp in about 30–50 ms while those 8 ranks took 170–280 ms.\n\nThe delay spread through collective dependencies. The 8 slow ranks were in an expert-parallel (EP) group of 32 ranks (10336–10367), and the EP dispatch needs all 32 ranks, so the whole group entered the data-parallel ReduceScatter late. Because the other EP groups were already waiting, this group's ReduceScatter looked shorter than its neighbours', and pipeline stage dependencies gave ranks in every PP stage at DP=256–287 the same shorter ReduceScatter.\n\nOperations first took the port-down event as the root cause and scheduled a network repair. ARGUS tracing showed that the anomaly appeared only in pure-compute operators with no communication, which contradicted the network explanation.","ko":"GPU 약 10,000개로 돌던 MoE 학습 작업의 반복 시간이 약 30초에서 90초 넘게 늘어 ARGUS의 L1 단계가 알림을 냈다. L1은 랭크마다 반복 시간 시계열을 모아 급등과 계단식 성능 저하를 찾는 단계다.\n\nL2 단계가 DP 그룹 안의 랭크끼리 단계별 소요 시간을 비교했다. DP는 데이터 병렬, PP는 파이프라인 병렬, EP는 전문가 병렬을 뜻한다. 통신 없이 계산만 하는 mlp 단계에서 PP=7, DP=272~279에 있는 랭크 10352~10359의 변동 계수가 0.8을 넘었고, 이 랭크들의 소요 시간은 그룹 평균의 약 5.7배였다.\n\nGrafana 히트맵에서 대부분의 랭크는 mlp 지연이 30~50 ms로 고르게 나왔지만 랭크 10352~10359는 170~280 ms였다. 반대로 ReduceScatter는 DP=256~287 범위의 모든 PP 단계에서 주변 랭크보다 짧게 나왔다. 느린 랭크 8개가 속한 EP 그룹 전체가 DP 단계의 ReduceScatter에 늦게 들어갔고, 그때는 다른 EP 그룹이 이미 준비되어 있어 기다리지 않고 바로 끝났기 때문이다.\n\n같은 때 대역 외 모니터링 시스템이 영향받은 노드 중 하나에서 \"server port down\" 이벤트를 보고했다. 운영팀은 처음에 이것을 근본 원인으로 보고 네트워크 수리 일정을 잡았다. 그러나 ARGUS의 세밀한 추적에서는 이상이 통신이 전혀 없는 순수 계산 연산자에서만 나타났고, 이는 네트워크가 원인이라는 판단과 맞지 않았다."},"updated_at":"2026-11-14T12:34:12.351532Z","url":"https://benchlet.com/incidentlib/app/cases/IL-0477","org_slug":"tencent"}