제7부 엔터프라이즈 운영과 MLOps

7.3 쿠버네티스 GPU 운영 II — DCGM·모니터링·스케줄링

7.3.1 이 장에서 배우는 것 / 선수 지식

7.2에서 GPU Operator로 GPU를 스케줄 가능한 자원으로 만들었다. 이제 관측·배치 — GPU가 실제로 어떻게 실행되고 있나를 보고, 워크로드를 GPU에 잘 배치하는 운영 — 을 판다. CPU·메모리 메트릭으로는 GPU 워크로드를 진단할 수 없다(6.8의 "GPU 메트릭으로 오토스케일"). DCGM(Data Center GPU Manager)이 GPU 텔레메트리(활용률·메모리·온도·전력·ECC·텐서코어)를 수집하고, Prometheus·Grafana로 모니터링한다. 그리고 다GPU 학습은 토폴로지(NVLink)·갱 스케줄링처럼 기본 스케줄러가 못 하는 배치가 필요하다.

핵심 통찰: "GPU util 90%"가 일을 잘하고 있다는 뜻이 아니다. SM은 바쁜데 텐서코어는 놀거나 메모리 바운드일 수 있다(2.14·5.12). 깊은 메트릭(SM 활동·텐서코어 util·DRAM 대역폭)을 봐야 정확한 진단이 된다. 그리고 다GPU 학습은 NVLink로 묶인 GPU에 배치(4.14)하고 전부 또는 전무(gang) 로 스케줄해야 — 부분 할당은 교착·낭비를 부른다.

배우는 것:

DCGM — GPU 텔레메트리(util·메모리·온도·전력·ECC·클럭·텐서코어·DRAM 대역), DCGM exporter → Prometheus·Grafana.
메트릭 해석 — util vs SM 활동 vs 텐서코어 util vs DRAM 대역(2.14·5.12 연결), "util 90%"의 함정.
헬스·진단 — Xid 에러·ECC·thermal throttling, 불량 GPU 노드 cordon/drain.
토폴로지 인지 스케줄링 — 다GPU 파드를 NVLink로 묶인 GPU에(4.7·4.14), NUMA/PCIe.
갱(gang) 스케줄링 — 다GPU·다노드 학습의 전부-또는-전무 배치(Volcano/Kueue류), 부분 할당 교착 방지.
오토스케일·관측 스택(6.8 연결)·비용/활용 가시성.

선수 지식: 7.2(GPU Operator·device plugin — DCGM 포함), 6.8(HPA·오토스케일), 2.14(Nsight Compute·깊은 메트릭)·5.12(활용률), 4.7·4.14(NVLink 토폴로지·매핑), 5.14(Triton 메트릭). 공유는 7.5, MLOps는 7.7. 환경은 7.2 클러스터.

정직: DCGM 메트릭 이름·Grafana 대시보드·배치 스케줄러(Volcano·Kueue 등)는 버전·생태계 의존이다 — 이 장은 무엇을 보고 어떻게 배치하나의 원리를 가르치고 구체 이름은 한 형태를 예시. 모든 수치는 환경 의존, 실측.

7.3.2 DCGM — GPU 텔레메트리

DCGM은 데이터센터 GPU의 모니터링·관리 도구다. 수집하는 것:

구분	메트릭
기본 텔레메트리	GPU 활용률(%)·메모리 사용량·메모리 대역폭
기본 텔레메트리	온도·전력·클럭(throttling 여부)
기본 텔레메트리	ECC 에러·Xid 에러(하드웨어 오류)
기본 텔레메트리	NVLink·PCIe 처리량
프로파일링 메트릭(더 깊게, 2.14)	SM 활동(occupancy)·텐서코어 활용률
프로파일링 메트릭(더 깊게, 2.14)	DRAM 읽기/쓰기 대역폭·캐시

'GPU가 무엇을 하고 있나'를 정밀하게 본다.

DCGM exporter가 이를 Prometheus 형식으로 노출(:9400 등) → Prometheus 수집 → Grafana 대시보드·알림. GPU Operator(7.2)가 DCGM exporter를 자동 배포한다.

7.3.3 메트릭 해석 — "util 90%"의 함정

가장 흔한 오해: "GPU 활용률 90% = 잘 쓰고 있다". 틀릴 수 있다.

메트릭	의미	진단
GPU util	커널이 떠 있는 시간	높아도 효율은 모름
SM 활동/occupancy	SM이 채워졌나	낮으면 점유율 문제(1.6·5.12)
텐서코어 util	텐서코어 사용	낮으면 FP32·미정렬·정밀도(1.11·5.5)
DRAM 대역폭	메모리 사용	높고 텐서코어 낮으면 메모리 바운드(1.10)
전력·온도	throttling	한계면 클럭 저하·성능↓

핵심: util만 보면 오진한다. "util 90%인데 처리량이 낮다"는 텐서코어 미사용·메모리 바운드·낮은 occupancy일 수 있다 — DCGM의 깊은 메트릭으로 2.14(Nsight Compute) 수준의 진단을 클러스터 차원에서. 학습·추론이 텐서코어를 제대로 쓰는지를 본다.

7.3.4 헬스·진단 — 불량 GPU 격리

GPU는 하드웨어라 고장난다. DCGM이 건강 상태를 본다:

구분	내용
주요 신호	Xid 에러: GPU 드라이버/하드웨어 오류(메모리·과열·버그) — 종류로 원인 추정
주요 신호	ECC 에러: 메모리 비트 오류(정정 가능/불가), 불가면 심각
주요 신호	thermal throttling: 과열로 클럭 저하(성능↓)
주요 신호	메모리 잔여·프로세스 누수
대응	불량 GPU 노드 cordon(새 스케줄 차단)·drain(파드 이주) → 점검·교체
대응	DCGM 진단(diagnostic)으로 주기 헬스체크
대응	알림(Xid·ECC·throttling 임계)

대규모 GPU 클러스터에서 하드웨어 고장은 일상이다(수천 GPU면 매주 몇 개). 학습 중 한 GPU가 죽으면 전체 잡이 멈출 수 있어(동기 학습), 헬스 모니터링·자동 격리·체크포인트(7.7)가 필수다.

견해: 학습 잡은 GPU 고장에 취약하다(동기·다GPU). DCGM 헬스로 불량 노드를 조기 격리하고, 잡은 체크포인트로 재개 가능하게(6.2·7.7). 추론은 복제본으로 견디지만(6.8), 학습은 한 노드 실패가 전체를 멈출 수 있어 관측·내결함성이 더 중요.

7.3.5 토폴로지 인지·갱 스케줄링

기본 k8s 스케줄러는 GPU를 개수로만 보고, GPU 간 연결(NVLink)·전부-또는-전무를 모른다. 다GPU 워크로드엔 부족하다.

① 토폴로지 인지 스케줄링. 다GPU 파드(텐서 병렬, 5.9)는 NVLink로 묶인 GPU에 배치해야 통신이 빠르다(4.7·4.14):

구분	내용
문제	TP=4 파드가 한 노드의 4 GPU를 받았는데, 그 4개가 NVLink로 잘 안 묶이면 매 레이어 all-reduce가 느림(4.14) → 같은 4 GPU라도 성능 차이
해결	토폴로지 인지 — NVLink/NVSwitch로 연결된 GPU 그룹에 배치(device plugin·스케줄러가 토폴로지를 고려, NUMA/PCIe도)

② 갱(gang) 스케줄링. 다GPU·다노드 학습은 모든 워커가 동시에 있어야 시작된다(NCCL 집합연산, 4.13). 기본 스케줄러는 파드를 하나씩 배치해 부분 할당 교착을 부른다:

구분	내용
문제(기본 스케줄러)	16-GPU 잡이 8개만 배치되고 나머지 8개는 자원 대기 → 8 GPU를 점유한 채 멈춤, 다른 잡도 못 들어옴 → 교착·낭비
해결	갱 스케줄링 — '전부 배치 가능할 때만 전부 배치, 아니면 전무' → Volcano·Kueue·배치 스케줄러가 all-or-nothing·큐·우선순위 제공

스케줄링	무엇을	왜
토폴로지 인지	NVLink로 묶인 GPU에 다GPU 파드	TP 통신 성능(4.14)
갱(gang)	전부-또는-전무 배치	다GPU 학습 교착 방지
affinity/taint	GPU 노드풀 분리·배치	워크로드 격리
우선순위·preemption	학습 vs 추론 혼합	자원 경합 조정
bin-pack vs spread	모으기 vs 분산	활용 vs 내결함

핵심: 추론은 단일 GPU·복제(6.8)라 기본 스케줄러로 충분하지만, 다GPU 학습은 토폴로지·갱 스케줄링이 필요하다 — NVLink로 묶고(통신), 전부-또는-전무로(교착 방지). 학습 클러스터는 Volcano·Kueue 같은 배치 스케줄러를 흔히 쓴다.

7.3.6 워크스루 — 관측·진단·배치

   1) 관측 스택(GPU Operator가 DCGM exporter 배포, 7.2):
      Prometheus가 DCGM exporter 스크레이프 → Grafana GPU 대시보드
      curl <dcgm-exporter>:9400/metrics | grep DCGM_FI_DEV   # GPU 메트릭(이름 버전 확인)

   2) 진단 — util만 보지 말 것:
      util 높은데 처리량 낮음 → 텐서코어 util·DRAM 대역 확인
        텐서코어 낮음 → FP32·미정렬·정밀도(1.11·5.5)
        DRAM 높음 → 메모리 바운드(1.10)
        SM occupancy 낮음 → 점유율(1.6·5.12)

   3) 헬스:
      Xid·ECC·throttling 알림 → 불량 노드 cordon/drain
      kubectl cordon <node>; kubectl drain <node> --ignore-daemonsets

   4) 다GPU 학습 배치:
      갱 스케줄러(Volcano/Kueue)로 잡 제출 → 전부 배치되면 시작(교착 방지)
      토폴로지 인지로 NVLink 묶인 GPU에(TP 통신, 4.14)

   5) 오토스케일(6.8):
      HPA를 GPU util·큐 깊이(DCGM/Triton 메트릭)로 → 추론 복제 스케일
      Cluster Autoscaler로 GPU 노드 추가/제거(비용)

운영: GPU util·메모리·온도·전력 + 텐서코어·DRAM 대역 + 워크로드(Triton/NIM) 메트릭을 Grafana 한 대시보드로. 알림은 Xid·ECC·throttling·낮은 활용(비용)·높은 큐(SLA). 비용 가시성으로 right-sizing(6.8).

7.3.7 중간 점검 (체크포인트)

[ ] DCGM이 GPU 텔레메트리(util·메모리·온도·전력·ECC·텐서코어·DRAM)를 수집하고 Prometheus·Grafana로 관측됨을 안다.
[ ] "util 90%"의 함정 — 텐서코어 util·DRAM 대역·SM occupancy로 실질적 효율을 진단(2.14·5.12).
[ ] 헬스(Xid·ECC·throttling)로 불량 GPU를 cordon/drain하고, 학습이 고장에 취약함을 안다.
[ ] 토폴로지 인지(NVLink 묶인 GPU에 다GPU 파드)와 갱 스케줄링(전부-또는-전무, 교착 방지)의 필요를 안다.
[ ] 추론(복제·기본 스케줄러)과 학습(토폴로지·갱·배치 스케줄러)의 스케줄링 차이를 안다.
[ ] HPA(GPU 메트릭)·Cluster Autoscaler·비용 가시성을 운영에 잇는다.

증상→의심: CPU 메트릭으론 GPU 부하 안 보임 → GPU 메트릭(DCGM)으로. util 높은데 느림 → 텐서코어 미사용·메모리 바운드 → 깊은 메트릭. 학습 잡이 8/16만 배치되고 멈춤 → 갱 스케줄링 없음 → Volcano/Kueue. TP 학습이 같은 GPU 수로 느림 → 토폴로지(NVLink 안 묶임) → 토폴로지 인지. GPU 고장으로 학습 전체 중단 → 헬스·체크포인트 없음 → DCGM·체크포인트. GPU 유휴 비용 → 활용 가시성 없음 → DCGM 활용 리포트·right-sizing(6.8).

7.3.8 트레이드오프·대안

결정	트레이드오프
util만 vs 깊은 메트릭	단순 vs 정확한 진단(텐서코어·DRAM)
기본 스케줄러 vs 배치(Volcano/Kueue)	추론 충분 vs 학습 갱·큐·우선순위
bin-pack vs spread	활용·비용↑ vs 내결함·격리
DCGM/Prometheus vs 클라우드 매니지드 모니터링	자체·유연 vs 운영↓·종속

견해: 추론 클러스터는 기본 스케줄러 + DCGM 관측 + HPA(GPU 메트릭) 로 충분하고, 학습 클러스터는 배치 스케줄러(갱·토폴로지·큐·우선순위) + 헬스·체크포인트가 필요하다. 관측은 util만 보지 말고 텐서코어·DRAM까지 — 그래야 "고가의 GPU가 실제로 일하나"를 안다. 비용은 활용 가시성으로 right-sizing(6.8)·유휴 제거.

비엔비디아 정직: 갱·토폴로지 스케줄링은 k8s 생태계 도구(Volcano·Kueue·스케줄러 플러그인)가 제공하고 DCGM·Prometheus·Grafana는 표준 관측이다. NVIDIA의 강점은 DCGM의 깊은 GPU 텔레메트리·GPU Operator 통합·토폴로지 인지다. 클라우드 매니지드 모니터링·다른 배치 스케줄러도 대안 — 워크로드·규모로 판단.

7.3.9 흔한 함정

CPU/메모리 메트릭으로 GPU 운영. GPU 부하를 반영 못 함 → DCGM GPU 메트릭.
util 90%를 효율로 오해. 텐서코어·DRAM·occupancy를 봐야 실질적 효율(2.14·5.12). util은 "떠 있음"일 뿐.
갱 스케줄링 없이 다GPU 학습. 부분 할당 교착·자원 낭비 → Volcano/Kueue.
토폴로지 무시. TP 파드가 NVLink 안 묶인 GPU에 떨어져 느림(4.14) → 토폴로지 인지.
헬스 모니터링 없음. 불량 GPU(Xid·ECC·throttling)가 학습 전체를 망침 → DCGM 헬스·cordon/drain·체크포인트.
알림 없음. 에러·throttling·유휴를 안 보면 사고·비용 방치 → Grafana 알림.
추론·학습 같은 스케줄링 가정. 추론(복제)과 학습(갱·토폴로지)은 다름.
유휴 GPU 비용 방치. 활용 가시성 없으면 고가의 GPU가 유휴여도 모름 → 활용 리포트·right-sizing.

7.3.10 연습문제

연습 1 (util 함정). "우리 학습 GPU util이 95%니 잘 쓰고 있다"는 주장을 반박하고, 실질적 효율을 진단할 메트릭 셋과 각 의미를 제시하라.

정답

반박: GPU util은 "GPU에 커널이 떠 있는 시간 비율" 일 뿐, 그 커널이 효율적인지·텐서코어를 쓰는지·SM이 채워졌는지는 모른다. util 95%여도 텐서코어는 거의 유휴 상태이고(메모리 바운드, 1.10) 처리량이 낮을 수 있다. 진단 메트릭: ① 텐서코어 util(1.11) — 딥러닝 행렬 연산이 텐서코어를 쓰나; 낮으면 FP32·미정렬 shape·정밀도 미설정(5.5)으로 텐서코어 미사용 → 큰 손실. ② DRAM 대역폭(1.9) — 메모리 사용; 높고 텐서코어 낮으면 메모리 바운드(연산보다 데이터 이동이 병목, 1.10). ③ SM occupancy/활동(1.6) — SM이 실제로 채워졌나; 낮으면 점유율 문제(레지스터·블록 구성). 종합: util 95% + 텐서코어 20% + DRAM 90%면 "GPU는 바쁘지만 텐서코어를 못 쓰고 메모리에 묶임" → 정밀도·데이터 경로·shape를 고쳐야. util만으로는 이 진단이 불가 — DCGM 깊은 메트릭(클러스터판 Nsight Compute, 2.14)이 필요.

연습 2 (갱 스케줄링). 16-GPU 학습 잡을 기본 k8s 스케줄러로 제출했더니 8개만 배치되고 멈췄으며 다른 잡도 못 들어온다. 원인과 해결을 설명하라.

정답

원인: 부분 할당 교착 — 기본 스케줄러는 파드를 하나씩 독립적으로 배치한다. 16-GPU 잡의 워커 파드 중 8개가 배치되고 나머지 8개는 자원이 없어 Pending. 그런데 다GPU 학습은 모든 워커가 있어야 NCCL 집합연산(4.13)으로 시작하므로 8개만으론 진행 불가 → 8 GPU를 점유한 채 멈춤. 그 8 GPU가 묶여 다른 잡도 못 들어와 클러스터 자원 낭비·교착. 해결: 갱(gang) 스케줄링 — Volcano·Kueue 같은 배치 스케줄러로 "전부 배치 가능할 때만 전부, 아니면 전무(all-or-nothing)" 정책. 16 GPU가 모두 가용할 때 한꺼번에 배치, 아니면 큐에서 대기(부분 점유 안 함). 큐·우선순위·preemption도 제공. 다GPU/다노드 학습에는 갱 스케줄링이 필수 — 기본 스케줄러는 추론(독립 복제)용. 토폴로지 인지(NVLink 묶기)도 함께.

연습 3 (헬스). 수천 GPU 학습 클러스터에서 하드웨어 고장이 일상이다. DCGM 헬스로 무엇을 보고, 학습 잡이 고장에 취약한 이유와 대응을 설명하라.

정답

DCGM 헬스 신호: Xid 에러(드라이버/하드웨어 오류, 종류로 원인 추정)·ECC 에러(메모리 비트 오류, 정정 불가면 심각)·thermal throttling(과열로 클럭 저하)·메모리 누수. 학습 취약 이유: 다GPU 동기 학습은 모든 워커가 매 스텝 집합연산(4.13)으로 동기화하므로, 한 GPU가 죽으면 전체 잡이 멈추거나 행(hang). 수천 GPU면 확률상 매주 몇 개 고장 → 긴 학습이 자주 중단. 대응: ① DCGM 헬스 모니터링·알림으로 불량 GPU 조기 탐지. ② 불량 노드 cordon/drain(새 스케줄 차단·파드 이주) 후 교체. ③ 체크포인트(6.2·7.7) — 주기적으로 상태 저장해 고장 시 마지막 체크포인트에서 재개(처음부터 X). ④ 내결함 학습(일부 프레임워크의 elastic·재시작). 추론은 복제본(6.8)으로 견디지만 학습은 단일 실패가 전체를 멈추므로 헬스·체크포인트가 더 중요. 관측 없이는 어느 GPU가 잡을 죽였는지도 모른다.

연습 4 (토폴로지). TP=8 학습 파드가 한 노드의 8 GPU를 받았는데 다른 동일 노드보다 느리다. DCGM·토폴로지로 진단·해결하라.

정답

진단: TP=8은 매 레이어 all-reduce(5.9)로 통신이 잦은데, 8 GPU가 NVLink/NVSwitch로 잘 묶이지 않으면(또는 일부가 PCIe·먼 토폴로지) 통신이 느려 같은 8 GPU라도 성능 저하(4.14). DCGM의 NVLink 처리량 메트릭으로 GPU 간 통신이 NVLink 대역에 근접하는지, nvidia-smi topo -m(4.6)로 토폴로지 확인 — 느린 노드는 NVLink가 아니라 PCIe를 타거나 NVSwitch 전결합이 아닐 수 있음. 해결: ① 토폴로지 인지 스케줄링 — 스케줄러/device plugin이 TP 파드를 NVLink로 전결합된 GPU 그룹에 배치하도록(NUMA·PCIe·NVLink 고려). ② 노드 자체가 PCIe 느슨 연결이면(4.1 SXM vs PCIe) 그 노드를 TP 학습에서 제외. ③ NCCL 환경변수·친화도(4.14)로 통신 경로 최적화. 핵심: TP는 NVLink 도메인에 정렬해야(4.14) — 토폴로지 인지 없으면 같은 GPU 수로도 통신 병목.

연습 5 (관측 스택). production GPU 클러스터(추론+학습)의 관측·알림을 설계하라. 무엇을 수집·대시보드·알림하나?

정답

수집: GPU Operator의 DCGM exporter(GPU util·메모리·온도·전력·텐서코어 util·DRAM 대역·NVLink·Xid·ECC) + 워크로드 메트릭(Triton/NIM: 처리량·큐 vs 컴퓨트 시간·p99·실패율, 5.14·6.7) → Prometheus. 대시보드(Grafana): ① GPU 하드웨어(util·텐서코어·DRAM·온도·전력·메모리) — "고가의 GPU가 실제로 일하나". ② 워크로드(처리량·p99·goodput·큐). ③ 헬스(Xid·ECC·throttling). ④ 활용/비용(유휴 GPU·GPU-시간). 알림: Xid·ECC(불가)·thermal throttling(하드웨어), p99 SLA 위반·큐 폭증(서비스), 낮은 활용 지속(비용), 학습 잡 행/중단. 운영 연결: 불량 노드 cordon/drain, HPA를 GPU util·큐 깊이로 추론 스케일(6.8), 학습은 갱 스케줄러·체크포인트, 활용 리포트로 right-sizing. 핵심: 하드웨어(DCGM 깊은 메트릭) + 워크로드(Triton)를 통합해 "효율·SLA·헬스·비용"을 한눈에, util만이 아니라 텐서코어까지.

7.3.11 요약 · 다음 장

CPU 메트릭으로 GPU를 운영할 수 없다 — DCGM이 GPU 텔레메트리(util·메모리·온도·전력·ECC·텐서코어·DRAM 대역)를 수집, exporter→Prometheus→Grafana로 관측(GPU Operator가 배포).
"util 90%"의 함정 — 텐서코어 util·DRAM 대역·SM occupancy를 봐야 실질적 효율을 진단한다(2.14·5.12). util은 "떠 있음"일 뿐.
헬스(Xid·ECC·throttling)로 불량 GPU를 cordon/drain. 학습은 GPU 고장에 취약(동기·다GPU)하니 헬스·체크포인트가 필수.
다GPU 학습은 토폴로지 인지(NVLink 묶인 GPU에, 4.14)·갱 스케줄링(전부-또는-전무, 교착 방지, Volcano/Kueue)이 필요 — 추론(복제·기본 스케줄러)과 다르다.
오토스케일은 GPU 메트릭(HPA·Cluster Autoscaler, 6.8), 비용은 활용 가시성으로 right-sizing. 정직: 메트릭·스케줄러는 생태계 의존, util만으로 오진 금지.

다음 장: 7.4 GPU 가상화·공유 I — vGPU·타임슬라이싱. 베어메탈 k8s를 봤으니, 이제 가상화(VM) 에서 GPU를 다루는 법으로 — VDI·VM에 GPU를 할당하는 vGPU와, 한 GPU를 여러 워크로드가 나누는 공유 방식(타임슬라이싱)을 보고, 7.5에서 MPS·MIG와 비교한다.