vLLM v0.26.0: 그룹별 어텐션 백엔드·오브젝트 스토어 KV 계층·Rust 멀티모달로 하이브리드 모델 서빙을 다시 쓰는 방법

왜 지금 봐야 하나

2026년 7월 말, vLLM이 v0.26.0을 출시했다. 411개 커밋, 212명의 기여자(신규 61명)로 구성된 이번 릴리스는 단순한 기능 추가가 아니라 두 가지 구조적 제한을 풀어내는 방향으로 설계됐다.

첫 번째 제한: 한 모델 안에서 모든 KV 캐시 그룹이 동일한 어텐션 백엔드를 써야 했다. Mamba-Transformer 하이브리드나 Inkling처럼 레이어마다 다른 어텐션 메커니즘을 쓰는 모델이 등장하면서 이 가정이 무너졌다. v0.26.0은 KV 캐시 그룹마다 다른 어텐션 백엔드를 선택할 수 있게 했다.

두 번째 제한: KV 캐시가 넘치면 GPU VRAM과 CPU DRAM이 전부였다. 오브젝트 스토어(S3, GCS 등)를 3차 오프로딩 대상으로 쓸 수 있는 구조가 생겼다. 워크로드 아이덴티티 기반 인증으로 클라우드 환경에서 자연스럽게 연동된다.

이 두 변화 외에도 DeepSeek-V4 서빙 성능 개선, Rust 프론트엔드 멀티모달 확장, FlashAttention 3 안정 ABI 전환이 포함됐다. 이 글은 각 변화의 작동 방식과 운영 기준점을 다룬다.

변경 사항 전체 요약

아키텍처 변화 1: KV 캐시 그룹별 어텐션 백엔드 선택

왜 이것이 필요했나

기존 vLLM은 모델 내 모든 레이어가 동일한 어텐션 백엔드(FlashAttention, FlashInfer 등)를 사용한다고 가정했다. 단순한 Transformer 계열에서는 문제없는 전제다. 그러나 2025년 이후 등장한 하이브리드 아키텍처는 다르다.

• Jamba, Mamba-2-Transformer 하이브리드: 일부 레이어는 State Space Model(SSM), 나머지는 표준 어텐션
• TML Inkling: 상대적 어텐션(relative attention), 쇼트 컨볼루션, MoE를 조합
• Gemma 기반 모델 중 일부: 슬라이딩 윈도우 + 글로벌 어텐션 혼합

이런 모델은 레이어마다 다른 KV 캐시 레이아웃이 필요하고, 어텐션 연산 방식도 다르다. 하나의 백엔드가 두 가지를 동시에 처리하면 불필요한 코드 분기가 생기거나 최적화 기회를 잃는다.

v0.26.0의 해법

v0.26.0은 KV 캐시 그룹 개념을 도입해 모델 내부에서 어텐션 백엔드를 그룹마다 선택할 수 있게 했다. 동시에 슬라이딩 윈도우 어텐션을 특정 백엔드의 구현 세부사항에서 꺼내 명시적인 백엔드 기능(capability)으로 분리했다.

이 변화의 실용적 결과: Inkling처럼 혼합 아키텍처를 가진 모델을 vLLM에서 실행할 때 각 레이어 유형에 맞는 백엔드가 자동으로 선택된다. 개발자가 커스텀 패치를 작성할 필요가 없다.

아키텍처 변화 2: 오브젝트 스토어 KV 오프로딩

KV 캐시 압박 문제

장문 컨텍스트(100K+ 토큰)를 처리하는 서빙 환경에서 KV 캐시는 가장 큰 메모리 소비원이다. 기존 vLLM의 오프로딩 구조는 2계층이었다.

1. GPU VRAM (가장 빠름): 활성 요청의 KV 캐시
2. CPU DRAM (느리지만 용량 큼): 대기 중인 요청의 KV 캐시

CPU DRAM도 가득 찰 경우 기존에는 요청을 대기시키거나 기존 캐시를 퇴출(eviction)하는 방법밖에 없었다. 퇴출된 캐시는 재계산이 필요하다.

v0.26.0: 오브젝트 스토어를 3차 티어로

v0.26.0은 오브젝트 스토어(S3, GCS, Azure Blob Storage 등)를 KV 캐시의 3차 오프로딩 대상으로 추가했다. 핵심 설계 원칙은 다음과 같다.

• TP1 정규 형식 저장: TP(Tensor Parallelism) rank에 상관없이 KV 값을 TP1 형식으로 통일해 저장한다. 나중에 다른 TP 설정에서 읽어도 문제없다.
• 워크로드 아이덴티티 기반 인증: AWS IAM Role, GCP Workload Identity 등을 사용해 서비스 계정 키 없이 인증한다.
• DP 복제본 인식 티어링: 데이터 병렬(DP) 복제본 여러 개가 같은 오브젝트 스토어를 공유할 때 불필요한 중복 쓰기를 피하는 로직이 추가됐다.
• 오프로딩 메트릭: 티어별 히트율, 오프로딩 대역폭, 복원 지연 시간이 메트릭으로 노출된다.
• 인코더 캐시 커넥터: 멀티모달 인코더(이미지, 오디오) 캐시도 동일한 티어링 메커니즘으로 관리할 수 있다.

운영 판단 기준

오브젝트 스토어 KV 오프로딩이 유용한 상황:

• 긴 컨텍스트 서빙 (64K 토큰 이상): CPU DRAM만으로는 충분하지 않고 GPU 추가가 비용 대비 비효율
• 프리픽스 캐싱 재활용 비율이 높은 워크로드: 동일한 시스템 프롬프트가 많은 챗봇, 코드 자동완성 서비스
• 쿠버네티스 클라우드 환경: Workload Identity가 이미 구성된 경우 추가 자격증명 없이 연결

주의할 점:

• 오브젝트 스토어 접근 지연은 수십~수백 ms 수준이다. GPU VRAM 접근(μs)이나 CPU DRAM 접근(ms)보다 느리다. 캐시 히트율이 낮은 워크로드에서는 성능이 오히려 나빠질 수 있다.
• TP1 정규화 저장은 TP를 변경해 재시작해도 캐시를 재사용할 수 있는 장점이 있지만, 직렬화/역직렬화 오버헤드가 발생한다.

신규 모델: TML Inkling

Inkling이란

TML Inkling(Thinking Machines Lab)은 1조(1T) 파라미터 오픈웨이트 모델이다. 아키텍처 특징:

• 네이티브 멀티모달: 텍스트, 이미지, 오디오를 동시에 처리. 학습 시작부터 멀티모달.
• 최대 1M 토큰 컨텍스트
• 혼합 아키텍처: 상대적 어텐션(relative attention) + 쇼트 컨볼루션 + MoE(Mixture of Experts)
• Hopper FA4 최적화: H100 기준 상대적 어텐션에 특화된 FlashAttention 4 커널 적용

vLLM은 이 모델의 Day-0 지원을 선언했다. 지원 기능:

4× GB200에서 MTP 적용 시 약 380 tok/s/user를 달성한다고 vLLM 팀이 발표했다.

왜 Inkling이 v0.26.0과 함께 나왔나

Inkling의 혼합 어텐션 구조는 v0.25.0 이하에서 단일 어텐션 백엔드 제약 때문에 서빙할 수 없었다. v0.26.0의 그룹별 어텐션 백엔드 변경이 선행되어야 Day-0 지원이 가능했다.

DeepSeek-V4 성능 최적화

v0.26.0은 DeepSeek-V4 서빙에 세 가지 최적화를 추가했다.

1. 전문가 라우팅 커널

• 기존 라우팅 연산을 특화된 커널로 교체
• E2E TPOT(Time Per Output Token) 기준 2.94% 감소

2. fused_topk_bias

• TopK 선택과 bias 추가를 단일 커널로 통합
• 커널 단독 측정 1.5–2× 속도 향상

3. 중복 repeat/copy 제거

• MoE 라우팅 경로에서 불필요한 텐서 복사 연산 제거
• E2E TPOT 기준 1.8% 추가 감소

Rust 프론트엔드 확장

v0.26.0에서 Rust로 작성된 HTTP/API 서버 프론트엔드에 두 가지 기능이 추가됐다.

멀티모달 비디오·오디오 지원 기존 Rust 프론트엔드는 텍스트와 이미지만 처리했다. 비디오 프레임 시퀀스와 오디오 입력을 처리하는 경로가 추가됐다. Inkling처럼 오디오 입력을 지원하는 모델을 Rust 프론트엔드로 서빙할 수 있다.

네이티브 vllm-bench 기존 벤치마킹 도구는 Python으로 작성되어 있었다. Rust 프론트엔드에 vllm-bench가 통합되면서 Python 인터프리터를 거치지 않고 서빙 성능을 측정할 수 있다. 클라이언트 측 오버헤드가 제거되어 레이턴시 측정이 더 정확해진다.

Seed-OSS 도구 파서 Seed-OSS(오픈소스 코드 생성 모델) 계열의 함수 호출 형식을 파싱하는 Seed-OSS 도구 파서도 Rust 프론트엔드에 추가됐다.

의존성 업데이트

FlashAttention 3 stable-ABI 전환의 의미

이전 FlashAttention 3은 특정 CUDA 버전과 결합된 빌드를 사용해 환경마다 호환성 문제가 발생했다. stable-ABI 빌드는 CUDA 버전 변화에 독립적으로 동작하도록 설계됐다. 컨테이너 이미지 빌드 시 CUDA 버전 고정 필요성이 줄어든다.

제거된 모델

v0.26.0에서 세 모델이 제거됐다.

이 모델을 사용 중이라면 v0.25.x를 유지하거나, 다른 모델로 마이그레이션을 검토해야 한다.

운영 업그레이드 체크리스트

업그레이드 전 확인

• [ ] 현재 서빙 중인 모델 목록에 TeleChat, Persimmon, Fuyu가 있는지 확인
• [ ] FlashAttention 3 안정 ABI 빌드 호환성 검증 (CUDA 12.1 이상 권장)
• [ ] 오브젝트 스토어 오프로딩 사용 계획이 있다면 Workload Identity 설정 사전 확인
• [ ] Transformers 5.13.0 의존성 호환성 확인 (모델 별 커스텀 코드 있는 경우)

업그레이드 후 검증

• [ ] DeepSeek-V4 서빙 중이라면 E2E TPOT 변화 모니터링 (2–5% 개선 예상)
• [ ] 슬라이딩 윈도우 모델 서빙 시 어텐션 백엔드가 올바르게 선택됐는지 로그 확인
• [ ] vllm-bench(Rust 네이티브)로 레이턴시 재측정 — Python bench 대비 측정값 차이 파악

오브젝트 스토어 티어링 도입 시

• [ ] S3/GCS 버킷에 대한 Workload Identity 권한 설정
• [ ] DP 복제본 수와 티어링 정책 조합 테스트 (복제본이 동일 KV를 중복 쓰지 않는지)
• [ ] 오프로딩 메트릭 대시보드 구성 (히트율, 복원 지연 모니터링)

Open question

• vLLM v0.26.0의 정확한 릴리스 일자는 2026년 7월 하순으로 추정되지만, GitHub 릴리스 날짜 기준 공식 일자는 확인 필요.
• 오브젝트 스토어 KV 오프로딩의 실제 효용은 오프로딩 지연과 네트워크 대역폭에 크게 의존한다. 워크로드별 캐시 히트율 측정 없이는 도입 효과를 예측하기 어렵다.
• Inkling 1T 모델의 4× GB200 기준 380 tok/s/user 수치는 vLLM 팀의 내부 테스트 기준이며, 실제 워크로드 조건(배치 크기, 컨텍스트 길이, 멀티모달 입력 비율)에 따라 다를 수 있다.
• TeleChat, Persimmon, Fuyu 모델의 커뮤니티 지원 경로(별도 포크 등)는 현재 미확인.

References

• Release v0.26.0 · vllm-project/vllm — GitHub
• vLLM v0.26.0 릴리스 발표 — vLLM on X
• TML Inkling Day-0 Support in vLLM — vLLM Blog
• Welcome Inkling by Thinking Machines — Hugging Face Blog
• RFC: Multi-tier KV offloading via the vLLM offloading connector — GitHub Issue #38260
• Inside vLLM's New KV Offloading Connector — vLLM Blog
• Predictive Multi-Tier Memory Management for KV Cache — arXiv 2604.26968
• vLLM Production GPU Cluster Architecture 2026 — Markaicode