제5부 추론 최적화와 서빙

5.15 오픈소스 서빙과 비교 — vLLM·SGLang vs 엔비디아 스택

5.15.1 이 장에서 배우는 것 / 선수 지식

제5부(5.1~5.14)에서 엔비디아 추론 스택을 쌓았다 — 컴파일·최적화(TensorRT·TensorRT-LLM)와 서빙(Triton). 그런데 LLM 추론에는 강력한 오픈소스 진영 — vLLM·SGLang(그리고 TGI 등) — 이 있고, 실무 선택은 거의 항상 "엔비디아 스택 vs 오픈소스"의 저울질이다. 이 장은 제5부를 닫으며 그 둘을 정직하게 비교한다.

핵심 통찰을 미리 확정한다: 둘은 같은 사면체(5.1)를 같은 핵심 기법으로 푼다. 페이지드 KV·연속 배칭·양자화·speculative는 양쪽이 다 가졌고(5.7~5.10, 상당수는 오픈소스가 대중화) 빠르게 수렴 중이다. 차이는 기법의 유무가 아니라 설계·통합·성숙도·운영 모델에 있다 — 그래서 "어느 것이 빠르냐"는 슬라이드가 아니라 당신 모델·하드웨어·워크로드로 실측해야 답이 나온다.

배우는 것:

vLLM(페이지드 어텐션·연속 배칭·OpenAI 호환)과 SGLang(RadixAttention prefix 공유·구조적 생성)의 설계·강점.
엔비디아 스택(TRT-LLM + Triton)과 오픈소스의 비교 축 — 최고 성능·모델 지원 속도·사용성·이식성·통합·빌드 비용.
엄밀한 양자택일이 아님 — TRT-LLM·vLLM을 Triton 백엔드로, NIM이 이들을 감쌈(6.7).
공정한 벤치마크 방법 — 같은 모델·하드웨어·워크로드로 tokens/s·TTFT·TPOT·p99·$/토큰을 재는 법.
선택 의사결정 프레임과, 정직성(고정 승자 없음, 시점·버전 의존).

선수 지식: 5.1(사면체·지표·배포 선택), 5.7~5.10(TRT-LLM·KV·인플라이트 배칭·speculative), 5.8(페이지드 KV·연속 배칭 — 오픈소스와 공유), 5.11~5.14(Triton), 6.7(NIM — 다음 부에서 이들을 감쌈). 이 장은 도구 실습보다 비교·의사결정 중심.

정직: 이 분야는 이 책에서 가장 빠르게 변한다. vLLM·SGLang·TRT-LLM의 기능·성능·모델 지원은 주 단위로 바뀐다. 이 장은 고정 성능 수치나 "승자"를 제시하지 않는다 — 설계 철학·비교 축·실측 방법을 가르친다. 특정 모델·시점의 우열은 반드시 당신이 직접 벤치마크해 확인하라("시점 의존, 확인 필요").

5.15.2 같은 사면체, 같은 핵심 기법

먼저 공통점을 분명히 하자 — 그래야 실질적 차이가 보인다. LLM 추론의 핵심 기법은 양 진영이 수렴했다:

기법(5.7~5.10)	엔비디아(TRT-LLM)	오픈소스(vLLM/SGLang)
페이지드 KV	○	○ (vLLM이 대중화)
연속/인플라이트 배칭	○	○
prefix KV 공유	○	○ (SGLang RadixAttention)
양자화(FP8·INT4 등)	○	○
speculative decoding	○	○
텐서/파이프라인 병렬	○	○
OpenAI 호환 API	○(NIM/프런트)	○

핵심: 기법은 거의 공통이다. 페이지드 어텐션·연속 배칭은 오히려 오픈소스(vLLM)가 대중화했고 엔비디아가 흡수했다(5.8에서 정직하게 명시했듯). 그러니 "엔비디아만 페이지드 KV가 있다" 같은 마케팅은 틀렸다. 실질적 차이는 다음 절들의 설계·통합·성숙도다.

5.15.3 오픈소스 진영 — vLLM·SGLang

vLLM.

대표 기여: PagedAttention(KV를 페이지로 관리, 5.8)을 대중화. 연속 배칭 기본.
사용성: pip install·HuggingFace 모델 바로 로드·OpenAI 호환 서버를 몇 줄로. 진입이 매우 쉽다.
모델 지원 속도: 새 오픈웨이트 모델이 나오면 빠르게 지원(커뮤니티). 빌드·컴파일 단계 없음.
하드웨어: NVIDIA 중심이나 다른 가속기 백엔드도 확장 중(시점 의존).
양자화·기능: FP8·INT4(AWQ/GPTQ 등)·speculative·prefix caching 등 지원(버전 의존).

SGLang.

대표 기여: RadixAttention — KV를 접두 트리(radix tree) 로 관리해 prefix 공유를 극대화(공통 시스템 프롬프트·few-shot·분기 생성에 강함).
구조적 생성: 정규식·문법 제약·JSON 등 구조화 출력과 프로그래밍 가능한 프런트엔드 언어.
강점 워크로드: prefix 재사용이 많은 경우(에이전트·다중 호출·공유 문맥), 구조적 디코딩.

TGI(Text Generation Inference) 등 다른 서버도 있다(연속 배칭·양자화). 공통적으로 LLM 특화·간편·빠른 모델 지원이 오픈소스의 색깔이다.

요지: 오픈소스는 "빠르게 기동하고·새 모델을 빨리 쓰고·간편" 에 강하다. vLLM은 범용 LLM 서빙의 사실상 표준에 가깝고, SGLang은 prefix 공유·구조적 생성에서 독특한 강점을 가진다.

5.15.4 비교 축 — 무엇이 실제로 다른가

기법이 공통이라면 차이는 어디에? 여섯 축으로 본다.

축	엔비디아(TRT-LLM + Triton)	오픈소스(vLLM/SGLang)
최고 성능(NVIDIA GPU)	FP8/FP4·트랜스포머 엔진·커널 최적화 흡수 빠름 → 특정 모델·세대서 우위 가능	매우 경쟁적, 케이스별. 빌드 없이도 빠름
모델 지원 속도	변환·빌드 필요 → 신모델 지원에 시간차 가능	빠름(HF 바로, 커뮤니티)
사용성·설치	컨테이너·빌드·config 학습 곡선	pip·몇 줄, OpenAI API 즉시
빌드/컴파일 비용	엔진 빌드(오프라인)·버전 관리(5.2·5.7)	컴파일 없음(모델 바뀌어도 재빌드 불필요)
이식성	NVIDIA GPU 특화	다중 하드웨어 확장 가능(시점 의존)
통합·운영	Triton 다중 프레임워크·다중 모델·메트릭, NIM·엔터프라이즈 지원	LLM 단일에 간결, 비-LLM·다중 모델은 약함

읽는 법:

엔비디아의 색깔: 최신 하드웨어 기능(FP8/FP4·TMA·트랜스포머 엔진, 4.2~4.4)을 빨리·깊이 흡수하고, Triton으로 비-LLM 포함 다중 모델을 통합 운영하며, 엔터프라이즈 지원·NIM(6.7)이 있다. 대가는 빌드·버전 관리·설정 비용.
오픈소스의 색깔: 빠른 모델 지원·간편·컴파일 없음·커뮤니티. 대가는 최신 하드웨어 기능 흡수가 다소 늦거나(시점 의존), 다중 프레임워크·엔터프라이즈 통합이 약함.

핵심: "성능 우위"는 모델·세대·워크로드·버전마다 뒤집힌다. 어느 한쪽이 항상 빠르지 않다 — FP8 트랜스포머는 TRT-LLM이, 신모델 즉시 지원·prefix 공유는 오픈소스가 유리한 식. 고정 결론을 외우지 말고 실측(5.15.6).

5.15.5 양자택일이 아니다 — 조합·NIM

흔한 오해: "TRT-LLM 아니면 vLLM 중 하나만". 실제로는 섞고 감쌀 수 있다.

그래서 실무 선택은 "둘 중 하나"가 아니라 "어떤 계층을 무엇으로 채우나" 다:

엔진/런타임: TRT-LLM vs vLLM vs SGLang — 성능·모델 지원·기능으로.
서빙·운영: Triton(다중 모델·메트릭) vs 각자의 내장 서버 vs NIM(완제품).
이 조합을 워크로드로 실측해 정한다.

견해: 빠른 출시·신모델·간편이 우선이면 vLLM(또는 SGLang)으로 시작, NVIDIA GPU 최대 성능·FP8·다중 모델 운영·엔터프라이즈가 우선이면 TRT-LLM + Triton(또는 NIM). 그리고 둘을 같은 워크로드로 벤치마크해 비용/지연으로 결정하는 것이 정석이다. 초기 vLLM → 안정화 후 TRT-LLM/NIM 전환(또는 그 반대)도 흔하다.

5.15.6 워크스루 — 공정한 벤치마크

"어느 것이 빠르냐"는 반드시 같은 조건으로 직접 측정한다. 공정한 비교의 체크리스트.

   동일하게 맞출 것(안 맞추면 비교 무효):
     · 같은 모델·가중치(같은 양자화 수준 — FP16 vs FP16, FP8 vs FP8)
     · 같은 GPU·같은 수·같은 병렬도(TP/PP)
     · 같은 워크로드: 입력/출력 시퀀스 '분포'(평균만 X — 분포!), 동시성(부하)
     · 같은 측정: tokens/s(입력·출력 구분), TTFT, TPOT, p99, $/1M토큰
     · 워밍업 후 측정, 충분한 샘플, 동일 디코딩 파라미터(온도·max_tokens)

측정 도구·절차(개략):

# 오픈소스(vLLM 예): OpenAI 호환 서버 기동하고 부하 생성
#   (명령·옵션 버전 의존)
python -m vllm.entrypoints.openai.api_server --model <hf_model> --tensor-parallel-size 8
# 벤치마크: vLLM 제공 벤치 스크립트 또는 genai-perf 등으로 동시성 스윕

# 엔비디아(TRT-LLM + Triton): 5.7~5.14대로 빌드·서빙 후
#   genai-perf(또는 perf_analyzer)로 같은 워크로드 부하
genai-perf profile -m <model> --service-kind triton \
    --concurrency-range 1:64 ...        # 옵션 버전 확인

# 두 결과를 같은 축(tokens/s vs p99, $/토큰)으로 비교
#   → SLA(p99) 제약 하 처리량·비용이 나은 쪽. 모델·시퀀스대마다 다를 수 있음.

해석:

단일 지표로 단정 금지: tokens/s만 보면 p99가 숨는다. SLA 제약 하 goodput·$/토큰(5.1)으로.
시퀀스 분포에 민감: 짧은 프롬프트·긴 생성 vs 긴 프롬프트(RAG)·짧은 생성에서 우열이 다르다.
prefix 공유 워크로드: 공통 시스템 프롬프트·에이전트가 많으면 SGLang(RadixAttention)이 유리할 수 있다 — 워크로드를 반영해 측정.
버전 고정·기록: 각 런타임의 버전·설정을 기록(재현). 다음 분기에 결과가 뒤집힐 수 있음을 전제.

5.15.7 중간 점검 (체크포인트)

[ ] 엔비디아 스택과 오픈소스가 같은 사면체·같은 핵심 기법을 공유하며(페이지드 KV·연속 배칭 등 오픈소스가 대중화) 수렴 중임을 안다.
[ ] vLLM(페이지드 어텐션·간편·모델 지원)·SGLang(RadixAttention prefix 공유·구조적 생성)의 강점을 제시한다.
[ ] 비교 6축(최고 성능·모델 지원 속도·사용성·빌드 비용·이식성·통합)으로 두 진영의 색깔을 설명한다.
[ ] 양자택일이 아님(vLLM/TRT-LLM을 Triton 백엔드로, NIM이 감쌈)을 안다.
[ ] 공정한 벤치마크(같은 모델·HW·워크로드 분포·SLA 제약 goodput·$/토큰)를 설계한다.
[ ] "고정 승자 없음 — 시점·모델·워크로드 의존"을 받아들이고 실측으로 결정한다.

증상→의심: "X가 Y보다 빠르다"는 글을 그대로 믿음 → 조건(모델·HW·시퀀스·버전·정밀도) 확인 → 내 워크로드로 재측정. 벤치마크가 불규칙 → 시퀀스 분포·정밀도·동시성 불일치 → 조건 통제. 신모델이 TRT-LLM에서 안 됨 → 변환·지원 시간차 → vLLM로 우선 출시 후 전환. prefix 많은데 처리량 낮음 → prefix 공유 미활용 → SGLang/KV reuse(5.8). 비-LLM도 많은데 vLLM만 → 다중 모델 운영 → Triton 통합 고려.

5.15.8 트레이드오프·대안 — 선택 프레임

우선순위	기우는 쪽	이유
빠른 출시·신모델 즉시·간편	vLLM(또는 SGLang)	pip·HF·OpenAI API, 컴파일 없음, 커뮤니티
prefix 공유·구조적 생성·에이전트	SGLang	RadixAttention·문법 제약
NVIDIA GPU 최고 성능·FP8/FP4	TRT-LLM	최신 HW 기능 흡수·커널
다중 모델·비-LLM 포함·메트릭·엔터프라이즈	Triton(+TRT-LLM) / NIM	통합 운영·지원
운영 안 하고 완제품 API	NIM(6.7)	TRT-LLM을 표준 API 컨테이너로
멀티-하드웨어 가능성	오픈소스	이식성 확장 중

견해: 단일 LLM·빠르게면 vLLM/SGLang, NVIDIA GPU 대규모·최고 성능·다중 모델·엔터프라이즈면 TRT-LLM+Triton(또는 NIM). 결정 불가하면 둘을 같은 워크로드로 벤치마크(5.15.6)해 SLA 하 비용/지연으로. 기법은 수렴하므로 "생태계·운영·지원·이식성" 같은 비기능 요소가 점점 더 결정적이다 — 순수 성능 격차는 좁아지고 버전마다 뒤집힌다.

비엔비디아 정직: 이 장 자체가 정직성의 실천이다. 오픈소스가 핵심 기법을 대중화·선도한 부분이 많고(페이지드 어텐션·연속 배칭·RadixAttention), 성능 우열은 시점·모델·워크로드 의존이다. 엔비디아 스택의 지속적 강점은 최신 실리콘 기능(FP8/FP4·트랜스포머 엔진)의 빠른 흡수, 다중 프레임워크 통합(Triton), 엔터프라이즈 패키징(NIM·지원) 이다. 어느 쪽도 항상 옳지 않다 — 워크로드로 측정하고, 결과의 유효기간이 짧음을 전제하라.

5.15.9 흔한 함정

벤치마크 슬라이드를 그대로 믿음. 조건(모델·HW·시퀀스 분포·정밀도·버전)이 다르면 무의미. 내 워크로드로 재측정.
tokens/s만 비교. p99·goodput·$/토큰을 빠뜨리면 SLA 위반 처리량을 "빠르다"고 착각(5.1). SLA 제약 하로.
정밀도·병렬도 불일치 비교. FP8 vs FP16, TP8 vs TP4를 섞어 비교하면 무효. 같은 조건.
시퀀스 분포 무시. 짧은 생성 vs 긴 RAG에서 우열이 다르다 — 실제 분포 반영.
양자택일로 봄. vLLM/TRT-LLM을 Triton에, NIM이 감쌈 — 계층별 조합이 가능.
"항상 X가 빠르다"고 외움. 버전마다 뒤집힌다. 결과에 유효기간을 둔다.
prefix 공유 워크로드에 일반 서빙. 공통 프롬프트·에이전트가 많으면 RadixAttention/KV reuse가 큰 차이 — 워크로드 특성을 반영.
신모델 지원 시간차 간과. 막 나온 모델은 오픈소스가 먼저 지원할 수 있다 — 출시 속도가 중요하면 고려.

5.15.10 연습문제

연습 1 (공통 vs 차이). "엔비디아 TRT-LLM만 페이지드 KV와 연속 배칭이 있어 빠르다"는 주장을 반박하고, 두 진영의 실질적 차이가 어디에 있는지 설명하라.

정답

반박: 페이지드 어텐션·연속 배칭은 오픈소스(vLLM)가 대중화했고 양 진영이 모두 가진 공통 기법이다(5.8에서 명시). 따라서 "엔비디아만 있다"는 틀렸다. 실질적 차이: ① 최신 하드웨어 기능 흡수 속도(FP8/FP4·트랜스포머 엔진은 TRT-LLM이 빠름), ② 모델 지원 속도(신모델은 vLLM/오픈소스가 빠름), ③ 사용성·빌드 비용(오픈소스는 컴파일 없음·pip, TRT-LLM은 빌드·버전 관리), ④ 통합 운영(Triton 다중 프레임워크·메트릭·엔터프라이즈), ⑤ 이식성(오픈소스 멀티-HW). 기법은 수렴했으니 비기능 요소가 결정적. 성능 우열은 모델·세대·워크로드·버전 의존.

연습 2 (워크로드 매칭). 다음에 vLLM·SGLang·TRT-LLM+Triton 중 무엇을 우선 검토할지와 이유: (a) 막 공개된 신규 오픈웨이트 모델을 다음 주 출시, (b) 공통 시스템 프롬프트를 모든 요청이 공유하는 에이전트 서비스, (c) Hopper GPU에서 고정 모델을 FP8로 대규모·저비용.

정답

(a) vLLM(또는 SGLang) — 신모델은 오픈소스가 빠르게 지원하고 컴파일 없이 HF에서 바로 로드, 다음 주 출시에 부합. TRT-LLM은 변환·지원 시간차 위험. (b) SGLang — RadixAttention으로 공통 prefix KV 공유를 극대화, 공통 시스템 프롬프트·에이전트 다중 호출에서 prefill·메모리 절감. (vLLM도 prefix caching 있으나 SGLang이 이 패턴에 특화.) (c) TRT-LLM + Triton(또는 NIM) — Hopper FP8·트랜스포머 엔진을 깊이 흡수, 고정 모델이라 빌드 비용이 상각되고 대규모·저비용·다중 모델 운영에 적합. 모두 실측 비교로 확정.

연습 3 (공정 벤치마크). 동료가 "vLLM이 우리 TRT-LLM보다 tokens/s가 높으니 바꾸자"고 한다. 이 비교를 신뢰하기 전 확인할 조건 다섯과, tokens/s 외에 봐야 할 지표를 제시하라.

정답

확인 조건: ① 같은 모델·가중치·양자화 수준(FP8 vs FP16 비교는 무효), ② 같은 GPU·수·병렬도(TP/PP), ③ 같은 입력/출력 시퀀스 분포(평균이 아니라 분포 — 짧은 생성 vs 긴 RAG), ④ 같은 동시성·디코딩 파라미터(온도·max_tokens), ⑤ 워밍업·충분한 샘플·버전 기록. tokens/s 외 지표: p99 TTFT/TPOT(SLA), goodput(SLA 만족 처리량 — tokens/s가 높아도 p99 위반이면 무의미), $/1M토큰(비용), 동시 요청 수. 결론: 조건을 통제해 SLA 제약 하 goodput·비용으로 비교해야 하며, 한쪽 tokens/s 수치만으로 결정하면 안 된다. 그리고 결과는 버전·워크로드 의존이라 유효기간이 짧다.

연습 4 (조합). "TRT-LLM과 vLLM 중 하나만 골라야 한다"는 전제가 왜 틀렸는지, 계층 관점에서 가능한 조합을 셋 이상 들어라.

정답

틀린 이유: 엔진/런타임과 서빙/운영은 분리된 계층이라 섞을 수 있다. 조합: ① TRT-LLM을 Triton 백엔드로(tensorrtllm 백엔드, 5.11~5.14) — 표준. ② vLLM을 Triton 백엔드로(vllm 백엔드) — Triton의 다중 모델·메트릭 + vLLM 엔진. ③ NIM(6.7)이 TRT-LLM(또는 vLLM)을 OpenAI 호환 컨테이너로 감쌈 — 내부를 몰라도 표준 API. ④ 비-LLM은 Triton, LLM은 vLLM/SGLang 자체 서버를 한 클러스터에서 공존. ⑤ 초기 vLLM(빠른 출시) → 안정화 후 TRT-LLM/NIM 전환. 즉 결정은 "엔진을 무엇으로, 서빙을 무엇으로"의 계층별 선택이며 워크로드로 실측해 조합한다.

연습 5 (정직성). 이 책이 "TRT-LLM이 항상 가장 빠르다"고 단정하지 않는 이유를, 기법 수렴·시점 의존·비기능 요소 관점에서 설명하고, 독자가 가져야 할 태도를 제시하라.

정답

이유: ① 기법 수렴 — 페이지드 KV·연속 배칭·양자화·speculative를 양 진영이 모두 가졌고(오픈소스가 일부 선도) 격차가 좁다. ② 시점·워크로드 의존 — 성능 우열이 모델·GPU 세대·시퀀스 분포·버전마다 뒤집힌다(FP8 트랜스포머는 TRT-LLM, 신모델 즉시 지원은 오픈소스). 주 단위로 변한다. ③ 비기능 요소 — 사용성·모델 지원 속도·이식성·통합·지원이 순수 성능만큼 중요. 독자 태도: 고정 승자를 외우지 말고, 자신의 모델·하드웨어·워크로드로 SLA 제약 하 goodput·$/토큰을 직접 측정하며, 결과에 유효기간을 두고 주기적으로 재평가한다. 마케팅 수치가 아니라 자기 측정을 신뢰한다.

5.15.11 요약 · 다음 장(제5부 마무리)

엔비디아 스택(TRT-LLM·Triton)과 오픈소스(vLLM·SGLang)는 같은 사면체(5.1)를 같은 핵심 기법으로 푼다 — 페이지드 KV·연속 배칭·양자화·speculative는 공통이고(오픈소스가 일부 대중화) 수렴 중.
vLLM: 페이지드 어텐션·연속 배칭·간편·빠른 모델 지원·OpenAI API. SGLang: RadixAttention prefix 공유·구조적 생성. 오픈소스의 색깔은 빠르고 간편.
엔비디아의 색깔: 최신 HW 기능(FP8/FP4·트랜스포머 엔진) 빠른 흡수·Triton 다중 모델 통합·NIM·엔터프라이즈. 대가는 빌드·버전·설정 비용.
양자택일이 아니다 — vLLM/TRT-LLM을 Triton 백엔드로, NIM이 감쌈. 결정은 계층별 선택 + 워크로드 실측.
공정한 벤치마크: 같은 모델·HW·시퀀스 분포·정밀도·병렬도로, SLA 제약 하 goodput·$/토큰을 측정. 고정 승자 없음 — 시점·워크로드 의존, 직접 측정.
제5부(추론 최적화·서빙, 5.1~5.15) 완료. 사면체에서 출발해 TensorRT(컴파일·정밀도·플러그인) → TensorRT-LLM(KV·배칭·병렬·speculative) → Triton(리포지토리·배칭·인스턴스·파이프라인·운영) → 오픈소스 비교까지, "학습된 모델을 SLA 안에서 비용이 낮고 빠르게 서비스하는" 전 계층을 손에 익혔다.

다음 장: 6.1 생성형 AI 라이프사이클 개관 — 제6부(생성형 AI 플랫폼) 의 시작. 지금까지의 "모델을 최적화·서빙"에서 한 단계 올라가, 데이터 큐레이션 → 학습·커스터마이즈(NeMo) → 정렬 → 배포(NIM) → RAG·에이전트의 생성형 AI 전체 라이프사이클과 엔비디아 플랫폼(NeMo·NIM·NeMo Retriever·Guardrails)의 지형을 세운다. 이 장에서 비교한 TRT-LLM·Triton·NIM이 그 배포 계층으로 다시 등장한다.