vLLM vs SGLang 2026: H100 벤치마크 결과 공개

vLLM vs SGLang 2026: H100 벤치마크 결과 공개

Hugging Face는 2025년 12월 TGI(Text Generation Inference)를 유지 보수 모드(maintenance mode)로 전환했으며, 새로운 배포를 위해 팀들에게 vLLM 또는 SGLang을 사용할 것을 권장하고 있습니다. 오늘 추론 스택을 구축한다면, 진짜 질문은 "TGI에서 벗어나야 하는가?"가 아니라 "이 두 엔진 중 어느 것이 내 워크로드에 실제로 적합한가?"입니다.

요약

vLLM을 선택하세요: 가장 광범위한 하드웨어 지원, 가장 큰 커뮤니티, 그리고 AWS, GCP, Azure 전반에 걸쳐 검증된 프로덕션 경로를 원한다면.

SGLang을 선택하세요: 멀티 턴 대화, 구조화된 출력(structured outputs), 또는 RAG와 같은 프리픽스 중심 파이프라인에 부하가 크고, 상대적으로 작은 생태계에서도 작업하는 데comfortable하다면.

이제 각 엔진이 실제로 어디에서 우위를 점하는지 자세히 살펴보겠습니다.

어떻게 여기까지 왔는가? TGI의 퇴장

Text Generation Inference(TGI)는 수년간 Hugging Face 생태계를 이끌었지만, 2025년 12월 기준으로 버그 수정만 수용하며 새로운 기능은 추가되지 않습니다. Hugging Face의 자체 Inference Endpoints는 이제 기본적으로 vLLM을 사용하며, 대안으로 SGLang을 제공합니다.

이는 자체 호스팅 LLM 서빙을 위한 두 가지 진정한 경쟁자만 남게 되었음을 의미합니다. 둘 다 오픈소스이며, 둘 다 OpenAI API를 지원하고, 둘 다 NVIDIA GPU에서 실행됩니다. 차이점은 부하가 걸릴 때 드러납니다.

결론: vLLM과 SGLang 모두 프로덕션 환경에서 TGI를 대체할 준비가 되었습니다. 마이그레이션을 고려 중이라면 둘 다 안전한 선택이며, 이 가이드의 나머지 부분은 어떤 것을 선택할지 결정하는 데 도움을 줄 것입니다.

처리량(Throughput) 및 지연 시간(Latency) 벤치마크

벤치마크 결과는 모델, GPU 및 동시성(concurrency) 수준에 따라 달라지므로, 동일한 하드웨어에서 수행된 독립 테스트의 수치를 참고합니다. 다음 데이터는 FP8 형식의 Llama 3.3 70B Instruct를 사용한 Spheron의 H100 벤치마크와 Llama 3.1 8B를 사용한 PremAI의 테스트에서 가져왔습니다.

H100에서의 Llama 3.3 70B (FP8)

H100에서의 Llama 3.1 8B

더 작은 모델에서는 격차가 더 벌어집니다. PremAI의 측정 결과, SGLang은 약 16,200 tok/s, vLLM은 12,500 tok/s로 기록되어 SGLang이 29%의 처리량 우위를 보였습니다. LMDeploy는 여기서 SGLang과 비슷한 성능을 보였지만, 이는 별도의 논의 주제입니다.

수치가 의미하는 바

70B 스케일에서는 차이가 미미합니다(3-5%). 하지만 8B 스케일에서는 상당합니다. 이 패턴은 합리적인데, SGLang의 RadixAttention은 프리필(prefill)이 총 비용에서 더 큰 비중을 차지할 때, 즉 작은 모델과 짧은 출력에서 더 큰 효과를 발휘하기 때문입니다.

테일 지연 시간(tail latency)도 유사한 이야기를 합니다. SGLang의 TTFT p95는 테스트된 모든 동시성 수준에서 vLLM보다 일관되게 5-8% 낮았습니다. 모든 50ms가 중요한 실시간 채팅 인터페이스를 구축한다면, 이 격차는 사용자 수에 따라 누적되어 큰 차이가 됩니다.

결론: SGLang이 특히 작은 모델에서 raw 처리량 면에서 우세합니다. vLLM은 70B 이상 스케일에서 근접한 성능을 보입니다. 대부분의 프로덕션 워크로드에서는 차이가 한 자릿수 퍼센트 수준으로, 대규모 운영에서는 의미가 있지만 결정적인 차이(dealbreaker)는 아닙니다.

프리픽스 캐싱: RadixAttention vs 자동 프리픽스 캐싱

두 엔진 모두 반복되는 프리픽스에 대한 KV 계산을 캐시하지만, 특정 워크로드에서 중요한 방식으로 메커니즘이 다릅니다. API 레벨의 프롬프트 캐싱에 이미 익숙하다면, 이를 서버 사이드 버전이라고 생각하면 됩니다.

vLLM은 블록 단위 해싱을 사용합니다. KV 캐시를 고정 크기 블록으로 나누고, 해시하여 새 요청에서 일치하는 항목을 조회합니다. 예측 가능하고 효율적이며 이해하기 쉽지만, 캐시 히트를 위해서는 일관된 블록 경계가 필요합니다.

SGLang은 토큰 수준에서 인덱싱된 래딕스 트리(radix tree)를 사용합니다. 수동 구성 없이 요청 간 공유된 프리픽스를 자동으로 발견합니다. 50명의 사용자가 동일한 대화 스레드에서 메시지를 보내면, SGLang은 공통 프리픽스를 자동으로 찾아 재사용합니다.

실제로 중요한 경우

RunPod은 멀티 턴 대화를 벤치마크했으며, 높은 동시성 하에서 SGLang은 일관되게 ~30-31 tok/s를 제공한 반면, vLLM은 캐시 압력이 증가함에 따라 22 tok/s에서 16 tok/s로 떨어지는 것을 발견했습니다. 이는 챗봇 및 에이전트 워크로드에서 의미 있는 격차입니다.

모든 요청이 동일한 시스템 프롬프트를 사용하는 템플릿 기반 프롬프트의 배치 추론에서는 vLLM의 접근 방식도 잘 작동합니다. 캐시 경계가 템플릿 구조와 자연스럽게 정렬되기 때문입니다.

결론: 동적이고 멀티 턴 워크로드에서는 SGLang이 우세합니다. vLLM은 프리픽스가 예측 가능한 배치 추론 및 템플릿 기반 프롬프트에 충분히 적합합니다.

구조화된 출력(Structured Outputs)

JSON 스키마 강제 적용이나 제약된 생성(constrained generation)이 필요하다면 이 섹션이 매우 중요합니다. 두 엔진 모두 XGrammar 및 LLGuidance와 같은 문법 백엔드를 통해 구조화된 출력을 지원하지만, 성능 양상은 매우 다릅니다.

SqueezeBits는 상세한 벤치마크를 수행했으며, vLLM은 guided decoding이 활성화될 때, 특히 배치 크기 8 이상에서 처리량이 현저히 저하되는 것을 발견했습니다. 반면 SGLang은 마스크 생성을 GPU 추론 단계와 오버랩(overlap)시켜 오버헤드를 최소화합니다.

반복적 vs 동적 스키마

백엔드 선택도 중요합니다:

구조화된 강제 적용 없이는 복잡한 스키마에서 정확도가 ~61%로 떨어집니다. 이를 적용하면 정확도가 20-25%p 상승합니다. 따라서 프로덕션 에이전트 워크플로우에서는 이것이 선택 사항이 아니며, 선택한 엔진이 얼마나 많은 처리량을 희생할지 결정합니다.

결론: 구조화된 출력에서는 SGLang이 우세합니다. 파이프라인이 JSON 스키마 강제 적용에 의존한다면(대부분의 에이전트 워크플로우가 그러함), SGLang의 오버랩 접근 방식은 처리량 세금을 내지 않아도 된다는 의미입니다.

Multi-LoRA 및 파인튜닝 모델 서빙

두 엔진 모두 단일 기본 모델에서 여러 LoRA 어댑터를 서빙하는 것을 지원하며, 이는 다양한 테넌트나 작업을 위해 모델을 파인튜닝할 경우 필수적입니다.

SGLang은 Multi-LoRA를 네이티브 배칭을 갖춘 일급 기능으로 취급하여, 서로 다른 어댑터를 대상으로 하는 요청이 동일한 배치를 공유할 수 있습니다. vLLM도 이를 지원하지만, 최근 릴리스에서 SGLang의 구현이 약간 더 다듬어진 것으로 보입니다.

실질적인 차이는 무엇일까요? 하나의 Llama 70B 기본 모델에서 5-10개의 LoRA 어댑터를 서빙한다면 둘 다 잘 작동합니다. 그러나 이질적인 트래픽 패턴을 가진 50개 이상의 어댑터를 실행한다면, SGLang의 네이티브 배칭이 스케줄링을 더 원활하게 처리합니다.

결론: 대규모 Multi-LoRA 환경에서는 SGLang이 약간 우세합니다. 소수의 어댑터라면 두 엔진 모두 equally well 작동합니다.

Speculative Decoding

두 엔진 모두 speculative decoding을 지원합니다. 이는 작은 "draft" 모델을 사용하여 메인 모델이 병렬로 검증할 토큰을 예측하는 방식입니다. 그 결과 메모리 바운드(memory-bound) 시나리오에서 추론 속도가 2-3배 빨라집니다.

vLLM은 최근 Unified Parallel Drafting을 도입했으며, speculative decoding은 이제 구조화된 출력과 함께 작동합니다. SGLang의 구현도 능력 면에서 유사하며, 중간 정도의 동시성 수준에서 약간 더 나은 성능을 보입니다.

진정한 차별화 요소는 엔진이 아니라 speculative decoding이 워크로드에 적합한지 여부입니다. 이는 병목 현상이 컴퓨팅이 아닌 메모리 대역폭인 대형 모델의 긴 출력에서 가장 도움이 됩니다.

결론: 무승부. 두 엔진 모두 비교 가능한 speculative decoding 속도 향상을 제공합니다.

하드웨어 지원 및 배포

이 부분에서 vLLM이 크게 앞서갑니다.

vLLM

• NVIDIA GPU (A100, H100, H200, B200)
• AMD GPU (MI250, MI300X)
• Intel GPU (vllm-xpu-kernels 통해)
• AWS Trainium 및 Inferentia
• Google TPU
• Helm 차트, startup/readiness/liveness probe를 포함한 성숙한 Kubernetes 문서
• 기본 제공 NVIDIA Container Toolkit 통합

SGLang

• NVIDIA GPU (A100, H100, H200, B200)
• AMD GPU (ROCm 통해 MI300X)
• Docker 우선 배포
• Kubernetes는 가능하지만 문서화가 덜 됨

NVIDIA 또는 AMD 이외의 환경에서 배포한다면 vLLM이 유일한 옵션입니다. 특히 AWS에서는 Trainium 지원으로 인해 추론 비용을 크게 절감할 수 있으며, SGLang은 해당 하드웨어를 지원하지 않습니다.

표준 NVIDIA GPU에서 운영하는 팀에게는 배포 이야기가 비슷합니다. 둘 다 Docker 이미지와 OpenAI 호환 엔드포인트를 제공합니다. vLLM은 단순히 더 많이 검증된 프로덕션 가이드와 커뮤니티 기여 Helm 차트를 보유하고 있을 뿐입니다.

로컬에서 LLM을 실행하기 위한 도구를 탐색하거나 자체 호스팅 추론에 대한 더 넓은 관점을 원한다면, 두 엔진 모두 데이터센터 하드웨어용으로 설계되었지만 소비자용 GPU에서도 로컬 배포를 지원합니다.

결론: 하드웨어 다양성과 배포 성숙도 면에서 vLLM이 우세합니다. NVIDIA나 AMD를 사용한다면 SGLang도 괜찮습니다. 그 외의 경우 vLLM이 유일한 선택입니다.

분리형 서빙(Disaggregated Serving)

두 엔진 모두 프리필(계산 집약적)과 디코드(메모리 집약적)를 별도의 워커 풀로 분리하는 것을 지원합니다. 이를 통해 각 단계를 독립적으로 확장할 수 있습니다. 프롬프트가 많은 급증 구간에는 프리필 워커를 더 많이, 긴 생성에는 디코드 워커를 더 많이 배치할 수 있습니다.

SGLang은 분리를 위한 전송 백엔드로 Mooncake와 NIXL을 지원하며, NVIDIA GB200 NVL72 클러스터에서 디코드 처리량이 2.7배 높아졌다는 결과를 발표했습니다. vLLM의 분리형 서빙도 기능하지만, 문서화가 덜 두드러집니다.

이 기능은 매우 대규모(96+ GPU)에서 가장 중요합니다. 몇 개의 GPU만 실행한다면 아직 필요하지 않을 수 있습니다.

결론: 분리형 서빙 성숙도 면에서 SGLang이 약간 우세합니다. 둘 다 지원하지만, SGLang이 더 많은 실제 결과를 발표했습니다.

언제 무엇을 사용할까: 의사 결정 프레임워크

많은 팀에게 솔직한 답변은: 둘 다 시도해 보라는 것입니다. 둘 다 오픈소스이며, 동일한 OpenAI API를 노출하므로, 전환은 컨테이너 교체에 불과합니다. 실제 워크로드를 각각에서 하루 동안 실행하고 귀하에게 중요한 지표를 비교해 보세요.

여러 추론 백엔드 간에 트래픽을 라우팅한다면, LLM 게이트웨이를任一 엔진 앞에 배치하여 장애 조치(failover), 속도 제한(rate limiting) 및 관찰 가능성(observability)을 처리할 수 있습니다.

Techsy가 추론 서버를 선택하는 방식

우리가 팀들이 LLM 기반 기능을 배포하도록 돕할 때, 추론 엔진 선택은 다음 세 가지 질문으로 귀결됩니다:

1. 어떤 하드웨어에 종속되어 있나요? Trainium이나 TPU라면 vLLM입니다. 그 외에는 둘 다 작동합니다.
2. 워크로드의 형태는 어떻습니까? 멀티 턴 채팅과 에이전트 루프는 SGLang의 프리픽스 캐싱을 선호합니다. 배치 처리와 단순 완성은 둘 다 괜찮습니다.
3. 운영(ops) 역량은 얼마나 있습니까? vLLM의 더 큰 커뮤니티는 새벽 3시에 문제가 발생했을 때 더 많은 StackOverflow 답변과 Helm 차트를 의미합니다.

우리는 두 엔진 모두에서 프로덕션 워크로드를 실행해 왔습니다. 그들은 genuinely close합니다. 정답은 추상적으로 하나가 "더 낫다"는 것이 아니라 귀하의 제약 조건에 달려 있습니다.

추론 서버 선택이나 배포에 도움이 필요하신가요? 저희에게 연락하세요. 워크로드를 평가하고 적절한 스택을 추천해 드리겠습니다.

도구 선택은 쉬운 반쪽입니다. 실제 제품 내에서 안정적으로 실행되도록 만드는 것이 대부분의 팀이 막히는 부분이며,这正是 저희 AI 통합 팀이 RAG 파이프라인부터 맞춤형 에이전트까지 고객을 위해 구축하는 부분입니다.

자주 묻는 질문

SGLang이 vLLM보다 빠른가요?

작은 모델(7B-8B)에서 SGLang은 H100 GPU에서 약 29% 더 높은 처리량을 보입니다. 70B+ 모델에서는 격차가 3-5%로 좁아집니다. SGLang은 또한 테스트된 모든 동시성 수준에서 더 낮은 테일 지연 시간(TTFT p95)을 가집니다.

vLLM과 SGLang을 OpenAI API 형식으로 사용할 수 있나요?

예. 둘 다 기본적으로 OpenAI 호환 엔드포인트를 노출합니다. 클라이언트 코드를 변경하지 않고 하나를 다른 것으로 교체할 수 있습니다. /v1/chat/completions 호출은 둘 다에서 동일하게 작동합니다.

왜 Hugging Face는 TGI를 폐기했나요?

TGI는 2025년 12월 유지 보수 모드에 진입했습니다. Hugging Face는 별도의 추론 엔진을 유지하는 대신 vLLM과 SGLang에 기여하기로 결정했습니다. TGI는 기존 배포에서 여전히 작동하지만 새로운 기능은 추가되지 않습니다.

SGLang은 NVIDIA 및 AMD GPU를 지원하나요?

SGLang은 NVIDIA GPU(A100, H100, H200, B200)와 AMD GPU(ROCm 통해 MI300X)를 지원합니다. Intel GPU, AWS Trainium, Inferentia 또는 Google TPU는 지원하지 않습니다. vLLM이 더 광범위한 하드웨어를 커버합니다.

RadixAttention이란 무엇이며 왜 중요한가요?

RadixAttention은 SGLang의 프리픽스 캐싱 메커니즘입니다. 토큰 수준에서 인덱싱된 래딕스 트리에 KV 캐시 항목을 저장하여 요청 간 공유된 프리픽스를 자동으로 발견합니다. 이는 반복적인 컨텍스트를 다시 계산할 필요가 없기 때문에 멀티 턴 대화와 RAG 파이프라인을 상당히 빠르게 만듭니다.

구조화된 JSON 출력에 어떤 엔진이 더 나은가요?

SGLang입니다. 문법 마스크 생성을 GPU 추론과 오버랩시켜 구조화된 출력 강제 적용이 처리량에 거의 영향을 미치지 않습니다. vLLM은 guided decoding이 활성화될 때 배치 크기 8 이상에서 눈에 띄는 저하를 보입니다.

하나의 기본 모델에서 여러 LoRA 어댑터를 서빙할 수 있나요?

두 엔진 모두 Multi-LoRA 서빙을 지원합니다. SGLang은 이를 네이티브 기능으로 취급하여 동일한 요청 배치에서 서로 다른 어댑터 간에 배칭합니다. vLLM도 지원하지만, 어댑터 수가 많을 때 SGLang의 스케줄링이 더 효율적입니다.

분리형 프리필/디코드 서빙이란 무엇인가요?

프롬프트를 처리하는 프리필 단계와 토큰을 생성하는 디코드 단계를 별도의 GPU 워커에서 실행하는 것을 의미합니다. 프리필은 계산 바운드(compute-bound)이고 디코드는 메모리 바운드(memory-bound)입니다. 이를 분리하면 각각을 독립적으로 확장할 수 있습니다. 두 엔진 모두 이를 지원하며, SGLang이 더 많은 프로덕션 결과를 발표했습니다.

TGI에서 vLLM 또는 SGLang으로 어떻게 마이그레이션하나요?

세 가지 모두 OpenAI 호환 API를 노출하므로, 마이그레이션은 대부분 컨테이너 교체입니다. Docker Compose 또는 Kubernetes 배포를 새 이미지로 지정하고, 모델 로딩 플래그를 조정하며, 헬스 체크 엔드포인트를 업데이트하세요. 클라이언트 코드는 동일하게 유지됩니다.

RAG 파이프라인에는 vLLM과 SGLang 중 무엇을 사용해야 하나요?

RAG에는 SGLang이 더 강력한 선택입니다. RadixAttention은 RAG 파이프라인이 반복적으로 보내는 긴 시스템 프롬프트와 문서 컨텍스트를 자동으로 캐시하고 재사용합니다. vLLM의 블록 단위 캐싱도 작동하지만, 문서_chunks이 요청마다 약간 다를 경우 SGLang의 토큰 단위 접근 방식으로 더 높은 캐시 히트율을 볼 수 있습니다.

최종 결론

SGLang이 더 많은 카테고리에서 승리하지만, vLLM의 장점인 하드웨어 다양성과 생태계 성숙도는 노드가 다운된 새벽 3시에 중요한 요소들입니다.

NVIDIA 하드웨어를 사용하고 있으며 워크로드에 멀티 턴 대화, 구조화된 출력을 가진 에이전트, 또는 공유 프리픽스가 있는 RAG 파이프라인이 포함된 경우, SGLang으로 시작하세요. 중요한 곳에서 더 나은 처리량과 더 낮은 지연 시간을 얻을 수 있습니다.

멀티 클라우드 유연성, 비-NVIDIA 하드웨어 지원, 또는 가장 큰 오픈소스 LLM 서빙 커뮤니티의 안락함이 필요한 경우, vLLM으로 시작하세요. 이는 대부분의 팀에게 잘 맞는 더 안전한 기본값입니다.

어느 쪽이든 두 엔진 모두 우수하고 빠르게 개선되고 있습니다. 하나를 선택하고, 배포하고, 실제 워크로드를 측정하며, 수치가 그렇게 말하면 전환하세요. OpenAI 호환 API는 이러한 전환을 고통스럽지 않게 만듭니다.

출처

• Spheron H100 벤치마크: vLLM vs TensorRT-LLM vs SGLang
• PremAI: vLLM vs SGLang vs LMDeploy 벤치마크
• SqueezeBits: vLLM 및 SGLang의 Guided Decoding 성능
• RunPod: SGLang vs vLLM KV 캐시 재사용
• SGLang 공식 문서
• vLLM 공식 문서