2026-06-07 — 회 조회

vLLM 0.22, 다중 계층 KV 캐시 오프로딩 추가: 장문맥 로컬 서빙을 위한 GPU에서 CPU 그리고 디스크로

vLLM 0.22.0(2026년 5월 29일)은 캐시된 블록을 CPU DRAM 너머 디스크까지 캐스케이드하는 다중 계층 KV 캐시 오프로딩 프레임워크를 출시했으며, Python 파일시스템 계층과 Mooncake 디스크 백엔드를 갖췄다. 6월 5일 패치는 몇 가지 모델 및 AMD-CPU 수정을 추가했다. 128K-token 문맥을 서빙하는 단일 박스 로컬 리그에서, prefill을 재계산하는

무엇이 출시되었나

2026년 5월 29일에 태그된 vLLM 0.22.0은 네이티브 다중 계층 KV 캐시 오프로딩 프레임워크(PR #40020)를 안착시켰다. 지금까지 vLLM은 key/value 캐시를 GPU 메모리에서 CPU DRAM으로 흘려보냈다가 다시 가져올 수 있었지만, 그것이 막다른 길이었다. 호스트 RAM이 가득 차면 블록은 축출되고 prefill은 재계산되어야 했다. 새 프레임워크는 CPU DRAM을 단일 주(primary) 계층으로 취급하고, 그 뒤에 하나 이상의 보조(secondary) 계층——로컬 파일시스템, 오브젝트 스토리지, key-value 스토어, 또는 원격 노드——을 둘 수 있게 한다. 이번 릴리스는 첫 구체적 백엔드로 Python 파일시스템 보조 계층(PR #41735)과 Mooncake 디스크 오프로딩(PR #42689)을 추가했고, 함께 DeepSeek V4 지원(PR #43142)도 더했다.

2026년 6월 5일 패치인 0.22.1은 더 작은 후속이다. JetBrains의 Mellum v2 코드 MoE를 추가하고, AMD Zen CPU에서 int8 및 GPTQ 선형 연산을 zentorch kernels를 통해 라우팅하며, DeepSeek-V4 CUTLASS 초기화 깨짐을 수정한다. 단일 박스에서 장문맥을 돌리는 누구에게나 핵심 기능은 0.22.0에 있다.

계층화는 어떻게 작동하는가

이 설계(RFC #38260)는 스케줄러 프로세스 안에서 실행되는 TieringManager와 각 백엔드가 구현하는 SecondaryTierManager 인터페이스를 도입한다. 오케스트레이션 규칙은 “항상 캐스케이드”다. 어떤 블록이 CPU DRAM에 있다고 확인되면, 매니저는 그것을 등록된 모든 보조 계층으로 비동기적으로 밀어 내리며, CPU 텐서에 대한 zero-copy 뷰를 사용하므로 스케줄러는 I/O로 절대 블로킹되지 않는다. 어떤 요청이 DRAM에서 노후화되어 사라진 블록을 필요로 하면, 매니저는 새로운 prefill을 트리거하는 대신 보조 계층에서 그것을 위로 승격시킨다. 블록은 정규 CPU 레이아웃(TP rank 1 형식)으로 저장되며, 바로 이것이 어떤 tensor-parallel 정도에서 기록된 캐시를 다른 정도에서 재사용할 수 있게 해 준다.

경제성은 단순하다. GPU HBM은 약 3.35 TB/s로 데이터를 옮긴다. PCIe 4.0 NVMe 드라이브는 약 7 GB/s에 자리하며 1밀리초 미만의 지연을 가진다. 그 격차는 잔혹해 보이지만, 그것은 대안과 비교하기 전까지의 이야기다. 대안은 “HBM에서 읽기”가 아니라 “전체 prefill을 재계산하기”다. 프롬프트가 길어지면, 디스크에서 미리 계산된 블록을 로드하는 것이 재계산을 손쉽게 이긴다.

왜 이것이 로컬 리그에 중요한가

2026년의 현실은 128K——심지어 1M-token 윈도우조차 평범한 워크로드이며, 카드를 잡아먹는 것은 KV 캐시라는 점이다. 아래는 H100 급 카드에서 70B 모델을 128K 문맥으로 서빙한 독립 벤치마크에서 가져온 대략적인 단일 박스 그림이다.

구성	128K에서의 대략적인 동시 사용자 수
GPU HBM만	~1
FP8 KV + CPU swap + 디스크 오프로드	~8-10

같은 출처는, prefill이 재계산되는 대신 디스크에서의 캐시 히트로 제공될 때, 128K 시스템 프롬프트에 대한 time-to-first-token이 약 11초에서 약 1.5초로 떨어진다고 인용한다. (이 수치들은 어느 호스팅 업체의 2026년 4월 글에서 나온 것이며 vLLM 자체의 수치가 아니므로, 그 배수는 방향성으로 받아들일 것.) 셀프 호스팅 운영자에게 실질적인 해금은, 고정된 시스템 프롬프트나 긴 검색 문서를 더 이상 매 요청마다 지불할 필요가 없다는 점이다——그것은 SSD에 존재하며 필요할 때 다시 승격되어 돌아온다.

같은 릴리스는 애초에 GPU 상의 풋프린트를 더 작게 만드는 양자화 경로도 조였다. batch-invariant Cutlass FP8은 엔드투엔드 +28.9%를 주장하고(PR #40408), padded NVFP4 양자화 kernel은 +2.4에서 5.7%를 더한다(PR #42774). 더 작은 KV 블록에 더해 넘침을 둘 곳이 있다는 것——이 조합이야말로 단일 카드를 더 늘려 주는 것이다.

실무자 메모

만약 당신이 단일 GPU 박스를 쓰고 있고 병목이 순수한 토큰 처리량이 아니라 문맥 길이에 있다면, 여기서의 지렛대는 두 번째 GPU가 아니라 빠른 로컬 NVMe에 더해 파일시스템 계층 또는 Mooncake 계층이다. 캐시 히트 경로가 실제로 발화하도록, 현실적인 공유 프리픽스(시스템 프롬프트나 고정된 RAG 문서)로 벤치마크할 것. 차갑고 전부 고유한 워크로드는 당신에게 I/O 비용만 보여 줄 뿐 재계산 절감은 전혀 보여 주지 않는다. 디스크 계층을 활성화하기 전에 합당한 CPU DRAM 예산을 고정할 것——주 계층은 여전히 모든 블록이 거쳐 가는 스테이징 영역이다.

충분히 고려되지 않은 관점: 다중 계층 오프로딩은 “로컬” 배포의 위협 및 신뢰성 표면을 조용히 바꾼다. 이제 KV 블록은 디스크에 지속되며, 이는 당신의 프롬프트와 검색된 문맥의 내용이 요청의 수명을 넘어 SSD에 존재한다는 뜻이다——이는 캐시가 GPU 메모리와 함께 증발하던 때에는 존재하지 않았던 프라이버시 및 보존 고려 사항이다. 그리고 블록이 정규 TP-rank-1 레이아웃으로 저장되기 때문에, 오늘 구축한 캐시는 당신이 tensor-parallel 정도를 바꾸거나 서버를 재시작한 후에도 재사용될 수 있으며, 이는 KV 스토어를 덧없는 스크래치가 아니라 당신이 따져 보아야 할 지속적 상태(축출 정책, 디스크 압박, 오래된 항목)로 바꿔 놓는다. 가까운 미래의 흥미로운 질문은, 지속적이고 재시작을 넘나드는 KV 캐시가, 벡터 인덱스가 이미 그렇게 된 것처럼, 솔로 리그에서 관리되는 자산이 될 것인가이다.