SGLang — Performance Optimization

2024년 LLM 서빙은 더 이상 “FlashAttention 을 누가 더 빨리 짜느냐” 의 게임이 아니다. 같은 attention 커널을 쓰면서도 엔진별로 throughput 이 두 배 차이가 나는데, 그 차이가 거의 다 CPU scheduling overhead에 있다는 게 SGLang 의 출발점.

강의 첫 슬라이드의 측정 — vLLM 의 초기 버전과 SGLang 의 초기 버전 모두에서 “CPU 가 다음 batch 를 준비하는 동안 GPU 가 50% 이상 idle” 인 구간이 있었다. 같은 GPU, 같은 모델, 같은 attention 커널인데도 엔진의 control loop 가 막혀서 throughput 이 절반 이하로 떨어진다.

그래서 강의 끝에 손에 잡혀야 하는 자산은 — (1) CPU scheduling 이 어떻게 GPU 를 굶기는가의 mental model, (2) RadixAttention 이 prefix sharing 을 어떻게 일반화하는가, (3) SGLang 의 frontend DSL 이 왜 단순 OpenAI 호환이 아니라 별도의 형태가 됐는가, (4) vLLM 과 정확히 어디가 다른가.

continuous batching (vLLM 이 일반화한 패턴) 은 매 forward 마다 batch 의 구성을 다시 만든다. 새 요청 도착, 종료된 요청 제거, KV cache 메모리 할당, FlashAttention 메타데이터 빌드 — 이 모든 게 한 step 안에 들어간다. 모델 forward 가 5ms 라면, scheduling 이 또 5ms 걸리는 순간 throughput 은 절반.

이 한 줄짜리 변경이 만들어내는 차이는 단순한 latency 가 아니다 — throughput 이 거의 두 배로 뜬다. 강의에서 Yineng 이 보여준 측정 — Llama-3.1-8B 의 throughput 이 v0 vLLM 대비 약 1.5×~2× 수준. 같은 모델, 같은 GPU 에서.

RadixAttention 은 SGLang 의 핵심 자산. 여러 요청이 prefix 를 공유하는 일 이 LLM 서빙의 거의 모든 실제 워크로드(few-shot, system prompt, tree-of-thoughts 등)에서 흔하다는 관찰에서 출발 — KV cache 를 단순 LRU 페이지가 아니라 radix tree 로 관리한다.

이 구조의 이득은 두 단계로 온다. 첫째 — prefill 비용이 줄어든다. system prompt 가 1k 토큰이라도, 두 번째 요청부터는 prefix 부분의 prefill 을 건너뛴다. 둘째 — 같은 prefix 를 쓰는 N 개 요청이 batch 안에 들어오면, attention 커널이 K/V 를 한 번만 read 한다 (FlashInfer 의 shared-prefix 모드와 결합).

구현이 까다로운 곳은 eviction. radix tree 노드를 LRU 로 자르면, 자식 노드까지 잘라야 cache 일관성이 깨지지 않는다. SGLang 은 reference count 기반의 변형 LRU 를 쓴다 — “현재 진행 중인 요청이 의존하는 노드는 자르지 않는다”.

SGLang 은 backend 만 있는 게 아니다. 같은 이름이 붙은 frontend DSL 이 있고, 이게 RadixAttention 을 효율적으로 쓸 수 있는 형태로 프로그램을 구조화하게 강제한다.

# SGLang frontend — sl.gen / sl.fork / sl.select
@sgl.function
def few_shot_qa(s, question):
    s += "You are a math tutor.\n"     # shared prefix
    s += "Q: 1+1?\nA: 2\n"             # shared examples
    s += "Q: 2*3?\nA: 6\n"
    s += "Q: " + question + "\nA: "     # branch point
    s += sgl.gen("answer", max_tokens=64)

# 1000개의 question 으로 호출 — system prompt 와 examples 의 KV 가
# 자동으로 radix tree 위에서 공유된다

SGLang scheduler 의 핵심 결정 — (a) request 의 reorder, (b) 메모리 budget 안에서 batch 크기 결정, (c) attention metadata 빌드 — 이 셋을 GPU forward 와 overlap 한다. 한 step 의 GPU 가 도는 동안, 그 다음 step 의 (a)~(c) 가 CPU thread 위에서 미리 끝난다.

overlap 이 가능한 이유는 단순하다 — step n 의 forward 가 끝나기 전에도, n+1 의 batch 구성은 (현재 진행 중인 요청들 + queue 에 쌓인 새 요청) 만으로 결정된다. n 의 출력 토큰 이 들어와야 하는 부분(EOS 검사, structured output mask 갱신)만 마지막에 갱신.

vLLM 이 사실상 표준이 된 시점에서 SGLang 이 등장한 이유. 강의에서 Yineng 이 직접 비교한 표를 정리한다 — 모든 항목에서 SGLang 이 우위는 아니지만, prefix sharing 과 frontend DSL 이 두드러진다.

정확한 입장 — vLLM 은 더 먼저 와 있고 더 많은 모델/하드웨어를 지원한다. SGLang 의 자리는 “같은 워크로드에서 throughput 1.5~2배 + 더 풍부한 frontend”. 회사가 OpenAI 호환만 필요하면 vLLM 이 보통 더 안전하고, multi-turn agent 워크로드처럼 prefix 공유가 큰 시나리오라면 SGLang 의 이득이 가시화된다.

structured output (JSON schema, regex) 은 매 토큰마다 vocabulary 위에 mask 를 만든다. 그 mask 비용이 무거운 경우, scheduling 의 overlap 으로 해결된다.

SGLang 의 명시적 결정 — “attention 커널은 우리가 짜지 않는다”. 대신 FlashInfer (L041) 를 first-class backend 로 묶고, fall-back 으로 Triton attention 을 둔다.

강의에서 Yineng 이 말한 한 줄 — “FlashInfer 의 다음 release 는 SGLang 에 약 10~20% 추가 성능을 가져올 것이다. 우리가 같이 작업 중이라.” 이 종속성이 강의의 자연스러운 다리가 — L041 으로 이어지는 자리.

Triton attention 이 fallback 으로 남는 이유 — 새 모델 / 새 GPU 로 처음 띄울 때 FlashInfer 의 binary 가 아직 빌드되지 않은 상태에서 동작 보장. 또한 Triton 은 customize 가 trivial 해서 디버깅 용도로도 유용.

강의의 마지막 절반에서 Yineng 이 언급한 production 사례들. 자세한 숫자는 NDA 로 막혀 있지만, 패턴은 분명하다 — agent / multi-turn / structured output 워크로드가 많은 곳일수록 SGLang 의 이득이 큼.

강의 시점 기준으로 SGLang 의 다음 단계 — (a) Hopper TMA 활용 강화, (b) FlashInfer 의 다음 release 와의 통합, (c) stream-K 류 SM 균등 분배 알고리즘. (c) 의 실험은 강의 시점에 이미 “예상보다 잘 된다” 는 측정.

SGLang 을 6개월 뒤 다시 마주했을 때 가장 빨리 복원해야 할 사실들과 — 직접 읽어볼 코드 위치들.

손에 새기기 — 실습 시퀀스

1. SGLang 띄우고 toy 모델 서빙 — Llama-3.2-1B 정도. --enable-radix-cache 명시 (default 지만). 첫 sanity.
2. same-prefix 워크로드 throughput — 같은 system prompt + 다른 question 1k 개. radix cache hit rate 와 throughput 측정. RadixAttention 의 이득이 보이는 가장 단순한 실험.
3. frontend DSL 로 self-consistency — sgl.fork(8) 로 같은 question 에 8개 답 생성. attention 커널이 K/V 를 한 번만 읽는지 메모리 트래픽으로 검증.
4. structured output 비용 비교 — JSON schema 강제 ON/OFF 에서 latency 차이. XGrammar 통합 의 효과.
5. scheduler overlap 끄기 — 환경변수로 v0 lockstep 으로 fall-back 시켜서 throughput 차이 직접 측정. overlap 의 값을 숫자로 손에 잡는다.
6. vLLM 과 같은 모델 비교 — 같은 GPU, 같은 모델, 같은 batch. throughput · TTFT (time-to-first-token) · TBT (time-between-tokens) 셋 다 본다.

L035 의 system 차원 최적화 가 다른 강의들의 어디에 다시 묶이는지.

강의에서 부분적으로만 등장한 주제, 후속 작업으로 비워둔 자리들.

• radix tree 의 page=1 vs page=N — 강의에서 page=1 이 hit rate 표준이라고 못 박았지만, 메모리 fragmentation 비용은 어느 정도? 실제 production 워크로드에서 page=4, page=8 의 trade-off 가 어디에 있는지.
• multi-LoRA 서빙 — 같은 base 모델 위 여러 LoRA adapter 의 KV 공유. RadixAttention 트리 안에서 LoRA boundary 가 prefix 의 일부가 되어야 한다는 게 자연스러운 답이지만, 강의에선 짧게만 다뤘다.
• chunked prefill 의 hyperparameter — chunk 크기와 attention metadata 빌드 비용의 trade-off. FlashInfer 의 다음 release 와 묶인 영역.
• multi-node 분산 — 강의는 single-node 에 집중. tensor parallel + pipeline parallel 분산이 RadixAttention 의 트리 동기화와 어떻게 합쳐지는지. cluster level 의 구조.
• speculative decoding 와의 관계 — draft model 의 KV 도 RadixAttention 트리 안에 두는가, 별도로 두는가. 강의에서 짧게만 언급됨.