대규모 언어 모델(LLM)을 실제 서비스에 적용하려는 기업과 개발자가 급격히 늘어나고 있습니다. 챗봇, 코드 어시스턴트, 문서 요약 서비스 등 다양한 AI 애플리케이션이 등장하면서, LLM을 얼마나 빠르고 효율적으로 서빙할 수 있느냐가 핵심 경쟁력이 되었습니다. 그러나 기존의 추론(Inference) 엔진들은 GPU 메모리를 비효율적으로 사용하고, 동시 요청 처리에 한계를 보이는 문제가 있었습니다. 이러한 한계를 근본적으로 해결하기 위해 등장한 것이 바로 vLLM입니다. vLLM은 UC Berkeley의 Sky Computing Lab에서 2023년에 개발되어, 2026년 현재 v0.17.1까지 빠르게 발전하며 사실상 프로덕션 LLM 서빙의 업계 표준으로 자리 잡았습니다.
이 글에서는 vLLM의 핵심 개념과 아키텍처부터, 경쟁 도구인 Ollama와의 차이점, 설치 및 실행 방법, 그리고 실제 활용 사례까지 상세하게 다루겠습니다. LLM 서빙에 관심이 있는 초보 개발자부터 프로덕션 환경을 준비하는 엔지니어까지 모두에게 실질적인 도움이 될 수 있도록 구성하였습니다.
목 차
1. vLLM이란 무엇인가
vLLM의 정의
vLLM(Virtual Large Language Model)은 대규모 언어 모델의 추론(Inference)과 서빙(Serving)을 위해 설계된 오픈소스 고성능 엔진입니다. 2023년 UC Berkeley의 Sky Computing Lab에서 발표한 논문 "Efficient Memory Management for Large Language Model Serving with PagedAttention"을 기반으로 탄생하였으며, Apache 2.0 라이선스로 공개되어 누구나 자유롭게 사용할 수 있습니다. vLLM의 핵심 목표는 GPU 메모리를 최대한 효율적으로 관리하여, 동일한 하드웨어에서 기존 대비 최대 24배 높은 처리량(Throughput)을 달성하는 것입니다. 2026년 3월 현재 최신 버전은 v0.17.1이며, 매월 새로운 릴리즈가 발표될 정도로 활발한 개발이 이루어지고 있습니다.
[i] 추론(Inference) 이란 이미 학습된 AI 모델에 입력 데이터를 넣어 결과를 출력하는 과정을 의미합니다. 서빙(Serving) 은 이 추론 과정을 API 형태로 외부에 제공하는 것을 뜻합니다.
주요 특징
vLLM이 다른 추론 엔진과 차별화되는 핵심 특징은 크게 성능, 유연성, 호환성의 세 가지 축으로 나눌 수 있습니다. 아래 표는 vLLM의 주요 특징을 영역별로 정리한 것입니다.
| 영역 | 주요특징 | 상세설명 |
| 성능 최적화 | PagedAttention | - GPU 메모리를 OS의 가상 메모리처럼 페이지 단위로 관리하여 메모리 낭비를 4% 미만으로 줄임 - 기존 시스템 대비 60~80%의 메모리 낭비를 근본적으로 해결 |
| 성능 최적화 | Continuous Batching | - 요청을 동적으로 배치에 추가/제거하여 GPU 유휴 시간을 최소화 - 정적 배칭 대비 최대 23배 높은 처리량 달성 |
| 성능 최적화 | Speculative Decoding | - 작은 드래프트 모델이 토큰을 미리 생성하고 메인 모델이 검증하는 방식 - EAGLE, MTP, n-gram 등 다양한 방법 지원으로 지연 시간 1.3~2배 감소 |
| 성능 최적화 | Chunked Prefill | - 긴 프롬프트를 청크 단위로 분할 처리하여 디코딩과 병렬 실행 - 32K 이상의 긴 컨텍스트 요청 시 지연 스파이크 방지 |
| 유연성 | 다중 병렬 처리 | - Tensor Parallelism, Pipeline Parallelism, Data Parallelism, Expert Parallelism 지원 - 단일 GPU부터 다중 노드 클러스터까지 유연하게 확장 가능 |
| 유연성 | 양자화 지원 | - GPTQ, AWQ, AutoRound, INT4, INT8, FP8 등 다양한 양자화 포맷 지원 - H100/Blackwell GPU에서 FP8 추론 시 처리량 대폭 향상 |
| 유연성 | Multi-LoRA | - 하나의 서버에서 수백 개의 LoRA 어댑터를 동시에 서빙 - 어댑터 전환 오버헤드 거의 없음 |
| 호환성 | OpenAI 호환 API | - OpenAI SDK의 base URL만 변경하면 바로 사용 가능 - Chat Completions, Completions, Embeddings, Structured Output 지원 |
| 호환성 | 하드웨어 지원 | - NVIDIA GPU, AMD CPU/GPU, Intel CPU/GPU, Google TPU, ARM CPU 지원 - Intel Gaudi, IBM Spyre, Huawei Ascend 등 플러그인 하드웨어도 지원 |
| 호환성 | 멀티모달 지원 | - LLaVA, Qwen-VL, InternVL, Llama 4 등 텍스트+이미지 모델 지원 - 오디오 입력 처리 기능도 확장 중 |
2. vLLM의 핵심 기술 | PagedAttention과 Continuous Batching
vLLM의 성능 혁신은 PagedAttention과 Continuous Batching이라는 두 가지 핵심 기술에서 비롯됩니다. 이 두 기술이 어떻게 작동하는지 이해하면, vLLM이 왜 기존 추론 엔진보다 월등히 빠른지 명확하게 알 수 있습니다. 이 섹션에서는 일반인도 쉽게 이해할 수 있도록 비유와 함께 기술적 원리를 설명하겠습니다.
PagedAttention | GPU 메모리의 혁명
LLM이 텍스트를 생성할 때, 이전에 생성한 모든 토큰의 정보를 "KV 캐시(Key-Value Cache)"라는 형태로 GPU 메모리에 저장해야 합니다. 기존 시스템에서는 요청이 들어오면 해당 요청이 생성할 수 있는 최대 토큰 수만큼의 메모리를 미리 연속된 공간에 할당했습니다. 이것은 마치 레스토랑에서 10인용 테이블을 예약했는데 실제로 3명만 오는 것과 같은 상황으로, 나머지 7자리는 아무도 앉지 않아도 다른 손님에게 배정할 수 없는 것과 동일한 낭비가 발생합니다.
PagedAttention은 이 문제를 운영체제의 가상 메모리(Virtual Memory) 기법에서 영감을 받아 해결합니다. 연속된 큰 메모리 블록을 한 번에 할당하는 대신, 작은 고정 크기의 "페이지(Block)"로 메모리를 나누고, 토큰이 실제로 생성될 때마다 필요한 만큼만 페이지를 할당합니다. 논리적 KV 캐시와 물리적 메모리 공간 사이의 매핑은 "블록 테이블(Block Table)"이라는 자료구조가 관리합니다. 이를 통해 메모리 조각화(Fragmentation)가 거의 발생하지 않으며, 기존 시스템이 60~80%를 낭비하던 KV 캐시 메모리를 4% 미만의 낭비율로 관리할 수 있게 됩니다.
[i] KV 캐시(Key-Value Cache) 란 Transformer 모델이 어텐션 연산 시 사용하는 중간 결과물입니다. 한 번 계산된 결과를 캐시에 저장해 두면, 다음 토큰 생성 시 처음부터 다시 계산하지 않아도 되므로 속도가 크게 향상됩니다.
Continuous Batching | GPU를 쉬지 않게 하는 기술
기존의 정적 배칭(Static Batching) 방식에서는 여러 요청을 하나의 배치(Batch)로 묶어 GPU에 전달하되, 배치 내 모든 요청이 완료될 때까지 기다린 후에야 다음 배치를 처리했습니다. 이것은 마치 식당에서 한 테이블의 손님이 모두 식사를 마칠 때까지 다음 손님을 안내하지 않는 것과 같습니다. 한 요청이 100개의 토큰을 생성하고 다른 요청은 10개만 생성한다면, 짧은 요청이 끝나도 GPU는 긴 요청이 완료될 때까지 해당 슬롯을 유휴 상태로 남겨두게 됩니다.
vLLM의 Continuous Batching은 매 디코딩 스텝(Step)마다 스케줄러가 배치를 재구성합니다. 어떤 요청이 완료되면 즉시 그 슬롯에 새로운 요청을 삽입하고, GPU의 용량이 허용하는 한 대기열에서 새로운 요청을 계속 끌어옵니다. 이를 "반복 수준 스케줄링(Iteration-level Scheduling)"이라고 하며, GPU가 유휴 상태에 놓이는 시간을 극적으로 줄여줍니다. PagedAttention이 메모리를 효율적으로 관리해주기 때문에, Continuous Batching은 더 많은 요청을 동시에 배치에 포함시킬 수 있고, 이것이 곧 처리량의 폭발적 향상으로 이어집니다.
아키텍처 다이어그램
다음은 vLLM의 핵심 추론 파이프라인을 보여주는 다이어그램입니다. 요청이 들어오면 스케줄러가 배치를 구성하고, PagedAttention을 통해 KV 캐시를 관리하며, Continuous Batching으로 GPU를 최대한 활용하는 전체 흐름을 한눈에 파악할 수 있습니다.
계층 구조 요약:
- Client Applications - Web/Mobile, Python OpenAI SDK, curl, LangChain 등 다양한 클라이언트가 REST/WebSocket으로 연결
- vLLM API Server - OpenAI 호환 엔드포인트(/v1/chat/completions 등)를 노출
- vLLM Engine Core - Scheduler(Continuous Batching) → KV Cache Manager(PagedAttention) → Model Runner(CUDA Graph, FlashAttention) → Token Sampler → Detokenizer/Streamer의 반복 루프
- GPU Memory (VRAM) - Model Weights(BF16/FP8/INT4), KV Cache(동적 블록 할당), LoRA/Activations 세 영역으로 분할 관리
- Local Model Source - HuggingFace Hub, 로컬 가중치, GGUF/AWQ, GPTQ/FP8 등 다양한 포맷에서 모델 로딩
- Hardware - NVIDIA/AMD/Intel/TPU 및 Tensor/Pipeline/Expert Parallelism 지원
flowchart TB
subgraph INPUT["요청 수신"]
A["클라이언트 요청\n(OpenAI 호환 API)"] --> B["요청 큐\n(Request Queue)"]
end
subgraph SCHEDULER["스케줄러 (Iteration-level)"]
B --> C{"매 스텝마다\n배치 재구성"}
C -->|"새 요청 추가"| D["Prefill 단계\n(프롬프트 처리)"]
C -->|"진행 중 요청"| E["Decode 단계\n(토큰 생성)"]
C -->|"요청 완료"| F["슬롯 해제 및\n새 요청 삽입"]
F --> C
end
subgraph ENGINE["추론 엔진"]
D --> G["Chunked Prefill\n(긴 프롬프트 분할)"]
E --> H["Forward Pass\n(모델 실행)"]
G --> H
H --> I["토큰 샘플링\n(Greedy/Top-p/Top-k)"]
end
subgraph MEMORY["메모리 관리 (PagedAttention)"]
J["블록 풀\n(Block Pool)"] --> K["블록 테이블\n(Block Table)"]
K --> L["KV 캐시\n(페이지 단위 할당)"]
L --> H
I -->|"새 KV 생성"| L
end
subgraph OUTPUT["응답 반환"]
I --> M{"종료 조건\n확인"}
M -->|"완료"| N["응답 스트리밍\n(SSE)"]
M -->|"계속"| C
N --> O["클라이언트\n응답 수신"]
end
style INPUT fill:#aAaAaE,stroke:#878790,stroke-width:2px
style SCHEDULER fill:#aAaAaE,stroke:#878790,stroke-width:2px
style ENGINE fill:#aAaAaE,stroke:#878790,stroke-width:2px
style MEMORY fill:#aAaAaE,stroke:#878790,stroke-width:2px
style OUTPUT fill:#aAaAaE,stroke:#878790,stroke-width:2px3. vLLM vs Ollama | 무엇이 다른가
설계 철학의 차이
vLLM과 Ollama는 모두 LLM을 로컬 환경에서 실행할 수 있게 해주는 오픈소스 도구이지만, 근본적인 설계 철학이 완전히 다릅니다. vLLM은 "프로덕션 환경에서의 고성능 서빙"을 목표로 설계되었으며, GPU 활용 최적화와 다중 사용자 동시 처리에 초점을 맞추고 있습니다. 반면 Ollama는 "개발자 경험의 극대화"를 지향하며, 복잡한 설정 없이 단일 명령어로 모델을 다운로드하고 실행할 수 있는 편의성을 최우선으로 합니다. 이러한 차이는 마치 가정용 커피머신(Ollama)과 카페용 에스프레소 머신(vLLM)의 차이와 비슷합니다. 전자는 간편하게 한 잔을 내릴 수 있지만, 후자는 수십 명의 주문을 동시에 빠르게 처리할 수 있습니다.
상세 비교표
| 비교항목 | vLLM | Ollama |
| 핵심 목표 | 프로덕션 고성능 서빙, GPU 최적화 | 로컬 개발 편의성, 간편한 모델 실행 |
| 핵심 기술 | PagedAttention, Continuous Batching | llama.cpp 래핑, 컨테이너 기반 모델 패키징 |
| 설치 난이도 | Python 환경 및 CUDA 설정 필요, 중간 수준 | 단일 명령어 설치, 매우 쉬움 |
| 동시 처리 성능 | 수백~수천 동시 요청 처리 가능 | 기본 4개 병렬 처리, 확장 시에도 제한적 |
| 최대 처리량(TPS) | 793~8,033 TPS (하드웨어에 따라 다름) | 41~484 TPS (하드웨어에 따라 다름) |
| P99 지연시간 | 80ms (피크 처리량 기준) | 673ms (피크 처리량 기준) |
| 모델 지원 | Hugging Face 모델 광범위 지원, 다양한 양자화 포맷 | 큐레이션된 모델 카탈로그, 간편하지만 제한적 |
| 멀티모달 | LLaVA, Qwen-VL, InternVL, Llama 4 등 지원 | 제한적 지원 |
| API 호환성 | OpenAI API 완전 호환 (Chat, Embeddings, Structured Output) | OpenAI 호환 API 기본 지원 (고급 기능 제한) |
| 분산 추론 | Tensor/Pipeline/Data/Expert Parallelism | 미지원 |
| 하드웨어 요구 | NVIDIA GPU 권장 (AMD, Intel, TPU 지원) | CPU만으로도 실행 가능, Apple Silicon 최적화 |
| 적합한 용도 | 기업 프로덕션 API 서비스, 대규모 동시 사용자 처리 | 로컬 프로토타이핑, 개인 개발, 학습 |
성능 차이의 원인
Red Hat의 벤치마크 테스트에 따르면, vLLM은 동시 사용자 수가 증가할수록 Ollama 대비 압도적인 성능 차이를 보여줍니다. 이 차이의 핵심 원인은 아키텍처 수준에서의 설계 차이에 있습니다. Ollama는 기본적으로 순차 처리(Sequential Processing) 방식을 사용하며, OLLAMA_NUM_PARALLEL 설정으로 병렬 처리를 늘릴 수 있지만 아키텍처 자체가 변하지는 않습니다. 10명의 동시 사용자만 접속해도 응답 시간이 2초에서 45초 이상으로 급격히 증가하는 현상이 발생할 수 있습니다. 반면 vLLM은 Continuous Batching을 통해 매 이터레이션마다 GPU 파이프라인에 새로운 요청을 동적으로 삽입하므로, 동시 사용자가 256명 이상으로 늘어나도 안정적인 성능을 유지합니다.
어떤 도구를 선택해야 하는가
두 도구는 경쟁 관계라기보다 LLM 개발 수명주기의 서로 다른 단계를 담당하는 보완 관계에 가깝습니다. 프로토타이핑과 실험 단계에서는 Ollama의 간편함이 큰 장점이며, 서비스를 프로덕션에 배포할 때는 vLLM의 성능과 확장성이 필수적입니다. 실제로 많은 기업이 "Ollama로 개발하고, vLLM으로 배포한다"는 하이브리드 전략을 채택하고 있습니다. 두 도구 모두 OpenAI 호환 API를 지원하므로, base URL만 변경하면 애플리케이션 코드의 수정 없이 전환이 가능합니다.
flowchart LR
subgraph DEV["개발 단계"]
A["아이디어\n검증"] --> B["프로토타입\n개발"]
B --> C["모델 실험\n및 비교"]
end
subgraph TRANSITION["전환"]
C --> D["base URL\n변경만으로 전환"]
end
subgraph PROD["프로덕션 단계"]
D --> E["API 서비스\n배포"]
E --> F["스케일링\n및 최적화"]
F --> G["모니터링\n및 운영"]
end
style DEV fill:#2D4A2D,stroke:#66BB6A,stroke-width:2px
style TRANSITION fill:#4A3D2D,stroke:#FFA726,stroke-width:2px
style PROD fill:#2D2D4A,stroke:#4A90D9,stroke-width:2px
A:::ollama
B:::ollama
C:::ollama
E:::vllm
F:::vllm
G:::vllm
classDef ollama fill:#2D4A2D,stroke:#66BB6A,color:#FFFFFF
classDef vllm fill:#2D2D4A,stroke:#4A90D9,color:#FFFFFF4. vLLM 지원 하드웨어: Apple Silicon부터 데이터센터 GPU까지
vLLM의 가장 큰 강점 중 하나는 단일 프레임워크로 다양한 하드웨어 플랫폼을 지원한다는 것입니다. NVIDIA GPU 전용이었던 초기 버전과 달리, 2026년 현재 vLLM은 AMD GPU, Intel XPU, Google TPU, ARM CPU, 그리고 Apple Silicon까지 폭넓은 하드웨어를 공식적으로 지원하고 있습니다. 이는 vLLM의 플러그인 아키텍처 덕분으로, 각 하드웨어 벤더가 커뮤니티 플러그인 형태로 자사 하드웨어에 최적화된 백엔드를 개발하고 통합할 수 있는 구조를 제공합니다. 이 섹션에서는 vLLM이 지원하는 하드웨어 플랫폼을 전체적으로 살펴보고, 특히 최근 주목받고 있는 Apple Silicon 지원에 대해 상세히 다루겠습니다.
지원 하드웨어 플랫폼 전체 현황
아래 표는 vLLM이 지원하는 주요 하드웨어 플랫폼과 그 특징을 정리한 것입니다. 각 플랫폼은 네이티브 지원(vLLM 코어에 내장)과 플러그인 지원(별도 설치 필요)으로 구분됩니다.
| 하드웨어 | 플랫폼지원방식 | 컴퓨트 백엔드 | 주요 특징 | 권장용도 |
| NVIDIA GPU | 네이티브 (코어) | CUDA | - 최고 성능 및 최적화 수준 - A100, H100, Blackwell(B200) 등 - FP8, NVFP4 양자화 지원 - Tensor/Pipeline/Expert Parallelism |
프로덕션 대규모 서빙, 학습-추론 통합 |
| AMD GPU | 네이티브 (코어) | ROCm/HIP | - MI300X 등 데이터센터 GPU 지원 - Triton Attention 백엔드 - AITER 커널 최적화 |
비용 효율적 프로덕션, NVIDIA 대안 |
| Intel GPU/XPU | 네이티브 + 플러그인 | vllm-xpu-kernels | - Gaudi 가속기 지원 - FP8, MoE 커널 지원 - v0.16.0부터 IPEX 대신 전용 커널로 전환 |
인텔 인프라 기반 기업 환경 |
| Google TPU | 네이티브 (코어) | tpu-inference | - Cloud TPU v4/v5e 지원 - vllm-tpu 패키지로 설치 |
Google Cloud 기반 배포 |
| Huawei Ascend | 플러그인 (vllm-ascend) | CANN | - Ascend 910B/950 칩 지원 - FlashComm 최적화 - Expert Parallelism 지원 |
화웨이 생태계, 중국 시장 |
| IBM Spyre | 플러그인 | 전용 백엔드 | - IBM 전용 AI 가속기 | IBM 기업 인프라 |
| Apple Silicon | 플러그인 (vllm-metal) | MLX + Metal | - M1/M2/M3/M4/M5 시리즈 지원 - 유니파이드 메모리 활용 제로카피 - Paged Attention 실험적 지원 |
개발/프로토타이핑, 개인 서빙 |
| ARM CPU | 네이티브 (코어) | ARM BF16/INT8 | - ARM 서버 및 에지 디바이스 - KleidiAI INT8_W4A8 지원 |
에지 추론, CPU 기반 서빙 |
| PowerPC CPU | 네이티브 (코어) | 벡터 연산 | - ppc64le 아키텍처 지원 - Prefix Caching 지원 |
IBM Power 인프라 |
Apple Silicon 지원 | vLLM Metal
Apple Silicon을 탑재한 Mac은 유니파이드 메모리(Unified Memory) 아키텍처 덕분에 CPU와 GPU가 동일한 메모리 풀을 공유합니다. 이는 NVIDIA GPU처럼 별도의 VRAM이 존재하는 환경과 근본적으로 다른 구조입니다. 예를 들어 Mac Studio M3 Ultra의 192GB 통합 메모리는 전체가 LLM의 모델 가중치와 KV 캐시에 활용될 수 있어, 단일 기기에서 400B 파라미터 규모의 초대형 모델도 로드할 수 있습니다. 이러한 장점을 vLLM에서 활용할 수 있도록 개발된 것이 바로 vLLM Metal 플러그인입니다.
vLLM Metal은 vLLM 공식 프로젝트 산하(vllm-project/vllm-metal)에서 커뮤니티가 유지보수하는 하드웨어 플러그인으로, Apple의 MLX(Machine Learning eXtensions) 프레임워크를 기본 컴퓨트 백엔드로 사용합니다. Docker와 vLLM 프로젝트의 협업으로 개발되었으며, vLLM의 핵심 엔진(스케줄러, API 서버, 토크나이저)은 그대로 유지하면서 Apple Silicon에 특화된 플랫폼, 워커, 모델 러너 계층을 플러그인으로 추가하는 구조입니다.
vLLM Metal의 아키텍처
vLLM Metal의 아키텍처는 크게 네 개의 계층으로 구성됩니다. 최상위에는 변경 없이 그대로 사용되는 vLLM Core가 있고, 그 아래에 Apple Silicon 전용 플러그인 계층이 위치합니다. 플러그인 계층은 MetalPlatform(하드웨어 감지 및 초기화), MetalWorker(추론 작업 관리), MetalModelRunner(모델 실행)의 세 컴포넌트로 구성됩니다. 그 아래에는 MLX와 PyTorch를 통합하는 Unified Compute Backend가 있으며, MLX가 SDPA Attention, RMSNorm, RoPE, Cache Ops 등 실제 연산을 담당하고, PyTorch는 Hugging Face 모델 로딩과 가중치 변환을 처리합니다. 최하단에는 Apple Silicon의 Metal GPU와 유니파이드 메모리가 위치합니다.
vLLM Metal 설치 및 실행
vLLM Metal은 단일 명령어로 설치할 수 있는 설치 스크립트를 제공합니다. 설치 스크립트는 ~/.venv-vllm-metal 디렉토리에 Python 3.12 가상환경과 함께 vLLM, MLX, 그리고 Metal 플러그인의 모든 의존성을 자동으로 설치합니다.
# vLLM Metal 원클릭 설치
curl -fsSL https://raw.githubusercontent.com/vllm-project/vllm-metal/main/install.sh | bash
# 가상환경 활성화
source ~/.venv-vllm-metal/bin/activate
# vLLM 서버 시작 (MLX 모델 사용)
vllm serve mlx-community/Qwen2.5-7B-Instruct-4bit \
--device metal \
--host 0.0.0.0 \
--port 8000
Paged Attention을 활성화하면 서빙 성능이 대폭 향상됩니다. 초기 벤치마크에서 Qwen3-0.6B 모델 기준으로 TTFT(Time To First Token)가 약 82배, 처리량이 약 3.75배 개선된 결과가 보고되었습니다. 다만 이 기능은 아직 실험적 단계이므로, 일부 모델에서는 안정성 이슈가 있을 수 있습니다.
# Paged Attention 활성화 (실험적)
VLLM_METAL_USE_PAGED_ATTENTION=1 vllm serve mlx-community/Qwen2.5-7B-Instruct-4bit \
--device metal \
--host 0.0.0.0 \
--port 8000
vLLM Metal의 주요 환경 변수 설정은 다음과 같습니다.
| 환경 변수 | 기본값 | 설명 |
| VLLM_METAL_MEMORY_FRACTION | auto | auto는 모델 로드에 필요한 만큼만 할당, 0.?로 메모리 비율 직접 지정 가능 |
| VLLM_METAL_USE_MLX | 1 | MLX 컴퓨트 사용 여부 (1=사용, 0=미사용) |
| VLLM_MLX_DEVICE | gpu | MLX 디바이스 선택 (gpu 또는 cpu) |
| VLLM_METAL_BLOCK_SIZE | 16 | KV 캐시 블록 크기 |
| VLLM_METAL_USE_PAGED_ATTENTION | 0 | Paged Attention 활성화 (1=활성화, 실험적) |
| VLLM_METAL_DEBUG | 0 | 디버그 로깅 활성화 |
vLLM Metal과 Docker Model Runner 통합
2026년 3월, Docker는 Docker Model Runner에 vLLM Metal 백엔드 지원을 공식 추가하였습니다. 이를 통해 Mac 사용자는 Docker의 통합 워크플로우 안에서 MLX 모델을 vLLM으로 서빙할 수 있게 되었습니다. Docker Model Runner는 MLX 모델 요청이 들어오면 자동으로 vLLM Metal 서버 프로세스를 시작하고, OpenAI 호환 API와 Anthropic Messages API를 모두 제공합니다. 이는 Claude Code와 같은 AI 개발 도구와의 통합도 가능하게 합니다.
다만 Apple의 Metal GPU는 컨테이너 내부에서 GPU 패스스루를 지원하지 않기 때문에, vLLM Metal은 호스트에서 네이티브로 실행됩니다. Docker Model Runner는 설치 시 vLLM Metal의 Python 환경을 ~/.docker/model-runner/vllm-metal/ 디렉토리에 추출하고, 요청 시 TCP 통신을 통해 vLLM Metal 서버와 연동하는 방식으로 작동합니다.
Apple Silicon vs NVIDIA GPU | 언제 무엇을 선택할 것인가
Apple Silicon에서의 vLLM 실행은 NVIDIA GPU 환경과는 다른 성격의 장점과 한계를 가지고 있습니다. Mac의 유니파이드 메모리는 대형 모델 로딩에서 압도적인 이점을 제공하지만, 순수 연산 처리량에서는 데이터센터 GPU에 미치지 못합니다. 아래 표는 두 환경의 특성을 비교한 것입니다.
| 비교항목 | Apple Silicon - vLLM Metal | NVIDIA GPU(vLLM CUDA) |
| 메모리 용량 | 최대 192GB (Mac Studio M3 Ultra) | 80GB (H100 SXM), 멀티 GPU로 확장 |
| 메모리 구조 | 유니파이드 메모리 (제로카피) | 분리된 VRAM (PCIe/NVLink 전송 필요) |
| 최대 모델 크기 | 단일 기기에서 400B+ 모델 로드 가능 | 단일 GPU 80GB, 다중 GPU 확장 필요 |
| 동시 처리 성능 | 다중 사용자 시 성능 저하 | Continuous Batching으로 수천 동시 요청 |
| 처리량 (TPS) | 134~345 tok/s (Llama 3.2 1B 4bit) | 793~8,033 TPS (모델/하드웨어에 따라) |
| 소음/전력 | 무소음, 저전력 | 팬 소음, 높은 전력 소비 |
| 비용 | Mac Studio ~$4,000~$10,000 | H100 GPU $10,000~$30,000 단일 카드 |
| 적합한 용도 | 개인 개발, 프로토타입, 소규모 서빙, 대형 모델 실험 | 프로덕션 대규모 서빙, 고동시성 API |
결론적으로, Apple Silicon에서의 vLLM 실행은 "대형 모델을 간편하고 조용하게 실행하면서 OpenAI 호환 API를 통해 서빙"하려는 개인 개발자나 소규모 팀에게 최적의 선택입니다. 특히 Mac의 대용량 유니파이드 메모리는 70B 이상의 대형 모델을 단일 기기에서 테스트하고 싶을 때 NVIDIA GPU 여러 장을 구비하는 것보다 훨씬 간편한 방법을 제공합니다. 반면 수백~수천 명의 동시 사용자를 처리해야 하는 프로덕션 서비스에서는 NVIDIA GPU 기반의 vLLM 배포가 여전히 유일한 선택입니다.
5. vLLM 설치 방법
vLLM은 크게 세 가지 방법으로 설치할 수 있습니다. pip을 이용한 직접 설치, Docker 컨테이너를 이용한 설치, 그리고 소스 코드에서 직접 빌드하는 방법이 있습니다. 각각의 방법은 사용 환경과 목적에 따라 장단점이 다르므로, 본인의 상황에 가장 적합한 방법을 선택하시기 바랍니다.
사전 요구사항
vLLM을 설치하기 전에 반드시 확인해야 할 시스템 요구사항이 있습니다. GPU 드라이버와 CUDA 버전이 호환되지 않으면 설치가 완료되더라도 정상적으로 작동하지 않을 수 있으므로, 아래 사항을 먼저 점검하시기 바랍니다.
| 요구사항 | 최소 권장 | 비고 |
| Python | 3.10 이상 (3.12 이상 권장) | 3.14 미만까지 지원 |
| GPU | NVIDIA GPU (Compute Capability 7.0+) | A100, H100, RTX 3090 이상 권장 |
| CUDA | 12.1 이상 | 최신 릴리즈는 CUDA 12.9~13.0 기반 |
| OS | Linux (Ubuntu 22.04 이상 권장) | Windows는 WSL2를 통해 사용 가능 |
| RAM | 16GB 이상 | 대형 모델은 64GB 이상 권장 |
| VRAM | 모델 크기에 따라 다름 | 7B 모델 기준 최소 16GB, 70B 모델은 80GB+ |
NVIDIA GPU 드라이버와 CUDA 설치 상태를 확인하는 방법은 다음과 같습니다.
# NVIDIA 드라이버 버전 확인
nvidia-smi
# CUDA 버전 확인
nvcc --versionpip을 이용한 설치 (권장)
vLLM 공식 문서에서는 uv라는 고속 Python 패키지 매니저를 사용한 설치를 권장하고 있습니다. uv는 기존 pip보다 훨씬 빠르고 안정적인 환경 관리를 제공합니다. 아래는 uv를 이용하여 vLLM을 설치하는 전체 과정입니다.
먼저 uv를 설치합니다. uv는 Rust로 작성된 차세대 Python 패키지 매니저로, pip 대비 10~100배 빠른 설치 속도를 제공합니다.
# uv 설치 (공식 설치 스크립트)
curl -LsSf https://astral.sh/uv/install.sh | sh
# 설치 확인
uv --version
다음으로 Python 가상환경을 생성하고 vLLM을 설치합니다. --torch-backend=auto 옵션은 시스템에 설치된 CUDA 드라이버 버전을 자동으로 감지하여 적절한 PyTorch 버전을 선택해줍니다.
# Python 3.12 기반 가상환경 생성
uv venv --python 3.12 --seed
# 가상환경 활성화
source .venv/bin/activate
# vLLM 설치 (CUDA 자동 감지)
uv pip install vllm --torch-backend=auto
설치가 완료되면, 간단한 명령어로 vLLM이 정상적으로 설치되었는지 확인할 수 있습니다.
# vLLM 버전 확인
python -c "import vllm; print(vllm.__version__)"
# vLLM 서버 도움말 확인
vllm serve --help[i] 만약 특정 CUDA 버전을 직접 지정하고 싶다면, --torch-backend=cu126과 같이 명시할 수 있습니다. 또한 가상환경을 만들지 않고 바로 실행하려면 uv run --with vllm vllm serve ... 명령어를 사용할 수도 있습니다.
Docker를 이용한 설치 (프로덕션 권장)
프로덕션 환경에서는 Docker 컨테이너를 이용한 배포가 재현성과 격리성 측면에서 가장 안정적입니다. vLLM은 공식 Docker 이미지(vllm/vllm-openai)를 제공하며, 이 이미지에는 vLLM과 모든 의존성이 사전 설치되어 있습니다.
먼저 NVIDIA Container Toolkit이 설치되어 있는지 확인합니다. 이 도구가 있어야 Docker 컨테이너 내부에서 GPU를 사용할 수 있습니다.
# NVIDIA Container Toolkit 설치 (Ubuntu)
distribution=$(. /etc/os-release;echo $ID$VERSION_ID)
curl -fsSL https://nvidia.github.io/libnvidia-container/gpgkey | sudo gpg --dearmor -o /usr/share/keyrings/nvidia-container-toolkit-keyring.gpg
curl -s -L https://nvidia.github.io/libnvidia-container/$distribution/libnvidia-container.list | \
sed 's#deb https://#deb [signed-by=/usr/share/keyrings/nvidia-container-toolkit-keyring.gpg] https://#g' | \
sudo tee /etc/apt/sources.list.d/nvidia-container-toolkit.list
sudo apt-get update && sudo apt-get install -y nvidia-container-toolkit
sudo nvidia-ctk runtime configure --runtime=docker
sudo systemctl restart docker
# GPU 접근 확인
docker run --rm --gpus all nvidia/cuda:12.6.0-base-ubuntu22.04 nvidia-smi
Docker로 vLLM 서버를 실행하는 방법은 다음과 같습니다. Hugging Face 모델을 자동으로 다운로드하여 OpenAI 호환 API 서버를 즉시 시작합니다.
# vLLM 공식 이미지 다운로드
docker pull vllm/vllm-openai:latest
# vLLM 서버 실행 (Llama 3.1 8B 예시)
docker run --runtime nvidia --gpus all \
-v ~/.cache/huggingface:/root/.cache/huggingface \
-p 8000:8000 \
--ipc=host \
--env "HUGGING_FACE_HUB_TOKEN=<your-token>" \
vllm/vllm-openai:latest \
--model meta-llama/Llama-3.1-8B-Instruct \
--dtype bfloat16 \
--gpu-memory-utilization 0.90 \
--max-model-len 8192 \
--host 0.0.0.0
위 명령어에서 각 옵션의 의미는 다음과 같습니다.
| 옵션 | 설명 |
| --runtime nvidia --gpus all | 컨테이너에서 모든 GPU를 사용할 수 있도록 설정 |
| -v ~/.cache/huggingface:... | 모델 캐시 디렉토리를 호스트와 공유하여 재다운로드 방지 |
| --ipc=host | 프로세스 간 공유 메모리 활성화 (멀티 GPU 시 필수) |
| --dtype bfloat16 | BFloat16 정밀도 사용 (H100 등 Ampere 이상 GPU에서 권장) |
| --gpu-memory-utilization 0.90 | GPU VRAM의 90%까지 사용 허용 |
| --max-model-len 8192 | 최대 시퀀스 길이를 8192 토큰으로 설정 |
프로덕션 배포 시에는 latest 대신 특정 버전 태그(예: v0.17.1)를 사용하여 재현 가능한 빌드를 유지하는 것을 권장합니다.
Docker Compose를 이용한 배포
여러 설정을 관리하고 반복적으로 배포해야 하는 환경에서는 Docker Compose를 사용하면 편리합니다. 다음은 vLLM 서버를 Docker Compose로 구성하는 예시입니다.
# docker-compose.yml
version: '3.8'
services:
vllm:
image: vllm/vllm-openai:v0.17.1
runtime: nvidia
ports:
- "8000:8000"
volumes:
- ~/.cache/huggingface:/root/.cache/huggingface
environment:
- HUGGING_FACE_HUB_TOKEN=${HF_TOKEN}
ipc: host
deploy:
resources:
reservations:
devices:
- driver: nvidia
count: all
capabilities: [gpu]
command: >
--model meta-llama/Llama-3.1-8B-Instruct
--dtype bfloat16
--gpu-memory-utilization 0.90
--max-model-len 8192
--max-num-seqs 256
--enable-chunked-prefill
--host 0.0.0.0
restart: unless-stopped
위 Compose 파일을 사용하여 서버를 시작하고 관리하는 명령어는 다음과 같습니다.
# 환경 변수 설정
export HF_TOKEN="your-huggingface-token"
# 서비스 시작
docker compose up -d
# 로그 확인
docker compose logs -f vllm
# 서비스 종료
docker compose down6. vLLM 주요 활용 및 실행 방법
vLLM은 크게 두 가지 모드로 활용할 수 있습니다. 첫 번째는 Python API를 직접 호출하는 오프라인 배치 추론(Offline Batch Inference) 모드이고, 두 번째는 OpenAI 호환 API 서버를 구동하여 HTTP 요청으로 추론하는 온라인 서빙(Online Serving) 모드입니다. 각각의 모드는 사용 목적에 따라 적합한 시나리오가 다릅니다.
오프라인 배치 추론 | Offline Batch Inference
대량의 프롬프트를 한꺼번에 처리해야 할 때, API 서버를 띄우지 않고 Python 코드에서 직접 vLLM을 호출하여 사용할 수 있습니다. 데이터 전처리, 대규모 텍스트 생성, 벤치마크 테스트 등에 적합한 방식입니다.
from vllm import LLM, SamplingParams
# 샘플링 파라미터 설정
sampling_params = SamplingParams(
temperature=0.8, # 생성 다양성 (0: 결정적, 1: 매우 다양)
top_p=0.95, # 상위 95% 확률의 토큰만 샘플링
max_tokens=512, # 최대 생성 토큰 수
)
# LLM 엔진 초기화
llm = LLM(
model="meta-llama/Llama-3.1-8B-Instruct",
dtype="bfloat16",
gpu_memory_utilization=0.90,
)
# 프롬프트 목록 정의
prompts = [
"인공지능의 미래에 대해 설명해주세요.",
"Python과 Rust의 장단점을 비교해주세요.",
"쿠버네티스의 핵심 개념을 초보자에게 설명해주세요.",
]
# 배치 추론 실행
outputs = llm.generate(prompts, sampling_params)
# 결과 출력
for output in outputs:
prompt = output.prompt
generated_text = output.outputs[0].text
print(f"[프롬프트] {prompt}")
print(f"[응답] {generated_text}")
print("-" * 80)
위 코드에서 SamplingParams의 주요 파라미터를 조절하면 생성 결과의 품질과 다양성을 제어할 수 있습니다. temperature를 0에 가깝게 설정하면 가장 확률이 높은 토큰만 선택하는 결정적(Greedy) 생성이 되며, 1에 가깝게 설정하면 더 다양하고 창의적인 결과를 얻을 수 있습니다.
온라인 API 서빙 | Online Serving
프로덕션 환경에서 가장 일반적인 사용 방식은 vLLM을 API 서버로 구동하는 것입니다. vLLM 서버는 OpenAI API와 완전히 호환되므로, 기존에 OpenAI API를 사용하던 애플리케이션의 base URL만 변경하면 바로 전환이 가능합니다.
다음 명령어로 vLLM API 서버를 시작합니다.
# vLLM API 서버 시작
vllm serve meta-llama/Llama-3.1-8B-Instruct \
--dtype bfloat16 \
--host 0.0.0.0 \
--port 8000 \
--gpu-memory-utilization 0.90 \
--max-model-len 8192 \
--max-num-seqs 256 \
--enable-chunked-prefill
서버가 시작되면 curl이나 Python의 OpenAI SDK를 이용하여 요청을 보낼 수 있습니다.
# curl을 이용한 Chat Completion 요청
curl http://localhost:8000/v1/chat/completions \
-H "Content-Type: application/json" \
-d '{
"model": "meta-llama/Llama-3.1-8B-Instruct",
"messages": [
{"role": "system", "content": "당신은 친절한 AI 어시스턴트입니다."},
{"role": "user", "content": "vLLM이 무엇인지 간단히 설명해주세요."}
],
"temperature": 0.7,
"max_tokens": 256
}'
Python OpenAI SDK를 이용한 방법은 다음과 같습니다. base_url만 vLLM 서버 주소로 변경하면 됩니다.
from openai import OpenAI
# vLLM 서버에 연결
client = OpenAI(
base_url="http://localhost:8000/v1",
api_key="dummy-key", # vLLM은 기본적으로 인증 불필요
)
# Chat Completion 요청
response = client.chat.completions.create(
model="meta-llama/Llama-3.1-8B-Instruct",
messages=[
{"role": "system", "content": "당신은 AI 기술 전문가입니다."},
{"role": "user", "content": "PagedAttention의 원리를 설명해주세요."},
],
temperature=0.7,
max_tokens=512,
stream=True, # 스트리밍 활성화
)
# 스트리밍 응답 출력
for chunk in response:
if chunk.choices[0].delta.content:
print(chunk.choices[0].delta.content, end="", flush=True)멀티 GPU 분산 추론
70B 이상의 대형 모델을 서빙할 때는 단일 GPU의 VRAM으로는 부족합니다. 이 경우 vLLM의 Tensor Parallelism을 활용하여 모델 가중치를 여러 GPU에 분할 적재할 수 있습니다. --tensor-parallel-size 옵션을 GPU 수에 맞게 설정하면 됩니다.
# 4개 GPU를 이용한 70B 모델 서빙
vllm serve meta-llama/Llama-3.1-70B-Instruct \
--dtype bfloat16 \
--tensor-parallel-size 4 \
--gpu-memory-utilization 0.90 \
--max-model-len 8192 \
--max-num-seqs 128 \
--host 0.0.0.0 \
--port 8000
--tensor-parallel-size는 반드시 사용 가능한 GPU 수와 동일하게 설정해야 합니다. vLLM은 자동으로 모델 가중치를 지정된 수의 GPU에 균등하게 분할하며, NVLink가 있는 환경(H100 SXM 등)에서는 GPU 간 통신 오버헤드가 최소화되어 거의 선형에 가까운 확장성을 보여줍니다.
Speculative Decoding 활용
Speculative Decoding은 작은 "드래프트 모델"이 여러 토큰을 미리 추측(Draft)하고, 큰 "타겟 모델"이 이를 한 번에 검증(Verify)하는 기법입니다. 검증을 통과한 토큰은 모두 한꺼번에 채택되므로, 이론적으로 한 스텝에 여러 토큰을 생성하는 효과를 얻을 수 있습니다. vLLM은 EAGLE, MTP, 드래프트 모델, n-gram 등 다양한 Speculative Decoding 방법을 지원합니다.
# Speculative Decoding 활성화 (드래프트 모델 사용)
vllm serve meta-llama/Llama-3.1-8B-Instruct \
--speculative-model meta-llama/Llama-3.2-1B-Instruct \
--num-speculative-tokens 5 \
--dtype bfloat16 \
--host 0.0.0.0 \
--port 8000Structured Output (구조화된 출력)
프로덕션 환경에서 LLM을 에이전트(Agent)나 함수 호출(Function Calling) 워크플로우에 통합할 때, JSON과 같은 구조화된 출력이 필수적입니다. vLLM은 JSON 스키마 검증, 정규식 기반 생성 제약, 문법 기반 가이드 디코딩 등을 지원하여 모델의 출력을 원하는 형식으로 강제할 수 있습니다.
from openai import OpenAI
client = OpenAI(
base_url="http://localhost:8000/v1",
api_key="dummy-key",
)
# JSON 스키마를 이용한 구조화된 출력
response = client.chat.completions.create(
model="meta-llama/Llama-3.1-8B-Instruct",
messages=[
{"role": "user", "content": "서울의 날씨 정보를 알려주세요."},
],
response_format={
"type": "json_schema",
"json_schema": {
"name": "weather_info",
"schema": {
"type": "object",
"properties": {
"city": {"type": "string"},
"temperature": {"type": "number"},
"condition": {"type": "string"},
"humidity": {"type": "number"},
},
"required": ["city", "temperature", "condition"],
},
},
},
)
print(response.choices[0].message.content)
# 출력 예시: {"city": "서울", "temperature": 15, "condition": "맑음", "humidity": 45}7. 권장 사용 사례
vLLM은 다양한 시나리오에서 활용될 수 있지만, 특히 다음과 같은 사용 사례에서 가장 큰 효과를 발휘합니다. 각 사례별로 왜 vLLM이 적합한지, 그리고 어떤 설정이 권장되는지를 상세히 설명하겠습니다.
기업 AI 챗봇 및 고객 서비스
수백~수천 명의 고객이 동시에 접속하는 AI 챗봇 서비스에서는 vLLM의 Continuous Batching과 낮은 P99 지연시간이 결정적인 장점을 제공합니다. 기존 OpenAI API를 사용하던 서비스가 자체 호스팅으로 전환할 때, vLLM의 OpenAI 호환 API 덕분에 애플리케이션 코드를 전혀 수정하지 않고도 base URL만 변경하여 마이그레이션할 수 있습니다. 월 수만 달러의 API 비용을 자체 GPU 인프라로 대체하여 비용을 대폭 절감한 사례도 다수 보고되고 있습니다.
RAG(Retrieval-Augmented Generation) 파이프라인
문서 검색 기반 생성(RAG) 시스템에서는 검색된 컨텍스트와 사용자 질문을 결합한 긴 프롬프트를 처리해야 합니다. vLLM의 Chunked Prefill 기능은 이러한 긴 프롬프트를 효율적으로 처리하며, Prefix Caching 기능을 통해 시스템 프롬프트나 반복되는 컨텍스트의 KV 캐시를 재사용할 수 있어 지연시간과 GPU 사용량을 모두 줄일 수 있습니다. 특히 동일한 시스템 프롬프트를 공유하는 다수의 사용자 요청에서 이 효과가 극대화됩니다.
AI 에이전트 및 함수 호출 워크플로우
AI 에이전트가 외부 도구를 호출하고 결과를 기반으로 추가 추론을 수행하는 워크플로우에서는, 모델의 출력이 정확한 JSON 형식을 따라야 합니다. vLLM의 Structured Output 기능은 JSON 스키마 검증과 정규식 기반 생성 제약을 지원하여, 에이전트가 안정적으로 도구를 호출하고 결과를 파싱할 수 있도록 보장합니다. 이는 Ollama 등 다른 도구에서는 지원이 제한적이거나 부재한 기능입니다.
다수 모델 동시 서빙 (Multi-LoRA)
하나의 기본 모델 위에 고객별, 도메인별로 미세조정(Fine-tuning)된 LoRA 어댑터를 수백 개 동시에 서빙해야 하는 SaaS 플랫폼에서 vLLM의 Multi-LoRA 기능은 핵심적인 역할을 합니다. 기본 모델의 가중치는 GPU에 한 번만 로드되고, 각 요청에 따라 경량의 LoRA 어댑터만 교체하므로, 메모리와 전환 비용을 최소화하면서 수많은 커스텀 모델을 동시에 서비스할 수 있습니다.
대규모 배치 데이터 처리
수만~수십만 건의 텍스트를 일괄 처리해야 하는 경우(예: 문서 분류, 감성 분석, 요약 생성), vLLM의 오프라인 배치 추론 모드가 적합합니다. PagedAttention의 메모리 효율성 덕분에 한 번에 더 많은 시퀀스를 배치에 포함시킬 수 있으며, 이는 전체 처리 시간의 단축으로 직결됩니다. 비실시간 작업이므로 --max-num-seqs를 512 이상으로 높여 처리량을 극대화할 수 있습니다.
사용 사례별 권장 설정 요약
| 사용 사례 | 핵심 설정 | 권장 GPU |
| 실시간 챗봇 (동시 100명+) | --max-num-seqs 256 --enable-chunked-prefill | H100 80GB x1~2 |
| RAG 파이프라인 (긴 컨텍스트) | --max-model-len 32768 --enable-chunked-prefill | A100 80GB x2+ |
| 70B+ 대형 모델 서빙 | --tensor-parallel-size 4 --kv-cache-dtype fp8 | H100 80GB x4 |
| Multi-LoRA SaaS | --enable-lora --max-loras 64 | A100/H100 x2 |
| 대규모 배치 처리 | --max-num-seqs 512+ --max-num-batched-tokens 65536 | A100 80GB x1+ |
8. vLLM의 최근 이슈 및 경쟁력
2025~2026년 주요 업데이트
vLLM은 2025년부터 2026년 초까지 놀라운 속도로 발전을 거듭하고 있습니다. 매월 새로운 버전이 릴리즈되며, 성능 개선과 새로운 기능 추가가 끊임없이 이루어지고 있습니다. 다음은 최근 1년간의 주요 업데이트 내역입니다.
- V1 엔진 아키텍처: 2025년 v0.6.0부터 기본 엔진으로 채택된 V1 엔진은 스케줄링 오버헤드를 대폭 줄였습니다. GPU와 CPU 간의 불필요한 텐서 복사를 제거하고, DMA(Direct Memory Access) 기반의 제로카피 전송을 도입하여 고동시성 환경에서의 스케줄링 병목을 해소하였습니다. V0 엔진은 공식적으로 지원이 중단(Deprecated)되었으며, xformers 백엔드도 함께 제거되었습니다.
- FlashAttention 4 통합: v0.17.0에서 FlashAttention 4 백엔드가 공식 지원되었습니다. 이전 세대 대비 향상된 어텐션 연산 성능을 제공하며, 특히 긴 시퀀스 처리에서 체감할 수 있는 속도 향상을 가져왔습니다.
- NVIDIA Blackwell GPU 지원: RTX Blackwell(SM120) 워크스테이션 GPU에 대한 NVFP4 MoE 커널 지원이 추가되었습니다. FP8 CUTLASS Group GEMM의 SM120 GPU 폴백 처리도 수정되어, 최신 NVIDIA 하드웨어에서의 안정성이 향상되었습니다.
- Model Runner V2 성숙: Pipeline Parallel, Decode Context Parallel, Eagle3 Speculative Decoding with CUDA Graphs, Pooling 모델 지원 등 Model Runner V2가 프로덕션 수준으로 성숙하였습니다. 새로운 --performance-mode 플래그(balanced, interactivity, throughput)를 통해 사용 시나리오에 맞는 최적화를 간편하게 적용할 수 있게 되었습니다.
- Qwen3.5 모델 패밀리 지원: GDN(Gated Delta Networks) 아키텍처를 사용하는 Qwen3.5 모델 패밀리가 완벽하게 지원됩니다. FP8 양자화, MTP Speculative Decoding, Reasoning Parser 등 고급 기능도 함께 지원합니다.
- Realtime API: v0.16.0에서 WebSocket 기반의 Realtime API가 도입되어, 스트리밍 오디오 인터랙션이 가능해졌습니다. 음성 AI 애플리케이션과의 통합이 한층 용이해진 것입니다.
경쟁 도구와의 비교
LLM 추론 엔진 시장에서 vLLM의 주요 경쟁 도구로는 NVIDIA TensorRT-LLM, Hugging Face TGI, SGLang 등이 있습니다. 각 도구는 고유한 강점과 약점을 가지고 있으며, 아래 표에서 핵심 차이점을 비교하였습니다.
| 비교 항목 | vLLM | TensorRT-LLM | TGI | SGLang |
| 라이선스 | Apache 2.0 | Apache 2.0 | HF License | Apache 2.0 |
| 핵심 강점 | 범용성, 모델 호환성, 커뮤니티 생태계 | NVIDIA GPU 최적 성능 | 간편한 배포, HF 통합 | 구조화된 생성, 공동설계 |
| 모델 호환성 | 매우 넓음 (Transformers 백엔드로 거의 모든 모델 지원) | 모델별 컴파일 필요, 지원 범위 제한 | 넓음 | 넓음 |
| 피크 처리량 | 매우 높음 | 최고 (NVIDIA 하드웨어 한정) | 보통 | 높음 |
| 설정 복잡도 | 중간 | 높음 (전문가 수준) | 낮음 | 중간 |
| Chunked Prefill | 지원 | 지원 | 미지원 | 지원 |
| 멀티모달 | 넓은 지원 | 제한적 | 제한적 | 지원 |
| 벤더 종속성 | 없음 (다중 하드웨어) | NVIDIA 종속 | 없음 | 없음 |
vLLM의 가장 큰 경쟁력은 범용성과 커뮤니티 생태계입니다. TensorRT-LLM이 NVIDIA 하드웨어에서 최고의 피크 성능을 제공하지만, 모델별 컴파일이 필요하고 벤더 종속성이 강합니다. vLLM은 NVIDIA뿐 아니라 AMD, Intel, TPU 등 다양한 하드웨어를 지원하며, Hugging Face 모델을 별도의 변환 과정 없이 바로 로드할 수 있습니다. 또한 Red Hat, NVIDIA, AMD, Intel 등 주요 기업이 공식적으로 vLLM 개발에 참여하고 있어, 오픈소스 프로젝트 중에서도 가장 활발한 커뮤니티를 보유하고 있습니다.
vLLM의 산업 채택 현황
2026년 현재 vLLM은 사실상 프로덕션 LLM 서빙의 업계 표준으로 자리매김하였습니다. Meta, Mistral AI, Cohere, IBM 등 주요 AI 기업들이 자사 모델 서빙에 vLLM을 활용하고 있으며, Google Cloud Vertex AI, Red Hat OpenShift AI, AWS 등 주요 클라우드 플랫폼에서도 vLLM을 공식 지원하고 있습니다. 특히 Red Hat은 vLLM의 최대 상업적 기여자(Leading Commercial Contributor)로서, vLLM에 최적화된 양자화 모델 저장소를 Hugging Face에서 운영하고 있습니다. NVIDIA 역시 매월 최적화된 vLLM Docker 컨테이너를 공식 배포하여, NVIDIA GPU 사용자들이 최고의 성능을 얻을 수 있도록 지원하고 있습니다.
마무리
이 글에서는 vLLM의 핵심 개념인 PagedAttention과 Continuous Batching의 동작 원리부터, Ollama와의 상세한 비교, 다양한 설치 방법, 실전 활용 코드, 권장 사용 사례, 그리고 최근 업데이트 동향까지 폭넓게 다루었습니다. vLLM은 단순한 추론 엔진을 넘어, LLM 서빙의 모든 측면을 아우르는 종합 플랫폼으로 빠르게 진화하고 있습니다.
핵심 내용을 정리하면 다음과 같습니다.
- 첫째, vLLM은 PagedAttention을 통해 GPU 메모리 낭비를 4% 미만으로 줄이고, Continuous Batching으로 GPU 활용률을 극대화하여 기존 대비 최대 24배의 처리량 향상을 달성합니다.
- 둘째, Ollama가 개발 편의성에 초점을 맞춘 반면, vLLM은 프로덕션 환경의 고성능 서빙에 최적화되어 있으며, 두 도구는 보완적으로 함께 활용할 수 있습니다.
- 셋째, OpenAI 호환 API를 지원하므로, 기존 OpenAI API 기반 애플리케이션을 코드 수정 없이 자체 호스팅 환경으로 전환할 수 있습니다.
LLM을 프로덕션에 배포하고자 하는 기업이나 개발자라면, vLLM은 반드시 검토해야 할 핵심 도구입니다. 먼저 Ollama로 아이디어를 빠르게 검증한 후, 프로덕션 단계에서 vLLM으로 전환하는 것이 가장 효율적인 워크플로우가 될 것입니다. vLLM의 활발한 커뮤니티와 빠른 업데이트 주기는, 빠르게 변화하는 AI 생태계에서 안정적인 기술적 기반을 제공해줄 것입니다.
참고 자료
- vLLM 공식 웹사이트: https://vllm.ai
- vLLM 공식 문서: https://docs.vllm.ai
- vLLM GitHub 저장소: https://github.com/vllm-project/vllm
- vLLM 블로그: https://blog.vllm.ai
- PyPI vLLM 패키지: https://pypi.org/project/vllm/
- vLLM 논문 (SOSP 2023): "Efficient Memory Management for Large Language Model Serving with PagedAttention"
- NVIDIA vLLM 릴리즈 노트: https://docs.nvidia.com/deeplearning/frameworks/vllm-release-notes/
- Red Hat - Ollama vs vLLM 벤치마크: https://developers.redhat.com/articles/2025/08/08/ollama-vs-vllm-deep-dive-performance-benchmarking
'AI 코딩' 카테고리의 다른 글
| .claude 폴더 구조 분석 (0) | 2026.03.30 |
|---|---|
| cmux - AI 코딩 에이전트 시대의 새로운 터미널 (0) | 2026.03.22 |
| Scrapling 설치부터 쿠팡 스크래핑까지 (0) | 2026.03.14 |
| Tailscale 완벽 가이드 (2편) - 설치부터 Zero Trust 네트워크 구축 (0) | 2026.02.07 |
| Tailscale 완벽 가이드 (1편) - 아키텍처 이해 (0) | 2026.02.07 |
