vLLM x Novita AI: PegaFlow for Production-Grade External KV Cache

TL;DR

Novita AI와 협업하여, PegaFlow는 vLLM과 외부 KV 캐시 서비스로 통합됩니다. 이는 독립적인 Rust 프로세스로 구현된 KV 캐시 서비스를 제공하여 KV 캐시 수명을 vLLM 워커 프로세스에서 분리하고, 로컬 인스턴스와 원격 노드 간에 캐시를 풀링하며, 고정된 호스트 메모리, RDMA 접근 가능한 원격 메모리, SSD를 결합한 3단계 캐시 계층을 구현합니다.

Why KV cache needs a process boundary

KV 캐시는 프로덕션 LLM 서빙에서 가장 비용이 많이 드는 런타임 자원 중 하나로, 호스트당 수백 GiB에 달하고 할당 및 워밍에 시간이 소요되며, 이를 생성한 요청 패턴보다 오래 지속됩니다. 전통적인 인-프로세스 설계에서는 KV 캐시가 추론 엔진 프로세스와 밀접하게 결합되어 있어, 엔진 충돌, 롤링 업그레이드, 모델 전환 시 엔진 재시작과 함께 호스트 KV 풀이 사라지는 문제를 일으킵니다. PegaFlow는 KV 캐시 런타임을 각 머신의 독립 데몬으로 이동시켜 호스트 KV 풀, SSD 캐시, 토폴로지 메타데이터, RDMA 자원, 인덱싱 상태, 백그라운드 작업을 소유하게 하고, vLLM 워커는 CUDA IPC와 gRPC를 통해 연결합니다. 이 설계는 하나의 캐시 서버가 동일 호스트 내 여러 엔진 및 모델을 서비스하도록 하여 네임스페이스 격리를 제공하면서도 동일 메모리 풀, SSD 용량, 노드 간 네트워크 대역폭을 공유하게 하여 실패 도메인을 보다 깔끔하게 만듭니다.

Faster restarts with external cache ownership

호스트 KV 풀 소유권이 시작 경로에 미치는 영향을 격리하기 위해, 더미 가중치와 eager 모드로 TP8을 사용한 Qwen3-8B를 8 x RTX 5090 환경에서 측정했습니다. 내장 KV 캐시 설계에서는 vLLM이 준비 상태에 도달하는 데 71.4초가 걸렸습니다. PegaFlow를 사용하면 독립 서버가 준비된 후 vLLM이 준비 상태에 도달하는 데 33.2초가 걸렸으며, 이는 장기 호스트 캐시 할당을 추론 프로세스 수명 주기와 분리함으로써 2.15배 빠른 시작 경로를 제공합니다.

Rust data path and tail-latency stability

KV 캐시를 외부 프로세스로 이동한 주된 이유는 라이프사이클 관리, 공유, CPU 자원 격리였습니다. 이 프로세스를 Rust로 구현하면 Python 인터프리터 오버헤드, GIL 경쟁, 전역 가비지 컬렉션을 피할 수 있는데, 이는 프로덕션 캐시 서비스가 통계 수집, 인덱스 업로드, 프리패치, 헬스 체크, 메트릭 보고, eviction, SSD 캐시 관리와 같은 백그라운드 작업을 수행하기 때문에 중요합니다. PegaFlow에서는 이러한 작업이 동일한 독립 Rust 서비스 내에서 실행되며, vLLM과 인터프리터 런타임을 공유하지 않으므로 데이터 플레인 경로를 방해하지 않고 컨트롤 플레인 및 유지보수 작업을 수행할 여유가 더 많아집니다.

Pooling cache across instances and nodes

프로덕션 배포에서는 프로세스, 모델, 노드 경계 때문에 동일 논리 KV 내용이 여러 번 복제되는 경우가 많습니다. PegaFlow는 이러한 격리된 캐시 조각을 공유 캐시 풀로 전환합니다. 단일 호스트에서는 모든 로컬 인스턴스가 동일 PegaFlow 서버에 연결해 하나의 CPU KV 풀을 공유합니다. 호스트 간에는 PegaFlow MetaServer가 근사 전역 인덱스를 유지해 노드가 원격 KV 블록을 일방향 RDMA READ로 가져올 수 있게 하며, 연결 설정 이후 원격 측에서는 CPU 개입이 없습니다.

Single-node multi-instance sharing

우리는 동일 500 GiB 캐시 예산으로 한 호스트에서 8개의 Qwen3-8B 인스턴스를 평가했습니다.

Setup	Cache layout	Throughput	Mean TTFT	Request hit rate
PegaFlow	500 GiB 공유 풀	11.97 req/s	5.26 s	52.35%
In-process	8 × 62.5 GiB 격리 풀	7.68 req/s	8.22 s	11.77%
Throughput는 56% 향상되고, 평균 TTFT는 36% 감소했으며, 요청 히트율은 4.4배 증가했습니다.

MLA logical KV deduplication

우리는 또한 500 GiB 캐시 예산 하에 TP8을 사용한 DeepSeek-V3.2 MLA를 평가했습니다.

Setup	Cache layout	Throughput	Mean TTFT	Request hit rate
PegaFlow	논리 KV를 한 번만 저장	1.81 req/s	35.66 s	97.23%
In-process	TP 랭크당 KV 저장	1.05 req/s	60.88 s	65.18%
Throughput는 72% 향상되고, 평균 TTFT는 41% 감소했으며, 요청 히트율은 트레이스의 실질적 상한에 근접했습니다.

Cross-node RDMA sharing

노드당 8 × 400 Gbps RDMA NIC가 장착된 내부 프로덕션 추론 클러스터에서 수천 건의 최신 온라인 원격 읽기를 샘플링했습니다. 1 GiB 이상 대형 프리픽스 풀에 대해, PegaFlow는 프로덕션 트래픽 하에서 평균 194 GB/s의 유효 처리량을 유지했으며, P99는 250 GB/s, 피크는 261.6 GB/s였습니다. 이 전송 속도에서는 24 GiB KV 캐시 세그먼트를 원격 노드에서 약 100 ms에 가져올 수 있어, GPU 시간을 초 단위로 소모하던 프리필 계산을 대체합니다.

Three-level cache hierarchy

풀링을 통해 캐시 용량 활용도가 높아지지만, 호스트 메모리는 여전히 제한적입니다. PegaFlow는 3단계 캐시 계층으로 이를 해결합니다: 뜨거운 로컬 블록은 고정 DRAM에 머무르고, 원격 히트는 RDMA로 가져오며, 차가운 재사용 가능한 블록은 로컬 SSD에 스필됩니다.

Level	Medium	Access path	Typical role
L1	Local pinned DRAM	Local memory	Fast local KV reuse
L2	Remote DRAM	RDMA READ	Cross-node cache sharing
L3	Local SSD	io_uring	Large-capacity spillover
SSD 캐시는 io_uring 위에 Rust로 구현되었습니다. 내부 테스트에서 단일 SSD는 약 6.9 GB/s 피크 읽기 처리량을 제공했으며, PegaFlow는 디스크당 6.5‑6.6 GB/s 수준의 온라인 지속 처리량을 유지했습니다.
여러 디스크에 RAID0를 적용하면 총 처리량이 거의 선형적으로 확장됩니다.
스캔이 많은 워크로드나 캐시 예산이 작은 호스트에서는 TinyLFU 입장 정책을 활성화해 재사용 가능성이 높은 블록만 받아들여 일회성 트래픽으로부터 캐시를 보호할 수 있습니다.
TinyLFU는 기본적으로 비활성화되어 있으며, 최적 입장 정책은 워크로드 형태에 따라 달라집니다.

Measuring distance from the theoretical hit-rate ceiling

온라인 히트율만으로는 오해의 소지가 있습니다. PegaFlow는 HyperLogLog을 사용해 이론적 히트율 상한을 온라인으로 추정합니다:

r* = (N - U) / N

여기서 N은 윈도우 내 전체 블록 요청 수, U는 처음 본 고유 블록 수입니다. HyperLogLog은 이 추정을 저비용으로 유지합니다: 24시간 윈도우는 1 MiB 미만의 메모리와 약 0.8% 오차를 가집니다. PegaFlow는 기본값이 15분, 1시간, 24시간인 롤링 HLL 윈도우를 내보냅니다. 측정된 히트율과 이론적 상한을 동일 대시보드에 배치하면 운영자는 다음 세 경우를 구분할 수 있습니다:

• 캐시가 이미 워크로드 상한에 가깝다면 용량을 늘려도 큰 효과가 없을 수 있습니다.
• 측정 히트율이 상한보다 크게 낮다면 용량, 입장 정책, 프리패치, 혹은 노드 간 탐색을 개선할 여지가 있습니다.
• 이론적 상한 자체가 낮다면 워크로드 재사용이 제한적이며 병목이 캐시 구현이 아니라는 의미입니다.

Integrating with vLLM through the external connector

외부 KV 캐시 시스템은 종종 스케줄러, 블록 매니저, 어텐션 커널에 침투적인 변경을 요구합니다. PegaFlow는 대신 vLLM의 외부 KV 커넥터 메커니즘을 통해 통합됩니다. 커넥터는 kv_transfer_config를 통해 설정되며, 외부 패키지는 kv_connector_module_path로 동적으로 로드할 수 있습니다. 이를 통해 PegaFlow는 vLLM 소스 코드를 수정하거나 장기 포크를 유지하지 않고도 런타임에 핵심 KV 캐시 작업을 인계받을 수 있습니다. vLLM 입장에서 PegaFlow는 서빙 엔진을 대체하는 것이 아니라 KV 전송 인터페이스를 통해 연결된 외부 캐시 백엔드이며, vLLM은 스케줄링, 모델 실행, 배칭, OpenAI 호환 서빙 경로를 계속 담당합니다. 이 경계는 양 프로젝트 모두에 유용합니다: PegaFlow는 Rust 데이터 플레인, SSD 캐시, RDMA 경로, 인덱싱, 커넥터 로직을 독립적으로 발전시킬 수 있고, vLLM은 핵심 서빙 엔진을 개선하면서 외부 캐시 시스템을 위한 안정적인 커넥터 계약을 제공할 수 있습니다.

Quick start

CUDA 버전에 맞는 패키지를 설치합니다:

uv pip install pegaflow-llm        # CUDA 12
uv pip install pegaflow-llm-cu13   # CUDA 13

고정 호스트 메모리와 SSD 캐시를 사용해 단일 노드 PegaFlow 서버를 시작합니다:

pegaflow-server \
  --pool-size 30gb \
  --ssd-cache-path <ssd-cache-file-path> \
  --ssd-cache-capacity 512gb

온라인 배포에서는 --use-hugepages 옵션을 추가하는 것을 권장합니다. Huge page는 미리 예약해 두어야 합니다. 멀티 노드 배포에서는 먼저 MetaServer를 시작하고, 각 노드에서 RDMA 설정과 함께 PegaFlow 서버를 시작합니다. P2P가 활성화된 경우 각 PegaFlow 서버의 --addr는 라우팅 가능한 IP 주소여야 하며, 0.0.0.0이나 127.0.0.1이 될 수 없습니다. 다른 노드가 gRPC 핸드쉐이크와 블록 질의를 위해 이 주소를 사용하기 때문입니다.

pegaflow-metaserver --addr 0.0.0.0:50056

pegaflow-server \
  --addr this-node:50055 \
  --pool-size 30gb \
  --ssd-cache-path <ssd-cache-file-path> \
  --nics mlx5_0 mlx5_1 \
  --metaserver-addr http://metaserver-host:50056

vLLM을 수정 없이 연결합니다. 이 글의 예시는 vllm>=0.20.0을 사용합니다:

vllm serve <model> \
  --kv-transfer-config '{
    "kv_connector": "PegaKVConnector",
    "kv_role": "kv_both",
    "kv_connector_module_path": "pegaflow.connector"
  }'

PEGAFLOW_HOST와 PEGAFLOW_PORT 환경 변수는 커넥터가 PegaFlow 서비스에 연결하도록 지정합니다. 기본값은 각각 http://127.0.0.1와 50055입니다.

Public reference benchmark

PegaFlow 레포지토리에는 H800에서 Llama-3.1-8B를 사용한 공개 KV 캐시 벤치마크도 포함되어 있습니다. 8개의 프롬프트, 10K 토큰 프리필, 1 토큰 디코드, 4.0 req/s 조건입니다. 이 설정에서 워밍 캐시 경로는 평균 TTFT를 572.5 ms에서 61.5 ms로 감소시키고, P99 TTFT는 1113.7 ms에서 77.0 ms로 낮춥니다.

Try PegaFlow

PegaFlow는 GitHub에서 확인할 수 있습니다: novitalabs/pegaflow. 레포지토리에는 설치 안내, 서버 설정, P2P RDMA 구성, 메트릭 문서, vLLM 커넥터 예제가 포함되어 있습니다.

Acknowledgements

Novita AI 팀에게 PegaFlow를 구축하고 프로덕션에 적용해 준 것에 감사드리며, vLLM 유지보수자와 광범위한 vLLM 커뮤니티에도 토론, 리뷰, 커넥터 인프라 제공에 감사드립니다.