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

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

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

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

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

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

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

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

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

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

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

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

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

Prefix caching: когда повторяющийся контекст помогает GPU-пулу; KV-кеш и экономика GPU: зачем считать память активных запросов.