백서-AI LLM 가속 엔진 vLLM 으로 GPU 병목과 AI 도입 비용을 줄이는 법

온프레미스 GPU를 넉넉히 사놓고도 처리량이 기대의 몇 분의 일에 그친다면, 병목은 카드가 아니라 서빙 방식에 있습니다(백서 §1장). UC Berkeley에서 출발한 vLLM은 KV 캐시 낭비와 GPU 유휴를 제거해 같은 하드웨어로 더 많은 동시 요청을 받게 합니다. 처리량과 비용, 라이선스를 실무 기준으로 정리했습니다.

2026년 07월 07일

왜 지금 vLLM을 검토해야 하는가?

순정 추론 코드를 그대로 프로덕션에 올리면 GPU 메모리가 빨리 차 OOM이 나고 사용률 그래프에 골짜기가 생깁니다(백서 §1장). 같은 카드로 받는 동시 요청 수가 줄고 대기 시간이 늘어납니다.

경쟁 지형도 기웁니다. Hugging Face는 TGI(Text Generation Inference)를 유지보수 모드로 전환하고 신규 서빙에 vLLM 계열을 권장합니다(백서 §8장). 서빙 스택을 갖춘 조직은 표준 경로를 점검해야 합니다.

vLLM 추론 서빙으로 GPU 병목과 AI 도입 비용을 줄이는 법 - 백서 다운로드

MSAP.ai 백서 구독하기🔔

새로운 백서 소식을 가장 먼저 만나보세요!

MSAP.ai 가 전하는 AI 기반 운영 인사이트와 최신 백서 소식을 가장 빠르게 받아보실 수 있습니다.

구독해 주시면 더 좋은 콘텐츠로 보답하겠습니다.🙏

무엇이 진짜 문제인가?

근본 원인은 KV 캐시(대화 문맥을 담는 GPU 메모리)를 쓰는 방식입니다. 순정 구현은 요청마다 최대 시퀀스 길이만큼 메모리를 연속 예약하는데, 실제 요청은 대부분 짧게 끝나 쓰지 않는 낭비가 쌓입니다(백서 §4장).

두 번째 원인은 정적 배칭입니다. 한 배치가 끝날 때까지 다음 배치를 시작하지 않아, 짧은 요청이 끝나도 가장 긴 요청을 기다리며 GPU가 놉니다(백서 §1장). 두 손실을 어떤 기법이 제거하는지 확인해야 합니다.

무엇을 어떻게 해결하는가?

vLLM은 두 손실을 다른 기법으로 없앱니다. PagedAttention은 가상 메모리 페이징처럼 KV 캐시를 고정 크기 블록으로 쪼개 쓰는 만큼만 배정하고 요청끼리 재사용해, 메모리 낭비를 거의 0에 가깝게(near-zero waste) 낮춥니다(백서 §4장). 연속 배칭은 요청이 끝나면 빈 자리에 대기 요청을 곧바로 끼워 넣어 GPU를 채웁니다.

효과는 처리량 배수로 나타나지만 비교 대상을 함께 봅니다(백서 §5장).

향상 수치	비교 대상	성격
2~4배	FasterTransformer·Orca	최적화된 SOTA 서빙 엔진
최대 24배	순정 HF Transformers	서빙 미최적화 라이브러리

자사 스택이 두 비교 대상 중 어디에 가까운지 판별한 뒤 해당 배수를 시작점으로 삼습니다. “24배”는 보장치가 아니라 조건부 상한이라 조건을 병기합니다.

도입 효과와 비용을 환산하는 기준

처리량 향상은 비용 지렛대입니다. 트래픽이 고정이면 더 적은 GPU로 같은 트래픽을 감당하고, 대수가 고정이면 같은 카드로 더 많은 사용자를 받습니다(백서 §5장). 다만 개선되는 것은 주로 처리량이라 단일 요청 지연은 자동으로 좋아지지 않으므로, 지연 목표는 SLO로 관리합니다.

온프렘 도입을 검토하는 순서

백서는 다섯 단계의 검토 순서를 제시합니다. 앞 단계가 정해져야 다음으로 넘어갈 수 있어, 순서 자체가 리스크를 앞에서 걸러 냅니다(백서 §9장). 아래를 순서대로 확인합니다.

GPU 확인 — 확보 가능한 GPU 종류와 메모리 용량이 모델 크기와 처리량 상한을 결정합니다.
모델 선택 — GPU 용량에 맞는 모델을 고르고 이때 가중치 라이선스를 함께 확인합니다.
설치 — vllm serve <model> 한 줄로 서빙하며, OpenAI 호환 API라 기존 코드를 붙입니다.
파라미터 조정 — --gpu-memory-utilization·--max-model-len·--quantization fp8·--max-num-seqs(V1 기본 1024)를 조율하고, 여러 장은 --tensor-parallel-size로 샤딩합니다.
검증 — 실제와 유사한 부하로 처리량·지연·안정성을 측정해 기준선을 잡습니다.