모델이 실제로 필요로 하는 VRAM의 양입니다.
숫자 2개가 이를 결정합니다: 고정된 가중치와, 서빙하는 컨텍스트 양에 따라 커지는 KV 캐시입니다. 오답은 거의 모두 첫 번째 값에서 두 번째 값을 추정하는 데서 나옵니다.
짧은 답
- Weights
- 10억 단위 파라미터 수 × 파라미터당 바이트. 4비트의 70B는 35 GB입니다.
- KV 캐시
- 2 × 레이어 × KV 헤드 × 헤드 차원 × 바이트, 토큰당. 파라미터 수와는 무관합니다.
- Overhead
- 활성화 값, CUDA 컨텍스트, 할당자 단편화를 위해 약 15%를 더하십시오.
- 함정
- 가중치를 4비트로 양자화해도 캐시는 양자화되지 않습니다. 흔히 쓰이는 모든 스택에서 캐시는 FP16으로 유지됩니다.
계산식
두 번째 모델을 만나면 살아남는 경험칙이 여기에는 없습니다. 전체 계산은 3줄이며, 배수를 믿기보다 직접 계산해 보는 편이 낫습니다.
# 1. Weights
weights_gb = parameters_in_billions × bytes_per_parameter
# 2. KV cache, per token — then multiplied by the context you serve
bytes_per_tok = 2 × layers × kv_heads × head_dim × cache_bytes
cache_gb = bytes_per_tok × context_tokens × batch / 1024³
# 3. Everything else
total_gb = (weights_gb + cache_gb) × 1.15
2가 있는 이유는 토큰마다 K와 V, 텐서 2개가 있기 때문입니다. bytes_per_parameter는 BF16에서 2, FP8에서 1, 4비트에서 0.5입니다. cache_bytes는 별개의 숫자이며, 이 구분이 오답의 가장 흔한 원인입니다 — 아래를 참조하십시오.
가중치
쉬운 쪽 절반입니다. 파라미터 수에 정확히 비례하며, 결정할 것은 정밀도뿐입니다.
| 모델 | BF16 / FP16 | FP8 | 4-bit (AWQ, GPTQ) |
|---|---|---|---|
| Llama 3.1 8B | 16.0 GB | 8.0 GB | 4.0 GB |
| Qwen 3 32B | 64.0 GB | 32.0 GB | 16.0 GB |
| Llama 3.3 70B | 140.0 GB | 70.0 GB | 35.0 GB |
| Llama 3.1 405B | 810.0 GB | 405.0 GB | 202.5 GB |
4비트 양자화는 품질을 희생하며, 그 정도는 방법보다 모델에 훨씬 더 크게 좌우됩니다. 카드 1장과 4장을 가르는 상황이라면 옳은 절충이고, 이미 여유가 있다면 나쁜 절충입니다.
KV 캐시
어려운 쪽 절반이며, 어떤 머신이 4k에서는 충분하고 128k에서는 가망 없는지를 결정하는 쪽입니다. 레이어 수와 KV 헤드 수에 좌우됩니다 — 모델의 크기에는 좌우되지 않습니다.
| 모델 | 토큰당 | 4k 컨텍스트 | 8k 컨텍스트 | 32k 컨텍스트 | 128k 컨텍스트 |
|---|---|---|---|---|---|
| Llama 3.1 8B | 128 KB | 0.5 GB | 1.0 GB | 4.0 GB | 16.0 GB |
| Gemma 3 27B | 496 KB | 1.9 GB | 3.9 GB | 15.5 GB | 62.0 GB |
| Llama 3.3 70B | 320 KB | 1.3 GB | 2.5 GB | 10.0 GB | 40.0 GB |
| DeepSeek V3 671B-A37B (MoE) | 70 KB | 0.3 GB | 0.5 GB | 2.2 GB | 8.8 GB |
| Llama 3.1 405B | 504 KB | 2.0 GB | 3.9 GB | 15.8 GB | 63.0 GB |
첫 열보다 마지막 열을 먼저 보십시오. 4k 컨텍스트에서 캐시는 여기 있는 모든 모델에서 반올림 오차 수준이지만, 128k에서는 4비트 70B 모델의 가중치보다 큽니다. DeepSeek V3 모델은 예외인데, 잠재 어텐션이 설계상 캐시를 압축하기 때문입니다 — 목록에서 가장 큰 모델인데도 긴 컨텍스트에서 쓸 만한 이유가 여기에 있습니다.
추정이 어긋나는 지점
파라미터 수로 캐시를 추정하는 것. 가장 흔한 오류이며, 위에서 보인 것이 바로 그것입니다. 27B 모델이 70B 모델보다 더 많은 캐시를 필요로 할 수 있습니다.
4비트 가중치가 4비트 캐시를 뜻한다고 가정하는 것. 그렇지 않습니다. AWQ와 GPTQ는 가중치만 양자화하며, FP8 KV를 명시적으로 켜지 않는 한 캐시는 FP16으로 남습니다. 4비트에 128k 컨텍스트인 70B 모델은 가중치 35 GB에 캐시 40 GB입니다.
요청 1건만 기준으로 사이징하는 것. 캐시는 동시 시퀀스마다 필요합니다. 사용자 8명을 동시에 서빙하려면 캐시가 8배 필요합니다 — 아래를 참조하십시오.
오버헤드를 잊는 것. 활성화 값, CUDA 컨텍스트, 할당자 단편화는 실재합니다. 15%는 의도적으로 넉넉히 잡은 여유분이며, 이를 완전히 무시하면 “들어간다”던 모델이 로드에 실패합니다.
여러 카드의 VRAM을 합산하는 것. 24 GB 카드 4장은 96 GB 카드 1장이 아닙니다. 텐서 병렬화로 모델을 여러 카드에 나눌 수는 있지만, 그러면 모든 레이어가 링크를 통해 동기화합니다 — NVLink 가이드를 참조하십시오.
MoE를 활성 파라미터 기준으로 사이징하는 것. DeepSeek V3 모델은 토큰당 37B를 활성화하지만, 671B 전체를 메모리에 담아야 합니다. 활성 파라미터는 속도를 예측하고, 전체 파라미터는 아예 로드되는지 여부를 결정합니다.
계산 예시
8k 컨텍스트, 요청 1건 기준으로 가중치와 캐시, 오버헤드를 합한 총 필요 메모리입니다. 구성 도구가 카탈로그의 모든 구성에 대해 수행하는 계산과 동일합니다.
| 모델 | BF16 / FP16 | FP8 | 4-bit (AWQ, GPTQ) | 들어가는 가장 작은 노드 |
|---|---|---|---|---|
| Llama 3.1 8B | 20 GB | 10 GB | 6 GB | NVIDIA L4 |
| Mistral Small 24B | 57 GB | 28 GB | 15 GB | NVIDIA L4 |
| Gemma 3 27B | 67 GB | 33 GB | 20 GB | NVIDIA L4 |
| Qwen 3 32B | 76 GB | 38 GB | 21 GB | NVIDIA L4 |
| Llama 3.3 70B | 164 GB | 82 GB | 43 GB | 2 × NVIDIA L4 |
| Mixtral 8×22B (MoE) | 326 GB | 163 GB | 83 GB | 4 × NVIDIA L4 |
| Qwen 3 235B-A22B (MoE) | 542 GB | 271 GB | 137 GB | 8 × NVIDIA L4 |
| DeepSeek V3 671B-A37B (MoE) | 1,544 GB | 772 GB | 386 GB | 8 × NVIDIA A100 PCIe |
| Llama 3.1 405B | 936 GB | 468 GB | 237 GB | 10 × NVIDIA L4 |
마지막 열은 4비트, 8k 컨텍스트에서 모델을 담는, 당사 카탈로그에서 가장 저렴한 노드이며, 메모리 대역폭이 허용하는 단일 스트림 생성 속도를 함께 표시합니다. 처리량 수치는 의도적으로 보수적으로 잡았고 공개된 측정값에 맞추어 보정했습니다 — 약속이 아니라 하한으로 보십시오.
요청을 여러 건 서빙하기
데모에 맞춰 사이징한 머신이 제품을 서빙하지 못하는 머신이 되는 지점이 바로 여기입니다. 가중치는 1회 지불하고, 캐시는 동시 시퀀스마다 지불합니다.
| 동시 요청 | 4k 컨텍스트 | 8k 컨텍스트 | 32k 컨텍스트 |
|---|---|---|---|
| 요청 1건 | 42 GB | 43 GB | 52 GB |
| 요청 4건 | 46 GB | 52 GB | 86 GB |
| 요청 16건 | 63 GB | 86 GB | 224 GB |
| 요청 64건 | 132 GB | 224 GB | 776 GB |
Llama 3.3 70B 모델은 4비트에서 무엇을 하든 가중치가 35 GB입니다. 그 표에서 35 GB를 넘는 것은 모두 캐시입니다. “내 노트북에서는 잘 돌았다”와 “운영 환경에서 무너졌다”가 같은 카드 위의 같은 모델인 이유가 바로 이것입니다.
--max-model-len 값을 실제로 서빙하는 컨텍스트로 제한하십시오: vLLM은 선언된 최댓값에 맞추어 캐시를 예약하므로, 8k를 서빙하면서 128k를 선언하면 필요한 메모리의 16배를 버리게 됩니다.
그에 해당하는 머신
위의 모든 내용에서 따라 나오는 실용적인 규칙 3가지를, 중요한 순서대로 정리했습니다.
- 가능하다면 언제나 카드 1장이 여러 장보다 낫습니다. 샤딩도, 레이어 간 동기화도, 고민해야 할 인터커넥트도 없습니다. 사용하시는 컨텍스트에서 모델이 단일 카드에 들어간다면, 그 카드를 사십시오.
- 모델이 광고하는 최댓값이 아니라, 실제 컨텍스트와 실제 동시성에 맞추어 사이징하십시오. 광고된 최댓값은 능력치일 뿐 요구 사항이 아닙니다.
- 샤딩해야 한다면 NVLink를 택하십시오. PCIe 카드 4장에 나누는 것도 동작하지만, NVLink 카드 4장에 나누면 동작하면서 의미 있게 더 빠릅니다. 다음 가이드는 그 차이에 값을 치를 만한 때가 정확히 언제인지를 다룹니다.
구성 도구는 구성 41개 전체에 대해 이 계산을 실시간으로 수행합니다: 모델과 정밀도, 컨텍스트 길이를 고르면 어느 노드가 이 모델을 담는지, 어느 노드가 단일 카드에 담는지, 각각의 월 비용이 얼마인지 알려 줍니다. 이 페이지의 계산식을 그대로 쓰므로, 당사의 계산에 동의하지 않으신다면 이제 어느 부분인지 정확히 지적하실 수 있습니다.
다른 가이드
- 사이징 · 7분
NVLink 또는 PCIe: 작업에 필요한 쪽
카드 사이의 연결이 처리량을 좌우하는 경우, 아무것도 바꾸지 않는 경우, 그리고 잘못된 노드에 돈을 쓰기 전에 어느 쪽인지 판단하는 방법.
가이드 읽기 - 사이징 · 9분
이미지·영상 모델용 카드 선택
FLUX, SDXL, SD 3.5, Wan 2.1 모델이 VRAM을 얼마나 요구하는지, 카탈로그의 어떤 카드가 각각을 담는지, 그리고 들어가는 가장 싼 카드가 왜 임대할 카드가 아닌지.
가이드 읽기 - 사이징 · 10분
양자화 형식 선택
AWQ, GPTQ, GGUF, FP8 포맷이 각각 메모리, 속도, 품질에서 치르는 대가 — 그리고 가중치가 가장 작은 포맷이 왜 가장 작은 모델로 이어지지 않는지.
가이드 읽기