11. vLLM·SGLang·TensorRT-LLM 비교 — 엔진을 안정적 개념 축으로 읽기

이 장의 핵심 질문

• 추론 엔진을 "어느 게 제일 빠른가"로 비교하면 왜 금방 낡고 틀리는가?
• vLLM·SGLang·TensorRT-LLM을 어떤 안정적 개념 축으로 나눠 봐야 오래가는가?
• "엔진 층"과 "서빙 층"(12장)은 왜 반드시 분리해야 하는가?

앞 장과의 연결 — 두 묶음(①②)을 거쳐 배포는 "SLO 계약을 지키는 서비스"가 됐다. 이제 그 서비스를 무엇으로 구현하는지를 다룬다. 단 이 안내서는 추천·점수가 아니라 비교 축과 조건을 다룬다(원칙 3·7). 선수 과정 ②의 엔진 아키텍처(스케줄러·배칭·KV)를 전제한다.

먼저: 왜 "제일 빠른 엔진" 질문이 함정인가

엔진 비교 자료는 대개 "X가 Y보다 N% 빠르다"는 벤치마크로 시작한다. 이 방식엔 두 문제가 있다.

1. 금방 낡는다 — 엔진은 빠르게 발전하고 표면 기능(연속 배칭·paged KV·FP8 양자화 등)이 서로 수렴한다. 오늘의 "N% 빠름"은 다음 버전에서 뒤집힌다.
2. 조건에 따라 뒤집힌다 — 같은 엔진이 워크로드(프리픽스 공유율·동시성·모델 크기)에 따라 이기기도 지기도 한다. 단일 숫자로는 이 조건 의존성을 담을 수 없다.

그래서 이 장은 "누가 빠른가"가 아니라, 버전이 바뀌어도 오래가는 개념 축으로 엔진을 나눈다. 축을 알면 새 벤치마크를 만나도 스스로 조건을 물을 수 있다.

⚠️ 경계 혼동 주의 — 표면 기능 수렴 — vLLM·SGLang·TensorRT-LLM은 모두 연속 배칭(continuous batching)·paged KV 캐시·FP8 양자화 같은 표면 기능을 갖췄다. "이 엔진은 연속 배칭을 지원한다"는 더 이상 구별점이 아니다. 진짜 차이는 메모리·컴파일 계층의 아키텍처 접근에 있다. 기능 목록 비교는 대체로 무의미하다.

안정적 개념 축 — 세 엔진의 아키텍처적 차이

세 엔진의 오래가는 구별점은 "KV 캐시와 실행을 어떻게 다루는가" 라는 아키텍처 철학이다.

vLLM — PagedAttention: KV를 가상 메모리처럼

vLLM의 핵심 아이디어는 PagedAttention이다. KV 캐시를 운영체제의 가상 메모리(virtual memory) 처럼 다뤄, 고정 크기 페이지로 쪼개 관리한다. 이렇게 하면 메모리 단편화(fragmentation)가 거의 사라져, 같은 하드웨어에 더 많은 요청을 촘촘히 배치할 수 있다. 개념적으로 "KV 메모리를 OS처럼 관리한다"가 vLLM의 정체성이다.

SGLang — RadixAttention: 공유 프리픽스 재사용

SGLang은 paged 메모리 위에 한 걸음 더 얹는다: RadixAttention. KV 캐시를 토큰 프리픽스를 키로 하는 radix tree(트라이) 에 저장해, 두 요청이 같은 앞부분(프리픽스)을 공유하면 그 계산을 자동으로 재사용한다. 08장의 프리픽스 캐시·09장의 지역성 개념이 엔진 아키텍처로 구현된 것이다. 수동 설정 없이 공유 프리픽스를 발견·재사용하는 것이 SGLang의 정체성이다.

TensorRT-LLM — 컴파일된 엔진: 하드웨어에 맞춰 굽기

TensorRT-LLM은 다른 접근을 택한다: 모델을 특정 NVIDIA GPU에 맞춰 컴파일된 실행 엔진으로 변환한다. Python 스케줄러가 PyTorch forward를 돌리는 대신, 커널 융합·자동 튜닝·CUDA 그래프를 담은 하드웨어 특화 실행 계획을 미리 굽는다. 유연성을 내주고 커널 수준 속도를 얻는다. "특정 하드웨어에 맞춰 컴파일한다"가 TensorRT-LLM의 정체성이다.

flowchart TB
    subgraph AXIS["안정적 개념 축 — KV·실행을 어떻게 다루는가"]
        V["vLLM<br/>PagedAttention<br/>KV를 가상 메모리처럼<br/>→ 단편화↓, 촘촘한 배치"]
        S["SGLang<br/>RadixAttention<br/>프리픽스를 radix tree로<br/>→ 공유 계산 자동 재사용"]
        T["TensorRT-LLM<br/>컴파일된 엔진<br/>하드웨어 특화 실행 계획<br/>→ 커널 속도, 유연성↓"]
    end

    classDef mem fill:#e9d8fd,stroke:#7c3aed,color:#000
    classDef reuse fill:#c4f1f4,stroke:#0891b2,color:#000
    classDef compile fill:#cfe2ff,stroke:#2563eb,color:#000
    class V mem
    class S reuse
    class T compile

📌 핵심 — 조건부 이득 — PagedAttention은 거의 모든 워크로드에서 메모리·처리량 이득을 준다(단편화 감소). RadixAttention은 그 위에 워크로드 의존적 이득을 더한다: 프리픽스가 겹치면 크고, 모든 요청이 고유하면 미미하다. TensorRT-LLM의 컴파일 이득은 NVIDIA 하드웨어·고정 형태에 특화될 때 크다. 어느 것도 "무조건 최고"가 아니며, 이득은 워크로드·하드웨어 조건에 달렸다.

🔬 증거 읽기 — 엔진 근거표 (확인일 2026-07-20)

conditions — 위 버전 번호는 특정 2차 자료의 특정 시점(2026-06) 스냅샷이며, 엔진은 빠르게 갱신되므로 실제 사용 시 각 프로젝트의 공식 저장소에서 최신 버전을 재확인해야 한다. does-not-support — 이 표는 "어느 엔진이 몇 % 빠르다"를 지지하지 않는다. 벤치마크 수치는 워크로드·하드웨어·동시성·설정에 강하게 의존하며, 2차 자료의 수치(예: "29% 높은 처리량", "TTFT p95 몇 ms")는 그 자료의 특정 조건에서만 유효하고 일반값이 아니다. 이 안내서는 그런 순위 수치를 옮기지 않는다.

⚠️ 경계 혼동 주의 — 2차 벤치마크 수치의 함정 — 비교 블로그들은 "SGLang이 29% 빠르다", "TensorRT-LLM p95 TTFT가 가장 낮다" 같은 수치를 제시한다. 이런 수치는 특정 모델·동시성·프리픽스 공유율·하드웨어의 산물이다. 같은 자료 안에서도 "고유 프롬프트로 측정했더니 RadixAttention 이득이 baseline 수준"이라고 단서를 단다. 조건이 다르면 뒤집힌다. 순위 숫자가 아니라 "어떤 조건에서 어떤 아키텍처가 유리한가"를 읽어라.

엔진 선택을 좌우하는 조건 (추천이 아니라 조건)

이 안내서는 특정 엔진을 추천하지 않는다. 대신 어떤 조건이 어떤 아키텍처를 유리하게 하는지를 정리한다. 판단은 각자의 워크로드로 프로파일링해야 한다.

• 프리픽스 공유율 — 멀티턴 대화·RAG·공통 시스템 프롬프트처럼 앞부분이 겹치면 RadixAttention(재사용)의 이득이 크다. 모든 요청이 고유하면 그 이득은 사라진다.
• 하드웨어 범위 — 여러 종류의 가속기를 쓰거나 NVIDIA 외 하드웨어가 있으면 컴파일 특화(TensorRT-LLM)의 벤더 종속이 제약이 된다.
• 운영 복잡도 허용치 — 컴파일 엔진은 모델 버전마다 컴파일 시간·설정 비용이 든다. 이를 감당할 여력이 있는지가 조건이다.
• 동시성·모델 크기 — 벤치마크 우열이 동시성 수준·모델 규모에 따라 달라진다(작은 모델과 큰 모델에서 순위가 다를 수 있음).

⚖️ 절충 — 유연성 vs 특화 — 컴파일 특화(TensorRT-LLM)는 특정 하드웨어에서 커널 속도를 얻지만 유연성·이식성·설정 편의를 내준다. 유연한 엔진(vLLM)은 넓은 하드웨어·쉬운 설정을 얻지만 특정 하드웨어의 마지막 성능을 일부 포기한다. RadixAttention(SGLang)은 재사용 이득을 얻지만 그 이득은 워크로드에 달렸다. "최고 엔진"은 없고, 워크로드·하드웨어·운영 제약의 함수만 있다.

엔진 층 ≠ 서빙 층 — 이 묶음의 핵심 경계

이 장에서 다룬 셋은 모두 추론 엔진(inference engine) 이다. 엔진은 단일 (다중 device) 실행 단위의 forward pass를 최적화한다: KV 관리, 배칭, 커널. 하지만 엔진 위에는 서빙 층(serving layer) 이 따로 있다(12장): 여러 엔진 인스턴스에 걸친 분산 조율 — PD 분리 오케스트레이션, KV-aware 라우팅, 다중 tier KV 관리, 오토스케일링.

이 경계를 섞으면 안 된다. 예를 들어 "PD 분리"는 엔진의 기능이라기보다 서빙 층이 여러 엔진을 배치·조율하는 방식에 가깝다(12장). "라우팅"도 엔진 안(모델 안 MoE 라우터, 05장)과 서빙 층(요청→워커, 09·12장)이 완전히 다르다.

flowchart TB
    subgraph SERVE["서빙 층 (12장) — 분산 조율"]
        DYN["Dynamo · llm-d 등<br/>PD 오케스트레이션·KV-aware 라우팅·<br/>다중 tier KV·오토스케일링"]
    end
    subgraph ENGINE["엔진 층 (이 장) — 단일 실행 단위 최적화"]
        E1["vLLM 인스턴스"]
        E2["SGLang 인스턴스"]
        E3["TensorRT-LLM 인스턴스"]
    end
    DYN -->|"엔진을 워커로 배치·조율<br/>(engine-agnostic)"| E1
    DYN --> E2
    DYN --> E3

    classDef serve fill:#c4f1f4,stroke:#0891b2,color:#000
    classDef eng fill:#cfe2ff,stroke:#2563eb,color:#000
    class DYN serve
    class E1,E2,E3 eng

📌 핵심 — 층 분리 — 엔진 층은 "한 실행 단위를 어떻게 빠르게", 서빙 층은 "여러 실행 단위를 어떻게 조율"이다. 서빙 층(Dynamo 등)은 보통 engine-agnostic하여 여러 엔진을 워커로 갈아 끼울 수 있다(12장에서 확인). 그래서 "엔진 선택"과 "서빙 층 선택"은 독립적 결정이다. 이 둘을 섞어 "Dynamo vs vLLM 중 뭐가 빠른가"라고 묻는 것은 층위를 혼동한 잘못된 질문이다.

배포에 엔진을 앉히다

배포 확장 — 앞 묶음에서 "SLO 계약을 지키는 서비스"가 된 배포의 팀은, 각 워커에 어떤 엔진을 쓸지 정한다. 프리픽스 공유가 많은 대화형 트래픽이면 RadixAttention 계열이, 다양한 하드웨어를 쓰면 유연한 엔진이 조건상 유리할 수 있다. 하지만 이 선택은 서빙 층 선택과 독립이며, 벤치마크 순위가 아니라 자기 워크로드 프로파일로 판단해야 한다. 다음 장(12)에서 이 엔진들을 조율하는 서빙 층을 다룬다.

이 장에서 배운 것

• 엔진을 "제일 빠른 것"으로 비교하면 금방 낡고 조건에 따라 뒤집힌다. 표면 기능(연속 배칭·paged KV·FP8)은 수렴했다.
• 오래가는 구별점은 아키텍처 축이다: vLLM의 PagedAttention(KV를 가상 메모리처럼), SGLang의 RadixAttention(프리픽스 재사용), TensorRT-LLM의 컴파일 엔진(하드웨어 특화).
• 각 이득은 조건부다: PagedAttention은 광범위, RadixAttention은 프리픽스 공유 시, 컴파일은 NVIDIA·고정 형태 시. "무조건 최고"는 없다.
• 2차 벤치마크의 순위 수치("N% 빠름")는 특정 조건의 산물이라 옮기면 안 된다. 버전 번호도 특정 시점 스냅샷일 뿐 계속 갱신된다.
• 엔진 층 ≠ 서빙 층: 엔진은 단일 실행 단위, 서빙 층(12장)은 여러 엔진의 분산 조율. 둘은 독립적 결정이며 섞으면 잘못된 질문이 된다.

🔎 이 장의 '지지하지 않는 결론' + 'unknown으로 남겨야 할 것'

• 지지하지 않는 결론 — "엔진 X가 엔진 Y보다 빠르다/낫다"는 이 장에서 지지되지 않는다. 우열은 워크로드·하드웨어·동시성·설정·버전에 달렸고, 이 안내서는 추천·점수를 하지 않는다.
• unknown으로 남길 것 — 특정 워크로드에서의 실제 엔진 우열, 최신 버전 번호, 특정 배포의 엔진 선택 근거는 그 조건·측정 없이는 unknown. 2차 자료의 벤치마크 수치는 원 조건이 다르면 옮기지 않는다.

✍️ 확인 문제

1. "연속 배칭을 지원한다"가 왜 더 이상 세 엔진의 구별점이 아닌가? 대신 어떤 아키텍처 축으로 나눠야 오래가는 비교가 되는지 세 엔진 각각의 정체성으로 답하라.

1. (조건 유형) 어떤 자료가 "SGLang이 vLLM보다 처리량 29% 높다"고 한다. 이 수치를 자기 배포에 그대로 적용하면 안 되는 이유를, RadixAttention 이득의 조건(프리픽스 공유율)과 "고유 프롬프트일 때 이득이 사라짐"을 근거로 설명하라.

1. (경계 혼동 유형) 동료가 "우리 서빙 층으로 Dynamo를 쓸지, 아니면 vLLM을 쓸지 고민이다"라고 한다. 이 질문의 층위 혼동을 지적하고, 엔진 층과 서빙 층이 왜 독립적 결정인지 바로잡아라.

다음 장에서는 이 엔진들을 조율하는 서빙 층(NVIDIA Dynamo·llm-d)을 다룬다. 서빙 층의 control path와 data path를 나누고, 엔진과의 경계를 명확히 하는 것이 초점이다.
다음 → 12. NVIDIA Dynamo와 llm-d — 서빙 층의 control/data path와 엔진 경계