Skip to content
Published on

vLLM을 넘어선 새로운 왕좌: SGLang이 LLM 인퍼런스의 판도를 바꾸는 5가지 이유

Authors
  • Name
    Twitter

1. 서론: LLM 인퍼런스의 '건망증'을 치료하다

1.1 반복되는 연산, 낭비되는 GPU

2024년 하반기, LLM 기반 에이전트와 RAG 파이프라인이 프로덕션 환경에 본격적으로 투입되면서 한 가지 불편한 진실이 수면 위로 올라왔다. 바로 LLM 인퍼런스의 '건망증' 문제다.

사용자가 동일한 시스템 프롬프트와 Few-shot 예제를 반복 전송할 때마다, 서빙 엔진은 이미 한 번 계산한 KV 캐시를 버리고 처음부터 다시 연산한다. 멀티턴 대화에서 이전 턴의 컨텍스트를 재활용하지 못하고, RAG 파이프라인에서 공통 문서 청크의 인코딩을 매번 새로 수행한다. H100 GPU의 시간당 비용이 $3~4에 달하는 시대에, 이러한 중복 연산은 곧 비용의 직접적인 낭비다.

기존의 인퍼런스 엔진들은 이 문제를 부분적으로만 해결했다. vLLM의 PagedAttention은 KV 캐시의 메모리 관리 효율성을 혁명적으로 개선했지만, 요청 간 캐시 재사용이라는 더 큰 문제를 근본적으로 풀지 못했다. TensorRT-LLM은 NVIDIA 하드웨어에서 극한의 커널 최적화를 제공하지만, 유연한 프롬프트 프로그래밍과의 통합에서 한계를 보였다.

1.2 SGLang: DSL + Runtime Co-Design

이 지점에서 **SGLang(Structured Generation Language)**이 등장한다. UC Berkeley의 LMSYS 팀이 주도하여 개발한 SGLang은 단순한 인퍼런스 엔진이 아니다. **프론트엔드 언어(DSL)와 백엔드 런타임을 공동 설계(co-design)**하여, 복잡한 LLM 프로그램을 최적으로 실행하는 통합 시스템이다.

"SGLang is a system for efficient execution of complex language model programs. It consists of a frontend language and a runtime. The frontend simplifies programming with primitives for generation and parallelism control. The runtime accelerates execution with novel optimizations." — Zheng et al., NeurIPS 2024

SGLang의 핵심 설계 철학을 한 마디로 요약하면 **'LLM 인퍼런스 운영체제'**다. 운영체제가 프로세스 스케줄링, 메모리 관리, I/O 최적화를 통합하듯, SGLang은 KV 캐시 관리(RadixAttention), CPU-GPU 파이프라이닝(Zero-Overhead Scheduler), 분산 실행(PD Disaggregation), 구조화된 출력(Compressed FSM)을 하나의 일관된 아키텍처로 통합한다.

1.3 숫자로 말하는 SGLang

논문에서 보고된 벤치마크 결과는 인상적이다.

지표SGLang 성능
에이전트 태스크vLLM 대비 최대 6.4x 처리량
H100 토큰 처리량16,215 tok/s (vLLM: 12,553)
멀티턴 캐시 히트율85-95% (vLLM: 15-25%)
JSON 구조화 디코딩최대 3x 속도 향상
PD Disaggregation노드당 52.3K input tok/s

이 글에서는 SGLang이 LLM 인퍼런스의 판도를 바꾸는 5가지 핵심 이유를 기술적으로 심층 분석한다. 각 이유가 단순한 기능 추가가 아니라, 인퍼런스 파이프라인 전체를 재설계하는 아키텍처적 혁신임을 밝힌다.


2. [이유 1] RadixAttention: KV 캐시의 패러다임 전환

2.1 PagedAttention의 한계

vLLM이 도입한 PagedAttention은 KV 캐시 관리에 운영체제의 가상 메모리 개념을 적용하여, 메모리 단편화(fragmentation) 문제를 획기적으로 해결했다. 고정 크기 블록 단위로 KV 캐시를 관리하여 Internal/External Fragmentation을 최소화한 것이다.

그러나 PagedAttention에는 근본적인 한계가 있다. 요청 간(inter-request) KV 캐시 공유가 어렵다는 점이다.

[요청 A] System Prompt(500 tokens) + User Query A(50 tokens)
[요청 B] System Prompt(500 tokens) + User Query B(80 tokens)
[요청 C] System Prompt(500 tokens) + User Query C(30 tokens)

세 요청 모두 동일한 500 토큰의 시스템 프롬프트를 공유하지만, vLLM의 기본 PagedAttention은 각 요청마다 시스템 프롬프트의 KV 캐시를 독립적으로 계산하고 저장한다. 이는 GPU 연산과 메모리 모두에서 막대한 낭비를 초래한다. vLLM도 Automatic Prefix Caching을 도입했지만, 이는 정확한 프롬프트 일치에 의존하며, 부분적 접두사 공유에는 한계가 있다.

2.2 Radix Tree: 데이터 구조의 혁신

SGLang의 RadixAttention은 이 문제를 근본적으로 다른 접근법으로 해결한다. 핵심은 Radix Tree(기수 트리) 데이터 구조를 KV 캐시 관리에 도입한 것이다.

Radix Tree(Patricia Trie라고도 불림)는 문자열의 공통 접두사를 압축하여 저장하는 트리 구조다. 네트워크 라우팅 테이블(IP Prefix Matching)이나 문자열 사전에서 널리 사용되는 자료구조를 KV 캐시 관리에 적용한 것이 SGLang의 핵심 통찰이다.

RadixAttention KV Cache Tree 구조
=================================

                          [ROOT]
                            |
                +-----------+-----------+
                |                       |
        [System Prompt]           [Few-shot Prefix]
        "You are a helpful       "Translate the following
         AI assistant..."         examples..."
         (KV: 500 tokens)         (KV: 800 tokens)
                |                       |
        +-------+-------+        +-----+-----+
        |               |        |           |
   [User A]        [User B]  [Example 1]  [Example 2]
   "What is       "Explain   "Hello->     "Good->
    Docker?"      K8s pods"   안녕하세요"    좋은"
   (KV: 50 tok)  (KV: 80 tok) (KV: 30 tok) (KV: 25 tok)
        |               |
   [Turn 2-A]     [Turn 2-B]
   "How to       "What about
    install?"     services?"
   (KV: 40 tok)  (KV: 60 tok)
        |
   [Turn 3-A]
   "Configure
    networking"
   (KV: 45 tok)

위 다이어그램에서 볼 수 있듯이, Radix Tree의 각 노드는 토큰 시퀀스와 그에 대응하는 KV 캐시 페이지를 저장한다. 새로운 요청이 도착하면, 런타임은 트리를 순회하며 **가장 긴 공통 접두사(Longest Common Prefix)**를 자동으로 감지한다. 매칭된 접두사의 KV 캐시는 재사용되고, 매칭되지 않는 나머지 부분만 새로 계산된다.

2.3 RadixAttention의 동작 원리

RadixAttention의 핵심 동작 흐름을 상세히 살펴보자.

1단계: Prefix Matching (접두사 매칭)

새 요청: "You are a helpful AI assistant... What is Kubernetes?"

Radix Tree 탐색:
  [ROOT][System Prompt] ✅ 매칭! (500 tokens 재사용)
[User A: "What is Docker?"] ❌ 불일치
[User B: "Explain K8s pods"] ❌ 불일치
                 → 새 분기 생성 필요

결과: 500 tokens의 KV 캐시 재사용, 나머지 50 tokens만 새로 계산

2단계: Cache Insertion (캐시 삽입)

새로 계산된 KV 캐시는 트리의 적절한 위치에 삽입된다. 기존 노드와의 공통 접두사가 있으면 노드를 분할(split)하고, 없으면 새 자식 노드를 추가한다.

3단계: LRU Eviction + Tree Pruning (캐시 퇴거)

GPU 메모리가 부족해지면, LRU(Least Recently Used) 정책트리 구조를 결합한 지능적 퇴거가 수행된다.

LRU Eviction 과정:
=================
메모리 부족 발생!

1. 리프 노드 중 가장 오래 접근되지 않은 노드 선택
[Turn 3-A] (마지막 접근: 30분 전)

2. 해당 노드의 KV 캐시 해제 (45 tokens 회수)

3. 부모 노드 검사: [Turn 2-A]의 다른 자식이 있는가?
   → 없음: 부모도 퇴거 후보로 승격
   → 있음: 부모 유지

4. 메모리 충분? → 아니면 다음 LRU 리프 노드로 반복

이 메커니즘의 핵심은 리프 노드부터 퇴거한다는 점이다. 트리의 상위 노드(시스템 프롬프트 등)는 더 많은 요청에 의해 공유되므로 자연스럽게 보존되고, 하위의 개별 사용자 턴이 먼저 퇴거된다. 이는 캐시 재사용 가치가 높은 노드를 자동으로 우선 보존하는 효과를 낳는다.

2.4 에이전트 워크플로우에서의 위력

RadixAttention의 위력은 최근 급부상하는 에이전트 워크플로우에서 극적으로 나타난다. 에이전트는 도구 호출, 관찰, 추론을 반복하며, 매 단계마다 이전 대화 이력 전체를 컨텍스트로 전송한다.

에이전트 실행 흐름 (10단계 추론):
================================
[Step 1] System + Tools + Query1000 tokens (새로 계산)
[Step 2] System + Tools + Query + Obs11000 재사용 + 200 새로 계산
[Step 3] System + Tools + Query + Obs1 + Obs21200 재사용 + 200 새로 계산
...
[Step 10] System + Tools + Query + Obs1~Obs92800 재사용 + 200 새로 계산

RadixAttention: 총 새 연산 = 1000 + 200*9 = 2,800 tokens
PagedAttention: 총 새 연산 = 1000 + 1200 + 1400 + ... + 2800 = 19,000 tokens

절감률:85%

Zheng et al.의 논문에 따르면, 이러한 에이전트 시나리오에서 SGLang은 vLLM 대비 최대 5x의 처리량 향상을 달성한다. 특히 Few-shot Learning 벤치마크에서 SGLang의 캐시 히트율은 85-95%에 달하는 반면, vLLM은 15-25%에 머문다.

2.5 Cache-Aware Load Balancer

SGLang v0.4에서 도입된 Cache-Aware Load Balancer는 RadixAttention의 효과를 멀티 인스턴스 환경으로 확장한다. 여러 SGLang 서버 인스턴스가 존재할 때, 로드 밸런서는 단순한 라운드 로빈 대신 각 인스턴스의 Radix Tree 상태를 고려하여 요청을 라우팅한다.

Cache-Aware Load Balancing:

요청: "System Prompt A + User Query X"

Instance 1: Radix Tree에 "System Prompt A" 캐시 존재 ← 여기로 라우팅!
Instance 2: Radix Tree에 "System Prompt B" 캐시 존재
Instance 3: Radix Tree에 "System Prompt A" 캐시 없음

결과: 캐시 히트율 최대화 → 1.9x 처리량 향상, 3.8x 캐시 히트율 향상

이 기능으로 SGLang은 클러스터 레벨에서도 KV 캐시 재사용을 극대화할 수 있다.


3. [이유 2] 29%의 격차: 하이퍼 스페셜라이즈드 설계

3.1 동일한 커널, 다른 성능

LLM 인퍼런스 엔진의 성능을 비교할 때 자주 간과되는 사실이 있다. SGLang과 vLLM은 실제 GPU 연산에서 동일한 FlashInfer 커널을 사용한다는 점이다. FlashInfer는 FlashAttention의 인퍼런스 특화 변형으로, Attention 연산의 GPU 커널 자체는 동일하다.

그런데 H100 GPU에서의 벤치마크 결과는 놀라운 격차를 보인다.

엔진처리량 (tok/s)상대 성능
SGLang16,215100%
LMDeploy16,13299.5%
vLLM12,55377.4%

동일한 GPU 커널을 사용하는데 29%의 처리량 격차가 발생한다. 이 격차는 어디서 오는가?

3.2 아키텍처 철학의 차이

답은 아키텍처 설계 철학의 근본적 차이에 있다.

vLLM: 유연한 플러그인 아키텍처

vLLM은 다양한 하드웨어(NVIDIA, AMD, Intel, TPU)와 다양한 모델 아키텍처를 지원하기 위해 플러그인 기반의 추상화 레이어를 두텁게 설계했다. Attention Backend, Executor, Worker 등을 교체 가능한 모듈로 설계하여 확장성을 극대화했다.

vLLM Architecture (Simplified):
================================
[Request][Scheduler][Executor Interface]
                    [Backend Abstraction Layer]
                    [Attention Backend Plugin]
                    [FlashInfer / FlashAttention / ...]
                          [GPU Kernel]

이 설계의 장점은 명확하다. 새로운 하드웨어 지원 추가, 새로운 Attention 알고리즘 통합, 커뮤니티 기여 수용이 용이하다. 그러나 이 추상화 레이어들은 간접 호출(indirection), 메모리 복사, 타입 변환 등의 오버헤드를 수반한다. 각 레이어의 오버헤드는 미미하지만, Autoregressive Decoding에서 수천~수만 번 반복되면 누적된다.

SGLang: 하이퍼 스페셜라이즈드 통합

SGLang은 반대의 접근을 택했다. 지원 범위를 좁히는 대신, 지원하는 경로의 성능을 극한까지 최적화하는 전략이다.

SGLang Architecture (Simplified):
=================================
[Request][Zero-Overhead Scheduler]
            [Direct FlashInfer Integration]
            [TMA-Optimized GPU Kernel]
                [GPU HBM]

SGLang은 FlashInfer 커널을 직접 통합(direct integration)하며, 중간 추상화 레이어를 최소화한다. 특히 NVIDIA Hopper 아키텍처의 **TMA(Tensor Memory Accelerator)**를 활용한 최적화된 메모리 접근 패턴을 커널 레벨에서 직접 구현한다.

3.3 마이크로 벤치마크 분석

29%의 격차를 분해하면 다음과 같은 구성 요소로 나뉜다.

오버헤드 원인예상 기여도설명
스케줄러 오버헤드~10%vLLM의 복잡한 스케줄링 로직 vs SGLang의 zero-overhead 스케줄러
메모리 관리 오버헤드~8%블록 테이블 관리, 메타데이터 동기화
추상화 레이어 비용~6%Backend dispatch, 타입 변환
캐시 관리 효율~5%RadixAttention의 트리 기반 접근 vs 해시 기반 접근

각 항목은 개별적으로는 크지 않지만, Autoregressive Decoding의 수천 번 반복에서 누적되어 최종적으로 29%의 의미 있는 격차를 형성한다.

3.4 실전 벤치마크: 모델별 비교

다양한 모델에서의 벤치마크 결과를 종합하면 다음과 같다.

모델GPUSGLang (tok/s)vLLM (tok/s)TRT-LLM (tok/s)TGI (tok/s)
Llama-3.1-8B1x H10016,21512,55314,80011,200
Llama-3.1-70B4x H1008,5006,8008,2005,900
Mixtral-8x7B2x H10012,80010,10011,5008,700
Qwen-2.5-72B4x H1007,9006,2007,5005,500
DeepSeek-V3 (EP)8x H1006,2004,800--

SGLang은 대부분의 시나리오에서 최고 처리량을 기록하며, 특히 MoE(Mixture of Experts) 모델에서 Expert Parallelism 지원으로 추가적인 이점을 보인다.


4. [이유 3] 4,000라인의 기적: Python Zero-Overhead 스케줄러

4.1 "Python Control, Native Compute" 패러다임

LLM 인퍼런스의 숨은 병목은 GPU가 아니라 CPU에 있다. GPU가 현재 배치의 Forward Pass를 수행하는 동안, CPU는 다음 작업을 위한 메타데이터를 준비해야 한다. 배치 구성, 메모리 할당, 프리픽스 매칭, 요청 큐 관리 등 CPU에서 처리해야 하는 작업은 적지 않다.

최적화되지 않은 인퍼런스 엔진은 전체 실행 시간의 최대 50%를 CPU 오버헤드에 소비할 수 있다. 이 문제를 해결하기 위해 SGLang은 "Python Control, Native Compute" 패러다임을 채택한다.

기존 방식 (Sequential):
========================
Time[CPU: Batch N 준비] [GPU: Batch N 연산] [CPU: Batch N+1 준비] [GPU: Batch N+1 연산]
GPU idle                              ↑ GPU idle

SGLang Zero-Overhead (Pipelined):
==================================
Time[CPU: Batch N 준비] [CPU: Batch N+1 준비] [CPU: Batch N+2 준비] [CPU: Batch N+3 준비]
        [                 ] [GPU: Batch N 연산  ] [GPU: Batch N+1 연산] [GPU: Batch N+2 연산]
No GPU idle!No GPU idle!No GPU idle!

4.2 비동기 CPU-GPU 파이프라이닝

SGLang의 스케줄러는 GPU가 배치 N을 처리하는 동안, CPU가 배치 N+1의 메타데이터를 미리 준비하는 비동기 파이프라이닝을 구현한다.

# SGLang 스케줄러의 핵심 루프 (개념적 의사 코드)
class ZeroOverheadScheduler:
    def run_event_loop(self):
        while True:
            # 1. GPU에서 이전 배치 결과 비동기 수신 (non-blocking)
            completed = self.recv_from_gpu(blocking=False)
            if completed:
                self.process_completed_tokens(completed)

            # 2. 다음 배치 구성 (CPU에서 수행)
            next_batch = self.schedule_next_batch()

            # 3. Radix Tree에서 프리픽스 매칭 (CPU에서 수행)
            self.match_prefixes(next_batch)

            # 4. GPU 메모리 할당 (CPU에서 수행)
            self.allocate_kv_cache(next_batch)

            # 5. GPU로 배치 전송 (non-blocking)
            self.send_to_gpu(next_batch)

            # GPU는 이 모든 과정 동안 이전 배치를 처리 중!

핵심은 모든 CPU 작업이 GPU 연산과 병렬로 수행된다는 것이다. SGLang은 forward_streamcopy_stream을 분리하여, Forward Pass GPU 연산과 Data-to-Host(D2H) 메모리 전송을 독립적으로 실행함으로써 오버랩을 극대화한다.

4.3 Iterative Scheduling

SGLang의 또 다른 혁신은 Iterative Scheduling 방식이다. 기존 배치 스케줄러가 배치 내 모든 요청이 완료될 때까지 기다리는 반면, SGLang은 매 Forward Iteration마다 배치를 재구성한다.

기존 Static Batching:
=====================
Batch: [Req A(100 tok), Req B(50 tok), Req C(200 tok)]

Step 1-50:   A, B, C 모두 처리
Step 51-100: A, C 처리 (B 완료, 슬롯 낭비)
Step 101-200: C처리 (A도 완료, 2슬롯 낭비)

SGLang Iterative Scheduling:
============================
Step 1-50:   [A, B, C] 처리
Step 51:     B 완료 → 즉시 [A, C, D] (새 요청 D 삽입)
Step 101:    A 완료 → 즉시 [C, D, E, F] (새 요청 E, F 삽입)

GPU 활용률 극대화!

4.4 코드베이스 경량성

SGLang의 핵심 스케줄러는 약 4,000라인의 순수 Python 코드로 구현되어 있다. 이 숫자는 의미심장하다.

엔진스케줄러 코드 규모언어
SGLang~4,000 linesPython
vLLM~30,000+ linesPython + C++
TensorRT-LLM~50,000+ linesC++ + Python
TGI~20,000+ linesRust + Python

Python으로 작성된 스케줄러가 C++이나 Rust 기반 스케줄러와 대등하거나 더 빠른 성능을 낸다는 것은, 알고리즘 설계구현 언어보다 중요하다는 것을 증명한다. SGLang의 비동기 파이프라이닝은 CPU 스케줄링 시간을 GPU 연산 시간 뒤에 완전히 숨기므로, Python의 상대적 느림이 병목으로 작용하지 않는다.

이 경량성은 실용적 이점도 크다. 디버깅, 프로파일링, 커스텀 스케줄링 로직 추가가 C++ 기반 엔진 대비 압도적으로 쉽다. 연구자와 엔지니어가 빠르게 실험하고 기여할 수 있는 환경이 조성되어, SGLang의 빠른 발전 속도의 원동력이 되고 있다.

4.5 Micro-Batching Event Loop

SGLang v0.4 이후 도입된 Micro-Batching Event Loop는 파이프라이닝을 한 단계 더 진화시켰다. Pipeline Parallelism(PP) 환경에서 비동기 P2P(Peer-to-Peer) 통신을 통해 GPU 연산, CPU 메타데이터 처리, PP 통신을 모두 오버랩한다.

Micro-Batching Event Loop (PP=2):
==================================
GPU Stage 0: [Fwd mb0] [Fwd mb2] [Fwd mb4] ...
GPU Stage 1:           [Fwd mb0] [Fwd mb2] [Fwd mb4] ...
P2P Comm:      [Send mb0→S1] [Send mb2→S1] ...
CPU:         [Sched mb2] [Sched mb4] [Sched mb6] ...

mb = micro-batch, S = Stage, Fwd = Forward Pass
→ 모든 자원이 동시에 활성화!

이 설계를 통해 SGLang은 Pipeline Parallelism 환경에서도 버블(bubble)을 최소화하여, 대규모 모델의 멀티 노드 서빙에서도 높은 효율을 유지한다.


5. [이유 4] Prefill-Decode Disaggregation: 연산의 분업

5.1 Prefill과 Decode의 근본적 차이

LLM 인퍼런스의 두 단계인 Prefill과 Decode는 완전히 다른 하드웨어 요구사항을 갖는다.

특성Prefill PhaseDecode Phase
연산 유형Compute-BoundMemory-Bound
병목 자원GPU FLOPSGPU Memory Bandwidth
배치 특성큰 입력, 병렬 처리토큰 1개, 순차 처리
GPU 활용률높음 (60-80%)낮음 (10-30%)
최적 하드웨어높은 FLOPS높은 HBM 대역폭
지연 시간 영향TTFTTPOT

기존 인퍼런스 엔진은 두 단계를 **동일한 GPU에서 시분할(time-sharing)**로 처리한다. Continuous Batching 등의 기법으로 어느 정도 최적화할 수 있지만, 근본적으로 서로 다른 연산 패턴이 하나의 GPU를 공유하는 비효율은 해소되지 않는다.

Prefill과 Decode의 간섭 문제:

동일 GPU에서 시분할 처리:
========================
Time[Prefill Req A] [Decode Batch 1-5] [Prefill Req B] [Decode Batch 1-8]
                          ↑                                   ↑
                   Decode 지연 시간 불규칙           새 Prefill이 기존 Decode 방해
                   (Prefill이 GPU 점유)             (TPOT 스파이크 발생)

긴 프롬프트의 Prefill이 실행되면, 이미 Decode 중인 요청들의 TPOT(Time Per Output Token)이 급증하는 간섭 현상이 발생한다. 이는 사용자 경험을 심각하게 저하시킨다.

5.2 SGLang의 PD Disaggregation 아키텍처

SGLang은 Prefill과 Decode를 물리적으로 분리된 GPU 그룹에 배치하는 Disaggregation 아키텍처를 지원한다.

PD Disaggregation Architecture:
================================

   ┌─────────────────────────────────────────────────────┐
Router / Gateway              (요청 수신 및 Prefill 서버로 분배)   └──────────────────┬──────────────────────────────────┘
          ┌───────────┴───────────┐
          ▼                       ▼
   ┌──────────────┐      ┌──────────────┐
Prefill GPU  │      │  Prefill GPUGroup #1    │      │   Group #2     (H100 x4)  (H100 x4)   │              │      │              │
Compute-     │      │ Compute-Optimized    │      │ Optimized   └──────┬───────┘      └──────┬───────┘
NIXL/RDMANIXL/RDMA
KV Cache TransferKV Cache Transfer
          ▼                       ▼
   ┌──────────────┐      ┌──────────────┐
Decode GPU   │      │  Decode GPUGroup #1    │      │   Group #2     (H100 x4)  (H100 x4)   │              │      │              │
Bandwidth-   │      │ Bandwidth-Optimized    │      │ Optimized   └──────────────┘      └──────────────┘

5.3 NIXL: 고속 KV 캐시 전송

Prefill과 Decode를 분리하면, Prefill에서 생성된 KV 캐시를 Decode GPU로 전송해야 하는 새로운 과제가 생긴다. SGLang은 NVIDIA의 **NIXL(NVIDIA Inference Transfer Library)**을 전송 백엔드로 활용한다.

NIXL은 NVLink, InfiniBand, PCIe, SSD 등 다양한 패브릭(fabric)을 단일 추상화 레이어로 통합하는 저지연 포인트-투-포인트 전송 라이브러리다.

NIXL KV Cache Transfer Flow:
============================

1. Bootstrap: DecodePrefill에 bootstrap_room ID 전달
2. Memory Alloc: Decode가 GPU 메모리 페이지 사전 할당
3. Prefill Exec: Prefill Worker가 프롬프트 처리 → KV Cache 생성
4. RDMA Write: Prefill이 RDMA를 통해 Decode GPU 메모리에 직접 쓰기
                (CPU 우회, Zero-Copy)
5. Completion: Decode가 전송 완료 폴링 → 즉시 Decode 시작

NVLink 전송 대역폭: ~900 GB/s (GB200 NVL72)
InfiniBand 전송 대역폭: ~400 Gb/s (HDR)

RDMA(Remote Direct Memory Access)를 통해 CPU를 우회하여 GPU 메모리 간 직접 전송이 이루어지므로, 전송 지연이 최소화된다.

5.4 Blackwell GB200/B200 최적화

SGLang의 PD Disaggregation은 NVIDIA Blackwell 아키텍처에서 특히 강력한 성능을 발휘한다.

하드웨어Prefill 성능Decode 성능비고
H100 SXMBaselineBaselineFP8
B200 SXM~2.5x~2.0xNVFP4 지원
GB200 NVL72~3.8x~4.8xNVLink 900GB/s

GB200 NVL72에서 SGLang은 DeepSeek V3/R1 모델을 FP8 Attention + NVFP4 MoE 구성으로 서빙하며, GPU당 26,156 input tokens/s13,386 output tokens/s를 달성했다. 이는 H100 대비 프리필 3.8x, 디코드 4.8x 향상이다.

5.5 독립적 스케일링의 가치

PD Disaggregation의 가장 중요한 실용적 이점은 독립적 스케일링이다.

트래픽 패턴에 따른 스케일링:

[시나리오 1: 긴 프롬프트, 짧은 응답 (문서 요약)]
Prefill GPU: 8/  Decode GPU: 2
[시나리오 2: 짧은 프롬프트,응답 (코드 생성)]
Prefill GPU: 2/  Decode GPU: 8
[시나리오 3: 균등 부하 (일반 챗봇)]
Prefill GPU: 4/  Decode GPU: 4

워크로드 특성에 따라 Prefill과 Decode 자원을 독립적으로 조절할 수 있으므로, GPU 활용률을 극대화하면서 비용을 최적화할 수 있다. 이는 클라우드 환경에서 자동 스케일링(autoscaling)과의 자연스러운 결합을 가능하게 한다.


6. [이유 5] 구조화된 생성: Compressed FSM의 혁신

6.1 구조화된 출력의 필요성

프로덕션 LLM 애플리케이션에서 모델의 출력이 특정 형식(JSON, XML, SQL 등)을 준수하도록 강제하는 것은 필수적이다. 에이전트 시스템에서 도구 호출 파라미터가 유효한 JSON이어야 하고, 데이터 추출 파이프라인에서 출력이 사전 정의된 스키마를 따라야 한다.

기존의 구조화된 생성 방식은 토큰 단위 마스킹으로 구현된다. 매 토큰 생성 시 현재 FSM(Finite State Machine) 상태에서 허용되는 토큰만 남기고 나머지의 로짓을 -infinity로 설정한다. 이 방식은 정확하지만, 매 토큰마다 FSM 상태 전이를 계산해야 하므로 상당한 오버헤드가 발생한다.

6.2 Compressed FSM의 원리

SGLang의 Compressed FSM은 JSON 스키마(또는 정규표현식)를 FSM으로 변환한 후, 인접한 단일 전이 엣지(Singular Transition Edge)를 압축하는 최적화를 적용한다.

JSON Schema 예시:
{
  "name": string,
  "age": integer,
  "city": string
}

일반 FSM (토큰별 전이):
========================
S0'{'S1'"'S2'n'S3'a'S4'm'S5'e'S6'"'S7':'S8

각 전이마다 GPU forward pass 필요 → 8번의 forward pass

Compressed FSM (점프 포워드):
=============================
S0'{"name":'S8  (Singular transitions 압축!)

감지: S0에서 S8까지 각 상태에서 가능한 전이가 딱 하나뿐
1번의 forward pass로 8 토큰 생성!

6.3 Jump-Forward 메커니즘

Compressed FSM의 핵심은 Jump-Forward Decoding이다. FSM을 분석하여, 현재 상태에서 다음 상태까지 **유일한 경로(singular transition path)**가 존재하는 구간을 미리 식별한다.

Jump-Forward Decoding 과정:
===========================

1. FSM 사전 분석:
   - 각 상태에서 가능한 전이 수 계산
   - Singular path 구간 식별 및 압축

2. 디코딩 실행:
   State S0: 가능한 전이 = {'{'} (singular!)
Jump: '{"name":"' 직접 삽입 (forward pass 불필요)

   State S8: 가능한 전이 = {any string token} (multiple)
Normal decode: GPU forward pass 수행 → "Alice"

   State S9: 가능한 전이 = {'","age":'} (singular!)
Jump: '","age":' 직접 삽입

   State S10: 가능한 전이 = {0-9 tokens} (multiple)
Normal decode: GPU forward pass 수행 → "30"

   State S11: 가능한 전이 = {'","city":"'} (singular!)
Jump: '","city":"' 직접 삽입

   ...계속

RadixAttention과의 시너지도 강력하다. Jump-Forward 실행 시 현재 요청을 종료하고 새 요청을 큐에 넣어도, RadixAttention이 이전 토큰의 KV 캐시를 자동으로 재사용하므로 중복 연산이 발생하지 않는다.

6.4 성능 향상

Compressed FSM을 통한 구조화된 생성의 성능 향상은 출력 형식에 따라 다르지만, JSON 디코딩에서 특히 극적이다.

생성 형식일반 Constrained DecodingSGLang Compressed FSM속도 향상
Simple JSON1.0x1.6x1.6x
Nested JSON1.0x2.1x2.1x
Complex Schema1.0x3.0x3.0x
Regex Pattern1.0x1.4x1.4x

복잡한 JSON 스키마일수록 고정 키 이름, 구분자, 괄호 등의 예측 가능한 토큰이 많아져 압축 효과가 극대화된다. Zheng et al.의 논문에 따르면, JSON 디코딩 벤치마크에서 최대 3x의 처리량 향상을 달성했다.

6.5 Structured Generation API 사용 예시

SGLang에서 구조화된 출력을 활용하는 방법은 OpenAI-호환 API를 통해 간단히 사용할 수 있다.

import openai

client = openai.Client(base_url="http://127.0.0.1:30000/v1", api_key="EMPTY")

# JSON Schema를 통한 구조화된 출력
response = client.chat.completions.create(
    model="meta-llama/Llama-3.1-8B-Instruct",
    messages=[
        {"role": "user", "content": "Generate a user profile for Alice who is 30 years old."}
    ],
    response_format={
        "type": "json_schema",
        "json_schema": {
            "name": "user_profile",
            "schema": {
                "type": "object",
                "properties": {
                    "name": {"type": "string"},
                    "age": {"type": "integer"},
                    "city": {"type": "string"},
                    "hobbies": {
                        "type": "array",
                        "items": {"type": "string"}
                    }
                },
                "required": ["name", "age", "city", "hobbies"]
            }
        }
    },
    max_tokens=256
)

print(response.choices[0].message.content)
# 출력: {"name": "Alice", "age": 30, "city": "San Francisco", "hobbies": ["reading", "hiking", "coding"]}

정규표현식을 통한 제약도 지원된다.

# Regex 기반 구조화된 생성
response = client.chat.completions.create(
    model="meta-llama/Llama-3.1-8B-Instruct",
    messages=[
        {"role": "user", "content": "Generate a valid email address for John."}
    ],
    extra_body={"regex": r"[a-zA-Z0-9._%+-]+@[a-zA-Z0-9.-]+\.[a-zA-Z]{2,}"},
    max_tokens=64
)

7. SGLang 인퍼런스 프레임워크 종합 비교

7.1 SGLang vs vLLM vs TGI vs TensorRT-LLM

주요 LLM 인퍼런스 프레임워크를 종합적으로 비교하면 다음과 같다.

특성SGLangvLLMTGI v3TensorRT-LLM
개발 주체UC Berkeley / LMSYSUC BerkeleyHugging FaceNVIDIA
언어PythonPython + C++Rust + PythonC++ + Python
KV Cache 관리RadixAttention (Radix Tree)PagedAttention (Block Table)PagedAttentionPagedAttention
요청 간 캐시 공유자동 (Radix Tree)Automatic Prefix Caching제한적제한적
스케줄러 오버헤드Zero-Overhead중간낮음낮음
구조화된 출력Compressed FSM (3x)Outlines 통합지원제한적
PD DisaggregationNIXL 기반 네이티브실험적미지원지원
하드웨어 지원NVIDIA, AMD, Intel, TPUNVIDIA, AMD, TPU, CPUNVIDIA, AMDNVIDIA Only
양자화FP4/FP8/INT4/AWQ/GPTQFP8/INT4/AWQ/GPTQGPTQ/AWQFP8/INT4/INT8
MoE Expert Parallelism지원지원미지원지원
Multi-LoRA Batching지원지원지원제한적
Speculative Decoding지원지원지원지원
DSL/프론트엔드 언어SGLang Frontend미지원미지원미지원
OpenAI-호환 API완전 지원완전 지원지원부분 지원
코드베이스 규모~50K lines~200K+ lines~100K+ lines~300K+ lines
러닝 커브낮음낮음중간높음
최적 사용 시나리오에이전트, RAG, Few-shot범용 서빙HF 생태계 통합극저지연 요구

7.2 선택 가이드

  • 에이전트/RAG/도구 호출 집약적 워크로드: SGLang -- RadixAttention의 자동 캐시 재사용이 압도적 이점
  • 범용 LLM 서빙 (다양한 하드웨어): vLLM -- 가장 넓은 하드웨어/모델 지원
  • Hugging Face 생태계 통합: TGI -- Inference Endpoints와 네이티브 통합
  • 단일 요청 극저지연 (NVIDIA 전용): TensorRT-LLM -- 커널 수준 최적화

8. SGLang 설치 및 빠른 시작

8.1 pip을 통한 설치

가장 간단한 설치 방법이다.

# Python 3.9+ 필요, CUDA 12.x 권장
pip install --upgrade pip
pip install "sglang[all]"

# 또는 uv를 사용한 빠른 설치
pip install uv
uv pip install "sglang[all]"

소스로부터 설치하면 최신 기능을 사용할 수 있다.

git clone https://github.com/sgl-project/sglang.git
cd sglang
pip install -e "python[all]"

8.2 Docker를 통한 배포

프로덕션 환경에서는 Docker 이미지를 권장한다.

# 공식 Docker 이미지 사용
docker run --gpus all \
  --shm-size 32g \
  -p 30000:30000 \
  -v ~/.cache/huggingface:/root/.cache/huggingface \
  --env "HF_TOKEN=${HF_TOKEN}" \
  --ipc=host \
  lmsysorg/sglang:latest \
  python3 -m sglang.launch_server \
    --model-path meta-llama/Llama-3.1-8B-Instruct \
    --host 0.0.0.0 \
    --port 30000

Docker Compose를 사용할 수도 있다.

# docker-compose.yml
version: '3.8'
services:
  sglang:
    image: lmsysorg/sglang:latest
    ports:
      - '30000:30000'
    volumes:
      - ~/.cache/huggingface:/root/.cache/huggingface
    environment:
      - HF_TOKEN=${HF_TOKEN}
    deploy:
      resources:
        reservations:
          devices:
            - driver: nvidia
              count: all
              capabilities: [gpu]
    ipc: host
    shm_size: '32g'
    command: >
      python3 -m sglang.launch_server
      --model-path meta-llama/Llama-3.1-8B-Instruct
      --host 0.0.0.0
      --port 30000
docker compose up -d

8.3 서버 실행

SGLang 서버를 직접 실행하는 기본 명령어는 다음과 같다.

# 기본 서버 실행 (단일 GPU)
python -m sglang.launch_server \
  --model-path meta-llama/Llama-3.1-8B-Instruct \
  --host 0.0.0.0 \
  --port 30000

# 또는 sglang serve 명령어 사용
sglang serve meta-llama/Llama-3.1-8B-Instruct \
  --host 0.0.0.0 \
  --port 30000

서버가 정상적으로 시작되면, http://localhost:30000/docs에서 Swagger UI 기반 API 문서를 확인할 수 있다.

8.4 서버 상태 확인

# 서버 헬스 체크
curl http://localhost:30000/health

# 모델 정보 확인
curl http://localhost:30000/v1/models

# 서버 메트릭 확인
curl http://localhost:30000/get_server_info

9. API 사용법 및 코드 예제

9.1 OpenAI-호환 Chat Completions API

SGLang은 OpenAI API와 완전히 호환되는 엔드포인트를 제공하므로, 기존 OpenAI SDK를 그대로 사용할 수 있다.

cURL 사용:

curl http://127.0.0.1:30000/v1/chat/completions \
  -H "Content-Type: application/json" \
  -H "Authorization: Bearer EMPTY" \
  -d '{
    "model": "meta-llama/Llama-3.1-8B-Instruct",
    "messages": [
      {"role": "system", "content": "You are a helpful AI assistant."},
      {"role": "user", "content": "Kubernetes의 Pod과 Deployment의 차이를 설명해주세요."}
    ],
    "max_tokens": 512,
    "temperature": 0.7,
    "top_p": 0.9
  }'

Python OpenAI SDK 사용:

from openai import OpenAI

client = OpenAI(
    base_url="http://localhost:30000/v1",
    api_key="EMPTY"  # SGLang은 기본적으로 인증 불필요
)

# 일반 Chat Completion
response = client.chat.completions.create(
    model="meta-llama/Llama-3.1-8B-Instruct",
    messages=[
        {"role": "system", "content": "당신은 클라우드 네이티브 전문가입니다."},
        {"role": "user", "content": "Helm chart와 Kustomize의 장단점을 비교해주세요."}
    ],
    max_tokens=1024,
    temperature=0.7
)

print(response.choices[0].message.content)

스트리밍 응답:

# Streaming 응답
stream = client.chat.completions.create(
    model="meta-llama/Llama-3.1-8B-Instruct",
    messages=[
        {"role": "user", "content": "Python으로 간단한 웹 서버를 작성해주세요."}
    ],
    max_tokens=1024,
    stream=True
)

for chunk in stream:
    if chunk.choices[0].delta.content:
        print(chunk.choices[0].delta.content, end="", flush=True)

9.2 Text Completions API

Chat 형식이 아닌 일반 텍스트 완성도 지원된다.

curl http://127.0.0.1:30000/v1/completions \
  -H "Content-Type: application/json" \
  -d '{
    "model": "meta-llama/Llama-3.1-8B-Instruct",
    "prompt": "The capital of France is",
    "max_tokens": 32,
    "temperature": 0
  }'

9.3 배치 요청 처리

대량 요청을 효율적으로 처리하는 배치 API도 사용 가능하다.

import requests
import json

# 네이티브 SGLang 배치 엔드포인트
batch_requests = [
    {
        "text": "Translate to Korean: Hello, how are you?",
        "sampling_params": {"max_new_tokens": 64, "temperature": 0.3}
    },
    {
        "text": "Translate to Korean: The weather is nice today.",
        "sampling_params": {"max_new_tokens": 64, "temperature": 0.3}
    },
    {
        "text": "Translate to Korean: I love programming.",
        "sampling_params": {"max_new_tokens": 64, "temperature": 0.3}
    }
]

# 비동기 요청으로 처리량 극대화
import asyncio
import aiohttp

async def send_requests(requests_data):
    async with aiohttp.ClientSession() as session:
        tasks = []
        for req in requests_data:
            task = session.post(
                "http://localhost:30000/generate",
                json=req
            )
            tasks.append(task)
        responses = await asyncio.gather(*tasks)
        results = [await r.json() for r in responses]
        return results

results = asyncio.run(send_requests(batch_requests))
for r in results:
    print(r["text"])

9.4 SGLang Frontend (DSL) 사용

SGLang의 고유한 프론트엔드 언어를 사용하면, 복잡한 LLM 프로그램을 Pythonic하게 작성할 수 있다.

import sglang as sgl

# SGLang 프론트엔드 함수 정의
@sgl.function
def multi_turn_qa(s, question1, question2):
    s += sgl.system("You are a helpful AI assistant specialized in cloud computing.")
    s += sgl.user(question1)
    s += sgl.assistant(sgl.gen("answer1", max_tokens=256))
    s += sgl.user(question2)
    s += sgl.assistant(sgl.gen("answer2", max_tokens=256))

# 런타임 엔드포인트 설정
sgl.set_default_backend(sgl.RuntimeEndpoint("http://localhost:30000"))

# 실행
state = multi_turn_qa.run(
    question1="Kubernetes에서 HPA는 어떻게 동작하나요?",
    question2="VPA와의 차이점은 무엇인가요?"
)

print("Answer 1:", state["answer1"])
print("Answer 2:", state["answer2"])

병렬 생성(Fork-Join):

@sgl.function
def parallel_analysis(s, topic):
    s += sgl.system("You are a technology analyst.")
    s += sgl.user(f"Analyze '{topic}' from three perspectives.")

    # Fork: 3개의 분석을 병렬로 생성
    forks = s.fork(3)

    forks[0] += sgl.user("Technical perspective:")
    forks[0] += sgl.assistant(sgl.gen("technical", max_tokens=200))

    forks[1] += sgl.user("Business perspective:")
    forks[1] += sgl.assistant(sgl.gen("business", max_tokens=200))

    forks[2] += sgl.user("User experience perspective:")
    forks[2] += sgl.assistant(sgl.gen("ux", max_tokens=200))

    # Join: 모든 결과 수집
    forks.join()

    # 종합
    s += sgl.user("Summarize the three analyses above:")
    s += sgl.assistant(sgl.gen("summary", max_tokens=300))

state = parallel_analysis.run(topic="SGLang inference engine")
print("Technical:", state["technical"])
print("Business:", state["business"])
print("UX:", state["ux"])
print("Summary:", state["summary"])

선택(Select) 기반 분류:

@sgl.function
def classify_sentiment(s, text):
    s += sgl.user(f"Classify the sentiment of the following text: '{text}'")
    s += sgl.assistant(
        "The sentiment is " + sgl.select("label", ["positive", "negative", "neutral"])
    )

state = classify_sentiment.run(text="SGLang is amazingly fast!")
print("Sentiment:", state["label"])  # "positive"

10. 주요 설정 파라미터 가이드

10.1 서버 실행 파라미터

SGLang 서버의 주요 설정 파라미터를 정리한다.

python -m sglang.launch_server \
  --model-path <model_name_or_path>    # HuggingFace 모델 이름 또는 로컬 경로
  --host 0.0.0.0                        # 바인딩 호스트
  --port 30000                          # 서비스 포트
  --tp-size 4                           # Tensor Parallelism 크기
  --dp-size 2                           # Data Parallelism 크기
  --pp-size 2                           # Pipeline Parallelism 크기
  --mem-fraction-static 0.88            # GPU 메모리 중 KV Cache 비율 (기본: 0.88)
  --max-running-requests 128            # 동시 처리 최대 요청 수
  --max-total-tokens 131072             # 최대 총 토큰 수
  --context-length 32768                # 컨텍스트 길이
  --chunked-prefill-size 8192           # Chunked Prefill 청크 크기
  --schedule-policy lpm                 # 스케줄링 정책 (lpm / fcfs / random)
  --quantization fp8                    # 양자화 방법 (fp8 / int4 / awq / gptq)
  --dtype auto                          # 데이터 타입 (auto / float16 / bfloat16)
  --trust-remote-code                   # 원격 코드 신뢰 허용
  --chat-template auto                  # 채팅 템플릿 (auto 또는 커스텀 경로)
  --log-level info                      # 로그 레벨
  --enable-metrics                      # Prometheus 메트릭 활성화
  --api-key "your-secret-key"           # API 키 인증 활성화

10.2 핵심 파라미터 상세 설명

메모리 관리:

# GPU 메모리의 88%를 KV Cache에 할당 (기본값)
--mem-fraction-static 0.88

# 대규모 모델에서 메모리 부족 시 줄임
--mem-fraction-static 0.80

# KV Cache 최대 토큰 수 명시적 설정
--max-total-tokens 65536

스케줄링 정책:

# LPM (Longest Prefix Match): RadixAttention 캐시 히트율 극대화 (기본값)
--schedule-policy lpm

# FCFS (First Come First Served): 단순 선입선출
--schedule-policy fcfs

# Random: 무작위 선택
--schedule-policy random

양자화 설정:

# FP8 양자화 (Hopper+ GPU 필요)
--quantization fp8

# NVFP4 양자화 (Blackwell GPU 필요)
--quantization fp4

# INT4 AWQ 양자화
--quantization awq

# INT4 GPTQ 양자화
--quantization gptq

10.3 환경 변수

# CUDA 디바이스 선택
export CUDA_VISIBLE_DEVICES=0,1,2,3

# HuggingFace 토큰 (게이트 모델 접근)
export HF_TOKEN="hf_your_token_here"

# NCCL 설정 (멀티 GPU)
export NCCL_P2P_DISABLE=0
export NCCL_IB_DISABLE=0

# SGLang 로그 레벨
export SGLANG_LOG_LEVEL=info

# FlashInfer 워크스페이스 크기
export SGLANG_FLASHINFER_WORKSPACE_SIZE=2147483648  # 2GB

11. 배포 가이드

11.1 단일 GPU 배포

가장 기본적인 배포 형태다.

# Llama-3.1-8B를 단일 GPU에 배포
python -m sglang.launch_server \
  --model-path meta-llama/Llama-3.1-8B-Instruct \
  --host 0.0.0.0 \
  --port 30000 \
  --mem-fraction-static 0.88

# 양자화를 적용하여 더 큰 모델을 단일 GPU에 배포
python -m sglang.launch_server \
  --model-path meta-llama/Llama-3.1-70B-Instruct \
  --quantization awq \
  --host 0.0.0.0 \
  --port 30000

11.2 멀티 GPU 배포 (Tensor Parallelism)

모델이 단일 GPU 메모리에 들어가지 않을 때 사용한다.

# 4-GPU Tensor Parallelism (70B 모델)
python -m sglang.launch_server \
  --model-path meta-llama/Llama-3.1-70B-Instruct \
  --tp-size 4 \
  --host 0.0.0.0 \
  --port 30000

# 2-GPU TP + 2-GPU DP = 4 GPU (8B 모델, 처리량 극대화)
python -m sglang.launch_server \
  --model-path meta-llama/Llama-3.1-8B-Instruct \
  --tp-size 2 \
  --dp-size 2 \
  --host 0.0.0.0 \
  --port 30000

11.3 멀티 노드 배포

대규모 모델을 여러 서버에 걸쳐 배포할 때 사용한다.

# Node 0 (Master)
python -m sglang.launch_server \
  --model-path meta-llama/Llama-3.1-405B-Instruct \
  --tp-size 16 \
  --nnodes 2 \
  --node-rank 0 \
  --dist-init-addr node0-ip:5000 \
  --host 0.0.0.0 \
  --port 30000

# Node 1 (Worker)
python -m sglang.launch_server \
  --model-path meta-llama/Llama-3.1-405B-Instruct \
  --tp-size 16 \
  --nnodes 2 \
  --node-rank 1 \
  --dist-init-addr node0-ip:5000

11.4 PD Disaggregation 배포

Prefill과 Decode를 분리하여 배포하는 방법이다.

# Prefill 서버 실행
python -m sglang.launch_server \
  --model-path meta-llama/Llama-3.1-70B-Instruct \
  --tp-size 4 \
  --disaggregation-mode prefill \
  --disaggregation-transfer-backend nixl \
  --host 0.0.0.0 \
  --port 30001

# Decode 서버 실행
python -m sglang.launch_server \
  --model-path meta-llama/Llama-3.1-70B-Instruct \
  --tp-size 4 \
  --disaggregation-mode decode \
  --disaggregation-transfer-backend nixl \
  --host 0.0.0.0 \
  --port 30002

11.5 Kubernetes 배포 (SkyPilot)

클라우드 환경에서 Kubernetes를 통한 배포도 지원된다.

# sglang-skypilot.yaml
resources:
  cloud: aws # 또는 gcp, azure
  accelerators: A100:4
  memory: 128+

envs:
  HF_TOKEN: <your-hf-token>
  MODEL_NAME: meta-llama/Llama-3.1-70B-Instruct

setup: |
  pip install "sglang[all]"

run: |
  python -m sglang.launch_server \
    --model-path ${MODEL_NAME} \
    --tp-size 4 \
    --host 0.0.0.0 \
    --port 30000
# SkyPilot으로 클러스터 생성 및 배포
pip install skypilot-nightly
sky launch -c sglang-cluster --env HF_TOKEN sglang-skypilot.yaml

11.6 Multi-LoRA 배포

여러 LoRA 어댑터를 동시에 서빙하는 구성이다.

# Base 모델 + 여러 LoRA 어댑터 동시 서빙
python -m sglang.launch_server \
  --model-path meta-llama/Llama-3.1-8B-Instruct \
  --lora-paths \
    korean-chat=/path/to/korean-lora \
    code-gen=/path/to/code-lora \
    medical=/path/to/medical-lora \
  --max-loras-per-batch 4 \
  --host 0.0.0.0 \
  --port 30000

요청 시 LoRA 어댑터를 지정할 수 있다.

curl http://127.0.0.1:30000/v1/chat/completions \
  -H "Content-Type: application/json" \
  -d '{
    "model": "korean-chat",
    "messages": [{"role": "user", "content": "안녕하세요!"}],
    "max_tokens": 128
  }'

12. SGLang 2026 로드맵과 생태계

12.1 2026 Q1 로드맵 하이라이트

SGLang 프로젝트는 2026년에도 빠르게 진화하고 있다. 2026 Q1 로드맵의 주요 항목은 다음과 같다.

영역진행 사항
Blackwell 최적화GB300/B300 지원, NVFP4 MoE 커널 통합
TPU 지원SGLang-JAX 백엔드를 통한 네이티브 TPU 실행
Diffusion 모델SGLang Diffusion으로 이미지/비디오 생성 가속
Pipeline ParallelismMillion-Token 컨텍스트 지원을 위한 Chunked PP
Day-0 모델 지원MiMo-V2-Flash, Nemotron 3 Nano, Mistral Large 3
NVIDIA Dynamo 통합NVIDIA Dynamo와의 네이티브 Disaggregated Serving

12.2 하드웨어 지원 확대

SGLang은 NVIDIA GPU뿐 아니라 다양한 하드웨어로 지원을 확대하고 있다.

하드웨어지원 상태핵심 기능
NVIDIA H100/H200완전 지원FP8, FlashInfer
NVIDIA B200/GB200완전 지원NVFP4, TMA, NVLink 900GB/s
NVIDIA GB300/B300지원 진행 중차세대 Blackwell
NVIDIA RTX PRO 6000지원Blackwell Server Edition
NVIDIA Jetson Thor지원 진행 중Edge 인퍼런스
AMD MI300X지원ROCm, FP8
Intel Xeon AMX실험적 지원CPU 인퍼런스
Google TPU지원SGLang-JAX 백엔드

12.3 '인퍼런스 경제학'의 변화

SGLang이 대표하는 차세대 인퍼런스 엔진의 의미는 단순한 속도 향상을 넘어선다. **'인퍼런스 경제학(Inference Economics)'**의 근본적 변화를 촉진한다.

비용 효율 공식:

인퍼런스 비용 = GPU 시간당 비용 / 처리량 (tok/s)

H100 기준:
  vLLM:  $3.50/hr / 12,553 tok/s = $0.000279 / 1K tokens
  SGLang: $3.50/hr / 16,215 tok/s = $0.000216 / 1K tokens

SGLang은 동일 GPU에서 22.6% 비용 절감
→ 에이전트 시나리오 (캐시 히트율 포함): 최대 60-80% 비용 절감

대규모 LLM 서비스를 운영하는 조직에서 이 차이는 월 수만~수십만 달러의 비용 절감으로 이어진다. 하드웨어의 물리적 한계를 소프트웨어 지능으로 돌파하는 것이 SGLang의 본질이다.


13. 결론: 하드웨어의 한계를 소프트웨어 지능으로 돌파하다

SGLang이 LLM 인퍼런스의 판도를 바꾸는 5가지 이유를 정리하면 다음과 같다.

#혁신핵심 메커니즘성과
1RadixAttentionRadix Tree 기반 KV 캐시 공유에이전트 워크플로우 최대 5x 향상
2하이퍼 스페셜라이즈드 설계추상화 최소화, TMA 직접 통합vLLM 대비 29% 처리량 우위
3Zero-Overhead 스케줄러CPU-GPU 비동기 파이프라이닝4,000라인 Python으로 C++ 수준 성능
4PD DisaggregationNIXL 기반 Prefill-Decode 분리독립적 스케일링, GB200에서 3.8-4.8x
5Compressed FSMSingular transitions 압축, Jump-ForwardJSON 디코딩 최대 3x 속도 향상

이 5가지 혁신은 개별적으로도 강력하지만, 통합 아키텍처 안에서 시너지를 발휘한다는 것이 SGLang의 진정한 강점이다. RadixAttention의 캐시 재사용이 Compressed FSM의 Jump-Forward를 가능하게 하고, Zero-Overhead 스케줄러가 RadixAttention의 트리 탐색 오버헤드를 GPU 연산 뒤에 숨기며, PD Disaggregation이 이 모든 최적화를 대규모 분산 환경으로 확장한다.

LLM 인퍼런스 비용이 AI 서비스의 지속 가능성을 결정하는 시대에, SGLang은 **"같은 GPU로 더 많은 가치를 창출한다"**는 명제를 현실로 만들고 있다. NVIDIA Blackwell의 NVFP4, AMD MI300X, Intel Xeon AMX까지 지원하며 하드웨어 중립적인 최적화를 추구하는 SGLang의 행보는, 인퍼런스 엔진이 단순한 모델 실행기를 넘어 AI 인프라의 핵심 운영체제로 진화하고 있음을 보여준다.

vLLM이 PagedAttention으로 LLM 서빙의 대중화를 이끌었다면, SGLang은 RadixAttention과 전체 시스템 co-design으로 **LLM 서빙의 다음 장(chapter)**을 열고 있다.


14. References

  1. Zheng, L., Yin, L., Xie, Z., et al. "SGLang: Efficient Execution of Structured Language Model Programs." NeurIPS 2024. arXiv:2312.07104

  2. SGLang GitHub Repository. https://github.com/sgl-project/sglang

  3. SGLang Official Documentation. https://docs.sglang.ai/

  4. LMSYS Blog - "Fast and Expressive LLM Inference with RadixAttention and SGLang." https://lmsys.org/blog/2024-01-17-sglang/

  5. LMSYS Blog - "SGLang v0.4: Zero-Overhead Batch Scheduler, Cache-Aware Load Balancer, Faster Structured Outputs." https://lmsys.org/blog/2024-12-04-sglang-v0-4/

  6. LMSYS Blog - "Fast JSON Decoding for Local LLMs with Compressed Finite State Machine." https://lmsys.org/blog/2024-02-05-compressed-fsm/

  7. LMSYS Blog - "Deploying DeepSeek on GB200 NVL72 with PD and Large Scale EP." https://lmsys.org/blog/2025-09-25-gb200-part-2/

  8. LMSYS Blog - "Pipeline Parallelism in SGLang: Scaling to Million-Token Contexts and Beyond." https://lmsys.org/blog/2026-01-15-chunked-pipeline/

  9. SGLang PD Disaggregation Documentation. https://docs.sglang.ai/advanced_features/pd_disaggregation.html

  10. SGLang NVIDIA Collaboration Roadmap 2026 Q1. https://github.com/sgl-project/sglang/issues/17130

  11. SGLang Development Roadmap 2026 Q1. https://github.com/sgl-project/sglang/issues/12780

  12. Kwon, W., et al. "Efficient Memory Management for Large Language Model Serving with PagedAttention." SOSP 2023. (vLLM 논문)

  13. NVIDIA NIXL Documentation - "Low Latency Point-to-Point Inference Transfer Library."

  14. Clarifai Blog - "Comparing SGLang, vLLM, and TensorRT-LLM with GPT-OSS-120B." https://www.clarifai.com/blog/comparing-sglang-vllm-and-tensorrt-llm-with-gpt-oss-120b

  15. RunPod Blog - "When to Choose SGLang Over vLLM: Multi-Turn Conversations and KV Cache Reuse." https://www.runpod.io/blog/sglang-vs-vllm-kv-cache