vLLM vs llama.cpp vs Ollama: What Happens When Your Model Doesn't Fit in 24GB VRAM

개요

RTX 3090 (24GB VRAM) 및 128GB RAM 환경에서 1B부터 116.8B 파라미터까지 다양한 모델을 대상으로 llama.cpp, Ollama, vLLM의 성능을 비교 분석합니다.

주요 내용

* 24GB VRAM 내 성능:
* vLLM은 연속 배치 처리(continuous batching)를 통해 동시 요청 1개에서 8개로 증가 시 집계 처리량을 3.9배에서 5.4배까지 높였습니다.
* llama.cpp는 명시적으로 -np 8을 설정해도 동시 요청 증가 시 처리량 증가율이 1.2배에서 1.9배에 그쳤습니다.
* vLLM은 llama.cpp보다 2.9배에서 3.7배, Ollama(기본 직렬 처리)보다 6.3배에서 16.4배 더 나은 동시성 8에서의 성능을 보였습니다.

* 24GB VRAM 초과 시 성능:
* 24GB VRAM을 초과하는 두 가지 모델(GLM-4.5-Air, GPT-OSS 120B)에 대해 llama.cpp와 Ollama는 각각 7~10 tok/s 수준으로 느린 속도를 보였으나 생성을 지속했습니다.
* vLLM은 동일 조건에서 OutOfMemoryError (OOM)를 발생시키며 실패했으며, 이는 모델 종류나 양자화 방식에 관계없이 약 22.1-22.2GB의 VRAM 사용량과 700MB 미만의 여유 VRAM 상태에서 발생했습니다.

* First Token Time (TTFT) 비교:
* RAM 스필(RAM-spill) 상황에서 llama.cpp의 수동 레이어 오프로드 설정(-ngl)은 Ollama의 자동 분할보다 37배 빠른 TTFT를 기록했습니다.
* 평균적인 디코드 속도는 RAM 스필 상황에서도 두 백엔드 간에 거의 동일했습니다.

* 비용 (에너지 소비량):
* 100만 개의 출력 토큰당 에너지 소비량 측면에서, GPT-OSS 120B 모델의 경우 Ollama가 llama.cpp보다 약 7배 더 많은 실제 전력을 소비했습니다. 이는 TTFT 성능 차이에서 비롯된 것으로 분석됩니다.
* vLLM은 일부 테스트에서 거의 제로에 가까운 에너지 소비량을 기록했으나, 이는 너무 짧은 테스트 시간으로 인한 샘플링 한계로 보입니다.

* vLLM의 양자화 문제:
* vLLM에서 MoE 모델의 경우 bitsandbytes 4-bit 양자화가 다양한 이유로 실패했습니다. (MoE 패딩된 expert 레이아웃 디큐운타이제이션 실패, 새로운 아키텍처에 대한 bnb 경로 미연결 등)
* 이 문제를 해결하기 위해 AWQ 등 사전 양자화된 체크포인트를 사용하거나, vLLM의 자동 감지 기능을 활용해야 했습니다.

시사점

24GB VRAM을 초과하는 대규모 언어 모델을 로컬 환경에서 운영할 경우, vLLM은 VRAM 한계에 도달하면 즉시 실패하지만 llama.cpp와 Ollama는 성능 저하를 감수하며 생성을 지속할 수 있습니다. TTFT 성능과 비용 측면에서는 llama.cpp가 Ollama보다 유리한 경우가 있으며, vLLM은 VRAM 내에서 높은 처리량을 제공하지만 RAM 스필 상황에는 취약합니다.