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% 감소하는 것을 확인했으며, 동일한 일일 5천만 API 호출을 1/3의 GPU 플릿으로 처리했습니다.¹ 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 추론은 각 시퀀스의 키-값(KV) 캐시에 연속적인 메모리 블록을 할당하며, 실제 사용량과 관계없이 가능한 최대 시퀀스 길이를 위한 공간을 예약합니다. 4,096 토큰으로 구성된 시스템은 100 토큰 응답에도 전체 메모리를 할당하여 예약된 용량의 97%를 낭비합니다. 수백 개의 동시 요청을 곱하면 GPU 메모리가 빈 예약으로 가득 차고 실제 시퀀스는 리소스를 기다리며 대기합니다.

PagedAttention은 GPU 메모리를 일반적으로 16 토큰 크기의 고정 크기 페이지로 나누어 이 아키텍처를 재구상합니다.⁵ 각 시퀀스는 연속 할당 대신 페이지 참조 목록을 유지하여 여러 획기적인 기능을 가능하게 합니다:

비연속 저장을 통해 KV 캐시 블록이 사용 가능한 GPU 메모리 전체에 분산될 수 있습니다. 시스템은 더 이상 큰 연속 영역이 필요하지 않아 기존 할당자를 괴롭히는 단편화를 제거합니다. 2,000 토큰 시퀀스는 공간이 있는 곳이면 어디든 분산된 125개 페이지에 캐시를 저장합니다.

동적 할당은 시퀀스가 증가할 때만 메모리를 프로비저닝합니다. 첫 번째 토큰은 하나의 페이지를 할당합니다. 17번째 토큰은 두 번째 페이지 할당을 트리거합니다. 메모리 소비는 이론적 최대값이 아닌 실제 사용량을 추적하여 유효 용량을 극적으로 개선합니다.

메모리 공유를 통해 동일한 프롬프트 접두사가 요청 간에 KV 캐시 페이지를 공유할 수 있습니다. 동일한 시스템 프롬프트의 변형을 묻는 10명의 사용자가 해당 접두사의 단일 캐시된 복사본을 공유하여 일반적인 패턴에 대한 메모리 소비를 90% 줄입니다. 표준화된 프롬프트를 사용하는 프로덕션 시스템은 400%를 초과하는 활용률 개선을 경험합니다.⁶

거의 제로에 가까운 낭비는 정적 할당에서 흔한 내부 단편화를 제거합니다. 기존 시스템은 부분적으로 채워진 블록에서 시퀀스당 평균 4.1 토큰을 낭비합니다. PagedAttention의 페이지 수준 세분성은 낭비를 페이지의 일부로 줄여 길이에 관계없이 시퀀스당 일반적으로 8 토큰 미만입니다.

이 알고리즘은 운영체제 가상 메모리에서 직접 영감을 받아 수십 년간의 메모리 관리 연구를 GPU 추론에 적용합니다. 현대 운영체제가 가상 주소를 물리적 메모리 페이지에 매핑하는 것처럼, PagedAttention은 논리적 KV 캐시 위치를 물리적 GPU 메모리 블록에 매핑합니다. 변환 오버헤드는 각 어텐션 계산에 마이크로초를 추가하지만 기가바이트의 메모리 용량을 절약합니다.

연속 배칭이 GPU 활용률을 극대화합니다

정적 배칭은 고정된 수의 요청을 함께 처리하기 전에 대기하여, 배치가 부분적으로 채워질 때 지연 시간 급증을 일으키고 요청이 불균등하게 도착할 때 처리량이 감소합니다. 배치 크기 32는 31번째 요청이 처리를 시작하기 전에 하나의 추가 도착을 기다린다는 것을 의미하며, 트래픽이 적은 기간에 잠재적으로 몇 초의 지연을 추가합니다.

vLLM의 연속 배칭은 배치 경계를 완전히 제거합니다.⁷ 스케줄러는 배치 수준이 아닌 반복 수준에서 작동하여 매 배치가 아닌 매 순방향 패스마다 결정을 내립니다. 시퀀스가 생성을 완료하면 그 슬롯은 형제 시퀀스가 완료될 때까지 기다리지 않고 즉시 새 요청을 받습니다. GPU는 각 순간에 존재하는 작업을 처리하여 정적 배칭이 비워두는 공백을 채웁니다.

구현에는 메모리 관리와 스케줄링 간의 신중한 조정이 필요합니다:

반복 수준 스케줄링은 모든 디코더 단계에서 요청 대기열을 평가합니다. 완료된 시퀀스는 슬롯을 해제하고, 대기 중인 요청은 사용 가능한 용량을 차지하며, 다음 반복은 최적으로 채워진 배치로 진행됩니다. 요청 간의 지연 시간 변동은 증폭되지 않고 흡수됩니다.

선점 처리는 메모리 압력으로 시퀀스 제거가 강제되는 상황을 관리합니다. 낮은 우선순위 요청은 KV 캐시 상태를 체크포인트하고 높은 우선순위 시퀀스에 GPU 메모리를 양보합니다. 용량이 돌아오면 선점된 시퀀스는 처음부터 다시 시작하지 않고 체크포인트에서 재개됩니다.

접두사 캐싱은 공통 접두사를 공유하는 요청을 식별하고 관련 KV 캐시 페이지를 이미 보유한 인스턴스로 라우팅합니다. 모든 요청이 동일한 500 토큰 컨텍스트로 시작하는 고객 지원 시스템은 캐시된 상태에서 후속 토큰을 제공하여 중복 접두사 계산을 제거합니다.

벤치마크는 그 영향을 보여줍니다: vLLM은 동등한 구성에서 Ollama의 초당 41 토큰과 비교하여 초당 793 토큰의 처리량을 달성하며, P99 지연 시간은 673ms 대비 80ms입니다.⁸ 연속 배칭 아키텍처는 1명에서 256명의 동시 사용자까지 동시성 수준에 걸쳐 이러한 이점을 유지합니다.

프로덕션 아키텍처가 클러스터 전체로 확장됩니다

단일 노드 vLLM 배포는 상당한 트래픽을 처리하지만, 프로덕션 시스템은 안정성, 확장성 및 효율성을 위해 클러스터 전체 오케스트레이션이 필요합니다. vLLM production-stack은 네 가지 중요한 추가 사항으로 추론 엔진을 완전한 서빙 시스템으로 변환합니다.⁹

요청 라우팅은 라우팅 키, 세션 ID 또는 접두사 매칭을 기반으로 들어오는 쿼리를 적절한 백엔드 인스턴스로 보냅니다. 지능형 라우팅은 관련 요청을 이미 관련 컨텍스트를 보유한 인스턴스로 보내 KV 캐시 재사용을 극대화합니다. 여러 턴이 있는 대화는 일관되게 동일한 백엔드로 라우팅되어 인스턴스 간 중복 접두사 계산을 방지합니다.

KV 캐시 공유는 LMCache 프로젝트를 통해 여러 vLLM 인스턴스에 걸쳐 PagedAttention의 메모리 효율성을 확장합니다. 백엔드는 고속 상호 연결을 통해 계산된 KV 캐시 블록을 공유하여 요청이 다른 인스턴스로 라우팅되더라도 캐시 히트를 가능하게 합니다. 반복적인 워크로드가 있는 시스템은 인스턴스 간 캐시 공유로 3~10배 지연 시간 감소와 2~5배 처리량 향상을 경험합니다.¹⁰

관측성 통합은 Prometheus를 통해 메트릭을 노출하고 Grafana 대시보드를 통해 시각화합니다. 요청별 메트릭은 첫 토큰까지 시간(TTFT), 토큰 간 시간(TBT) 및 종단 간 지연 시간을 캡처합니다. 인스턴스별 메트릭은 GPU 활용률, 메모리 압력, 대기열 깊이 및 캐시 히트율을 추적합니다. 운영 팀은 성능 병목 현상과 용량 계획 데이터에 대한 가시성을 얻습니다.

수평 확장은 수요 신호에 따라 vLLM 인스턴스를 추가하고 제거합니다. Kubernetes 배포는 대기열 깊이 또는 지연 시간 백분위수를 대상으로 하는 사용자 정의 메트릭과 함께 Horizontal Pod Autoscaler를 사용합니다. 라우터 계층은 자동으로 새 인스턴스를 검색하고 트래픽을 재조정하여 실제 수요를 추적하는 탄력적 용량을 가능하게 합니다.

배포는 Helm 차트를 통한 표준 Kubernetes 패턴을 따릅니다:

# vLLM production-stack용 values.yaml
replicaCount: 4
model:
  name: "meta-llama/Llama-3.1-70B-Instruct"
  tensorParallelism: 4
resources:
  limits:
    nvidia.com/gpu: 4
router:
  enabled: true
  prefixAwareRouting: true
observability:
  prometheus: true
  grafana: true

배포된 스택은 Kubernetes 서비스를 통해 OpenAI 호환 API를 노출하여 현재 OpenAI 또는 Azure OpenAI 엔드포인트를 호출하는 애플리케이션에 대한 즉시 교체를 가능하게 합니다. 기존 코드베이스는 클라우드 API에서 자체 호스팅 추론으로 마이그레이션하기 위해 엔드포인트 URL 변경만 필요합니다.

인프라 요구 사항이 배포 결정을 형성합니다

vLLM의 메모리 효율성은 더 작은 GPU 구성에서 더 큰 모델을 가능하게 하지만, 하드웨어 선택은 여전히 성능 특성을 결정합니다. 모델 크기, GPU 메모리 및 처리량 간의 관계를 이해하면 조달 결정에 정보를 제공합니다.

GPU 메모리는 최대 모델 크기와 동시 배치 용량을 제한합니다. FP16의 70B 파라미터 모델은 가중치만으로 140GB가 필요하여 현재 하드웨어에서 다중 GPU 텐서 병렬 처리가 필요합니다. INT4 양자화의 동일 모델은 35GB에 맞아 단일 A100 80GB 또는 H100에서 KV 캐시를 위한 상당한 여유 공간과 함께 배포할 수 있습니다. 메모리 대역폭은 종종 원시 컴퓨팅보다 처리량을 더 많이 제한하여 HBM3 장착 GPU가 불균형적으로 효과적입니다.

텐서 병렬 처리는 노드 내 여러 GPU에 모델 레이어를 분할하며, 단일 GPU 메모리를 초과하는 모델에 필수적입니다. vLLM은 GPU 수와 일치하는 텐서 병렬 차수를 지원하며 어텐션 및 피드포워드 레이어를 자동으로 샤딩합니다. 텐서 병렬 처리 8로 실행되는 8-GPU 노드는 그렇지 않으면 더 느린 파이프라인 병렬 처리가 있는 여러 노드가 필요한 405B 파라미터 모델을 제공합니다.

네트워크 패브릭은 다중 노드 배포에서 중요해집니다. 노드 간 파이프라인 병렬 처리는 스테이지 간 저지연, 고대역폭 상호 연결이 필요합니다. 200-400Gbps 대역폭의 InfiniBand 또는 RoCE 네트워크는 효율적인 다중 노드 서빙을 지원하지만, 표준 이더넷은 첫 토큰까지 시간을 상당히 저하시키는 지연을 도입합니다.

스토리지 처리량은 모델 가중치를 로드할 때 콜드 스타트 성능에 영향을 미칩니다. FP16의 70B 모델은 첫 요청을 서빙하기 전에 스토리지에서 GPU 메모리로 140GB를 전송해야 합니다. 7GB/s를 제공하는 NVMe 스토리지는 20초 만에 모델을 로드하고, 500MB/s의 네트워크 연결 스토리지는 5분이 걸립니다. 프로덕션 시스템은 콜드 스타트 영향을 최소화하기 위해 웜 대기 인스턴스를 유지하거나 모델 캐싱 전략을 구현합니다.

Introl은 전 세계 서비스 지역 전반에서 조직이 vLLM 인프라를 설계하도록 돕고, 비용 효율성을 최적화하면서 하드웨어 구성을 워크로드 요구 사항에 맞춥니다.¹¹ 당사 엔지니어들은 월간 수십억 건의 요청을 처리하는 추론 인프라를 배포해 왔으며, 기능적인 배포와 고도로 최적화된 시스템을 구분하는 뉘앙스를 이해합니다.

vLLM과 대안 비교

추론 서빙 생태계는 각각 고유한 강점을 가진 여러 프레임워크를 제공합니다. 올바른 도구를 선택하려면 프레임워크 기능을 워크로드 특성에 맞춰야 합니다.

TensorRT-LLM은 공격적인 커널 최적화와 그래프 컴파일을 통해 NVIDIA 하드웨어에서 최대 성능을 제공합니다. 벤치마크는 TensorRT-LLM이 FP8 양자화로 H100에서 초당 10,000개 이상의 출력 토큰을 달성하며, 첫 토큰까지 시간은 약 100ms입니다.¹² 트레이드오프: 체크포인트 변환, 엔진 빌드, TensorRT-LLM, tensorrtllm_backend 및 Triton Inference Server 전반에 걸친 광범위한 구성이 필요한 복잡한 설정. 전담 ML 인프라 팀과 안정적인 모델 배포를 가진 조직이 가장 큰 혜택을 받습니다.

**Hugging Fa

[번역을 위해 내용 잘림]