PrefixSim: открытый симулятор KV-кэша сравнивает 40+ политик вытеснения

Если вы запускаете LLM в продакшене, то наверняка уже слышали про префиксное кэширование. Идея простая: у многих запросов одинаковое начало — системный промпт, описание инструментов, история диалога. Считать для него KV-кэш каждый раз незачем, его можно сохранить и переиспользовать. Но память GPU конечна, и рано или поздно кэшу приходится что-то выкидывать. От того, что именно вы выбросите, зависит, сколько видеокарточного времени сгорит впустую.

Именно эту задачу пытается закрыть PrefixSim — проект, который открыл Juncheng Yang (@1a1a11a). Это быстрый симулятор кэша KV-блоков для LLM-сервинга. Вместе с ним авторы выложили два датасета с трейсами нагрузки. Оговорка: исходный пост в X обрывается на полуслове, поэтому ниже только то, что в нём прямо сказано. Детали вроде формата трейсов и лицензии стоит смотреть в репозитории.

Какую проблему решает

Классические кэш-политики вроде LRU придумывали для веб-страниц и блоков диска. У KV-блоков другая специфика. Они устроены как префиксное дерево: блок в начале цепочки нужен всем, кто идёт после него. Выкинуть «старый», но корневой блок значит обесценить целую ветку. Кроме того, разные блоки стоят разного количества вычислений: пересчитать длинный префикс гораздо дороже короткого.

Поэтому привычная метрика hit rate здесь может вводить в заблуждение. Авторы PrefixSim прямо называют главным критерием compute savings — сколько работы на prefill удалось не делать. Две политики с одинаковым процентом попаданий могут дать очень разную экономию GPU.

Как это выглядит на практике

Представьте чат-ассистента с длинным системным промптом и десятками тысяч сессий в день. Вы берёте реальный трейс запросов и прогоняете его через симулятор с разными политиками вытеснения. По словам автора, их больше 40. На выходе вы видите, какая из них сохраняет больше всего вычислений при вашем объёме памяти под кэш.

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

Другая причина ценности симулятора — стоимость экспериментов. Проверять политику вытеснения на живом кластере долго и рискованно: нужно менять движок, раскатывать, ждать репрезентативного трафика. Симуляция на записанном трейсе занимает минуты и ничего не ломает.

Что с этим делать

Если вы строите собственный инференс-стек или тюните vLLM, SGLang и подобные движки, PrefixSim даёт способ проверить, не оставляете ли вы деньги на столе. Запишите трейс своей нагрузки, прогоните через симулятор и сравните свою текущую политику с альтернативами. Если разница в сэкономленном prefill заметна, это аргумент для доработки кэша. Если нет, вы хотя бы будете знать, что стандартный вариант вас устраивает.

Продактам и основателям полезно другое: эффективность кэша напрямую влияет на задержку первого токена и себестоимость запроса. Для сервисов с длинными общими префиксами — агентов, RAG-ассистентов, кодовых помощников — это может быть заметная статья расходов.

Ограничения

Симулятор остаётся моделью. Он не учитывает всё, что происходит в реальном движке: фрагментацию памяти, планировщик, перегрузки очереди. Результаты на трейсах конкретных компаний не обязательно перенесутся на вашу нагрузку. И мы пока не видели независимых проверок: на момент публикации это анонс в X с охватом около 7,5 тысячи просмотров. Но как инструмент и как набор открытых данных для спорной и недооценённой области сервинга LLM проект выглядит стоящим, чтобы потратить на него вечер.