GPU 모니터링, 무엇을 봐야 하나: 활용률 너머의 7가지 지표
GPU 한 장이 수천만 원, 수십 장을 묶은 학습 클러스터라면 수십억 원짜리 자산입니다. 그런데 많은 조직이 이 자산의 건강 상태를 nvidia-smi 한 줄, 그중에서도 GPU-Util이라는 숫자 하나로 판단합니다. 대시보드에 "사용률 90%"가 찍히면 "잘 돌고 있네" 하고 넘어가고, 30%가 찍히면 “GPU가 부족한가?” 하고 증설을 검토합니다.
문제는 그 90%가 실제로는 거의 아무것도 보장하지 않는다는 데 있습니다. GPU-Util이 90%인데 학습 처리량(throughput)은 기대의 절반도 안 되는 상황, GPU를 증설했는데 전체 학습 시간이 거의 줄지 않는 상황 — 이 모든 것이 '활용률'이라는 단일 숫자를 믿었기 때문에 벌어집니다.
이 글에서는 GPU-Util이 왜 당신을 속이는지, 그리고 실제 운영에서 반드시 함께 봐야 할 7가지 지표가 무엇인지, 마지막으로 이 지표들을 '단일 숫자'가 아니라 '계층'으로 읽는 방법을 정리합니다.
GPU-Util이란 무엇이고, 무엇을 말하지 않는가
GPU-Util(GPU Utilization)은 "직전 샘플링 구간 동안 GPU에서 커널(kernel)이 하나라도 실행된 시간의 비율"을 뜻합니다. 핵심은 '하나라도'입니다. 이 지표는 커널이 돌았는지 여부만 측정할 뿐, 그 커널이 GPU의 연산 유닛을 얼마나 채웠는지는 전혀 보지 않습니다.
그래서 다음과 같은 일이 일어납니다. GPU에는 수천 개의 CUDA 코어와 수십~수백 개의 SM(Streaming Multiprocessor)이 있는데, 그중 단 하나의 SM만 일하고 나머지가 전부 놀고 있어도 GPU-Util은 100%를 찍을 수 있습니다. 커널이 메모리에서 데이터가 도착하기를 기다리며 대부분의 시간을 '멈춤(stall)' 상태로 보내도, 커널이 '실행 중'이기만 하면 활용률은 높게 표시됩니다.
가장 흔한 착시는 데이터 로더 병목에서 나옵니다. GPU가 CPU에게 다음 배치(batch)를 받기를 기다리는 동안, 직전 연산의 잔여 커널이 남아 있으면 GPU-Util은 여전히 높게 보입니다. 운영자는 “GPU를 꽉 쓰고 있다”고 믿지만, 실제 연산 효율(MFU, Model FLOPs Utilization)은 20~30%대에 머무는 경우가 드물지 않습니다. 참고로 잘 튜닝된 대규모 학습의 MFU도 35~45% 수준이며, 이 수치를 넘기는 것은 상당한 엔지니어링이 필요합니다.
실제 운영에서 반드시 봐야 할 7가지 지표
활용률 하나를 버리는 대신, 다음 7가지를 함께 봐야 비로소 GPU가 '실제로' 무슨 일을 하는지 보입니다.
지표 | 무엇을 측정하는가 | 왜 중요한가 |
|---|---|---|
SM Efficiency | 스트리밍 멀티프로세서가 실제로 가동된 비율 | GPU-Util의 '커널 실행 여부'가 아니라 '연산 유닛이 실제로 일했는가'. 진짜 활용도의 1차 신호 |
메모리 대역폭 사용률 | HBM 대역폭이 얼마나 포화되었는가 | 추론과 많은 학습 구간은 연산이 아니라 메모리 병목. 이 값이 높고 SM이 낮으면 메모리 바운드 |
GPU 메모리 점유(VRAM) | 할당 VRAM, 실사용 VRAM, 여유분 | OOM 사고 예방과 '이 GPU에 워크로드를 더 올릴 수 있는가' 판단의 기준 |
전력(Power Draw) | 카드별 실시간 소비 전력(W) | 전력은 곧 운영비. 전력 대비 처리량이 효율의 실질 지표 |
온도·클럭 스로틀링 | 코어 온도와 클럭 저하 발생 여부 | 발열로 클럭이 떨어지면(thermal throttling) 성능이 '조용히' 깎임. 원인 모를 성능 저하의 단골 |
PCIe·인터커넥트 트래픽 | 카드 간·노드 간 데이터 이동량 | 분산 학습에서 통신 병목을 잡아내는 핵심. 네트워크가 연산을 붙잡는지 확인 |
처리량(Throughput) | 초당 처리 토큰·이미지·샘플 수 | 결국 '일을 얼마나 했는가'의 최종 지표. 위 6개는 이 숫자를 설명하기 위한 진단값 |
이 지표들의 진짜 가치는 서로 교차해서 읽을 때 나옵니다. 몇 가지 대표적인 조합을 보면:
SM 낮음 + 메모리 대역폭 포화 → 메모리 바운드. 연산 유닛이 데이터를 기다리는 중. 배치 크기·양자화·KV 캐시 전략을 조정해야 함.
SM 낮음 + 메모리 대역폭도 낮음 + PCIe 높음 → 통신 바운드. 분산 학습에서 네트워크가 병목. 네트워크 패브릭이나 통신 전략(gradient 압축 등)을 봐야 함.
SM 낮음 + 모두 낮음 → 입력 병목(데이터 로더/전처리) 또는 스케줄링 문제. GPU가 애초에 일을 받지 못하는 상태.
온도 높음 + 클럭 하락 → 냉각·전력 문제. 하드웨어·데이터센터 레벨의 이슈.
단일 숫자로는 이 중 어느 것도 구별할 수 없습니다. “GPU-Util 90%”는 네 가지 상황 모두에서 똑같이 90%로 보일 수 있습니다.
단일 지표에서 계층형 관측(Layered Observability)으로
성숙한 GPU 운영은 지표를 '한 장짜리 숫자'가 아니라 '계층'으로 봅니다. 왜냐하면 병목은 특정 계층에서 발생하는데, 단일 숫자는 어느 계층의 문제인지 가려주지 못하기 때문입니다.
관측해야 할 계층을 아래에서 위로 정리하면 다음과 같습니다.
계층 | 보는 것 | 답하는 질문 |
|---|---|---|
물리 카드 | 전력, 온도, 클럭, 팬 | 하드웨어가 건강한가? 스로틀링은 없나? |
연산·메모리 | SM Efficiency, 메모리 대역폭, VRAM | GPU가 실제로 일하고 있나? 무엇을 기다리나? |
워크로드 | 처리량, Pod/Job별 자원 사용 | 각 작업이 효율적인가? 어디가 느린가? |
프로젝트·팀 | 프로젝트별 GPU-hour, 할당 대비 실사용 | 누가 자원을 효율적으로 쓰나? |
계정·조직 | 전사 사용 패턴, 비용 배분 | 투자가 성과로 이어지나? 증설이 답인가? |
이 계층 구조가 중요한 이유는, 많은 조직이 가장 비싼 결론인 “GPU를 더 사자”로 직행하기 때문입니다. 하지만 계층을 분리해서 보면, 상당수의 경우 문제는 GPU 부족이 아니라 있는 GPU를 20~30%밖에 못 쓰고 있는 운영 비효율이라는 사실이 드러납니다. 증설은 그 비효율을 비싼 값에 복제할 뿐입니다.
AIPub의 접근: 5계층 관측과 50개 이상의 자체 지표
TEN의 GPU 운영 플랫폼 AIPub은 이 문제를 계층형 모니터링으로 설계했습니다. AIPub은 물리 카드부터 노드, 워크로드, 프로젝트, 계정까지 5개 계층에 걸쳐 50개 이상의 자체 지표를 수집하고 시각화합니다. 운영자는 "사용률 90%"라는 착시 하나가 아니라, 각 계층에서 연산 유닛이 실제로 일하고 있는지, 병목이 어느 층에서 생기는지를 한 화면에서 추적할 수 있습니다.
여기에 카드별 전력 상한(Power Limit) 제어가 더해지면, 발열과 전력 비용이 '관측 대상'에서 '운영 레버'로 바뀝니다. 특정 카드의 전력을 제한해 전력 대비 처리량을 최적화하거나, 냉각 여력에 맞춰 클러스터 전체의 전력 프로파일을 조정하는 것이 가능해집니다. 모니터링이 '사후 확인'에서 '능동적 제어'로 넘어가는 지점입니다.
GPU를 더 사기 전에, 지금 있는 GPU가 각 계층에서 실제로 얼마나 일하고 있는지부터 보십시오. 대부분의 경우, 그 답이 증설 품의서를 다시 쓰게 만듭니다.
자주 묻는 질문(FAQ)
Q. GPU-Util이 100%면 GPU를 잘 쓰고 있는 것 아닌가요?
아닙니다. GPU-Util은 커널이 실행 중인 시간의 비율만 측정합니다. 단 하나의 SM만 돌아도, 커널이 메모리를 기다리며 멈춰 있어도 100%가 될 수 있습니다. 실제 연산 활용도는 SM Efficiency와 처리량으로 봐야 합니다.
Q. SM Efficiency는 어떻게 측정하나요?
NVIDIA의 DCGM(Data Center GPU Manager)이 제공하는 프로파일링 지표(예: SM Active, SM Occupancy)로 측정합니다. nvidia-smi 기본 출력에는 없고, DCGM이나 이를 통합한 모니터링 플랫폼이 필요합니다.
Q. 추론 워크로드에서 가장 중요한 지표는 무엇인가요?
메모리 대역폭 사용률과 VRAM 점유입니다. LLM 추론은 대부분 메모리 바운드이기 때문에, 연산 유닛보다 HBM 대역폭이 먼저 포화됩니다. 배치 처리와 KV 캐시 관리가 성능을 좌우합니다.
Q. 지표를 몇 개까지 봐야 하나요?
처음부터 수십 개를 볼 필요는 없습니다. 본문의 7가지(SM Efficiency, 메모리 대역폭, VRAM, 전력, 온도·클럭, 인터커넥트, 처리량)를 계층별로 엮어 보는 것에서 시작해, 병목이 반복되는 지점을 중심으로 세부 지표를 늘려가는 것이 현실적입니다.
→ AIPub의 5계층 GPU 모니터링을 직접 확인하기: