sglang vs vLLM — 오픈소스 LLM 서빙 프레임워크 실전 비교

오픈소스 LLM을 직접 서빙하려고 하면 이 두 개를 반드시 마주치게 됩니다.

"sglang이랑 vLLM 중에 뭐 써야 하지?"

둘 다 LLM을 HTTP API로 서빙하는 프레임워크인데, 설계 철학과 강점이 달라요. 이번 글에서는 실전 관점에서 두 프레임워크를 비교해 드릴게요.

먼저 둘 다 뭔지부터

vLLM은 2023년 UC Berkeley에서 발표한 LLM 서빙 프레임워크예요. PagedAttention이라는 메모리 관리 기법을 처음 도입해서 GPU 메모리 효율을 획기적으로 높인 프레임워크입니다. OpenAI API와 호환되는 엔드포인트를 제공해서 기존 코드를 거의 수정 없이 연결할 수 있어요.

sglang은 2024년 Stanford에서 발표한 프레임워크예요. RadixAttention이라는 KV 캐시 공유 기법을 도입해서 특정 시나리오에서 vLLM보다 빠른 처리 속도를 냅니다. 특히 system prompt가 길거나 같은 prefix를 반복 사용하는 경우에 강력해요.

핵심 기술 비교

구분 vLLM sglang

핵심 기술	PagedAttention	RadixAttention
KV 캐시 방식	페이지 단위 메모리 관리	Prefix 공유 캐시
API 호환성	OpenAI API 완벽 호환	OpenAI API 호환
Continuous Batching	지원	지원
JSON 출력 강제	지원	지원 (더 빠름)
멀티모달	지원	지원

PagedAttention vs RadixAttention

PagedAttention (vLLM)

GPU 메모리를 고정 크기 페이지로 나눠서 관리하는 방식이에요. KV 캐시를 동적으로 할당하기 때문에 메모리 낭비가 줄어들고, 더 많은 요청을 동시에 처리할 수 있어요. vLLM 이전에는 KV 캐시 메모리를 미리 예약해야 해서 낭비가 심했는데 이걸 해결한 거예요.

RadixAttention (sglang)

여러 요청이 동일한 prefix를 공유할 때 KV 캐시를 재사용하는 방식이에요. 예를 들어 system prompt가 같은 요청이 100개 들어오면, system prompt 부분의 KV 캐시를 한 번만 계산하고 100개가 공유합니다. 멀티 에이전트 시스템처럼 같은 system prompt를 반복 사용하는 환경에서 속도가 확 올라가요.

실전 성능 차이

sglang은 system prompt가 길고 반복적으로 쓰이는 환경, 그러니까 멀티 에이전트나 RAG 구조에서 특히 유리해요. JSON 출력을 강제해야 하는 structured output 작업이나 같은 prefix를 공유하는 배치 처리에서도 sglang이 더 좋은 성능을 보여줘요.

반대로 vLLM은 다양한 요청이 뒤섞이는 범용 서빙 환경에서 안정적이에요. 모델 지원 범위가 넓어야 하거나 안정성과 커뮤니티 레퍼런스가 중요한 프로덕션 환경이라면 vLLM 쪽이 더 안전한 선택이에요.

설치 및 실행

직접 띄워보는 게 가장 빠른 이해 방법이니 설치부터 해볼게요. 둘 다 pip 한 줄로 설치되고 명령어 한 줄로 서버가 뜨는 구조라 진입장벽이 낮아요.

pip install vllm

python -m vllm.entrypoints.openai.api_server \
  --model Qwen/Qwen2.5-7B-Instruct \
  --host 0.0.0.0 \
  --port 8000

vLLM은 이렇게 실행하면 OpenAI 호환 엔드포인트가 8000번 포트에서 바로 떠요. 모델은 Hugging Face 모델 ID를 그대로 넣으면 자동으로 다운로드돼요.

pip install sglang[all]

python -m sglang.launch_server \
  --model-path Qwen/Qwen2.5-7B-Instruct \
  --host 0.0.0.0 \
  --port 8000

sglang도 명령어 구조가 거의 동일해서 vLLM에서 넘어와도 헷갈릴 일이 없어요. 다만 [all] 옵션을 빼고 설치하면 일부 기능이 빠질 수 있으니 처음에는 풀 설치를 권장해요.

둘 다 OpenAI 호환 엔드포인트를 제공하기 때문에 클라이언트 코드는 동일하게 쓸 수 있어요. 아래 코드는 두 프레임워크 어느 쪽에 붙여도 그대로 동작해요.

from openai import OpenAI

client = OpenAI(
    base_url="http://localhost:8000/v1",
    api_key="dummy"
)

response = client.chat.completions.create(
    model="Qwen/Qwen2.5-7B-Instruct",
    messages=[{"role": "user", "content": "안녕하세요"}]
)

base_url만 맞춰주면 기존에 OpenAI API로 짜둔 코드를 거의 그대로 재사용할 수 있어요.

JSON 출력 강제 비교

LLM 에이전트에서 JSON 출력을 강제하는 건 중요한 기능이에요. 둘 다 지원하는데 방식이 달라요.

vLLM은 아래처럼 response_format에 json_object만 지정하면 끝나는 단순한 방식이에요.

response = client.chat.completions.create(
    model="Qwen/Qwen2.5-7B-Instruct",
    messages=[...],
    response_format={"type": "json_object"}
)

이 방식은 키 이름이나 구조까지 강제하지는 못하고, 결과가 JSON 형태이기만 하면 통과돼요.

sglang은 한 단계 더 들어가서 json_schema 자체를 정의할 수 있어요.

response = client.chat.completions.create(
    model="Qwen/Qwen2.5-7B-Instruct",
    messages=[...],
    response_format={
        "type": "json_schema",
        "json_schema": {
            "name": "output",
            "schema": {
                "type": "object",
                "properties": {
                    "result": {"type": "string"},
                    "reasoning": {"type": "string"}
                }
            }
        }
    }
)

sglang은 JSON schema 수준까지 강제할 수 있어서 더 정밀해요. 멀티 에이전트 시스템에서 LLM 출력을 파싱해야 할 때 파싱 실패율이 낮아집니다.

멀티 GPU 설정

대형 모델을 서빙할 때는 Tensor Parallelism으로 여러 GPU에 분산해서 처리해야 해요. 옵션 이름만 다를 뿐 설정 방식은 두 프레임워크 모두 비슷해요.

python -m vllm.entrypoints.openai.api_server \
  --model Qwen/Qwen2.5-72B-Instruct \
  --tensor-parallel-size 4

vLLM은 --tensor-parallel-size로 GPU 개수를 지정하면 모델을 자동으로 쪼개서 로드해요.

python -m sglang.launch_server \
  --model-path Qwen/Qwen2.5-72B-Instruct \
  --tp 4

sglang은 같은 역할을 --tp 옵션으로 줄여서 쓰는데, 동작 방식은 vLLM과 동일하다고 보면 돼요.

어떤 걸 선택해야 하나

멀티 에이전트 시스템을 구축하고 있거나 system prompt가 길고 반복적으로 사용되는 환경이라면 sglang이 유리해요. JSON schema 수준의 출력 강제가 필요한 경우에도 sglang이 더 편합니다.

모델 지원 범위가 넓어야 하거나 커뮤니티 레퍼런스가 중요한 프로덕션 환경이라면 vLLM이 안전해요. 다양한 요청 패턴이 섞이는 범용 서빙 환경에서도 vLLM이 더 안정적입니다.

마무리

둘 다 OpenAI API 호환이라 클라이언트 코드를 바꾸지 않고 프레임워크만 교체할 수 있다는 점이 가장 큰 장점이에요. 처음 LLM 서빙을 시작한다면 레퍼런스가 많고 커뮤니티가 큰 vLLM으로 먼저 익혀보는 게 안전한 선택이에요. 이후 system prompt 재사용이 많은 멀티 에이전트 구조나 RAG 파이프라인으로 확장한다면 그 시점에 sglang으로 전환을 검토하면 돼요. 결국 어느 한쪽이 절대적으로 우월한 게 아니라 워크로드 특성에 맞춰 고르는 문제라서, 지금 운영 중인 서빙 환경의 요청 패턴부터 점검해보는 게 먼저예요.