Skip to content

vLLM vs LMDeploy vs SGLang

대형 언어 모델(LLM)은 자연어 처리 분야에서 중요한 돌파구를 만들어냈지만, 고성능 모델일수록 추론 지연과 자원 소모가 큰 것이 현실이다. 특히 모델을 서비스에 배포할 때는 처리 속도, 메모리 효율, 동시 사용자 대응 능력이 핵심 고려 요소이다. 본 글에서는 이러한 문제를 해결하기 위해 개발된 세 가지 오픈소스 프레임워크인 vLLM, LMDeploy, SGLang을 다양한 관점에서 비교하고, 벤치마크 결과를 기반으로 장단점을 분석하고자 한다.

1. 배경: 추론 병목의 근본 원인

LLM이 사용하는 핵심 알고리즘인 Attention은 이전보다 긴 컨텍스트를 다룰 수 있게 해주지만, 동시에 매우 많은 연산과 메모리 캐싱을 요구한다. 특히 디코딩 단계에서 사용하는 Key-Value(KV) 캐시는 연속적인 요청 처리에서 큰 병목이 되며, 캐시를 효율적으로 관리하지 않으면 응답 속도가 크게 느려진다.

기존 해결 방식으로는 FP16, INT8, 4-bit 양자화 같은 저정밀 연산 또는 고성능 GPU 사용이 있었으나, 이는 근본적인 알고리즘 병목을 해결하지는 못한다. 이에 따라 최근에는 KV 캐시 관리 최적화, GPU 커널 성능 개선, 동적 배치 처리 등의 근본적 접근이 주목받고 있다.

2. 프레임워크 개요

vLLM

  • PagedAttention: OS의 페이징 기법을 차용하여 GPU 메모리의 고정 블록화를 지원하고, KV 캐시 할당을 효율적으로 수행한다.

  • Continuous Batching: 요청을 prefill과 decode 단계로 나누어 동시성 효율을 극대화한다.

  • 지원 범위: Transformer, 멀티모달 LLM, Mixture-of-Experts, 임베딩 모델

  • 지원 하드웨어: NVIDIA GPU, AMD GPU/CPU, Intel, AWS Neuron 등 광범위한 플랫폼을 지원한다.

LMDeploy

  • 엔진 구성: PyTorch와 Turbomind 두 가지 엔진으로 구성되며, 후자는 성능 최적화에 중점을 둔다.

  • 기술 구성: Blocked KV 캐시, 지속적 배치(persistent batch), 고성능 CUDA 커널, 텐서 병렬화, 동적 분할 및 병합 처리

  • 양자화 지원: 4-bit 추론도 지원하며, FP16 대비 최대 2.4배 속도를 제공한다.

  • 특징: 실시간 추론, 분산 환경 배포, 멀티모달 및 다양한 아키텍처 호환

SGLang

  • RadixAttention: Radix 트리를 이용해 멀티턴 대화의 공통 prefix를 공유하여 캐시 재사용률을 높이는 기술이다.

  • Constrained Decoding: 정규식 기반의 출력 제약 조건을 빠르게 처리하는 상태 머신을 제공한다.

  • Batch Scheduler: Python 기반 배치 스케줄러임에도 C++급의 효율성을 보인다.

  • 특징: 구조화된 출력(JSON 등), 멀티턴 대화, Agent 프롬프트 설계 등에서 강력한 성능을 보인다.

3. 벤치마크 환경 및 테스트 조건

  • 테스트 장비:

    • CPU: AMD EPYC 7J13 (64코어)

    • RAM: 216GB

    • GPU: NVIDIA A100 40GB

  • 프레임워크 실행 환경: Docker Compose 기반

  • 테스트 기준:

    • TTFT (Time to First Token): 첫 토큰이 생성되기까지 걸리는 시간 (낮을수록 좋음)

    • Throughput per second: 초당 생성 토큰 수 (높을수록 좋음)

  • 모델 종류:

    • Llama3.1-8B-Instruct

    • Mistral-v0.3-Instruct

    • Qwen2-7B-Instruct

  • 조건:

    • 단일 요청 (concurrent=1)

    • 100개 요청 동시 처리 (concurrent=100)

    • 입력/출력 토큰 수: 각 2048

4. 벤치마크 결과 분석

단일 요청 (Concurrent=1)

TTFT (첫 토큰 생성 속도)

  • SGLang이 세 모델 모두에서 빠른 응답을 보이며 가장 우수하였다.

  • Llama3.1 기준, 가장 느린 lmdeploy-pytorch 대비 22.3% 빠름

  • Qwen2-7B에서도 모든 프레임워크 중 가장 낮은 TTFT를 기록하였다.

Throughput

  • lmdeploy-turbomind가 가장 높은 평균 토큰 생성률(약 88.6 tok/s)을 보였다.

  • vLLM은 가장 낮은 수치를 보였으며, 평균 8.12% 뒤쳐졌다.

  • SGLang은 평균 수준이나 구조화된 출력이 필요한 작업에는 강점을 보인다.

100개 요청 동시 처리 (Concurrent=100)

TTFT

  • SGLang은 Qwen2-7B에서 탁월한 성능(0.052s)을 보였으며, 이는 모든 프레임워크 중 가장 빠른 수치이다.

  • 하지만 Mistral-v0.3에서는 가장 낮은 성능(32.39s)을 기록하며, 해당 아키텍처에 대한 최적화 부족이 드러났다.

Throughput

  • LMDeploy-Turbomind는 Qwen2-7B에서 초당 2380 토큰, SGLang은 2506 토큰으로 가장 높은 수치를 기록하였다.

  • TGI는 Llama 및 Mistral 모델에서 OOM(Out-Of-Memory) 오류로 테스트 실패

5. 종합 결론

항목 vLLM LMDeploy SGLang
TTFT (단일 요청) 평균 수준 느림 가장 빠름
TTFT (동시 요청) 안정적 빠름 모델에 따라 편차 존재
Throughput 낮음 일관되게 높음 특정 모델에서 최고 성능
구조화 출력 지원 미지원 미지원 지원 (JSON 등)
멀티턴 캐시 최적화 미지원 제한적 RadixAttention 지원
시스템 통합 난이도 낮음 중간 높음 (DSL 기반)

6. 추천 가이드

상황 적합한 프레임워크
단일턴 대량 생성, 대규모 배포 LMDeploy
다양한 플랫폼 통합, 빠른 배포 vLLM
멀티턴 챗봇, 구조화 응답이 필요한 시스템 SGLang

SGLang은 멀티턴 처리와 구조화 출력에 강점을 가지며, 싱글턴 위주의 대량 생성 작업에서는 LMDeploy가 우수한 처리량을 보여준다. 반면 vLLM은 손쉬운 통합과 넓은 플랫폼 호환성을 통해 빠른 구축이 필요한 상황에 적합하다. 각 프레임워크의 특성과 시스템 요구사항을 고려하여 선택하는 것이 중요하다.