В этом материале
Как разделять KV-кэш по ревизиям весов, токенизаторам, формату блоков и арендаторам, чтобы безопасно переиспользовать его после обновления инференса.
Постоянный KV-кэш способен пережить процесс инференса. Это полезно только пока его блоки соответствуют вычислениям, которые выполнил бы новый воркер. Совпадения видимого текста недостаточно: токенизация, веса, расположение attention-состояния или правила изоляции могут измениться без заметной разницы в окне чата. Поэтому срок жизни кэша нужно связывать с идентичностью вычисления, а не только с именем сервера.
Определите идентичность состояния
Начните с явного пространства имён, описывающего ревизию весов, токенизатор и специальные токены, существенную конфигурацию модели, формат хранения и разбиение по рангам. Учитывайте адаптеры и другие параметры запроса, влияющие на состояние. Это операторский перечень совместимости, а не утверждение, что любой продукт автоматически хэширует все перечисленные поля.
Например, документация LMCache для Redis показывает ключи с моделью и сведениями о воркерах. Читаемое имя модели не становится автоматически криптографическим отпечатком конкретного чекпойнта за этим именем. Перед повторным использованием идентификатора проверьте реализацию именно установленной версии.
Разделите равенство текста и токенов
HTTP API LMCache MP работает с идентификаторами токенов и метаданными модели и расположения блоков. Одинаковые слова способны дать разные последовательности из-за шаблонов, специальных маркеров и версии токенизатора. Сами номера токенов тоже имеют смысл только внутри соответствующей модели и токенизатора.
Сохраните сериализованный вход и настройки токенизации для небольшого диагностического корпуса. При обновлении сравнивайте фактический вход модели, а не только видимые сообщения пользователя. Включите пустые реплики, результаты инструментов, разные языки и длинные беседы с ранее сгенерированным текстом внутри повторяемого префикса.
Сделайте инвалидацию решением релиза
Классифицируйте обновление до направления запросов на новый воркер. Изменение отображаемого названия может сохранить совместимость; новые веса под прежним именем репозитория могут её нарушить. Смена точности или расположения блоков коннектора тоже требует документированного ответа вместо предположения.
Выберите один из трёх исходов: новое пространство имён, проверенное совместимое использование или осознанную очистку. Отделяйте это решение от отката образа приложения. Возврат старой программы без подходящей границы кэша способен снова создать несовместимость, которую должен был устранить откат.
Проверьте обманчивое попадание
Руководство vLLM по prefix caching объясняет механизм повторения. Дополните обычные тесты специально устаревшим пространством имён в изолированной проверке. Цель состоит в подтверждении, что процедура обновления предотвращает несовместимое повторение, а не в подсчёте правдоподобных ответов от устаревших блоков.
Сравните ответы с кэшем и без него по фиксированной процедуре, учитывая документированную численную недетерминированность. Добавьте проверки, обнаруживающие неправильный документ или инструкцию, а не только успешный статус запроса. Загрузка блока без аварии ещё не подтверждает его смысловую корректность.
Учтите владение и очистку
Разделяйте состояния по разрешённой границе совместного использования. Совпадение префиксов у разных арендаторов само по себе не разрешает общее хранение или раскрытие метаданных. Согласуйте устройство кэша с правилами обработки содержимого сервиса.
Назначьте срок хранения и ответственного за очистку старых релизов, неудачных обновлений и забытых экспериментальных адаптеров. Постоянному кэшу нужен учёт, как и постоянным файлам модели. Иначе занятый объём растёт, а оператор уже не способен уверенно объяснить полезность и допустимость повторного использования сохранённых блоков.
Материалы по теме
Prefix caching: когда повторяющийся контекст помогает GPU-пулу, Кэш torch.compile в vLLM: как переносить прогрев между релизами.