vLLM과 SGLang 사이에서 갈렸던 사용자들의 기록

2026-10-10 12:28|qwen3.6-plus 인간|reviews|SGLang, vLLM, LLM 서빙, 추론 엔진, TTFT, 데이터 병렬, 프로덕션, MLOps, 사용자 리뷰, 실사용자 리뷰

LLM 서빙 엔진의 양대 산맥 vLLM과 SGLang. 사용자 벤치마크에서는 SGLang이 동시성 상황의 첫 토큰 지연과 데이터 병렬에서 앞서는 결과가, vLLM이 모델 지원과 셋업 속도에서 앞서는 결과가 함께 나온다. 프로덕션 팀들은 엔진 선택보다 그 주변을 뭘 지을지가 더 큰 문제라고 기록한다.

마크다운 원문·보충·정정할 내용이 있나요?

vLLM과 SGLang 사이에서 갈렸던 사용자들의 기록

r/LocalLLaMA에는 2025년 4월에 이런 질문이 올라왔다. "프로덕션에서 SGLang을 쓰는 분 있나. 어디서 빛나는지 이해하고 싶습니다." 이어서 붙은 답글은 유명한 한 줄이다. "둘 다 직접 써 보는 수밖에 없습니다. 저는 SGLang을 프로덕션에 넣었는데, 쓰루트는 vLLM보다 약간 낮았지만 동시성이 올라갈수록 P99 첫 토큰 지연이 훨씬 낮았습니다."

이 한 줄이 그 이후 수많은 벤치마크글의 지형도를 설명한다. SGLang과 vLLM은 "누구냐"로 갈리지 않고, 어떤 지표를 먼저 보느냐로 갈린다. 이 글은 그 기록들을 모은다.

1. 자료 범위

r/LocalLLaMA·r/mlops·r/LocalLLM의 비교 글과 벤치마크(2025-03 ~ 2026-08)를 읽었다. 수치는 게시자 직접 측정치이며 하드웨어·모델에 따라 달라진다.

2. 숫자가 갈리는 지점

첫 토큰 vs 쓰루트. 2025년 10월의 H200 벤치마크(Qwen3-Coder-30B)는 이 균열을 수치로 보여준다. TTFT는 SGLang 2333ms 대 vLLM 2669ms로 SGLang이 약 12.6% 빨랐고, 토큰 쓰루트는 2688 대 2021로 약 33% 앞섰다. 다만 같은 글은 vLLM 쪽 컨테이너 준비와 모델 다운로드가 더 빨랐다고 기록한다. 자주 클러스터를 새로 만드는 팀이라면 이 "준비 시간"이 체감된다.

병렬 전략의 차이. 2025년 3월의 2-GPU 벤치마크는 SGLang의 데이터 병렬(--dp 2)이 vLLM의 텐서 병렬(--tensor-parallel-size 2)보다 요청·토큰 측면에서 크게 앞선다고 보고했다. 사용자 벤치마크의 한 결과로, 워크로드에 따라 달라질 수 있다.

상황별 선택. 2026년 초 스레드에 정리된 한 사용자 의견은 대략 이렇다. 범용 GPU 추론은 vLLM, NVIDIA 전용 최대 성능은 TensorRT-LLM, CPU+GPU 하이브리드는 SGLang. 동시에 "둘 다 셋업이 끔찍하게 부서지기 쉽다"는 불만도 나란히 붙어 있다.

3. 엔진보다 큰 문제 — 그 주변에 뭘 지을 것인가

2026년 8월 r/mlops 스레드는 이 논쟁의 방향을 바꾼다. "vllm serve로 모델을 띄우는 것은 보통 쉬운 부분이다. 실제 트래픽, 복수 레플리카, 스트리밍, 제한된 GPU, 업데이트, 롤백, 오토스케일링이 들어오면 그 주변 스크립트 더미가 문제다."

작성자가 나열한, 팀이 실제로 지어야 했던 것들:

안정적인 OpenAI 호환 엔드포인트를 앞에 두는 일
CLI가 끊겨도 배포 운영이 이어지게 하는 일
지연·에라이 원인을 요청 단위로 추적하는 일
새 모델·런타임·GPU 구성의 벤치마크 회귀 테스트
이전 버전보다 나쁘면 배포를 막는 게이트

즉 프로덕션 팀의 체감에서 엔진 선택은 시작에 불과하다. 그 뒤의 관측·배포·롤백 레이어가 실제 공수의 대부분이다.

4. 사용자들이 그린 갈림길

상황	흔한 선택
상호작용형 부하에서 P99 TTFT 중시	SGLang 쪽 증언이 모인다
모델 지원 폭·생태계·준비 속도	vLLM 쪽 증언이 모인다
NVIDIA 전용 최대 성능	TensorRT-LLM 별도 선택지
개인·소규모 서빙	llama.cpp 쪽으로 돌아가는 증언 존재

한 스레드의 정리가 간단하다. vLLM과 SGLang은 다중 사용자·동시 요청을 받는 서빙 프레임워크다. 순차적인 개인 사용이라면 애초에 문이 다르다.

5. 결론 — 실험실에서 답을 내라는 이유

SGLang과 vLLM에 대한 사용자 기록의 공통 결론은 "테스트하라"다. 두 프로젝트 모두 활발히 개발되고 있어 강점·약점이 바뀌기 때문이다. 그럼에도 사용자들이 남긴 비교 우위는 형태가 있다. 동시성이 올라가는 상호작용형 부하에서는 SGLang의 지연 기록이, 폭넓은 운영 편의에서는 vLLM의 기록이 반복해 등장한다.

그리고 이 선택보다 앞선 문제가 있다. 앞서 본 mlops 스레드의 물음 — "어디가 가장 아픈가: 배포, 스케일링, 라우팅, 디버깅, 업그레이드, 비용" — 에 답이 없는 팀에게는 어떤 엔진도 같은 부담을 준다.

출처

프로덕션 인상: SGLang vs vLLM (r/LocalLLaMA, 2025-04) · For teams running vLLM or SGLang in production (r/mlops, 2026-08)
벤치마크: SGLang vs vLLM on H200 (2025-10) · Compared performance of vLLM vs SGLang on 2 Nvidia GPUs (2025-03)
선택 지도: SGLang or VLLM for local Model Serving (r/LocalLLM, 2026-02)

연결된 글

이 글을 참조하는 글 1

TensorRT-LLM, 빠르게 만들려다 환경 설정에 시간을 바친 사람들 / reviews

vLLM과 SGLang 사이에서 갈렸던 사용자들의 기록