WAKMan: кэш-менеджер для LLM-серверов сам выбирает стратегию и даёт на 5 п.п. больше попаданий

Серверы с большими языковыми моделями тратят заметную часть вычислений на повторную обработку одного и того же контекста. Если два запроса начинаются с одинакового куска текста — например, системной инструкции или истории диалога — сервер может один раз посчитать для него внутренние "ключи" и "значения" модели и затем просто взять готовый результат из памяти видеокарты, вместо того чтобы считать заново. Это называется переиспользованием префикса, и оно реально ускоряет ответы и снижает затраты на обслуживание.

Проблема в том, что память видеокарты ограничена, и место под такой кэш постоянно освобождают, выкидывая старые записи. От правила, по которому выбирают, что выкинуть, напрямую зависит, сколько раз сервер сможет повторно использовать уже посчитанные данные. Исследователи из Мэрилендского университета и Capital One показали, что универсального правила не существует — и предложили систему WAKMan, которая подбирает подходящую стратегию сама, наблюдая за реальным трафиком.

Почему одно правило не работает для всех

Трафик к LLM-серверам обычно смешанный: это разовые вопросы без памяти о предыдущих сообщениях, многоходовые диалоги с историей переписки и агентные сценарии, где ИИ-система сама за секунды делает серию шагов подряд.

У этих трёх типов запросов принципиально разный паттерн повторного использования данных:

• Агентные шаги возвращаются к общему контексту почти мгновенно, за секунды, поэтому для них выгодно правило «выкидывай самое старое» (LRU) — оно и есть стандарт в популярном движке vLLM.
• Популярные фиксированные запросы (например, системные подсказки часто используемых сервисов) и длинные диалоги возвращаются к своему контексту спустя множество других, не связанных с ними запросов. Для них важнее не свежесть, а частота использования — тут выигрывает правило S3FIFO, которое защищает часто запрашиваемые блоки от вытеснения разовым "шумом".

Авторы проверили оба правила на 20 искусственно смешанных потоках запросов с разной долей разовых, многоходовых и агентных сценариев. LRU выигрывал у S3FIFO на агентно-ориентированных смесях, давая до 12% больше попаданий в кэш, но проигрывал ему до 22% на смесях с преобладанием диалогов и повторяющихся запросов. Более того, даже при фиксированном составе трафика достаточно поменять один параметр — например, среднее число реплик в диалоге или длину входного текста разового запроса — чтобы победитель поменялся местами. На одной и той же смеси запросов LRU выигрывал при коротких диалогах в 2 реплики, а при диалогах из 8 реплик уже выигрывал S3FIFO с разницей 15,4 процентных пункта.

Как работает WAKMan

Идея WAKMan в том, чтобы не угадывать тип трафика заранее, а постоянно проверять его на практике. Система держит рядом с реальным сервером две "теневые" копии кэша — одну с правилом LRU, другую с правилом S3FIFO — и прогоняет через них лог недавних запросов за прошедший временной интервал. Побеждает та стратегия, которая на этом же наборе запросов дала больше совпадений с уже закэшированными данными. Сервер переключается на неё до следующей проверки.

Для этого WAKMan не нужно ничего знать о содержимом запросов, их типе или номере реплики в диалоге — он использует только хэши блоков данных, которые vLLM и так вычисляет в обычном режиме работы. Это важно, потому что на практике сервер часто физически не может определить тип запроса: диалоговая история склеивается на стороне клиента, а требования приватности и разделения данных не позволяют серверу "читать" содержимое запросов, чтобы угадать их природу.

Результаты и ограничения

В экспериментах на модели Gemma, развёрнутой через vLLM на четырёх видеокартах NVIDIA RTX PRO 6000, WAKMan в среднем дал на 5 процентных пунктов больше попаданий в кэш по сравнению со стандартным для vLLM правилом LRU. Среди трёх проверенных стратегий — чистого LRU, чистого S3FIFO и динамического WAKMan — именно WAKMan показал наименьший средний и наименьший максимальный разрыв с идеальным кэшем бесконечного размера, который теоретически мог бы хранить вообще всё.

Главная слабость подхода — задержка реакции: решение о смене стратегии принимается не мгновенно, а по итогам прошедшего интервала, и если характер трафика резко меняется сразу после переключения, часть запросов в этом интервале обслуживается неоптимальной стратегией. Авторы также отмечают, что в их систему можно добавлять и другие стратегии вытеснения кэша, если для них есть способ смоделировать работу без реального железа — так что набор "кандидатов" на выбор не ограничен только LRU и S3FIFO.

Для команд, которые обслуживают LLM-продукты с смешанным трафиком — часть пользователей ведёт долгие диалоги, часть использует агентные сценарии, часть просто задаёт разовые вопросы, — вывод практичный: жёстко зашитая стратегия кэширования почти гарантированно теряет производительность на части трафика, и имеет смысл закладывать механизм адаптивного переключения уже на уровне инфраструктуры, а не выбирать "одно правильное" правило раз и навсегда.