vLLM 연속 배칭, 병목은 어디서 시작하나

vLLM 연속 배칭의 처리량, 진짜 병목은 GPU 연산이 아니다?

결론부터 적는다. vLLM의 처리량 상한은 연산이 아니라 KV 캐시가 버틸 수 있는 배치 크기에서 정해진다. UC Berkeley EECS 2025 보고서는 이를 "serving system's throughput is memory-bound"로 정리한다. 배칭을 아무리 늘려도 GPU 메모리, 특히 KV 캐시 공간이 부족하면 처리량은 더 오르지 않는다.

• vLLM 처리량은 배치 크기가 아니라 KV 캐시 여유 공간에 의해 상한이 정해진다.
• 고동시성에서는 continuous batching이 정적 배칭 대비 2~4배 처리량 우위를 보이나, 조건이 붙는다.
• 처리량은 어느 지점부터 plateau에 도달하고, 이후에는 지연만 늘어난다.
• prefix 캐시 히트율이 높으면 처리량보다 TTFT 개선 폭이 더 크게 나타난다.

이 글은 vLLM의 스케줄러·PagedAttention·prefix 라우팅 세 계층을 순서대로 뜯어, 실측 sweep 데이터로 병목 지점을 확인한다. 모델 아키텍처 자체나 양자화 기법은 다루지 않는다.

PagedAttention은 KV 캐시 압박을 어디까지 완화하나?

PagedAttention은 KV 캐시를 고정 크기 블록 단위로 나눠 단편화를 줄이지만, 캐시 총량 자체를 늘려주지는 않는다. Berkeley 보고서가 지적하는 지점이 바로 여기다. "primary bottleneck … is not computation but memory management"라는 서술은, 배치 효율화가 메모리 관리 문제를 없애는 게 아니라 다른 형태로 옮긴다는 뜻에 가깝다. 시퀀스가 길어지거나 동시 요청 수가 늘면, 블록 단위 관리로도 결국 캐시 여유분은 바닥난다.

연속 배칭 스케줄러는 요청을 어떻게 묶고, 언제 못 묶나?

스케줄러는 GPU 메모리 한도 안에서 요청을 자동으로 여러 배치로 쪼개 처리하되, 입력 순서는 유지한다. vLLM 포럼의 2025년 답변은 1000개 프롬프트를 넣어도 vLLM이 메모리에 맞춰 알아서 배치를 나눈다고 설명한다. 다만 긴 요청이 섞이면 자동 배칭이 있어도 실제 동시 처리 수는 줄어든다. v0.6.0에서는 여러 scheduling step을 한 번에 묶어 GPU 유휴 시간을 줄이는 방식으로 2.7배 처리량, 5배 지연 개선을 보고했는데, 이는 이전 버전 대비 수치라는 점을 함께 봐야 한다. 스케줄링 최적화는 캐시 부족 문제를 해결하는 게 아니라, 주어진 캐시 안에서 GPU를 더 바쁘게 만드는 작업에 가깝다.

prefix 캐시 라우팅은 TTFT를 얼마나 바꾸나?

캐시 히트가 걸리면 첫 토큰 시간(TTFT)은 수 배 단위로 줄어든다. Red Hat/llm-d의 2025년 자료는 cache hit rate 87.4%에서 TTFT가 2,850ms에서 340ms로, 약 88% 개선됐다고 보고한다. 처리량 병목을 푸는 축이 배치 확대만이 아니라 요청을 어느 인스턴스로 보내느냐, 즉 라우팅에도 있다는 뜻이다. 같은 vLLM 계열이라도 prefix 재사용률이 낮으면 캐시가 매번 새로 채워지고, 그만큼 KV 캐시 압박도 커진다.

실측: 동시성을 늘리면 처리량은 어디서 꺾이나?

2026년 공개된 Kubernetes 위 vLLM 서빙 사례는 L40S GPU에서 동시성을 8부터 456까지 sweep했다. 처리량은 약 1,680 tok/s에서 6,600~7,300 tok/s까지 오른 뒤 plateau에 도달했고, 이후로는 요청을 더 받아도 처리량은 그대로였고 지연만 늘었다.

같은 사례에서 production 부하는 약 124 concurrent requests에서 유지됐고, burst는 최대 약 720 attempted connections까지 튀었지만 503으로 shed됐다. 이때 GPU cache 사용률은 약 31%, prompt-prefix reuse는 66% 이상 유지됐다. 다른 비교 실험에서는 LLaMA-2-7B 기준 vLLM이 15,243 tok/s, TGI가 4,156 tok/s를 기록했고, TGI는 동시성 50 이후 포화됐다는 2025년 11월 arXiv 초록도 있다. 2026년 기준으로 봐도 상승 후 plateau, admission control로 안정화라는 패턴은 반복해서 나타난다.

처리량을 올리면 무엇을 잃나?

동시성을 무리하게 밀어붙이면 처리량 대신 tail latency를 잃는다. 위 sweep 사례에서 처리량이 plateau에 도달한 이후 구간은 P99가 급격히 늘어나는 구간과 겹친다. limit_conn을 낮춰 admission control을 걸면 최고 처리량은 일부 포기하는 대신 P99를 예측 가능한 범위로 묶을 수 있다. 반대로 캐시 히트율을 높이는 prefix 라우팅을 도입하면 TTFT는 크게 줄지만, 라우팅 로직과 캐시 상태 추적이라는 추가 복잡도가 시스템에 들어온다. 어느 쪽이든 공짜로 얻는 개선은 없다.

언제 연속 배칭에 기대고, 언제 admission control을 먼저 걸어야 하나?

요청 길이 분포가 고르지 않고 동시성이 높은 워크로드라면 continuous batching과 PagedAttention 조합이 정적 배칭 대비 우위를 낸다. 다만 이 우위는 KV 캐시에 여유가 있을 때의 이야기다. prefill이 긴 요청이 섞이거나 동시성이 plateau 지점을 넘어서면, 배칭 최적화보다 admission control이나 요청 shedding을 먼저 설계하는 편이 안전하다. 캐시 히트율이 낮은 워크로드라면 배칭 튜닝보다 prefix 라우팅 개선이 먼저다.

핵심 정리

• vLLM 처리량 상한은 GPU 연산이 아니라 KV 캐시 여유 공간에서 정해진다.
• 동시성 sweep에서 처리량은 약 1,680→6,600~7,300 tok/s로 오른 뒤 plateau에 도달하며, limit_conn 136에서 5,900 tok/s(89%)·P99 263s로 안정화됐다.
• prefix 캐시 히트율 87.4%에서 TTFT가 2,850ms→340ms로 줄어드는 등, 병목 해소 축은 배칭 확대뿐 아니라 라우팅에도 있다.
• 처리량과 tail latency는 트레이드오프 관계이며, admission control로 최고 처리량을 일부 포기하고 P99를 안정화하는 선택이 가능하다.
• 요청 길이가 고르고 캐시 여유가 있을 때는 continuous batching이 유리하지만, plateau 근처에서는 배칭 튜닝보다 admission control과 prefix 라우팅 점검이 먼저다.

더 알아보기

LLM 추론 서빙: 처리량과 지연의 트레이드오프를 보는 법 — 이 주제의 종합 가이드