vLLM Recipes 개편: GPU를 고르면 서빙 명령이 나오는 레시피 사이트

vLLM 팀이 Recipes 사이트(recipes.vllm.ai)를 전면 개편하여 모델과 하드웨어 조합별로 최적화된 서빙 설정을 커뮤니티가 함께 유지·관리하는 플랫폼으로 탈바꿈시켰다. 하드웨어 피커(Hardware Picker)와 복사 가능한 vllm serve 명령어, 전체 JSON API를 제공함으로써, 프로덕션 LLM 인프라 구축 시 거쳐야 했던 긴 시행착오를 대폭 단축할 수 있게 되었다. 여기서는 vLLM Recipes 개편의 핵심 내용과 PagedAttention·연속 배치·텐서 병렬처리(Tensor Parallelism) 등 vLLM의 핵심 아키텍처 설계 원리, 그리고 프로덕션 환경에서의 실전 최적화 전략을 짚는다.

GPU를 고르면 명령이 나온다

기존 vLLM 문서는 모델별 서빙 옵션을 산발적으로 다루고 있어, 특정 GPU에서 특정 모델을 최적으로 띄우는 방법을 찾으려면 여러 이슈와 커뮤니티 포럼을 뒤져야 했다. 개편된 Recipes 사이트는 이 문제를 정면으로 해결한다.

인터랙티브 하드웨어 피커는 모델과 GPU를 선택하면 그에 맞는 최적 vllm serve 명령어가 자동으로 생성되며, NVIDIA H100/H200/B200/B300, Grace-Blackwell, AMD MI300X/MI325X/MI355X 등 주요 GPU를 모두 지원한다. 새로운 레시피는 models/<hf_org>/<hf_repo>.yaml 경로의 구조화된 YAML 파일로 관리되는 YAML 기반 레시피 구조를 쓰며, VRAM 계산 공식과 유효성 검증 단계가 포함된 기여(CONTRIBUTING) 가이드를 통해 커뮤니티가 직접 레시피를 추가·수정할 수 있다. recipes.vllm.ai의 전체 데이터를 JSON API로 조회할 수 있어 CI/CD 파이프라인이나 내부 플랫폼에 자동으로 연동하는 것도 가능해졌다. 지원 모델도 확대되고 있어 Llama 4 Scout/Maverick, Qwen3.5/3.6, Gemma 4, GLM-5/5.1, Kimi-K2.6 등 최신 대규모 언어 모델(LLM) 레시피가 활발히 추가되고 있다.

⤢✕

단편화를 없앤 메모리 관리, PagedAttention

PagedAttention은 vLLM이 기존 LLM 서빙 프레임워크 대비 수배 높은 처리량(Throughput)을 달성하게 해주는 핵심 메모리 관리 알고리즘이다.

트랜스포머 모델에서 어텐션(Attention) 연산은 이전 토큰들의 Key-Value(KV) 캐시를 참조한다. 기존 방식은 각 요청의 최대 시퀀스 길이만큼 연속적인 GPU 메모리를 사전 할당했다. 이 방식은 실제 시퀀스가 최대 길이보다 짧으면 사전 할당된 메모리의 상당 부분이 낭비되는 내부 단편화(Internal Fragmentation)와, 요청마다 연속 메모리 블록을 요구하므로 사용 가능한 메모리가 충분해도 새 요청을 수용하지 못하는 외부 단편화(External Fragmentation)라는 두 가지 심각한 문제를 낳는다.

PagedAttention은 운영체제의 가상 메모리(Virtual Memory) 개념을 GPU KV 캐시에 적용했다. 각 시퀀스의 KV 캐시는 논리 블록 테이블(Logical Block Table)을 통해 GPU 메모리 내의 비연속적인 물리 블록(Physical Block)에 매핑된다. 고정 크기의 블록(기본값 16토큰)으로 메모리를 분할하고, 필요한 블록만 그때그때 할당하는 온디맨드 할당을 쓰며, 동일한 시스템 프롬프트를 공유하는 요청들은 KV 캐시 블록을 재사용하는 공유 프리픽스(Prefix Sharing)를 지원한다. 그 결과 KV 캐시 낭비율을 4% 미만으로 줄임으로써 같은 GPU에서 2~4배 많은 동시 요청을 처리할 수 있다.

⤢✕

자리가 비면 바로 채우는 연속 배치

전통적인 정적 배치(Static Batching) 방식은 배치 내 모든 요청이 완료될 때까지 새 요청을 받지 않는다. 짧은 요청이 완료되어도 긴 요청이 끝날 때까지 GPU가 그 자리를 차지하며, 이는 GPU 활용률을 크게 저하시킨다.

연속 배치(또는 롤링 배치, Iteration-level Scheduling)는 각 디코딩 스텝마다 스케줄링 결정을 내린다. 한 요청이 종료 토큰(EOS)을 생성하는 순간 그 슬롯이 해제되고, 대기 중인 새 요청이 즉시 채워진다. 이 방식과 PagedAttention이 결합되면 시너지가 극대화된다. 새 요청이 들어올 때 연속 메모리 블록이 아닌 여유 블록만 있으면 즉시 수용할 수 있으므로, 배치 점유율이 항상 높게 유지된다. 결과적으로 동일한 H100에서 단순 PyTorch 추론 루프 대비 3~5배 많은 트래픽을 처리할 수 있다.

한 GPU에 안 들어가는 모델을 나눠 서빙하기

단일 GPU 메모리를 초과하는 대형 모델은 여러 GPU에 분산하여 서빙해야 한다. vLLM은 텐서 병렬처리(TP)와 파이프라인 병렬처리(PP)를 모두 지원한다.

텐서 병렬처리는 각 트랜스포머 레이어의 가중치 행렬(Weight Matrix)을 여러 GPU에 분할하여 저장하고, 행렬 곱셈 연산을 GPU 간에 분산 수행한다. 각 GPU는 전체 가중치의 1/N만 보유하되, 활성화(Activation)는 AllReduce 연산을 통해 동기화된다. --tensor-parallel-size N(N은 GPU 수)으로 설정하며, Attention 레이어의 QKV 프로젝션 및 출력 프로젝션, FFN 레이어의 업/다운 프로젝션에 적용되고, 2~8+ GPU 구성을 지원한다. 파이프라인 병렬처리(PP)는 레이어 단위로 분할하며, TP와 PP를 조합하면 수십 개의 GPU에 걸쳐 100B+ 파라미터 모델도 효율적으로 서빙할 수 있다.

⤢✕

레시피를 실무에 맞게 조정하는 법

개편된 Recipes 사이트를 가장 효과적으로 활용하는 방법은 단순히 명령어를 복사하는 것을 넘어, 설정 파라미터의 의미를 이해하고 자신의 워크로드에 맞게 조정하는 것이다.

모델을 로드하기 위한 최소 GPU 수를 먼저 파악해야 한다. 기본 공식은 다음과 같다.

필요 VRAM ≈ (파라미터 수 × 정밀도 바이트 수) + KV 캐시
예: 70B 모델 BF16 → 70B × 2bytes ≈ 140GB → H100 80GB 기준 2장 필요

Recipes의 YAML은 이 VRAM 계산을 사전 수행하여 권장 GPU 수를 제시한다.

핵심 서빙 파라미터는 다음과 같다.

파라미터	기본값	설명	조정 방향
`--gpu-memory-utilization`	0.90	GPU VRAM 중 vLLM이 사용할 비율	처리량 최대화 시 0.95까지 증가
`--max-num-batched-tokens`	모델 의존	한 배치에 처리할 최대 토큰 수	>8192면 처리량↑, 작으면 지연↓
`--tensor-parallel-size`	1	텐서 병렬화 GPU 수	모델 크기에 따라 2/4/8 설정
`--max-model-len`	모델 의존	처리할 최대 시퀀스 길이	메모리 부족 시 줄여서 해결
`--kv-cache-dtype`	auto	KV 캐시 저장 타입	FP8로 설정 시 VRAM 절약

고정 하드웨어 환경에서 권장하는 배포 전략은 모델 로드에 필요한 최소 GPU 수를 식별하고, 그 최소 구성으로 최대한 많은 레플리카(Replica)를 배포하며, 다양한 동시 요청 수(Concurrency) 수준에서 성능을 테스트한 뒤, 필요에 따라 레플리카당 GPU 수를 늘려 최적 균형점을 찾는 순서를 따른다. 이 접근법은 GPU 자원을 단일 고성능 인스턴스에 집중하는 대신, 수평 확장(Horizontal Scaling)을 통해 처리량을 극대화한다.

KV 캐시를 더 아끼는 고급 기법들

H100/A100에서 --kv-cache-dtype fp8을 설정하면 KV 캐시 저장 타입을 BF16에서 FP8으로 전환하는 FP8 KV 캐시 양자화가 가능하다. 메모리 사용량이 절반으로 줄어들어 같은 VRAM에서 더 많은 KV 캐시를 수용할 수 있으며, 대부분의 프로덕션 워크로드에서 품질 저하는 무시할 수 있는 수준이다.

vLLM 0.11.0부터 도입된 KV 캐시 오프로딩 기능(LMCache 연동)은 GPU VRAM 압력을 CPU DRAM으로 분산한다. Llama-3.1-8B-Instruct + H100 환경 벤치마크에서 TTFT(Time-To-First-Token) 4배 감소, 처리량 5배 증가가 확인되었다.

긴 프롬프트 처리 시 프리필(Prefill) 단계가 디코딩(Decoding) 단계를 차단하는 문제가 있다. Chunked Prefill은 긴 프리필을 작은 청크로 분할하여 디코딩 요청과 인터리빙(Interleaving) 처리한다. 이를 통해 긴 컨텍스트 요청이 있을 때도 짧은 요청의 지연 시간이 급증하지 않는다.

⤢✕

인스턴스를 어떻게 쪼갤 것인가

전략	장점	단점	적합한 상황
단일 대형 인스턴스 (8xH100)	큰 배치 처리 가능, 낮은 레이턴시	장애 시 전체 중단, 고비용	연구·내부 툴, 낮은 QPS
다수 소형 레플리카 (1-2xH100 × N)	고가용성, 점진적 확장	네트워크 오버헤드, 로드밸런서 필요	프로덕션 API, 높은 QPS

vLLM 0.8 이후 도입된 프로덕션 스택(Production Stack) 아키텍처는 여러 vLLM 인스턴스 앞단에 라우터를 배치한다. KV 캐시 인식 라우팅(KV Cache Aware Routing)을 통해 동일한 프리픽스를 공유하는 요청을 같은 인스턴스로 보내 캐시 히트율을 높인다.

프로덕션 vLLM 배포에서 반드시 추적해야 할 지표는 90% 이상이면 OOM 위험 신호인 GPU KV 캐시 사용률, 큐가 쌓이면 처리량 한계에 도달했다는 의미인 요청 큐 대기 시간, 배치 크기와 함께 추적하여 효율성을 평가하는 토큰 처리 속도(TPS), 사용자 경험에 직결되는 TTFT/TPOT다.

vLLM Recipes의 전면 개편은 "모델 X를 하드웨어 Y에서 어떻게 실행하는가"라는 현장의 핵심 질문에 커뮤니티 집단지성으로 답하는 플랫폼으로 진화했다는 점에서 의미가 크다. PagedAttention·연속 배치·텐서 병렬처리의 조합이 만들어내는 vLLM의 고성능 서빙 아키텍처는 여전히 오픈소스 LLM 인프라의 기준점으로 자리잡고 있으며, KV 오프로딩·FP8 양자화·Chunked Prefill 등의 고급 기법이 프로덕션 환경에서의 실용성을 더욱 높이고 있다. 프로덕션 LLM 서비스를 구축하는 팀이라면 recipes.vllm.ai를 출발점으로 삼아 하드웨어별 검증된 설정을 확인하고, 자신의 워크로드 특성에 맞게 세밀하게 튜닝하는 접근을 권장한다.