GPU의 신비 해제: AI 시대에 모든 개발자가 알아야 할 것

어디에서나 이런 말을 들어보셨을 겁니다 — "GPU가 더 필요합니다", "GPU 클러스터가 포화 상태입니다", "모델을 위해 GPU 인스턴스를 생성하세요". 몇 년 전만 해도 GPU는 게이밍 하드웨어였습니다. 오늘날 GPU는 지구상에서 가장 전략적으로 희소한 인프라 구성 요소입니다. 하지만 대부분의 엔지니어에게 그 이유를 설명해 보라고 하면, 답변은 금세 모호해지곤 합니다.

이 포스트는 그저 고개를 끄덕이는 것에 지친 개발자, SRE(Site Reliability Engineer), 또는 플랫폼 엔지니어를 위한 것입니다. 우리는 박사 학위 없이도 이해할 수 있는 실제적인 멘탈 모델 (Mental Model)을 구축해 볼 것입니다.

CPU가 하는 일 (그리고 왜 AI에는 충분하지 않은가)

GPU를 이해하기 전에, CPU에 대한 명확한 그림이 필요합니다.

여러분의 CPU는 **범용 문제 해결사 (General-purpose problem solver)**입니다. CPU는 소수의 강력한 코어(Core)를 가지고 있으며 — 현대적인 서버의 경우 보통 8개에서 64개 사이 — 각 코어는 엄청난 유연성을 가지고 복잡하고 분기(Branchy)가 많은 로직을 실행할 수 있습니다. 웹 서버를 실행하고, HTTP 요청을 처리하며, 데이터베이스를 쿼리하고, 템플릿을 렌더링하는 작업을 동시에 수행해야 하나요? CPU는 이를 쉽게 처리합니다. CPU는 순차적이고, 다양하며, 서로 의존적인 작업들을 위해 구축되었습니다.

CPU를 10명의 세계적인 셰프 팀이라고 생각해보세요. 각 셰프는 어떤 요리든, 어떤 종류의 요리든 만들 수 있습니다. 그들은 즉흥적으로 대처하고, 레시피 중간에 결정을 내리며, 순식간에 작업을 전환할 수 있습니다. 그들은 비싸고, 엘리트이며, 매우 다재다능합니다.

이제 작업이 복잡한 테이스팅 메뉴를 요리하는 것이 아니라, 1,000만 조각의 빵에 버터를 바르는 것이라고 상상해 보세요.

여러분의 10명의 세계적인 셰프들은 이 작업에 매우 서툽니다. 그들이 능력이 없어서가 아니라, 이 작업이 당황스러울 정도로 반복적이고 병렬적이기 때문입니다. 여러분에게 필요한 것은 기술이 아닙니다. 여러분에게 필요한 것은 **규모 (Scale)**입니다.

GPU의 실체

GPU는 **대규모 병렬 프로세서 (Massively parallel processor)**입니다. CPU가 수십 개의 코어를 가진 반면, 현대의 GPU는 수천 개의 더 작고 단순한 코어를 가지고 있습니다 — NVIDIA H100은 16,896개의 CUDA 코어를 보유하고 있습니다. 각 코어는 CPU 코어보다 덜 강력하지만, 이들이 모이면 수천 개의 연산을 동시에 실행할 수 있습니다.

빵에 버터를 바르는 비유가 그대로 적용됩니다: GPU는 버터 칼을 든 10,000명의 작업자이며, 모두가 동시에 같은 일을 하고 있는 것과 같습니다.

이러한 아키텍처는 그래픽을 위해 발명되었습니다. 왜냐하면 픽셀을 렌더링(rendering)하는 것이 바로 이런 종류의 문제이기 때문입니다. 즉, 수백만 개의 픽셀 색상을 병렬(parallel)로 계산해야 하며, 각 픽셀에 동일한 수학적 연산이 적용됩니다.

알고 보니, AI 모델을 학습(training)시키고 실행(running)하는 것 또한 정확히 이런 종류의 문제였습니다.

AI가 GPU를 사랑하는 이유

현대 AI — 구체적으로 딥러닝 (deep learning) — 은 엄청난 규모로 반복 수행되는 단일 수학 연산, 즉 **행렬 곱셈 (matrix multiplication)**을 기반으로 구축됩니다.

신경망 (neural network)이 입력값(문장, 이미지, 오디오 클립 등)을 처리할 때, 해당 입력값을 수백 개의 레이어 (layers)를 통해 통과시킵니다. 각 레이어는 행렬 곱셈입니다. 즉, 큰 숫자 격자(입력값)를 또 다른 큰 숫자 격자(학습된 가중치, weights)와 곱하는 것입니다. 이 출력값은 다음 레이어의 입력값이 됩니다.

이러한 곱셈의 특징은 다음과 같습니다:

• 서로 독립적임 (Independent of each other) — 하나의 결과가 다른 결과의 완료를 기다리지 않습니다.
• 구조적으로 수치상 동일함 (Numerically identical in structure) — 수백만 개의 값에 대해 동일한 연산이 반복됩니다.
• 규모가 엄청남 (Enormous in scale) — GPT-4를 통한 단 한 번의 순전파 (forward pass)에는 수조 번의 이러한 연산이 포함됩니다.

이것이 바로 GPU가 설계된 목적입니다. CPU에서 행렬 곱셈을 실행하는 것은 버터를 바르기 위해 메스 (scalpel)를 사용하는 것과 같습니다. 기술적으로는 맞지만, 엄청나게 비효율적입니다.

현대의 GPU에는 심지어 이를 위한 전용 실리콘이 포함되어 있습니다. 텐서 코어 (Tensor Cores) (NVIDIA)는 반정밀도 (half-precision, FP16/BF16)로 행렬 곱셈을 놀라운 속도로 수행하는 특화된 하드웨어 유닛이며, 오로지 AI 워크로드 (workloads)를 가속화하기 위해 존재합니다.

GPU의 해부학: 실제로 듣게 될 용어들

칩 아키텍처를 암기할 필요는 없습니다. 하지만 다음 다섯 가지 용어는 인프라 및 AI 관련 대화에서 끊임없이 등장할 것이므로 반드시 숙지해야 합니다.

1. VRAM (Video RAM)

이것은 GPU 자체의 메모리로, 서버의 일반적인 RAM과는 별개입니다. 모델 가중치 (model weights), 입력 데이터, 그리고 추론 (inference) 또는 학습 (training) 중 발생하는 중간 계산값들이 머무는 곳입니다.

이것은 실제 작업 시 가장 자주 발목을 잡는 리소스입니다.

70억 개(7-billion)의 파라미터를 가진 언어 모델을 로드하는 데만 약 14 GB의 VRAM이 필요합니다 (FP16 정밀도에서 파라미터당 2바이트 기준). 여기에 요청 배치(batch)를 위한 작업 메모리(working memory)를 더하면, 단 한 명의 사용자에게 서비스를 제공하기도 전에 이미 18~22 GB에 도달하게 됩니다.

VRAM이 가득 차면, 우아한 성능 저하(graceful degradation)란 없습니다. 대신 다음과 같은 상황을 맞이하게 됩니다:

RuntimeError: CUDA out of memory. Tried to allocate 2.00 GiB.

프로세스가 종료됩니다. RAM이 부족할 때 최소한 스왑(swap)이라도 시도하는 CPU와 달리, GPU에는 오버플로(overflow)가 없습니다. VRAM은 소프트 리밋(soft limit)이 아니라 하드 실링(hard ceiling, 엄격한 상한선)입니다.

2. SM 사용률 (Streaming Multiprocessors)

SM은 함께 그룹화된 CUDA 코어들의 클러스터입니다. SM 사용률은 CPU 사용률(CPU%)에 대응하는 GPU의 지표입니다. 이는 GPU의 연산 능력 중 몇 퍼센트가 활발하게 작업을 수행하고 있는지를 알려줍니다.

• 50% 미만: GPU가 저활용되고 있음 — 아마도 요청을 효율적으로 배치(batching)하지 못하고 있을 가능성이 높습니다.
• 75–85%: 건강한 운영 구간
• 95% 이상: 포화 상태 — 지연 시간(latency)이 급증하고 요청 대기열(request queue)이 쌓이게 됩니다.

CPU와의 핵심적인 차이점은 다음과 같습니다. CPU에서 100% 사용률은 "느리지만 작동은 한다"는 의미입니다. 하지만 SM 사용률이 100%인 GPU에서는 추론 지연 시간(inference latency)이 비선형적으로 급증할 수 있습니다. 작업이 처리되는 속도보다 대기열에 쌓이는 속도가 더 빨라지기 때문입니다.

3. 메모리 대역폭 (Memory Bandwidth)

이는 GPU
_내부_에서 데이터가 이동하는 속도를 의미하며, 초당 기가바이트(GB/s) 단위로 측정됩니다.

거의 모든 사람을 당혹스럽게 만드는 직관에 반하는 진실이 하나 있습니다: LLM 추론에서 병목 현상(bottleneck)은 대개 연산(compute)이 아니라 메모리 대역폭에서 발생합니다.

왜 그럴까요? 모델을 서비스할 때, GPU는 실제로 가중치를 곱하는 시간보다 VRAM에서 모델 가중치를 읽어오는 데 더 많은 시간을 소비하기 때문입니다. 70B 파라미터 모델은 매 포워드 패스(forward pass)마다 GPU 코어로 스트리밍해야 할 140 GB의 가중치를 가지고 있습니다. GPU 코어는 다음 데이터 덩어리가 도착하기도 전에 곱셈 연산을 끝내버립니다.

이러한 상태를 연산 제한(compute-bound)이 아닌 메모리 제한(memory-bound) 상태라고 부릅니다. 이 경우 CUDA 코어를 늘리는 것은 도움이 되지 않습니다. 더 빠른 메모리(HBM — 고대역폭 메모리)가 도움이 됩니다.

4. TDP 및 써멀 스로틀링 (Thermal Throttling)

TDP는 열 설계 전력 (Thermal Design Power)의 약자로, GPU가 처리하도록 설계된 최대 지속 전력 소모량을 와트(Watts) 단위로 나타낸 것입니다.

NVIDIA H100 SXM의 TDP는 700W입니다. 오타가 아닙니다. 8개의 H100이 장착된 랙 하나는 작은 아파트 한 채보다 더 많은 전력을 소모합니다.

GPU가 지속적으로 TDP 근처에서 작동하면, 과열을 방지하기 위해 스스로 클록 속도 (clock speed)를 낮추는 써멀 스로틀링 (thermal throttling) 현상이 발생하기 시작합니다. 외부에서 보기에는 오류 없이 처리량 (throughput)이 미스터리하게 저하되는 것처럼 보입니다. 인퍼런스 (inference) 서버가 명확한 원인 없이 점점 더 느린 결과를 반환하기 시작하는 것입니다.

실무에서는: GPU 온도와 전력 소모량을 최우선 지표 (first-class metrics)로 모니터링하십시오. 냉각 성능이 떨어지는 랙에서 TDP의 90%로 작동하는 GPU는 서서히 진행되는 사고와 같습니다.

5. PCIe 대역폭 (PCIe Bandwidth)

PCIe는 GPU를 CPU에 연결하는 버스 (bus)입니다. 애플리케이션이 GPU로 데이터를 보낼 때(입력 토큰, 배치 데이터)나 결과를 다시 읽어올 때(출력 토큰)마다 이 버스를 통과합니다.

대부분의 인퍼런스 (inference) 워크로드에서는 이 정도면 충분합니다. 하지만 그래디언트 (gradients)가 반복적으로 앞뒤로 흐르는 트레이닝 (training) 과정이나, 불필요한 CPU↔GPU 복사를 수행하는 잘못 설계된 인퍼런스 파이프라인의 경우, PCIe는 숨겨진 병목 현상 (bottleneck)이 됩니다.

징후: GPU 사용률 (utilisation)은 높지만 실제 처리량 (throughput)은 낮습니다. 데이터가 전송 중에 대기하고 있는 상태입니다.

GPU 파티셔닝 (GPU partitioning): 하나의 칩, 다양한 용도

현대의 데이터 센터용 GPU는 매우 고가이기 때문에 (H100 기준 약 $30,000–$40,000), 워크로드가 칩 전체를 필요로 하지 않는데도 하나의 GPU에서 단일 워크로드만 실행하는 것은 낭비입니다. 세 가지 파티셔닝 전략이 존재합니다:

전체 GPU (독점 할당)

GPU 전체를 하나의 워크로드에 전용으로 할당합니다. 최대 성능을 제공하며, 간섭이 없고, 구조를 이해하기 쉽습니다. 대규모 모델 트레이닝 (training)이나 대규모 모델의 고처리량 프로덕션 인퍼런스 (production inference)에 적합합니다.

# Kubernetes 리소스 요청: 전체 GPU
resources:
  requests:
...

MIG — 멀티 인스턴스 GPU (Multi-Instance GPU)

NVIDIA의 하드웨어 레벨 파티셔닝 (A100 및 H100에서 사용 가능)입니다. GPU가 물리적으로 격리된 슬라이스(slice)로 나뉘며, 각 슬라이스는 고유한 전용 VRAM과 연산 자원을 가집니다. 한 슬라이스는 메모리 압박(memory-pressure) 상황에서도 다른 슬라이스에 간섭할 수 없습니다.

A100 80GB는 다음과 같이 파티셔닝할 수 있습니다:

• 7 × 1g.10gb (7개의 테넌트, 각 10 GB)
• 3 × 2g.20gb (3개의 테넌트, 각 20 GB)
• 1 × 7g.80gb (하나의 테넌트가 칩 전체를 사용)

# Kubernetes 리소스 요청: MIG 슬라이스
resources:
  requests:
...

MIG는 여러 개의 작은 모델을 운영하거나 테넌트 간의 엄격한 격리 요구 사항이 있을 때 적합한 선택입니다.

타임 슬라이싱 (Time-Slicing, 공유 GPU)

여러 포드(pod)가 단일 GPU를 공유하며, CPU가 멀티스레딩(multithreading)을 처리하는 방식과 유사하게 빠른 타임 슬라이스(time slices) 단위로 교대로 사용합니다. 여기에는 메모리 격리(memory isolation)가 없습니다: 모든 포드가 동일한 VRAM 풀을 공유합니다. 한 포드의 메모리 누수(memory leak)가 다른 포드들의 OOM(Out of Memory)을 유발할 수 있습니다.

이 방식은 격리가 중요하지 않은 개발 워크로드, 실험, 또는 매우 가벼운 배치 작업(batch jobs)에만 사용하십시오.

주의 깊게 살펴봐야 할 지표 (Metrics)

SRE, 플랫폼 엔지니어, 또는 직접 모델을 실행하는 개발자 등 GPU를 포함한 인프라를 운영한다면, 다음 수치들을 주시해야 합니다. 이 지표들은 고전적인 **4대 골든 시그널 (Four Golden Signals)**과 직접적으로 매핑됩니다:

시그널 (Signal)	GPU 지표 (Metric)	의미
지연 시간 (Latency)	P95/P99 추론 시간, 첫 번째 토큰 생성 시간 (Time to First Token)	모델이 SLO 내에서 서빙되고 있는가?
...

이 모든 지표를 Prometheus 호환 형식으로 노출하는 도구는 DCGM Exporter (NVIDIA Data Center GPU Manager)입니다. Kubernetes를 사용 중이라면, 이는 DaemonSet으로 배포되어 모든 노드로부터 GPU 지표를 자동으로 스크래핑(scrape)합니다.

특별히 언급할 만한 몇 가지 지표는 다음과 같습니다:

# 핵심 4가지 — 여기서부터 시작하세요
DCGM_FI_DEV_GPU_UTIL          # SM 사용률 (0–100%)
DCGM_FI_DEV_FB_USED           # 사용된 VRAM (MiB)
...

사용된 VRAM이 전체의 85%를 초과하면 이를 심각도가 높은 경고(high-severity alert)로 취급하십시오. 이는 아직 무언가 고장 났기 때문이 아니라, 시스템이 완전히 충돌(hard crash)하기 전까지 남은 여유 공간이 매우 적다는 것을 의미합니다. 단 한 번의 큰 배치 요청(batch request)만으로도 한계를 넘어설 수 있습니다.

"GPU가 더 필요한가?"를 판단하기 위한 간단한 사고 모델

GPU 용량을 추가하기 전에, 다음 세 가지 질문을 순서대로 던져보십시오.

1. VRAM이 제약 사항인가?
피크 부하(peak load) 시 VRAM 사용량이 85% 이상이라면, GPU 노드를 더 추가하거나 양자화 (Quantisation, FP16에서 INT8 또는 INT4 정밀도로 전환하여 약간의 정확도 손실을 감수하며 VRAM 사용량을 절반 또는 4분의 1로 줄이는 기법)를 통해 모델의 메모리 점유율(memory footprint)을 줄여야 합니다.

2. SM 사용률(SM utilisation)이 제약 사항인가?
VRAM은 여유가 있지만 SM 사용률이 지속적으로 90%를 상회한다면, 연산 능력(compute)이 포화 상태인 것입니다. 지연 시간 예산(latency budget)이 허용한다면 배치 크기(batch size)를 키우십시오. 여러 요청을 함께 배치 처리하면 GPU의 병렬성(parallelism)을 더 효율적으로 사용할 수 있습니다. 만약 배치 크기가 이미 한계라면, 스케일 아웃(scale out)을 수행하십시오.

3. 모델이 실제로 GPU를 사용하고 있는가?
당연한 소리처럼 들리겠지만, 가장 당혹스러운 답변이기도 합니다. 워크로드가 실제로 GPU에서 실행되고 있는지, 아니면 소리 없이 CPU로 폴백(fallback)되고 있지는 않은지 확인하십시오. 간단한 무결성 검사(sanity check) 방법은 다음과 같습니다:

import torch

# CUDA 사용 가능 여부와 모델이 GPU에 있는지 확인
...

CPU에서 실행되는 모델은 10~100배 더 느리겠지만, 에러를 발생시키지는 않습니다. 그저 조용히 성능이 저하될 뿐이며, 이로 인해 실제로는 디바이스 매핑(device mapping)을 수정해야 함에도 불구하고 "GPU가 더 필요하다"고 착각하게 만들 수 있습니다.

흔한 실수 (및 방지 방법)

실수 1: SM%를 "GPU가 열심히 일하고 있음"과 동일시하는 것

GPU가 최적화되지 않은 커널(kernel)을 실행하거나, 과도한 CPU↔GPU 메모리 복사를 수행하거나, 커널 실행 오버헤드(kernel-launching overhead)가 발생하는 경우, 실제 유용한 작업은 거의 하지 않으면서도 SM 사용률이 90%로 나타날 수 있습니다. 사용률이 "생산적(productive)"인지 확인하기 위해 항상 SM 사용률을 처리량(throughput) 지표(초당 토큰 수, 초당 요청 수)와 함께 확인하십시오.

실수 2: 테스트 시점에 VRAM을 무시하는 것

대부분의 개발자는 배치 크기(batch size)를 1로 설정하여 모델을 테스트하는데, 이는 프로덕션(production) 환경에서 필요한 VRAM의 극히 일부만 사용합니다. 프로덕션 배치 크기가 VRAM에 들어가지 않는다는 사실을 깨달았을 때는 이미 장애(incident)가 발생한 후일 것입니다. 프로덕션 SLO(Service Level Objectives)를 설정하기 전에, 현실적인 배치 크기에서 VRAM을 프로파일링(profile)하십시오.

실수 3: Kubernetes에서 GPU 노드를 CPU 노드처럼 취급하는 것

GPU 노드에 테인트(taint)를 설정하지 않으면, 일반적인 CPU 워크로드(workload)가 실수로 GPU 노드에 할당되어 값비싼 하드웨어를 낭비하게 됩니다. 항상 다음과 같이 테인트를 설정하십시오:

kubectl taint nodes <gpu-node-name> nvidia.com/gpu=present:NoSchedule

그리고 모든 GPU 워크로드에 그에 상응하는 톨러레이션(toleration)을 추가하십시오:

tolerations:
  - key: nvidia.com/gpu
    operator: Exists
...

실수 4: GPU 워크로드에 대해 CPU 지표를 기준으로 스케일링하는 것

GPU 추론(inference) 서비스에 대해 CPU 사용률(CPU utilisation)을 기준으로 스케일링하는 수평 포드 오토스케일러(Horizontal Pod Autoscaler)를 설정하는 것은 잘못된 방법입니다. GPU가 포화 상태인 동안에도 CPU는 대부분 유휴(idle) 상태일 수 있기 때문입니다. 대신 추론 요청 큐 깊이(inference request queue depth)나 P95 지연 시간(latency)을 기준으로 스케일링하십시오.