AI 패브릭의 링크 신뢰성과 모니터링

학습 작업은 수천 개의 GPU에 걸친 동기식 연산입니다: 모든 집합 통신 연산은 가장 느린 링크를 기다립니다. 링크가 불안정한 트랜시버 하나는 서버 하나를 살짝 늦추는 정도가 아니라 작업 전체를 멈추게 하며, 완전히 고장 나면 작업은 마지막 체크포인트부터 다시 시작됩니다. 그래서 광학 부품은 더 이상 하나의 부품이 아니라 신뢰성 버짓이 됩니다. 이 페이지는 장애 확률 계산, 문제를 예측하는 지표, 패브릭이 불량 링크를 모니터링하고 격리하는 방법, 장애율을 낮추는 운영 관행을 다룹니다.

링크 하나가 중요한 이유

이벤트	학습 작업에 미치는 영향
링크 플랩(수 초)	집합 통신이 타임아웃되거나 재시도됨; 스텝 시간이 급증함; NCCL/RCCL에서는 정체가 충분히 길면 작업이 중단됨
속도/폭이 낮아진 링크	모든 All-Reduce가 그 속도에 맞춰짐; 클러스터 전체 처리량이 그 링크 몫만큼 떨어짐
pre-FEC BER 상승, 미정정 없음	아직은 문제없음 — 하지만 마진이 사라진 상태; 다음번 더운 오후에 플랩이 발생함
미정정 FEC 오류	패킷 손실 → RDMA 재전송 폭주 → 정체
완전 고장	체크포인트부터 작업 재시작: 클러스터 전체에서 수 분에서 한 시간의 연산 손실

GPU 1 000개 규모의 작업에서 체크포인트 재시작 비용은 GPU-시간 단위로 측정됩니다; 이 수치를 더 나은 광학 부품과 더 나은 QA의 비용과 비교해야 합니다.

장애 확률 계산

트랜시버 신뢰성은 FIT(10⁹ 장치-시간당 고장 횟수) 또는 MTBF로 표시됩니다.

가정	값
패브릭의 광 종단 수	4 000(GPU 1 024개, 2계층 클러스터)
종단당 FIT(안정화된 400G 광학 부품, 냉각 양호)	200–500
월간 예상 완전 고장 수	4 000 × 350 × 10⁻⁹ × 720 h ≈ 1
실제 관측되는 링크 플랩 비율	완전 고장보다 5–20배 높음 — 오염, 한계에 가까운 마진, 열, 펌웨어

따라서 완전 고장은 드물고 예측 가능합니다; 대부분을 차지하는 것은 플랩과 열화된 링크이며 이는 대체로 예방 가능합니다 — 모니터링과 QA가 스스로 비용을 회수하는 이유입니다.

문제를 예측하는 지표

지표	출처	정상 범위	조치
레인별 Pre-FEC BER	CMIS VDM; 호스트 FEC 카운터	< 10⁻⁷	> 10⁻⁶이면서 상승 중; > 10⁻⁵이면 교체 예정
FEC 미정정 코드워드	호스트	0	하나라도 증가하면 인시던트
레인별 심볼 오류	호스트(이더넷) / `perfquery`(IB)	균형 잡힘, 0에 가까움	한 레인에 편중됨
기준값 대비 레인별 Rx 파워	DDM	첫날 대비 1 dB 이내, 레인 간 2 dB 이내	기준값 대비 −2 dB
Tx 바이어스 추이	DDM	평탄함	기준값 대비 +15–20 %(Tx 바이어스와 노화)
모듈 온도	DDM	< 60 °C	> 65 °C 또는 주변보다 +10 °C
eSNR(CMIS)	VDM	> 18–20 dB	한 레인에서 하락
포트당 링크 플랩	스위치 로그, 패브릭 매니저	0	하나라도 발생 시
협상된 속도/폭	스위치 / `ibstat`	최대치	정격 미만

정의와 형식: VDM 및 FEC 지표, 모니터링.

모니터링 아키텍처

패브릭	수집 방식	도구
InfiniBand	서브넷/패브릭 매니저가 모든 포트의 카운터와 케이블 EEPROM/DDM을 폴링	UFM급 매니저, `ibdiagnet`, `mlxlink -m`
이더넷(RoCE)	10–60초 간격으로 트랜시버와 FEC 상태를 gNMI/OpenConfig 스트리밍; SNMP는 대체 수단	gnmic → Prometheus/Grafana, 벤더 텔레메트리(도구로 DDM 읽기)
호스트 측	NIC 카운터: 재전송, CNP, 순서 어긋남; 타임아웃에 대한 NCCL/RCCL 로그	노드 익스포터
작업 측	스텝 시간 편차, 스트래글러 탐지	학습 프레임워크 지표

이 세 가지를 서로 연관 지어 보십시오: 14:05의 스텝 시간 급증, 14:04에 리프 7 레인 3에서 나타난 pre-FEC BER 이상, 랙 12의 모듈 온도 피크를 종합하면 완전한 진단이 됩니다.

격리와 대응

미정정 오류나 플랩이 임계값을 넘으면 포트를 자동으로 비활성화하거나 우회합니다 — 패브릭 매니저와 NOS는 링크 오류 정책을 지원하며, 그동안 적응형 라우팅이 트래픽을 열화된 링크 주변으로 돌립니다.
원인이 노드의 NIC 포트라면 해당 노드를 드레인하고, 작업 스케줄을 그에 맞게 조정합니다.
모듈을 벤치에서 점검합니다: 식별 정보, 첫날 기준값 대비 레인별 DDM, 체크섬, 펌웨어 버전(Check transceiver, DDM).
모듈을 탓하기 전에 양쪽 MPO를 세정하고 다시 점검합니다 — 오염이 가장 흔한 원인입니다(물리적 불일치).
교체 후 관찰합니다: 오류가 모듈을 따라가면 RMA를 진행하고, 포트에 그대로 남아 있으면 케이지, 광섬유, 반대쪽 끝을 살펴봅니다.

장애율을 낮추는 운영 관행

관행	효과
입고 검사와 번인(부하와 온도 조건에서 24–72시간)	초기 고장을 작업에 닿기 전에 걸러냄
첫날 레인별 DDM 기준값 확보	절대 정확도(±3 dB)를 정밀한 변화량 비교로 바꿔줌
모듈을 60 °C 미만으로 유지 — 통풍, 핀형/플랫형 OSFP를 올바르게 사용, 흡기 막힘 없음	−10 °C마다 수명이 두 배로 늘어남
결합할 때마다 모든 커넥터를 세정; 사용하지 않는 포트에는 캡 장착	대부분의 플랩은 오염이 원인
모듈과 호스트의 펌웨어를 최신 상태로 유지	CMIS 상호운용성 문제 해결(CMIS 문제)
계층별로 균일하고 검증된 광학 부품 사용	호스트/모듈 DSP 상호운용성 문제가 줄어듦
번인과 기준값 확보를 마친 예비품 3–5 %	2차 인시던트 없이 교체 가능
매주 추이 검토	고장이 아니라 일정에 따라 노후 레이저를 교체

기술의 방향

레인 속도가 높아질수록(200G/레인, 1.6T) 마진은 더 줄어듭니다; 리니어(LPO)와 코패키지 옵틱스는 DSP와 그 모니터링 기능을 없애 BER 가시성을 호스트로 넘기는 대신, 부품 수와 발열을 줄여 줄 것으로 기대됩니다(변조와 DSP, AI 속의 광학 부품). 어떤 모듈이든 원칙은 같습니다: 기준값을 잡고, 변화량을 지켜보고, 추이에 따라 행동하십시오.

CodingBox에서

CodingBox는 이 순환 구조의 벤치 쪽 끝입니다: 입고 검사와 번인 판독, 시리얼별로 code database에 저장되는 첫날 레인별 기준값, 그리고 빼낸 모듈에 대한 사후 판독 — 식별 정보, 펌웨어, 체크섬, DDM을 자체 이력과 비교 — 을 통해 RMA 결정이 포트의 마지막 로그 한 줄이 아니라 데이터에 근거하게 됩니다.

이 문서에서 부정확한 내용이나 오류를 발견하면 해당 부분을 선택하고 Ctrl+Enter를 눌러 해 주세요.