LMCache: как вынести KV-cache из VRAM в RAM/NVMe и ускорить длинные LLM-сессии
Длинный prompt на 100–200 тысяч токенов может дорого стоить не только по памяти: после eviction или перезапуска inference server приходится снова выполнять prefill — заново прогонять весь старый контекст через модель. LMCache превращает KV-cache из временного GPU-состояния в отдельный persistent/reusable слой, который можно держать в CPU RAM, SSD/NVMe, Redis/Valkey, S3 и других backends и затем загружать обратно без полного повторного prefill.
LMCache не запускает модель — он сохраняет уже вычисленное внимание
vLLM, SGLang или другой inference engine всё равно загружает веса модели и выполняет inference. LMCache стоит рядом и занимается другим: он перехватывает готовые KV tensors, складывает их в отдельный cache layer и при следующем совпадающем контексте возвращает их обратно.
Это не KTransformers и не CPU-offload model weights.
Он помогает хранить/повторно использовать состояния уже допустимого контекста.
Нужен serving engine с LMCache integration.
Повторный decode не становится магически быстрее только из-за cache.
Без KV-cache модель пересчитывала бы прошлое на каждом следующем токене
При autoregressive generation attention layers используют Key/Value states для уже обработанных токенов. Runtime сохраняет их, чтобы на следующем token не выполнять полный attention pass по старой последовательности заново.
Фиксированный основной объём памяти модели.
Растёт вместе с tokens × sessions × architecture.
Нужны runtime во время вычисления.
Даёт больше virtual capacity за пределами GPU.
В обычном runtime KV-cache живёт в GPU memory. Когда места становится мало, старые blocks eviction'ятся. Если пользователь вернётся к этой session, engine снова обрабатывает длинный prefix. Именно этот повторный prefill LMCache пытается убрать.
Context tuning отвечает «сколько токенов держать», LMCache — «что делать с уже рассчитанным KV»
LMCache особенно силён на длинных повторяющихся contexts
Session постоянно возвращается к большому prefix из repo/system/tools context.
История растёт, а старый prefix повторяется почти дословно.
Одни и те же документы используются в разных запросах.
Standalone cache переживает lifecycle отдельных vLLM instances.
Cache hit почти отсутствует.
Повторный prefill дешевле, чем сложная storage hierarchy.
KV сначала нужно вычислить. Выигрыш появляется только тогда, когда тот же prefix/chunk реально используется снова.
KV-cache длинной session легко занимает десятки гигабайт
Official LMCache FAQ приводит ориентиры для популярных моделей: Qwen3-8B — около 0.1373 GB KV на 1000 tokens, Qwen3-32B — около 0.2441 GB/1000 tokens в указанной TP-конфигурации, Llama-3.1-70B — около 0.3052 GB/1000 tokens. Это reference values для конкретных engine/hardware settings, а не универсальные константы.
Если грубо масштабировать официальный 0.1373 GB/1K reference.
Reference TP=2/H100 configuration.
Reference TP=4/H100 configuration.
GQA/MQA, attention type, dtype, TP, hybrid Mamba/linear-attention groups и cache quantization заметно меняют расчёт.
LMCache лучше рассматривать как отдельный cache service, а не библиотеку внутри vLLM
Current quickstart поддерживает два режима, но MP mode официально рекомендован. LMCache запускается отдельным процессом, а inference engines подключаются к нему через connector.
Лучше масштабируется, имеет HTTP management/observability и умеет обслуживать несколько engines.
Проще для первого single-node experiment, но многие current docs считают этот path legacy/deprecated для продвинутых функций.
Отделение cache daemon от inference engine означает, что cache может пережить restart/crash serving process и использоваться несколькими engine instances, если model/cache geometry совместимы.
Установка
Current PyPI release 0.5.5 опубликован 12 сентября 2026.
Package metadata: Python >=3.10,<3.14,
POSIX/Linux и Apache-2.0.
uv venv --python 3.12
source .venv/bin/activate
uv pip install lmcache vllmOfficial current installation docs для full runtime требуют: Linux, современный accelerator runtime и совместимый vLLM/PyTorch stack. Для NVIDIA — compute capability 7.0+ и CUDA 12.1+ как общий baseline.
NIXL optional extra
uv pip install "lmcache[nixl]"NIXL нужен не каждому: он применяется для P2P/disaggregated prefill-decode и высокопроизводительного KV transfer.
Current compatibility guide прямо предупреждает: одной пары version numbers недостаточно. Нужно одновременно совпадение Python/PyTorch/accelerator ABI, connector API и validation конкретной model/feature.
Минимальная схема: LMCache server + vLLM connector
1. Запустить cache server
lmcache server \
--host localhost \
--port 5555 \
--l1-size-gb 20 \
--eviction-policy LRUProduction default chunk size — 256 tokens. В official quickstart меньшие 8/16 используются только чтобы cache traffic было видно на коротком demo prompt.
2. Запустить vLLM
vllm serve Qwen/Qwen3-8B \
--port 8000 \
--kv-transfer-config \
'{"kv_connector":"LMCacheMPConnector",
"kv_role":"kv_both",
"kv_connector_extra_config":{
"lmcache.mp.host":"localhost",
"lmcache.mp.port":5555
}}'Для vLLM ≥0.20 official docs рекомендуют при возможности использовать connector implementation, который ship'ится самим LMCache, потому что он быстрее получает новые protocol fixes/features:
vllm serve Qwen/Qwen3-8B \
--kv-transfer-config \
'{"kv_connector":"LMCacheMPConnector",
"kv_connector_module_path":"lmcache.integration.vllm.lmcache_mp_connector",
"kv_role":"kv_both"}'3. Проверить состояние
lmcache ping kvcache
lmcache describe kvcacheRequest endpoint по умолчанию — port 5555; HTTP management frontend — port 8080. Это важно для firewall и security.
Current quickstart поддерживает и SGLang integration
uv venv --python 3.12
source .venv/bin/activate
uv pip install --prerelease=allow lmcache sglangcat > lmc_config.yaml <<'EOF'
chunk_size: 256
local_cpu: true
use_layerwise: true
max_local_cpu_size: 10
EOF
export LMCACHE_CONFIG_FILE=$PWD/lmc_config.yaml
python -m sglang.launch_server \
--model-path Qwen/Qwen3-8B \
--host 127.0.0.1 \
--port 30000 \
--enable-lmcacheSGLang integration в current quickstart также ориентируется на MP architecture. При этом validation status конкретных новых hybrid models может отличаться от vLLM.
LMCache умеет строить реальную storage hierarchy
Идеален для hot sessions, но объём конечен.
Медленнее RAM, зато переживает engine restart и вмещает гораздо больше.
Подходит для нескольких nodes/engines.
Ещё больше capacity, но latency выше.
Для GPU/P2P/disaggregated serving.
Интеграции для production-scale cache fabric.
Current README перечисляет CPU RAM, local disk, Redis/Valkey, Mooncake, InfiniStore, S3-compatible storage, NIXL и GDS. Storage plugin framework позволяет добавлять собственные backends.
Cache hit экономит GPU prefill, но KV всё равно нужно прочитать со storage и передать в engine. Если restore latency выше cold recompute, cache становится бесполезным.
CacheBlend умеет повторно использовать chunks, даже если они находятся не в начале prompt
Традиционный prefix cache хорош, когда запросы начинаются одинаково. Но RAG часто собирает документы в разном порядке: один и тот же paragraph сегодня стоит первым, завтра третьим.
Лучше всего повторно используется начало A.
Может reuse repeated chunk B вне исходной prefix position.
lmcache server \
--l1-size-gb 20 \
--eviction-policy LRU \
--engine-type blendCacheBlend не просто безусловно вставляет старый KV. Он выборочно recompute'ит часть tokens на границах/смещённых позициях, чтобы восстановить quality.
Сначала добейтесь корректного ordinary prefix reuse, затем измерьте, есть ли у вашего RAG достаточный non-prefix repetition, чтобы blending оправдал сложность.
Agentic workloads держат огромный context и постоянно возвращаются к нему после tool calls
Именно такие workloads всё чаще обсуждаются в сообществах vLLM/LocalLLaMA: несколько параллельных coding/research agents, 100–200K+ tokens на session и желание вынести холодный context из дорогой GPU memory.
Пользователи сравнивают LMCache, native offload и custom storage layers.
Практические reports отмечают ценность восстановления evicted context без re-prefill.
Qwen hybrid/flash families усиливают спрос на external KV storage.
PCIe generation, RAM bandwidth, SSD, model architecture, chunk size, KV dtype и hit ratio полностью меняют итог.
Высокий hit rate сам по себе ещё не означает хороший пользовательский опыт
Current LMCache CLI уже имеет отдельные
bench, describe, ping,
cache inspection и checksum tools.
lmcache describe kvcache
lmcache ping kvcache
lmcache bench server \
--rpc-url tcp://localhost:5555 \
--url http://localhost:8080 \
--end 100Сколько ждём первый token после отправки request.
Нужен, но без latency мало о чём говорит.
Показывает, успевает ли RAM/NVMe за compute.
Без него нельзя понять, выгоден ли внешний cache.
Official benchmarking guide именно так и строит сравнение: baseline vLLM alone против vLLM + standalone LMCache.
На Windows LMCache лучше запускать через WSL2 или отдельный Linux server
Current PyPI package classifier — POSIX :: Linux. Full server использует CUDA extensions, POSIX shared memory и Linux-oriented serving ecosystem.
Ближе всего к official Linux path.
Windows PC остаётся client, vLLM/LMCache живут на server.
lmcache-cli работает без CUDACLI-only package может работать на любой ОС, но не запускает full cache server.
Если ваша локальная LLM живёт только в Ollama/LM Studio на Windows, LMCache не добавляется туда одной галочкой. Нужен совместимый serving engine — прежде всего vLLM/SGLang stack.
HTTP management frontend по умолчанию слушает 0.0.0.0:8080 и не должен быть публичным
Current MP HTTP API содержит не только health/status.
Среди diagnostic routes есть /env,
который показывает process environment,
и /run_script,
который выполняет caller-supplied Python внутри server process.
Official docs прямо говорят: environment dump без redaction/auth.
Docs прямо предупреждают: restricted builtins не являются security sandbox.
0.0.0.0Нужен firewall/private network или явный loopback bind.
Тоже не публиковать в internet без внешнего network isolation.
Безопасный single-host baseline
lmcache server \
--host 127.0.0.1 \
--port 5555 \
--http-host 127.0.0.1 \
--http-port 8080 \
--l1-size-gb 20 \
--eviction-policy LRUЕсли нужен remote management, используйте VPN/private network и отдельный reverse-proxy/auth layer. Сам LMCache current HTTP API не является hardened public admin panel.
У проекта есть SECURITY.md;
vulnerabilities просят отправлять maintainers по email.
На дату проверки публичных GitHub Security Advisories проект не показывает.
Совместимость конкретной модели и connector path нужно проверять, а не предполагать
LMCache быстро развивается:
stable 0.5.5 вышел 12 сентября,
а 20 сентября nightly уже имеет version line
0.5.6.dev54.
Количество model-specific recipes и hybrid-attention paths постоянно растёт.
В 0.5.3/0.5.4 + vLLM ≥0.26 reported disk restore мог давать высокий hit rate, но неправильный результат из-за incomplete KV geometry restore.
Reported idle worker reaping в data-parallel setup; issue отдельно проверял код 0.5.4.
Current issue list содержит model/IPC/MP reports уже на 0.5.5-era stack.
Они относятся к конкретным model/engine/connector/geometry combinations. Но именно поэтому перед production rollout нужен validation: cache hit должен давать тот же ответ/quality, что cold prefill, а не только красивый hit-rate metric.
Для новых hybrid models official recipes часто прямо указывают, какие engines, CacheBlend, compression и MTP combinations уже validated, а какие ещё нет.
Есть workloads, где LMCache добавит больше сложности, чем скорости
Нечего restore, если контекст ещё ни разу не вычислялся.
LMCache в первую очередь борется с повторным prefill.
Slow SSD может оказаться хуже recompute.
Уникальные prompts создают cache pollution вместо пользы.
Это инфраструктурный слой, а не простой Windows app.
LMCache/vLLM/PyTorch/model feature должны совпадать.
RAM/NVMe/network bandwidth становятся частью inference budget.
Высокий hit ratio не доказывает корректный restore на новом hybrid model.
Нужен ли LMCache именно вам?
Если только Ollama/LM Studio — сначала нужен другой serving stack.
Чем больше repeated prefill, тем выше потенциальный выигрыш.
Если нет — hit rate будет низким.
Измерить, а не предполагать.
Начать с L1 RAM — самый простой внешний tier.
Добавлять NVMe/remote backend.
Если restore не быстрее — cache tier не окупается.
Не усложнять систему раньше времени.
LMCache 0.5.5: MP architecture, storage, CacheBlend, security и compatibility
Stable PyPI release — 0.5.5 от 12 сентября.
Nightly 20 сентября уже использует line
0.5.6.dev54,
поэтому compatibility docs перед production install нужно перепроверять.
LMCache становится полезен тогда, когда context уже слишком дорог, чтобы постоянно считать его заново
Для домашнего chat с 8–16K context LMCache обычно избыточен. Для coding/research agents с 100K+, нескольких параллельных users, длинного RAG и production vLLM ситуация меняется: repeated prefill начинает стоить ощутимо дороже, чем хранение KV на более дешёвом tier.
Самая разумная последовательность: сначала L1 CPU RAM, измерить TTFT/hit ratio, затем NVMe или remote storage, и только потом CacheBlend/P2P/disaggregated serving.
LMCache не делает GPU быстрее. Он просто не заставляет GPU повторять вычисление, которое уже однажды было выполнено.
Частые вопросы про LMCache
Что такое LMCache простыми словами?
Отдельный слой хранения KV-cache для LLM inference: уже вычисленный контекст можно вынести из GPU в RAM/NVMe/remote storage и затем переиспользовать без полного повторного prefill.
LMCache увеличивает VRAM?
Нет. Он увеличивает эффективную/виртуальную ёмкость KV storage за счёт более дешёвых tiers, но GPU memory физически не становится больше.
Можно ли хранить KV на SSD?
Да. Local filesystem/NVMe — один из supported secondary backends. Но нужно сравнивать restore latency с cold prefill.
Работает ли с vLLM?
Да. Это основной integration path; current docs рекомендуют MP mode через LMCacheMPConnector.
Работает ли с SGLang?
Да. Current quickstart содержит SGLang integration и MP-oriented configuration.
Работает ли с Ollama?
Не как drop-in cache layer. LMCache рассчитан на поддерживаемые serving engines вроде vLLM/SGLang/TRT-LLM integration paths.
Нужен ли LMCache для одного короткого чата?
Обычно нет. Он особенно полезен при длинном context, нескольких sessions и повторном использовании больших prefixes/documents.
Работает ли на Windows?
Full runtime официально Linux-oriented. На Windows практичный путь — WSL2 или отдельный Linux server. CLI-only package может работать без CUDA на других ОС.
Почему нельзя просто включить vLLM prefix cache?
In-engine prefix cache ограничен lifecycle и GPU capacity конкретного engine. LMCache добавляет persistent external tiers, cross-engine reuse и non-prefix reuse через CacheBlend.
Какая версия актуальна?
На 21 сентября 2026 current stable PyPI release — LMCache 0.5.5 от 12 сентября.
Ваш coding-agent каждый раз заново прогоняет 100–200 тысяч токенов после eviction или restart?
Начните с измерения cold TTFT и cache hit rate. Если repeated prefill действительно является bottleneck, LMCache с CPU RAM — самый простой первый шаг, а NVMe/remote tiers добавляются уже после benchmark.
