vLLM 완벽 해부 — LLM 추론 엔진의 표준이 된 진짜 이유

vLLM 완벽 해부 — LLM 추론 엔진의 표준이 된 진짜 이유

PagedAttention부터 Continuous Batching까지, 그리고 TensorRT-LLM·SGLang·TGI 관련 도메인 총정리

AI 인프라 LLM Serving PagedAttention 2026 최신

GPU 한 장으로 더 많은 사용자를 받을 수 있다면? 추론 비용을 절반으로 줄일 수 있다면? 2023년 UC 버클리에서 시작된 vLLM은 단순히 "빠른 라이브러리" 수준이 아니라, 운영체제의 가상 메모리 개념을 LLM에 이식해 업계 표준이 된 추론 엔진이다. 이 글은 vLLM이 왜 만들어졌는지, 핵심 기술인 PagedAttention이 정확히 무엇을 해결하는지, 그리고 TensorRT-LLM·SGLang·TGI 같은 경쟁자들과 어떻게 다른지를 한 번에 정리한다.

vLLM이란 무엇인가

vLLM은 대규모 언어모델(LLM)의 추론(inference)과 서빙(serving)을 위한 오픈소스 엔진이다. 2023년 UC 버클리 Sky Computing Lab에서 시작됐고, 2024년 7월 Linux Foundation에 기증된 뒤 2025년 PyTorch Foundation 호스팅 프로젝트로 편입됐다. 현재 2,000명이 넘는 기여자가 참여하는 가장 활발한 오픈소스 AI 프로젝트 중 하나다.

프로젝트 이름의 "v"는 원래 "virtual"을 의미했다. 가상 메모리(virtual memory)에서 영감을 받았다는 뜻이다. 이게 핵심이다. vLLM은 GPU 메모리를 마치 운영체제가 RAM을 다루듯 페이지 단위로 관리한다.

한 줄 요약

vLLM = PagedAttention(메모리 관리) + Continuous Batching(스케줄링) + OpenAI 호환 API. 이 세 가지로 같은 GPU에서 2~4배 더 많은 요청을 처리한다.

왜 vLLM이 필요했나 — KV 캐시라는 골칫거리

LLM은 한 토큰씩 순차적으로 텍스트를 생성한다. 100번째 토큰을 만들려면 앞선 99개 토큰을 모두 다시 봐야 한다. 매번 처음부터 계산하면 끔찍하게 느려지므로, 엔지니어들은 KV 캐시(Key-Value Cache)라는 트릭을 쓴다. 이전 토큰들의 어텐션 중간값을 GPU 메모리에 저장해 두는 것이다.

문제는 KV 캐시가 요청마다 크기가 다르고, 생성 도중 계속 늘어난다는 점이다. 어떤 사용자는 5단어 답변을 원하고, 어떤 사용자는 5,000단어 에세이를 원한다. 기존 시스템은 "일단 최대 길이만큼 통째로" 메모리를 잡아 뒀다. 결과는 처참했다.

기존 방식

통짜 연속 메모리 할당

요청마다 최대 길이만큼 GPU 메모리를 미리 잡음. 짧은 답변에도 큰 공간을 점유하고, 사용 안 한 영역이 그대로 낭비됨.

vLLM 방식

PagedAttention

OS의 가상 메모리처럼 작은 페이지 단위로 KV 캐시를 분산 저장. 필요할 때 필요한 만큼만 할당, 끝나면 즉시 회수.

연구 결과에 따르면 기존 추론 엔진은 GPU 메모리의 60~80%를 낭비하고 있었다. 즉 절반 넘는 비싼 H100 VRAM이 빈 공간이었다는 뜻이다. vLLM은 이 낭비율을 4% 아래로 떨어뜨렸다.

60~80%

기존 엔진의 KV 캐시 메모리 낭비율

< 4%

vLLM의 메모리 낭비율

2~4×

기존 대비 처리량(throughput) 개선

최대 24×

HuggingFace Transformers 대비 처리량

핵심 기술 1 — PagedAttention

PagedAttention의 발상은 단순하면서도 천재적이다. "운영체제는 RAM 부족 문제를 50년 전에 풀었잖아? 그 해법을 그대로 GPU에 가져오자."

작동 원리

1) KV 캐시를 고정 크기의 작은 블록(페이지)으로 쪼갠다.
2) 각 블록은 GPU 메모리 어디든 흩어져 있어도 된다 — 연속될 필요가 없다.
3) 블록 테이블(block table)이라는 매핑 자료구조가 "논리 블록 → 물리 블록"을 추적한다.
4) 새 토큰이 생성되면 새 블록을 동적으로 할당하고, 시퀀스가 끝나면 즉시 해제한다.

이 구조 덕분에 외부 단편화(external fragmentation)는 완전히 사라지고, 내부 단편화도 마지막 블록 한 개분으로 줄어든다. 운영체제 수업의 페이징(paging) 개념을 그대로 가져온 것이다.

덤으로 얻는 이득 — KV 캐시 공유

논리/물리 블록이 분리돼 있으니, 같은 시스템 프롬프트를 쓰는 여러 요청이 동일한 물리 블록을 공유할 수 있다. Beam search·Parallel sampling 같은 디코딩 알고리즘에서도 prefix를 공유해 메모리를 추가로 절약한다. 이게 나중에 Prefix Caching으로 발전한다.

핵심 기술 2 — Continuous Batching

PagedAttention이 메모리 문제를 풀자, 또 다른 보너스가 따라왔다. 연속 배칭(Continuous Batching)이다.

Static Batching

정적 배칭

요청 10개를 모아 한 번에 처리. 사용자 A가 5단어, B가 500단어를 원하면 GPU는 B가 끝날 때까지 기다림. A는 이미 끝났는데 자리에서 빠져나갈 수 없음.

Continuous Batching

연속 배칭

버스 정류장처럼 동작. A가 5단어 받자마자 바로 빠지고, 대기 중이던 C가 다음 스텝부터 즉시 합류. GPU는 한순간도 놀지 않음.

이 두 가지(PagedAttention + Continuous Batching)가 바로 vLLM이 같은 GPU로 4배 더 많은 사용자를 받을 수 있는 이유다. 실제로 Chatbot Arena·Vicuna를 운영하는 LMSYS는 vLLM 도입 후 GPU 수를 50% 줄이면서도 초당 요청 처리량을 2~3배 늘렸다.

vLLM의 주요 기능 한눈에 보기

PagedAttention

KV 캐시 페이징, 메모리 낭비 4% 미만

Continuous Batching

요청 단위가 아닌 토큰 스텝 단위 스케줄링

Prefix Caching

동일 시스템 프롬프트 재사용으로 TTFT 단축

Speculative Decoding

소형 draft 모델이 미리 토큰 예측, 2~3배 가속

Chunked Prefill

긴 입력을 잘게 나눠 디코딩 지연 최소화

Quantization

FP8 / INT8 / INT4 / GPTQ / AWQ / GGUF 지원

Tensor / Pipeline Parallelism

멀티 GPU·멀티 노드 분산 추론

OpenAI 호환 API

기존 OpenAI SDK 코드를 그대로 재사용

Disaggregated Prefill

Prefill과 Decode를 별도 서버로 분리 (2026)

Realtime Audio API

OpenAI Realtime 호환 WebSocket 스트리밍

관련 도메인 총정리 — 경쟁 엔진들

"LLM 추론 엔진"은 vLLM 하나가 아니다. 각 엔진은 서로 다른 문제를 우선순위로 둔다. 2026년 기준 실전에서 마주칠 주요 엔진을 정리하면 다음과 같다.

엔진	개발 주체	핵심 기술	가장 잘하는 것
vLLM	UC Berkeley → PyTorch Foundation	PagedAttention	균형, 모델 폭, 하드웨어 다양성
TensorRT-LLM	NVIDIA	커널 컴파일·하드웨어 특화	NVIDIA GPU에서 절대 성능
SGLang	UC Berkeley (LMSYS)	RadixAttention	공유 prefix 워크로드, 구조화 출력
TGI	Hugging Face	Rust 기반 서버	HF 생태계 통합, 운영 안정성
LMDeploy	OpenMMLab	TurboMind 커널	고속 디코딩, 양자화
llama.cpp	Georgi Gerganov	GGUF · CPU 최적화	엣지·CPU·저전력 환경
Ollama	Ollama 팀	llama.cpp 래퍼	로컬 개발, 즉시 실행

TensorRT-LLM — 절대 성능의 챔피언

NVIDIA가 자기 GPU에 맞춰 만든 엔진. H100에서 vLLM 대비 10~30% 더 높은 처리량을 뽑는다. 단점은 명확하다. NVIDIA에 락인되고, 모델마다 컴파일 단계를 거쳐야 하며, 셋업에만 며칠~몇 주가 걸린다. 모델을 자주 바꾸지 않는 초대규모 서비스(예: Perplexity)에 적합하다.

SGLang — RAG와 에이전트의 비밀 무기

PagedAttention 위에 RadixAttention을 얹은 엔진. KV 캐시를 트라이(trie) 구조로 관리해 동일한 prefix를 가진 요청들이 자동으로 캐시를 공유한다. 시스템 프롬프트가 길거나, 같은 문서에 대해 여러 질문을 던지는 RAG, 멀티턴 에이전트 워크로드에서 vLLM보다 TTFT(첫 토큰 응답시간)가 30~40% 빠를 수 있다.

TGI — Hugging Face 생태계의 표준

Rust + Python 조합으로 만들어진 안정성 중심 서버. 헬스체크, Prometheus 메트릭, 분산 트레이싱 등 운영 기능이 가장 성숙하다. 단, 2026년 들어 핵심 개발이 둔화되며 사실상 유지보수 모드라는 평가가 늘고 있다. HF Inference Endpoints를 그대로 쓸 거면 여전히 합리적 선택.

llama.cpp · Ollama — 로컬과 엣지의 왕

GPU 없이 CPU만으로도 모델을 돌릴 수 있는 경량 엔진. llama.cpp가 코어 라이브러리고, Ollama는 그 위에 "그냥 명령 한 줄이면 끝"인 사용자 경험을 입힌 래퍼다. 노트북에서 7B/8B 모델을 돌려보고 싶다면 사실상 답이 정해져 있다.

상황별 추천 — 어떤 엔진을 골라야 할까

상황	추천 엔진	이유
개인 PC에서 모델 테스트	Ollama	설치 1분, GPU 없어도 동작
스타트업 첫 프로덕션 서빙	vLLM	균형, 문서, 모델 호환성
HF 모델 위주 + 운영 안정성	TGI	HF 생태계와 즉시 연결
NVIDIA H100 풀가동	TensorRT-LLM	같은 GPU에서 최대 성능
RAG · 에이전트 · 구조화 출력	SGLang	RadixAttention 효과
온디바이스 · 엣지 · CPU 서버	llama.cpp	가장 가벼움, 양자화 지원
AMD GPU 환경	vLLM	ROCm 지원, 옵션이 가장 넓음

현장에서 자주 보는 실수

엔진 선택보다 양자화 전략·프롬프트 길이 관리·컨텍스트 윈도우 사이즈가 비용에 더 큰 영향을 준다. 잘못 양자화한 모델은 어떤 엔진을 써도 느리다. 엔진 교체로 시간을 쓰기 전에 모델 자체의 최적화부터 점검하는 것이 정석이다.

vLLM 생태계와 미래

2025년 7월 UC 버클리는 vLLM을 Linux Foundation에 기증했고, 이후 PyTorch Foundation의 호스팅 프로젝트가 됐다. 이는 단순한 학술 프로젝트가 아니라 업계 공동 자산으로 자리 잡았다는 의미다. NVIDIA, AMD, Intel, AWS, Google Cloud 등 거의 모든 메이저 인프라 기업이 vLLM 호환을 기본 옵션으로 제공한다.

2026년 현재 vLLM이 밀고 있는 방향은 세 가지다.

• Disaggregated Prefill / Decode — Prefill 단계와 Decode 단계는 GPU 자원 사용 패턴이 완전히 다르다. 두 단계를 별도 서버로 분리해 각각 최적화된 하드웨어에서 돌리는 구조.
• Speculative Decoding 고도화 — EAGLE, Medusa, n-gram 등 다양한 추측 디코딩 알고리즘을 기본 탑재해 단일 사용자 응답 속도를 끌어올림.
• 멀티모달·MoE 1급 지원 — DeepSeek-V3, Qwen-VL, Mixtral 등 새로운 아키텍처가 출시 직후부터 vLLM에서 돌아가도록 지원.

"vLLM은 단순한 엔지니어링 최적화가 아니다. 컴퓨트가 가장 비싼 자원이 된 시대에 비용을 직접 줄이는 인프라다." — 2026 업계 관측

정리하며

vLLM이 표준이 된 이유는 결국 단순하다. 가장 비싼 자원(GPU)을 가장 적게 낭비하는 방법을 찾았기 때문이다. PagedAttention으로 메모리 낭비를 4% 아래로 떨어뜨렸고, Continuous Batching으로 GPU를 한순간도 놀리지 않게 만들었다. 그 결과 같은 하드웨어로 2~4배의 처리량을 뽑아낸다. 추론 비용이 곧 AI 서비스의 손익분기점인 시대에 이건 단순한 기술적 우위가 아니라 사업적 우위다. 처음 LLM 서빙을 시작한다면 vLLM이 정답이고, 더 들어가면 SGLang·TensorRT-LLM·TGI 중 워크로드에 맞는 것을 더하는 그림이 된다.

Tags

#vLLM #LLM추론엔진 #PagedAttention #KV캐시 #ContinuousBatching #TensorRTLLM #SGLang #LLM서빙 #AI인프라 #GPU최적화