커뮤니티 해설난이도 보통파이토치 한국 사용자 모임 · 10월 17일(토) 공개

vLLM과 SGLang: 속도표보다 실제 요청 패턴이 중요한 이유

KV 캐시 관리 원리와 과거 벤치마크의 조건을 비교하며, 내 서비스의 입력·출력·공유 접두사에 맞게 추론 엔진을 고르는 방법을 설명합니다.

쉽게 말하면비유하자면 두 식당이 주방을 다르게 꾸리기 시작한 것과 같다. 한 곳은 조리대 빈자리를 잘게 나눠 쓰고, 다른 곳은 여러 주문에 겹치는 밑준비를 해 두었다가 다시 쓴다. 어느 쪽이 나은지는 손님이 무엇을 주문하느냐에 달렸다.

왜 봐야 하나: 오픈 모델을 직접 돌리는 팀은 속도표 한 장으로 엔진을 고르기 어렵다. 반복되는 지시문과 입력·출력 길이를 먼저 재고, 같은 트래픽을 두 엔진에 넣어 비교하라는 판단 순서를 준다. 원문을 쓴 Red Hat이 vLLM의 주요 기여자라는 점도 함께 본다.

10월 17일 UTC의 새 해설은 Red Hat이 10월 14일 쓴 vLLM·SGLang 비교를 다룬다. vLLM은 KV 캐시 메모리 낭비를 줄이는 PagedAttention, SGLang은 공통 프롬프트의 계산을 재사용하는 RadixAttention에서 출발했다. 지금은 주요 기능이 많이 겹친다. 글에 인용된 기본 설정 성능 비교는 2025년 중반의 구버전 실험이므로, 최신 엔진의 승자를 가리는 표로 읽어서는 안 된다. 어떤 입력과 출력을 처리하고 무엇을 캐시할 수 있는지가 선택의 핵심이다.

알아낸 것

인용된 표에서 처리량 차이는 출력이 긴 코드 생성 형태에서만 두드러졌다. SGLang이 초당 6.50건, vLLM이 5.34건으로 약 22% 높았고 나머지 두 조건은 거의 같았다.
이 표는 2025년 중반 버전을 H100 한 장, Llama 3.1 8B, 기본 설정으로 잰 결과다. 최신 엔진의 승자를 가리는 자료가 아니다.
시험 프롬프트는 소설에서 무작위로 잘라 낸 조각이라 요청끼리 앞부분이 거의 겹치지 않았다. 채팅과 에이전트에서 중요한 앞부분 재사용 효과는 이 표에 드러나지 않는다.

한계와 주의할 점

10월 17일 새 커뮤니티 해설이지만 표에 인용한 엔진 비교는 2025년 중반 버전의 측정이다.
단일 H100·Llama 3.1 8B·기본 설정과 거의 겹치지 않는 접두사 조건이다. 같은 부하에서의 지연 비교나 실제 에이전트 트래픽 전체를 대표하지 않는다.
현재 Modal Advisor 자료는 동일 모델의 양 엔진 비교가 없어 옛 표를 재현하지 못한다.
Red Hat은 vLLM의 주요 기여자이고, 현재 장비에서 직접 설치·성능 측정을 수행하지 않았다.

용어 풀이

KV 캐시: 프리필 단계에서 계산한 어텐션 키(key)와 값(value)을 저장해 두는 메모리 영역. 디코드 단계에서 새 토큰을 생성할 때 같은 계산을 반복하지 않도록 재사용한다. 대화가 길어질수록 커져 GPU 메모리를 많이 차지하며, 추론 엔진의 핵심 관리 대상이다.
PagedAttention: vLLM이 도입한 KV 캐시 관리 방식. 캐시를 고정 크기의 작은 블록으로 나누고 비연속적인 GPU 메모리 위치에 할당한다. 운영체제의 가상 메모리 페이지 관리와 유사하며, 메모리 낭비를 줄여 GPU 한 장에 더 많은 요청을 동시에 처리할 수 있게 한다.
RadixAttention: SGLang이 도입한 KV 캐시 재사용 방식. 계산한 KV 캐시를 토큰 접두사를 키로 하는 래딕스 트리에 저장한다. 새 요청이 오면 트리를 따라 내려가 일치하는 접두사의 캐시를 재사용하고 새로운 부분만 계산한다. 공통 시스템 프롬프트나 대화 기록이 반복되는 에이전트 워크로드에서 효과적이다.
TTFT (Time To First Token): 요청을 보낸 뒤 첫 토큰을 받기까지 걸리는 시간. 대기열과 프롬프트 처리 등의 지연이 포함될 수 있고, 전체 답변 완료 시간과 다르다. p95는 측정 요청의 95%가 그 시간 안에 첫 토큰을 받았다는 뜻이다.
연속 배칭 (Continuous Batching): 요청이 도착하고 끝나는 대로 배치를 갱신하여 GPU를 계속 바쁘게 유지하는 스케줄링 기법. 고정 배치와 달리 요청 수명이 달라도 유휴 시간을 줄여 처리량을 높인다. vLLM과 SGLang 모두 지원한다.
접두사 캐싱 (Prefix Caching): 여러 요청이 공유하는 프롬프트 접두사의 KV 캐시를 저장해 두었다가 재사용하는 최적화. vLLM은 블록 해시 기반, SGLang은 래딕스 트리 기반으로 구현한다. 시스템 프롬프트나 퓨샷 예시가 반복되는 워크로드에서 계산량을 크게 줄인다.

더 깊이 읽기 읽는 데 약 8분

배경과 문제

오픈 가중치 모델을 직접 실행하려는 팀에게 추론 엔진은 요청을 받아 모델을 돌려주는 운영 소프트웨어다. OpenAI 호환 API를 쓰는 서비스라면 연결 주소를 바꾸는 것으로 시작할 수 있지만, 모델의 입력 형식과 지원 기능도 확인해야 한다. 같은 모델이라도 요청을 묶는 방법, GPU 메모리에 보관하는 내용, 작업을 기다리게 하는 순서에 따라 처리량과 응답 지연이 달라진다. 이 글의 질문은 어느 엔진이 무조건 빠른가보다 내 요청에 어떤 방식이 맞는가에 가깝다.

LLM 요청은 프리필과 디코드 두 단계로 처리된다. 프리필은 프롬프트 전체를 한 번에 처리하며 모든 입력 토큰의 어텐션 키와 값을 계산하고, 디코드는 그 키와 값을 재사용하면서 출력 토큰을 하나씩 생성한다. 이렇게 저장해 둔 키와 값이 KV 캐시다. KV 캐시가 있으면 새 토큰마다 같은 계산을 반복하지 않아도 되지만, 대화가 길어질수록 커져서 GPU 메모리를 많이 차지한다. 긴 문서를 읽는 작업은 프리필에, 출력이 긴 코드 생성은 디코드에 부담이 크다. 추론 엔진은 결국 KV 캐시를 다루는 스케줄러이자 메모리 관리자이며, vLLM과 SGLang은 이 문제에 서로 다른 답으로 출발했다.

기존 접근의 한계

vLLM의 출발점은 KV 캐시를 큰 연속 구간으로 미리 잡아 둘 때 생기는 메모리 낭비였다. PagedAttention은 캐시를 작은 고정 크기 블록으로 나눠 GPU의 비연속 위치에 둘 수 있게 한다. 책을 놓으려고 큰 선반 전체를 예약하는 대신 빈 칸에 나눠 놓고 위치표를 관리하는 것에 비유할 수 있다. 이는 원리를 위한 비유다. 실제로는 시퀀스가 길어질 때 필요한 블록을 할당해 같은 GPU에 더 많은 요청을 담도록 한다.

SGLang은 2024년 1월 LMSYS를 통해 소개되었으며, 이름은 Structured Generation Language의 약자다. 멀티턴 채팅, 추출 워크플로, 분기와 반복을 하는 에이전트처럼 서로 관련된 모델 호출을 많이 하는 애플리케이션을 겨냥했다. 이런 애플리케이션은 같은 시스템 프롬프트와 도구 정의를 반복해서 보내고 대화 기록은 계속 길어진다. SGLang의 RadixAttention은 계산한 KV 캐시를 토큰 접두사를 키로 하는 래딕스 트리에 저장한다. 래딕스 트리는 공통 접두사를 한 경로로 합쳐 저장하는 트리 자료구조로, 새 요청이 오면 트리를 따라 내려가 일치하는 부분을 모두 재사용하고 새로운 부분만 계산한다. 여기에 캐시 인식 스케줄링을 더해 접두사를 공유하는 요청들을 가까운 시점에 실행함으로써 캐시된 가지가 필요할 때 메모리에 남아 있게 한다.

비교표를 읽는 순서

Red Hat은 Modal의 LLM Engineer’s Almanac을 성능 근거로 인용한다. Llama 3.1 8B를 H100 한 장에서 기본 설정으로 돌린 세 가지 입력·출력 길이의 결과를 골랐다. 각 엔진에서 요청의 95%가 첫 토큰을 1초 안에 받는 가장 높은 요청률을 비교했다. 따라서 표의 처리량 단위는 복제본 하나당 초당 요청 수이며, 첫 토큰 지연은 답변 전체가 끝나는 시간과 다르다.

표의 수치를 보면 입력 1024/출력 128 토큰(RAG·요약)에서 vLLM 17.08 req/s, SGLang 16.88 req/s로 차이가 2% 안쪽이다. 입력 128/출력 1024 토큰(코드 생성)에서는 SGLang 6.50 req/s, vLLM 5.34 req/s로 SGLang이 약 22% 높다. 입력 2048/출력 2048 토큰(긴 채팅)에서는 1.23 req/s 대 1.25 req/s로 거의 같다. p95 TTFT는 세 조건 모두 vLLM이 더 짧게 나왔지만, 각 엔진의 지연 값은 서로 다른 요청률에서 측정되었으므로 같은 부하에서의 지연 우위를 입증하지 않는다. 또한 표의 수치가 fp8 설정인지 원문에서 명시하지 않는다.

결과와 숫자의 의미

Modal의 요약 보고서는 'vLLM과 SGLang은 기본 설정에서 비슷한 성능을 낸다. 다른 요인으로 결정해야 한다'고 결론 내린다. 원문이 인용한 표에서도 처리량 차이는 출력이 긴 코드 생성 형태에서만 두드러진다. 그러나 이 벤치마크의 테스트 프롬프트는 제인 오스틴의 소설 『오만과 편견』에서 무작위로 잘라 낸 조각이라 요청끼리 접두사를 거의 공유하지 않는다. 이는 서로 독립적인 요청에 대한 공정한 테스트이지만, 채팅과 에이전트에서 중요한 접두사 재사용, 즉 RadixAttention과 vLLM 접두사 캐싱이 차이를 만드는 지점은 보여주지 않는다. 결과는 기본 설정의 단일 복제본에서 나왔으므로 튜닝하면 달라질 수 있다.

Modal 요약에 따르면 첫 실험은 2025년 5월 말에 끝났고 vLLM 0.8.x·0.9.x, SGLang 0.4.6-post5를 사용했다. 최신 엔진을 측정한 자료가 아니다. 이번에 다시 확보한 Advisor 데이터는 2026년 10월 8일 생성됐으며, 실시간 생성 레시피 42건 중 SGLang이 40건, vLLM이 2건이다. 이 자료에는 Llama 3.1 8B도, 같은 모델을 두 엔진으로 측정한 짝도 없다. 현재 Advisor를 열어도 옛 표를 그대로 재현하거나 엔진 차이를 분리할 수 없는 이유다.

구체적인 예시

접두사 재사용이 실제로 어떤 차이를 만드는지 이해하려면 에이전트 호출을 생각해 보면 된다. 에이전트는 매 호출마다 같은 시스템 프롬프트와 도구 정의를 보내고, 대화 기록은 계속 길어진다. SGLang의 RadixAttention은 이런 공통 접두사의 KV 캐시를 래딕스 트리에 저장해 새 요청이 오면 일치하는 부분을 재사용한다. vLLM도 접두사 캐싱을 지원하지만 구현이 다르다. vLLM 공식 문서에 따르면 트리 대신 해시를 사용하며, 각 KV 블록을 그 블록의 토큰과 앞선 접두사의 해시로 식별한다. vLLM은 가득 찬 블록만 캐시한다. 두 엔진 모두 공유 접두사를 재사용하지만, 찾는 자료구조가 SGLang은 래딕스 트리, vLLM은 블록 해시로 다르다.

Modal의 현재 Advisor 데이터에는 요청당 캐시된 입력 45,000 토큰을 가정한 에이전트형 워크로드(Online agentic)가 들어 있어, 원문이 지적한 접두사 재사용 조건을 일부 다룬다. 그러나 이 데이터도 모델마다 엔진 하나만 측정했기 때문에 두 엔진을 직접 비교할 수는 없다. Modal의 워크로드 문서는 처리량이 중요한 오프라인 배치 워크로드에는 vLLM을, 지연이 중요한 온라인 워크로드에는 텐서 병렬화와 EAGLE-3 투기적 디코딩을 켠 SGLang을 권한다. 이는 플랫폼 운영 경험과 설정을 포함한 권고이지, 기본 설정 비교표의 보편적인 승자 결론이 아니다.

한계와 오해하기 쉬운 점

이 글은 새 엔진 비교 실험이 아니라 기존 설명과 벤치마크를 읽는 해설이다. Red Hat은 vLLM의 가장 큰 기업 기여자라고 밝히고 관련 제품도 표시한다. 따라서 글쓴이의 이해관계를 함께 살펴야 한다. 또한 기본 설정 결과를 튜닝한 운영 환경으로 옮기거나, 한 GPU와 모델에서의 처리량 차이를 모든 서비스에 적용할 수 없다.

PagedAttention과 RadixAttention을 서로 배타적인 전체 엔진 구조로 볼 수도 없다. 두 엔진 모두 접두사 캐싱과 연속 배칭을 지원하고, SGLang도 페이지화된 KV 캐시 관리를 사용한다. 차이는 구현과 일정 조정, 모델·장비 지원, 실제 트래픽에서 드러난다. 이런 조건을 제외하고 기능 이름 하나만으로 엔진을 고르는 것은 이 글의 결론과도 맞지 않는다.

실제로 어떻게 활용할까

실제로는 반복되는 시스템 지시문과 도구 정의가 얼마나 많은지, 입력·출력 길이가 어떻게 분포하는지부터 측정하면 된다. GuideLLM처럼 OpenAI 호환 서버에 실제 또는 합성 요청을 보내는 도구로 같은 트래픽을 두 엔진에 적용할 수 있다. 현재 사용할 버전과 GPU를 고정하고, 처리량뿐 아니라 첫 토큰과 전체 답변 지연, 원하는 서비스 수준 목표를 함께 비교해야 한다. 여기서는 프로그램을 설치하거나 사용자 장비에서 성능을 측정하지 않았다.

하드웨어 선택도 별도 확인이 필요하다. 원문은 vLLM의 TPU·Intel·CPU·Apple 지원 경험이 더 오래됐다고 설명하지만, 현재 SGLang README에도 플랫폼별 문서가 있다. 지원 목록에 이름이 있다는 사실만으로 원하는 모델과 모든 최적화가 같은 수준으로 작동하는 것은 아니다. 요구 모델과 장비를 먼저 정하고 실제 실행 경로와 성능을 확인하는 것이 이 해설에서 얻을 수 있는 실용적인 판단 순서다.

원문에서 확인한 근거 6곳

vLLM은 PagedAttention으로 KV 캐시를 고정 크기 블록으로 나누어 비연속 메모리에 할당함으로써 GPU 메모리 낭비를 줄였다.Fixing wasted GPU memory with PagedAttention
SGLang의 RadixAttention은 계산한 KV 캐시를 토큰 접두사를 키로 하는 래딕스 트리에 저장하고, 새 요청이 오면 일치하는 부분을 재사용한다.SGLang: Reusing work across related requests
인용 표의 입력 128/출력 1024 조건에서는 vLLM 5.34req/s, SGLang 6.50req/s다. 각 엔진의 p95 TTFT가 1초 미만인 최대 요청률을 각각 골랐다.What independent benchmarks show
Modal의 테스트 프롬프트는 제인 오스틴의 『오만과 편견』에서 무작위로 잘라 낸 조각이라 요청끼리 접두사를 거의 공유하지 않는다.What independent benchmarks show
vLLM의 접두사 캐싱은 해시 기반으로, 각 KV 블록을 그 블록의 토큰과 앞선 접두사의 해시로 식별하며 가득 찬 블록만 캐시한다.Automatic Prefix Caching
Modal의 워크로드 문서는 오프라인 배치 워크로드에는 vLLM을, 지연이 중요한 온라인 워크로드에는 텐서 병렬화와 EAGLE-3 투기적 디코딩을 켠 SGLang을 권한다.The three types of LLM workloads and how to serve them

출처소개 글 — 파이토치 한국

10월 18일(일) 정리 · AI가 쓰고 원문과 대조

AI 목록