GPU 전력/사용률, 구간 평균의 함정
NVML/DCGM/nvidia-smi는 구간 평균·비율이다. 1Hz 로깅에서 LLM 추론 전력 변동을 해석한다.
DCGM은 GPU 메트릭을 **기본 1Hz(1000ms)**로 샘플링한다. NVML의 nvmlDeviceGetPowerUsage는 Ampere(단, GA100 제외) 이후 GPU에서 1초 평균 전력을 돌려준다. nvidia-smi가 보여주는 GPU/메모리 Util도 “지난 샘플 기간 동안” 커널 실행/메모리 R/W가 있었던 시간 비율이다(제품별로 1초~1/6초). 이 세 가지를 이해하면, “로컬 LLM 추론 중 GPU 전력/사용률이 왜 입력 형태에 따라 다르게 보이느냐”는 질문을 더 차분히 정리할 수 있다. 우리가 보는 그래프는 ‘순간’이 아니라, 직전 구간을 평균낸 결과이기 때문이다.
세 줄 요약
- 핵심 이슈: LLM 추론 중 GPU 전력/사용률이 토큰 수만이 아니라 프롬프트 구조(질문형/추론형)와 함께 흔들려 보일 때, 그 차이가 ‘계산 차이’인지 ‘측정/평균화의 영향’인지 분리해야 한다.
- 왜 중요: NVML/DCGM의 전력·활동 지표는 “지난 샘플 구간” 기반이다. 1초 로깅만으로는 서브초 버스트·지연·종료 직후 잔여 커널이 몇 개 샘플로 합쳐져 보일 수 있다. 이 때문에 전력 제한, 배치 스케줄링, “응답이 끝났는데 왜 GPU가 도나” 같은 운영 판단이 흔들릴 수 있다.
- 독자가 할 일: 1Hz(기본) + 필요 시 100ms까지 질의 간격을 낮춘 로그를 세션 단위로 나눈다. “응답 종료 후 대기 구간”을 포함한 프로토콜로 재현한다. 그 다음 디코딩 설정을 바꿔 루프/종료 지연이 전력 패턴에 어떤 변화를 주는지부터 확인한다.
현황
GPU 전력/사용률을 “추론 부하”의 대리 지표로 쓰는 경우가 있다. 다만 NVIDIA가 정의하는 지표가 실시간 값이 아닐 수 있다는 점을 먼저 고려해야 한다. NVML 문서에서 nvmlDeviceGetPowerUsage는 Ampere(단, GA100 제외) 이후는 1초 평균 전력을 반환한다고 적는다. 프롬프트가 특정 순간에 부하를 올려도, 1초 창에서 평균내면 피크가 완만하게 보이거나 종료 후에도 값이 남는 것처럼 보일 수 있다.
nvidia-smi에서 흔히 보는 GPU/Memory Util도 해석에 주의가 필요하다. 이 값은 “지난 샘플 기간 동안” GPU에서 커널이 실행된 시간 비율로 정의된다. 메모리 Util은 “지난 샘플 기간 동안” 글로벌 메모리 R/W가 있었던 시간 비율로 정의된다. 그리고 샘플 기간은 제품별로 1초~1/6초 범위로 달라질 수 있다. 같은 워크로드라도 장비에 따라 그래프가 다르게 보일 수 있다.
DCGM은 “프로파일링 메트릭 기본 샘플레이트가 1Hz(1000ms)”라고 안내한다. 사용자는 질의 주기를 더 촘촘히 설정할 수 있다. 문서에 따르면 최소 100ms까지 낮출 수 있다. 다만 1초든 100ms든, “기간 동안의 활동 비율” 같은 정의 자체는 유지된다. 즉, 우리는 계속 구간 평균/구간 비율을 보고 있다.
분석
운영에서 이 이슈가 까다로운 이유는, LLM 추론이 “토큰을 하나씩” 출력하는 동작처럼 보이더라도 GPU 내부에서는 커널 실행이 버스트로 나타나고 프레임워크/드라이버 레벨 큐잉이 섞일 수 있기 때문이다. 여기에 NVML/DCGM의 구간 평균이 더해지면, 입력이 달라질 때 GPU 전력 곡선이 달라 보일 수 있다. 이때 먼저 해야 할 일은, 그 차이가 모델의 연산량 차이에서 온 것인지, 아니면 측정 창과 워크로드 버스트가 맞물린 결과인지 구분하는 것이다.
또 다른 변수는 “실패 모드”다. 무한 반복 생성이나 종료 지연 같은 문제는 전력 패턴을 크게 바꿀 수 있다. 예를 들어 Hugging Face의 한 모델 토론에서는 “무한 generation loop” 이슈가 보고됐고, 임시 회피책으로 greedy decoding을 피하고 do_sample=True, temperature=0.6, top_p=0.9 같은 샘플링 설정을 권고했다. 여기서 핵심은 특정 모델 하나의 문제로 단정하는 것이 아니다. 디코딩 정책이 루프/종료 지연과 연관될 수 있고, 그 경우 전력/사용률 그래프는 토큰 길이만으로 설명하기 어려워진다는 점이다.
실전 적용
재현·검증의 출발점은 “GPU 로그가 무엇을 의미하는지”를 먼저 고정하는 일이다. NVML 전력은 (해당 아키텍처에선) 1초 평균일 수 있다. DCGM은 기본이 **1Hz(1000ms)**다. 따라서 ‘토큰당 전력’ 같은 결론을 먼저 내리기보다, 세션을 분리하고 관측 구간을 명확히 잡아야 한다.
프롬프트 전송 전 대기 구간과 응답 종료 후 대기 구간을 로그에 포함한다. 이를 통해 “종료 후에도 GPU가 도는 것처럼 보이는 샘플”이 실제 잔여 작업인지, 평균화/지연 때문에 그렇게 보이는지 구분한다. 그 다음에야 프롬프트 카테고리(질문형/추론형 등) 비교가 해석 가능한 형태가 된다.
예: 같은 출력 길이를 목표로 두 프롬프트를 만든다(하나는 짧은 Q&A, 하나는 단계적 추론). 같은 디코딩 설정으로 실행한다. DCGM을 기본 1Hz로 먼저 기록하고, 같은 실험을 100ms 질의로 한 번 더 기록한다. 두 로그에서 “응답 종료 직후” 구간의 전력/Util이 어떻게 뭉개져 보이는지 비교하면, 관측된 ‘잔열’이 측정 창 때문인지, 실제로 커널이 남아 있었는지 판단에 도움이 된다.
오늘 바로 할 일 체크리스트
- DCGM을 **기본 1Hz(1000ms)**로 찍는 로그와, 가능한 경우 100ms 질의 로그를 같은 실험에서 함께 남겨 비교한다.
- 각 세션에 “프롬프트 투입 전 대기”와 “응답 종료 후 대기” 구간을 넣는다. Util/전력의 구간 평균이 어느 구간에 걸리는지 확인한다.
- 무한 루프/종료 지연이 의심되면 greedy를 피하고
do_sample=True, temperature=0.6, top_p=0.9같은 설정으로 재실험한다. 전력 패턴 변화가 실패 모드와 연결되는지 분리한다.
FAQ
Q1. nvidia-smi의 GPU Util 70%는 “GPU가 70% 속도로 일했다”는 뜻인가?
A1. 그렇지 않습니다. 문서 정의상 GPU Util은 “지난 샘플 기간 동안” 커널 실행이 있었던 시간 비율입니다. 샘플 기간이 제품별로 1초~1/6초일 수 있어, 짧은 버스트가 평균화되어 보일 수 있습니다.
Q2. NVML 전력 값은 순간 전력인가, 평균 전력인가?
A2. NVML 문서에 따르면 nvmlDeviceGetPowerUsage는 Ampere(단, GA100 제외) 이후 GPU에서 1초 평균 전력을 반환합니다. GA100 및 그 이전 아키텍처는 동작이 다를 수 있습니다.
Q3. DCGM은 어느 정도로 촘촘하게 측정할 수 있나?
A3. DCGM 문서에서는 프로파일링 메트릭 기본 샘플레이트가 **1Hz(1000ms)**이고, 사용자가 질의 빈도를 조정할 수 있으며 최소 100ms까지 낮출 수 있다고 안내합니다.
결론
로컬 LLM 추론의 GPU 패턴을 “토큰 길이”만으로 해석하면, NVML/DCGM이 제공하는 구간 평균/구간 비율이라는 전제와 충돌할 수 있다. 먼저 측정 창과 세션 설계를 고정한다. 그 다음 입력 카테고리, 디코딩 설정, 실패 모드가 전력/사용률 그래프를 어떻게 바꾸는지 나눠서 본다.
다음으로 읽기
참고 자료
- NVML API Reference Guide :: GPU Deployment and Management Documentation (nvmlDeviceGetPowerUsage) - docs.nvidia.com
- Feature Overview — NVIDIA DCGM Documentation (Profiling Metrics) - docs.nvidia.com
- Data Center GPU Manager User Guide (v2.2) — Feature Overview - docs.nvidia.com
- meta-llama/Llama-3.1-8B-Instruct · The model often enters infinite generation loops (discussion #32) - huggingface.co
업데이트 받기
주간 요약과 중요한 업데이트만 모아서 보내드려요.
오류를 발견했나요? 정정/오류 제보로 알려주시면 검토 후 업데이트에 반영할게요.