로컬 LLM VRAM 계산법, 모델 크기별로 그래픽카드 몇 GB가 필요할까

내 컴퓨터에서 AI 모델을 직접 돌리려고 그래픽카드를 알아보면 가장 먼저 부딪히는 질문이 로컬 LLM VRAM입니다. “8B 모델은 8GB면 되나”, “16GB면 어디까지 되나”, “32B를 돌리려면 무엇을 사야 하나” 같은 질문입니다. 답은 감으로 정할 필요가 없습니다. 모델 파일 크기와 대화 길이에 따른 메모리는 공식으로 계산할 수 있고, 그 결과는 실제 배포 파일 크기와도 잘 맞습니다.

이 글은 그 계산을 처음부터 끝까지 공개합니다. 양자화 형식별 크기는 llama.cpp 공식 README의 측정표에서, 모델 구조 값은 Hugging Face의 모델 카드와 설정 파일에서, 그래픽카드 사양은 NVIDIA·AMD 공식 페이지에서 2026.10 기준으로 확인했습니다. 계산은 모두 Python으로 실행했고, 공식과 가정을 함께 적어 독자가 다른 모델에도 그대로 적용할 수 있게 했습니다. 노트북이나 미니 PC처럼 CPU와 GPU가 메모리를 나눠 쓰는 기기라면 AI PC 선택 기준 글이 더 맞고, 이 글은 데스크톱 그래픽카드의 전용 메모리(VRAM)를 중심으로 봅니다. AI 도구 관련 글은 AI 도구·활용 카테고리에 모아 두었습니다.

로컬 LLM VRAM은 무엇으로 정해지나

그래픽카드에서 LLM을 돌릴 때 VRAM을 차지하는 것은 크게 세 가지입니다.

1. 가중치(모델 파일): 학습으로 정해진 파라미터 값입니다. 파라미터 수 × 파라미터 하나의 비트 수로 크기가 정해지고, 실행 내내 VRAM에 머뭅니다.
2. KV 캐시: 모델이 이미 읽은 토큰의 키(Key)·값(Value)을 저장해 두는 공간입니다. 대화가 길어질수록 커집니다.
3. 실행 버퍼와 여유분: 계산 중간값, 드라이버와 화면 출력이 쓰는 메모리입니다. 환경마다 달라서 정확한 공식은 없고, 이 글에서는 1.0GB를 가정합니다.

많은 글이 1번만 계산하고 끝냅니다. 그러면 “8B 4비트 모델은 5GB니까 6GB 그래픽카드면 충분하다”는 결론이 나오는데, 실제로는 대화가 길어지는 순간 2번이 몇 GB씩 붙습니다. 반대로 3번을 과하게 잡으면 필요 이상으로 비싼 카드를 사게 됩니다. 아래에서 세 가지를 차례로 계산합니다.

양자화별 가중치 크기: 10억 파라미터당 몇 GB인가

양자화는 파라미터 하나를 16비트 대신 8비트, 4비트 같은 더 적은 비트로 저장하는 방법입니다. llama.cpp는 공식 README에 Llama 3.1 8B 모델을 형식별로 양자화했을 때의 비트 수(bpw, bits per weight)와 파일 크기, 속도를 표로 공개하고 있습니다. 이 값을 바탕으로 10억 파라미터당 메모리를 계산했습니다.

출처: llama.cpp quantize README의 Llama 3.1 8B 표(2026.10 기준). 10억 개당 GB = bpw ÷ 8, 속도 배율은 같은 표의 텍스트 생성 속도(128토큰)를 F16 값으로 나눈 값.

두 가지가 눈에 띕니다. 첫째, “4비트”라고 부르는 Q4_K_M의 실제 비트 수는 4.0이 아니라 4.89입니다. 블록마다 배율(scale) 같은 부가 정보를 함께 저장하기 때문입니다. 그래서 “4비트면 10억 개당 0.5GB”로 계산하면 20% 가까이 작게 잡게 됩니다. 둘째, 생성 속도는 크기에 거의 반비례합니다. 16비트에서 Q4_K_M으로 줄이면 파일은 30.6%가 되고 속도는 2.47배가 됐습니다. 토큰을 하나 만들 때마다 가중치 전체를 메모리에서 읽어야 하므로, 읽을 양이 줄면 빨라지는 구조입니다. 다만 Q3_K_M 아래로 내려가면 속도 이득이 거의 멈추고, 품질 손실은 커지는 쪽이라 일반적인 출발점은 Q4_K_M 전후입니다.

계산값은 실제 파일과 맞을까

공식이 현실과 맞는지 확인하려면 실제 배포 파일과 비교하면 됩니다. Ollama 라이브러리는 Qwen3 모델을 형식별로 배포하며 파일 크기를 공개하고 있습니다. 모델 카드의 실제 파라미터 수(8B는 8.2B, 14B는 14.8B, 32B는 32.8B)에 위 표의 bpw를 곱해 계산값과 비교했습니다.

출처: 파라미터 수는 Hugging Face Qwen3 모델 카드, 파일 크기는 Ollama qwen3 태그 페이지(2026.10 기준). 계산값 = 파라미터(10억) × bpw ÷ 8.

아홉 경우 모두 계산값과 실제 파일의 차이가 4% 안쪽입니다. Ollama 페이지의 크기는 소수점 첫째 자리 또는 정수로 반올림된 값이라 1~2% 차이는 표기 오차 범위입니다. 즉 “파라미터 수 × bpw ÷ 8”만으로 가중치 크기는 충분히 정확하게 예측된다고 볼 수 있습니다. 작은 모델에서 계산값보다 파일이 조금 큰 것은 임베딩처럼 일부 층을 더 높은 정밀도로 남겨 두는 경우가 많기 때문으로 보입니다.

대화 길이만큼 늘어나는 KV 캐시 계산

KV 캐시는 모델이 앞서 읽은 토큰마다 키와 값을 저장해 두는 공간입니다. Sebastian Raschka가 정리한 계산식은 다음과 같습니다.

KV 캐시(바이트) = 2(키·값) × 레이어 수 × KV 헤드 수 × 헤드 차원 × 원소당 바이트 × 토큰 수

여기서 KV 헤드 수가 핵심입니다. 최신 모델 대부분은 GQA(그룹 쿼리 어텐션)를 써서 질문(Query) 헤드보다 KV 헤드를 훨씬 적게 둡니다. Qwen3 32B는 Query 헤드 64개에 KV 헤드 8개라 캐시가 8분의 1로 줄어 있습니다. Raschka는 이 공식에 2가 두 번 들어간다는 점도 짚습니다. 하나는 키와 값 두 텐서, 다른 하나는 16비트 원소의 2바이트입니다. 하나를 빼먹으면 결과가 절반이 됩니다.

설정 파일의 값을 넣어 계산한 결과입니다.

출처: 레이어·헤드 값은 각 모델의 Hugging Face 설정 파일(Qwen3 공식, Llama 3.3은 Unsloth 미러). 16비트(f16) 캐시 기준, 1GB = 10⁹바이트로 계산.

검산도 해 볼 수 있습니다. Raschka의 글은 Qwen3 8B를 32,768토큰으로 계산하면 약 4.5GiB라고 예시를 듭니다. 위 표의 4.83GB를 GiB(2³⁰바이트)로 바꾸면 4.50GiB로 같습니다.

이 표에서 볼 점은 32K 대화에서는 KV 캐시가 작은 모델의 가중치만큼 커진다는 것입니다. Qwen3 8B는 4비트 가중치가 5.2GB인데 32K 캐시가 4.83GB입니다. 긴 문서를 통째로 넣고 요약하는 용도라면 이 몫을 반드시 따로 잡아야 합니다.

기본 4K와 캐시 양자화

Ollama 공식 FAQ에 따르면 Ollama의 기본 컨텍스트 길이는 4,096토큰이고, OLLAMA_CONTEXT_LENGTH 환경 변수로 바꿀 수 있습니다. 기본값으로 쓰면 KV 캐시는 1GB 안팎이라 크게 신경 쓸 일이 없지만, 긴 문서를 다루려고 컨텍스트를 늘리는 순간 위 표의 오른쪽 열로 이동합니다.

캐시 자체를 줄이는 방법도 있습니다. Ollama는 OLLAMA_KV_CACHE_TYPE으로 KV 캐시 형식을 정할 수 있고, 기본값은 f16입니다. FAQ는 q8_0이 f16의 약 2분의 1 메모리를 쓰며 정밀도 손실이 매우 작고, q4_0은 약 4분의 1을 쓰며 작거나 중간 정도의 손실이 있다고 설명합니다. 캐시 양자화는 플래시 어텐션이 켜져 있을 때 동작하고, 현재는 모든 모델에 한꺼번에 적용되는 전역 설정입니다. Qwen3 32B의 32K 캐시라면 8.59GB가 q8_0에서 약 4.3GB로 줄어듭니다.

그래픽카드 VRAM별로 올릴 수 있는 모델

이제 세 가지를 합칩니다. 가중치는 Ollama의 실제 파일 크기, KV 캐시는 위 표, 여유분은 1.0GB로 잡았습니다.

계산: 필요량 = Ollama 파일 크기 + KV 캐시(f16) + 여유 1.0GB(가정). 화살표 뒤는 그 필요량을 담을 수 있는 가장 작은 일반 VRAM 용량(8·12·16·24·32GB).

8K 대화 길이를 기준으로 하면 표는 단순하게 정리됩니다. 8GB는 8B급, 12GB는 14B급, 24GB는 32B급입니다. 대화를 32K로 늘리면 한 단계씩 위 용량이 필요해지는데, 캐시를 q8_0으로 줄이면 다시 반 단계 정도 내려옵니다. 예를 들어 Qwen3 14B를 32K로 쓰는 경우 f16 캐시는 15.7GB로 16GB 카드에 빠듯하지만, q8_0이면 13.0GB로 여유가 생깁니다. 다만 8GB 카드에 8B 모델을 8K로 올리는 조합(7.4GB)은 숫자상 들어가도 화면 출력이 같은 VRAM을 쓰면 넘칠 수 있으니 여유가 거의 없다고 보는 편이 맞습니다.

MoE(전문가 혼합) 모델은 따로 봐야 합니다. OpenAI의 gpt-oss-20b는 전체 210억 파라미터 중 토큰마다 36억 개(17.1%)만 계산에 쓰는 구조이고, 모델 카드는 이 모델이 16GB 메모리 안에서 돌아간다고 밝힙니다. Ollama의 gpt-oss:20b 파일은 14GB입니다. 여기에 여유분 1GB를 더하면 15GB라 16GB 카드가 맞는 구간입니다. 반면 gpt-oss-120b는 OpenAI 기준으로 80GB 그래픽카드 한 장이 필요한 모델이라 일반 소비자용 카드의 범위를 벗어납니다. MoE는 메모리는 전체 파라미터만큼, 속도는 활성 파라미터만큼 든다는 점을 기억하면 됩니다.

주요 그래픽카드의 VRAM과 대역폭

출처: NVIDIA GeForce 사양 비교 페이지, AMD RX 9070 XT 사양 페이지(2026.10 기준). RTX 5060 Ti는 8GB 모델도 있으니 용량 표기를 확인해야 합니다.

MSI 지포스 RTX 5060 Ti 벤투스 2X OC 플러스 (16GB) 쿠팡에서 가격 확인 →

같은 16GB라도 대역폭은 448GB/s(RTX 5060 Ti)부터 960GB/s(RTX 5080)까지 두 배 넘게 차이 납니다. 이 차이는 “어떤 모델을 올릴 수 있는가”가 아니라 “올린 모델이 얼마나 빨리 답하는가”를 가릅니다. 24GB 구간은 2026.10 기준 RTX 50 시리즈 데스크톱 라인업에 없습니다. NVIDIA 사양 비교 페이지에서 24GB는 RTX 4090·RTX 3090 같은 이전 세대 카드에 표기돼 있어, 32B급을 8K로 쓰려면 RTX 5090(32GB)이나 이전 세대 24GB 카드를 봐야 합니다.

MSI 지포스 RTX 5070 Ti 게이밍 트리오 OC (16GB) 쿠팡에서 가격 확인 →

속도는 대역폭이 정한다: 이론 상한과 실측 비교

토큰 생성은 매번 가중치 전체를 VRAM에서 읽어 오는 작업이라, 대역폭 ÷ 모델 크기가 초당 토큰 수의 이론 상한이 됩니다. 이 상한이 실제와 얼마나 맞는지 llama.cpp 공식 GitHub 토론의 CUDA 점수표와 비교했습니다. 점수표는 Llama 2 7B Q4_0(파일 3.56GiB)을 llama-bench로 측정한 값입니다.

단위: 초당 토큰. 실측은 llama.cpp Discussion #15013 CUDA 점수표(플래시 어텐션 끔). 이론 상한 = 대역폭 ÷ 파일 크기(3.56GiB = 3.823GB), 14B·32B는 Ollama 파일 9.3GB·20GB로 계산.

실측은 이론 상한의 62~78%에 들어왔습니다. 대역폭이 가장 큰 RTX 5090의 비율이 가장 낮은데, 작은 7B 모델에서는 메모리 읽기 외의 고정 비용이 상대적으로 커지기 때문으로 해석됩니다. 실용적으로는 예상 속도를 “대역폭 ÷ 모델 크기”의 약 70% 수준으로 잡으면 크게 벗어나지 않습니다. 이 기준으로 RTX 5060 Ti에서 14B Q4 모델은 초당 약 34토큰, RTX 5070 Ti는 약 67토큰을 예상할 수 있습니다. 사람이 읽는 속도보다 충분히 빠른 수준이라, 이 구간에서는 대역폭보다 용량이 선택을 가르는 경우가 많습니다.

ASUS ROG Astral 지포스 RTX 5090 OC (32GB) 쿠팡에서 가격 확인 →

독립 측정에서도 같은 결론이 나옵니다. Level1Techs 포럼의 비교에서 RTX 5080(16GB)은 Gemma 3 27B 양자화 모델(13.7GB)과 8K 컨텍스트가 16GB에 다 들어갈 때 RTX 3090 Ti(24GB)보다 프롬프트 처리가 약 20%, 토큰 생성이 10~15% 빨랐습니다. 하지만 작성자는 더 긴 컨텍스트에서는 5080이 CPU 오프로드를 해야 해 속도 이점이 사라진다고 지적했고, 본격적인 로컬 LLM 용도라면 VRAM이 많은 쪽을 고르겠다고 결론 내렸습니다.

VRAM이 모자라면: 시스템 메모리로 나눠 올릴 때의 속도

Ollama와 llama.cpp는 VRAM에 다 들어가지 않는 부분을 시스템 메모리(RAM)에 두고 CPU와 나눠 실행할 수 있습니다. Ollama FAQ는 ollama ps의 PROCESSOR 열이 “100% GPU”, “100% CPU”, 또는 “48%/52% CPU/GPU”처럼 나뉜 비율을 보여 준다고 안내합니다. 실행은 되지만, 속도는 어떻게 될까요.

토큰 하나를 만드는 시간은 GPU 쪽 가중치를 읽는 시간과 RAM 쪽 가중치를 읽는 시간의 합으로 근사할 수 있습니다. RAM은 DDR5-5600 듀얼 채널을 가정했고, 대역폭은 5,600MT/s × 8바이트 × 2채널 = 89.6GB/s로 계산했습니다. Qwen3 32B 4비트(20GB)를 8K 대화로 올리는 경우입니다.

계산: GPU에 올릴 수 있는 가중치 = VRAM − 8K KV 캐시(2.15GB) − 여유 1.0GB. 시간 = GPU 몫 ÷ VRAM 대역폭 + RAM 몫 ÷ 89.6GB/s. 실제 속도는 이 상한보다 낮습니다.

이 표가 이 글에서 가장 중요한 결과입니다. 16GB 카드 두 종은 VRAM 대역폭이 두 배 차이 나는데도 이론 상한은 9.2와 10.6으로 15% 차이에 그칩니다. 시간의 4분의 3 이상을 RAM에서 가중치를 읽는 데 쓰기 때문입니다. 모델이 VRAM을 넘치는 순간 그래픽카드 등급은 속도에 거의 영향을 주지 못하고, 느린 RAM이 속도를 정합니다. 반대로 같은 모델이 VRAM에 다 들어가는 32GB 카드는 상한이 89.6으로 열 배 가까이 됩니다. 큰 모델을 쓰려고 그래픽카드를 한 단계 올릴 계획이라면, 대역폭이 아니라 “이번에는 다 들어가는가”를 먼저 계산해야 합니다.

XFX 라데온 RX 9070 XT SWIFT (16GB) 쿠팡에서 가격 확인 →

흔한 오해와 반론

“모델 이름의 B 숫자만큼 GB가 필요하다.” 16비트라면 10억 개당 2GB라 8B 모델은 약 16GB입니다. 반대로 4비트(Q4_K_M)라면 10억 개당 0.61GB라 약 5GB입니다. 같은 모델도 형식에 따라 세 배 넘게 달라지므로, 반드시 형식을 함께 확인해야 합니다.

“VRAM은 모델 파일 크기만큼만 있으면 된다.” 파일 크기는 가중치만의 크기입니다. 앞서 본 것처럼 32K 대화에서는 KV 캐시가 작은 모델의 가중치만큼 커지고, 실행 버퍼도 필요합니다. 파일 크기보다 최소 2~3GB 여유를 두는 편이 안전합니다.

“더 낮은 비트로 양자화하면 무조건 이득이다.” llama.cpp 표에서 Q3_K_M과 Q4_K_M의 생성 속도는 사실상 같았습니다(16비트 대비 2.46배와 2.47배). 크기는 줄지만 속도 이득이 거의 없고, 비트를 줄일수록 품질 손실 위험은 커집니다. 2~3비트는 “그래야만 들어가는” 경우의 마지막 선택지로 보는 편이 합리적입니다.

반대쪽 시각도 있습니다. 이 글의 계산은 한 번에 한 사람이 쓰는 경우(배치 1)를 가정한 근사치입니다. Raschka도 공식 결과는 논리적인 추정치이고 실제 서빙 메모리는 대개 더 크다고 적었습니다. 이미지 입력을 받는 모델은 별도의 비전 인코더를 함께 올리고, 여러 요청을 동시에 처리하면 KV 캐시가 요청 수만큼 늘어납니다. 또 Ollama 페이지의 크기 표기는 반올림 값입니다. 그래서 계산 결과가 VRAM에 딱 맞는 구성은 실제로는 넘칠 수 있다고 보고, 10% 정도 여유를 두는 것을 권합니다.

직접 계산해 보기

다른 모델도 아래 세 줄로 계산할 수 있습니다. 필요한 값은 모델 카드의 파라미터 수와 설정 파일(config.json)의 num_hidden_layers, num_key_value_heads, head_dim입니다.

1. 가중치(GB) = 파라미터 수(10억) × bpw ÷ 8 (Q4_K_M은 4.89, Q8_0은 8.50, 16비트는 16)
2. KV 캐시(GB) = 2 × 레이어 수 × KV 헤드 수 × 헤드 차원 × 2바이트 × 토큰 수 ÷ 10⁹ (캐시 q8_0이면 절반)
3. 필요 VRAM = 가중치 + KV 캐시 + 여유분(1GB 안팎)

예시 1: Qwen3 14B를 16GB 카드에서 32K로

가중치는 14.8 × 4.89 ÷ 8 = 9.05GB(Ollama 실제 파일 9.3GB)입니다. KV 캐시는 2 × 40 × 8 × 128 × 2 × 32,768 ÷ 10⁹ = 5.37GB입니다. 합계는 9.3 + 5.37 + 1.0 = 15.7GB로 16GB에 들어가지만 여유가 0.3GB뿐입니다. 캐시를 q8_0으로 바꾸면 KV가 약 2.68GB가 되어 합계 13.0GB로 내려갑니다.

예시 2: 32B를 24GB 카드에서 어디까지

가중치 20GB에 여유 1.0GB를 빼면 KV 캐시에 쓸 수 있는 공간은 3GB입니다. Qwen3 32B는 토큰당 256KiB(262,144바이트)라, 3 × 10⁹ ÷ 262,144 ≈ 11,444토큰이 f16 캐시의 한계입니다. q8_0으로 줄이면 약 두 배인 2만 2천 토큰 남짓까지 늘어납니다. 긴 문서를 넣을 계획이라면 24GB에서도 캐시 양자화가 사실상 필요하다는 뜻입니다.

이런 사람은 비추합니다

클라우드 AI 서비스로 충분한 사람이 로컬 LLM용으로 고가 그래픽카드를 사는 것은 권하지 않습니다. 이 글의 계산대로라면 일반 소비자용 카드 한 장으로 다룰 수 있는 범위는 32B급까지이고, 70B급은 4비트로도 가중치만 43GB입니다. 또 8GB 카드로 로컬 LLM을 본격적으로 시작하려는 경우도 비추입니다. 8B 모델을 8K 대화로 올리는 데 7.4GB가 필요해 여유가 거의 없고, 대화를 늘리거나 더 큰 모델로 옮기는 순간 시스템 메모리로 넘어가 속도가 크게 떨어집니다. 게임과 겸용으로 고른다면 게임 쪽 기준은 따로 있으니 게임 그래픽 설정 최적화 글도 함께 참고하세요.

체크리스트

1. 쓰려는 모델의 파라미터 수와 형식(Q4_K_M, Q8_0 등)을 확인했는가
2. 가중치 = 파라미터(10억) × bpw ÷ 8로 계산했는가(Q4_K_M은 10억 개당 0.61GB)
3. 실제로 쓸 대화 길이(4K, 8K, 32K)로 KV 캐시를 계산했는가
4. 여유분 1GB 안팎과 화면 출력 몫을 더했는가
5. 합계가 VRAM의 90% 안쪽인가(넘으면 캐시 양자화나 작은 형식을 검토)
6. MoE 모델이라면 메모리는 전체 파라미터 기준으로 잡았는가
7. 모델이 VRAM에 다 들어가는 조건에서 대역폭을 비교했는가
8. AMD 카드라면 사용할 도구의 ROCm·Vulkan 지원과 드라이버 요구 사항을 확인했는가

정리

로컬 LLM VRAM은 계산으로 답할 수 있는 문제입니다. 가중치는 파라미터 수 × bpw ÷ 8로 실제 파일 크기와 4% 안쪽으로 맞았고, KV 캐시는 모델 설정 파일의 세 값으로 대화 길이에 비례해 늘어납니다. 4비트·8K 대화 기준으로 8GB는 8B급, 12GB는 14B급, 16GB는 14B급을 긴 대화로, 24GB는 32B급, 32GB는 32B급을 긴 대화로 쓰는 구간이고, 70B급은 카드 한 장의 범위를 벗어납니다.

그래픽카드를 고를 때는 순서가 중요합니다. 먼저 쓰려는 가장 큰 모델과 대화 길이로 필요 VRAM을 계산하고, 그 용량을 갖춘 카드들 사이에서 대역폭을 비교합니다. 모델이 VRAM을 넘치면 RAM이 속도를 정하기 때문에, 그 상태에서 더 비싼 카드를 고르는 것은 효과가 작습니다. 용량이 먼저, 대역폭이 그다음입니다.