LLM은 GPU 위에서 어떻게 동작할까 | How LLMs Run on GPUs (1)

---

KEYWORDS
GPU란, GPU 메모리, LLM 추론 메모리, KV Cache 뜻, LLM VRAM 계산, GPU 아키텍처, SIMT, 양자화, 파인튜닝 메모리, LLM GPU 입문

---

Introduction

• LLM을 GPU에 올리고 추론을 돌리려는 순간, 많은 사람들은 Out of Memory(OOM) 에러에 부딪힙니다.
• 분명 GPU 메모리(VRAM)가 모델보다 큰데도 OOM이 납니다. 배치 크기를 1로 줄이고, 컨텍스트 길이를 반으로 잘라도, 추론 처리량은 바닥을 칩니다.
• 본 글은 GPU의 작동 원리와 GPU 메모리 계층, LLM이 GPU 메모리를 사용하는 방식, 추론과 파인튜닝 메모리 계산법을 다루겠습니다.

(2)편 ㅣ Multi-GPU의 세계: 분산 학습 병렬화 (Data·Tensor·Pipeline·Sequence Parallel)

GPU란? ^{Graphics Processing Unit}

• GPU(Graphics Processing Unit) 는 이름 그대로 원래 그래픽 처리를 위해 만들어진 프로세서입니다.
  • 화면의 수많은 픽셀을 동시에 계산해야 하니, 처음부터 많은 것을 한꺼번에 처리 하도록 설계되었습니다.
  • 이 병렬 처리(Parallel Processing)의 강점이 우연히도 신경망 학습·추론에 잘 맞아 떨어지면서, GPU는 오늘날 AI의 핵심 하드웨어가 되었습니다.
• 그래서 GPU를 이해하려면 먼저 CPU와 무엇이 다른가부터 시작해야 합니다.

CPU vs GPU

빠른 소수 vs 느린 다수

• 같은 컴퓨터 안에서 둘은 완전히 다른 철학으로 만들어졌습니다.

	CPU	GPU
코어 개수	적음 (보통 8~64개)	많음 (보통 수천~수만 개)
코어 하나의 성능	빠름, 복잡한 분기 처리 강함	단순, 분기 처리 약함
최적화 목표	지연 시간(Latency): 한 Thread를 빨리 끝냄	처리량(Throughput): 많은 Thread를 동시에
캐시/제어 회로	크고 복잡	작고 단순

• 직관적으로 비유하자면,
  • CPU: 4차선 고속도로 방식이며, 차선은 적지만 한 차가 매우 빠르게 달립니다.
  • GPU: 64차선 일반도로 방식이며, 차선이 매우 많고 차들이 동시에 줄지어 달립니다.
• LLM은 거대한 행렬 곱(Matrix Multiplication) 의 연속입니다. 수억 개의 곱셈·덧셈을 독립적으로 동시에 처리할 수 있다면 더 빠릅니다.
• 그래서 LLM에는 GPU가 유리합니다 ¹.

GPU 안에는 뭐가 있나

• GPU를 한 번도 뜯어본 적이 없다면, “수천 개의 코어”가 어떻게 한 칩 안에 들어가 있는지 잘 와닿지 않습니다.
• GPU 내부 구조를 이해해야 다음 절의 메모리 계층이 자연스럽게 이해됩니다. 그러니 먼저 GPU의 “장기”부터 살펴봅니다.

SM과 SP: GPU의 작업 단위

• GPU 내부는 크게 두 단계의 작업 단위로 구성됩니다.

• SM(Streaming Multiprocessor) ㅣ GPU 안에 여러 개 들어있는 독립적인 처리 유닛
  • SM 하나는 “작은 GPU 한 대”라고 봐도 됩니다.
  • SM 끼리는 거의 독립적으로 작업을 처리합니다.
  • ex. NVIDIA A100은 약 100여 개의 SM을 가지고 있습니다.
• SP(Streaming Processor) ㅣ SM 하나 안에 들어있는 실제 연산을 수행하는 작은 코어
  • SP가 실제로 Thread(연산 한 줄)를 실행하는 단위입니다.
• GPU의 수천 개 코어라는 표현은 사실 SP의 총합을 뜻하는 경우가 많습니다.

GPU 내부 구조 ¹

Thread, Block, Warp: 실행 단위의 계층

• 앞 절에서 본 SM·SP는 하드웨어 단위였습니다. 그 위에서 실제로 작업이 어떻게 묶여 실행되는지가 소프트웨어 실행 단위입니다.

• GPU 프로그래밍을 한 줄도 해보지 않았더라도, 이 세 개념만 이해하면 GPU 동작 그림이 거의 완성됩니다.

• Thread ㅣ GPU의 가장 작은 실행 단위
  • 각 Thread는 자기 몫의 데이터를 독립적으로 계산합니다.
  • ex. 길이 1000인 두 벡터를 더할 때, Thread 0은 0번째 원소, Thread 1은 1번째 원소, …
• Thread Block ㅣ 협업하는 Thread들의 묶음
  • 같은 Block 안의 Thread들은 SM의 빠른 On-chip 메모리(Shared Memory) 를 공유해서 빠르게 데이터를 주고받을 수 있습니다.
  • 같은 Block 안에서는 동기화(Synchronization) 도 가능합니다.
• Warp ㅣ 실제 하드웨어가 동시에 실행하는 Thread의 묶음, 정확히 32개
  • Thread Block은 내부적으로 32개씩 묶인 Warp 단위로 쪼개져 실행됩니다.
  • “왜 하필 32?”는 NVIDIA GPU의 하드웨어 설계 결정입니다. 이 숫자는 지난 십수 년간 거의 바뀌지 않았습니다.

Thread → Block → Warp의 계층: 32개 Thread가 한 Warp를 구성

• 한 LLM의 행렬 곱은 이런 식으로 GPU 위에서 펼쳐집니다.
  1. 거대한 행렬 곱이 작은 단위 연산으로 쪼개져 수많은 Thread가 생성됩니다.
  2. Thread들이 Block으로 묶여 각 SM에 배치됩니다.
  3. Block은 SM 안에서 Warp(32 Threads) 단위로 동시에 실행됩니다.

SIMT 실행 모델 ^{Single Instruction, Multiple Threads}

• 32개의 Thread가 동시에 실행된다는 게 정확히 무슨 의미일까요? 여기서 GPU의 가장 중요한 실행 모델이 등장합니다.
• 이 개념을 이해하면 GPU의 장점과 약점이 모두 한 번에 보입니다.

SIMT의 핵심: 한 명령어, 32 Thread

• SIMT(Single Instruction, Multiple Threads) ㅣ 한 Warp에 속한 32개 Thread가 매 순간 동일한 명령어를 실행하는 모델
  • 스케줄러는 하나의 명령어를 가져와 Warp 전체에 방송(Broadcast) 합니다.
  • 32개의 Thread는 같은 명령어를, 각자의 데이터에 대해, 동시에 수행합니다.
• 예를 들어 a[i] = b[i] + c[i] 라는 한 줄의 코드는, 한 Warp에 속한 Thread 0~31이 한 번에 처리합니다.

Thread	b	c	a
0	5	3	8
1	2	4	6
2	7	1	8
3	3	5	8
…	…	…	…

• 명령어는 하나(+)이고, 데이터는 Thread마다 다릅니다. 그래서 이 모델을 “Single Instruction, Multiple Threads” 라고 부릅니다.

SIMT 실행 방식: 한 명령어가 Warp 내 32 Thread에 동시에 Broadcast

GPU 메모리 계층 ^{Memory Hierarchy}

• GPU의 실행 단위는 이해했으니, 이제 데이터가 어디에 저장되는가를 봅니다. 결국 LLM의 성능은 메모리가 결정합니다.
• SM에 가까울수록 빠르고 작고, 멀수록 크고 느립니다.

메모리 계층의 3단계

• 한 칩 안에서 GPU 메모리는 SM과의 거리에 따라 다음과 같이 나뉩니다.

• Global Memory(HBM / DRAM) ㅣ GPU 칩 옆에 붙어있는 큰 메모리
  • GPU “VRAM 용량”이라고 부르는 그것입니다.
  • 가장 크지만 가장 느립니다.
  • ex. A100: 80 GB, H200: 141 GB
• L2 Cache ㅣ GPU 칩 위(On-die)에 있는 중간 캐시
  • 모든 SM이 공유합니다.
  • ex. A100: 40 MB
• L1 Cache / Shared Memory ㅣ 각 SM 내부에 있는 가장 빠른 메모리
  • SM 안의 Thread들만 접근 가능합니다.
  • ex. A100: SM당 192 KB

GPU 메모리 계층: SM에 가까울수록 빠르고 작으며, 멀수록 크고 느림 (A100 기준 수치)

대역폭(Bandwidth)

• 메모리는 용량(GB) 만 중요한 게 아니라, 대역폭(GB/s 또는 TB/s) 도 중요합니다.
• 대역폭은 초당 얼마나 많은 데이터를 읽고 쓸 수 있는가를 뜻합니다.
• ex. NVIDIA H200의 HBM은 최대 4.8 TB/s 의 메모리 대역폭을 가집니다 ².

메모리가 LLM 성능의 병목

• 보통 GPU 성능이라고 하면 연산 능력(FLOP/s) 을 떠올립니다. 그런데 LLM 추론에서는 종종 메모리 대역폭이 진짜 병목이 됩니다.

• 연산 능력은 매년 빠르게 늘고 있지만, 메모리 대역폭은 그만큼 빠르게 늘지 못하기 때문입니다.

• 그 결과 이런 일이 빈번합니다:
  • GPU의 산술 연산기는 놀고 있는데, 데이터를 메모리에서 가져오는 속도가 이를 따라가지 못합니다.
  • 연산은 끝났는데 다음 데이터를 기다리고 있는 상태가 자주 발생합니다.
  • 결국 메모리 이동에 묶여서(Memory-bound) 성능이 결정됩니다.
• 그래서 LLM 엔지니어링의 큰 그림은 어떻게 하면 메모리를 덜 옮기고도 같은 연산을 할 것인가 가 됩니다.
• 양자화, KV Cache 관리, Tensor Parallelism, FlashAttention 등 거의 모든 최적화가 이 한 줄로 환원됩니다.

LLM이 GPU 메모리를 쓰는 3가지 방식

• 이제 LLM이 GPU의 VRAM을 실제로 어떻게 채우는지를 보겠습니다.

• (1) Model Weights ㅣ 모델 가중치
  • 학습이 끝난 모델의 파라미터 자체.
  • 추론 시작 전에 한 번 로딩되며, 추론 도중에는 크기가 변하지 않습니다.
• (2) KV Cache ㅣ Key/Value 캐시
  • 추론 도중 동적으로 자라는 메모리에 해당합니다.
  • 토큰을 하나 생성할 때마다 Attention 계산에 사용되는 Key, Value 벡터가 캐시에 쌓입니다.
  • 컨텍스트 길이, 배치 크기, 레이어 수에 비례해서 커집니다.
• (3) Activation + Framework Overhead
  • Prefill 단계에서 일시적으로 쓰이는 Activation 메모리
  • CUDA 커널·Workspace
  • PyTorch 등 프레임워크의 메모리 단편화·예약 공간
  • vLLM, TensorRT-LLM 같은 런타임의 오버헤드

LLM 추론 시 GPU 메모리의 3대 사용처: Weights / KV Cache / Overhead

• 사양표만 보면 (1) Model Weights만 신경 쓰기 쉽지만, 추론 시 진짜 병목은 (2) KV Cache 인 경우가 많습니다.

정밀도와 메모리 ^{Precision and Memory}

• Model Weights가 메모리를 얼마나 차지하는가를 계산하려면 먼저 하나의 파라미터가 몇 Byte인가를 알아야 합니다.
• 이를 결정하는 것이 정밀도(Precision) 또는 데이터 타입(Data Type) 입니다.

정밀도별 Byte 수

데이터 타입	Bits	Bytes/param	특징
FP32 (32-bit Floating Point)	32	4	가장 높은 정밀도, 학습용 표준
FP16 / BF16 (16-bit Floating Point)	16	2	Mixed-precision 학습·추론 표준
INT8 (8-bit Integer)	8	1	양자화 추론에 자주 사용
INT4 (4-bit Integer)	4	0.5	극단적 양자화, 메모리 절감 최대

• 직관적으로:
  • FP32 → FP16 으로 가면 메모리가 절반으로 줄고, 연산 속도도 향상됩니다.
  • FP16 → INT8 로 가면 다시 절반이 됩니다.
  • INT8 → INT4 로 가면 여기서 또 절반이 됩니다.
• 단, 비트 수를 줄이면 정밀도 손실이 생깁니다.
  • 챗봇·RAG 같은 응용에서는 손실이 작아 실용적으로 INT8/INT4가 자주 쓰이며, 정밀도 손실을 최소화하는 양자화 알고리즘(GPTQ, AWQ 등) 이 활발하게 연구되고 있습니다 ².

양자화는 메모리 절감의 가장 큰 레버

• 70B 모델을 예로 들면:
  • FP16: 140 GB (모델 가중치만)
  • INT4: 35 GB (모델 가중치만)
• 같은 모델이 4배 작은 메모리에 들어갑니다. Multi-GPU가 필요하던 모델을 Single GPU에 올릴 수도 있게 됩니다.

추론 메모리 계산법 ^{Inference Memory Formula}

• 이제 본격적인 계산입니다. 모델 가중치 메모리부터 시작해서, 추론 시 필요한 전체 메모리를 단계별로 구합니다.

1. Model Memory: 모델 가중치만 계산한 메모리

• 가장 기본 공식:

\[\text{Model Memory (bytes)} = (\text{Number of Parameters}) \times (\text{Memory per Parameter})\]

• 여기서 Memory per Parameter 는 앞 절의 정밀도별 Byte 수입니다
  • (FP32=4, FP16=2, INT8=1, INT4=0.5).
• Byte를 GB로 바꾸려면 \(1024 \times 1024 \times 1024\) 로 나누면 됩니다.

2. Inference Memory: 추론 시 전체 메모리

• 모델 가중치만 GPU에 올려도, 추론 도중 추가 오버헤드가 필요합니다.
  • Activation, CUDA Workspace, 프레임워크 단편화 등.
• 경험적으로 모델 메모리의 20% 정도를 더 잡습니다.

\[\text{Total Memory for Inference} \approx 1.2 \times \text{Model Memory}\]

• 위 식을 정밀도 변수로 일반화하면 다음과 같이 쓸 수 있습니다 ³:

\[M \approx \frac{P \times 4B}{32/Q} \times 1.2,\]

• where
  • \(M\) ㅣ GPU Memory (GB)
  • \(P\) ㅣ 모델 파라미터 수
  • \(4B\) ㅣ FP32 기준 1 파라미터당 Byte (4 Bytes)
  • \(Q\) ㅣ 양자화 Bit 수 (32 for FP32, 16 for FP16, 8 for INT8, 4 for INT4)
  • \(1.2\) ㅣ Buffer·Metadata 20% 오버헤드
• 유도 관점에서 보면, \(Q\) 비트로 양자화된 파라미터의 크기는 FP32(32비트) 대비 \(Q/32\) 배이므로, \(4B \div (32/Q) = 4B \times Q/32\) 는 결국 파라미터당 Byte 수와 동일합니다. 즉 위 식은 “FP32에서 시작해서 양자화 비율만큼 줄인 다음, 20%를 더한다”는 뜻입니다.

3. LLaMA 70B 예시

• LLaMA 70B 모델은 \(P = 70{,}000{,}000{,}000\) (700억 파라미터) 입니다 ⁴.
• 정밀도별 추론 메모리 (NVIDIA H100 80 GB 기준):

정밀도	추론 메모리	필요한 GPU 수 (80GB 기준)
FP32	\(\approx 1.2 \times \frac{P \times 4}{1024^3} \approx 312\text{ GB}\)	\(\approx 4\) GPUs
FP16	\(\approx 1.2 \times \frac{P \times 2}{1024^3} \approx 156\text{ GB}\)	\(\approx 2\) GPUs
INT8	\(\approx 1.2 \times \frac{P \times 1}{1024^3} \approx 78\text{ GB}\)	1 GPU
INT4	\(\approx 1.2 \times \frac{P \times 0.5}{1024^3} \approx 39\text{ GB}\)	1 GPU

• 한눈에 보면, 양자화가 GPU 수를 그대로 줄여줍니다.
• 하지만 이 표는 모델 가중치 + 20%만 계산한 값입니다. KV Cache는 빠져 있습니다. 다음 절에서 추가하겠습니다.

KV Cache 메커니즘

• 사양표 위에서는 LLaMA 70B INT8이 80 GB GPU 한 장에 Fit 되는 것처럼 보입니다. 그런데 실제로 추론을 돌리면 OOM이 발생합니다.
• 그 원인의 9할이 KV Cache 입니다.

Prefill vs Decode

• LLM 추론은 두 단계로 나눠집니다.

• Prefill ㅣ 사용자의 입력 Prompt 전체를 한 번에 처리하는 단계
  • 입력 토큰 모두에 대해 Attention 계산이 일어납니다.
  • 각 레이어에서 Key, Value 벡터를 계산해서 KV Cache에 저장합니다.
• Decode ㅣ 다음 토큰을 하나씩 자기회귀(Autoregressive) 적으로 생성하는 단계
  • 새 토큰 1개에 대해서만 새로운 K, V를 계산합니다.
  • 이전 토큰들의 K, V는 이미 캐시에 있으므로 재계산하지 않고 캐시에서 읽어와 활용합니다.
  • 새로 계산된 K, V는 캐시에 추가됩니다.
• 즉 토큰 하나가 생길 때마다 KV Cache는 계속 자라납니다.

KV Cache 크기 공식

• 공식을 세우기 전에, 이후 계속 등장할 Transformer의 기본 변수를 먼저 정리합니다.
  • \(\text{batch_size}\) ㅣ 동시에 처리하는 요청(시퀀스) 수
  • \(\text{seq_len}\) ㅣ 현재까지의 누적 토큰 수
  • \(\text{num_layers}\) ㅣ Transformer 레이어(=block)의 수
  • \(\text{hidden_dim}\) ㅣ 각 토큰의 임베딩 벡터 차원
  • \(\text{bytes_per_parameter}\) ㅣ 파라미터 하나의 정밀도별 Byte 수 (FP16=2, FP32=4 등)
• 이제 KV Cache의 크기를 유도합니다. 한 토큰 · 한 레이어에서 저장되는 값은 다음과 같습니다.
  • Key 벡터 하나: \(\text{hidden_dim}\) 개의 실수
  • Value 벡터 하나: \(\text{hidden_dim}\) 개의 실수
  • 합쳐서 \(2 \times \text{hidden_dim} \times \text{bytes_per_parameter}\) Bytes
• 여기에 모든 토큰(× seq_len)과 모든 레이어(× num_layers), 모든 요청(× batch_size)을 곱하면 ²:

\[\text{KV Cache Size (Bytes)} = 2 \times \text{batch_size} \times \text{seq_len} \times \text{num_layers} \times \text{hidden_dim} \times \text{bytes_per_parameter}\]

• 위 공식은 Multi-Head Attention (MHA) 기준입니다.
  • 최근 오픈 LLM은 대부분 GQA(Grouped Query Attention) 나 MQA(Multi-Query Attention) 를 채택해 Key/Value 헤드 수를 줄이므로, 실제 KV Cache는 이 공식보다 훨씬 작습니다
  • (ex. LLaMA 3 70B는 KV 헤드 8개로 이 공식의 약 1/8).

KV Cache의 메모리 증가 메커니즘

• 위 식에서 \(\text{seq_len}\) 이 선형적으로 곱해진다는 점이 핵심입니다.

• 컨텍스트가 4k → 8k → 32k 로 늘어나면, KV Cache도 그에 정비례해서 4배 → 8배로 커집니다.
• 멀티턴 대화에서는 매 턴마다 이전 대화 전체가 컨텍스트에 포함되므로, 유효 컨텍스트 길이가 계속 자라며 KV Cache가 VRAM의 주된 소비자가 됩니다.

KV Cache는 시퀀스 길이에 선형적으로 자람: 멀티턴·Long-context에서 폭증

• 정리하면 KV Cache가 메모리를 잡아먹는 흔한 시나리오는 다음과 같습니다:
  • 긴 컨텍스트 윈도우(4k, 8k, 32k …) ㅣ KV Cache가 선형적으로 자람
  • 높은 동시성(Concurrency) ㅣ Batch_size가 늘면 KV Cache도 그만큼 곱해짐
  • 멀티턴 대화 ㅣ 유효 컨텍스트가 계속 커짐
• 그래서 Weights는 60 GB짜리 LLM이지만 80 GB GPU 한 장에 안정적으로 못 돌아간다는 결론에 도달합니다 ².

Fine-tuning 메모리

• 추론 메모리가 모델 가중치 + 약 20% 였다면, 파인튜닝(Fine-tuning) 메모리는 그보다 훨씬 큽니다.
• 학습은 Backpropagation 을 위한 추가 메모리가 필요하기 때문입니다.

학습에 필요한 4가지 메모리

파인튜닝 시 GPU 메모리에 함께 올라가야 하는 것은 다음 네 가지입니다 ⁴⁵.

• (1) Model Weights ㅣ 추론과 동일, \(P \times \text{size per param}\)
• (2) Gradients ㅣ 모델 가중치와 같은 크기, Backward에서 각 파라미터에 대한 기울기를 저장
• (3) Optimizer States ㅣ 모델 가중치의 약 2배
  • Adam 같은 최적화기는 Momentum, Variance 등 추가 상태를 보관
• (4) Activations ㅣ 보통 모델 크기의 약 0.25배
  • Forward에서 계산된 중간 Activation을 Backward에서 다시 사용해야 함

파인튜닝 메모리 구성: Weights + Gradients + Optimizer States + Activations (합계 ≈ 4.25× Model)

공식과 LLaMA 70B 예시

• 위 네 가지를 합치면:

\[\text{Total Memory} = (1 + 1 + 2 + 0.25) \times P \times \text{size per param}\] \[\text{Total Memory} \approx 4.25 \times P \times \text{size per param}\]

• 즉 파인튜닝은 추론보다 약 3.5배 많은 메모리를 요구합니다.

• LLaMA 70B 파인튜닝 시 정밀도별 메모리와 필요한 GPU 수 (NVIDIA H100 80 GB 기준):

정밀도	파인튜닝 메모리	필요한 GPU 수
FP32	\(\approx 1108\text{ GB}\)	\(\approx 14\) GPUs
FP16	\(\approx 554\text{ GB}\)	\(\approx 7\) GPUs
INT8	\(\approx 277\text{ GB}\)	\(\approx 4\) GPUs
INT4	\(\approx 139\text{ GB}\)	\(\approx 2\) GPUs

• 추론용 FP16이 2장이면 됐는데, 파인튜닝용 FP16은 7장이 필요합니다.

• 그래서 Single GPU로 70B 모델을 파인튜닝하는 것은 사실상 불가능합니다. (2)편에서 다룰 Multi-GPU 병렬화가 필수입니다.

• 위 4.25× 공식은 모든 구성요소가 같은 정밀도라는 단순한 가정에 근거합니다.
  • 실제 Mixed Precision 학습에서는 Optimizer State와 Master Weight를 FP32로 유지하므로 메모리가 더 큽니다.
  • 이 자세한 계산은 (2)편 Naive DDP 절에서 다시 다룹니다.

함정 정리

• 마지막으로, 실무에서 자주 만나는 함정 몇 가지를 짚습니다.

• 함정 1 ㅣ 사양표로는 Fit인데 실제로는 OOM
  • 사양표는 보통 모델 가중치 메모리만 보여줍니다.
  • KV Cache, Framework Overhead, CUDA Context를 빼고 봤기 때문에 실제와 차이가 큽니다.
  • 반드시 KV Cache까지 더해서 추산해야 합니다.
• 함정 2 ㅣ Long Context를 켜면 갑자기 VRAM이 폭발
  • KV Cache는 seq_len에 선형으로 자랍니다.
  • 4k 컨텍스트에서 잘 돌아가던 추론이, 32k 컨텍스트에서는 8배의 KV Cache를 필요로 함.
  • Long-context 워크로드는 항상 KV Cache 추산을 먼저 해야 합니다.
• 함정 3 ㅣ 동시 요청을 늘리면 처리량이 늘 줄 알았는데, 오히려 떨어짐
  • Batch_size가 커지면 KV Cache가 그만큼 곱해집니다.
  • VRAM이 모자라면 KV Cache가 일찍 Evict되고, 같은 토큰을 다시 계산하게 됩니다.
  • 결과: 지연 시간 증가, 처리량 감소.
• 함정 4 ㅣ 양자화로 모델만 줄였는데 메모리가 별로 안 줄어듦
  • 양자화는 (1) Model Weights만 줄입니다. KV Cache와 Overhead는 그대로.
  • Long Context 워크로드에서는 KV Cache가 지배적이므로, 양자화 효과가 제한적입니다.
  • 이런 경우엔 KV Cache 자체에 대한 최적화(KV Cache 양자화, Paged Attention 등)가 별도로 필요합니다.

Conclusion

• GPU는 Throughput을 위한 하드웨어입니다.
  • 수많은 SM·SP·Thread·Warp가 SIMT 모델로 거대한 행렬 곱을 병렬 처리합니다.
• 메모리 계층은 SM에 가까울수록 빠르고 작습니다. L1·Shared → L2 → HBM 순서.
  • LLM의 진짜 병목은 메모리 대역폭입니다.
• LLM은 GPU 메모리를 세 가지 방식으로 씁니다:
  • Model Weights, KV Cache, Activation + Framework Overhead.
• 추론 메모리 \(\approx 1.2 \times P \times \text{bytes/param}\).
  • 파인튜닝 메모리 \(\approx 4.25 \times P \times \text{bytes/param}\).
• KV Cache는 seq_len에 선형으로 자랍니다.
  • 사양표로는 Fit해 보이는 모델이 OOM 나는 진짜 이유.
• LLM은 GPU의 메모리를 두 단계로 먹습니다.
  • 처음 한 번(모델), 그리고 토큰마다(KV Cache).

---

References

1. Namhyuk Ahn, *Understanding GPUs* (ECE7115 Multimodal VLM LLM, Lecture 8), Generative Computing Lab, Inha University, Spring 2026. ↩︎ ↩︎²

2. BentoML, What is GPU Memory and Why it Matters for LLM Inference. ↩︎ ↩︎² ↩︎³ ↩︎⁴

3. Praneeth Dhananjaya, LinkedIn Post on GPU Memory for LLM Inference and Training. ↩︎

4. Pramod Singh, How to Calculate GPU and vRAM for Inferencing & Fine-tuning LLM, Data Science Champion Blog, 2024-08-23. ↩︎ ↩︎²

5. Yanjie Gao et al., “Estimating GPU Memory Consumption of Deep Learning Models,” Proceedings of the 28th ACM Joint European Software Engineering Conference and Symposium on the Foundations of Software Engineering (ESEC/FSE ‘20), 2020. DOI ↩︎