# LMCache и prefix caching vLLM: где проходит граница кэша

Сравнение локального повторного использования префикса с внешним KV-кэшем: собственный offload vLLM, срок жизни блоков и цена их переноса.

Автор: Команда Retrivium
Обновлено: 2026-11-03
Канонический URL: https://retrivium.ai/ru/journal/lmcache-vs-vllm-prefix-caching/
Language: ru

LMCache и автоматический prefix caching в vLLM отвечают на разные вопросы развёртывания. Кэширование префикса позволяет воркеру не пересчитывать начало запроса. Внешний кэш дополнительно определяет, где хранить пригодное для повторного использования состояние после его удаления из памяти GPU. Перед добавлением ещё одного сервиса стоит определить, какая именно граница важна для вашей системы инференса.

## Начните с локального повторного использования

[Документация vLLM об automatic prefix caching](https://docs.vllm.ai/en/latest/features/automatic_prefix_caching/) описывает повторное использование KV-блоков для совпадающих входных префиксов. Новый ответ всё равно проходит декодирование. Поэтому попадание в кэш не означает бесплатную или мгновенную генерацию длинного вывода.

Представим помощника поддержки с постоянной инструкцией и меняющимися сообщениями клиентов. Сначала измерьте, как часто конкретный воркер действительно получает общий префикс. Если блоки остаются в памяти, а запросы приходят на тот же воркер, дополнительный слой хранения может почти ничего не дать, увеличив объём эксплуатационной работы.

## Определите изменения от внешнего слоя

[Режим LMCache MP](https://docs.lmcache.ai/mp/) отделяет сервис кэширования от процесса инференса и описывает несколько уровней хранения. Меняются владение состоянием, его перемещение и возможные границы повторного использования. Само появление сервиса не обеспечивает совместимость произвольной модели, коннектора или расположения блоков.

Нарисуйте жизнь кэшированного документа после завершения запроса, вытеснения с GPU, перезапуска воркера и переноса задачи. Отметьте события, после которых повторное использование сегодня теряется. Такая схема полезнее сравнения названий двух технологий без понимания, какой возможности не хватает в текущем развёртывании.

## Учтите собственный offload vLLM

Противопоставление «vLLM работает только с GPU, а LMCache предоставляет любой offload» уже некорректно. Официальное [руководство vLLM по переносу KV-кэша](https://github.com/vllm-project/vllm/blob/main/docs/features/kv_offloading_usage.md) описывает собственный коннектор для дополнительных уровней памяти. Доступность и сочетания функций зависят от выбранной версии.

Сравните три конкретных варианта: только локальное повторение, документированный собственный offload и интеграцию LMCache. Зафиксируйте версии движка, коннекторы, ёмкость хранения и допустимость совместного включения функций. Наличие возможности где-то в репозитории ещё не подтверждает её работу в вашем образе.

## Сопоставьте перенос и повторное вычисление

Возьмите трассу с первыми обращениями, повторными документами, прерванными сессиями и конкурирующими префиксами. Сохраните одинаковые запросы и расписание поступления. Разделяйте попадания в GPU, обращения к выгруженным блокам и промахи, не объединяя их одним средним процентом.

Измеряйте задержку первого токена, время переноса, очередь, использование RAM и завершённые запросы. Загрузка выгруженного блока иногда проигрывает пересчёту из-за медленной передачи или конкуренции. Дорогой повторный prefill, наоборот, может оправдывать хранение даже при скромной общей доле попаданий. Универсального результата здесь нет.

## Выберите достаточную границу

Предпочитайте конфигурацию, которая решает наблюдаемую проблему срока жизни или размещения при приемлемой сложности сопровождения. Помимо загрузки GPU учитывайте обновления коннектора, инвалидацию, изоляцию арендаторов и очистку хранилища. Память за пределами GPU тоже ограничена.

Опишите ожидаемые промахи и переход к обычным вычислениям при ошибке загрузки. Полезный кэш повышает эффективность известной нагрузки, сохраняя контракт ответа. Он не должен становиться скрытым условием корректного обслуживания самого первого запроса.

## Материалы по теме

[Prefix caching: когда повторяющийся контекст помогает GPU-пулу](/ru/journal/prefix-caching/), [vLLM KV cache и preemption: почему запросы пересчитываются](/ru/journal/vllm-kv-cache-preemption/).