SGLang vs vLLM 실전 비교 — 처리량 3배 차이의 비밀
중앙값만 보면 vLLM이 나아 보입니다. 20명에서 vLLM이 14% 빠르고, 100명에서는 61% 빠릅니다. 그런데 왜 SGLang을 선택했을까요? 답은 P95(꼬리 지연)에 있습니다. 같은 20명 환경에서 SGLang P95는 13.7초, vLLM P95는 89.8초 — 6.5배 차이. 동일 GPU, 동일 모델, 동일 LoRA 5개 조건에서 200명까지 돌린 실전 비교 결과를 공개합니다.
3.0x
처리량 차이 (20명)
6.5x
P95 차이 (20명)
0건
SGLang 에러
15/15
격리 테스트 (양쪽)
테스트 조건
동일 환경, 엔진만 교체
GPU: RTX PRO 6000 (96GB, 350W 제한)
모델: Qwen3-32B-AWQ + LoRA 5개 (SGLang 서빙 가이드, AWQ 양자화 비교)
테스트: 2~4턴 멀티턴, max_tokens=500
SGLang: v0.5.8.post1
vLLM: v0.15.1
동시 접속: 20 / 50 / 100 / 200명
| 항목 | SGLang | vLLM |
|---|---|---|
| VRAM 사용량 | 87.6GB | 85.7GB |
| 시작 시간 | ~60초 | ~50초 |
| LoRA 등록 | --lora-paths name=path | --lora-modules name=path |
| API 호환 | OpenAI 호환 | OpenAI 호환 |
교체 비용
두 엔진 모두 OpenAI 호환 API를 제공합니다. 클라이언트 코드에서 base_url과 LoRA 파라미터명만 변경하면 즉시 전환 가능합니다. 실제로 5대 프로젝트 서버의 코드 변경 없이 엔진만 교체하여 테스트를 진행했습니다.
중앙값: vLLM이 나은 구간
솔직하게, 중앙값(50% 사용자가 경험하는 응답 시간)만 보면 vLLM이 저~중부하에서 더 빠릅니다. 이 결과만 보고 vLLM을 선택하면 안 되는 이유를 이어서 설명합니다.
| 동시 접속 | SGLang | vLLM | 차이 |
|---|---|---|---|
| 20명 | 11.6초 | 10.0초 | vLLM -14% |
| 50명 | 18.5초 | 11.3초 | vLLM -39% |
| 100명 | 38.0초 | 14.8초 | vLLM -61% |
| 200명 | 71.4초 | 101.3초 | SGLang -29% |
중앙값의 함정
중앙값은 "절반의 사용자"가 경험하는 시간입니다. 나머지 절반은 더 오래 기다립니다. 서비스에서 중요한 건 "가장 오래 기다리는 5%의 사용자"(P95)가 얼마나 기다리는가입니다. 이 5%가 이탈하면 고객 불만으로 직결됩니다.
P95: 결정적 차이
여기서 결판이 납니다. vLLM의 P95는 중앙값의 6~9배까지 치솟습니다. 20명밖에 안 되는 환경에서도 상위 5% 사용자가 90초를 기다립니다.
| 동시 접속 | SGLang P95 | vLLM P95 | 배수 |
|---|---|---|---|
| 20명 | 13.7초 | 89.8초 | 6.5x |
| 50명 | 24.1초 | 137.2초 | 5.7x |
| 100명 | 46.2초 | 167.5초 | 3.6x |
| 200명 | 97.3초 | 118.5초 | 1.2x |
P95 / 중앙값 비율
SGLang: 안정적
20명: P95/중앙값 = 1.2배
50명: P95/중앙값 = 1.3배
100명: P95/중앙값 = 1.2배
200명: P95/중앙값 = 1.4배
모든 사용자가 비슷한 시간을 경험합니다.
vLLM: 불안정
20명: P95/중앙값 = 9.0배
50명: P95/중앙값 = 12.1배
100명: P95/중앙값 = 11.3배
200명: P95/중앙값 = 1.2배
일부 사용자가 극단적으로 오래 기다립니다.
실 서비스 관점
동시 20명 환경을 가정합니다. SGLang에서는 모든 사용자가 11~14초 안에 응답을 받습니다. vLLM에서는 절반은 10초 안에 받지만, 상위 5%는 90초를 기다립니다. 이 5%의 사용자가 고객 지원팀에 "챗봇이 안 돼요"라고 문의하게 됩니다.
처리량: 1.5~3배
단위 시간당 처리할 수 있는 토큰 수에서도 SGLang이 전 구간 우위입니다. RadixAttention 기반의 효율적인 배칭이 처리량 차이의 핵심 원인입니다.
| 동시 접속 | SGLang | vLLM | 배수 |
|---|---|---|---|
| 20명 | 565 tok/s | 187 tok/s | 3.0x |
| 50명 | 905 tok/s | 350 tok/s | 2.6x |
| 100명 | 1,059 tok/s | 547 tok/s | 1.9x |
| 200명 | 1,093 tok/s | 708 tok/s | 1.5x |
왜 차이가 나는가
SGLang의 RadixAttention은 KV 캐시를 프리픽스 트리 구조로 관리하여, 동일 시스템 프롬프트를 공유하는 요청들의 캐시를 재사용합니다. LoRA 멀티테넌트 환경에서 5개 회사가 각기 다른 시스템 프롬프트를 사용해도, 공통 접두사 부분의 캐시를 효율적으로 공유합니다. 이 메커니즘이 처리량 차이의 주요 원인입니다.
안정성과 격리
에러율
| 동시 접속 | SGLang | vLLM |
|---|---|---|
| 20명 | 0건 | 0건 |
| 50명 | 0건 | 0건 |
| 100명 | 0건 | 16건 |
| 200명 | 0건 | 0건 |
vLLM은 100명에서 16건의 타임아웃 에러가 발생했습니다. P95 꼬리 지연이 극단적으로 길어지면서 일부 요청이 타임아웃에 걸린 것으로 추정됩니다.
멀티테넌트 격리
| 항목 | SGLang | vLLM |
|---|---|---|
| KV 캐시 누출 | 0건 | 0건 |
| LoRA 격리 | 5/5 | 5/5 |
| 동시 페르소나 | 5/5 | 5/5 |
| 빠른 전환 반복 | 10/10 | 10/10 |
| 종합 | 15/15 PASS | 15/15 PASS |
격리 기능은 양쪽 완벽하게 동일합니다. A회사의 질문이 B회사로 새어나가는 일은 어느 쪽에서도 발생하지 않았습니다.
API 호환성 상세
| 기능 | SGLang | vLLM |
|---|---|---|
| /v1/chat/completions | ✅ | ✅ |
| /v1/models | ✅ | ✅ |
| /health | ✅ | ✅ |
| Prometheus 메트릭 | --enable-metrics 필요 | 기본 활성 |
결론: 왜 SGLang인가
| 항목 | 승자 | 이유 |
|---|---|---|
| 처리량 | SGLang | 전 구간 1.5~3배 우위 |
| P95 안정성 | SGLang | 중앙값의 1.2~1.4배 vs vLLM의 9~12배 |
| 에러율 | SGLang | 전 구간 0% vs vLLM 100명에서 16건 |
| 중앙값 응답 | 비슷~vLLM | 저부하에서 vLLM이 14~61% 빠름 |
| 격리 | 동일 | 양쪽 15/15 PASS |
| API 호환 | 동일 | OpenAI 호환, 즉시 전환 가능 |
| 모니터링 | vLLM | Prometheus 기본 활성 |
그래도 vLLM을 선택해야 할 때
1. 저부하 단독 운영 (5~10명): P95 문제가 드러나지 않는 규모에서는 vLLM의 중앙값 이점을 활용할 수 있습니다.
2. Prometheus 모니터링이 핵심일 때: vLLM은 별도 설정 없이 Prometheus 메트릭을 제공합니다. SGLang은 --enable-metrics 플래그가 필요합니다.
3. 커뮤니티 생태계: vLLM은 더 큰 커뮤니티와 서드파티 도구 지원을 가지고 있습니다.
실 서비스에서는 P95가 중앙값보다 중요하다
중앙값이 빠르더라도 5%의 사용자가 90초를 기다린다면, 그 서비스는 "느린 서비스"입니다. SGLang은 처리량 1.5~3배, P95 안정성 6.5배, 에러 0%로 실 서비스 환경에서 압도적인 우위를 보여줍니다.
교체 비용이 거의 없으니(base_url만 변경), 두 엔진 모두 테스트해보고 워크로드에 맞는 쪽을 선택하세요.
댓글
(4개)로그인하면 댓글을 작성할 수 있습니다.
중앙값만 보면 vLLM이 나아 보이는데 P95에서 뒤집히는 게 핵심이군요. 실 서비스에서 '가끔 90초 대기'가 얼마나 치명적인지 경험해봐서 공감합니다.
동일 모델+LoRA 조건에서 비교한 자료는 처음 봅니다. 격리 테스트 15/15 양쪽 동일이라는 것도 중요한 정보네요.
vLLM 100명에서 에러 16건이 결정적이네요. 처리량 3배에 에러 0%면 SGLang 선택은 당연해 보입니다.
관련 글
© 2026 TreeRU. All rights reserved.
본 콘텐츠의 저작권은 TreeRU에 있으며, 출처를 밝히지 않은 무단 전재 및 재배포를 금합니다. 인용 시 출처(treeru.com)를 반드시 명시해 주세요.