로컬 LLM이 GPU 메모리에 안 들어갈 때 쓰는 세 가지 방법을 실측 수치로 정리했습니다. Q4_K_S 양자화 70.83% 절감, KV 캐시 q8_0 절반, llama.cpp –n-cpu-moe 옵션까지 단계별 적용 순서를 안내합니다.
로컬 LLM 메모리 부족, 시작 전 확인할 것
모델이 GPU 메모리에 안 들어갈 때 손댈 순서는 ① 컨텍스트 길이 → ② 양자화 등급 → ③ KV 캐시 자료형 → ④ MoE 오프로딩입니다. 그래픽카드를 새로 사는 것은 이 네 가지를 다 해본 뒤에 판단할 문제입니다. 근거가 되는 수치를 하나 먼저 보겠습니다. Llama-3.1-8B-Instruct를 13개 GGUF 양자화로 비교한 독립 평가에서 FP16 15,317 MiB가 Q4_K_S에서 4,468 MiB로 70.83% 줄었고, 다운스트림 평균 점수는 69.47%에서 69.17%로 0.3%p만 떨어졌습니다(arXiv 2601.14277, 2026-01-11 게재). 이 글은 llama.cpp와 Ollama 두 실행기를 기준으로 메모리를 줄이는 절차와 각 단계에서 실제로 잃는 것을 정리했습니다. 클라우드 API 전환이나 GPU 구매 가이드는 다루지 않습니다.
전제조건은 세 가지입니다. 첫째, 자신의 모델이 덴스(dense)인지 MoE인지 알아야 합니다. 4단계 MoE 오프로딩은 활성 파라미터가 총 파라미터보다 훨씬 작은 구조에서만 이득이 있습니다. gpt-oss-20b는 총 21B 중 활성 3.6B이고, Gemma 4의 26B-A4B도 같은 계열입니다. 덴스 모델에 이 옵션을 걸면 얻는 게 없습니다.
둘째, 현재 GPU 메모리가 몇 GiB인지 정확히 알아야 합니다. Ollama는 VRAM 구간에 따라 기본 컨텍스트를 다르게 잡습니다 — 24 GiB 미만이면 4k, 24-48 GiB면 32k, 48 GiB 이상이면 256k입니다(docs.ollama.com/context-length, 2026-08-30 확인). 24 GiB 미만 카드에서 “컨텍스트가 짧다”고 느꼈다면 그건 모델 한계가 아니라 기본값 문제입니다.
셋째, 메모리 부족이 실제로 어디서 나는지 진단해야 합니다. Ollama에서는 ollama ps의 processor 열이 100% GPU, 100% CPU, 48%/52% CPU/GPU처럼 분할 상태를 보여줍니다. 여기서 CPU 비중이 잡혀 있으면 이미 일부가 시스템 메모리로 밀려난 상태입니다.
용어 풀이
1. 양자화(quantization) — 모델 가중치를 16비트 대신 4~5비트 같은 낮은 정밀도로 저장해 메모리를 줄이는 기법.
2. KV 캐시 — 생성 중 앞선 토큰의 키·값 벡터를 저장해두는 영역으로, 컨텍스트가 길수록 커지는 메모리 항목.
3. MoE(Mixture of Experts) — 전체 파라미터 중 일부 전문가 블록만 토큰마다 활성화하는 구조로, 총 크기보다 실제 연산량이 작다.
4. GGUF — llama.cpp 계열이 쓰는 양자화 모델 파일 형식.
준비물·필요 서류
작업 전 확보해야 할 항목을 표로 정리했습니다. 서류가 아니라 환경 정보와 선택지 목록이라고 보시면 됩니다.
| 구분 | 항목 | 확인 방법·값 |
|---|---|---|
| 하드웨어 | GPU VRAM 용량 | 또는 시스템 정보. Ollama 기본 컨텍스트 분기점이 24·48 GiB |
| 하드웨어 | 시스템 RAM | MoE 오프로딩·CPU 폴백 시 여기로 내려간다 |
| 실행기 | llama.cpp | , , --cache-type-k/v 사용 |
| 실행기 | Ollama | OLLAMA_KV_CACHE_TYPE, 컨텍스트 길이 설정 사용 |
| 모델 정보 | 아키텍처 | 덴스 / MoE 구분 (MoE만 4단계 적용) |
| 모델 정보 | 양자화 등급 | Q5_0 · Q4_K_S · Q3_K_S 등 |
| 진단 | 현재 적재 상태 | ollama ps의 processor 열 |
모델별 실제 메모리 수치를 미리 알아두면 시행착오가 줄어듭니다. Google 공식 표(ai.google.dev/gemma/docs/core) 기준 Gemma 4의 Q4_0 메모리는 E2B 2.9 GB, E4B 4.5 GB, 12B 6.7 GB, 26B-A4B 14.4 GB, 31B 17.5 GB입니다. 같은 모델의 BF16은 각각 11.4 / 17.9 / 26.7 / 57.7 / 69.9 GB입니다. 12B 모델이 26.7 GB에서 6.7 GB로 내려가는 것이 4비트 양자화의 실질 효과입니다.
이전 세대인 Gemma 3의 QAT int4 수치도 참고가 됩니다(2025-04-18 Google Developers Blog). 27B 54 GB → 14.1 GB, 12B 24 → 6.6 GB, 4B 8 → 2.6 GB, 1B 2 → 0.5 GB입니다.
다만 주의할 점이 하나 있습니다. 이 표의 수치는 가중치만 계산한 값입니다. KV 캐시와 프레임워크 오버헤드로 10~20% 여유가 더 필요하다는 것이 배포자 권고입니다. Gemma 4 31B의 Q4_0 17.5 GB를 18 GB 카드에 넣으려는 계획은 실패하기 쉽습니다.
OpenAI의 gpt-oss-20b는 MoE 레이어가 MXFP4로 네이티브 양자화돼 16 GB 메모리에서 동작한다고 공식 발표했습니다. 다만 이 수치에는 컨텍스트 조건이 명시돼 있지 않으니, 짧은 컨텍스트 전제로 읽는 편이 안전합니다.
단계별 진행 순서
1단계 — 컨텍스트 길이부터 조정 (소요 1분)
가장 먼저 손댈 곳은 모델이 아니라 대화 길이 설정입니다. Ollama 공식 문서는 컨텍스트를 늘리면 필요 메모리가 함께 는다고 명시하고 있고, 반대로 줄이면 그만큼 회수됩니다. 24 GiB 미만 카드는 기본 4k가 잡히므로, 여기서 128k로 올려놓고 OOM이 났다면 원인은 명확합니다. 요약이나 코드베이스 분석처럼 긴 입력이 필수인 작업에서는 이 단계를 건너뛰어야 합니다.
2단계 — 양자화 등급 낮추기 (소요 10~30분, 모델 재다운로드 시간 포함)
메모리를 가장 크게 줄이는 단계입니다. 독립 평가(arXiv 2601.14277)의 실측을 그대로 옮기면 다음과 같습니다.
| 양자화 | 크기 | 감소율 | perplexity | 다운스트림 평균 | 생성 속도 |
|---|---|---|---|---|---|
| FP16 | 15,317 MiB | 기준 | 7.32 | 69.47% | 2.83 tok/s |
| Q5_0 | — | — | 7.43 | — | 6.66 tok/s |
| Q4_K_S | 4,468 MiB | 70.83% | — | 69.17% | — |
| Q3_K_S | 3,487 MiB | 77.23% | 8.96 | 65.49% | 9.91 tok/s |
해당 논문 저자의 권고는 정확도 우선이면 Q5_0, 압축 우선이면 Q4_K_S입니다. Q3_K_S는 크기가 7% 더 줄어드는 대신 평균 점수가 4%p 가까이 떨어지므로 교환비가 나쁩니다. 다만 이 수치는 Llama-3.1-8B-Instruct 한 체크포인트 실험이라, 다른 모델에서 그대로 재현된다는 보장은 없습니다.
3단계 — KV 캐시 자료형 변경 (소요 5분)
llama.cpp는 / 로 지정하며 기본값은 f16, 선택지는 f32·f16·bf16·q8_0·q4_0·q4_1·iq4_nl·q5_0·q5_1입니다. Ollama는 OLLAMA_KV_CACHE_TYPE으로 같은 일을 하며 공식 문서 기준 q8_0이 절반, q4_0이 4분의 1 메모리입니다.
여기가 이 글에서 가장 강조하고 싶은 주의 지점입니다. Ollama 공식 문서는 메모리 절감만 언급하고 품질은 말하지 않습니다. 그런데 독립 논문(arXiv 2606.09864 v2, 2026-08-11)이 11개 instruction-tuned 모델·5개 벤치마크·1,894 프롬프트로 평가한 결과, Mistral-7B에서 perplexity가 1.03배 변화하는 데 그쳤는데도 거부율(refusal)이 15.2% 손실됐습니다. 논문이 제안한 완화책 PCR의 복구율은 초록 기준 최대 97.2%, 검색 요약 기준 0%(LLaMA)~97%(Qwen)로 자료마다 어긋나 양쪽을 병기합니다. 정리하면 q8_0은 무난하되, 안전 정렬이 걸린 워크로드에서 q4_0은 자체 검증 없이 쓰지 않는 편이 좋습니다.
4단계 — MoE 전문가만 CPU로 내리기 (소요 10분, MoE 모델만)
llama.cpp의 --n-cpu-moe N은 앞쪽 N개 레이어의 MoE 가중치만 CPU에 두고 어텐션은 GPU에 남깁니다. 전부 내리는 극단값은 입니다. 모델을 작게 만드는 게 아니라 배치만 바꾸는 방식이라 품질 손실이 없다는 것이 장점입니다. 참고로 는 정수 외에 ·을 받고 기본값이 이며, 은 기본 비활성입니다. 이 방법은 덴스 모델에는 무의미합니다.
5단계 — Ollama 버전 확인 (소요 2분)
Ollama는 2025-09-23 발표에서 추정 대신 실제 필요 메모리를 측정하는 새 스케줄링을 도입했습니다. 공식 발표의 실측 예로 RTX 4090·gemma3:12b·128k 컨텍스트에서 52.02 → 85.54 tok/s, VRAM 19.9 → 21.4 GiB, GPU 적재 레이어 48/49 → 49/49가 제시됐습니다. 구버전을 쓰고 있다면 업데이트만으로 개선될 여지가 있습니다.
자주 놓치는 부분
공식 발표 수치를 조건 없이 믿는 것이 첫 번째 함정입니다. gpt-oss-20b의 “16 GB”에는 컨텍스트 조건이 붙어 있지 않고, Gemma 4 31B의 “Q4_0 17.5 GB”는 가중치만의 값입니다. 두 수치 모두 틀린 게 아니라 전제가 생략됐을 뿐입니다. 카드 용량과 딱 맞아떨어지는 계획이라면 여유분 10~20%를 얹어 다시 계산하시기 바랍니다.
perplexity가 정상이면 품질도 정상이라는 가정이 두 번째입니다. 앞서 인용한 정렬 붕괴 논문의 핵심이 정확히 이 지점입니다. perplexity 1.03배는 사실상 변화 없음에 가까운 수치인데 거부율은 15.2%가 사라졌습니다. 지표 하나로 검증을 끝내지 않아야 합니다.
아직 병합되지 않은 기능을 계획에 넣는 것이 세 번째입니다. llama.cpp의 MoE 전문가 캐싱 PR #26824는 저자 측정으로 Qwen 35B-IQ2_M(12GB) 1.57배, Gemma 26B-Q5_K_S(18GB) 2.19배, Qwen 122B-IQ2_M(29GB) 1.74배 디코드 향상을 보고했습니다. 하지만 프롬프트 처리가 일부 구성에서 3~4배 느려졌고, 2026-08-10 기준 closed(미병합) 상태입니다. 선행 PR #26563( 플래그)도 8GB VRAM·Qwen3.6-35B에서 Q2_M 33→56 tok/s, Q5_K_P 17.34→35.93 tok/s를 보고했으나 단일 토큰 디코드에만 걸리고 CUDA 전용이며 역시 종료됐습니다. Ollama의 TurboQuant KV 캐시 PR #15090은 256k 컨텍스트 총 메모리를 16-17 GiB에서 8-9 GiB로 줄인다고 보고하지만(tq2가 F16 대비 65% 절감, 7.9 vs 22.3 GiB), 2026-08-30 확인 시점에 open 상태로 미병합이며 마지막 주요 커밋이 2026-05-02입니다. 벤치마크 숫자가 돌아다닌다고 지금 쓸 수 있는 기능은 아닙니다.
마케팅 문구의 방향을 잘못 읽는 것이 네 번째입니다. Unsloth Dynamic 3.0 GGUF는 같은 크기에서 다른 공급자 대비 top-1% 정확도 10% 이상 향상을 주장합니다. 그런데 자사 Aider Polyglot 표를 보면 UD-Q4_K_XL 387 GB에서 69.7%, 표준 Q4_K_M 405 GB에서 69.7%로 정확도는 동점이고 실제 이득은 18 GB 작다는 쪽입니다. 이 주장이 어떤 모델·어떤 baseline 대비인지는 문서에 조건이 흩어져 있어 단일 조건으로 재현하지 못했습니다(확인 필요).
용량 문제와 속도 문제를 하나로 묶는 것이 마지막입니다. 통합 메모리 하드웨어는 용량은 풀지만 속도는 남깁니다. LMSYS의 DGX Spark 실측(128 GB 통합 메모리, 대역폭 273 GB/s)에서 Llama 3.1 70B FP8 디코드는 2.7 tok/s에 그쳤고, 같은 장비의 gpt-oss-20B MXFP4·Ollama 배치 1은 49.7 tok/s(prefill 2,053)였습니다. Llama 3.1 8B FP8·SGLang은 배치 1에서 20.5 tok/s(prefill 7,991), 배치 32에서 368 tok/s입니다. 참고로 DGX Spark의 공식 가격은 유통 기사에 $4,699로 나오나 공식 가격표 원문을 확인하지 못했습니다(확인 필요 — T1 미확인).
용어 풀이
1. perplexity — 모델이 다음 토큰을 얼마나 잘 맞추는지 나타내는 지표로, 낮을수록 좋지만 안전성 같은 다른 품질까지 대변하지는 않는다.
2. QAT(Quantization Aware Training) — 훈련 단계에서 양자화를 미리 시뮬레이션해 같은 비트수에서 손실을 줄이는 방식.
3. prefill / decode — 입력 프롬프트를 한 번에 처리하는 구간과 토큰을 하나씩 생성하는 구간으로, 병목 지점이 서로 다르다.
체크리스트 정리
- 모델 구조 확인 — 덴스인지 MoE인지 먼저 판별한다. MoE가 아니면 는 건너뛴다.
- 컨텍스트 길이 점검 — VRAM 24 GiB 미만이면 Ollama 기본이 4k다. 필요 이상으로 올려놓지 않았는지 확인한다.
- 양자화 등급 선택 — 정확도 우선 Q5_0, 압축 우선 Q4_K_S. Q3_K_S는 다운스트림 평균이 65.49%로 떨어지므로 마지막 수단이다.
- 가중치 표에 여유분 가산 — 공식 메모리 표는 가중치만의 값이므로 10~20%를 더한 뒤 카드 용량과 비교한다.
- KV 캐시는 q8_0까지 — 절반으로 줄어든다. q4_0은 거부율 손실 사례가 보고됐으므로 자체 검증 후 적용한다.
- 적재 상태 재확인 —
ollama ps의 processor 열이100% GPU인지 본다. CPU 비중이 남아 있으면 아직 덜 줄인 것이다. - 미병합 기능 배제 — (closed), TurboQuant
tq3/tq4(open)는 2026-08-30 기준 사용 불가이므로 계획에서 뺀다.
전체 판단 기준을 한 줄로 압축하면 이렇습니다. 모델이 VRAM의 1.5배 이내면 양자화로, MoE이면서 2~4배면 전문가 오프로딩으로, 덴스이면서 4배 이상이면 하드웨어를 바꾸거나 모델 자체를 바꾸는 편이 현실적입니다.
참고 자료
조사 기준일: 2026년 08월 30일
본문의 수치는 아래 자료에서 확인한 것입니다. 제조사 공식 자료(T1)와 전문 매체 실측(T2)을 구분해 표기했습니다. 가격·공급 상황은 변동이 크므로 기준일 이후의 값은 다시 확인해야 합니다.
Tier 1 (2026-08-30 확인)
– llama.cpp server README — https://github.com/ggml-org/llama.cpp/blob/master/tools/server/README.md
– llama.cpp CLI README — https://github.com/ggml-org/llama.cpp/blob/master/tools/cli/README.md
– Ollama FAQ — https://docs.ollama.com/faq
– Ollama Context length — https://docs.ollama.com/context-length
– Ollama, New model scheduling (2025-09-23) — https://ollama.com/blog/new-model-scheduling
– Google Developers Blog, Gemma 3 QAT (2025-04-18) — https://developers.googleblog.com/en/gemma-3-quantized-aware-trained-state-of-the-art-ai-to-consumer-gpus/
– Google AI for Developers, Gemma 4 model overview — https://ai.google.dev/gemma/docs/core
– OpenAI, Introducing gpt-oss — https://openai.com/index/introducing-gpt-oss/
– Unsloth Docs, Dynamic 3.0 GGUFs — https://unsloth.ai/docs/basics/dynamic-3.0-ggufs
– Unsloth Docs, Dynamic GGUFs on Aider Polyglot — https://unsloth.ai/docs/basics/dynamic-3.0-ggufs/unsloth-dynamic-ggufs-on-aider-polyglot
Tier 2 (2026-08-30 확인)
– arXiv 2601.14277, Which Quantization Should I Use? A Unified Evaluation of llama.cpp Quantization on Llama-3.1-8B-Instruct — https://arxiv.org/html/2601.14277v1
– arXiv 2606.09864 v2, Alignment Collapse Under KV Cache Quantization: Diagnosis and Mitigation — https://arxiv.org/abs/2606.09864
– LMSYS Org, NVIDIA DGX Spark In-Depth Review — https://www.lmsys.org/blog/2025-10-13-nvidia-dgx-spark/
– GitHub, llama.cpp PR #26824 (expert caching, closed) — https://github.com/ggml-org/llama.cpp/pull/26824
– GitHub, llama.cpp PR #26563 (, closed) — https://github.com/ggml-org/llama.cpp/pull/26563
– GitHub, ollama PR #15090 (TurboQuant KV cache, open) — https://github.com/ollama/ollama/pull/15090
– Tom’s Hardware RAM price index 및 “32GB of DDR5 now costs $375 minimum” — 본문 미반환
– OpenBenchmarking.org llama.cpp 테스트 프로파일 — HTTP 403
– OpenReview BqKhzrtkGe — 브라우저 검증 페이지
– qwenlm.github.io/blog/qwen3.5/ — HTTP 404
답글 남기기