vLLM 프로덕션 배포: 고처리량 추론 서빙 아키텍처 구축
2025년 12월 11일 업데이트
2025년 12월 업데이트: Stripe는 vLLM 마이그레이션을 통해 73%의 추론 비용 절감 달성 (기존 GPU 플리트의 1/3로 일일 5천만 API 호출 처리). PagedAttention은 KV 캐시 단편화로 인한 60-80% 메모리 낭비 제거. vLLM은 기존 서빙 방식 대비 2-24배 처리량 제공. Meta, Mistral AI, Cohere, IBM에서 프로덕션 구동. OpenAI 호환 API로 도입 간소화.
Stripe의 ML 플랫폼 팀은 Hugging Face Transformers에서 vLLM으로 마이그레이션한 후 추론 비용이 73% 감소하는 것을 목격했으며, 기존 GPU 플리트의 1/3로 동일한 일일 5천만 API 호출을 처리했습니다.¹ vLLM 효율성의 비밀은 PagedAttention에 있습니다. 이 알고리즘은 GPU 메모리를 운영체제의 가상 메모리처럼 처리하여 기존 추론 시스템에서 메모리의 60-80%를 낭비하는 단편화를 제거합니다.² 프로덕션 LLM 워크로드를 운영하는 조직들은 vLLM이 기존 서빙 프레임워크 대비 2-24배의 처리량 개선을 제공하여 대규모 대형 언어 모델 배포의 경제성을 변화시킨다는 것을 발견하고 있습니다.³
추론 서빙 환경은 수십 가지 옵션으로 분화되고 있습니다: TensorRT-LLM은 최대 NVIDIA 최적화를 약속하고, Hugging Face TGI는 친숙한 통합을 제공하며, Ollama는 로컬 배포를 간소화합니다. 그러나 vLLM은 프로덕션 워크로드의 지배적인 선택으로 부상했으며, Meta, Mistral AI, Cohere, IBM에서 추론을 구동하고 있습니다.⁴ 프레임워크의 PagedAttention, 연속 배칭, OpenAI 호환 API 조합은 원시 성능과 운영 단순성의 균형을 맞춘 배포 경험을 만들어냅니다. vLLM의 아키텍처와 배포 패턴을 이해하는 것이 비용 효율적인 추론을 달성하는 조직과 GPU 비용에 허우적대는 조직을 구분하는 요소입니다.
PagedAttention이 메모리 관리를 혁신하다
기존 LLM 추론은 각 시퀀스의 key-value (KV) 캐시를 위해 연속된 메모리 블록을 할당하며, 실제 사용량에 관계없이 최대 가능한 시퀀스 길이를 위한 공간을 예약합니다. 4,096 토큰으로 구성된 시스템은 100 토큰 응답에도 전체 메모리를 할당하여 예약된 용량의 97%를 낭비합니다. 이를 수백 개의 동시 요청으로 곱하면 실제 시퀀스가 리소스를 기다리며 대기하는 동안 GPU 메모리는 빈 예약으로 가득 찹니다.
PagedAttention은 GPU 메모리를 일반적으로 16 토큰씩의 고정 크기 페이지로 분할하여 이 아키텍처를 재구상합니다.⁵ 각 시퀀스는 연속적인 할당 대신 페이지 참조 목록을 유지하여 몇 가지 혁신적인 기능을 가능하게 합니다:
비연속 저장을 통해 KV 캐시 블록이 사용 가능한 GPU 메모리 전반에 분산될 수 있습니다. 시스템은 더 이상 큰 연속 영역이 필요하지 않아 기존 할당자를 괴롭히던 단편화를 제거합니다. 2,000 토큰 시퀀스는 공간이 있는 곳마다 분산된 125개 페이지에 캐시를 저장합니다.
동적 할당은 시퀀스가 증가할 때만 메모리를 제공합니다. 첫 번째 토큰은 하나의 페이지를 할당하고, 17번째 토큰은 두 번째 페이지 할당을 트리거합니다. 메모리 소비는 이론적 최대값이 아닌 실제 사용량을 추적하여 효과적인 용량을 극적으로 개선합니다.
메모리 공유를 통해 동일한 프롬프트 접두사가 요청 간에 KV 캐시 페이지를 공유할 수 있습니다. 동일한 시스템 프롬프트의 변형을 묻는 열 명의 사용자가 해당 접두사의 단일 캐시된 사본을 공유하여 일반적인 패턴에 대해 메모리 소비를 90% 줄입니다. 표준화된 프롬프트를 가진 프로덕션 시스템은 400%를 초과하는 활용도 개선을 봅니다.⁶
거의 제로 낭비는 정적 할당에서 일반적인 내부 단편화를 제거합니다. 기존 시스템은 부분적으로 채워진 블록에서 시퀀스당 평균 4.1 토큰을 낭비합니다. PagedAttention의 페이지 수준 세분성은 낭비를 페이지의 일부로 줄여 길이에 관계없이 일반적으로 시퀀스당 8 토큰 미만입니다.
이 알고리즘은 운영체제 가상 메모리에서 직접 영감을 받아 수십 년의 메모리 관리 연구를 GPU 추론에 적용합니다. 현대 운영체제가 가상 주소를 물리적 메모리 페이지에 매핑하는 것처럼, PagedAttention은 논리적 KV 캐시 위치를 물리적 GPU 메모리 블록에 매핑합니다. 번역 오버헤드는 각 attention 계산에 마이크로초를 추가하지만 기가바이트의 메모리 용량을 절약합니다.
연속 배칭이 GPU 활용도를 극대화하다
정적 배칭은 고정된 수의 요청을 함께 처리하기 전에 대기하여 배치가 부분적으로 채워질 때 지연 시간 스파이크를 만들고 요청이 불균등하게 도착할 때 처리량 저하를 야기합니다. 배치 크기가 32인 경우 31번째 요청은 처리가 시작되기 전에 하나 더 도착하기를 기다려야 하며, 이는 트래픽이 적은 기간 동안 잠재적으로 몇 초의 지연 시간을 추가할 수 있습니다.
vLLM의 연속 배칭은 배치 경계를 완전히 제거합니다.⁷ 스케줄러는 요청 수준이 아닌 반복 수준에서 작동하여 각 배치가 아닌 매 전방 패스마다 결정을 내립니다. 시퀀스가 생성을 완료하면 해당 슬롯은 형제 시퀀스가 완료되기를 기다리지 않고 즉시 새 요청을 수락합니다. GPU는 각 순간에 존재하는 작업을 처리하여 정적 배칭이 비워두는 공백을 채웁니다.
구현에는 메모리 관리와 스케줄링 간의 신중한 조정이 필요합니다:
반복 수준 스케줄링은 모든 디코더 단계에서 요청 큐를 평가합니다. 완료된 시퀀스는 슬롯을 해제하고, 대기 중인 요청은 사용 가능한 용량을 요구하며, 다음 반복은 최적으로 채워진 배치로 진행됩니다. 요청 간 지연 시간 변동이 증폭되지 않고 흡수됩니다.
선점 처리는 메모리 압박이 시퀀스 제거를 강제하는 상황을 관리합니다. 낮은 우선순위 요청은 KV 캐시 상태를 체크포인트하고 더 높은 우선순위 시퀀스에게 GPU 메모리를 양보합니다. 용량이 돌아오면 선점된 시퀀스는 처음부터 다시 시작하지 않고 체크포인트에서 재개됩니다.
접두사 캐싱은 공통 접두사를 공유하는 요청을 식별하고 관련 KV 캐시 페이지를 이미 보유하고 있는 인스턴스로 라우팅합니다. 모든 요청이 동일한 500 토큰 컨텍스트로 시작하는 고객 지원 시스템은 중복 접두사 계산을 제거하여 캐시된 상태에서 후속 토큰을 제공합니다.
벤치마크는 그 영향을 보여줍니다: vLLM은 동등한 구성에서 Ollama의 초당 41 토큰 대비 초당 793 토큰의 처리량을 달성하며, P99 지연 시간은 673ms 대비 80ms입니다.⁸ 연속 배칭 아키텍처는 1명에서 256명의 동시 사용자까지 동시성 수준 전반에서 이러한 이점을 유지합니다.
프로덕션 아키텍처가 클러스터 전반으로 확장되다
단일 노드 vLLM 배포는 상당한 트래픽을 처리하지만, 프로덕션 시스템은 신뢰성, 규모, 효율성을 위해 클러스터 전반의 오케스트레이션이 필요합니다. vLLM 프로덕션 스택은 추론 엔진을 네 가지 중요한 추가 기능으로 완전한 서빙 시스템으로 변환합니다.⁹
요청 라우팅은 라우팅 키, 세션 ID 또는 접두사 매칭을 기반으로 들어오는 쿼리를 적절한 백엔드 인스턴스로 안내합니다. 지능적 라우팅은 관련 컨텍스트를 이미 보유한 인스턴스로 관련 요청을 보내 KV 캐시 재사용을 극대화합니다. 여러 턴이 있는 대화는 인스턴스 간 중복 접두사 계산을 피하기 위해 동일한 백엔드로 일관성 있게 라우팅됩니다.
KV 캐시 공유는 LMCache 프로젝트를 통해 여러 vLLM 인스턴스에 걸쳐 PagedAttention의 메모리 효율성을 확장합니다. 백엔드는 고속 상호연결을 통해 계산된 KV 캐시 블록을 공유하여 요청이 다른 인스턴스로 라우팅되어도 캐시 히트를 가능하게 합니다. 반복적인 워크로드를 가진 시스템은 인스턴스 간 캐시 공유로부터 3-10배 지연 시간 감소와 2-5배 처리량 개선을 봅니다.¹⁰
관찰 가능성 통합은 Prometheus를 통해 메트릭을 노출하고 Grafana 대시보드를 통해 시각화를 제공합니다. 요청별 메트릭은 첫 토큰까지의 시간(TTFT), 토큰 간 시간(TBT), 종단 간 지연 시간을 캡처합니다. 인스턴스별 메트릭은 GPU 활용도, 메모리 압박, 큐 깊이, 캐시 적중률을 추적합니다. 운영 팀은 성능 병목 현상과 용량 계획 데이터에 대한 가시성을 얻습니다.
수평 확장은 수요 신호에 기반하여 vLLM 인스턴스를 추가하고 제거합니다. Kubernetes 배포는 Horizontal Pod
