사례2건
2건 중 1~2번째
- 증상
Vela 에서 GPU 768개로 Granite-20B 를 학습하던 중 스텝 시간이 갑자기 거의 3배로 늘었고, 팀이 이 성능 저하를 알아챘다.
- 촉발
작업에 속한 노드 96대 가운데 한 대의 전원 카드에 문제가 생겼다.
- 원인
- 구성 요소
- 기여 요인
- –
- 감지
학습 팀은 스텝 시간이 거의 3배로 늘어난 것을 알아챘다. 이 고장은 호스트를 죽이지 않고 작업을 느리게만 만드는 종류였다. 팀은 작업이 쓰던 노드 96대를 모두 디버깅해서 원인 노드를 찾았다.
- 조치
- 작업이 쓰던 노드 96대를 모두 디버깅해 전원 카드 문제로 전력을 낮춘 노드 한 대를 찾았다.
- 후속 조치
- AI 연구자와 시스템 관리자가 문제 노드를 빨리 찾고 버퍼 노드로 작업을 빨리 다시 시작할 수 있도록 인프라 계층에 경보를 더한다. 경보는 호스트 VM 로그, 애플리케이션 로그, 호스트 BMC 로그의 메시지로 만든다.
- nvidia-smi 의 power break slowdown 같은 GPU 카운터로 전원 문제가 있는 노드를 찾는 검사를 Autopilot 에 넣고, Grafana 대시보드에 표시한다.
- 교훈
수백, 수천 개의 GPU 를 함께 쓰는 분산 학습에서는 노드 한 대의 성능만 떨어져도 작업 전체의 성능이 떨어진다. 그 상태는 느린 노드를 찾아 빼거나 고치기 전까지 이어진다. 호스트를 죽이지 않는 미묘한 하드웨어 고장도 작업을 실패시키거나 느리게 만들 수 있어서, IBM 은 로그 기반 경보와 Autopilot 의 주기 검사로 이런 노드를 먼저 찾는다. 이런 기능 덕분에 IBM 의 SRE 는 사용자가 신고하면 디버깅하던 방식에서 사용자가 알기 전에 먼저 알리는 방식으로 바뀌었고, 근본 원인을 찾는 시간을 2배 넘게 줄였다.
- 증상
Vela 의 GPU 노드는 PCI-E Gen3 와 Gen4 링크를 쓴다. 그런데 때때로 링크 성능이 4 GB/s 처럼 PCI-E Gen 1 과 비슷한, 더 낮은 세대 수준으로 떨어졌다. 이 노드가 낀 학습 작업은 몇 % 에서 2배까지 느려졌다.
- 원인
- 구성 요소
- 기여 요인
- –
- 감지
Autopilot 이 모든 노드에서 NVIDIA 의 CUDA 코드로 PCI-E 링크를 주기적으로 시험했다. 이 시험은 가벼워서 고객 워크로드를 거의 방해하지 않았다. 워크로드와 시험이 같은 자원을 두고 다퉈 생기는 오탐을 막으려고, 한 시간마다 모은 값 12개의 평균이 임계값 아래로 떨어질 때만 경보를 냈다. 링크가 저하된 노드는 Grafana 대시보드에 표시되었다. 임계값은 PCI-E 링크 세대마다 다르다.
- 조치
- 95% 이상의 경우 PCI-E 장치를 재설정해 문제를 풀었다. 재설정은 주로 VM 을 재부팅해서 했다.
- VM 을 주기적으로 재부팅했다.
- 후속 조치
- Autopilot 으로 NVIDIA 의 CUDA 코드를 써서 PCI-E 링크 검사를 주기적으로 돌리고, 12시간 평균으로 경보를 낸다.
- PCI-E 링크 저하의 근본 원인을 계속 조사한다.
- 교훈
수백, 수천 개의 GPU 를 함께 쓰는 분산 학습에서는 노드 한 대의 성능만 떨어져도 작업 전체가 느려진다. 그래서 IBM 은 작업이 도는 동안에도 가벼운 검사를 모든 노드에서 주기적으로 돌려, 성능을 서서히 떨어뜨리는 링크 저하를 미리 찾는다. 이런 검사와 경보 덕분에 SRE 는 사용자가 신고하면 디버깅하던 방식에서 사용자가 알기 전에 먼저 알리는 방식으로 바뀌었고, 근본 원인을 찾는 시간을 2배 넘게 줄였다.
이 2건에서 가장 많이 나오는 구성 요소: PCIe 링크, 서버 전원 공급 장치와 전력 제한. kubegap 은 Claude Code 나 Codex 에서 쿠버네티스 클러스터를 읽기만 하며 이런 틈을 점검합니다. 점검 항목의 근거는 이 라이브러리와 같은 공개 보고서입니다.