vLLM native KV offloading secondary tier backed by the MemKV context memory store (TieringOffloadingSpec).
Project description
memkv-vllm
MemKV secondary tier for vLLM's native KV offloading feature
(OffloadingConnector + TieringOffloadingSpec). vLLM offloads completed KV
blocks from GPU to a pinned CPU pool; this plugin adds a memkv tier behind
that pool, so blocks evicted from CPU (or produced by another vLLM instance)
are served from a shared MemKV cluster over RDMA instead of being recomputed.
This is MemKV's third vLLM-adjacent integration and does not replace the
others: lmcache-plugin/ (LMCache connector path, current production
recommendation) and plugin/ (NIXL storage backend for Dynamo KVBM).
Requirements
- vLLM main at or after commit
6cf7b26bd(v0.23.1rc1.dev962). The tiering framework (vllm.v1.kv_offload.tiering) has shipped in releases since v0.22.0, but the secondary-tier API this plugin implements (LookupResult lookups, ScheduleEndContext, get_stats/build_metric_definitions) is newer than the latest stable release (v0.24.0); it first appears in the v0.25.0 release candidates. The offloading spec API is experimental upstream; this plugin pins to the commit range noted inplans/VLLM-TIERING-PLUGIN-PLAN.md. - Linux with RDMA userspace (
libibverbs,ibverbs-providers) for the data path. The client falls back to TCP where RDMA is unavailable. PYTHONHASHSEEDpinned (e.g.0) on every vLLM instance that should share KV — vLLM's block content hashes are seeded per process otherwise.
Install
pip install memkv-vllm
The wheel registers itself via the vllm.general_plugins entry point
memkv_tier — no vLLM patches, no extra flags. If you restrict plugins with
VLLM_PLUGINS, include memkv_tier in the list.
Configure
MemKV connection settings come from the standard MEMKV_CONFIG yaml or
MEMKV_* env-var chain (MEMKV_SERVERS, MEMKV_AUTH_KEY, …) — identical to
the other MemKV plugins. The tier entry in secondary_tiers carries only
tier tuning:
PYTHONHASHSEED=0 vllm serve <model> \
--kv-transfer-config '{
"kv_connector": "OffloadingConnector",
"kv_role": "kv_both",
"kv_connector_extra_config": {
"spec_name": "TieringOffloadingSpec",
"cpu_bytes_to_use": 10737418240,
"block_size": 256,
"secondary_tiers": [
{"type": "memkv", "n_read_threads": 8, "n_write_threads": 8}
]
}
}'
| Tier config key | Default | Meaning |
|---|---|---|
type |
— | Must be "memkv". |
prefix |
"" |
Key-namespace prefix inside MemKV (multi-fleet separation). |
n_read_threads |
8 |
Load-priority I/O threads (promotions, TTFT-critical). |
n_write_threads |
8 |
Store-priority I/O threads (cascades). |
blocks_per_op |
8 |
Max blocks per batched client call. |
load_failure_grace_s |
60 |
Withhold a failed load's completion from vLLM for this long, keeping its target slots pinned so a server write abandoned by a client timeout cannot land in reused memory. 0 disables. |
max_store_backlog_mb |
2048 |
Shed store jobs once this much store work is queued/in flight, so a slow MemKV cannot pin the CPU pool solid. Shed blocks just skip MemKV; loads are never shed. Keep below cpu_bytes_to_use/2. |
Sizing notes: block_size (offloaded block, in tokens) controls the MemKV
value size — prefer values ≥ 1 MiB (long blocks) so reads are
bandwidth-bound, not per-key-overhead-bound. cpu_bytes_to_use is the CPU
tier working set; MemKV only sees traffic once blocks cascade (immediately on
store) and promote (on CPU-tier misses).
How it maps
One MemKV value per (block hash, KV cache group): the full offloaded block
across all TP ranks (stride bytes of the CPU pool). Keys reuse vLLM's
FileMapper naming — <prefix>/<model>_<configdigest>…/<hash>.bin — so runs
with the same model/layout share blocks and incompatible layouts can't
collide. Lookups are batched async exists probes (one round per scheduler
step); stores/loads are chunked batch_put_views/batch_get_into calls
straight against the pool slots (no Python-side copies). Capacity is governed
server-side by MemKV lane eviction; a value evicted between lookup and load
degrades to recompute, never corruption.
Test
cargo build -p memkv # loopback server binary for the fixture
maturin develop --manifest-path vllm-plugin/Cargo.toml
pytest vllm-plugin/tests -v # requires vllm importable; Linux for data path
Project details
Release history Release notifications | RSS feed
Download files
Download the file for your platform. If you're not sure which to choose, learn more about installing packages.
Source Distributions
Built Distributions
Filter files by name, interpreter, ABI, and platform.
If you're not sure about the file name format, learn more about wheel file names.
Copy a direct link to the current filters
File details
Details for the file memkv_vllm-1.0.4-cp38-abi3-manylinux_2_28_x86_64.whl.
File metadata
- Download URL: memkv_vllm-1.0.4-cp38-abi3-manylinux_2_28_x86_64.whl
- Upload date:
- Size: 1.5 MB
- Tags: CPython 3.8+, manylinux: glibc 2.28+ x86-64
- Uploaded using Trusted Publishing? No
- Uploaded via: twine/6.2.0 CPython/3.10.20
File hashes
| Algorithm | Hash digest | |
|---|---|---|
| SHA256 |
0ddd88d385667f8f35cc9faf5f189a8e07953817cb9a1f7214563bf80f335cab
|
|
| MD5 |
c791deb2301f00dec37f70a1f03877cb
|
|
| BLAKE2b-256 |
7f781e2b68dd3aac81351343afda1f9334f969a1422df57ca44abf5c2b2536ec
|
File details
Details for the file memkv_vllm-1.0.4-cp38-abi3-manylinux_2_28_aarch64.whl.
File metadata
- Download URL: memkv_vllm-1.0.4-cp38-abi3-manylinux_2_28_aarch64.whl
- Upload date:
- Size: 1.4 MB
- Tags: CPython 3.8+, manylinux: glibc 2.28+ ARM64
- Uploaded using Trusted Publishing? No
- Uploaded via: twine/6.2.0 CPython/3.10.20
File hashes
| Algorithm | Hash digest | |
|---|---|---|
| SHA256 |
c1dc30a30c75d5400c112a6fa4af8c0d4314500b7e9b0c36d2ff7054f27e44cc
|
|
| MD5 |
9a24ddaf487fbc39ec8a1003ad5634d3
|
|
| BLAKE2b-256 |
5c580a52bb0971f3b879e8c99e66281691b26c6946ceffc6f0799a8dc3718712
|