로컬 LLM 운영 — GGUF · 양자화 · VRAM 산정과 도입 판단

로컬 LLM 도입 논의는 대개 "API보다 싸다"에서 시작하는데, 손익분기 계산에 운영 인건비를 넣는 순간 그 전제가 무너지는 경우가 많다. GPU 하드웨어 비용보다 이걸 관리할 사람의 비용이 큰 조직이 흔하기 때문이다.

이 글은 로컬 LLM을 기술이 아니라 판단 문제로 다룬다. 어떤 조건에서 로컬이 옳은지에서 시작해, GGUF 파일 형식과 양자화 등급, VRAM 산정 공식, Ollama 운영과 그 보안 함정, 그리고 도입 여부를 가르는 체크리스트까지 이어진다. 토큰 비용 구조에서 다룬 변동비 문제의 다른 해법에 해당한다.

용어 정리

왜 로컬 LLM인가

이 판단의 출발점은 기술이 아니라 비용 구조와 통제권이다.

로컬 LLM은 "싸게 하려고" 쓰는 게 아니다. 데이터를 밖으로 못 내보내거나, 변동비를 고정비로 바꿔야 할 때 쓴다. 이 둘 중 어느 것도 해당하지 않으면 클라우드 API가 거의 항상 옳다.

GGML에서 GGUF로

GGUF와 GGML은 추론용 모델을 저장하는 파일 형식이다.

GGML은 머신러닝을 위해 설계된 텐서 라이브러리로, Apple Silicon을 비롯한 다양한 하드웨어에서 대규모 모델을 돌릴 수 있게 했다.

GGUF는 2023년 8월 21일 GGML의 후속으로 도입됐다. 마지막 단점이 결정적이었다 — 하이퍼파라미터를 손으로 맞추던 문제를 메타데이터를 파일에 내장해 없앴다.

양자화 등급 — VRAM을 결정하는 변수

GGUF 파일명의 Q5_K_M 같은 접미사가 양자화 등급이다.

7B 파라미터 모델 기준 등급별 비교다.

선택 규칙: Q4_K_M부터 시작하고, 품질이 부족하면 Q5_K_M으로, VRAM이 부족하면 Q4_K_S로 이동한다. Q3 이하는 품질 저하가 체감될 정도라 프로덕션 후보가 되기 어렵다.

위 크기·품질 값은 GGUF 생태계의 통용 기준이다.

"양자화하면 성능은 그대로"라는 인식은 틀렸다. 손실은 분명히 있고, Q4_K_M이 실무에서 합의된 균형점이라는 것이 정확한 표현이다.

Ollama 운영

Ollama는 로컬 LLM을 CLI와 HTTP 서버로 구동하는 런타임이다. 로컬 LLM 실행에서 docker run에 해당하는 위치를 차지한다.

한국어 특화 오픈 모델로는 yanolja/EEVE-Korean-Instruct-10.8B-v1.0 계열이 쓰인다. 원본 가중치는 HuggingFace에 safetensors로 올라오고, 커뮤니티가 이를 GGUF로 변환해 배포하는 것이 일반적인 유통 경로다.

Modelfile — 로컬 LLM의 Dockerfile

FROM ggml-model-Q5_K_M.gguf

TEMPLATE """{{- if .System }}
<s>{{ .System }}</s>
{{- end }}
<s>Human:
{{ .Prompt }}</s>
<s>Assistant:
"""

SYSTEM """A chat between a curious user and an artificial 
intelligence assistant. The assistant gives helpful, 
detailed, and polite answers to the user's questions."""

PARAMETER stop <s>
PARAMETER stop </s>

TEMPLATE이 조용한 실패 지점이다. 형식이 어긋나도 에러가 나지 않고 품질만 떨어지기 때문에 모델이 나쁘다고 오진하기 쉽다.

엔드포인트 노출 — 통제 목적을 스스로 무너뜨리는 지점

OLLAMA_MODELS=~/.ollama/models OLLAMA_HOST=127.0.0.1:11434 ollama serve

OLLAMA_HOST를 0.0.0.0으로 열면 인증 없이 사내 누구나 호출할 수 있는 LLM 엔드포인트가 된다.

로컬 LLM을 도입한 이유가 "데이터 반출 통제"인데 엔드포인트를 무인증으로 열면 통제 목적 자체가 무너진다. 리버스 프록시 + 인증 + 호출 로깅을 반드시 앞단에 둔다.

VRAM 산정

가중치 VRAM (GB) ≈ 파라미터 수(B) × (양자화 비트 ÷ 8)

KV 캐시 VRAM (GB) ≈ 2 × 레이어 수 × 히든 차원 × 컨텍스트 길이 × 배치 × 정밀도 바이트 ÷ 1024^3

총 VRAM ≈ (가중치 + KV 캐시) × 1.1 ~ 1.2   ← 활성화·프레임워크 오버헤드

실무에서는 간이식으로 충분하다.

총 VRAM (GB) ≈ 파라미터 수(B) × 비트수 ÷ 8 × 1.2 + 컨텍스트 여유분

KV 캐시가 산정에서 자주 누락되는 항목이다. 컨텍스트 길이에 비례해 선형으로 늘기 때문에, 4K로 계산해 두고 32K를 밀어넣으면 예산이 어긋난다.

모델 크기별 필요 GPU

Q4_K_M(4bit) 기준, 컨텍스트 4K 가정이다.

같은 7B 모델에서 양자화 등급만 바꿨을 때의 변화다.

VRAM이 부족하면 어떻게 되나. llama.cpp와 Ollama는 일부 레이어를 CPU로 오프로딩한다. 동작은 하지만 토큰 생성 속도가 수 배에서 수십 배 느려진다.

따라서 "돌아간다"와 "쓸 만하다"는 다르다. 용량을 산정할 때는 전 레이어가 GPU에 올라가는 조건을 목표로 잡아야 한다. "GPU가 작아서 못 돌린다"가 아니라 "돌아가지만 실용 속도가 안 나온다"가 정확한 진단이다.

도입 판단 체크리스트

손익분기 계산은 이렇게 세운다.

API 월 비용 = (월 입력토큰 ÷ 1M × 입력단가) + (월 출력토큰 ÷ 1M × 출력단가)

로컬 월 비용 = GPU 감가상각(또는 임차료) + 전력비 + 운영 인건비 안분

→ API 월 비용이 로컬 월 비용을 안정적으로 넘어서는 시점이 전환점

가장 흔한 계산 오류는 운영 인건비 누락이다. 이 항을 빼면 로컬이 항상 이기는 것처럼 보인다.

실제로는 GPU 하드웨어 비용보다 "이걸 관리할 사람"의 비용이 큰 경우가 많다. 그래서 조직 규모가 작을수록, 1·2번 항목(데이터 반출 제한)이 없으면 API가 합리적이라는 결론이 나온다.

로컬로 전환하든 API를 유지하든, 무엇이 느리고 무엇이 비싼지 알아야 판단이 성립한다. 그 측정 방법은 비동기와 트레이싱에서 다룬다.