vLLM은 64K 토큰 프롬프트에서 SGLang을 앞서지만, 8-GPU B300 서버에서 컨텍스트가 200K에 도달하면 SGLang이 앞서나갑니다. 이러한 변화는 토큰 윈도우가 확장됨에 따라 prefill 작업이 아닌 디코드(decode) 단계의 병목 현상이 성능을 결정한다는 것을 보여줍니다.
이 벤치마크가 중요한 이유
긴 컨텍스트 추론은 채팅 어시스턴트, 코드 어시스턴트, 그리고 수십만 개의 토큰을 메모리에 유지해야 하는 모든 애플리케이션의 비용을 결정합니다. 대규모 파라미터 모델인 Kimi-K3는 이러한 윈도우를 원활하게 처리할 수 있는 최초의 오픈 웨이트(open-weight) LLM 중 하나이지만, 이를 실행하는 엔진에 따라 요청이 몇 초 만에 끝날지 아니면 몇 분이 걸릴지가 결정됩니다.
vLLM과 SGLang 모두 높은 처리량(high-throughput)의 추론을 약속하지만, 디코드 단계에 대해서는 서로 상반된 접근 방식을 취합니다. vLLM은 Decode Context Parallelism(DCP)이 도입하는 추가적인 동기화를 피하여 디코드 경로를 단순하게 유지합니다. 반면 SGLang은 DCP를 사용하여 키-값(KV) 캐시 읽기를 여러 GPU에 분산시키는데, 이는 추가적인 통신 비용을 감수하는 대신 메모리 대역폭을 분산(amortize)시키는 기술입니다.
테스트 환경
- 하드웨어: 동일한 메모리를 가진 8개의 NVIDIA B300 GPU가 장착된 단일 서버.
- 워크로드: 두 가지 컨텍스트 길이 설정 – 64K 토큰("긴 컨텍스트"의 하한선) 및 200K 토큰(많은 연구 데모가 목표로 하는 상한선).
- 지표: 고정된 프롬프트 배치를 처리하는 데 걸리는 총 시간; 처리량(throughput)은 시간 차이로부터 도출됩니다.
배치 크기, 모델 가중치 및 메모리 사용률 목표는 일정하게 유지했습니다. 실행 간에 변경한 유일한 변수는 추론 엔진뿐이었습니다.
수치 결과
| 컨텍스트 | 엔진 | 시간 (s) | 상대 속도 |
|---|---|---|---|
| 64K | vLLM | 100.5 | – |
| SGLang | 150.8 | vLLM ≈ 1.5배 빠름 | |
| 200K | vLLM | 295.2 | – |
| SGLang | 225.3 | SGLang ≈ 1.31배 빠름 |
컨텍스트가 커짐에 따라 vLLM의 처리량(초당 토큰 수)은 급격히 감소했습니다. 64K에서 200K로 증가할 때 3.29배나 떨어졌습니다. 반면 SGLang의 처리량은 동일한 범위에서 1.25배만 감소했습니다.
격차가 발생하는 이유
두 엔진 모두 프롬프트를 KV 캐시에 로드하는 prefill 단계에서는 비슷한 시간을 소비합니다. 차이는 모델이 토큰을 하나씩 생성하는 디코드 단계에서 나타납니다.
- 64K 토큰: GPU 간 통신이 지배적입니다. vLLM의 단일 GPU 디코드 경로는 DCP에 필요한 추가 동기화를 우회하여 약 1.5배 더 빠르게 작업을 완료합니다.
- 200K 토큰: KV 캐시가 매우 커져서 이를 읽는 작업이 병목 현상이 됩니다. 크기가 8로 설정된 SGLang의 DCP는 이러한 읽기 작업을 8개의 GPU 전체에 분산시킵니다. 대역폭 이득이 통신 비용보다 크기 때문에 SGLang이 확실한 우위를 점합니다.
부차적이고 실무적인 관찰 사항은 메모리 압박에 관한 것입니다. 두 엔진 중 어느 것이든 메모리 사용률 목표를 0.95로 설정하면 B300에서 메모리 부족(OOM) 재시도가 발생했습니다. 목표를 0.92로 낮추면 재시도가 사라지고 실행 시간이 안정화되었지만, 지연 시간(latency)이 약간 증가하는 대가를 치러야 했습니다.
누가 이기고 누가 지는가
- 단기 또는 중기 컨텍스트(≤ 64K 토큰)를 사용하는 개발자는 vLLM의 가벼운 디코드 경로를 통해 더 많은 이득을 얻습니다. 빠른 처리 속도는 클라우드 컴퓨팅 비용 절감과 더 긴밀한 사용자 경험 루프로 이어집니다.
- 심층 분석 또는 연구 도구를 구축하며 수십만 개의 토큰을 컨텍스트에 유지해야 하는 팀은 DCP가 활성화된 SGLang을 사용하는 것이 좋습니다. SGLang의 안정적인 처리량은 타임아웃 위험을 줄이고 메모리 요구 사항이 증가함에 따라 GPU 사용률을 더 높게 유지합니다.
- 하드웨어 설계자는 단순히 GPU 개수만으로는 선형적인 확장을 보장할 수 없음을 알 수 있습니다. KV 대역폭이 병목 지점이 될 때, DCP나 향후 메모리 서브시스템 업그레이드를 통해 캐시 읽기를 병렬화할 수 있는 아키텍처가 동일한 실리콘에서 더 많은 가치를 추출할 수 있을 것입니다.
반론: vLLM이 격차를 줄일 수 있을까?
새로운 데이터가 나타나기 전까지는 현재의 수치가 가장 신뢰할 수 있는 공개 비교 자료입니다.
향후 주목할 점
- 더 큰 컨텍스트 윈도우는 KV 대역폭에 더 큰 부담을 주어 SGLang의 격차를 더 벌릴 가능성이 있습니다.
결론
B300 기반 클러스터에서 긴 컨텍스트 요청을 처리해야 하는 경우, 사용 중인 토큰 윈도우에 맞는 엔진을 선택하십시오. 64K 토큰 워크로드의 경우 vLLM이 약 1.5배 빠른 추론을 제공합니다. 200K 토큰을 넘어서면 SGLang의 DCP 기반 디코드가 더 효율적인 선택이 됩니다. SGLang의 처리량은 1.25배 감소하는 반면 vLLM은 3.29배 감소하기 때문입니다. OOM 재시도를 피하려면 메모리 사용률을 0.92로 조정하십시오. 그리고 "최고의" 엔진은 컨텍스트에 따라 달라지며, 모든 상황에 적용되는 만능 솔루션은 아니라는 점을 기억하십시오.