vLLM 리뷰 2026: 대규모 프로덕션 LLM 추론 (Production LLM Inference at Scale)

이 기사는 원래 aifoss.dev에 게시되었습니다.

title: 'vLLM 리뷰 2026: 대규모 프로덕션 LLM 추론 (Production LLM Inference at Scale)'
description: 'vLLM은 PagedAttention과 continuous batching을 통해 높은 처리량(high-throughput)의 LLM 서빙을 제공합니다. 2026년 리뷰: 설치, 벤치마크, 그리고 Ollama 대신 vLLM을 선택해야 하는 시점.'
pubDate: '2026년 5월 25일'

tags: ["vllm", "ai", "llm", "python", "gpu"]

vLLM은 Ollama만으로는 부족해지는 시점에 찾게 되는 추론 엔진(inference engine)입니다. UC Berkeley의 Sky Computing Lab에서 구축되었으며, 현재는 Linux Foundation의 PyTorch Foundation 산하에서 관리되고 있습니다. 이 엔진은 오픈 소스(Apache 2.0)이며, 성능에 대해 확고한 주관을 가지고 있고, 대안들보다 의도적으로 설정하기가 더 어렵습니다. 그러한 트레이드오프(trade-off)가 바로 핵심입니다.

만약 수 명 이상의 동시 사용자에게 LLM을 서빙하고 있다면, vLLM의 두 가지 핵심 혁신인 PagedAttention과 continuous batching은 계산 방식을 상당히 변화시킵니다. 하지만 개인적으로 모델을 로컬에서 실행하는 용도라면 과할 수 있습니다.

이 리뷰는 2026년 5월 15일에 출시된 v0.21.0 버전을 기준으로, Linux 환경과 NVIDIA 하드웨어에서 다룹니다.

vLLM이 차별화되는 점

모든 LLM 추론 엔진은 동일한 문제, 즉 KV 캐시(KV cache) 문제를 해결해야 합니다. 모델이 토큰을 생성함에 따라, 컨텍스트 윈도우(context window) 내의 모든 이전 토큰에 대한 키(key) 및 값(value) 텐서를 저장해야 합니다. 이 저장 공간은 VRAM을 빠르게 소모하며, 이를 어떻게 관리하느냐에 따라 처리할 수 있는 동시 요청(concurrent requests) 수가 결정됩니다.

전통적인 서빙 방식은 VRAM을 정적으로 할당합니다. 즉, 요청당 고정된 블록을 예약하고 생성이 진행됨에 따라 이를 채워 나갑니다. 이 방식은 낭비가 심합니다. 실제 생성이 메모리의 10%만 사용하고 있더라도, 가능한 최대 컨텍스트를 위한 메모리를 계속 점유하고 있기 때문입니다.

PagedAttention은 운영체제(OS)의 가상 메모리(virtual memory) 개념을 빌려와 이 문제를 해결합니다. KV 캐시는 고정된 크기의 페이지(pages)로 나뉘며, 활성 토큰에 실제로 필요한 페이지들만 할당됩니다. 이를 통해 메모리 파편화(memory fragmentation)가 거의 제로에 가깝게 감소하며, 동일한 VRAM으로 훨씬 더 많은 동시 시퀀스(concurrent sequences)를 지원할 수 있습니다.

**연속 배치 (Continuous batching)**는 스케줄링 측면의 대응 기술입니다. 전통적인 배치 추론 (batched inference)은 새로운 요청을 수락하기 전에 전체 배치가 완료될 때까지 기다립니다. 연속 배치 (Continuous batching)는 생성 중간에 슬롯이 열리는 즉시 새로운 요청이 배치에 끼어들 수 있게 합니다. 이를 통해 꼬리 지연 시간 (Tail latency)은 줄어들고, GPU 활용률 (GPU utilization)은 높아집 most니다.

이러한 개선 사항은 단순히 학술적인 수준에 그치지 않습니다. 이것이 바로 8명의 동시 사용자 환경에서 Llama 3 8B 모델을 구동할 때, Ollama가 초당 82 토큰 (82 tokens/second)을 기록하는 것에 비해 vLLM이 약 187 토큰/초 (187 tokens/second)를 기록하며 벤치마크 성능을 내는 이유입니다. 여러 동시 요청이 발생하는 최대 처리량 (peak throughput) 상황에서는 그 격차가 더욱 벌어집니다. Markaicode와 SitePoint의 제3자 벤치마크(출처 참조)에 따르면, 대략 793 tok/s 대 41 tok/s의 차이를 보입니다.

설치 (Installation)

vLLM은 NVIDIA GPU를 주요 대상으로 하며 Linux에서 실행됩니다. 가장 간단한 방법은 다음과 같습니다:

pip install vllm

이 명령은 Linux 환경의 CUDA 12.4를 처리합니다. Wheel 파일에는 PyTorch 2.11 및 모든 종속성이 포함되어 있으므로, 버전 충돌을 방지하기 위해 새로운 가상 환경 (virtual environment)을 사용하십시오.

시스템 요구 사항:

Python ≥3.10 및 <3.15 (v0.21.0에서 Python 3.14 추가)
Linux (Ubuntu 20.04 이상 권장)
CUDA 12.4를 지원하는 NVIDIA GPU; 최신 Blackwell 기능을 위해서는 CUDA 13.0 필요
서빙하려는 모델에 적합한 VRAM (아래 표 참조)

AMD ROCm 지원이 존재하지만 NVIDIA 경로보다는 뒤처져 있습니다. 2026년 4월 기준으로 AMD GPU에서의 컨텍스트 길이 (context-length) 제한 문제는 여전히 해결 중이었습니다 (특정 구성에서 64k 토큰 장벽).

Windows는 2026년에 네이티브 지원을 받았으나, CUDA 13.0과 RTX 6000 Ada 또는 그 이상의 사양이 필요합니다. 구형 하드웨어의 경우 WSL2가 여전히 더 신뢰할 수 있는 Windows 경로입니다.

로컬 드라이버 설정을 완전히 건너뛰고 싶다면, RunPod에서 CUDA 환경이 사전 설치된 vLLM 준비 완료 GPU 인스턴스를 제공합니다. 이는 서버 구축을 확정하기 전에 프로덕션 하드웨어에서 vLLM을 평가하는 데 유용합니다.

첫 번째 모델 서빙하기 (Serving your first model)

퀵스타트 (quickstart)를 통해 OpenAI 호환 API 서버를 실행할 수 있습니다:

vllm serve meta-llama/Llama-3.2-8B-Instruct --host 0.0.0.0 --port 8000

또는 명시적인 설정을 사용하여 실행할 수 있습니다:

python -m vllm.entrypoints.openai.api_server \
  --model meta-llama/Llama-3.2-8B-Instruct \
  --host 0.0.0.0 \
...

--gpu-memory-utilization 0.9는 vLLM이 사용 가능한 VRAM의 90%를 KV 캐시 풀 (KV cache pool)로 사용하도록 지시합니다. 나머지 10%는 모델 가중치 (model weights)와 오버헤드 (overhead)를 위해 할당됩니다. 만약 OOM (Out of Memory) 에러가 발생한다면 이 값을 낮추어 조정하십시오.

서버가 실행되면, 표준 OpenAI API 호출을 수락합니다:

from openai import OpenAI

client = OpenAI(base_url="http://localhost:8000/v1", api_key="not-needed")
...

OpenAI API용으로 이미 작성된 모든 애플리케이션은 베이스 URL (base URL)만 변경하면 vLLM과 함께 작동합니다. 이러한 즉각적인 호환성 (drop-in compatibility)은 팀들이 자체 호스팅 API 인프라로 vLLM을 선택하는 주요 이유입니다.

여러 GPU에 걸쳐 70B 모델을 실행하려면, 텐서 병렬화 (tensor parallelism) 플래그 하나만 추가하면 됩니다:

vllm serve meta-llama/Llama-3.2-70B-Instruct \
  --tensor-parallel-size 4 \
  --host 0.0.0.0 \
...

vLLM은 텐서 병렬화를 위해 동일한 GPU를 요구합니다. 그룹 내의 모든 카드는 일치하는 VRAM과 연산 능력 (compute capability)을 가져야 합니다.

모델 크기별 VRAM 요구 사항

모델 크기	FP16 (비양자화)	FP8 양자화 (quantization)	예시 GPU
7B	~14 GB	~8 GB	RTX 3080 (FP8 사용 시 10GB)
...

FP8 양자화 (--quantization fp8)는 품질 저하를 최소화하면서 VRAM 요구 사항을 대략 절반으로 줄여줍니다. 소비자용 하드웨어에서 메모리가 제한적인 상황이라면 가장 먼저 추가해야 할 플래그입니다. GGUF, AWQ, FP8 형식 간의 양자화 트레이드오프 (tradeoffs)에 대한 더 폭넓은 관점은 GGUF 양자화 가이드에서 자세히 확인할 수 있습니다.

성능: 이점이 드러나는 지점

vLLM의 강점은 동시성 (Concurrency)이 높아질수록 커집니다. 단일 사용자 환경에서는 Ollama와의 격차가 약 13% 정도로 미미한데, 이는 부분적으로 Ollama의 Q4_K_M 양자화 (Quantization)가 메모리를 적게 사용하며 메모리가 제한된 소비자용 하드웨어에서 더 빠르게 실행될 수 있기 때문입니다. 아키텍처의 차이는 규모가 커질 때 명확해집니다:

시나리오	vLLM (FP16)	Ollama (Q4_K_M)
1명의 동시 사용자, Llama 3 8B	~71 tok/s	~62 tok/s
...
Markaicode 및 SitePoint의 2026년 테스트 벤치마크 결과; 링크는 Sources 참조.

단일 사용자 수치는 서로 비슷합니다. vLLM의 배치 (Batching) 메커니즘이 배치할 대상이 없기 때문입니다. vLLM의 이점은 수많은 동시 요청이 발생하는 상황에서도 GPU 활용률 (Utilization)을 높게 유지하는 데 있습니다. Ollama의 처리량 (Throughput)은 동시 부하 상황에서 거의 즉시 평탄화(flatten)되는 반면, vLLM은 매끄럽게 확장됩니다.

TensorRT-LLM (NVIDIA의 독점 엔진)과 비교했을 때, vLLM은 피크 처리량 (Peak throughput)의 몇 퍼센트를 양보하는 대신, 훨씬 더 간단한 설정과 모델 불가지론적 (Model-agnostic) 아키텍처를 제공합니다. TGI (Hugging Face의 Text Generation Inference)는 vLLM과 동일한 니치 (Niche) 시장을 점유하고 있으며, 이미 Hugging Face 생태계에 깊이 발을 들여놓고 있다면 비교해 볼 가치가 있습니다.

하드웨어별 Ollama 대 vLLM의 상세한 분석 수치는 Ollama vs vLLM comparison에서 확인할 수 있습니다.

v0.21.0에서 지원되는 모델

vLLM의 모델 지원은 중요한 대부분의 아키텍처를 포괄합니다:

Llama 제품군: Llama 3.x, Llama 4
Mistral/Mixtral: Mistral 7B, Mixtral 8x7B, Mixtral 8x22B
Qwen: Qwen 2.5, Qwen 3.5, Qwen-VL 시각-언어 (Vision-language) 변형 모델
DeepSeek: DeepSeek V3, V4, R1 (MLA 어텐션 지원 포함)
Gemma: Gemma 2, Gemma 3
Phi: Microsoft Phi-3, Phi-4
시각-언어 모델 (Vision-language models): LLaVA, InternVL, Moondream3 (v0.21.0에서 추가)

Hugging Face Transformers의 새로운 아키텍처는 일반적으로 출시 후 몇 주 이내에 vLLM에 반영됩니다. 이 프로젝트는 매우 빠르게 움직입니다. v0.21.0은 200명의 기여자가 작성한 367개의 커밋 (Commit)을 포함하여 출시되었으며, v0.