Префиксный кэш

У обсуждения префиксного кэша есть три разных вопроса: изменился ли вход после шаблонизации, попал ли запрос на реплику с нужным префиксом и не съела ли очередь выигрыш от кэша. Здесь разберём, как их отличить и что проверить в каждом случае.

Начните с вопроса, который хотите проверить:

Если ранних изменений нет, перестраивать запрос ради кэша не нужно. Совпавший вход сам по себе ещё не показывает, были ли прочитаны готовые блоки: для этого нужны данные провайдера или движка.

Проблема

Агент несколько раз отправляет инструкции, описания инструментов и растущую историю. Меняется небольшой хвост, а движок снова тратит время на обработку общего начала. Префиксный кэш (prefix cache) позволяет переиспользовать вычисленное состояние этой части входа.

В пуле из нескольких реплик задача усложняется. Даже полностью совпадающий вход бесполезен для локального кэша сервера B, если нужное состояние осталось только на A. Но закрепить все повторы за A тоже недостаточно: там может накопиться очередь.

Кэш сокращает повторную обработку входа (prefill). Генерацию нового ответа (decode) всё равно нужно выполнить. Если основное время уходит на длинный ответ, сокращение обработки входа может мало изменить полное время запроса. Это ограничение описано в документации vLLMВнешняя ссылка, откроется в новой вкладке.

Симптомы

Сопоставляйте эти наблюдения по одному запросу: так можно проследить, где именно потерялось повторное использование.

Ментальная модель

Нужны три совпадения: то же начало, совместимое состояние, доступное место выполнения.

В vLLM блок идентифицируется с учётом предшествующего префикса, токенов самого блока и дополнительных признаков — например, адаптера или входного изображения. Повторно используются полные блоки. Одинаковый на вид текст до шаблонизации ещё не гарантирует одинаковый ключ. Устройство кэша vLLMВнешняя ссылка, откроется в новой вкладке.

Запрос 1: [инструкции v1][инструменты v3][история][вопрос A]
Запрос 2: [инструкции v1][инструменты v3][история][вопрос B]
           └──────── общее начало ────────────┘

Запрос 3: [новая дата][инструкции v1][инструменты v3][история]…
           ↑ различие до полезного общего контекста

Длину пригодного для кэша префикса нужно считать в токенах после применения шаблона модели. Для повторного использования важны совпадение и порядок токенов; близость смысла эту работу не заменяет.

Стабильность — договорённость с приложением. Версии инструкций и инструментов должны меняться осознанно. Удалять обязательные ограничения или сохранять недоступный пользователю инструмент ради совпадения префикса нельзя.

Архитектура

Сначала выбираем сценарий и совместимый пул. Потом решаем, можно ли принять запрос с текущими лимитами и сроком. И только среди подходящих реплик сравниваем локальность и нагрузку.

Исправность, совместимость модели и изоляцию данных проверяем до оценки выгоды. Реплика с неподходящей моделью или без нужной изоляции выпадает из списка кандидатов, сколько бы нужных блоков на ней ни лежало. После фильтрации маршрутизатору нужны размер доступного префикса, нагрузка и достаточно свежие сведения о памяти. Если сведения пропали, нужен заранее выбранный режим работы с учётом только нагрузки.

В Dynamo 1.0Внешняя ссылка, откроется в новой вкладке стоимость кандидата учитывает обработку входа и нагрузку генерации, а сведения о блоках могут поступать через события либо оцениваться приближённо. SGLang Model GatewayВнешняя ссылка, откроется в новой вкладке сочетает поиск совпадающего префикса с порогами балансировки.

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

Для одного запроса упростим сравнение до двух величин:

T_A = очередь A + оставшаяся обработка входа на A
T_B = очередь B + полная обработка входа на B

Выбираем A, когда T_A < T_B.
При равенстве эта модель не даёт предпочтения.

Возьмём условные числа: очередь B — 100 мс, полная обработка — 600 мс, обработка с кэшем — 80 мс. Тогда граница для очереди A — 620 мс. Ниже выгоднее A, выше — B. В этом расчёте реплики одинаковы по производительности, а кэш хранится локально.

Повторить вычисление вне браузера

Из локальной копии исходного кода сайтаВнешняя ссылка, откроется в новой вкладке на Node.js 22.18 или новее:

node --experimental-strip-types scripts/cache-routing-experiment.ts

Четыре сценария используют ту же функцию, что и интерактивный пример. Результаты и допущенияВнешняя ссылка, откроется в новой вкладке сохранены в репозитории сайта.

Метрики

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

Если есть счётчики токенов с согласованным охватом, доля повторного использования равна сумме переиспользованных токенов, делённой на сумму входных. Не усредняйте проценты реплик без весов. Не смешивайте счётчик запросов со счётчиком токенов и не считайте отсутствующее поле нулём.

Название политики не раскрывает её вход, а HTTP 200 не подтверждает завершение потокового ответа. В разборе кэш-роутера показано, почему chat-путь может сравнивать ключ сессии вместо текста и зачем отдельно проверять завершение SSE на клиенте.

План проверки на настоящем движке: повторить один очищенный запрос на той же реплике; отправить его на другую; затем сравнить политики на одинаковом потоке с сохранённым распределением длин, интервалов и параллельности. Для каждой политики отдельно получить холодное и прогретое состояние. Чередовать порядок прогонов, повторять их и сохранять исходные результаты. Не очищать кэш общего рабочего пула ради теста.

По данным о чтении кэша и времени выполнения будет видно, сколько работы удалось сэкономить и как это повлияло на задержку.

Компромиссы

При росте числа реплик один и тот же префикс может прогреваться в нескольких местах. Это не обязательно ошибка: дополнительная копия иногда снимает очередь. Выбор зависит от частоты повторов и цены ожидания.

В управляемом API реплика обычно скрыта. Там проверяют контракт конкретного провайдера и возвращаемые поля использования; собственный кэш-роутер перед API не даёт контроля над внутренними GPU-серверами.

Антипаттерны

• Максимизировать попадания, не ограничивая время ожидания.
• Принимать назначение реплики за доказанное чтение кэша.
• Диагностировать промах только по TTFT: задержка включает больше одной причины.
• Менять модель, права или границу изоляции ради тёплого состояния.
• Считать процент занятой KV-памяти прямым измерением числа вытеснений.
• Использовать один вес скоринга для любых длин входа, ответа и классов обслуживания.
• Выдавать сокращение вычислений за такую же экономию денег: аренда, тариф и полезная загрузка считаются отдельно.

Чеклист

• Закреплены модель, шаблон, токенизатор и версия движка.
• Сравнивается фактический вход, а не исходный объект до сериализации.
• Проверено, какое представление получает политика на выбранном endpoint и версии роутера.
• Определено, кому разрешено совместное использование кэша.
• Реплики фильтруются по совместимости и исправности до оценки выгоды.
• Есть связь между запросом, выбранной репликой и чтением кэша.
• Измерены очередь и TTFT по сценариям, а не только среднее по платформе.
• Завершение потокового ответа проверяется на клиенте отдельно от HTTP-статуса и success роутера.
• Определены действия при устаревшем индексе, отказе и перегрузке.
• Выгода проверена на повторяемом потоке, а ухудшение соседних запросов ограничено.

Связанные главы

Inference Plane описывает более широкую границу исполнения. Проверка стабильности инструментов помогает найти изменение формы запроса до исследования маршрута. audit-prompt-caching даёт инструмент для такого первого прохода.

Авторский вход в тему — «Тёплый кэш — ещё не быстрый ответ». Три условия повторного использования можно услышать в эфире «Каждый токен на счету».