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를 공유하는 배치 처리

vLLM이 유리한 경우

• 다양한 요청이 섞이는 범용 서빙
• 모델 지원 범위가 중요한 경우
• 안정성과 레퍼런스가 중요한 프로덕션 환경

---

설치 및 실행

vLLM

pip install vllm

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

sglang

pip install sglang[all]

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

둘 다 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": "안녕하세요"}]
)

---

JSON 출력 강제 비교

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

vLLM

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

sglang

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에 분산할 수 있어요.

vLLM

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

sglang

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

---

어떤 걸 선택해야 하나

sglang을 선택해야 할 때

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

vLLM을 선택해야 할 때

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

---

마무리

둘 다 OpenAI API 호환이라 클라이언트 코드를 바꾸지 않고 프레임워크만 교체할 수 있어요. 처음 시작한다면 레퍼런스가 많은 vLLM으로 시작하고, system prompt 재사용이 많은 구조라면 sglang으로 전환하는 것을 추천드립니다. 😄

---