llama.cpp vs vLLM 차이 정리: 로컬 LLM 엔진 선택 기준과 양자화·연속 배칭 핵심

핵심 메시지

• 모델을 직접 돌리려는 이유는 대체로 비용 절감, 서비스 장애·사용량 제한 회피, 그리고 데이터가 내 기기 밖으로 나가지 않는 프라이버시다.
• llama.cpp는 양자화와 GGUF 단일 파일, CPU 추론으로 '작은 하드웨어에서도 돌아가게' 만드는 데 초점을 맞춘다.
• vLLM은 연속 배칭과 KV 캐시 최적화(페이지드 어텐션)로 여러 사용자·대규모 요청을 감당하는 운영 환경을 노린다.
• 두 엔진 모두 OpenAI 호환 엔드포인트를 제공해, 기존 코드를 크게 고치지 않고 갈아끼울 수 있다.
• 결국 선택 기준은 성능 우열이 아니라 '소비자용 하드웨어냐, 프로덕션 워크로드냐'라는 용도의 차이다.

쉽게 이해하기

영상은 개인이 자기 컴퓨터에서 대규모 언어 모델을 돌리려는 흐름을 짚으며 시작한다. 이유는 세 가지로 정리된다. 상용 API 비용이 만만치 않다는 점, 외부 AI 서비스가 장애를 일으키거나 사용량 제한을 걸 수 있다는 점, 그리고 발표자가 가장 크게 꼽은 이유인 내 기기 안에서 처리해 얻는 프라이버시와 보안이다.

출발점으로 메타의 라마 2가 소환된다. 상업적으로 성공한 초기 공개 가중치 모델 중 하나로, 허깅페이스나 깃허브에서 내려받아 직접 돌려볼 수 있었다는 점이 달랐다. 다만 70억·130억·700억 파라미터라는 크기 탓에 큰 그래픽 카드가 필요했고, 개인 장비로는 사실상 실행이 어려웠다.

llama.cpp가 푼 문제가 여기에 있다. 핵심 기법은 양자화다. 원주율을 3.141592…가 아니라 3.14로 줄여 쓰듯, 높은 정밀도로 저장된 가중치를 8비트나 4비트 정수로 압축한다. 발표자는 이 방식으로 30기가바이트가 필요하던 모델을 4기가바이트 VRAM 수준으로 낮출 수 있다고 설명한다. 여기에 가중치·토크나이저·설정 파일을 GGUF라는 하나의 파일로 묶어 모델 교체를 쉽게 만들고, GPU가 없는 컴퓨터를 위해 CPU 추론까지 지원한다.

그 결과 노트북이나 라즈베리파이에서도 모델이 돌아가고, 네트워크가 없는 공장이나 IoT 환경에서 오프라인 실행이 가능해졌다. 오늘날 많이 쓰이는 Ollama와 LM Studio 같은 도구도 이 프로젝트에서 파생됐다는 것이 영상의 설명이다.

반면 vLLM은 규모를 향한다. 임베딩 생성용 모델, 코딩 에이전트용 모델을 함께 굴리거나, 사용자가 10명에서 1만 명으로 늘거나, 쿠버네티스와 가상 머신에 배포해야 하는 상황이 대상이다. 엔비디아 GPU와 구글 TPU, AMD, 인텔 등 폭넓은 가속기를 지원하고, 주요 오픈소스 연구소의 신규 모델이 출시 당일부터 지원되는 경우가 많다는 점도 강조된다.

주요 인사이트

• vLLM의 연속 배칭은 '팬케이크 굽기'에 비유된다. 여섯 장이 각기 다른 시점에 익는데, 전부 익을 때까지 기다렸다가 다음 반죽을 올리면 손해다. 먼저 끝난 자리에 곧바로 새 요청을 채워 넣는 방식이다.
• KV 캐시는 생각보다 무겁다. 프롬프트를 층층이 통과시키며 계산한 중간 결과가 수십 기가바이트에 이르기도 하고, A100 같은 가속기 메모리는 모델 가중치와 이 캐시가 대부분을 차지한다. 페이지드 어텐션은 이 공간을 효율적으로 관리해 같은 요청의 재계산을 피하는 기법이다.
• 스페큘레이터는 작은 모델이 답의 일부를 먼저 만들고 큰 모델이 그 결과를 검증하는 방식이다. 여기에 프리필과 디코드 단계를 분리하는 디스어그리게이션(LLM-D 프로젝트)을 결합할 수 있다고 소개된다.
• 두 엔진 모두 딥시크, Qwen, 라마 같은 모델은 물론 멀티모달 모델까지 OpenAI 호환 엔드포인트로 서빙한다. 기존 completions·responses API를 쓰던 코드라면 설정을 크게 바꾸지 않고 옮겨갈 수 있다는 뜻이다.
• 현실적인 경로는 대개 비슷하다. 처음에는 테스트가 쉬운 유료 API로 시작하고, 청구서가 불어나기 시작하면 llama.cpp나 vLLM으로 갈아탄다.

자주 묻는 질문

관련 AI 소식