Llama 3 또는 Gemma를 로컬에서 실행하려면 실제로 VRAM이 얼마나 필요할까요?
요약
Llama 3 및 Gemma 모델을 로컬에서 실행할 때 필요한 실제 VRAM 계산법을 설명합니다. 모델 가중치뿐만 아니라 컨텍스트 길이에 따라 급격히 증가하는 KV 캐시의 중요성을 수학적으로 분석합니다.
핵심 포인트
- VRAM은 가중치, KV 캐시, 오버헤드 세 요소로 구성됨
- 가중치는 고정적이지만 KV 캐시는 컨텍스트 길이에 따라 선형적으로 증가함
- Llama 3 8B 기준 128K 컨텍스트 사용 시 약 16GB의 KV 캐시가 필요함
- 단순 가중치 크기만 고려하면 긴 문맥 처리 시 OOM 발생 위험이 높음
며칠마다 로컬 LLM 스레드에서 누군가 똑같은 질문을 던집니다. "이거 제 3060에서 돌아갈까요?" 그리고 답변은 거의 항상 느낌(vibes)에 의존합니다. "괜찮을 거예요." "아마 양자화(quantize)가 필요할 겁니다." 아무도 수학적 계산을 보여주지 않기 때문에, 여러분은 16GB 모델을 다운로드하고 로드했다가 결국 고생하며 깨닫게 됩니다.
저도 얼마 전에 정확히 그렇게 했습니다. 8B 모델을 가져왔고, 12GB 카드에서 잘 로드되길래 제가 똑똑하다고 느꼈지만, 긴 문서의 약 20,000개 토큰 지점에서 OOM(Out of Memory)이 발생했습니다. 가중치(weights)는 들어갔지만, KV 캐시(KV cache)가 들어가지 않은 것입니다. 그 차이가 바로 이 포스트를 작성한 이유입니다.
그래서 여기 Llama 3와 Gemma의 실제 수치를 이용한 진짜 수학적 계산이 있습니다. 여기에는 서류상으로는 동일해 보이는 두 모델이 매우 다른 양의 메모리를 필요로 한다는, 저를 놀라게 했던 부분도 포함되어 있습니다.
VRAM을 잡아먹는 세 가지 요소
모델을 로컬에서 실행할 때, GPU 메모리는 세 곳으로 사용됩니다:
- 모델 가중치 (model weights)
- KV 캐시 (KV cache)
- 약간의 오버헤드 (CUDA context, activations, fragmentation)
대부분의 "VRAM이 얼마나 필요한가"에 대한 답변은 첫 번째 요소만 이야기합니다. 그것이 실수입니다.
1. 가중치(Weights): 모두가 인용하는 수치
이것은 간단합니다. 가중치는 파라미터 수 × 가중치당 바이트(bytes per weight)를 차지합니다. 전체 정밀도(FP16)는 가중치당 2바이트이며, 양자화(quantization)를 통해 이를 줄일 수 있습니다:
| 형식 | 가중치당 바이트 | Llama 3 8B 가중치 |
|---|---|---|
| FP16 | 2.0 | ~15 GB |
| ... |
제가 주로 사용하는 것은 Q4_K_M입니다. 이는 보통의 최적 지점(sweet spot)으로, FP16 크기의 약 4분의 1 수준이면서 대부분의 작업에서 품질 차이를 느끼기 어렵습니다. 따라서 8B 모델의 가중치는 약 4.3GB입니다. 쉽죠. 무엇이든 들어갑니다.
하지만 이것이 여러분을 속이는 수치입니다. 왜냐하면 이것은 이야기의 일부일 뿐이기 때문입니다.
2. KV 캐시(KV cache): 프롬프트에 따라 확장되는 부분
모델이 텍스트를 생성할 때, 이미 본 모든 토큰에 대한 키(key)와 값(value) 벡터를 캐싱하여 새로운 토큰이 나올 때마다 이를 다시 계산하지 않도록 합니다. 그 캐시가 바로 KV 캐시이며, 컨텍스트 길이(context length)에 따라 선형적으로 증가합니다. 프롬프트가 길면 캐시도 커집니다.
공식:
KV bytes = 2 × layers × kv_dim × context_length × bytes_per_element
앞서 언급한 숫자 2는 Key(키)를 위한 한 슬롯과 Value(값)를 위한 한 슬롯을 의미합니다. Llama 3 8B의 경우, 32개의 레이어(layers), 1024의 KV 차원(KV dimension, Grouped-Query Attention을 사용하므로 KV 헤드는 Attention 헤드보다 작습니다), 그리고 FP16 캐시 기준 요소당 2바이트(bytes per element)를 적용하면 다음과 같습니다:
2 × 32 × 1024 × 8192 × 2 ≈ 8K 컨텍스트에서 약 1 GB
지금까지는 괜찮습니다. 1GB는 별것 아닙니다. 하지만 컨텍스트(context)가 커짐에 따라 어떤 일이 발생하는지 주목하십시오. 가중치(weights)는 고정되어 있지만, 캐시(cache)는 그렇지 않기 때문입니다:
- 8K 컨텍스트: ~1 GB
- 32K 컨텍스트: ~4 GB
- 128K 컨텍스트: ~16 GB
가중치가 4GB인 모델을 위해 16GB의 KV 캐시가 필요하게 됩니다. 이것이 바로 모델은 잘 로드되지만, 긴 문서를 처리하는 도중에 모델이 죽어버리는 이유입니다. 모델을 위한 공간이 부족했던 것이 아닙니다. 대화에 대한 기억(memory)을 위한 공간이 부족했던 것입니다.
3. 오버헤드 (Overhead)
CUDA는 일정량의 메모리를 예약하고, 활성화 값(activations)은 임시 공간(scratch space)이 필요하며, 할당자(allocators)는 간격(gaps)을 남깁니다. 저는 가중치와 캐시를 합친 값에 약 10%를 추가로 예산에 잡습니다. 이는 법칙은 아니지만, 여유 공간을 너무 타이트하게 잡지 않기 위한 경험 법칙(rule of thumb)입니다.
종합하기: Llama 3 8B
Q4_K_M 가중치(약 4.3GB)에 8K 컨텍스트에서의 1GB KV 캐시, 그리고 10%의 오버헤드를 더하면 총 약 5.8GB가 됩니다. 이는 12GB 그래픽 카드에서는 충분한 여유를 두고 작동하며, 8GB 그래픽 카드에서도 약간의 여유를 두고 작동합니다. 컨텍스트를 32K로 늘리면 약 9GB가 되어 12GB 카드에서도 여전히 괜찮습니다. 128K 컨텍스트로 가면 KV 캐시만으로도 가중치보다 커지며, 이제는 24GB 그래픽 카드가 필요합니다.
동일한 모델, 동일한 양자화(quant)입니다. 바뀐 것은 당신이 모델에 입력한 텍스트의 양뿐입니다.
나를 놀라게 한 부분: Gemma 2 9B
Gemma 2 9B와 Llama 3 8B는 동일한 가중치 체급으로 보입니다. 파라미터(parameters) 수에서 10억 개 차이가 나지만, 둘 다 일반적인 게이밍 GPU에서 실행되므로 비슷한 양의 VRAM이 필요할 것이라고 예상할 것입니다.
계산을 해봅시다. Q4_K_M 양자화(Quantization) 기준, 가중치(Weights)는 Llama가 4GB를 약간 상회하고 Gemma가 약 5GB로 서로 비슷합니다. 하지만 8K 컨텍스트에서의 KV 캐시(KV cache)는 Gemma의 경우 1GB가 아니라 대략 2.6GB입니다. Gemma는 더 큰 헤드 차원(Head dimension)과 더 많은 레이어(Layer)를 사용하기 때문에, kv_dim이 Llama의 두 배이며 캐싱해야 할 레이어도 10개 더 많습니다. 결과적으로 Llama의 5.8GB와 비교했을 때 Gemma는 총 약 8.4GB가 필요합니다.
매개변수(Parameter)는 10억 개 더 많지만, VRAM은 약 2.5GB 더 많이 필요하며, 그 대부분은 KV 캐시에 숨어 있습니다. 매개변수 수만 보고는 절대 예측할 수 없는 부분이며, 바로 이런 점이 "맞을 것이다"라고 생각했던 모델을 최악의 순간에 OOM(Out of Memory)으로 만들어버리는 원인이 됩니다.
그래서 저는 수동으로 계산하는 것을 그만두었습니다
모델별, 양자화 방식별, 컨텍스트 길이별로 이를 일일이 계산하는 것은 지루한 일이었기에, 이를 대신 해주는 계산기를 만들었습니다: LLM VRAM Calculator. 모델을 선택하거나(또는 직접 매개변수, 레이어, KV 차원을 입력하거나), 양자화 방식과 컨텍스트 길이를 선택하면 가중치, KV 캐시, 오버헤드(Overhead)를 세부적으로 나누어 보여주며 어떤 GPU에 적합한지 알려줍니다. 브라우저에서 실행되며, 아무것도 업로드되지 않습니다.
상세 내역을 확인할 수 있게 되면 알아두어야 할 몇 가지 사항이 있습니다:
- 긴 컨텍스트(Long context)에서 OOM이 발생한다면, 그것은 가중치가 아니라 거의 항상 KV 캐시 때문입니다. 컨텍스트 창(Context window)을 줄이거나, KV 캐시를 FP8로 설정하여 크기를 절반으로 줄이세요.
- 동시 요청(Concurrent requests)은 캐시를 배수로 늘립니다. 8K 컨텍스트에서 4명의 사용자에게 서비스를 제공하는 것은 1명일 때보다 KV 메모리가 대략 4배 더 필요함을 의미합니다.
- Apple Silicon은 통합 메모리(Unified memory)가 하나의 공유 풀(Pool)이기 때문에 이 문제를 약간 우회하며, 일반적인 VRAM 한계가 동일한 방식으로 적용되지 않습니다.
제가 실제로 사용하는 경험적인 규칙(Rule of thumb)은 다음과 같습니다: 양자화된 가중치 크기를 가져온 뒤, 7B~8B 모델의 경우 8K 컨텍스트당 약 1GB의 KV를 더하고(Gemma 스타일의 아키텍처는 더 많이), 거기에 10%를 추가합니다. 아니면 산수를 건너뛰고 16GB를 다운로드하기 전에 계산기를 확인하세요.
만약 매개변수 수가 시사하는 것과 판이하게 다른 메모리 프로필을 가진 모델을 실행하게 된다면, 진심으로 의견을 듣고 싶습니다. 그런 모델들이야말로 GPU를 구매하기 전에 반드시 알아두어야 할 대상이기 때문입니다.
AI 자동 생성 콘텐츠
본 콘텐츠는 Dev.to AI tag의 원문을 AI가 자동으로 요약·번역·분석한 것입니다. 원 저작권은 원저작자에게 있으며, 정확한 내용은 반드시 원문을 확인해 주세요.
원문 바로가기