GPU·AI 학습 워크로드 검증 — GPU Operator·DCGM 진단·MIG 격리·NCCL 통신·Kueue 쿼터·체크포인트 재개

개념

"GPU가 보인다"는 검증의 시작일 뿐이다

이 레슨의 말 넷을 먼저 적어 둔다. CUDA 는 그래픽처리장치로 계산을 시키는 프로그램을 짤 때 쓰는 기반 소프트웨어, NVLink 는 그 장치 여러 개를 서로 빠르게 잇는 전용 연결, NCCL 은 여러 장치가 학습 중간 결과를 주고받을 때 쓰는 통신 라이브러리, nvidia-smi 는 장치 상태를 한눈에 보여 주는 명령이다. 모두 한 회사(NVIDIA)의 제품 계열 이름이다.

GPU 플랫폼 QA에서 가장 흔한 첫 테스트는 파드 안에서 nvidia-smi 를 실행해 GPU가 보이는지 확인하는 것이다. 이것은 필요하지만 거의 아무것도 보장하지 않는다. GPU가 보여도 다음과 같은 일이 일어날 수 있다.

• 장치의 메모리 일부가 손상되어 학습이 몇 시간 뒤 알 수 없는 NaN으로 멈춘다
• 노드 간 통신이 기대 대역폭의 절반으로 돌아 분산 학습이 두 배 느리다
• 공유 GPU에서 다른 테넌트의 작업이 메모리를 다 써서 내 작업이 OOM으로 죽는다
• 쿼터상 GPU 8개를 받을 수 있는데 입장 대기열에서 영원히 기다린다
• 체크포인트에서 재개했는데 옵티마이저 상태가 빠져 손실(loss)이 튄다

이 레슨은 GPU 플랫폼을 장치 → 공유 → 통신 → 스케줄링 → 작업 다섯 층으로 나눠 각 층의 판정 기준을 세운다.

1층 — GPU Operator 구성요소를 하나씩 검증한다

Kubernetes에서 GPU를 쓰려면 드라이버·컨테이너 런타임 설정·장치 플러그인·모니터링이 모두 맞아야 한다. NVIDIA GPU Operator가 이것들을 한꺼번에 배포·관리한다. 구성요소가 여럿이라 어느 층이 깨졌는지 를 가르는 검증이 필요하다.

두 번째 줄의 "요청 안 한 파드는 GPU를 못 보는가" 는 격리 기준이다. 런타임 설정 실수로 GPU를 요청하지 않은 파드에서 모든 GPU가 보이는 결함은 다른 테넌트의 작업에 간섭할 수 있다.

GPU Operator는 드라이버·툴킷 업그레이드를 노드별로 순차 수행한다. 업그레이드 중 실행 중인 학습 작업이 어떻게 되는지 (작업을 비우고 진행하는지, 그 정책이 문서와 같은지)가 릴리스 전 층의 핵심 기준이다.

2층 — 장치 건전성: DCGM 진단과 Xid

GPU는 물리 장치라 고장 난다. 플랫폼은 고장 난 장치를 작업에 배정하기 전에 걸러내야 한다. NVIDIA DCGM의 진단(dcgmi diag)이 표준 도구다. 진단은 단계가 있고, 높은 단계는 낮은 단계를 포함한다.

결과는 Pass·Fail·Warn·Skip으로 나오고, 실패에는 조치 수준(격리·리셋·감시·설정·분류 필요)과 범주(발열·메모리·NVLink·PCIe·전력, 드라이버· CUDA 설정)가 붙는다. JSON 출력을 지원하므로 판정 레코드로 바로 옮길 수 있다.

QA가 설계할 것은 언제 어느 단계를 돌리고 결과에 따라 무엇을 하는가 다.

[노드 건전성 정책 — 검증 기준으로 쓴 것]
노드 투입 전:        r2 Pass 필수. Warn 이면 운영자 확인 후 투입
작업 종료 후 Xid 발생: 해당 노드 스케줄링 금지(cordon) → r3 → Pass 면 복귀, Fail 이면 격리
주기:               유휴 노드 주 1회 r2
판정 기록:           노드·GPU UUID·단계·결과·조치를 레코드로
검증할 것:          위 정책이 자동으로 실행되는가 — Xid 를 주입했을 때 cordon 까지 걸리는 시간

Xid 는 NVIDIA 드라이버가 커널 로그에 남기는 GPU 오류 코드다. 일부는 애플리케이션 결함일 수 있고, 일부는 장치가 죽어가는 신호다. 흔히 치명으로 다루는 것은 Xid 48(이중 비트 ECC 오류), Xid 79(GPU가 PCIe 버스에서 떨어짐), Xid 74(NVLink 오류) 같은 부류다. 반면 Xid 13(엔진 예외)은 워크로드의 소프트웨어 결함에서도 나온다. 플랫폼이 Xid 번호별로 어떤 조치를 하는지 는 정책이고, QA는 그 정책의 결정 테이블을 시험한다. 드라이버 버전별 Xid 설명은 NVIDIA 문서에서 확인하고 기준에 문서 버전을 적는다.

실제 장치 오류를 만들 수는 없으므로, 시험은 Xid 로그를 흉내 낸 이벤트 주입 과 DCGM의 오류 주입 기능 으로 한다. 레슨 7의 장애 주입과 이어진다.

3층 — 공유: MIG와 시분할은 격리가 다르다

GPU 한 장을 여러 사용자에게 나누는 방식은 크게 둘이다. 두 방식의 격리 수준이 달라 검증 기준도 다르다.

MIG 프로필 이름은 연산 슬라이스 수g.메모리GB 형식이다. 80GB A100·H100 계열은 1g.10gb, 2g.20gb, 3g.40gb, 4g.40gb, 7g.80gb 같은 프로필을 가지며, 아무 조합이나 섞을 수 없고 NVIDIA 문서의 허용 조합만 가능하다. 1g.10gb 일곱 개로 나누면 인스턴스당 10GB씩 70GB가 보이고 나머지는 시스템 몫이다.

MIG 검증 기준의 예:

D-GPU-MIG-01  MIG 프로필 구성 요청 후 N분 안에 노드가 해당 프로필 리소스를 광고한다
              (예: nvidia.com/mig-1g.10gb: 7)
D-GPU-MIG-02  허용되지 않은 조합을 요청하면 구성이 거부되고 원인이 노드 라벨·이벤트에 남는다
D-GPU-MIG-03  인스턴스 A 에서 메모리를 한도까지 할당해도 인스턴스 B 의 작업은 영향 없음
D-GPU-MIG-04  인스턴스 A 의 프로세스 목록·메모리 사용량이 인스턴스 B 컨테이너에서 보이지 않는다
D-GPU-MIG-05  콘솔·과금·쿼터가 MIG 인스턴스를 GPU 1장이 아니라 해당 프로필로 계산한다
D-GPU-MIG-06  MIG 재구성은 실행 중 작업이 없는 GPU 에서만 수행된다 (실행 중이면 대기 또는 거부)

D-GPU-MIG-05는 모듈 38 레슨 5 과제 4의 탈출 결함과 같은 부류다. 장치 층은 맞는데 제품 층(콘솔·과금)이 MIG를 모르는 결함이다.

시분할을 제공한다면 격리가 없다는 사실을 문서·콘솔에 명시했는지 가 기준이 된다. 격리가 없는 공유를 격리가 있는 것처럼 판매하면 기술 결함이 아니라 계약 문제가 된다.

4층 — 통신: NCCL 테스트로 다중 GPU 성능 판정

분산 학습은 GPU 간 통신(주로 all-reduce)에 시간의 상당 부분을 쓴다. 노드 안에서는 NVLink, 노드 사이에서는 InfiniBand·RoCE가 쓰인다. 링크 하나가 느리거나 설정이 틀리면 전체 학습이 가장 느린 링크에 맞춰진다. nccl-tests 의 all_reduce_perf 가 표준 측정 도구다.

결과에서 QA가 읽을 숫자는 둘이다.

algbw (알고리즘 대역폭)  = 입력 크기 ÷ 시간
busbw (버스 대역폭)     = algbw × 보정 계수
                        all-reduce 의 경우 보정 계수 = 2 × (n − 1) / n   (n = 참여 랭크 수)

busbw는 랭크 수에 따른 차이를 보정해 하드웨어 링크의 실제 대역폭에 가깝게 만든 값이다. 그래서 GPU 8개와 16개 결과를 비교하거나, 링크 사양과 비교할 때 busbw를 쓴다. 단, NVLink SHARP 같은 네트워크 내 집계 기능이 켜지면 이 공식이 실제와 맞지 않는다는 보고가 있으므로, 기능 설정을 결과와 함께 기록한다.

판정 기준을 쓰는 방식:

D-NET-NCCL-01  노드 내 8 GPU all_reduce_perf, 메시지 1GB 이상 구간 busbw 가
               기준 노드 측정값의 90% 이상 (기준값: 입고 검증 시 측정, 하드웨어 구성별로 보관)
D-NET-NCCL-02  2노드 16 GPU, 1GB 이상 구간 busbw 가 기준값의 90% 이상
D-NET-NCCL-03  테스트 중 NCCL 오류·타임아웃 0
D-NET-NCCL-04  같은 노드 쌍에서 3회 반복 시 busbw 변동계수 5% 이하
기록:          NCCL 버전, 토폴로지, 활성화된 전송 방식(IB/RoCE/소켓 대체 여부), 환경 변수

기준값을 사양서가 아니라 실측 기준 노드 에서 가져오는 이유가 있다. 같은 GPU와 네트워크 카드라도 구성마다 기대값이 다르다. 공개 사례 하나를 예로 들면, 8 GPU씩 두 노드를 RoCE로 연결한 구성에서 대형 메시지 busbw 최고치가 약 35GB/s 수준으로 보고된 바 있다. 다른 구성에 이 숫자를 기준으로 쓰면 안 된다. 입고 검증 때 측정한 우리 구성의 값을 기준으로 삼고, 이후 측정은 그 대비 비율로 판정한다.

가장 자주 잡히는 결함은 대체 전송 이다. InfiniBand 설정이 틀려 NCCL이 조용히 TCP 소켓으로 대체되면 테스트는 성공하지만 busbw가 한 자릿수 배 낮다. "오류 없음"만 보면 통과한다. 활성화된 전송 방식을 로그에서 확인하는 것을 기준에 넣는다. DCGM r2 진단에 NCCL 시험이 포함된 것도 이런 이유다.

5층 — 스케줄링: Kueue로 쿼터·입장·선점 검증

GPU는 비싸고 모자라서 팀 간 쿼터와 대기열이 필요하다. 기본 Kubernetes 스케줄러는 대기열과 팀 쿼터 개념이 약하다. Kueue는 스케줄러 앞에서 작업 입장(admission) 을 관리하는 Kubernetes 프로젝트로, GPU 플랫폼에서 널리 쓰인다.

쿼터가 있으면 작업이 입장하고 파드가 생긴다. 없으면 파드가 생기지 않은 채 기다린다. Pending 파드로 스케줄러를 채우지 않는 것이 핵심이다. 우선순위와 선점은 ClusterQueue 설정에 따라 동작한다. 기본적으로 높은 우선순위 작업은 대기 중인 낮은 작업보다 먼저 입장하지만, 이미 실행 중인 작업을 밀어내는 것은 선점을 켰을 때만 이다.

Kueue 기반 스케줄링 검증 기준의 예:

D-SCHED-01  팀 A 쿼터 8 GPU, 실행 중 6. 4 GPU 작업 제출 → 입장하지 않고 보류, 파드 0개
D-SCHED-02  팀 A 작업 하나가 끝나 쿼터 여유 4 → 대기 작업이 N초 안에 입장
D-SCHED-03  코호트 안 팀 B 가 쿼터를 쓰지 않을 때 팀 A 가 빌리기 한도까지 빌려 입장
D-SCHED-04  팀 B 가 작업을 제출하면 빌려준 쿼터 회수 정책대로 동작 (선점 켜짐: A 의 빌린 작업 선점 / 꺼짐: 대기)
D-SCHED-05  선점된 작업은 체크포인트 저장 기회(유예 시간)를 받고, 재입장 후 재개 (아래 체크포인트 기준)
D-SCHED-06  다중 노드 작업은 전체 GPU 가 확보될 때만 입장 (일부 워커만 실행되어 GPU 를 붙잡지 않음)
D-SCHED-07  콘솔의 대기 사유 표시가 Workload 조건과 일치

D-SCHED-06은 갱(gang) 입장 이라 불리는 성질이다. 16 GPU 분산 학습에서 워커 12개만 떠서 나머지를 기다리는 동안 12 GPU를 붙잡으면, 다른 팀은 그 GPU를 못 쓰고 이 작업도 실행되지 않는다. 클러스터가 바쁠 때만 드러나므로 경합 조건을 일부러 만들어 시험한다.

작업 층 — 체크포인트 저장·재개의 정확성

며칠씩 도는 학습 작업에서 장애·선점은 일상이다. 플랫폼의 가치는 중단된 곳에서 정확히 이어 가게 하는 데 있다. "재개됐다"는 파드가 다시 떴다는 뜻이 아니다. 판정 기준을 정확성으로 쓴다.

"원자적 저장"이 가장 자주 깨지고 가장 비싸다. 저장 도중 노드가 죽으면 파일 일부만 쓰인 체크포인트가 남고, 재개 로직이 그것을 최신으로 읽어 실패하거나 조용히 틀린 상태로 이어 간다. 시험 방법은 저장 중인 시점을 노려 파드를 강제 종료하는 것이다(레슨 7).

손실 연속성은 해석 판정이 섞인다. "허용 범위"를 수치로 정하기 어려우면, 중단 없이 돈 기준 실행의 같은 스텝 구간 손실과 비교하는 결정적 판정으로 바꾼다.

실무에서 왜 필요한가

GPUaaS 플랫폼의 고객은 GPU 시간에 돈을 낸다. 느린 링크, 격리 없는 공유, 입장하지 못한 채 GPU를 붙잡은 작업, 틀린 지점에서 재개된 학습은 모두 고객이 낸 돈이 사라지는 결함 이다. 그리고 이 결함들은 기능 테스트가 모두 통과한 상태에서 일어난다.

우대사항의 "GPU·AI 워크로드 등 인프라 플랫폼 도메인에서 QA를 해 본 경험"을 증명하는 가장 좋은 이야기는 이 층 구분에서 나온다. "nvidia-smi는 정상이었는데 NCCL 테스트 busbw가 기준의 12%라 IB 대체 전송을 찾았다", "MIG 인스턴스를 과금이 GPU 1장으로 계산하는 결함을 찾았다", "체크포인트 저장 중 강제 종료 시험으로 반쯤 쓴 체크포인트를 최신으로 읽는 결함을 찾았다" 같은 이야기다.

실습 과제

과제 1 — 층 분류 (10분)

아래 증상을 장치·공유·통신·스케줄링·작업 층으로 분류하고, 확인할 첫 번째 검증을 적는다.

1. 16 GPU 학습이 8 GPU 학습보다 스텝당 시간이 오히려 길다
2. 공유 GPU 에서 옆 사용자가 모델을 올리면 내 추론 프로세스가 CUDA OOM
3. 팀 쿼터가 남았는데 콘솔에 "대기 중 — 자원 부족"
4. 재개 후 손실이 초기값 근처로 튄다
5. 학습이 6시간째 NaN 으로 멈췄고 커널 로그에 Xid 48

과제 2 — busbw 계산 (10분)

GPU 8개 all-reduce에서 algbw가 12GB/s일 때 busbw를 계산한다. 같은 노드를 16 GPU 2노드 구성으로 돌려 algbw가 9GB/s가 나왔을 때 busbw를 계산하고, 두 결과를 비교해 무엇을 의심할지 적는다.

과제 3 — MIG 검증 계획 (20분)

"추론 전용 MIG 노드 풀" 기능에 대해 본문의 D-GPU-MIG 기준을 확장해 장치·격리·제품(콘솔·쿼터·과금) 층 기준을 각각 세 개 이상 쓴다.

과제 4 (선택) — 체크포인트 시험 설계 (25분)

체크포인트 기준 일곱 가지 중 원자적 저장·스텝 연속성·상태 완전성의 시험 절차를 쓴다. 중단 시점을 어떻게 맞출지, 무엇을 관찰할지, 판정을 결정적으로 만드는 방법을 포함한다.

자가 체크리스트

• "GPU가 보인다"가 보장하지 않는 것들을 층별로 말할 수 있다
• GPU Operator 구성요소별 검증 질문과 요청하지 않은 파드의 격리 기준을 안다
• DCGM 진단 r1~r4의 내용과 용도를 구분하고 노드 건전성 정책을 기준으로 쓸 수 있다
• Xid 조치 정책을 결정 테이블로 시험하는 방법을 안다
• MIG와 시분할의 메모리·장애 격리 차이를 설명하고 각각의 검증 기준을 쓸 수 있다
• algbw와 busbw의 차이, all-reduce 보정 계수를 설명하고 기준값을 실측으로 잡는 이유를 안다
• NCCL 대체 전송 결함을 잡는 기준을 쓸 수 있다
• Kueue의 ResourceFlavor·ClusterQueue·LocalQueue·Workload와 입장·빌리기·선점 동작을 기준으로 바꿀 수 있다
• 갱 입장이 필요한 이유와 경합 조건에서 시험하는 방법을 안다
• 체크포인트 재개를 스텝·상태·손실·원자성·저장 시간 기준으로 판정할 수 있다

흔한 실수

nvidia-smi 성공을 GPU 검증 완료로 본다. 장치 건전성·통신·격리는 따로 본다.

시분할 공유를 격리된 공유처럼 시험한다. 격리가 없다는 사실이 문서에 있는지가 기준이다.

NCCL 테스트를 "오류 없음"으로 판정한다. 소켓 대체로도 오류 없이 끝난다. busbw와 전송 방식을 본다.

사양서 숫자로 busbw 기준을 잡는다. 구성마다 다르다. 우리 구성의 실측 기준값 대비로.

쿼터 시험을 한가한 클러스터에서만 한다. 갱 입장·선점 결함은 경합에서만 드러난다.

재개 판정을 "파드 재시작 성공"으로 한다. 스텝·옵티마이저 상태·원자적 저장을 본다.

참고 자료

• NVIDIA GPU Operator — Overview
• DCGM Diagnostics — NVIDIA DCGM Documentation
• Supported MIG Profiles — NVIDIA Multi-Instance GPU User Guide
• NVIDIA/nccl-tests — Performance (algbw·busbw 설명)
• Kueue — Cluster Queue
• The Complete NVIDIA Xid Error Field Guide (Abhik Sarkar)
• 이 커리큘럼 안: 모듈 3 레슨 3 「결정테이블」, 모듈 39 레슨 1·2·7, 모듈 38 레슨 4 「흉내 검증과 실물 검증」