파인튜닝의 현실적인 문제: 메모리 병목(Memory Bottlenecks)
파인튜닝이 강력한 기능을 제공함에도 불구하고, 가장 큰 현실적 제약은 바로 GPU 메모리 사용량입니다. 파인튜닝 중에는 모델이 예측을 수행하는 것뿐만 아니라, 오차를 계산하고 가중치를 수정하는 과정(backpropagation)까지 포함되기 때문에, 추론보다 훨씬 많은 메모리를 소모하게 됩니다.
요약: 메모리 병목을 이해하기 위한 핵심 포인트
Key Takeaways for Understanding Memory Bottlenecks
- 파인튜닝은 추론보다 훨씬 높은 메모리를 요구합니다.
모델이 결과를 출력하는 것만 필요한 추론(inference)과는 달리, 파인튜닝은 전체 파라미터를 업데이트하기 위해 두 배 이상의 메모리가 필요합니다. - 메모리 사용량을 결정짓는 핵심 요소는 다음 세 가지입니다.
- 모델의 파라미터 수
- 학습 가능한 파라미터 수 (trainable parameters)
- 파라미터 표현 방식 (예: float32, int8 등)
- 학습 가능한 파라미터 수를 줄이는 것이 핵심 전략입니다.
PEFT(예: LoRA, QLoRA)는 전체 모델이 아닌 일부 파라미터만 업데이트함으로써 메모리 요구량을 획기적으로 줄입니다. - 양자화(Quantization)를 통해 메모리 최적화가 가능합니다.
예를 들어 FP32(32비트)를 사용하는 모델을 8비트로 줄이면, 전체 모델의 메모리 요구량을 4분의 1까지 감소시킬 수 있습니다. - 추론은 8비트 또는 4비트까지도 가능하지만, 학습은 일반적으로 더 높은 정밀도(16~32비트)가 필요합니다.
메모리는 어떻게 쓰이는가? – 역전파(Backpropagation)의 이해
파인튜닝 시 메모리가 소모되는 이유는 바로 역전파 과정에 있습니다. 이 과정은 크게 다음과 같은 두 단계로 나뉩니다.
- Forward Pass (순방향 패스)
입력 데이터를 이용해 출력을 계산합니다. 이 단계는 추론에도 동일하게 사용됩니다. - Backward Pass (역방향 패스)
예측값과 실제값(정답)의 차이를 바탕으로 오차를 계산하고, 각 파라미터의 기여도(Gradient)를 계산하여 가중치를 조정합니다.
이때,
- 기울기(Gradient): 각 파라미터가 오차에 얼마나 영향을 미치는지를 수학적으로 계산한 값입니다.
- Optimizer(최적화기): 각 기울기를 반영해 파라미터를 실제로 업데이트하는 역할을 합니다. 대표적으로 Adam, SGD 등이 있으며, 특히 Transformer 기반 모델에서는 Adam이 가장 널리 쓰입니다.
마무리 – 파인튜닝을 위한 메모리 최적화 전략
파인튜닝을 안전하고 효율적으로 수행하기 위해서는 다음과 같은 메모리 관리 전략이 매우 중요합니다.
전략 | 설명 |
PEFT | 전체 모델이 아닌 일부 파라미터만 학습해 메모리 대폭 절약 |
Quantization | 파라미터 표현 정밀도를 낮춰서 모델 크기 축소 |
Mixed Precision Training | 일부 연산만 낮은 정밀도로 수행하여 성능과 정확도 균형 유지 |
Gradient Checkpointing | 계산 중간 결과를 일부만 저장해 메모리 압축 |
미니 배치 학습 | 한 번에 학습하는 샘플 수를 줄여 메모리 분산 사용 |
실전 메모리 계산법 – 얼마나 필요한가?
파인튜닝을 시도하기 전에 반드시 확인해야 하는 것은 정말 그 모델을 운영할 수 있는 자원이 있는가?입니다. 특히 모델 크기, 파라미터 수, 배치 크기, 정밀도(precision)에 따라 메모리 사용량은 기하급수적으로 증가합니다.
추론에 필요한 메모리 계산법
추론 시에는 오직 forward pass만 실행되며, 아래 두 가지 요소의 메모리가 필요합니다:
- 모델 파라미터 메모리 (weights)
- 활성화값 메모리 (activations) – 특히 Transformer의 경우, key-value vectors가 배치 크기와 시퀀스 길이에 따라 메모리를 추가로 요구합니다.
계산 공식:
Training memory = weights + activations + gradients + optimizer states
- N: 파라미터 수
- M: 파라미터당 바이트 수 (예: FP16 = 2바이트)
- 1.2: 활성화 메모리 포함 여유치
예시:
- 13B 파라미터 모델을 FP16 (2바이트)로 추론 시:
- 13B × 2B = 26GB (파라미터)
- 총 메모리 = 26GB × 1.2 = 31.2GB
- 70B 모델의 경우:
- 70B × 2B = 140GB의 파라미터 메모리만 필요
즉, 24GB VRAM으로는 대형 모델 추론조차도 어렵습니다.
학습(파인튜닝)에 필요한 메모리 계산법
학습 시에는 forward pass + backward pass 모두 필요하며, 다음 항목까지 메모리에 적재되어야 합니다:
- 모델 가중치 (weights)
- 활성화 값 (activations)
- 기울기 (gradients)
- 옵티마이저 상태값 (optimizer states)
계산 공식:
Training memory = weights + activations + gradients + optimizer states
- 옵티마이저(예: Adam)는 파라미터당 평균 2~3배의 추가 메모리를 요구합니다.
- 따라서, 학습 메모리는 추론 대비 2~5배 이상이 될 수 있습니다.
실무 팁 – 이 계산을 꼭 해야 하는 이유
- 사전에 메모리 추정 없이 모델을 파인튜닝하려 한다면, CUDA out of memory 오류는 피할 수 없습니다.
- 또한, 파인튜닝을 진행하더라도 모델의 크기와 자원 사이의 균형이 맞지 않으면, 속도가 현저히 느려지거나 결과 품질이 저하될 수 있습니다.
- LoRA, QLoRA 같은 Parameter-Efficient Finetuning 기법은 이러한 문제를 해결하기 위한 실질적인 대안입니다.
최종 요약: 파인튜닝을 성공시키기 위한 실전 가이드
파인튜닝 핵심 요약
항목 | 설명 |
정의 | 기존 모델을 특정 목적에 맞게 추가 학습 |
목적 | 도메인 특화, 스타일 통제, 응답 품질 향상 등 |
종류 | Supervised, Preference, Long-context, PEFT 등 |
대안 | Prompt Engineering, RAG, Distillation |
조합 | RAG + Finetuning 조합이 실무적으로 강력함 |
자원 | 메모리, 데이터, 인력 등 사전 준비 필요 |
계산 | 추론/학습에 필요한 메모리 계산 필수 |
실무 전략 | PEFT, Quantization, Mixed Precision 등으로 최적화 |
파인튜닝 시 메모리는 어디서 가장 많이 쓰일까?
앞서 파인튜닝에는 모델 파라미터, 활성화값, 기울기, 옵티마이저 상태가 필요하다고 말씀드렸는데요, 여기서 구체적으로 어떤 요소가 얼마나 많은 메모리를 차지하는지를 계산해볼 수 있습니다.
옵티마이저 종류별 메모리 요구량
파인튜닝 시, 각 학습 가능한 파라미터에는 추가적으로 옵티마이저 상태가 함께 저장되어야 합니다. 옵티마이저의 종류에 따라 이 상태 메모리 크기가 달라집니다:
옵티마이저 | 파라미터당 상태 수 | 설명 |
SGD | 0 | 상태 없음 (가장 단순) |
Momentum | 1 | 속도(momentum) 벡터 1개 저장 |
Adam | 2 | 평균(m)과 분산(v) 벡터 모두 저장 |
예를 들어 Adam을 사용할 경우, 13B 파라미터 모델을 학습하려면:
13B × 3 × 2 bytes = 78GB
(가중치 + 기울기 + 옵티마이저 상태 각각 2바이트씩)
하지만 학습 가능한 파라미터 수가 적다면 (예: PEFT 방식으로 1B만 학습한다면):
1B × 3 × 2 bytes = 6GB
로 메모리 요구량을 10배 이상 줄일 수 있습니다.
활성화 메모리가 더 클 수도 있다
많은 분들이 놓치는 포인트는 활성화 메모리(activation memory)입니다.
이는 단순히 중간 계산값이 아니라, 기울기 계산에 반드시 필요하기 때문에 역전파 시점까지 유지되어야 하는 값들입니다.
Korthikanti et al. (2022)의 연구에 따르면, 일부 상황에서는 모델 가중치보다 활성화 메모리가 훨씬 더 많이 사용되기도 합니다.
해결 방법: Gradient Checkpointing
이 문제를 해결하는 기법 중 하나가 Gradient Checkpointing 또는 Activation Recomputation입니다.
필요할 때만 중간값을 다시 계산해서 메모리를 절약하는 방식입니다. 단, 연산 시간이 늘어나는 단점이 있습니다.
숫자 표현 방식이 메모리에 미치는 영향
모델의 수치 연산은 대부분 부동소수점(float)으로 이루어지며, 그 정밀도(precision)에 따라 메모리 사용량이 달라집니다.
표현 방식 | 비트 수 | 메모리 크기 | 설명 |
FP64 | 64bit | 8 bytes | double precision (매우 정확, 자주 사용되지 않음) |
FP32 | 32bit | 4 bytes | single precision (기본값) |
FP16 | 16bit | 2 bytes | half precision (메모리 절감용) |
- 최근에는 FP16 기반의 mixed precision training이 널리 사용되며, 메모리를 절감하면서도 일정 수준의 정확도를 유지할 수 있습니다.
정리: 파인튜닝 메모리 최적화 요령
항목 | 최적화 전략 |
파라미터 수 | PEFT로 학습 파라미터 수 최소화 |
옵티마이저 상태 | Adam보다 메모리 효율 높은 옵티마이저 고려 |
활성화 메모리 | Gradient Checkpointing으로 줄이기 |
수치 표현 방식 | FP16 등으로 Precision 낮춰 메모리 절감 |
장비 스펙 결정 | 메모리 계산 공식으로 사전 용량 산정 필수 |
정밀도와 수치 표현 형식 – FP32, FP16, BF16, TF32
딥러닝 모델의 메모리 최적화에서 숫자 표현 방식은 단순한 기술 옵션이 아닌 운영 비용과 성능의 핵심 변수입니다.
정밀도(Precision)란 무엇인가요?
정밀도는 한 숫자를 얼마나 정확하게 표현할 수 있는가를 의미합니다.
예를 들어 1234.56789를 표현할 때, 두 자리만 표현할 수 있다면 1234.57이 되고, 정밀도가 낮아지는 셈입니다.
정밀도가 낮을수록 메모리는 절약되지만, 값의 정확성이 손상될 수 있습니다.
따라서 적절한 균형이 중요합니다.
주요 부동소수점 포맷 비교 (FP32 vs FP16 vs BF16 vs TF32)
포맷 | 전체 비트 | 부호 비트 | 범위 비트 (Range) | 정밀도 비트 (Precision) | 메모리 | 설명 |
FP32 | 32 | 1 | 8 | 23 | 4 bytes | 가장 일반적인 싱글 정밀도 형식 |
FP16 | 16 | 1 | 5 | 10 | 2 bytes | 절반 정밀도, 메모리 절감용 |
BF16 | 16 | 1 | 8 | 7 | 2 bytes | Google TPU 최적화용, 정밀도 낮음 |
TF32 | 19 (실제 32) | 1 | 8 | 10 | 4 bytes | NVIDIA GPU용 (A100 이후), FP32와 호환성 유지 |
BF16은 FP16과 같은 16비트이지만, 정밀도는 더 낮고 표현 범위는 더 넓습니다.
실무 팁 – 어떤 포맷을 언제 선택해야 할까?
사용 목적 | 권장 포맷 | 이유 |
고정밀 연산 (예: 금융, 의학) | FP32 | 정밀도 우선 |
메모리 절약 & 속도 우선 | FP16 | 트레이닝 시간 & 메모리 절감 |
범위 우선 (큰 값 표현) | BF16 | 범위 넓음 (Google Cloud TPU 권장) |
NVIDIA A100 이상 GPU | TF32 | FP32 호환 + 성능 최적화 |
이 섹션 요약
- 정밀도 비트가 많을수록 표현 정확도는 높지만, 메모리 사용도 많아집니다.
- FP16/BF16은 메모리 절감 효과가 크지만 정밀도 손실이 발생합니다.
- 실무에서는 모델의 용도와 하드웨어 환경에 따라 포맷을 전략적으로 선택해야 합니다.
'머신러닝 & 딥러닝 > LLM' 카테고리의 다른 글
[LLM] Finetuning – 파인튜닝과 RAG의 관계 (0) | 2025.03.28 |
---|---|
[LLM] Finetuning – 파인튜닝의 정의 및 도입 시기 (0) | 2025.03.27 |
[LLM] AI Agent의 메모리 시스템 관리 및 데이터 구조화 (0) | 2025.03.06 |
[LLM] AI Agent의 효율성(Efficiency) 및 메모리(Memory) 시스템 (0) | 2025.03.06 |
[LLM] AI Agent의 실패 유형 및 평가 방법 (0) | 2025.03.06 |