• 목록

LLM 서비스가 커질수록 GPU 부족보다 중요한 문제는 유휴 시간과 급증하는 비용입니다. 같은 GPU를 사용해도 모델 크기, 배치 크기, 메모리 사용 패턴, 요청 지연시간에 따라 실제 처리량은 크게 달라집니다. 클라우드에서는 사용량 측정과 자동 확장이 중요하고, 온프레미스에서는 스케줄링과 자원 격리가 핵심입니다. 이 글에서는 GPU 자원 최적화를 위해 무엇을 측정하고 어떻게 배분해야 하는지 단계별로 살펴보겠습니다.

AI 생성 삽화 · GPU 자원 최적화로 LLM 인프라 비용과 성능 개선하기의 내용을 설명하기 위한 이미지입니다.

핵심 정리
LLM 서비스가 커질수록 GPU 부족보다 중요한 문제는 유휴 시간과 급증하는 비용입니다.

1. GPU 자원 최적화가 필요한 이유

비용보다 먼저 봐야 할 유휴 시간

GPU 비용은 단순히 인스턴스 사용 시간만으로 결정되지 않습니다. 할당된 GPU가 실제 연산에 사용되지 않는 시간이 길면 비용 대비 처리량이 낮아집니다. 예를 들어 데이터 로딩이 느리거나 CPU 전처리가 병목이면 GPU 사용률이 낮은 상태로 인스턴스가 계속 실행될 수 있습니다.

먼저 GPU 사용률, 메모리 사용량, 전력 상태, 작업별 실행 시간, 대기 중인 요청 수를 함께 수집해야 합니다. 사용률 하나만 보면 메모리는 부족하지만 연산 장치가 쉬는 상황을 놓칠 수 있습니다. GPU 시간당 비용 ÷ 처리한 토큰 수 또는 요청 수를 계산하면 서비스별 효율을 비교하기 쉽습니다.

업무 특성에 맞는 GPU 선택

학습과 추론은 GPU를 사용하는 방식이 다릅니다. 대규모 학습은 GPU 간 통신 속도, 고대역폭 메모리, 네트워크 구성이 중요합니다. 반면 추론은 모델의 메모리 점유율과 동시 요청 수, 지연시간 목표에 따라 적절한 GPU가 달라집니다.

항상 가장 비싼 GPU가 최선은 아닙니다. 작은 모델의 실시간 추론에는 여러 개의 고성능 GPU보다 메모리가 충분한 중급 GPU와 효율적인 배칭이 유리할 수 있습니다. 클라우드에서는 온디맨드, 예약형, 스팟 인스턴스를 작업의 중단 허용 여부에 따라 나누고, 중단되면 안 되는 API와 재시작 가능한 배치 작업을 같은 정책으로 운영하지 않는 것이 좋습니다.

---

2. LLM 학습·추론의 GPU 병목 진단

학습 단계에서 확인할 지표

LLM 학습에서는 GPU 사용률만 보지 말고 step time, 메모리 부족 여부, 데이터 공급 속도, GPU 간 통신 대기 시간을 함께 확인해야 합니다. GPU 사용률이 낮다면 데이터로더의 워커 수, 스토리지 읽기 속도, CPU 메모리, 네트워크 처리량을 순서대로 점검합니다.

GPU 메모리가 부족할 때는 무작정 GPU를 추가하기보다 시퀀스 길이와 마이크로 배치 크기를 먼저 조정할 수 있습니다. 그래디언트 체크포인팅은 메모리를 줄이는 대신 연산량을 늘리고, 그래디언트 누적은 작은 배치로도 효과적인 배치 크기를 키우는 방법입니다. 다만 이 설정은 학습 시간과 수렴 특성에 영향을 주므로 변경 전후의 step time과 검증 손실을 함께 기록해야 합니다.

추론 단계에서 병목 분리하기

추론에서는 TTFT(Time to First Token)와 토큰 생성 속도, 전체 요청 지연시간을 분리해서 봐야 합니다. 입력 프롬프트를 처리하는 프리필 단계는 연산량이 크고, 출력 토큰을 생성하는 디코드 단계는 반복적인 메모리 접근과 배치 상태 관리가 중요합니다. 두 단계의 특성이 달라 하나의 평균 지표만으로는 원인을 찾기 어렵습니다.

요청이 몰릴 때 지연시간이 급증한다면 GPU 자체보다 큐 대기, 토크나이징, 네트워크, KV 캐시 부족이 원인일 수 있습니다. Prometheus와 NVIDIA DCGM Exporter 같은 도구로 GPU 지표를 수집하고, 애플리케이션 로그의 요청 ID와 연결하면 특정 모델이나 엔드포인트에서 병목이 반복되는지 확인할 수 있습니다.

---

3. 쿠버네티스와 MIG 기반 자원 배분

쿠버네티스 스케줄링 설계

쿠버네티스에서 GPU를 사용할 때는 NVIDIA GPU Operator와 디바이스 플러그인을 기반으로 노드와 GPU 상태를 관리하는 구성이 일반적입니다. 파드에는 필요한 GPU 개수를 리소스 요청으로 지정하고, 노드 라벨과 taint를 이용해 학습용·추론용 노드를 분리할 수 있습니다.

단순히 GPU 개수만 요청하면 실제 메모리 요구량이나 지연시간 정책이 반영되지 않을 수 있습니다. 워크로드별로 우선순위 클래스, 리소스 쿼터, 최대 실행 시간, 재시작 정책을 정하고, 학습 작업이 온라인 추론을 밀어내지 않도록 격리해야 합니다. 여러 팀이 클러스터를 공유한다면 네임스페이스별 사용량과 예약량을 정기적으로 비교하는 운영 규칙도 필요합니다.

MIG와 시간 분할의 선택

MIG는 지원되는 NVIDIA GPU를 여러 개의 독립적인 인스턴스로 나누어 메모리와 연산 자원을 격리하는 방식입니다. 작은 모델이나 개발·테스트 작업을 한 GPU에 배치할 때 유용하며, 한 작업이 다른 작업의 메모리를 침범하는 위험을 줄일 수 있습니다.

다만 모든 워크로드에 MIG가 적합한 것은 아닙니다. 큰 모델이나 높은 메모리 대역폭이 필요한 작업은 분할하지 않은 GPU가 더 적합할 수 있습니다. 시간 분할 방식은 유연하지만 작업 간 간섭과 예측하기 어려운 지연이 생길 수 있습니다. 따라서 실시간 서비스는 격리를 우선하고, 중단 가능한 배치 작업은 공유 정책을 적용하는 식으로 구분해야 합니다.

---

4. 양자화·배칭으로 처리량 높이기

양자화의 효과와 주의점

양자화는 모델의 가중치나 연산 정밀도를 낮춰 메모리 사용량과 메모리 대역폭 부담을 줄이는 기법입니다. FP16 또는 BF16에서 INT8, INT4 계열로 낮추면 더 작은 GPU에서 모델을 실행하거나 동일한 GPU에 더 많은 요청을 수용할 여지가 생깁니다.

그러나 정밀도가 낮아지면 모든 모델과 작업에서 동일한 품질이 보장되는 것은 아닙니다. 도메인별 정확도, 긴 컨텍스트 성능, 함수 호출 성공률, 안전성 평가를 원본 모델과 비교해야 합니다. 양자화 적용 전후에 대표 프롬프트 세트와 실제 트래픽 샘플을 사용해 품질·지연시간·메모리를 함께 검증하는 절차가 필요합니다.

연속 배칭과 KV 캐시 관리

LLM 추론에서는 요청이 들어올 때마다 고정 배치를 만드는 대신, 실행 중인 요청에 새 요청을 합류시키는 연속 배칭을 활용할 수 있습니다. 이를 지원하는 추론 서버는 GPU가 유휴 상태로 기다리는 시간을 줄이고 다양한 길이의 요청을 효율적으로 처리합니다. 다만 배치가 커지면 개별 요청의 지연시간이 늘 수 있어 서비스 목표에 맞는 상한을 설정해야 합니다.

KV 캐시는 생성 과정에서 이전 어텐션 정보를 저장하는 영역입니다. 긴 프롬프트와 많은 동시 요청이 겹치면 가중치보다 KV 캐시가 먼저 메모리를 압박할 수 있습니다. 최대 입력 길이, 최대 출력 토큰, 동시 요청 수를 제한하고 캐시 사용량을 관찰해야 합니다. 프롬프트 중복이 많은 서비스라면 프리픽스 캐싱도 검토할 수 있지만, 캐시 무효화와 개인정보 처리 조건을 먼저 확인해야 합니다.

---

5. 2026년 GPU 비용과 성능 모니터링 전략

비용·성능 대시보드 구성

2026년에도 GPU 인프라 운영의 핵심은 특정 제품의 성능 수치보다 실제 업무 단위의 비용과 처리량을 연결하는 데 있습니다. 대시보드에는 GPU 사용률, 메모리 사용률, 전력, 오류, 파드별 점유 시간뿐 아니라 초당 처리 토큰, 요청당 비용, p50·p95 지연시간, 큐 대기시간을 함께 표시하는 것이 좋습니다.

학습은 실험별 GPU 시간과 완료한 스텝, 추론은 백만 토큰당 비용이나 요청당 비용으로 비교하면 팀 간 의사결정이 쉬워집니다. 클라우드 청구 데이터와 쿠버네티스 라벨을 연결할 때는 팀, 모델, 환경, 프로젝트 태그를 일관되게 사용해야 합니다. 태그가 누락되면 비용 최적화보다 비용 추정에 더 많은 시간이 들 수 있습니다.

자동 확장과 장애 대응

추론 서비스의 자동 확장은 GPU 사용률 하나보다 대기 요청 수, 토큰 처리량, p95 지연시간을 기준으로 설계하는 편이 실용적입니다. GPU 사용률이 높아도 요청이 적을 수 있고, 반대로 GPU 사용률이 낮아도 큐가 길어질 수 있기 때문입니다. 스케일아웃에는 모델 로딩 시간과 웜업 시간을 포함해야 갑작스러운 트래픽에 대응할 수 있습니다.

스팟 인스턴스를 사용한다면 체크포인트 저장, 작업 재개, 중단 알림 처리가 필수입니다. 온프레미스에서는 ECC 오류, 온도, 전력 제한, 노드 장애를 감시하고 문제가 있는 GPU를 자동으로 격리하는 절차를 마련해야 합니다. 최적화는 평균 성능을 높이는 일뿐 아니라 장애가 발생해도 서비스가 예측 가능하게 회복되는 구조를 만드는 일입니다.

---

6. GPU 자원 최적화 실행 체크리스트

1단계: 기준선 만들기

모델별로 입력 길이, 출력 길이, 동시 사용자 수, 목표 지연시간을 고정한 기준 테스트를 만드세요. GPU 사용률만 기록하지 말고 처리 토큰 수, 메모리 사용량, p95 지연시간, 오류율을 함께 저장해야 변경 효과를 비교할 수 있습니다.

2단계: 병목에 맞춰 한 가지씩 변경하기

양자화, 배칭, GPU 교체, 캐시 설정을 한꺼번에 바꾸면 원인을 추적하기 어렵습니다. 기준선에서 가장 큰 병목 하나를 선택해 변경하고, 비용·성능·품질을 다시 측정하세요. 모델 품질 저하가 없는지 확인하지 않은 채 처리량만 높이는 것은 운영상 위험합니다.

---

7. 자주 묻는 질문 (FAQ)

Q1. GPU 사용률이 낮으면 GPU가 남는다는 뜻인가요?

반드시 그렇지는 않습니다. 메모리 사용량은 높은데 연산이 적거나, 데이터 로딩과 네트워크 대기로 GPU가 쉬는 상황이 있을 수 있습니다. 사용률, 메모리, 대기시간, 처리량을 함께 확인하고 CPU·스토리지 지표까지 연결해야 실제 유휴 원인을 판단할 수 있습니다.

Q2. MIG를 사용하면 항상 비용을 줄일 수 있나요?

MIG는 작은 작업을 한 GPU에 안전하게 나누는 데 유용하지만, 큰 모델이나 GPU 간 통신이 필요한 학습에는 오히려 제약이 될 수 있습니다. 워크로드의 메모리 요구량과 지연시간을 측정한 뒤, 분할 전후 처리량과 운영 복잡도를 비교해 선택해야 합니다.

Q3. 양자화하면 모델 정확도가 크게 떨어지나요?

정확도 변화는 모델 구조, 데이터, 양자화 방식과 비트 수에 따라 달라 일괄적으로 말하기 어렵습니다. 배포 전에 실제 사용 사례를 반영한 평가 세트를 만들고, 정확도뿐 아니라 긴 문맥, 도구 호출, 안전성 같은 핵심 기능을 원본 모델과 비교해야 합니다.

Q4. 취업 준비생은 GPU 최적화를 어떻게 연습하면 좋을까요?

작은 오픈소스 모델을 대상으로 기준선 측정부터 시작해 보세요. 배칭 전후의 처리량, 양자화 전후의 메모리와 품질, 쿠버네티스에서의 GPU 스케줄링을 기록하면 좋습니다. 결과를 대시보드와 간단한 비용 계산표로 정리하면 단순 사용법보다 문제 해결 역량을 보여주기 쉽습니다.

---

8. 마무리

GPU 자원 최적화는 더 비싼 GPU를 구매하는 일이 아니라, 업무 특성에 맞게 측정하고 배분하며 반복해서 개선하는 운영 과정입니다. 먼저 유휴 시간과 병목을 수치로 확인하고, 쿠버네티스·MIG·양자화·배칭을 목적에 맞게 적용해 보세요. 마지막으로 처리량뿐 아니라 품질, 지연시간, 장애 복구와 비용을 함께 검증하면 한정된 자원으로도 오래 운영할 수 있는 LLM 인프라를 설계할 수 있습니다.

태그: #GPU자원최적화 #LLM인프라 #쿠버네티스 #GPU스케줄링 #클라우드비용절감