SGLang vs vLLM, 어떤 추론 엔진을 써야 하나

LLM을 직접 서빙하려고 vLLM을 붙였다가 응답 속도가 생각보다 안 나온다는 분들, SGLang 얘기 한 번쯤 들어보셨을 텐데요. 두 엔진 다 실사용 벤치마크를 찾을 수 있는 만큼 다 찾아봤고, 수치가 벤치마크 조건마다 꽤 갈리길래 어떤 조건에서 어떤 결과가 나오는지, 그리고 실제로 프로덕션에서 어떤 회사들이 어떻게 쓰고 있는지까지 같이 정리했어요. 핵심 비교부터 표로 보여드릴게요.

한눈에 보는 비교표

항목	vLLM	SGLang
핵심 기술	페이지드어텐션 (KV 캐시 블록 분할)	래딕스어텐션 (프리픽스 캐시 재사용)
8B급 모델 처리량 (PremAI 측정)	초당 12,500토큰	초당 16,200토큰 (+29%)
70B급 모델 처리량 격차	기준	+3~5% (격차 축소)
단일 턴(캐시 미스) 처리량	초당 60토큰 (우위)	초당 52.7토큰
캐시 히트 시 처리량	초당 32.8토큰	초당 35토큰 (우위)
고동시성 처리량 추이	22→16토큰/요청 (하락)	30~31토큰/요청 (유지)
깃허브 스타	약 75,000	약 25,000
릴리스 주기	상대적으로 느림	약 3주
OS 지원	리눅스/윈도우(WSL)/맥OS	리눅스 전용(맥OS GPU 미지원)
동시 요청 확장성	우수	약 150개 이상에서 GIL 병목
최적 워크로드	다양한 모델, 단일 턴 위주	멀티턴·RAG·에이전트(프리픽스 반복)

표로 보면 결론은 명확해요. 프롬프트가 겹치지 않는 단일 턴 워크로드에서는 vLLM이 오히려 앞서기도 하고, 프롬프트 앞부분이 반복되는 멀티턴·RAG·에이전트 워크로드에서는 SGLang이 확실히 유리해요. 아래에서 이 표의 각 항목이 왜 이렇게 나오는지 좀 더 풀어드릴게요.

 

두 엔진의 근본적인 차이: KV 캐시 관리 방식

 

vLLM과 SGLang의 차이는 결국 KV 캐시, 그러니까 어텐션 계산 결과를 저장하는 GPU 메모리 구조를 어떻게 관리하느냐로 갈려요.

vLLM은 페이지드어텐션이라는 방식을 써요. 운영체제의 가상 메모리 관리 기법을 그대로 가져와서 KV 캐시를 불연속적인 블록으로 나눠 저장하는 방식이에요. 이 방식 덕분에 GPU 메모리 낭비를 최대 80%까지 줄일 수 있어요.

vLLM 팀은 v0.8.0부터 아예 엔진 아키텍처를 다시 짰는데, 스케줄러와 엔진 코어, GPU 워커를 ZeroMQ로 통신하는 멀티프로세스 구조로 분리하면서 기존 설계보다 최대 1.7배 높은 처리량을 낸다고 알려져 있어요. 지원 범위도 굉장히 넓어서, 텍스트 LLM은 물론이고 비전-언어 모델, 큐웬3-ASR/Omni 같은 오디오 모델, 임베딩 모델까지 모든 엔진 중 가장 폭넓은 모델과 하드웨어를 지원해요.

 

SGLang은 래딕스어텐션이라는 방식을 써요. 여러 요청이 프롬프트의 앞부분을 공유하는 상황, 그러니까 같은 문서를 반복해서 검색하거나 멀티턴 대화가 이어지는 상황에서 이미 계산해둔 KV 캐시를 재사용하는 방식이에요. 프롬프트가 겹치는 비율이 높을수록 SGLang이 유리해지는 구조예요.

H100 벤치마크 수치는 조건마다 다르게 나와요

가장 많이 인용되는 수치는 PremAI가 라마 3.1 8B 모델로 측정한 결과인데, SGLang이 초당 약 16,200토큰, vLLM이 초당 약 12,500토큰으로 29% 정도 SGLang이 앞섰어요. 다만 이 수치를 어디에나 그대로 적용하면 안 되는 게, 같은 벤치마크 팀이 라마 3.3 70B로 측정했을 때는 두 엔진의 격차가 3~5%까지 줄어들었어요. Spheron이 H100 80GB에서 라마 3.3 70B를 FP8 정밀도로 돌린 별도 테스트에서도 비슷한 패턴이 나왔는데, 모델이 커질수록 프리필 연산이 전체 비용에서 차지하는 비중이 줄어들면서 래딕스어텐션의 이점이 옅어지는 거예요.

반대로 프롬프트가 많이 겹치는 워크로드에서는 이 격차가 훨씬 크게 벌어져요. 딥시크-R1-Distill-Llama-70B로 진행한 Runpod 테스트에서는 프롬프트가 완전히 다른 단일 턴 요청에서는 오히려 vLLM이 앞섰는데(초당 60토큰 vs SGLang 52.7토큰), 캐시 히트가 발생하는 상황이 되자 SGLang이 역전했어요(캐시 적용 시 초당 35토큰 vs vLLM 32.8토큰). 동시 요청이 많아질수록 격차는 더 벌어져서, 높은 동시성 상황에서 SGLang은 요청당 초당 30~31토큰을 유지하는 반면 vLLM은 22토큰에서 16토큰까지 떨어진다는 측정 결과도 있었어요. 지연 시간 쪽에서도 100개 이상 동시 요청부터는 vLLM의 테일 TTFT(첫 토큰까지 걸리는 시간)가 늘어지기 시작하는데, SGLang의 p95 TTFT는 무거운 부하에서도 상대적으로 안정적으로 유지된다는 보고가 있어요.

프리필-디코드 분리와 최신 로드맵 차이

두 프로젝트 모두 계속 진화하고 있는데, 방향이 살짝 달라요. vLLM은 분리형 프리필(disaggregated prefill) 방식과 블랙웰 아키텍처 최적화 쪽으로 힘을 싣고 있고, SGLang은 딥시크 V4가 공식적으로 지지를 표명하면서 딥시크 계열 모델 최적화에서 확실한 우위를 보이고 있어요. 실제로 96개의 H100으로 딥시크 R1을 프리필-디코드 분리 방식으로 대규모 서빙한 최초의 엔진이 SGLang이었다는 기록도 있고요. SGLang의 릴리스 주기는 굉장히 빠른 편인데, 약 3주 간격으로 새 버전이 나오면서 신규 모델 지원 속도도 빨라요.

실제로 어떤 회사들이 뭘 쓰고 있나

vLLM 쪽 프로덕션 사례를 보면 아마존이 2억 5천만 고객을 대상으로 하는 루퍼스, 링크드인, 로블록스(주당 40억 토큰 처리), 메타, 미스트랄AI, IBM 같은 큰 조직들이 운영 시스템에 vLLM을 쓰고 있어요. 스트라이프는 vLLM으로 전환하면서 추론 비용을 73% 절감했다고 보고했고요. vLLM 팀은 프로젝트 상용화를 위해 인퍼랙트라는 별도 회사를 세웠고 2026년 1월에 1억 5천만 달러 투자를 받았어요. 커뮤니티 규모도 확실히 큰 편이라 깃허브 스타가 약 75,000개인데, SGLang은 약 25,000개예요. 커뮤니티가 크다는 건 문제가 생겼을 때 참고할 만한 자료나 서드파티 통합이 그만큼 많다는 뜻이기도 해요.

 

에이전트 인프라 쪽에서는 흐름이 좀 달라요. 2026년 4월 기준 기업의 51%가 이미 프로덕션에서 에이전트를 운영하고 있다는 조사가 있는데, SGLang의 구조화된 생성 모델이 에이전트 루프와 자연스럽게 맞물린다는 평가가 있어요. 도구 호출이 많고 그래머 제약 디코딩이 처리량을 갉아먹는 상황이라면 SGLang의 GPU 오버랩 구현이 특히 도움이 된다는 실전 보고도 있고요.

알아둬야 할 SGLang의 제약

SGLang이 만능은 아니에요. 몇 가지 확실한 제약이 있는데, 우선 리눅스 전용이라 윈도우에서는 WSL이 필요하고 네이티브 맥OS GPU 서빙은 지원하지 않아요. 파이썬 GIL 병목 현상 때문에 요청 라우터가 약 150개 이상의 동시 요청부터는 확장 한계에 부딪히고요. GGUF 지원도 제한적이라 llama.cpp만큼 양자화된 엣지 배포에 최적화돼 있지는 않아요. 릴리스 후보 단계에서 종속성 문제가 발생할 수 있어서 안정성 측면에서 vLLM보다 검증이 덜 된 편이라는 평가도 있어요.

 

실전: 두 엔진 다 로컬에서 띄워보기

# vLLM 설치 및 서버 실행
pip install vllm
vllm serve meta-llama/Llama-3.1-8B-Instruct

# SGLang 설치 및 서버 실행
pip install "sglang[all]"
python -m sglang.launch_server --model-path meta-llama/Llama-3.1-8B-Instruct --port 30000

# vLLM 스펙큘레이티브 디코딩 활성화 예시 (지연 시간 개선)
python -m vllm.entrypoints.openai.api_server \
  --model meta-llama/Llama-3.1-8B-Instruct \
  --speculative-model small-llama

 

위 명령어로 두 엔진 다 손쉽게 로컬에서 띄워볼 수 있으니까, 본인 워크로드의 실제 트래픽 패턴을 재현한 벤치마크를 직접 돌려보시는 걸 추천드려요. 벤치마크 수치는 모델 크기, GPU, 동시 요청 수, 프롬프트 재사용 비율에 따라 크게 달라지기 때문에, 남이 측정한 숫자보다 본인 환경에서 나온 숫자가 훨씬 신뢰할 만해요.

 

실전: 어떤 워크로드에 뭘 골라야 하나

정리하면 이렇게 나눠서 보시면 될 것 같아요. 이미 vLLM을 운영 중이고 별문제 없다면 굳이 옮길 이유는 없어요. 프롬프트 재사용 비율이 40% 이상으로 확인되거나 구조화된 출력의 지연 시간이 SLA를 갉아먹고 있는 상황이 아니라면 전환 비용이 이점을 상쇄할 수 있거든요. 반대로 멀티턴 챗봇이나 RAG 파이프라인처럼 프롬프트 앞부분이 반복적으로 겹치는 워크로드, 또는 여러 도구를 호출하는 에이전트 시스템을 새로 구축하는 상황이라면 SGLang으로 시작하는 게 유리해요.

 

실제 실무자들 사이에서는 "새 배포는 일단 vLLM으로 시작하고, 워크로드 프로파일이 확인되면 그때 재평가한다"는 식의 보수적인 접근을 취하는 팀도 많고, 반대로 에이전트 중심 스택을 처음부터 새로 구축하는 팀은 SGLang부터 시작하는 경우가 늘고 있다는 보고도 있었어요.

정리하면

vLLM은 넓은 모델 지원과 빠른 커뮤니티 대응, 검증된 안정성이 강점이고, SGLang은 프롬프트가 반복되는 워크로드와 에이전트 중심 시스템에서 확실한 성능 이점이 있어요. 29%라는 숫자 하나만 보고 결정하지 마시고, 본인 서비스가 실제로 어떤 트래픽 패턴을 갖고 있는지부터 파악하시는 게 먼저예요. 단일 턴 요청이 대부분이면 그 격차는 거의 사라지고, 반대로 캐시 히트가 자주 발생하는 구조라면 격차가 몇 배로 벌어질 수도 있으니까요.