한 줄 정의

llama-cpp는 검색어나 태그에서 llama.cpp를 적을 때 자주 쓰는 표기야. llama cpp처럼 띄어 쓰기도 하지만, 실제로 가리키는 건 모델 가족이 아니라 GGUF 파일을 로컬 장비나 자체 서버에서 실행하는 C/C++ 기반 추론 런타임이야.

실제로 무엇을 하나

실무에서 llama.cpp는 모델 파일과 앱 사이의 실행층을 맡아. 예를 들어 llama-cli -m model.gguf로 로컬 파일을 바로 테스트하고, llama-server -hf ggml-org/gemma-3-1b-it-GGUF처럼 Hugging Face 모델을 받아 OpenAI 호환 API 서버로 띄울 수 있어. 서버 쪽은 기본 예시에서 127.0.0.1:8080으로 뜨고, 앱은 이 주소를 새 base_url처럼 부를 수 있어.

이 도구가 자주 보이는 이유는 직접 조정할 수 있는 손잡이가 많기 때문이야. 1.5비트부터 8비트까지의 정수 양자화, CUDA·Metal·Vulkan·SYCL 같은 백엔드, CPU+GPU 혼합 실행, prompt cache, draft model을 쓰는 추측 디코딩까지 한 층에서 다룬다. Ollama나 LM Studio가 설치와 모델 관리를 더 감싸 준다면, llama.cpp는 그 아래에서 속도, 메모리, 템플릿, 서버 옵션을 직접 만지는 쪽이야.

왜 중요한가

llama-cpp라는 태그가 붙은 글은 보통 “새 모델이 나왔다”보다 “그 모델을 내 장비에서 굴릴 수 있나”에 가까운 질문을 다뤄. Gemma 4 사례가 딱 그래. PR #21534가 2026-04-09에 머지되면서 Gemma 4 tokenizer edge case가 고쳐졌고, 커뮤니티에서는 31B Q5 양자화 모델을 current master에서 안정적으로 돌렸다는 보고가 나왔어. 다만 그 글도 릴리스 빌드가 아니라 소스 코드 master 기준이라고 선을 그었고, CUDA 13.2는 피하라는 조건까지 붙였어.

성능 실험도 같은 식으로 읽어야 해. 한 Reddit 벤치마크는 RTX 5090 32GB에서 Gemma 4 31B를 메인 모델로, E2B를 draft model로 두고 추측 디코딩을 켰을 때 평균 57.17 t/s가 73.73 t/s로 올라간 +29.0% 사례를 보여 줬어. 코드 생성은 +50.5%까지 갔지만, creative text나 번역에서는 +10%대에 머물렀고, early GGUF metadata가 맞지 않으면 draft model이 오히려 손해가 날 수 있었다고 적었어. 숫자는 좋지만, 조건을 안 보면 바로 틀리기 쉬운 종류의 숫자야.

주의해서 볼 점

첫째, llama.cpp 지원은 모델 품질 보증이 아니야. Gemma 4 26B A4B가 25.2B 총 파라미터와 3.8B 활성 파라미터를 가진다고 해도, 실제 로컬 속도는 GGUF 변환, 양자화 비트 수, KV cache 타입, chat template, 백엔드 빌드가 같이 결정해.

둘째, “OpenAI 호환”은 요청 형식이 비슷하다는 뜻이지 OpenAI 서비스와 같은 품질, 정책, 인증, 과금 체계를 준다는 뜻은 아니야. 내부 앱을 llama-server에 연결할 때는 /v1/chat/completions가 호출되는지만 보지 말고, 로그, 네트워크 노출, 모델 alias, context 길이, 장애 복구까지 같이 확인해야 해.

셋째, 벤치마크는 먼저 조건을 읽는 게 낫다. RTX 5090 32GB, 128K context, --draft-max 8, TurboQuant fork에서 나온 +29.0% 평균값을 AMD iGPU나 일반 릴리스 빌드로 그대로 옮기면 안 맞을 수 있어. 그래서 llama-cpp 글을 읽을 때는 모델명보다 실행 파일, 빌드 시점, GGUF 버전, RAM·VRAM 구성을 먼저 보는 편이 덜 헷갈려.