vLLM에서 SGLang으로 LLM 추론 마이그레이션: RAG·멀티턴 워크로드에서 처리 속도 6배 차이가 나는 이유

솔직히 말하면, 처음 SGLang을 접했을 때 반응은 "또 새 프레임워크야?"였습니다. vLLM도 충분히 잘 쓰고 있었고, 이미 안정적으로 운영 중인 서빙 스택을 건드리는 건 언제나 부담스러운 일이니까요. 그런데 하루 수만 건의 RAG 요청을 처리하던 파이프라인 성능 병목을 파고들다가 SGLang의 RadixAttention 벤치마크 수치를 봤을 때, "이게 정말이면 지금 우리 스택을 뜯어야 한다"는 생각이 들었거든요.

여기서 미리 짚어드릴 게 있습니다. 제목의 "6배"라는 수치는 같은 문서 컨텍스트를 수천 개의 요청이 공유하는 RAG·멀티턴 구조에서 달성되는 숫자입니다. 매 요청이 완전히 새로운 내용인 단일 턴 워크로드에서는 두 프레임워크가 거의 차이가 없어요. 자신의 서비스가 어느 쪽에 가까운지 파악하는 게 먼저이고, 이 글은 그 판단을 돕기 위해 썼습니다. vLLM 사용 경험이 있거나 LLM 서빙을 운영 중인 개발자라면 코드 예시까지 바로 따라올 수 있도록 구성했습니다.

핵심은 하나입니다 — OpenAI 호환 API 덕분에 서버 엔드포인트 하나만 바꾸면 클라이언트 코드는 손댈 필요가 없습니다. 도입 허들 자체가 낮기 때문에, 지금 RAG나 멀티턴 대화를 서빙하고 있다면 한 번쯤 실험해볼 가치가 충분합니다.

핵심 개념

KV 캐시가 병목이 되는 이유

LLM이 토큰을 생성할 때, 이전에 처리한 토큰들의 어텐션 연산 결과(Key-Value 캐시, 줄여서 KV 캐시)를 GPU 메모리에 쌓아둡니다. 같은 내용을 다시 계산하지 않기 위해서인데, 문제는 이 캐시가 무거워지면 GPU 메모리가 빠르게 찬다는 거예요. RAG 파이프라인이라면 수천 토큰짜리 문서 컨텍스트를 요청마다 들고 오니, 이걸 어떻게 관리하느냐가 서빙 성능을 직접적으로 결정합니다.

vLLM — PagedAttention으로 쌓은 업계 표준

vLLM은 UC Berkeley에서 시작한 프로젝트로, PagedAttention이라는 기술로 GPU KV 캐시를 운영체제의 가상 메모리처럼 페이지 단위로 관리합니다. 덕분에 메모리 단편화를 줄이고 배치 처리 효율을 높였죠. 2023년 등장 이후 빠르게 업계 표준이 됐고, 현재 가장 넓은 모델 지원 범위와 커뮤니티 생태계를 갖추고 있습니다.

PagedAttention: GPU 메모리 상의 KV 캐시를 고정 크기 페이지로 나누어 관리하는 기법. 메모리 낭비 없이 더 많은 요청을 동시에 처리할 수 있게 해줍니다.

SGLang — prefix 재사용을 극단까지 밀어붙이다

SGLang(Structured Generation Language)은 LMSYS 그룹이 만든 프레임워크로, 두 가지 핵심 기술이 차별점을 만들어냅니다.

RadixAttention: KV 캐시를 Radix Tree 자료구조로 관리합니다. 여러 요청이 같은 prefix(시스템 프롬프트, RAG 컨텍스트, 대화 히스토리)를 공유하면 캐시를 자동으로 재사용합니다. RAG 파이프라인에서는 수천 개의 요청이 동일한 문서 컨텍스트를 앞에 붙이는 경우가 많은데, 매번 그걸 다시 계산하는 건 명백한 낭비거든요. vLLM도 캐싱을 하지만, Radix Tree 구조 덕분에 SGLang은 이 공통 prefix를 훨씬 정밀하게 찾아내 재사용합니다.

Radix Tree: 문자열의 공통 접두사를 공유하는 트리 자료구조. SGLang은 이를 토큰 시퀀스의 공통 prefix KV 캐시 공유에 적용합니다.

XGrammar 기반 구조화 출력: JSON/Regex/EBNF 제약 디코딩을 처리할 때, XGrammar는 문법 컴파일 단계에서 일반 방식 대비 80배 빠른 속도를 보입니다. 이 덕분에 실제 JSON 토큰 디코딩 처리량은 표준 방식 대비 약 3배 빠르게 나옵니다. 둘은 각각 컴파일과 디코딩이라는 서로 다른 단계를 측정한 수치이니 혼동하지 않는 것이 좋습니다. 에이전트나 툴 콜 파이프라인에서 JSON 응답을 강제해야 할 때 체감 차이가 크게 납니다.

두 프레임워크 비교

처음 이 표를 봤을 때 눈길이 간 건 TTFT 항목이었습니다. TTFT(Time To First Token)는 요청을 보낸 시점부터 첫 번째 토큰이 응답으로 돌아오기까지 걸리는 시간인데, 23%라는 수치는 절대값으로 보면 작아 보이지만 p95 레이턴시에서는 체감이 꽤 다르더라고요.

PyTorch 공식 통합(2025년 3월): SGLang이 PyTorch 생태계에 공식적으로 포함됐습니다. 단순한 서드파티 프로젝트가 아닌 PyTorch 생태계의 일원으로 인정받았다는 의미로, 장기적인 유지보수와 지속성을 기대할 수 있습니다.

실전 적용

예시 흐름을 미리 말씀드리면, 드롭인 교체로 동작 확인 → Docker로 운영 환경 세팅 → RAG 워크로드 최적화 → 벤치마크로 수치 확인 순서입니다. 자신의 상황에 맞는 예시부터 바로 참고하셔도 됩니다.

예시 1: 드롭인 교체 — 엔드포인트만 바꾸기

가장 먼저 확인하고 싶었던 건 "정말로 코드를 안 바꿔도 되는가"였습니다. 실제로 해보니 서버 실행 명령어만 바꾸면 됩니다. DeepSeek V3처럼 MoE 구조의 대형 모델을 서빙한다면 --model-path deepseek-ai/DeepSeek-V3 --tp 8로 모델만 교체해도 SGLang의 MLA 최적화 커널이 자동으로 적용됩니다.

# vLLM 서버 실행
python -m vllm.entrypoints.openai.api_server \
  --model meta-llama/Llama-3.1-8B-Instruct \
  --tensor-parallel-size 2
 
# SGLang 서버 실행 (동일 모델, 동일 API 포맷)
python -m sglang.launch_server \
  --model-path meta-llama/Llama-3.1-8B-Instruct \
  --tp 2 \
  --host 0.0.0.0 \
  --port 30000

클라이언트 코드는 base_url 하나만 변경하면 됩니다.

from openai import OpenAI
 
# vLLM을 쓰던 코드 — 이 줄만 바꾸면 됩니다
client = OpenAI(
    base_url="http://localhost:8000/v1",
    api_key="EMPTY",
)
 
# SGLang으로 전환 시
client = OpenAI(
    base_url="http://localhost:30000/v1",
    api_key="EMPTY",
)
 
response = client.chat.completions.create(
    model="meta-llama/Llama-3.1-8B-Instruct",
    messages=[{"role": "user", "content": "안녕하세요"}],
)

Tensor Parallelism(TP): 모델의 가중치 행렬을 여러 GPU에 분산해 병렬 처리하는 방식. --tp 4이면 GPU 4장에 모델을 나눠 올립니다. SGLang에서는 멀티 GPU 운영 시 --tp가 가장 안정적인 옵션입니다.

예시 2: Docker로 SGLang 서빙하기

운영 환경에서는 Docker가 훨씬 편합니다. 공식 이미지가 있어서 환경 세팅 없이 바로 올릴 수 있거든요.

docker run --gpus all \
  --shm-size 32g \
  -p 30000:30000 \
  -v ~/.cache/huggingface:/root/.cache/huggingface \
  --env "HF_TOKEN=<your-token>" \
  --ipc=host \
  lmsysorg/sglang:latest-runtime \
  python3 -m sglang.launch_server \
  --model-path meta-llama/Llama-3.1-8B-Instruct \
  --host 0.0.0.0 \
  --port 30000

--shm-size 32g는 멀티 GPU 텐서 병렬 처리 시 공유 메모리가 부족해 발생하는 오류를 예방합니다. 저도 처음엔 이 옵션 빼고 돌렸다가 한참 헤맸습니다. Docker를 쓰지 않는 환경이라면 서버 실행 전에 export HF_TOKEN=<your-token>으로 환경 변수를 먼저 설정해두시면 됩니다.

예시 3: RAG 파이프라인에서 RadixAttention 효과 극대화

RAG 워크로드에서는 같은 문서 컨텍스트를 수천 개의 요청이 공유합니다. 아래 코드에서 SHARED_CONTEXT에 들어가는 수천 토큰짜리 문서가 RadixAttention의 핵심 재사용 대상입니다. 동시 요청이 많아질수록, 그리고 공통 prefix가 길어질수록 vLLM과의 성능 차이가 벌어지는 구조예요.

import asyncio
from openai import AsyncOpenAI
 
client = AsyncOpenAI(
    base_url="http://localhost:30000/v1",
    api_key="EMPTY",
)
 
SHARED_CONTEXT = """
당신은 문서 분석 어시스턴트입니다.
[문서 내용 — 수천 토큰의 RAG 컨텍스트]
"""
 
async def query_with_rag(user_question: str) -> str:
    response = await client.chat.completions.create(
        model="meta-llama/Llama-3.1-8B-Instruct",
        messages=[
            {"role": "system", "content": SHARED_CONTEXT},  # prefix 재사용 대상
            {"role": "user", "content": user_question},
        ],
    )
    return response.choices[0].message.content
 
async def main():
    # 같은 문서에 대해 다양한 관점에서 던지는 질문 — 이 패턴이 RadixAttention 효과를 극대화합니다
    questions = [
        "이 문서의 핵심 주장은 무엇인가요?",
        "저자가 제시한 근거를 요약해주세요.",
        "3번째 단락의 내용을 한 문장으로 정리해주세요.",
        "이 문서에서 언급된 한계점은 무엇인가요?",
        "결론 부분을 쉬운 말로 풀어서 설명해주세요.",
    ]
    results = await asyncio.gather(*[query_with_rag(q) for q in questions])
    return results

예시 4: 서버 워밍업과 벤치마크 측정

SGLang은 초기 몇 번의 요청에서 RadixAttention 캐시를 쌓는 시간이 필요합니다. 서버 기동 직후 바로 성능을 측정하면 실제보다 낮게 나올 수 있어서, 운영 전에 더미 요청을 미리 몇 번 보내두는 것이 좋습니다.

import asyncio
from openai import AsyncOpenAI
 
async def warmup_server(base_url: str, model: str, n: int = 5) -> None:
    client = AsyncOpenAI(base_url=base_url, api_key="EMPTY")
    tasks = [
        client.chat.completions.create(
            model=model,
            messages=[{"role": "user", "content": "ping"}],
            max_tokens=1,
        )
        for _ in range(n)
    ]
    await asyncio.gather(*tasks)
    print(f"워밍업 완료 ({n}회 요청)")
 
# 서버 기동 후 실제 트래픽 전에 실행
asyncio.run(
    warmup_server("http://localhost:30000/v1", "meta-llama/Llama-3.1-8B-Instruct")
)

벤치마크는 SGLang에 내장된 bench_serving 스크립트로 측정할 수 있습니다.

# SGLang 내장 벤치마크
python -m sglang.bench_serving \
  --backend sglang \
  --host localhost \
  --port 30000 \
  --model meta-llama/Llama-3.1-8B-Instruct \
  --num-prompts 200 \
  --request-rate 10
 
# vLLM과 비교 측정 시 — backend와 port만 변경
python -m sglang.bench_serving \
  --backend vllm \
  --host localhost \
  --port 8000 \
  --model meta-llama/Llama-3.1-8B-Instruct \
  --num-prompts 200 \
  --request-rate 10

장단점 분석

장점

MLA(Multi-head Latent Attention): DeepSeek이 도입한 어텐션 변형으로, KV 캐시를 저차원 잠재 벡터로 압축해 메모리를 절감합니다. SGLang은 이 구조에 특화된 커널 최적화를 내장하고 있어, MoE 아키텍처와 결합됐을 때 vLLM보다 메모리 효율과 추론 속도 모두에서 앞섭니다.

단점 및 주의사항

Data Parallelism(DP): 동일한 모델 복사본을 여러 GPU에 올려 요청을 분산 처리하는 방식. SGLang에서는 현재 --dp 사용 시 성능 변동이 크게 나타나 권장하지 않습니다. 멀티 GPU 환경이라면 --tp를 먼저 조정해보시는 것이 좋습니다.

실무에서 가장 흔한 실수

1. 워밍업 없이 첫 응답 레이턴시로 판단하는 것 — SGLang은 초기 몇 번의 요청에서 RadixAttention 캐시를 쌓는 시간이 필요합니다. 첫 요청 하나만 보고 "vLLM이랑 차이 없네"라고 결론 내리면 오판이에요. 예시 4의 워밍업 코드를 먼저 실행해두고 충분한 트래픽이 지나간 이후의 수치를 봐야 합니다.

2. 단일 턴 독립 요청 워크로드에서 6배를 기대하는 것 — 매 요청이 완전히 새로운 내용이라면 RadixAttention의 prefix 재사용이 일어나지 않습니다. 이 경우 두 프레임워크의 성능은 거의 동일합니다. 자신의 워크로드에 prefix 공유가 얼마나 일어나는지 먼저 파악해보시면 좋습니다.

3. --dp 플래그를 --tp 대신 쓰는 것 — 여러 GPU를 활용할 때 Data Parallelism이 더 익숙하게 느껴질 수 있지만, SGLang에서는 현재 --tp가 훨씬 안정적입니다. 멀티 GPU 세팅이라면 --dp 대신 --tp 값부터 조정해보시는 것을 권장합니다.

마치며

SGLang으로의 전환은 "RAG, 멀티턴, 구조화 출력, DeepSeek 계열 모델"이라는 네 가지 키워드 중 하나라도 해당된다면 시도해볼 충분한 이유가 됩니다. OpenAI 호환 API 덕분에 마이그레이션 비용이 낮고, 잘 맞지 않으면 다시 vLLM으로 돌아가는 것도 엔드포인트 하나 바꾸는 수준입니다. 부담 없이 테스트해볼 수 있는 구조라는 게 가장 큰 장점이에요.

지금 바로 시작해볼 수 있는 3단계:

1. SGLang 설치 및 로컬 서버 실행 — pip install sglang[all] 후 python -m sglang.launch_server --model-path <현재 사용 중인 모델> --tp <GPU 수> --host 0.0.0.0 --port 30000으로 서버를 올릴 수 있습니다. Docker를 쓰지 않는 환경이라면 실행 전에 export HF_TOKEN=<your-token>으로 HuggingFace 토큰을 미리 설정해두시면 됩니다. 함정: 멀티 GPU Docker 환경에서 --shm-size 32g 없이 올리면 공유 메모리 오류가 납니다.

2. 기존 클라이언트의 base_url만 SGLang 포트로 변경 — http://localhost:30000/v1으로 바꾸고 기존 테스트가 그대로 통과하는지 확인합니다. 다른 코드는 그대로 둔 채로 동작 여부를 먼저 확인할 수 있습니다. 함정: 워밍업 없이 첫 요청 하나만 보고 성능을 판단하지 않는 것이 중요합니다.

3. 같은 워크로드로 처리 속도와 TTFT 비교 — python -m sglang.bench_serving으로 실제 트래픽 패턴(RAG 컨텍스트 포함 여부, 멀티턴 여부)을 시뮬레이션해보시면 됩니다. 수치가 의미 있게 개선된다면 Docker 배포로 넘어가는 것을 권장합니다. 함정: 70B+ 대형 모델은 격차가 3~5%로 줄어드니, 소형 모델 기준 수치를 그대로 기대하지 않는 것이 좋습니다.

참고 자료

• SGLang 공식 GitHub 저장소
• SGLang 공식 문서
• vLLM vs SGLang 2026: H100 Benchmarks | TECHSY
• vLLM vs TensorRT-LLM vs SGLang: H100 Benchmarks 2026 | Spheron Blog
• When to Choose SGLang Over vLLM: Multi-Turn Conversations and KV Cache Reuse | RunPod
• SGLang in Production: Structured Generation, RadixAttention, and Multi-Step Pipelines | RunPod
• SGLang: The Complete Guide to High-Performance LLM Inference | Inference.net
• OpenAI Compatible API | SGLang 공식 문서
• Mini-SGLang: Efficient Inference Engine in a Nutshell | LMSYS Blog
• SGLang Quantization 공식 문서
• SGLang Speculative Decoding 공식 문서