vLLM v0.18 / v0.19 업데이트 해부: gRPC 서빙, 비동기 스케줄링, CVE-2026-0994까지

도입

LLM 프로덕션 서빙의 사실상 표준인 vLLM이 2026년 4월에 두 차례의 메이저 릴리스를 내놨습니다. 3월 말의 v0.18.0은 gRPC 서빙과 GPU 스펙큘레이티브 디코딩을 들고 왔고, 4월 2일의 v0.19.0은 비동기 스케줄링을 기본값으로 전환하고 Gemma 4 아키텍처를 Day-0로 지원합니다. 더해서 Completions API에서 원격 코드 실행이 가능했던 CVE-2026-0994 패치도 이 사이클에 포함되어, 프로덕션 사용자는 가급적 빠르게 업그레이드가 필요합니다. 이 글에서는 릴리스의 의미, 성능 수치, 코드 관점에서의 변화를 정리합니다.

📌 한 줄 요약

• v0.18.0 (2026년 3월 말): gRPC 서빙, GPU NGram 스펙큘레이티브, FlexKV 오프로딩, GPU-less render 분리
• v0.19.0 (2026년 4월 2일): 비동기 스케줄링 기본 활성화, Gemma 4 Day-0 지원, Model Runner V2, --max-model-len auto
• 보안: CVE-2026-0994 (Completions API RCE 가능성), v0.10.2 이상 영향, 즉시 패치 권장
• 성능 대표치: Pooling maxsim +13.9%, Pipeline parallel send/recv +2.9%, Pooling copy +1.8%
• 호환성 변경: Ray 기본 의존성 제거, KV load 실패 기본 정책이 recompute → fail

주요 변화 상세

1) gRPC 서빙: HTTP/2 멀티플렉싱의 이득

v0.18에서 추가된 --grpc 플래그는 단순히 포트만 바꾸는 게 아닙니다. gRPC는 HTTP/2 멀티플렉싱 위에서 동작하므로, 동시에 수백 개의 스트리밍 응답을 한 TCP 연결에서 처리할 수 있습니다. 이는 엔드포인트 → vLLM 사이의 TCP connect/TLS handshake 비용을 수평 확장 환경에서 줄여 줍니다. 동일한 GPU에서 HTTP/1.1 기반 REST 대비 꼬리 지연시간(p99)이 낮아지는 효과가 큽니다. 특히 에이전트 워크로드처럼 짧은 요청이 몰려오는 트래픽 패턴과 잘 맞습니다.

2) 비동기 스케줄링 "zero-bubble overlap"

v0.19에서 비동기 스케줄링이 기본값이 되었고, 스펙큘레이티브 디코딩과도 정합성을 맞췄습니다. 전통적으로 스케줄링 스텝과 GPU 커널 실행 사이에는 "버블"(idle 구간)이 생기는데, 이번 릴리스는 스케줄링을 다음 스텝의 커널 실행과 겹쳐서 파이프라인 상의 빈 구간을 거의 0에 가깝게 줄였습니다. 결과적으로 소규모 배치·짧은 응답이 많은 인터랙티브 트래픽에서 대기열 지연이 감소합니다.

3) Gemma 4 Day-0 지원

Google이 4월 초 Gemma 4(E2B/E4B/26B MoE/31B Dense) 4종을 공개했는데, vLLM v0.19는 동일 주기에 맞춰 전 아키텍처 서빙을 지원합니다. 멀티모달(이미지·오디오 입력)과 툴 사용 포맷까지 커버하므로, 자체 GPU에서 멀티모달 Gemma를 돌리려는 팀은 별도 포크나 패치 없이 표준 vLLM 경로로 배포할 수 있습니다.

4) Model Runner V2와 자동 max-model-len

Model Runner V2는 멀티모달 임베딩, EPLB(Expert Parallel Load Balancing), 부분(Piecewise) CUDA 그래프 캡처를 하나의 런타임 경로로 통합합니다. 그리고 --max-model-len auto가 생겨, 메모리 계산에 맞춰 max_model_len을 자동으로 줄여 OOM 실패를 예방합니다. 새 GPU/새 모델 조합을 프로덕션에 올릴 때 반복되던 "첫 부팅은 OOM으로 죽는" 문제를 많이 줄여 줍니다.

5) CVE-2026-0994: 즉시 업그레이드 대상

v0.10.2 이후 버전의 Completions API에서 텐서 역직렬화 경로에 torch.load()가 잘못 사용되어, 악의적인 입력으로 원격 코드 실행 가능성이 있다는 취약점이 보고됐습니다. 공개된 엔드포인트를 운영 중이라면, 프록시 앞에서 거르고 있더라도 내부 네트워크 경로를 통한 측면 공격을 막기 위해 이번 주 내 패치를 권장합니다.

📊 릴리스 요약 비교표

항목	v0.17 이전	v0.18	v0.19
gRPC 서빙	—	`--grpc` 추가	유지
비동기 스케줄링	옵션	옵션	기본 활성화
Gemma 4 지원	—	—	Day-0
NGram 스펙큘레이티브	CPU	GPU	GPU + async 호환
CUDA 그래프	정적	정적	Piecewise
Ray 의존성	기본	제거	제거
KV load 실패 기본	recompute	fail	fail
CVE-2026-0994	영향	패치	패치

📊 성능 개선 표

최적화 대상	개선폭	주 혜택 대상
Pooling maxsim (임베딩 모델)	+13.9%	BGE, E5 계열 대용량 임베딩
Pipeline parallel async send/recv	+2.9%	멀티 GPU 분산 서빙
Pooling copy 최적화	+1.8%	임베딩 서빙
Prefix caching 오버헤드(0% hit rate)	< 1%	전 배포

절대 수치는 소박해 보일 수 있지만, 대형 트래픽에서는 2~3%가 곧 월 수천 달러의 GPU 비용 절감으로 이어집니다. 특히 임베딩 워크로드(+13.9%)는 벡터 DB 업데이트 파이프라인 쪽에서 체감이 큰 구간입니다.

💻 코드 예시: gRPC 서빙 띄우기

# 최신 버전 설치 (CVE-2026-0994 패치 포함)
pip install -U "vllm>=0.19.1"

# gRPC 서빙 기동. HTTP/2 멀티플렉싱으로 짧은 요청에 강함
vllm serve google/gemma-4-9b-it \
  --grpc \
  --host 0.0.0.0 \
  --port 50051 \
  --max-model-len auto \
  --async-scheduling \
  --enable-prefix-caching

--max-model-len auto는 GPU의 가용 KV 캐시 크기에 맞춰 최대 길이를 자동 계산합니다. 수작업 튜닝 없이도 초기 부팅 OOM을 예방할 수 있어, CI에서 스모크 테스트를 돌릴 때 편리합니다.

💻 코드 예시: OpenAI 호환 클라이언트로 gRPC 엔드포인트 호출

현재 커뮤니티에서는 grpcio 기반의 얇은 클라이언트 또는 기존 HTTP 클라이언트와의 호환 레이어를 많이 씁니다. 가장 간단한 HTTP 경로 비교 예시는 다음과 같습니다.

# pip install openai
from openai import OpenAI

# vLLM의 OpenAI 호환 HTTP 엔드포인트 (기존과 동일)
client = OpenAI(base_url="http://localhost:8000/v1", api_key="dummy")

resp = client.chat.completions.create(
    model="google/gemma-4-9b-it",
    messages=[{"role": "user", "content": "async scheduling이 왜 지연시간을 줄이는지 한국어로 설명해 줘."}],
    temperature=0.2,
    max_tokens=512,
)
print(resp.choices[0].message.content)

gRPC 경로는 같은 모델을 다른 포트(위 예시 50051)로 동시 서빙할 수 있으므로, 내부 마이크로서비스는 gRPC로, 외부 노출은 REST로 나누는 하이브리드 배치도 흔한 패턴입니다.

개발자 관점 심층 분석

비동기 스케줄링이 기본이라는 뜻

"옵션이었지만 잘 안 켜던 기능이 기본이 됐다"는 의미 이상으로, 내부 상태 머신이 더 많은 타이밍 케이스를 기본으로 보장해야 한다는 뜻입니다. 사이드 이펙트로 일부 커스텀 스케줄러/프로파일러 통합이 깨질 수 있으며, 특히 자체 프리픽스 캐시 전략을 달아 두었다면 타이밍 변경으로 인한 캐시 적중률 변동을 다시 측정해야 합니다.

Ray 제거와 배포 슬림화

Ray가 기본 의존성에서 빠지면서 도커 이미지가 가벼워지고, Kubernetes 수평 확장에서도 pod 부팅이 더 빨라집니다. 반대로 Ray를 전제로 한 기존 파이프라인이 있다면 명시적 설치(pip install vllm[ray])로 마이그레이션이 필요합니다.

KV 로드 실패 정책 변화

recompute가 기본이던 시절에는 디스크 KV 캐시 로드 실패 시 조용히 재연산으로 떨어져, 대형 트래픽에서는 장애가 눈에 잘 안 띄었습니다. 기본이 fail로 바뀐 것은 운영상 "조용한 성능 저하"를 줄이는 올바른 방향이지만, 스테이징에서 기존 로드 실패율이 얼마나 되는지 먼저 파악하지 않으면 프로덕션에서 갑자기 오류율이 튈 수 있습니다.

언제까지 v0.17에 머물러도 되나

CVE-2026-0994 패치가 있기 때문에, 외부 트래픽을 받는 배포는 사실상 선택지가 없습니다. 내부 전용이라도 호환성 문제가 없다면 v0.19로 직행하는 편이 성능·유지보수 양쪽에서 이득입니다. 내부 스케줄러를 커스터마이즈했거나 Ray 전제 배포라면 v0.18을 중간 단계로 삼아 단계적으로 올리는 전략이 안전합니다.

구현 가이드: 내 배포 적용 순서

1. 보안 먼저: 외부에 노출된 모든 vLLM 서빙 엔드포인트를 식별하고, v0.19.1 이상으로 긴급 업그레이드합니다. 내부망 서빙도 가능한 한 빠르게 따라갑니다.
2. 호환성 감사: --max-model-len을 하드코딩하던 배포 스크립트, Ray 전제 배포, 커스텀 스케줄러가 있는지 점검합니다. 필요하면 pip install vllm[ray], --max-model-len auto로 스위치합니다.
3. 성능 A/B: 대표 트래픽을 분리해 v0.17 ↔ v0.19 비교를 돌립니다. 임베딩 워크로드가 있다면 Pooling maxsim 개선 효과가 가장 큽니다.
4. gRPC 도입 여부 결정: 짧은 요청이 많거나 내부 마이크로서비스 간 통신이면 gRPC로 일부 트래픽을 옮겨 p99 지연시간을 비교합니다.
5. 모니터링 재점검: KV load 기본 정책 변경으로 fail 이벤트가 가시화됩니다. Prometheus 지표·알람 임계치를 재설정합니다.
6. 프리픽스 캐시 재측정: 스케줄러 타이밍 변화로 캐시 적중률이 달라질 수 있으니, 동일 트래픽 샘플로 1~2일간 로그를 비교한 뒤 튜닝합니다.

마무리

vLLM v0.18과 v0.19는 "더 빠른 라이브러리"라기보다 프로덕션 서빙 플랫폼으로서의 성숙을 보여주는 릴리스입니다. gRPC 서빙, 비동기 스케줄링 기본화, Gemma 4 Day-0 지원, 자동 max-model-len이 한꺼번에 들어왔고, 같은 사이클에 보안 패치까지 포함되었습니다. 개별 성능 퍼센트보다는, 이번 변화들이 합쳐져 "OOM 없이 켜지고, 스케줄링 버블 없이 돌고, 멀티 플랫폼 안에서 얇아진다"는 운영 안정성 개선이 훨씬 중요한 메시지입니다. 다음 관전 포인트는 Q2 로드맵에서 예고된 대형 MoE 최적화와 TPU 경로 확장입니다.

출처

• vLLM GitHub Releases
• vLLM Blog
• vLLM Update April 2026: v0.18, v0.19, Gemma 4, and gRPC Serving — Fazm Blog
• vLLM Q2 2026 Roadmap (draft)
• Welcome Gemma 4: Frontier multimodal intelligence on device — Hugging Face