vLLM vs 올라마 속도 비교: 페이지드어텐션과 연속 배칭 원리부터 실제 측정까지

핵심 메시지

• vLLM은 UC 버클리 스카이 컴퓨팅 랩에서 시작된 오픈소스 추론 엔진으로, 깃허브 스타 7만 개를 넘겼고 핵심 개발자 중 한 명이 한국인 권우석 박사다.
• 페이지드어텐션은 운영체제의 페이징 기법을 KV 캐시에 적용해, 60~80%에 달하던 메모리 낭비를 4% 미만으로 줄였다.
• 연속 배칭은 VRAM에 여유가 생길 때마다 대기 중인 요청을 밀어 넣어 GPU를 끝까지 쥐어짜는 스케줄러다.
• 직접 테스트에서 단일 요청은 올라마가 근소하게 빨랐지만, 요청 수를 늘리자 vLLM이 압도적으로 앞섰다.
• GUI가 없어 진입 장벽은 있지만, 로컬 에이전트를 여러 개 굴리는 개인 사용자에게도 병렬 처리 이점은 충분하다는 평가다.

쉽게 이해하기

로컬에서 대규모 언어 모델을 돌릴 때 가장 널리 쓰이는 도구는 올라마다. 다만 영상은 올라마에 분명한 약점이 있다고 짚으며 대안으로 vLLM을 소개한다. 레드햇이 낸 두 도구의 성능 비교 보고서에서 vLLM은 올라마보다 초당 처리 토큰 수가 약 19배 높게 나왔고 지연 시간도 더 짧았다는 것이 출발점이다.

vLLM은 UC 버클리 스카이 컴퓨팅 랩 연구진이 만든 프로젝트로, 깃허브 스타 7만 개를 넘겼고 허깅페이스에 올라온 대부분의 언어 모델을 지원한다. 엔비디아와 AMD 등 빅테크 엔지니어들이 직접 코드 기여에 참여하고 있으며, 핵심 개발자 중 한 명이 한국인 권우석 박사라는 점도 함께 소개된다.

속도의 비결은 두 가지다. 첫째는 페이지드어텐션이다. 언어 모델은 다음 토큰을 만들 때마다 이전 문맥을 다시 계산하지 않으려고 KV 캐시를 쓰는데, 답변이 얼마나 길어질지 미리 알 수 없어 넉넉하게 공간을 잡아 둔다. 짧은 답이 나오면 그 공간이 통째로 버려지는데, vLLM은 운영체제가 램을 관리하듯 작은 블록을 필요할 때마다 동적으로 할당하고 블록 테이블로 위치를 기억해 빈 공간을 테트리스처럼 채운다.

그 결과 기존에 60~80% 가까이 낭비되던 메모리가 4% 미만으로 줄었고, 처리량은 2~4배로 늘었다. 둘째 기술인 연속 배칭은 요청을 하나씩 차례로 처리하는 대신, VRAM에 자리가 나는 즉시 대기 중인 요청에 작업 공간을 배정해 병렬로 밀어 넣는 스케줄러다. 메모리 낭비가 사라져 여유가 생긴 덕분에 동시에 받을 수 있는 요청도 늘어나, 두 기술이 서로를 밀어주는 구조가 된다.

실제 비교는 Qwen3-8B 모델로 단일 요청과 다중 요청 두 가지 상황에서 진행됐고, 재현성을 위해 10회 반복 평균을 냈다. 단일 요청에서는 vLLM의 부가 작업에서 오는 오버헤드 탓에 올라마가 근소하게 앞섰지만, 요청 수를 늘리자 격차가 뒤집혀 vLLM이 압도적으로 빨랐다. 영상은 기업용 도구로 소개되는 vLLM이 로컬 에이전트를 여러 개 운영하는 개인에게도 쓸모가 있다고 보면서, GUI가 없다는 점은 문서를 따라 해 보면 넘을 만한 벽이라고 덧붙인다.

주요 인사이트

• 추론 엔진의 성능 차이는 모델이 아니라 메모리를 어떻게 나눠 쓰느냐에서 갈린다. 같은 GPU, 같은 모델에서도 할당 전략만으로 처리량이 몇 배 달라진다.
• 벤치마크 숫자는 조건을 봐야 한다. 단일 요청에서는 오버헤드 때문에 오히려 느릴 수 있고, 동시 요청이 쌓이는 환경에서 비로소 설계의 이점이 드러난다.
• 운영체제의 오래된 아이디어인 페이징이 KV 캐시 관리에 그대로 이식됐다는 점은, 시스템 소프트웨어 지식이 AI 인프라에서 여전히 유효하다는 사례다.
• 개인 사용자라도 에이전트를 여러 개 동시에 돌리는 순간 상황은 다중 요청 환경이 된다. 하드웨어를 늘리기 전에 엔진을 바꿔 보는 선택지가 있다.

자주 묻는 질문

관련 AI 소식