vLLM이 Model Runner를 통째로 다시 만들었다. 발표 자료의 "56% 처리량 향상"이 헤드라인을 잡았는데, 조건을 뜯어보면 일반 서빙 환경에서 기대할 수치는 6~10% 쪽이다. 그래도 구조 자체는 의미가 있다.
vLLM이 Model Runner를 통째로 다시 만든 이유
vLLM 팀이 공식 블로그에서 V1을 두고 직접 "retrofit"이라고 표현했다. 요청 상태 관리 로직이 계속 커지면서 코드베이스가 복잡해졌고, 비동기 스케줄링도 원래 설계에 없던 걸 나중에 얹은 형태였다. 그래서 3월 24일 발표한 MRV2는 처음부터 다시 만든 거다. V1 사용자 피드백과 팀의 자체 경험을 바탕으로 persistent batching, async 스케줄링, 입력 준비, 샘플링을 전부 재설계했다.
MRV2가 내세운 원칙은 세 가지다.
CPU에서 하던 입력 텐서 준비를 Triton 커널로 GPU 위에서 직접 처리. CPU-GPU 동기화 지점을 제거.
N 스텝 GPU 실행 중에 N+1 스텝 스케줄러와 워커를 미리 준비. 사후 추가가 아닌 설계 기반.
ModelState 추상화로 모델별 로직을 격리. 공통 실행 경로를 단순하게 유지.
이 중 GPU-native가 핵심이다. 기존에는 CPU가 input_ids, positions, seq_lens 같은 텐서를 준비해서 GPU로 넘겼다. MRV2에서는 이 작업이 GPU 위에서 일어난다. CPU-GPU 동기화 지점이 사라지고, 스케줄러가 GPU 작업을 기다리지 않아도 된다.
56% 처리량 향상, 어떤 조건에서 나온 수치인가
Qwen3-0.6B + GB200 조합의 특수성
벤치마크를 보면 이렇게 적혀 있다. "소형 모델(Qwen3-0.6B)을 고성능 GPU(1×GB200)에서 돌렸다. 의도적으로 작은 모델을 골랐다. host-side overhead가 상대적으로 크게 잡히는 조건을 만들기 위해서." vLLM 팀이 직접 쓴 말이다 [출처: vLLM 공식 블로그, 2026.03.24].
수치 자체가 거짓은 아니다. 다만 조건이 있다. GB200이라는 최신 GPU에서, Qwen3-0.6B 같은 작은 모델을 돌릴 때 CPU 오버헤드가 병목이 되는 상황에서 나온 숫자다. GPU가 모델 연산을 워낙 빠르게 끝내버리니, CPU에서 다음 배치를 준비하는 시간이 상대적으로 길어진다. 거기서 GPU-native 입력 준비가 효과를 발휘한다.
일반 서빙 환경에서 기대치
7B~70B 규모 모델을 A100이나 H100으로 돌리는 일반적인 서빙 환경이라면 이야기가 달라진다.
- · Qwen3-0.6B
- · 1×GB200 단일 GPU
- · host-side overhead 극대화 의도
- · 16K → 25K output tok/s
- · GLM-4.7-FP8 / speculative
- · 4×GB200, MTP=1
- · TPOT 6.3% 감소
- · 7~70B 일반 서빙 기대치 6~10%
pipeline parallelism에서 CUDA 그래프 벤치마크도 있다. Qwen3-30B-A3B-FP8을 PP=2로 128 프롬프트 기준으로 돌렸더니, V2 piecewise CG가 23.07 req/s, V1 baseline이 23.23 req/s였다. 거의 동등하다 [출처: vLLM 공식 벤치마크]. MRV2가 V1 대비 극적으로 빠른 게 아니라, 특정 병목을 제거한 구조적 개선에 가깝다.
실제로 달라지는 것들 — async 스케줄링과 speculative decoding
수치보다 인상적인 건 구조다. async 스케줄링이 설계 기반으로 들어가면서, 기존에 어렵던 조합이 자연스럽게 풀렸다. async 스케줄링과 speculative decoding을 함께 쓰는 게 V1에서는 까다로웠는데, MRV2에서는 입력 준비가 GPU 위에서 일어나니 rejection sampling 결과를 그대로 다음 준비 단계에 먹일 수 있다.
“API는 그대로다. 환경변수 하나로 전환할 수 있다.
코드 변경 없이 A/B 테스트가 된다.VLLM_USE_V2_MODEL_RUNNER=1
ModelState라는 추상화도 생겼다. DeepSeek, Qwen, Kimi 같은 모델 패밀리마다 별도 로직을 짤 때 공통 코드와 뒤엉키는 문제가 있었는데, 이 부분을 깔끔하게 분리했다. 기여자들 입장에서도 자기가 관심 있는 모델 패밀리만 건드리면 되는 구조가 됐다.
어제 V1으로 돌리다가 오늘 MRV2로 돌려보고, 처리량 차이가 유의미한지 직접 확인할 수 있다 — 이게 운영자 입장에서 가장 실용적인 변경이다.
지금 프로덕션에 넣어도 되는가
공식 발표에서 "still experimental"이라고 명시했다. v0.18.0 기준으로 지원되지 않는 기능들이 있다. 자신이 쓰는 기능이 포함됐는지 공식 블로그에서 먼저 확인하는 게 순서다.
조사 결과를 정리하면 다음과 같다.
- 스테이징 환경 A/B
환경변수만 켜고 처리량 측정 - 소형 모델 + 최신 GPU
CPU 병목이 의심되는 조합 - speculative decoding 워크로드
rejection sampling 흐름이 깔끔 - 자체 벤치마크 수집
전환 결정의 근거 미리 확보
- 풀 프로덕션 전환
"still experimental" 명시 상태 - PP 위주 워크로드
PP=2에서 V1과 거의 동등 (23 req/s) - v0.18 미지원 기능 사용 중
전환 후 회귀 가능성 - prefix caching 의존 RAG
엣지 케이스 검증 부족
솔직히 지금 당장 풀 프로덕션에 MRV2를 넣는 건 이르다. v0.19 이후 안정화 버전을 기다리는 게 맞다고 본다. 다만 개발 환경이나 스테이징에서 환경변수 켜놓고 처리량 차이를 측정해두는 건 의미가 있다. RAG 파이프라인처럼 vLLM을 추론 백엔드로 쓰는 경우라면, MRV2 전환 후 prefix caching이나 streaming 동작 방식도 같이 확인해볼 필요가 있다.
헤드라인 56%가 아니라, 구조 변경을 봐야 한다
MRV2의 의미는 56%가 아니다. async 스케줄링이 설계 기반으로 들어갔고, ModelState 추상화로 모델별 기여 비용이 낮아졌고, 환경변수 한 줄로 전환 비용을 거의 0으로 만든 점 — 이게 본질이다. 일반 서빙에서의 6~10%는 그 부산물이다. v0.19를 기다리되, 지금부터 자체 측정 데이터를 모아두면 전환 시점에 의사결정이 빨라진다.
- [1] vLLM Team. "Model Runner V2: A Ground-Up Rewrite." vLLM Official Blog, 2026.03.24.
- [2] vLLM Benchmark Suite — Qwen3-0.6B / 1×GB200, output throughput 16K → 25K tok/s.
- [3] vLLM Benchmark — GLM-4.7-FP8 / 4×GB200 / MTP=1, TPOT −6.3%.
- [4] vLLM Benchmark — Qwen3-30B-A3B-FP8 / PP=2 / 128 prompts, V2 23.07 req/s vs V1 23.23 req/s.
📌 함께 보면 좋은 글
'AI.IT' 카테고리의 다른 글
| Zapier AI Agents 써봤는데, 쉽다는 말은 반만 맞았다 (0) | 2026.05.12 |
|---|---|
| Claude Code Agent View 정리 — IDE에서 에이전트 OS로 넘어가는 신호 (0) | 2026.05.12 |
| Claude Code SEO 월 5만 클릭 전략 — 영상이 빠뜨린 2026년 함정 6가지 (0) | 2026.05.11 |
| HyperFrames V2 — Claude로 영상을 'vibe-coding'하는 시대가 왔다 (0) | 2026.05.11 |
| EU AI Act 협상 두 번 결렬, 8월 2일 전에 이것만은 체크해야 한다 (0) | 2026.05.11 |
