--- title: "추론 엔진의 쓸쓸함 — llama.cpp는 왜 누구도 없으면 안 되나" date: 2026-10-10 model: qwen3.6-plus author_type: human category: reviews summary: "llama.cpp는 '실무에 못 쓴다'는 비판과 '멀티 클라이언트에서 압도적'이라는 방어가 같은 스레드에서 붙는다. VRAM 경계·빌드 리그레션·새 텐서 타입 미지원 등 사용자 이슈를 통해, 추론 엔진의 성숙과 대가를 정리한다." tags: llama.cpp, GGUF, 추론 엔진, KV 캐시, 서버, 양자화, 사용자 리뷰, 실사용자 리뷰, AI 에이전트 --- ## 추론 엔진의 쓸쓸함 — llama.cpp는 왜 누구도 없으면 안 되나 r/LocalLLaMA에 굵은 제목이 올라왔다. "llama.cpp는 실제 작업에 못 쓴다." 본문: "의미 있는 컨텍스트를 넣는 순간 토큰 생성 속도가 무너진다. 프롬프트 처리도 고통스럽다. 장난감 데모 외에 뭘 위해 쓰나?" 이 스레드의 두 번째 문장이 이 글의 축이다. **같은 프로젝트에 대한 비판과 방어가 같은 댓글 창에 붙어 있다.** 하나는 "실무에 못 쓴다", 다른 하나는 "멀티 클라이언트 처리에서 엄청나게 잘 확장된다". 이 글은 llama.cpp의 실패 사례와 성공 사례를 **한 줄로 나눈 뒤**, 그 줄이 어디에 그려지는지 정리한다. --- ### 1. "실무에 못 쓴다"가 나오는 지점 **VRAM 밖으로 새는 순간.** 위 스레드의 진단 댓글: "속도 붕괴는 대개 out-of-memory다. 오버플로가 일반 RAM으로 밀려난다. 모델+KV 캐시가 VRAM에 완전히 들어가게 만들라. KV를 제한하지 않으면 모델 최대값까지 쓴다." 사용자의 명령어가 그대로 증거다. DeepSeek-R1 대형 GGUF를 L40S에 올린 이슈(#11635): 16 레이어를 GPU로 오프로드했음에도 GPU utilization 8%, 생성 0.82 t/s. `-ngl 8`·`16`으로 바꿔도 체감이 없다. "64 스레드보다 16 스레드가 더 낫다"는 코멘트까지 붙는다. **빌드 리그레션.** #18258: 특정 빌드(b7406→b7410)에서 동일 모델이 45 t/s에서 10~20 t/s로. 같은 명령어, 같은 하드웨어, 다른 빌드. 추론 엔진의 일상이 버전 핀 고정이라는 뜻이다. **새 포맷의 벽.** MXFP4 GGUF가 최신 llama.cpp에서 "invalid ggml type 39"로 거부되는 이슈(2025-08). 모델 출시와 GGUF 지원 사이에 항상 간극이 있다. **구조화 출력의 세그폴트.** #17391: llama-server + GLM-4.6 GGUF + BAML 구조화 출력을 고부하로 돌리면 결국 segmentation fault. "같은 패턴이 MiniMax-M2에서도 있었다"는 재현 보고. --- ### 2. "없으면 안 된다"가 나오는 지점 **멀티 클라이언트.** 위 "실무에 못 쓴다" 스레드의 방어 댓글: "멀티 클라이언트 처리가 엄청나게 잘 확장된다." 단일 사용자 대화 속도가 아니라 동시 요청 수용력의 문제다. **형식의 생태계.** GGUF는 양자화 선택지가 풍부하고, 서버 모드는 OpenAI 호환 API를 브로드캐스트한다. vLLM·SGLang·TensorRT-LLM·Ollama·LM Studio·llamafile의 상당수가 llama.cpp의 추론 코어 또는 형식 규약에 빚을 지고 있다. "누구도 없으면 안 되는" 이유가 생태계 기반이기 때문이다. **하드웨어의 다양성.** CUDA·Metal·Vulkan·CPU·AMX까지. 특정 벤더 락인 없이 "이 기계에서 일단 된다"는 것은 llama.cpp의 고유 강점이다. --- ### 3. 한 줄의 위치 사용자 기록을 세 구역으로 나누면 정리가 끝난다. | 구역 | 형태 | llama.cpp의 역할 | | --- | --- | --- | | 단일 대화, 최대 토큰 속도 | vLLM·SGLang·상용 API | llama.cpp는 선택지 중 하나 | | 혼자·소수, 하드웨어 제약 | 노트북·홈랩·GPU 한 장 | llama.cpp(또는 그 위에 얹힌 도구)가 기본 | | 동시성·배치·프로덕션 서빙 | 멀티 테넌트 API | llama.cpp는 빌드·핀·튜닝 비용을 감수해야 | "실무에 못 쓴다"는 말은 **보통 구역 3의 기준을 구역 2의 도구에 들이대면서** 나온다. "없으면 안 된다"는 말은 **구역 2·3의 기반을 설명한다.** 둘 다 맞고, 같은 스레드에 붙어 있는 이유다. --- ### 4. 결론 — 엔진의 규칙 llama.cpp를 쓸 때 사용자들이 몸으로 배운 규칙 세 가지. 1. **VRAM 밖의 문은 한 번에 열리지 않는다.** 모델·KV·컨텍스트 예산을 먼저 그리고, 떨어진 순간 속도가 아니라 가용성이 무너진다. 2. **빌드를 핀으로 고정하라.** 리그레션과 미지원 포맷이 일상이다. 3. **구조화 출력·툴 호출·고부하는 별도의 격전지다.** 대화가 되는 것이 API 서비스가 되는 것은 아니다. llama.cpp는 완성품이 아니라 **인프라**다. 인프라의 칭찬과 욕은 언제나 같은 댓글 창에 나란히 붙는다. 관련 글: [Ollama 사용자 리뷰](/reviews/2026-10-10-ollama-user-reviews/) · [vLLM 사용자 리뷰](/agents/vllm/) · [llama.cpp 에이전트 허브 항목](/agents/llama-cpp/) --- ### 출처 - 속도 논쟁: [llama.cpp is unusable for real work (r/LocalLLaMA, 2025-07)](https://www.reddit.com/r/LocalLLaMA/comments/1m6skm6/) - VRAM·GPU 이슈: [CPU bound while inferencing against DeepSeek-R1 GGUF (llama.cpp #11635)](https://github.com/ggml-org/llama.cpp/issues/11635) - 빌드 리그레션: [Major performance drop since b7406 (llama.cpp #18258)](https://github.com/ggml-org/llama.cpp/issues/18258) - 구조화 출력 크래시: [GLM-4.6 GGUF + BAML segfault (llama.cpp #17391)](https://github.com/ggml-org/llama.cpp/issues/17391) - 멀티 유저 비교: [llama.cpp GGUF vs vLLM AWQ/GPTQ (r/LocalLLaMA, 2025-06)](https://www.reddit.com/r/LocalLLaMA/comments/1lafihl/)