GPU 모니터링, 무엇을 봐야 하나
GPU 한 장이 수천만 원입니다. 수십 장을 묶은 클러스터라면 수십억 원짜리 자산이죠. 그런데 많은 조직이 이 자산의 상태를 nvidia-smi 한 줄, 그중에서도 GPU-Util 숫자 하나로 판단합니다. 대시보드에 “GPU 사용률 90%”가 찍히면 안심하고, 30%면 불안해합니다.
문제는 그 90%가 거의 아무것도 말해주지 않는다는 데 있습니다.
GPU-Util이 말하지 않는 것
nvidia-smi의 GPU-Util은 "지난 샘플링 구간 동안 GPU에서 커널이 하나라도 실행된 시간의 비율"을 의미합니다. 커널이 돌았는지 여부만 볼 뿐, 그 커널이 GPU의 연산 유닛을 얼마나 채웠는지는 보지 않습니다.
즉, GPU의 수천 개 코어 중 단 하나만 돌아가도, 그 코어가 메모리 로드를 기다리며 대부분 놀고 있어도 GPU-Util은 100%를 찍을 수 있습니다. 데이터 로더 병목으로 GPU가 CPU의 다음 배치를 기다리는 동안에도 잔여 커널 때문에 활용률은 높게 보일 수 있습니다. 운영자는 “GPU를 꽉 쓰고 있다”고 믿지만, 실제 연산 효율은 20~30%에 머무는 상황이 드물지 않습니다.
이것이 활용률의 함정입니다. 그렇다면 실제로는 무엇을 봐야 할까요?
실제 운영에서 반드시 봐야 할 5가지
지표 | 무엇을 보는가 | 왜 중요한가 |
|---|---|---|
SM Efficiency (연산 유닛 점유율) | 스트리밍 멀티프로세서가 실제로 가동된 비율 | GPU-Util의 '커널 실행 여부'가 아니라 '연산 유닛이 실제로 일했는가'를 측정. 진짜 활용도 |
메모리 대역폭 사용률 | HBM 대역폭이 얼마나 포화되었는가 | 추론 워크로드는 연산보다 메모리 병목이 대부분. 이 수치가 낮으면 연산이 메모리를 기다리는 중 |
GPU 메모리 점유 (VRAM) | 할당·실사용 VRAM과 여유분 | OOM 사고 예방과 추가 워크로드 배치 가능 여부 판단의 기준 |
전력 / 온도 / 클럭 | 소비 전력, 코어 온도, 클럭 스로틀링 | 발열로 클럭이 떨어지면(thermal throttling) 성능이 조용히 깎임. 전력은 곧 비용 |
PCIe / 인터커넥트 트래픽 | 카드 간·노드 간 데이터 이동량 | 분산 학습에서 통신 병목을 잡아내는 핵심. 네트워크가 연산을 붙잡는지 확인 |
핵심은 이 지표들이 서로 연결되어 읽혀야 한다는 점입니다. SM Efficiency가 낮은데 메모리 대역폭이 포화라면 메모리 병목이고, 둘 다 낮은데 PCIe 트래픽이 높다면 통신 병목입니다. 단일 숫자로는 절대 알 수 없는 진단입니다.
단일 지표에서 계층형 관측으로
성숙한 GPU 운영은 지표를 '한 장짜리 숫자'가 아니라 '계층'으로 봅니다. 물리 카드 단에서 전력·온도·클럭을, 그 위에서 연산·메모리 효율을, 다시 그 위에서 워크로드·프로젝트·계정 단위의 사용 패턴을 봐야 전체 그림이 나옵니다. 어느 층에서 병목이 생기는지를 가려내야 “GPU를 더 사자”는 결론이 정말 맞는지 판단할 수 있습니다.
실제로 GPU가 부족한 게 아니라, 있는 GPU를 20%밖에 못 쓰고 있는 경우가 훨씬 많습니다.
AIPub의 접근: 5계층 관측과 50개 이상의 지표
TEN의 GPU 운영 플랫폼 AIPub은 이 문제를 계층형 모니터링으로 풉니다. AIPub은 물리 카드부터 노드, 워크로드, 프로젝트, 계정까지 5개 계층에 걸쳐 50개 이상의 자체 지표를 수집·시각화합니다. 운영자는 “GPU 사용률 90%”라는 착시가 아니라, 각 계층에서 연산 유닛이 실제로 일하고 있는지, 어디서 병목이 생기는지를 한 화면에서 확인할 수 있습니다.
여기에 카드별 전력 상한(Power Limit) 제어를 더하면, 발열과 전력 비용까지 운영 레버로 다룰 수 있습니다. 모니터링이 '사후 확인'에서 '운영 제어'로 넘어가는 지점입니다.
GPU를 더 사기 전에, 지금 있는 GPU가 실제로 얼마나 일하고 있는지부터 보십시오. 그 답이 투자 결정을 바꿉니다.
