# LMCache — кэш, который делает LLM заметно быстрее и чуть-чуть умнее

- Site: VeraPoint News
- Section: Инструменты
- Date: 2026-06-13
- Canonical: https://verapointmedia.com/tools/lmcache-lmcache/
- Markdown: https://verapointmedia.com/tools/lmcache-lmcache.md
- Summary: Разбираю LMCache — KV-cache слой, который ускоряет инференс LLM для длинных диалогов, RAG и агентов. Где реально помогает, а где маркетинг.
- SEO title: LMCache: рабочий процесс для AI-агентов и разработки
- SEO description: Разбираю LMCache — KV-cache слой, который ускоряет инференс LLM для длинных диалогов, RAG и агентов. Где реально помогает, а где маркетинг
- Target queries: LMCache; LMCache github; что такое LMCache; как использовать LMCache
- Tags: #lmcache #kv-cache #llm-inference #vllm #optimization #speed
- Image: https://verapointmedia.com/static/content-assets/tools/lmcache-lmcache/cover.webp

## Sources

- https://github.com/LMCache/LMCache
- https://lmcache.ai/
- https://blog.lmcache.ai/
- https://docs.lmcache.ai/

---

Представьте: вы разговариваете с чат-ботом, спрашиваете что-то про здоровый образ жизни — и он отвечает. Потом вы уточняете «а при чём тут режим сна» — и он снова задумывается на пять секунд. Хотя по сути ответ уже вытекает из предыдущего контекста.

Это не тупость модели и не плохой интернет. Это прямое следствие архитектуры: по умолчанию LLM держит весь разговор в оперативной памяти GPU. Как только контекст становится длинным — например, в чате с агентом, который анализирует документы — модель начинает тормозить. А если контекст переваливает за размер выделенного окна — она вообще теряет нить.

И вот тут появляется [LMCache](https://github.com/LMCache/LMCache) — и говорит: «давайте я просто сохраню этот контекст отдельно, как умный кэш-слой, и буду подкладывать его обратно при каждом запросе».

## Если просто

LMCache — это отдельная программа-демон, которая живёт рядом с движком инференса (vLLM, SGLang, Dynamo) и перехватывает промежуточные вычисления модели. А именно — то, что на техническом языке называется KV-кэш (key-value cache). Простыми словами: когда модель читает ваш промпт, она вычисляет для каждого токена его «смысловой вектор» и хранит его в памяти GPU, чтобы не пересчитывать заново при генерации следующих токенов.

LMCache предлагает не держать этот кэш только в дорогой GPU-памяти. Он выгружает его на уровни подешевле: CPU RAM, SSD, Redis или даже S3-совместимое хранилище. При следующем запросе он подсовывает готовый кэш обратно — и модель пропускает дорогостоящий этап prefill. Результат: первый токен появляется быстрее (это называют снижением TTFT — Time To First Token), а общая пропускная способность железа растёт.

На бумаге — звучит как магия. Но давайте посмотрим, где оно реально работает, а где пока сыровато.

## Что это решает

Главная боль, которую адресует LMCache — это повторяющиеся или длинные контексты. Три сценария, где это критично:

- **Многораундовые диалоги и агенты.** Агент делает пять запросов подряд к одной модели, каждый раз с нарастающим контекстом. Без кэширования модель каждый раз заново пережёвывает весь диалог с нуля. LMCache запоминает вычисленное и экономит до 70-80% времени prefill.
- **RAG с большими документами.** Вы загрузили в промпт 40 страниц инструкции. Модель их обработала и ответила. Следующий пользователь спрашивает про пункт 14 — и модель снова читает все 40 страниц. LMCache сохраняет однажды вычисленный кэш документа и переиспользует его для всех будущих запросов.
- **Общий системный промпт.** У вас есть один длинный системный промпт для всех пользователей (например, «ты — ассистент, который отвечает в стиле Чехова»). Каждый запрос к модели начинается с его обработки. LMCache кэширует его один раз и применяет ко всем сессиям.

Ребята из LMCache в своём блоге приводят цифры: на агентных нагрузках с длинными контекстами на AMD MI300X ускорение prefill до 10x. А для MoE-моделей (это архитектура типа Mixtral, где часть параметров активируется динамически) новая многопроцессная архитектура даёт прирост до 10 раз на инференсе. Это, конечно, лучший сценарий — но даже средние цифры впечатляют.

## Как это работает на верхнем уровне

Чтобы не уходить в дебри, опишу главное.

1. Вы запускаете LMCache как отдельный демон-процесс. Он независим от движка инференса — если vLLM упадёт, кэш не теряется.
2. Движок инференса (vLLM, SGLang, Dynamo) через специальный коннектор отправляет KV-кэш в LMCache при prefill и запрашивает его обратно при следующем запросе.
3. LMCache хранит кэш в многоуровневом хранилище: сначала быстрая CPU RAM (для горячих данных), потом SSD (для тёплых), потом Redis или S3 (для долгосрочного хранения и шаринга между нодами).
4. При повторном запросе LMCache проверяет совпадение префиксов — и если находит, подставляет готовый кэш, пропуская вычисления.

Интересный момент: LMCache умеет переиспользовать кэш не только для точных совпадений префиксов. Через модуль CacheBlend он может найти совпадение в середине промпта, подставить кэш, а недостающие токены быстренько пересчитать — это называется non-prefix KV reuse. На практике это значит, что даже если вы чуть-чуть изменили системный промпт или документ, модель не будет пересчитывать всё с нуля.

## Как попробовать

Установка элементарная:

```bash
pip install lmcache
```

Дальше нужно настроить коннектор для вашего движка инференса. Для vLLM это выглядит примерно так (упрощаю, но суть передаю):

```python
from lmcache.integration.vllm import LMCacheConfig

config = LMCacheConfig(
    storage_backend="cpu",  # или redis, s3, disk
    max_local_cache_size=10,  # GB
)
```

И передать этот конфиг при старте vLLM-сервера. В README есть ссылки на подробные рецепты — там всё довольно дружелюбно.

Что ещё стоит сразу глянуть:
- Страница [Quickstart](https://docs.lmcache.ai/getting_started/quickstart.html) в документации
- Раздел [Recipes](https://docs.lmcache.ai/recipes/index.html) с рабочими примерами под разные хранилища и движки
- [Production Deployment](https://docs.lmcache.ai/mp/deployment.html) для тех, кто хочет запускать в кластере

Если вы просто хотите оценить разницу руками, есть встроенный CLI для бенчмаркинга. Запускаете, задаёте длину контекста, включаете/выключаете LMCache — и сравниваете TTFT.

## 3 сценария с примерами

### Сценарий 1: SaaS с поддержкой пользователей через RAG-базу знаний
**Задача:** У вас SaaS-продукт, пользователи задают вопросы по документации. 200 страниц мануалов залиты в векторную базу. При каждом вопросе вы извлекаете релевантные 10 страниц и засовываете их в промпт вместе с вопросом.
**Как применить:** Поднимаете vLLM с LMCache, указываете LMCache кэшировать все промпты с длиной больше 2000 токенов. Первый пользователь запрашивает документацию по API — модель вычисляет кэш для 10 страниц. LMCache сохраняет его в Redis. Следующие 100 пользователей с похожими запросами получают ответ в 4-5 раз быстрее, потому что prefill уже сделан.
**Что получится:** TTFT снижается с 3-5 секунд до 0.5-1.5 секунды для повторяющихся кусков документации. При 1000 запросов в час экономия GPU-часов существенная.

### Сценарий 2: Долгий диалог с ассистентом-аналитиком
**Задача:** Пользователь ведёт с моделью диалог на 50 реплик, анализируя финансовый отчёт. Каждая реплика добавляет контекст, и к 30-му сообщению промпт раздувается до 15 000 токенов. Без кэша модель начинает «думать» по 10 секунд перед каждым ответом.
**Как применить:** Включаете LMCache в режиме multi-turn conversation. Он автоматически сохраняет кэш каждой реплики в CPU RAM. При каждой следующей реплике модель пересчитывает только новые токены от пользователя, а всё предыдущее обсуждение берёт из кэша.
**Что получится:** Вместо экспоненциального роста задержки — линейный рост. Пользователь не замечает тормозов даже на 80-й реплике.

### Сценарий 3: Автоматическая обработка входящих писем с общим контекстом
**Задача:** Компания обрабатывает 5000 входящих писем в день через LLM. У каждого письма один и тот же префикс-инструкция на 1000 токенов: «Ты — ассистент, классифицируй письмо по категориям A, B, C, выдели суть, проверь на спам...» Плюс 500 токенов корпоративной политики безопасности.
**Как применить:** LMCache настраивается на хранение кэша общего префикса в горячей CPU RAM. Все 5000 запросов начинаются с одного и того же префикса — модель вычисляет его один раз утром и дальше просто подставляет.
**Что получится:** 1500 токенов prefill, которые раньше вычислялись 5000 раз в день, теперь вычисляются один раз. Экономия — около 30% GPU-времени на инференсе.

## Где можно застрять

Первое и главное: LMCache — это не «поставил и забыл». Это инфраструктурный слой, который требует настройки под конкретный стек. Нужно понимать, какое у вас хранилище, какие движки, какие нагрузки. Документация у ребят приличная, но 309 открытых issues на GitHub намекают, что не всё гладко.

Второе: эффективность LMCache сильно зависит от типа нагрузки. Если у вас 90% запросов

## Что читать дальше

- [Все материалы про AI-инструменты](/topics/ai-tools/)
- [Как отличить рабочий AI-инструмент от красивой демки](https://verapointmedia.com/guides/kak-otlichit-rabochiy-ai-instrument-ot-krasivoy-demki/)
- [Superpowers: как управлять ИИ-агентами в команде](https://verapointmedia.com/tools/obra-superpowers/)
- [React Doctor — линтер для ассистентов, чтобы они не портили код](https://verapointmedia.com/tools/millionco-react-doctor/)

## Материалы

- [LMCache/LMCache] LMCache/LMCache: https://github.com/LMCache/LMCache
- [lmcache.ai] supporting context: https://lmcache.ai/
- [blog.lmcache.ai] supporting context: https://blog.lmcache.ai/
- [docs.lmcache.ai] supporting context: https://docs.lmcache.ai/