vLLM 해부, 추론 인프라가 제품력이 됐다

HN이 2025년 글을 다시 올린 이유

Aleksa Gordic의 vLLM 해부 글은 2025년 8월 29일 게시된 장문 기술 해설이다. 새 발표는 아니지만 2026년 8월 7일 현재 Hacker News에서 다시 소비된 이유는 분명하다. GPT-5.6급 모델을 쓰는 제품이 늘면서 병목이 모델 호출 자체에서 추론 서버의 처리량, 지연, GPU 메모리 운영으로 옮겨가고 있기 때문이다.

vLLM은 공식 저장소에서 PagedAttention, 연속 배칭, chunked prefill, prefix caching, speculative decoding, OpenAI 호환 서버를 핵심 기능으로 내세운다. 이는 연구 논문보다 운영 시스템에 가까운 언어다. 모델이 아무리 좋아도 요청이 몰릴 때 첫 토큰이 늦고 GPU가 비어 있으면 제품은 느리다. 4B 검색 모델, 프런티어 비용을 흔들다가 작은 모델의 업무별 비용을 다뤘다면, 이번 글은 같은 비용 전쟁이 서빙 계층에서 어떻게 벌어지는지 보여준다.

핵심은 KV 캐시를 운영 자산으로 보는 일

vLLM 설명에서 가장 중요한 부분은 KV 캐시다. 디코드 단계에서는 새 토큰 하나를 만들기 위해 이전 토큰의 key, value 상태를 계속 읽는다. 이 메모리가 조각나거나 낭비되면 GPU는 비싼데 처리량은 떨어진다. PagedAttention은 이 캐시를 운영체제의 페이지처럼 블록으로 관리해 긴 요청과 짧은 요청이 섞여도 메모리 낭비를 줄인다.

또 하나는 연속 배칭이다. 전통적 배칭은 같은 시점에 들어온 요청을 묶고 끝날 때까지 기다리는 식이었다. 챗봇과 에이전트 제품에서는 요청 길이와 출력 길이가 제각각이라 이 방식이 쉽게 비효율화된다. vLLM식 스케줄러는 매 스텝마다 prefill과 decode 요청을 다시 보고 GPU가 계속 일하게 만든다. BTB, LLM 추론 병목을 캐시 예측으로 밀어내다에서 다룬 예측형 캐시 연구와 같은 방향이다. 병목은 더 이상 모델 가중치만이 아니라 토큰 흐름 전체다.

한국 서비스에 필요한 것은 벤치마크보다 프로파일링이다

vLLM 문서와 커뮤니티 자료를 보면 기능 목록이 매우 빠르게 늘고 있다. 하지만 모든 기능을 켜는 것이 정답은 아니다. speculative decoding은 특정 모델 조합과 트래픽 패턴에서 유리하고, prefix caching은 반복 프롬프트가 길 때 효과가 크다. chunked prefill은 긴 문맥 요청이 짧은 대화 요청을 밀어내는 상황에서 빛난다.

한국 기업의 흔한 실수는 모델 API 비용표만 보고 제품 원가를 추정하는 것이다. 실제 비용은 토큰 길이 분포, 동시성, 재시도, 스트리밍 중단, 검색 호출, 사용자별 시스템 프롬프트 길이에 의해 흔들린다. 마이크로소프트 실적, AI 원가표가 드러났다가 클라우드 CAPEX의 큰 그림을 보여줬다면, vLLM은 팀 단위에서 줄일 수 있는 미시 원가를 보여준다.

경쟁 구도는 오픈소스 서빙 표준으로 이동한다

vLLM은 UC Berkeley Sky Computing Lab에서 시작됐고 지금은 수많은 기업과 연구자가 붙은 오픈소스 프로젝트다. Hugging Face TGI, SGLang, TensorRT-LLM, 각 클라우드의 자체 서빙 스택과 경쟁한다. arXiv의 vLLM과 TGI 비교 연구는 고동시성에서 vLLM이 PagedAttention 기반 처리량 이점을 보였다고 보고한다. 다만 단일 사용자 대화형 지연에서는 다른 스택이 더 나을 수 있다. 즉 선택지는 제품 트래픽에 따라 달라진다.

에이전트 제품은 특히 까다롭다. 하나의 사용자 요청이 검색, 코드 실행, 파일 읽기, 재질문을 거치며 여러 모델 호출로 쪼개진다. 이때 서빙 엔진은 단순한 백엔드가 아니라 에이전트의 행동 속도를 결정하는 런타임이다. 한국 스타트업이 자체 모델을 만들지 않더라도 서빙을 이해하면 비용과 응답성을 차별화할 수 있다.

자주 묻는 질문

Q1: vLLM을 쓰면 무조건 빨라지나요?

A: 아니다. 긴 프롬프트, 높은 동시성, 반복 prefix가 있을수록 효과가 커진다. 낮은 트래픽의 단순 챗봇은 관리형 API가 더 단순할 수 있다.

Q2: PagedAttention은 왜 중요한가요?

A: KV 캐시를 블록 단위로 관리해 GPU 메모리 낭비를 줄이고 더 많은 동시 요청을 처리하게 해준다.

Q3: 한국 팀은 무엇부터 측정해야 하나요?

A: 첫 토큰 지연, 전체 응답 시간, prefill과 decode 토큰 비중, 큐 대기 시간, 재시도율을 먼저 봐야 한다.

Q4: 오픈소스 서빙을 직접 운영해야 하나요?

A: 대량 트래픽이나 민감 데이터가 있으면 검토할 만하다. 초기 제품은 관리형 API로 시작하고 병목이 확인될 때 옮기는 편이 현실적이다.

Q5: 에이전트와 어떤 관련이 있나요?

A: 에이전트는 한 요청 안에서 여러 번 모델을 부른다. 추론 지연이 누적되므로 서빙 효율이 곧 에이전트 사용성이다.