《GPU Mode》
L100
2025 · OSS Inference
High priority
transcript · failed
InferenceX — Continuous OSS Inference Benchmarking
vLLM, SGLang, TensorRT-LLM, llama.cpp, LMDeploy, MLC-LLM 의 한 주 전 성능을 어떻게 신뢰성 있게 비교할 것인가. 매주 자동으로 도는 대규모 OSS inference benchmark suite 의 설계와 metric, 자동화 파이프라인, leaderboard 의 운영. 강의 자막은 실패했지만, 같은 자리에서 도는 OSS benchmark 들의 디자인 — vLLM benchmarks, SGLang bench, MLPerf Inference, NVIDIA gaiacomp — 을 근거로 재구성한 학습 노트.
vLLM
SGLang
TensorRT-LLM
leaderboard
TTFT
TPOT
throughput
CI / scheduled run
K
Speakers
Kimbo Chen · Cam Quilici · Bryan Shan
InferenceX team · 확인 필요
§ 01강의가 풀려는 문제· OSS benchmark 의 baseline 부재
“이번 주 vLLM 이 SGLang 보다 빠른가” 에 누가 답할 것인가
OSS LLM inference 엔진은 — vLLM · SGLang · TensorRT-LLM · llama.cpp · LMDeploy · MLC-LLM — 매주 큰 변경을 commit 한다. 한 주 전의 비교가 다음 주에는 무효. 그런데 “방금 release 된 vLLM v0.6.x 는 같은 모델 / 같은 GPU 에서 SGLang v0.4.x 보다 빠른가” 에 답할 수 있는 신뢰성 있는 단일 source 가 사실상 없다.
강의가 던지는 세 개의 질문.
- OSS inference engine 들의 성능을 통일된 프로토콜로 측정하는 시스템을 어떻게 만드는가 — 각 엔진의 native interface 를 고려하면서.
- 이 측정을 매주 / 매일 자동으로 갱신하면서 결과를 신뢰할 만하게 유지하는가 — GPU 변동성, kernel 변동성, network 변동성을 다 흡수하면서.
- 비교 결과를 사람이 직관적으로 읽을 수 있게 어떻게 노출하는가 — leaderboard, dashboard, API.
강의의 인지적 frame
“Continuous benchmarking 은 CI 다” — InferenceX 의 핵심 frame. unit test 가 코드의 정확성을 매 commit 마다 확인하듯, inference benchmark 가 시스템의 성능을 매 release 마다 확인. 두 stack 의 기술적 요구사항은 거의 같다 — automation, reproducibility, alerting.
“OSS engine 들은 빠르게 진화한다. 어제의 leaderboard 가 오늘은 거짓. 그래서 continuous 가 필요하다.”학습 노트 · 확인 필요
§ 02OSS inference 의 baseline 확보 어려움· 왜 이걸 매주 돌려야 하는가
“같은 GPU, 같은 모델, 다른 엔진” 의 대조표가 의외로 안 만들어진다
비교를 직접 해보려고 하면 알게 되는 사실들 — 각 엔진의 launch 인터페이스, prompt 구조, 측정 metric 정의, GPU 사양 표기법이 모두 다르다. “공정한 비교” 가 사실상 인프라 문제다.
- 엔진마다 다른 launch 방법 — vLLM 의
vllm serve, SGLang 의 sglang.launch_server, TensorRT-LLM 의 trtllm-build 후 trt 엔진 build, llama.cpp 의 ./server. 같은 행동을 위해 4 가지 명령어.
- prompt format 의 변동 — chat template, system prompt, max tokens 의 default 값이 엔진마다 다름. 결과의 작은 perplexity 차이가 누적되면 throughput 에 영향.
- quantization 표기 — FP16/BF16/FP8/INT8/INT4 의 “default” 가 엔진마다 다르고, 같은 “FP8” 도 e4m3 인지 e5m2 인지 표기 안 됨.
- 측정 metric — TTFT 를 client 에서 잴 것인가 server 에서 잴 것인가. TPOT 의 분모는 generated tokens 인가 total tokens 인가. 차이가 30% 이상일 수 있음.
- warmup — 첫 request 는 거의 항상 outlier (kernel cache 가 비어 있음). warmup 횟수가 엔진마다 달라야 fair.
이 모든 차이를 정리해 한 protocol 로 rerun 가능한 하니스를 만드는 게 — 사실 이 강의의 절반 이상의 무게중심.
§ 03InferenceX 설계· infra · runner · storage
한 batch run 의 anatomy
전체 시스템은 다섯 단계의 파이프라인으로 잘린다. 각 단계가 분리되어 있어 한 단계 실패가 전체를 죽이지 않는다 — CI 의 표준 패턴.
FIG · InferenceX 의 한 주간 흐름weekly run pipeline
01
Detect
각 엔진 repo 의 last release tag 를 polling. 새 tag 가 잡히면 trigger.
02
Build / Pull
Docker image 를 build 또는 official image pull. CUDA / driver 버전을 일치.
03
Run on isolated GPU
A100 · H100 · L40S · 4090 · MI300 등 fleet 위에서 동일 workload 실행. 한 GPU 에 한 run.
04
Collect metrics
TTFT · TPOT · throughput · GPU mem · server CPU 모두 수집. JSON 으로 남김.
05
Publish
leaderboard DB 에 commit. 직전 주와 비교해 regression 감지 시 alert.
이 5 단계가 매주 자동으로 돈다. 사람의 개입은 — alert 가 떴을 때 — “regression 을 upstream 에 알릴 것인가” 결정하는 한 자리만.
isolation 의 중요성
한 host 에 두 엔진을 동시에 띄우면 GPU memory pressure 와 host CPU contention 으로 서로 영향을 준다. 한 run = 한 GPU 전용이 InferenceX 류 시스템의 표준. 이게 fleet 비용을 만들어내지만 결과의 reproducibility 가 보장된다.
§ 04metric 정의· TTFT · TPOT · throughput
“ms” 라고 같은 단위지만 정의에 따라 30% 차이가 나는 자리들
LLM inference 의 표준 metric 은 셋 — TTFT (Time-To-First-Token), TPOT (Time-Per-Output-Token), throughput (tokens/sec). 정확한 정의가 있어야 비교가 의미 있다.
FIG · 한 request 의 timeline 위 metric 분해client 시점
request
prefill (TTFT)
decode (TPOT × N tokens)
batch concur
prefill
queue
batched decode
single-stream 에서는 TTFT 와 TPOT 가 깨끗하지만, concurrent batch 에서는 — 같은 request 가 다른 request 와 묶여서 — TPOT 가 늘고 throughput 은 늘어난다. 두 영역 모두 측정해야 latency-sensitive vs throughput-sensitive 를 구분 가능.
METRIC 01
TTFT · Time-To-First-Token
request 발송 시점 → 첫 token 수신 시점. chat 응답성의 직접 지표. server-side prefill 시간 + queue + network. median 과 P99 둘 다 보고해야 한다.
METRIC 02
TPOT / ITL · 토큰 간 시간
두 번째 token 부터의 token 간 평균 시간. decode loop 의 효율을 본다. continuous batching 의 성능이 여기서 드러남. tail latency 가 중요 — 한 token 이 50ms 늦으면 전체 streaming 이 끊긴다.
METRIC 03
Throughput
전체 시스템의 tokens/sec. concurrency 와 같이 봐야 의미. tokens/sec @ N=64 같은 표기. SLA 주변에서의 throughput 이 production 의 진짜 지표.
METRIC 04
SLA-throughput frontier
“TPOT P95 < 50ms 를 만족하면서 가장 높은 throughput”. 단순한 max throughput 보다 production 친화적. 두 metric 의 조합으로 plot.
METRIC 05
GPU memory peak
실제 점유한 max VRAM. KV cache 정책에 따라 큰 차이. OOM 직전까지 가는 엔진이 throughput 에 유리하지만 안전 마진이 작음.
METRIC 06
Cost per 1M tokens
throughput × GPU price × time. 동일 GPU + 다른 엔진 비교의 가장 직관적 metric. cloud 가격 변동을 흡수하기 위해 GPU-hour 기준으로 정규화.
§ 05자동화 파이프라인· image · workload · runner · storage
매주 도는 하니스의 부품
자동화 stack 은 다섯 부품으로 뜯어 본다. 각 부품의 책임이 깔끔하게 분리되어 있어야 — 한 엔진이 추가될 때 다른 부품을 안 건드린다.
엔진 image
Dockerfile per engine. official image 가 있으면 사용, 없으면 fork 의 release tag 로 build. CUDA 버전은 image base 가 결정.
workload spec
YAML 파일. 모델 (Llama-3.1-8B-Instruct, Qwen2.5-7B-Instruct, ...), max-context, prompt distribution (ShareGPT-style), concurrency level, total requests.
runner
Python orchestrator. image 띄우고 → warmup → 측정 → cleanup. timeout 과 retry 로직. failure 도 metadata 로 기록.
load generator
async HTTP client. concurrency level 을 내부에서 관리. 각 request 의 client-side TTFT/TPOT/throughput 를 정확히 측정.
storage
PostgreSQL or BigQuery. (engine, version, model, gpu, timestamp, metric, value) 의 long-format. analytics 친화적.
scheduler
cron / Airflow / Dagster. 매주 / 매 release 의 trigger. fleet 의 GPU 가용성을 고려해 queue.
alerting
한 엔진의 throughput 이 직전 release 대비 -10% 이상 떨어지면 alert. upstream maintainer 에 자동으로 알림 (확인 필요).
leaderboard frontend
React / Next.js. 같은 모델 / 같은 GPU 에서의 cross-engine 비교, 시간축 (history) 비교, regression 표시.
§ 06leaderboard· 표시와 비교 UX
“가장 빠른 엔진은?” 에 답하는 표
leaderboard 는 단순한 표가 아니다 — 한 엔진의 “빠르다” 가 다른 엔진에서 어느 차원인지 (TTFT? throughput? cost?) 가 즉시 보여야 한다. 한 모델 / 한 GPU 의 한 케이스를 표로 풀면 다음 모양.
FIG · Llama-3.1-8B · H100 80GB · 예시 (확인 필요)concurrency = 64
RK
엔진 / 버전
TTFT P50
TPOT P95
Throughput
변화
1
SGLang v0.4.x
120 ms
22 ms
9.2k tok/s
+8%
2
vLLM v0.6.x
130 ms
25 ms
8.5k tok/s
+3%
3
TRT-LLM 0.13
95 ms
21 ms
8.1k tok/s
±0%
4
LMDeploy v0.6
140 ms
28 ms
7.0k tok/s
+5%
5
MLC-LLM nightly
160 ms
32 ms
5.8k tok/s
-2%
6
llama.cpp b3xxx
220 ms
40 ms
3.1k tok/s
+1%
이런 표 한 장이 — “이번 주 SGLang 이 가장 throughput-friendly, TRT-LLM 이 가장 latency-friendly” — 같은 사실을 한눈에 답한다. 위 수치는 오픈된 community benchmarks 의 일반적 경향을 정리한 예시이며 실제 InferenceX 결과는 별도. (확인 필요)
좋은 leaderboard 의 두 가지 부가 기능 — history (한 엔진의 시간 축 추이) 와 delta highlight (직전 release 대비 +/-). 사람은 “현재 순위” 보다 “변화” 에 반응하는 게 보통이다. SGLang 이 v0.3 → v0.4 에서 +8% 가 떴다는 사실이 단순한 1위보다 정보량이 많다.
§ 07채택 사례· 엔진별 user 효과
InferenceX 가 OSS 생태계에 만든 변화
benchmark suite 의 목적은 측정 이 아니라 피드백 루프. 누가 그 루프를 활용하고 있는가 — 이 강의의 가장 흥미로운 부분.
- 엔진 maintainer — release 직후 InferenceX 에서 자동으로 측정된 결과를 본다. regression 이 있으면 다음 release 전에 fix. “performance CI for free”.
- 모델 vendor — Llama 3.1 / Qwen 2.5 / Mistral 출시 시 — 어느 엔진에서 가장 잘 도는지를 InferenceX 결과를 인용해 추천.
- cloud / GPU vendor — H100 vs H200 vs B200 의 inference 성능 차이를 객관 데이터로. 영업 자료에 인용.
- application engineer — “어떤 엔진을 deploy 할까” 의 결정에 leaderboard 의 직접 참조.
- 연구자 — 새 attention kernel / KV cache 정책의 실험 결과를 InferenceX 와 비교. baseline 제공의 가치.
생태계의 미묘함 · 확인 필요
OSS engine 사이의 경쟁이 — 건강한 압력으로 작용하는 동시에 — 일부 엔진이 “benchmark gaming” 으로 흐를 가능성도 존재. InferenceX 가 의도적으로 workload distribution 을 다양화 (chat / RAG / long-context / batch) 하는 건 그 게이밍을 막기 위한 디자인.
§ 08production 활용· 조직이 InferenceX 를 쓰는 길
“public leaderboard” 를 넘어 internal 결정에 들어가는 자리
조직 안에서 InferenceX 류의 결과를 어떻게 의사결정에 끌어 쓰는가 — 강의가 production 에 닿는 부분.
엔진 선택
workload (chat / batch / long-context) 와 SLA (TTFT P95) 의 조합으로 leaderboard 필터링. 한 엔진이 모든 자리에 우월하지 않음.
capacity planning
throughput × concurrency 곡선으로 GPU 수 산정. cost-per-1M-tokens 가 cloud 견적의 직접 input.
internal CI 로 fork
자체 모델 / 자체 workload 로 InferenceX 의 harness 를 fork. release 마다 자동 측정.
vendor 협상
cloud / hardware vendor 에 “vLLM 에서 동일 GPU 의 다른 cloud 가 +10% 빠르다” 같은 객관 자료 제시.
regression alarm
production 에 deploy 하기 전, 새 엔진 release 의 InferenceX 점수를 자동 검토. 큰 regression 이면 hold.
SLA reporting
고객 SLA report 의 “기대 latency” 항목을 InferenceX 결과의 P95 로 보정.
§ 09다음· FP4 · MoE · multi-modal · speculative decoding
2025 의 추가 차원들
benchmark suite 의 가장 큰 design challenge 는 — “어떤 새 차원을 다음 분기에 추가할 것인가”. 강의 시점에서 명확한 후보들.
- FP4 inference (Blackwell) — B200 의 native FP4. 기존 FP8 / FP16 와 다른 metric 가 필요.
- MoE (DeepSeek-V3, Mixtral 등) — 모든 token 이 같은 비용이 아닌 모델. expert 활성도 추적이 새 차원.
- speculative decoding — draft + target 모델의 결합. throughput 이 단일 forward 와 다른 의미.
- multi-modal — vision + LLM. 이미지 입력의 prefill 비용이 텍스트와 다른 양상.
- long-context (128k+) — KV cache 가 GPU memory 를 압도. 다른 종류의 SLA 가 필요.
- RAG / tool calling pipeline — single-step 이 아닌 multi-hop. end-to-end latency 가 새 metric.
“각 차원이 추가될 때마다 — 새 workload, 새 metric, 새 비교축 — leaderboard 는 한 단계 더 복잡해진다. UX 의 challenge 가 시간이 지날수록 커짐.”학습 노트
§ 10기억할 메모· key takeaways · refs
다시 열었을 때 5분 안에 손에 잡혀야 할 것
continuous benchmarking = CI
unit test 가 정확성을, benchmark 가 성능을. 같은 자동화 stack 의 다른 metric.
5 단계 파이프라인
Detect → Build → Run → Collect → Publish. 각 단계 분리. 한 엔진 추가 = 한 단계만 수정.
3 핵심 metric
TTFT (responsiveness), TPOT (decode efficiency), throughput. 셋의 조합으로 SLA-throughput frontier.
isolation
한 run = 한 GPU. 비용을 만들지만 reproducibility 의 절대 조건.
delta highlight
leaderboard 는 순위가 아니라 변화 가 정보량. 직전 release 대비 +/- 를 강조.
workload diversity
chat / RAG / long-context / batch. game 막기와 production 매핑 둘 다.
엔진별 spectrum
SGLang, vLLM, TRT-LLM, LMDeploy, MLC-LLM, llama.cpp 가 같은 모델에서 서로 다른 trade-off.
조직 활용
엔진 선택, capacity planning, vendor 협상, regression alarm. internal CI 로 fork 하는 게 자연스러운 길.
손에 새기기 — 실습 시퀀스
- vLLM 단일 측정 — 한 모델 (Llama-3.1-8B-Instruct), 한 GPU (자기 환경) 에서 vLLM 의 native benchmark 를 돌려 TTFT / TPOT / throughput 을 측정. 정의 차이를 직접 확인.
- SGLang 동일 측정 — 같은 모델 / GPU 에 SGLang. 결과의 차이가 30% 이상 나면 측정 protocol 이 다른 것.
- workload spec YAML — 두 측정을 같은 spec 으로 통일. concurrency, prompt distribution, max tokens.
- storage — 결과를 sqlite 에 (engine, version, model, metric, value) 형식으로 저장. cross-run 비교를 SQL 로.
- weekly cron — 위 4 단계를 GitHub Actions 의 schedule trigger 로. 매주 결과가 자동으로 쌓이는지 확인.
- regression alarm — 새 결과가 직전과 -10% 이상 차이 나면 GitHub issue 자동 생성. 작은 자동화의 큰 가치.
§ 11다른 강의로 이어지는 길· connections
InferenceX 의 frame 이 다른 강의에서 어떻게 재등장하는가
§ 12열린 질문· open questions
다음에 다시 들었을 때 직접 검증해야 할 것들
- InferenceX 의 정확한 host 와 URL — 강의에서 leaderboard 의 실제 site 를 보여줬을 가능성. 자막 실패로 미확인. (확인 필요)
- fleet 구성 — 어떤 GPU 를 fleet 으로 쓰는지 (cloud rented vs 자체 hardware). 비용 모델. (확인 필요)
- regression alert 메커니즘 — Slack? GitHub issue? upstream 에 자동 PR? (확인 필요)
- workload distribution — ShareGPT 기반? 자체 dataset? RAG 트래픽 시뮬레이션 어떻게? (확인 필요)
- publication / paper — 강의에서 발표한 시스템이 paper / blog 로 정리됐는지. (확인 필요)
- license / 공개 범위 — harness 코드가 OSS 인지, 결과만 OSS 인지. (확인 필요)
검증 메모
이 노트의 leaderboard 표 (§ 06) 의 수치는 2024–2025 의 OSS engine benchmarks 의 일반적 추세를 정리한 예시이며 InferenceX 의 실제 결과와 다를 수 있다. 실제 결과는 해당 site 와 강의 영상에서 확인 필요. 시스템 설계의 5 단계 파이프라인은 vLLM benchmarks, SGLang bench, MLPerf 의 공통 패턴으로부터 일반화한 것.