로컬 오픈 LLM, 흔한 함정과 해결법

로컬 오픈 LLM을 돌리다 "이 모델 왜 이렇게 멍청하지/느리지/자꾸 터지지" 싶을 때, 2026년의 진실은 대부분 모델 탓이 아니라 '기본값(defaults)' 탓이라는 것으로, 실행기(Ollama·llama.cpp)를 켤 때 네가 설정하거나 방치한 파라미터가 모델·양자화 선택보다 실제 성능에 더 크게 작용하며, 가장 자주 놓치는 한 가지는 VRAM을 터뜨리는 진짜 범인이 '가중치'가 아니라 'KV 캐시'라는 것이다 — 이 글은 로컬 LLM에서 반복되는 함정을 증상 → 원인 → 해결 순으로 수치와 함께 정리한다.

쉽게 말하면: 로컬 LLM 튜닝은 새 차의 옵션 세팅과 같다. 엔진(모델)이 좋아도 사이드미러가 접혀 있고(문맥 2048) 트렁크에 짐을 가득(KV 캐시 선할당) 실어 두면 잘 못 달린다. "차가 구리다(모델이 멍청하다)"고 탓하기 전에 계기판 기본값부터 봐야 한다.

왜 로컬 LLM이 갑자기 멍청해지나?#

대개 문맥 창이 기본값 그대로거나 채팅 템플릿이 안 맞아서다 — 모델 지능 문제가 아니다. Ollama는 num_ctx 기본이 2,048 토큰이라, 대화가 길어지면 앞부분을 소리 없이 버린다 — "5메시지 전 말을 무시한다"는 증상이 바로 이것이다. 해결은 실행기 설정에서 문맥 창을 실제 필요량으로 올리는 것이다. 두 번째 흔한 원인은 채팅 템플릿 불일치다. Qwen·Yi·Mistral 계열은 ChatML, Llama 3는 전용 헤더 토큰 포맷을 쓰는데, GGUF를 직접 로드하면서 포맷을 틀리면 시스템 프롬프트를 통째로 무시하거나 사용자 메시지를 assistant 응답의 일부로 오인한다. --chat-template(llama.cpp)·Modelfile TEMPLATE를 모델에 맞게 지정하라.

VRAM이 터지는 진짜 원인은 무엇인가?#

가중치가 아니라 KV 캐시다 — 이게 소비자 하드웨어에서 문맥 길이를 실제로 제한한다. KV 캐시는 시작 시점에 전체 창만큼 미리 예약된다: --ctx-size 65536이면 실제 프롬프트가 200토큰이어도 즉시 65,536토큰치 메모리를 잡는다. 아래가 그 선할당 함정이다 — 짧은 프롬프트여도 예약은 전체 창이다.

그래서 첫 해결은 문맥을 VRAM에 맞추는 것: 8GB는 32k가 안전, 12GB는 코딩 64k, 128k 장문 RAG는 여유 필요. 다음 최고 레버리지는 KV 캐시 양자화다 — f16 → q8_0로 바꾸면 12GB·64k에서 약 2GB가 풀려 GPU 레이어를 1~2개 더 올릴 수 있고, 그만큼 토큰 속도가 오른다(Ollama OLLAMA_KV_CACHE_TYPE, llama.cpp --cache-type-k/-v). 아래가 '가중치 vs KV 캐시'의 실제 VRAM 구성이다.

가중치는 Q4_K_M이 기본값 — 75% 작아지고 품질 손실은 거의 없다. 단 Q2/Q3는 급락하고, 이미 양자화된 걸 다시 양자화(Q8→Q4)하면 오차가 누적되니 금지다.

느린데 GPU는 놀고 있다면?#

GPU 20~30%는 '유휴'가 아니라 '메모리 대역폭 병목'이다 — 가장 흔한 오진이다. llama.cpp 추론에서 GPU 코어는 배치를 빨리 끝내고 다음 가중치·캐시가 도착하길 기다린다 — 그래서 낮은 사용률이 뜬다. 속도를 짜내려 하기 전에 먼저 KV 캐시가 양자화됐는지, VRAM이 한계인지 확인하라. 켤 것 두 가지: (1) Flash Attention — 어텐션 행렬을 통째로 만들지 않아 메모리가 O(n²)→O(n)으로 줄고 더 빠르다(--flash-attn·OLLAMA_FLASH_ATTENTION=1, Vulkan은 드라이버별 확인). (2) prefill 배치 상향 — 기본 512에서 16,000토큰 프롬프트는 32번 패스지만, 2048로 올리면 8번으로 준다. 아래가 그 패스 수 축소다.

주의: KV 양자화가 항상 공짜는 아니다 — Gemma 3는 Q8_0 KV에서 GPU가 20~30%로 급락(CPU 100%)하는 반면 동급 Qwen은 멀쩡하다. K-캐시 과양자화는 코딩 에이전트에서 툴콜·diff 오류를 부르니, 실제 서빙 문맥 길이로 모델별 테스트가 답이다.

그래서 안전한 기본 세팅은?#

핵심은 최댓값으로 밀지 말고, 네 병목(연산·VRAM·대역폭·CPU)을 먼저 파악하는 것이다.

• 가중치: Q4_K_M 기본(여유 있으면 Q5_K_M/Q6_K). 수학·코드는 Q5 이상으로. Q2/Q3·재양자화 금지, GGUF↔GPTQ↔AWQ 포맷 비호환 주의.
• 문맥·메모리: 문맥을 VRAM에 맞추고(8GB=32k), KV 캐시 양자화(q8_0) + Flash Attention을 켜라. 진짜 병목은 가중치가 아니라 KV 캐시.
• 속도: prefill batch 2048, GPU 저활용은 대역폭 병목일 뿐. 모든 세팅은 실제 문맥 길이·모델로 A/B 후 고정.

함께 읽기: 로컬 LLM, VRAM은 얼마나 필요할까, 로컬 코딩 보조 모델 2026: 직접 돌려보고 고른 현황과 추천

함께 읽기: 로컬 오픈 LLM VRAM·RAM 요구량, 직접 계산·실측, 4bit·8bit 양자화, 5분 시작 가이드(초보자용)

참고 링크

• llama.cpp(로컬 추론·플래그)
• Ollama(로컬 실행기·환경변수)
• FlashAttention(O(n²)→O(n) 어텐션)
• k-quants 도입 PR(GGUF Q4_K_M 등)
• Ollama KV 캐시 양자화 이슈

참고: num_ctx 기본(2048)·문맥 권장(8GB 32k/12GB 64k)·KV 절약(~2GB)·batch 효과(2~3배)·양자화 감소폭(75%) 같은 수치는 2026년 공개·커뮤니티 실측이며 모델·실행기·드라이버·하드웨어에 따라 달라진다(영구 수치 아님). KV 양자화 품질 영향은 모델별로 크게 다르고(예: Gemma 3), 플래그·기본값은 실행기 버전마다 바뀐다. 설정 후에는 반드시 실제 문맥 길이로 검증하라. 실행기·양자화 관행은 빠르게 바뀌니 분기별로 다시 본다.