Hugging Face는 2025년 12월에 TGI를 유지보수 모드로 전환했고, 이제 팀들에게 새로운 배포를 위해 vLLM이나 SGLang을 사용하도록 권장하고 있습니다. 오늘 추론 스택을 구축하려면 "TGI에서 벗어나야 하는가?"가 아니라 "이 두 엔진 중 어느 것이 우리 워크로드에 맞는가?"가 진짜 질문입니다.
빠른 요약
vLLM을 선택하세요: 가장 광범위한 하드웨어 지원, 가장 큰 커뮤니티, AWS, GCP, Azure를 아우르는 검증된 프로덕션 경로를 원한다면.
SGLang을 선택하세요: 멀티턴 대화, 구조화된 출력, RAG 같은 프리픽스 기반 파이프라인으로 워크로드가 무거우며, 더 작은 생태계에 만족한다면.
이제 각 엔진이 실제로 우위를 점하는 부분을 알아봅시다.
어떻게 여기까지 왔나? TGI의 종료
Text Generation Inference(TGI)는 수년간 Hugging Face 생태계를 주도해왔지만, 2025년 12월부터는 버그 수정만 수용하고 새로운 기능은 받지 않습니다. Hugging Face의 자체 Inference Endpoints는 이제 vLLM을 기본으로 설정하며, SGLang을 대안으로 제시합니다.
이는 자체 호스팅 LLM 서빙을 위한 두 개의 실제 경쟁 상대를 남깁니다. 둘 다 오픈소스이고, 둘 다 OpenAI API를 지원하며, 둘 다 NVIDIA GPU에서 실행됩니다. 차이는 부하가 걸릴 때 나타납니다.
결론: vLLM과 SGLang 모두 TGI의 프로덕션 수준 대체재입니다. 마이그레이션 중이라면 둘 다 안전한 선택이며, 이 가이드의 나머지 부분이 어느 것을 선택할지 결정하는 데 도움이 됩니다.
처리량과 지연 시간 벤치마크
벤치마크는 모델, GPU, 동시성에 따라 달라지므로, 동일한 하드웨어에서의 독립적 테스트 수치를 제시합니다. 다음 데이터는 Llama 3.3 70B Instruct(FP8)를 사용한 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)이 전체 비용의 더 큰 비율을 차지할 때, 즉 더 작은 모델과 더 짧은 출력에서 더 큰 효과를 냅니다.
테일 지연 시간도 유사한 이야기를 합니다. SGLang의 TTFT p95는 테스트된 모든 동시성 수준에서 일관되게 vLLM보다 5-8% 낮았습니다. 모든 50ms가 중요한 실시간 채팅 인터페이스를 구축 중이라면, 그 격차는 사용자 전체에 걸쳐 복합됩니다.
결론: SGLang은 특히 더 작은 모델에서 원시 처리량에서 승리합니다. vLLM은 70B 이상 규모에서 근접합니다. 대부분의 프로덕션 워크로드의 경우 차이는 단일 자릿수 백분율로, 규모에서는 의미 있지만 어느 쪽이든 결정적이지 않습니다.
프리픽스 캐싱: RadixAttention vs 자동 프리픽스 캐싱
두 엔진 모두 반복된 프리픽스에 대해 KV 연산을 캐싱하지만, 메커니즘은 특정 워크로드에서 중요한 방식으로 다릅니다. API 수준의 프롬프트 캐싱에 이미 익숙하다면, 이를 서버 측 버전으로 생각하면 됩니다.
vLLM은 블록 레벨 해싱을 사용합니다. KV 캐시를 고정 크기 블록으로 분할하고, 해시하며, 새 요청에서 일치를 조회합니다. 예측 가능하고 효율적이며 이해하기 쉽지만, 캐시 히트를 위해 일관된 블록 경계가 필요합니다.
SGLang은 토큰 수준에서 인덱싱된 래딕스 트리(radix tree)를 사용합니다. 수동 구성 없이 요청 간 공유 프리픽스를 자동으로 발견합니다. 50명의 사용자가 같은 대화 스레드에 메시지를 보내면, SGLang이 공통 프리픽스를 자동으로 찾아서 재사용합니다.
실제로 중요한 곳
RunPod는 멀티턴 대화를 벤치마크했고, SGLang이 높은 동시성 하에서 일관되게 ~30-31 tok/s를 제공하는 동안 vLLM은 캐시 압력이 증가하면서 22에서 16 tok/s로 떨어졌습니다. 이는 챗봇 및 에이전트 워크로드에 의미 있는 격차입니다.
템플릿화된 프롬프트의 배치 추론의 경우, 모든 요청이 동일한 시스템 프롬프트를 사용하면 vLLM의 접근 방식이 잘 작동합니다. 캐시 경계가 자연스럽게 템플릿 구조와 정렬됩니다.
결론: SGLang은 동적, 멀티턴 워크로드에서 승리합니다. vLLM은 프리픽스가 예측 가능한 배치 추론 및 템플릿화된 프롬프트에 완벽하게 적합합니다.
구조화된 출력
JSON 스키마 강제나 제약된 생성이 필요하다면, 이 섹션이 매우 중요합니다. 두 엔진 모두 XGrammar 및 LLGuidance 같은 문법 백엔드를 통해 구조화된 출력을 지원하지만, 성능 이야기는 매우 다릅니다.
SqueezeBits는 상세한 벤치마크를 실행했고, vLLM은 특히 배치 크기 8 이상에서 가이드된 디코딩이 활성화되면 현저한 처리량 저하를 보인다는 것을 발견했습니다. 반면 SGLang은 마스크 생성을 GPU 추론 단계와 겹쳐서, 오버헤드를 최소로 유지합니다.
반복적 vs 동적 스키마
백엔드 선택도 중요합니다:
구조화된 강제 없이는 복잡한 스키마에서 출력이 ~61% 정확성으로 떨어집니다. 적용하면 정확성이 20-25 백분포인트 증가합니다. 따라서 이는 프로덕션 에이전트 워크플로우에 선택사항이 아니며, 선택한 엔진이 처리량 손실이 얼마나 되는지 결정합니다.
결론: SGLang은 구조화된 출력에서 승리합니다. 파이프라인이 JSON 스키마 강제에 의존한다면(대부분의 에이전트 워크플로우가 그렇습니다), SGLang의 겹쳐진 접근 방식은 처리량 세금을 내지 않아도 됩니다.
멀티-LoRA 및 미세 조정 모델 서빙
두 엔진 모두 단일 기본 모델에서 여러 LoRA 어댑터 서빙을 지원하며, 이는 다양한 테넌트나 작업을 위해 모델을 미세 조정할 때 필수적입니다.
SGLang은 멀티-LoRA를 기본 기능으로 취급하며 네이티브 배칭을 지원합니다. 다른 어댑터를 대상으로 하는 요청이 동일한 배치를 공유할 수 있습니다. vLLM도 지원하지만, SGLang의 구현이 최근 릴리스에서 약간 더 세련되었습니다.
실질적인 차이는? 하나의 Llama 70B 기본 모델에서 5-10개의 LoRA 어댑터를 서빙 중이라면 둘 다 작동합니다. 50개 이상의 어댑터를 이질적 트래픽 패턴으로 실행 중이라면, SGLang의 네이티브 배칭이 스케줄링을 더 우아하게 처리합니다.
결론: SGLang은 규모의 멀티-LoRA에서 약간의 이점을 가집니다. 소수의 어댑터라면, 두 엔진 모두 동등하게 작동합니다.
추측 디코딩(Speculative Decoding)
두 엔진 모두 추측 디코딩을 지원하며, 이는 작은 "드래프트" 모델을 사용하여 토큰을 예측하고 주 모델이 병렬로 검증합니다. 결과는 메모리 바운드 시나리오에서 2-3배 빠른 추론입니다.
vLLM은 최근 Unified Parallel Drafting을 도입했고, 추측 디코딩이 이제 구조화된 출력과 함께 작동합니다. SGLang의 구현은 기능상 유사하며, 중간 동시성 수준에서 약간 더 나은 성능을 보입니다.
진정한 차별화 요소는 엔진이 아니라 추측 디코딩이 당신의 워크로드에 맞는지입니다. 병목이 메모리 대역폭이 아닌 컴퓨트인 큰 모델의 긴 출력에 가장 도움이 됩니다.
결론: 동점. 두 엔진 모두 비슷한 추측 디코딩 가속을 제공합니다.
하드웨어 지원 및 배포
여기서 vLLM이 상당히 앞선갑니다.
vLLM
- NVIDIA GPU(A100, H100, H200, B200)
- AMD GPU(MI250, MI300X)
- Intel GPU(vllm-xpu-kernels 경유)
- AWS Trainium 및 Inferentia
- Google TPU
- 성숙한 Kubernetes 문서(Helm 차트, 시작/준비/생존성 프로브 포함)
- NVIDIA Container Toolkit 통합(기본 제공)
SGLang
- NVIDIA GPU(A100, H100, H200, B200)
- AMD GPU(MI300X, ROCm 경유)
- Docker-first 배포
- Kubernetes는 가능하지만 문서화가 부족함
NVIDIA나 AMD 이외의 것에 배포한다면 vLLM이 유일한 선택지입니다. AWS 특히, Trainium 지원은 추론 비용을 상당히 절감할 수 있다는 의미이며, SGLang은 이 하드웨어를 건드릴 수 없습니다.
표준 NVIDIA GPU에서 실행하는 팀의 경우, 배포 스토리는 유사합니다. 둘 다 Docker 이미지와 OpenAI 호환 엔드포인트를 제공합니다. vLLM은 단지 더 많은 검증된 프로덕션 가이드와 커뮤니티 기여 Helm 차트를 가지고 있습니다.
로컬에서 LLM을 실행하기 위한 도구를 탐색 중이거나 자체 호스팅 추론에 대한 더 광범위한 보기를 원한다면, 두 엔진 모두 소비자 GPU에서의 로컬 배포를 지원하지만, 데이터센터 하드웨어를 위해 설계되었습니다.
...