LLM WikiAccess-protected knowledge portal

WIKI

vLLM 0.27: Kimi K3 네이티브 지원·Rubin SM107 초기 활성화·Rust gRPC 제어면이 만드는 서빙 아키텍처 변화

무엇이 달라졌는가 vLLM 0.27.0은 2026년 8월 10일 공개됐다. 561개 커밋, 242명 기여자 신규 64명 로 구성된 이 릴리스는 단순한 기능 추가를 넘어 세 가지 방향에서 서빙 아키텍처의 경계를 다시 그었다. 첫째, Kimi K3 네이티브 지원 이 추가됐다. 2조 8000억 파라미터 MoE 모델인 Kimi K3를 16× GB300 NVL72에서 DSpark AR 퓨전 투기적 디코딩까지 엮어 370 tok/s를 내

경로human/study/content/ai-frontier/133-vllm-0-27-kimi-k3-rubin-sm107-grpc-control-plane.md
카테고리Study
태그#ai-review #control #grpc #plane #rubin #sm107 #study

무엇이 달라졌는가

vLLM 0.27.0은 2026년 8월 10일 공개됐다. 561개 커밋, 242명 기여자(신규 64명)로 구성된 이 릴리스는 단순한 기능 추가를 넘어 세 가지 방향에서 서빙 아키텍처의 경계를 다시 그었다.

첫째, Kimi K3 네이티브 지원이 추가됐다. 2조 8000억 파라미터 MoE 모델인 Kimi K3를 16× GB300 NVL72에서 DSpark AR 퓨전 투기적 디코딩까지 엮어 370 tok/s를 내는 전용 지원 스택이 들어왔다. 둘째, Rust 프론트엔드에 gRPC 제어면(control plane)이 추가됐다. 엔진 상태 보고, 중단 제어, KV 이벤트 소스 탐지가 gRPC 채널로 노출된다. 셋째, NVIDIA Rubin(SM107) 초기 활성화로 차세대 GPU를 미리 대상으로 하는 컴파일 경로가 열렸다.

Kimi K3 지원 스택

Kimi K3(arXiv:2607.16158)는 Moonshot AI가 공개한 하이브리드 어텐션 MoE 모델이다. 전체 파라미터의 일부만 활성화하는 MoE 구조에 선형 어텐션 레이어를 혼합해 긴 컨텍스트에서 메모리 효율을 높인다. vLLM이 이 모델을 서빙하려면 일반 트랜스포머 경로와 다른 커널이 필요하다.

0.27.0이 추가한 지원 스택은 다섯 부분으로 구성된다.

  1. AttnRes 커널: 선형 어텐션 레이어의 순환 상태(recurrent state)를 처리하는 전용 주의 커널
  2. DeepGEMM 연동: 전문가(expert) FFN 행렬 곱셈에 DeepGEMM을 적용해 MoE 라우팅 오버헤드를 낮춤
  3. DSpark AR 퓨전: 투기적 디코딩과 자기회귀(AR) 생성을 하나의 패스로 퓨전 — 사전 디코딩 없이 370 tok/s 달성
  4. 공유 전문가 샤딩: 선택적 shared-expert 분할로 다중 노드 배포 시 전문가 편중(load imbalance) 완화
  5. Python·Rust 프론트엔드 동시 지원: 두 프론트엔드 모두에서 동일한 모델 파이프라인 작동

투기적 디코딩 없는 경우에도 118 tok/s가 측정됐다.

Rust 프론트엔드 gRPC 제어면

0.25부터 도입된 Rust 프론트엔드는 데이터 경로(data plane)의 HTTP 처리를 담당했다. 0.27에서는 제어 경로(control plane)가 추가됐다.

API 클라이언트 HTTP 추론 요청 gRPC 제어 명령 Rust 프론트엔드 데이터 경로 HTTP/HTTPS 추론 요청 처리 스트리밍 응답 · 멀티모달 영상·음성 gRPC 제어면 (신규) 엔진 상태 보고 (헬스체크) 요청 중단(abort) 제어 서버·모델 탐지 (discovery) KV 이벤트 소스 탐지 vllm-bench CLI 통합 기존 HTTP 경로와 완전히 분리된 채널 vLLM 엔진 A Kimi K3 · H100×8 vLLM 엔진 B Qwen3.5 · A100×8 vLLM 엔진 C 임베딩 전용 · MRv2 데이터 경로 (HTTP) 제어 경로 (gRPC)
vLLM 0.27 Rust 프론트엔드 gRPC 제어면 구조 — 제어 채널과 데이터 채널이 분리된다

gRPC 제어면이 분리되면서 달라지는 점이 하나 있다. 기존에는 엔진 상태를 HTTP 경로로 폴링하거나 로그를 파싱해야 했다. 이제는 gRPC 스트리밍으로 엔진의 상태 변화를 구독할 수 있고, KV 이벤트(캐시 히트, 퇴거)를 실시간으로 탐지할 수 있다. 이 정보는 스케줄러나 라우터가 더 정밀한 라우팅 결정을 내리는 데 쓸 수 있다.

Model Runner V2 확장

Model Runner V2(MRv2)는 0.25에서 dense 추론 기본 경로가 됐다. 0.27에서는 비생성(non-generative) 워크로드로 범위가 넓어졌다.

워크로드 유형0.26 이전0.27
Dense 생성MRv2 기본MRv2 기본
인코더 전용 어텐션미지원MRv2 지원
시퀀스 풀링 (임베딩/분류)별도 경로MRv2 통합
인코더 토큰 분류·임베딩별도 경로MRv2 통합

임베딩 모델(jina-embeddings-v5 포함)과 분류 모델이 같은 MRv2 실행 경로를 타게 됐다. 하나의 vLLM 인스턴스에 생성 모델과 임베딩 모델을 함께 올려 서빙하는 구성이 한층 안정적이 됐다.

하드웨어 초기 활성화

NVIDIA Rubin 아키텍처(sm_107)에 대한 컴파일 타깃이 열렸다. 현재는 NVLink all-reduce 경로가 SM107에서 동작하는 것이 핵심이다. GB300 NVL72가 상용 배포에 들어가기 전 운영자가 테스트 환경을 미리 구성할 수 있는 수준이다.

ROCm gfx1250 아키텍처도 활성화됐다. AMD의 차세대 GPU 타깃이다.

FlashAttention 4는 0.26에서 선택적으로 지원됐는데, 0.27에서 FP8 KV 캐시와 headdim-256 지원이 추가됐다. H100 Hopper에서 상대 어텐션(relative attention)과 MTP=1 투기적 디코딩을 Inkling 계열 모델에 쓸 수 있다.

PyTorch 2.13 업그레이드 — 환경 파괴적 변경

0.27.0의 가장 큰 운영 위험은 PyTorch 2.13.0으로의 업그레이드다. torchvision 0.28.0, Triton 3.7.1도 함께 올라간다. CUDA, XPU, CPU 플랫폼 모두에 영향을 준다.

기존 PyTorch 2.12 기반 컨테이너 이미지나 가상환경과는 동일 환경에서 혼용이 불가능하다. 서빙 컨테이너 이미지를 교체하고 의존성을 재확인해야 한다. PyTorch 2.13에서 추가된 LinearCrossEntropyLoss(arXiv:2507.05XXX 기반)나 새 메모리 할당 정책이 기존 커스텀 확장과 충돌할 수 있다.

업그레이드 전 체크리스트:

  1. 커스텀 CUDA 확장이 있으면 PyTorch 2.13에서 재컴파일 확인
  2. 사용 중인 정량화 라이브러리(AutoAWQ, bitsandbytes 등)의 2.13 호환 버전 확인
  3. ROCm 사용자는 gfx942(MI300) 지원 여부를 upstream ROCm 릴리스 노트에서 교차 검증

운영자 관점 요약

0.27.0에서 즉시 관심을 가져야 하는 세 가지가 있다.

첫째, Kimi K3를 서빙할 계획이라면 이 버전이 안정적인 첫 번째 기준선이다. DSpark AR 퓨전을 켜면 GB300에서 370 tok/s까지 올라가지만, 공유 전문가 샤딩 설정(--shared-expert-sharding)은 노드 수에 따라 직접 조정해야 한다.

둘째, 임베딩 파이프라인을 vLLM으로 통합하려는 팀은 MRv2 확장으로 하나의 엔진 위에서 생성 + 임베딩을 안정적으로 혼용할 수 있게 됐다.

셋째, PyTorch 업그레이드 전에 스테이징 환경에서 반드시 검증해야 한다. 이 변경이 가장 흔히 예상치 못한 장애를 일으킨다.

References