로컬 코딩 모델, 내 GPU엔 얼마의 VRAM이 필요한가?

로컬 코딩 보조 모델의 VRAM은 '두 얼굴'이라, 커서 옆 자동완성용 작은 FIM 모델과 채팅·에이전트용 큰 모델이 서로 다른 예산을 쓴다. 실측 핵심 셋: ① Q4 기준 대략 1B당 0.5~0.6GB라 Qwen2.5-Coder 7B 약 5GB(8GB), 14B 약 8.7GB(12GB), 32B 18~20GB(24GB)다. ② 코딩의 진짜 킬러는 긴 문맥이다 — 파일·레포를 담으려면 문맥이 커지고 KV 캐시가 폭증하는데, Ollama 기본 2048토큰은 500줄 파일도 못 담는다. ③ 코드는 문법에 민감해 일반 채팅보다 양자화를 더 조심해야 한다(괄호·따옴표 하나가 출력을 깬다). 즉 코딩 VRAM은 '모델 크기'만이 아니라 용도·문맥·양자화 급으로 정해진다.

한 줄 요약: 코딩 VRAM은 모델 크기만이 아니라 용도(FIM vs 채팅)·문맥 길이·양자화 급으로 정해진다 — Q4에서 1B당 약 0.5~0.6GB, 코딩은 Q5+가 안전선이다.

쉽게 말하면: 코딩 보조는 운전 보조 두 종류다. 하나는 차선을 실시간으로 잡아주는 '즉답 보조'(작은 FIM 모델, 상시 켜짐), 다른 하나는 길을 통째로 짜주는 '내비 상담'(큰 모델). 둘은 필요 순간도, 먹는 자원도 다르다.

코딩 모델 VRAM은 왜 두 얼굴인가?#

자동완성(FIM)과 채팅/에이전트가 다른 일이기 때문이다. 커서 앞뒤를 보고 중간을 채우는 FIM(fill-in-the-middle)은 저지연이 생명이라 작고 빠른 모델(7B급, 상주)이 맞다 — Codestral은 FIM 특화로 측정상 95.3% FIM 정확도다. 반대로 멀티파일 리팩터·에이전트는 크고 문맥 긴 모델(14~32B)이 맞다. 그래서 Continue.dev 같은 IDE 통합은 자동완성 모델과 채팅 모델을 따로 지정한다(둘, 두 목적). VRAM이 넉넉하면 둘을 동시에 올려 각자 상주시킨다.

문맥이 왜 코딩에서 킬러인가?#

파일·레포를 담으려면 문맥이 커지고 KV 캐시가 선형으로 늘기 때문이다. 실측: 14B를 Q4로 올려도 32K 문맥 + q8 KV 캐시면 총 약 14GB로 16GB 천장에 붙는다. 128K를 켜면 KV가 몇 GB 더 붙는다. 그런데 Ollama 기본 문맥은 2048토큰이라 500줄 파이썬 파일도 못 담아, '레포를 안다'는 착각만 준다 — 반드시 키워야 한다. 문맥이 부족하면 ①문맥창을 줄이거나 ②KV를 q4로 양자화(긴 문맥서 품질 손실)하거나 ③작은 모델로 내린다. Qwen2.5-Coder는 128K를 지원하니 문맥부터 열어라.

왜 코드는 양자화를 더 조심해야 하나?#

코드는 문법에 민감해 작은 오차가 출력을 깨기 때문이다. 일반 채팅은 Q4로 충분하지만, 코딩은 괄호·따옴표 하나가 실행을 망친다. 그래서 급이 다르다: Q4_K_M은 채팅·간단 생성엔 쓸 만하되 복잡 함수에서 가끔 문법 실수, Q5_K_M이 실무 코딩의 권장 최소, 멀티파일 리팩터·에이전트는 Q6/Q8을 강권한다. 즉 일반 LLM에선 Q4가 기본이지만 코딩은 한 단계 위(Q5+)가 안전선이다. 남는 VRAM은 문맥과 이 '한 단계 위'에 쓰는 게 이득이다.

내 GPU엔 뭐가 들어가나?#

핵심은 용도·문맥·양자화 급을 함께 잡는 것이다.

• 8GB: Qwen2.5-Coder 7B(자동완성·간단 채팅). 문맥은 넉넉히, 양자화는 Q5 지향.
• 12~16GB: 14B가 기본(속도·품질 균형), 32K 문맥이면 KV 포함 16GB에 근접.
• 24GB: 32B(채팅)+Codestral(FIM) 듀얼 또는 큰 문맥. 정확한 값은 내 파일 크기·문맥으로 직접 재라.

함께 읽기: 에이전트 브라우저 제어, 직접 써보고 느낀 점과 한계, 오픈 음성 클로닝 파이프라인 — 우리는 이렇게 운영한다

함께 읽기: 로컬 음성합성(TTS) 오픈모델 — VRAM·RAM 요구량 실측, Ollama·LM Studio·llama.cpp 실행기 VRAM·RAM 실측

참고 링크

• Qwen2.5-Coder(코딩 모델·FIM)
• Continue.dev(IDE 통합·자동완성+채팅)
• DeepSeek-Coder(다국어 코딩)
• Ollama(로컬 런타임·문맥 설정)
• llama.cpp(GGUF·KV 캐시 양자화)

참고: GB 수치는 2026년 공개 측정 기준이며 총 사용량은 문맥·KV 정밀도·양자화·워크플로에 따라 달라진다(영구 수치 아님). Qwen3-Coder·DeepSeek V3 등 신모델이 나왔으나 자동완성·채팅엔 Qwen2.5-Coder·Codestral이 여전히 무난하다. 정확한 메모리는 내 파일·문맥·양자화로 직접 재라(여기 수치는 출발점). 코딩 모델은 빠르게 바뀌니 분기별로 다시 본다.