# LRU, LFU и SLRU в SGLang: как защитить горячий набор префиксов

Политику вытеснения Radix cache в SGLang выбирают по характеру повторного использования префиксов.

Автор: Команда Retrivium
Обновлено: 2026-11-01
Канонический URL: https://retrivium.ai/ru/journal/sglang-radix-eviction-hotset/
Language: ru

Политику вытеснения Radix cache в SGLang выбирают по характеру повторного использования префиксов. Для постоянного горячего набора и одноразового всплеска LRU, LFU и SLRU могут вести себя по-разному. Сравнивать следует при одинаковой емкости и одинаковом потоке запросов. Простого знания, что prefix caching ускоряет повторный вход, недостаточно для решения, какие записи сохранять при нехватке места и как обнаружить вытеснение полезных данных.

## Определите задачу eviction

Кэш ограничен, поэтому новый вход способен потребовать удаления прежнего состояния. [Документация SGLang](https://docs.sglang.io/docs/advanced_features/radix_eviction_policy) описывает политики, учитывающие давность, частоту и сегменты использования. Названия не означают универсальный порядок эффективности. Для одной нагрузки полезна недавняя активность, для другой важнее пережить короткий поток одноразовых обращений. Сначала определите, какие префиксы должны возвращаться повторно и через какой интервал, затем выбирайте сценарий проверки, который действительно создает конкуренцию за исследуемую емкость кэша.

## Сохраните hot set явно

Создайте небольшой набор повторяющихся длинных инструкций и отдельный набор уникальных документов. Сохраните точные token sequences, потому что похожий текст не всегда образует общий префикс после chat templating. Контролируйте порядок ролей и служебные маркеры. Не называйте весь conversation reusable, если между запросами меняется его начало. Также проверьте, не завершает ли приложение процесс сервера между сериями: тогда изменение hit behavior объясняется жизненным циклом, а не выбранной eviction policy.

## Пример последовательности нагрузки

Сначала прогрейте повторяющийся набор, затем подайте серию уникальных входов и снова обратитесь к горячим префиксам. Выполните одну и ту же последовательность для сравниваемых политик, начиная с сопоставимого состояния. Запишите повторный prefill, cache observations и TTFT возвращающихся запросов. Это предложенный эксперимент, а не готовые значения hit rate. Если одноразовые входы вытесняют полезные записи, исследуйте, какая политика лучше сохраняет их именно на этом потоке, не выдавая результат за свойство всех документов.

## Свяжите кэш с задержкой

[Руководство tuning](https://docs.sglang.io/docs/advanced_features/hyperparameter_tuning) помогает интерпретировать cache behavior вместе с остальной нагрузкой. Высокий hit показатель не заменяет пользовательскую задержку, особенно когда decode занимает значительную часть ответа. Сохраняйте длины совпадений и фактический объем prefill, если они доступны, а не только число запросов с любым попаданием. Короткое совпадение и повтор почти всего документа имеют разную ценность. Также следите за concurrent work: очередь может перекрыть выигрыш от сохраненного горячего состояния.

## Оформите ограниченную рекомендацию

Зафиксируйте политику, ее параметры, емкость и последовательность запросов. Покажите поведение до всплеска, во время него и после возврата hot set. Не меняйте одновременно allocator budget или модель, иначе сравнение перестанет изолировать eviction. При смене распределения документов повторите проверку. Полезный вывод объясняет, какие повторения защищает выбранная стратегия и какой ценой, включая случаи ухудшения. Политика не создает дополнительную VRAM и не превращает разные токены в одинаковый префикс. Она распределяет ограниченное сохраненное состояние между конкурирующими входами, поэтому приемка должна наблюдать именно вытеснение и последующее восстановление вычислений, а не только факт включенного флага кэширования в launch command сервера.

## Связанные материалы

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