В этом материале
Планирование RAM для повторно используемых KV-блоков: отличие от выгрузки весов и проверка нагрузки на передачу вместе с запросами инференса.
Выгрузка KV-кэша в оперативную память сохраняет уже рассчитанное состояние attention за пределами GPU. Это не означает исполнение слоёв модели на CPU и не уменьшает автоматически память GPU, занятую весами. Практический вопрос заключается в том, окупается ли хранение повторно используемого контекста с учётом перемещения данных и размера рабочего набора.
Разделите три бюджета памяти
Отдельно перечислите веса модели, состояние активных запросов и блоки, сохранённые для повторного использования. Свободная RAM не мешает серверу исчерпать память GPU при декодировании. Большой бюджет offload, наоборот, способен вытеснить операционную систему или процесс инференса, никак не помогая уникальным входным запросам.
Описание LMCache MP предусматривает отдельный процесс кэша с собственными уровнями памяти. Считайте его полноценной резидентной нагрузкой. При оценке узла учитывайте токенизаторы, буферы запросов и клиенты хранения, вместо того чтобы отдавать кэшу каждый байт, который сейчас кажется свободным.
Оцените полезный рабочий набор
Соберите сведения о разных префиксах документов и инструкций, которые возвращаются в выбранном окне повторного использования. Оцените объём KV по фактической модели, точности хранения, числу токенов и разбиению по рангам. Одного общего количества параметров модели для такого расчёта недостаточно.
Для помощника по внутренним документам отделите регулярно открываемые справочные материалы от одноразовых загрузок. Ограниченный горячий набор может заслуживать RAM, а проход по тысячам неповторяющихся документов лишь вытеснять полезные блоки. Зафиксируйте разницу до выбора размера памяти и публикации доли попаданий в кэш.
Проверьте фактический путь передачи
Актуальный quickstart LMCache MP различает режимы интеграции, в том числе путь через разделяемую память CPU. Значимы названия настроек, владение данными и совместимые релизы. Старый пример для встраиваемого процесса не становится универсальным шаблоном для каждого нового многопроцессного развёртывания.
Проследите маршрут блока из RAM до воркера. Измеряйте задержку передачи одновременно с декодированием модели. Отдельный тест копирования не показывает конкуренцию с другими передачами GPU, планировщиком CPU и соседними воркерами. При нескольких GPU запишите локальность памяти и границы её совместного использования.
Сравните с базовым вариантом
Официальный пример vLLM production-stack показывает конкретную интеграцию offload. Используйте его как документированный вариант, а затем проверьте выбранные версии: переносить все настройки руководства в другой релиз без проверки нельзя.
Повторите одинаковое расписание запросов с отключённой и включённой выгрузкой. Включите холодный старт, повторные запросы, вытеснение и перезапуск. Считайте завершённые ответы, задержку первого токена и рост RAM. Выигрыш от сокращения повторного prefill может исчезнуть из-за очереди или ожидания загрузки блока из памяти.
Ограничьте хранение и обработку ошибок
Определите поведение при заполнении RAM, завершении воркера и невозможности загрузить блок. Нужен понятный путь промаха с повторным вычислением контекста. Превращать сбой кэша в постоянно сломанный запрос означает создавать лишнюю зависимость корректности сервиса от необязательной оптимизации.
Согласуйте срок жизни и совместное использование блоков с политикой обработки данных. Хранение в RAM само по себе не означает отсутствия обработки. Укажите доступ к блокам, событие окончания их жизни и отключённые дисковые уровни, если постоянное хранение содержимого запрещено.
Материалы по теме
Pinned memory для GPU: бюджет закреплённой памяти хоста, KV-кеш и экономика GPU: зачем считать память активных запросов.