vLLMvLLM
쉽게 이해하기
LLM 서비스의 병목은 종종 연산량이 아니라 메모리다. 토큰을 하나씩 생성할 때마다 생기는 내부 상태(KV 캐시)가 길이와 레이어 수에 비례해 커지며, 다양한 길이의 요청이 뒤섞이면 GPU 메모리가 잘게 갈라져(단편화) 처리량이 떨어진다. 대기열을 채워 한 번에 실행하는 고정 배치는 트래픽 변동과 긴 프롬프트 혼합 상황에서 금세 비효율이 커진다.
vLLM은 이 문제를 "GPU 메모리를 운영체제의 가상 메모리처럼" 다뤄 풀어낸다. KV 캐시를 큰 연속 블록이 아니라 고정 크기 '페이지'로 나눠 보관하고, 각 시퀀스는 필요한 페이지를 참조만 하므로 빈틈을 줄이고 재사용을 쉽게 한다. 동시에 배치를 토큰 생성 단위로 계속 갱신하는 연속 배칭으로, 진행 중인 생성에 새 요청을 끼워 넣어 GPU를 쉬지 않게 만든다.
구체적으로 페이지 매핑 테이블이 KV 블록 전체 복사 없이 참조를 바꿔 붙이게 해 메모리 이동량과 즉시 할당/해제를 줄인다. 이 "게으른(lazy)" 매핑·회수는 큰 KV 블록 복사와 대규모 재할당을 피하며 단편화와 할당 오버헤드를 낮춘다. 결과적으로 긴·짧은 시퀀스가 섞여도 배치가 유지되고, 워커는 연산에 집중한다.
비유와 예시
- 사내 검색 챗봇의 트래픽 피크 흡수: 점심시간 15분 동안 동시 150명, 평균 프롬프트 900토큰, p95 응답 목표 2초 같은 조건에서 새 요청을 생성 중 배치에 합류시켜 일시적 큐 적체를 줄인다.
- 보고서 요약 파이프라인의 혼합 워크로드: 백그라운드 대용량 요약(입력 8k 토큰)과 실시간 질의응답(입력 300토큰)을 같은 GPU 팟에서 돌리되, 토큰 단위 스케줄링으로 긴 작업에 짧은 질의를 끼워 GPU 유휴 구간을 최소화한다.
- 멀티 모델 A/B 시험의 리소스 공존: 동일 노드에서 두 모델을 번갈아 호출하는 실험(동시 60 요청, 평균 출력 200토큰)에서 KV 페이지 재사용과 연속 배칭으로 모델 전환 시 배치 붕괴를 완화한다.
한눈에 비교
| vLLM | Hugging Face TGI | |
|---|---|---|
| 배칭 방식 | 토큰 단위 연속 배칭(실행 중 합류) | 배치 수준 동적 배칭(타임아웃 창) |
| 메모리 관리 | PagedAttention: 비연속 페이지 기반 KV | 연속 블록 중심, 공유 기회 제한 |
| 처리량 특성 | 보통 더 높은 처리량 지향 | 보통 더 예측 가능한 지연 특성 |
| 지연 특성 | per-request 변동성 가능성 | 창 기반으로 상대적 안정성 |
| 워크로드 형태 | 긴·짧은 혼합, 길이 분산 클 때 유리할 수 있음 | 길이 분포가 좁고 SLA 고정일 때 유리할 수 있음 |
두 접근은 처리량과 지연 안정성의 균형점이 달라 워크로드 길이 분포와 SLA에 맞춰 선택하는 것이 중요하다.
어디서 왜 중요한가
- AWS Trainium + vLLM 추측 디코딩 데모: 디코드 중심 워크로드에서 성능 향상(예: 최대 3배)이 보고되며, 모델 크기·병렬화·입력 분포 등 환경에 크게 의존하는 것으로 안내된다.
- 연속 배칭의 확산: 배치 대기 시간을 줄이고 토큰 단위로 스케줄링하는 방식이 서빙 설계의 기본 옵션으로 자리잡아, 트래픽 버스트 시 처리량 저하를 완화하는 실무 관행이 퍼졌다.
- 메모리 절감에 따른 동시성 증가: 한 비교 연구에서 페이지드 KV 관리가 19–27% 메모리 절감으로 이어져 더 큰 배치와 처리량 향상을 뒷받침한다고 보고되었다.
- 분산 실행 구성이 표준화: 엔진 코어/워커/DP 코디네이터 구조가 문서화되어 TP·PP·DP 조합 배포 시 프로세스 수와 역할이 명확해졌다.
- OpenAI 호환 API 도입 용이성: 기존 애플리케이션이 엔드포인트를 크게 바꾸지 않고 전환·병행 실험을 진행하기 쉬워졌다.
자주 하는 오해
- ❌ 오해: vLLM을 쓰면 모델 정확도가 오른다 → ✅ 실제: 서빙/추론 효율을 개선하는 엔진으로, 모델 품질은 바뀌지 않는다.
- ❌ 오해: vLLM은 항상 지연시간이 더 낮다 → ✅ 실제: 처리량은 높일 수 있으나 per-request 지연 특성은 스케줄링과 길이 분포에 따라 달라질 수 있다.
- ❌ 오해: 메모리 페이징은 복사 오버헤드가 크다 → ✅ 실제: 페이지 참조/매핑으로 큰 KV 블록 복사를 피해 단편화와 재할당 비용을 줄이도록 설계됐다.
대화에서는 이렇게
- "PO: 실험 — continuous batching 활성화, tokens/sec·p95 비교; 기간 2주; 롤백 기준: p95 10%↑ 초과 시 즉시 복귀. 담당: 서빙팀."
- "이번 주 목표는 KV 페이지 크기 스윕입니다. 길이 분산이 큰 트래픽에서 메모리 압력과 처리량 상관 확인해 주세요."
- "Bedrock의 speculative decoding + vLLM 설정으로 비용/지연 프로파일 재측정합시다. 워크로드는 decode-heavy 세트로 고정."
- "배포 구성은 -tp=2 -dp=4로 갑니다. 엔진 코어/워커 프로세스 수 모니터링 대시보드에 추가해 주세요."
- "이번 릴리스의 SLO는 동시 120, p95 2.0s입니다. 길이 95백분위 입력에 대한 큐 지연과 KV 캐시 사용률을 따로 트래킹합시다."
함께 읽으면 좋은 용어
참고 자료
- A Performance Study of vLLM and HuggingFace TGI
배칭 전략·메모리 관리 비교 및 관찰 결과
- Architecture Overview - vLLM
프로세스 구성, 스케줄러, GPU 워커 등 핵심 구조 개요
- Accelerating decode-heavy LLM inference with speculative decoding on AWS Trainium and vLLM
Trainium에서 vLLM과 결합한 speculative decoding 사례
- Beyond Model Serving: Inside vLLM’s Architecture for Enterprise-Scale LLM Inference
KV 캐시·스케줄링·요청 흐름을 직관적으로 설명
- Serving LLMs with vLLM: A practical inference guide
PagedAttention·연속 배칭·분산 지원 등 실무 가이드