При работе с кэшированием префиксов в LLM легко попасть в ловушку: кэш вроде бы включён, но reuse почти отсутствует. cached_tokens не растут, задержки высокие, а prefill каждый раз пересчитывается. Причина — не в самой модели, а в инженерных ошибках. Ниже разбор семи анти-паттернов, которые убивают эффективность prefix caching.

Три условия для работы кэша

Чтобы кэш сработал, нужно соблюсти три условия одновременно:

• Совпадение начала запроса — не просто похожее, а буквально идентичное начало по токенам.
• Попадание на нужную реплику — запрос должен прийти туда, где кэш уже прогрет.
• Выживание кэша — KV-cache должен сохраниться до следующего запроса, не быть вытесненным.

Если нарушено хотя бы одно — кэш не сработает. Всё остальное — детали реализации.

Синтетический кейс: как всё ломается

Представим корпоративного AI-ассистента. В каждом запросе — длинный system prompt, 14 tool definitions и короткая история чата. Идеальный кейс для кэширования: общая часть длинная, повторов много.

До релиза:

• prompt_tokens p50 — стабильны
• cached_tokens p50 — высокие
• роутинг — sticky / prefix-aware

После трёх «безобидных» изменений:

1. В system prompt добавили timestamp и user.company.
2. Порядок tools стал динамическим.
3. Перешли на round-robin между 4 репликами.

Результат:

• prompt_tokens p50 — почти те же
• cached_tokens p50 — почти ноль
• роутинг — round-robin

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

1. Волатильные данные в начале запроса

Самый частый анти-паттерн. Добавление timestamp, user.name, session_id в начало делает каждый запрос уникальным с первых токенов.

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

2. Невидимый дрейф шаблона

Когда один и тот же запрос собирается по-разному: разное количество пробелов, переводов строк, detail="low" vs detail="high", разная сериализация в SDK.

Глазами — одинаково. Для кэша — разные начала.

Решение: нормализация сборки запроса: пробелы, переводы строк, параметры изображений, сериализация ссылок. Должен быть один канонический способ.

3. Tools, schema и response_format — это тоже начало

API-обвязка часто ломает кэш. Динамические поля в json_schema, случайный requestId в response_format — и тяжёлый общий кусок перестаёт быть общим.

Решение: телеметрия (request_id, trace_id) — в отдельные поля, не в кэшируемую часть. Tools и schema — детерминированные и стабильные.

4. Переписывание истории вместо append-only

Кэш любит, когда диалог растёт в конец. Если вы переписываете начало — через суммаризацию, сжатие или обрезание — кэш сбрасывается.

Summarization — это trade-off, а не бесплатная оптимизация. Вы экономите на длине контекста, но теряете reuse.

5. Round-robin размазывает кэш по репликам

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

Решение: sticky routing, prompt_cache_key или prefix-aware routing. Без этого одинаковые запросы будут независимо прогревать кэш на каждой машине.

Минус: возможны hot spots. Но выигрыш в reuse (до 70% экономии вычислений в vLLM) перевешивает.

6. Параллельный запуск до прогрева

Контринтуитивный баг: отправка 10 одинаковых запросов одновременно не прогревает кэш — все начинают с нуля.

Решение: сначала прогреть общий префикс одним запросом, потом запускать параллельные вызовы.

7. Кэш не доживает до следующего запроса

Даже при идеальном запросе и роутинге — кэш может исчезнуть.

Причины:

• Редкий трафик — кэш остывает.
• Недостаток памяти — KV-cache переполняется, полезные блоки вытесняются.

В managed API — короткое окно жизни кэша. В своей инфраструктуре — нужно смотреть настройки движка и объём памяти.

Что мониторить

cached_tokens — метрика с задержкой. Лучше смотреть:

• Долю трафика, пригодного для кэширования.
• Время до первого токена по группам похожих запросов.
• Изменения после деплоев, A/B-тестов, смены SDK.
• Частоту повторного прогрева одних и тех же префиксов.

Чеклист перед деплоем

Начало запроса

• Только статичный и общий контент в начале.
• Персонализация, время, id — в конец или metadata.
• Один канонический способ рендеринга system prompt.

API-обвязка

• tools — стабильны по содержимому и порядку.
• JSON/schema — детерминированная сериализация.
• response_format — без динамических полей.
• Режимы — без мутации system prompt.

Диалог

• Рост в конец (append-only).
• Summarization — осознанный trade-off.
• Обрезание не ломает общий префикс.

Роутинг

• Stickiness: prompt_cache_key, affinity, prefix-aware routing.
• Параллельные вызовы — только после прогрева.

Время жизни кэша

• KV budget соответствует рабочему набору, а не паспортному максимуму.
• Есть мониторинг вытеснения и повторного прогрева.

Главный вывод: плохой hit rate — не абстракция. Это конкретная инженерная поломка. Один timestamp, один плавающий список tools, один round-robin — и весь потенциал кэша теряется.

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

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

В прошлый раз я писал про деньги. Здесь - про то, почему кэширование вроде бы включено, а повторного использования почти нет:cached_tokensне растут, задержка увеличивается, и система снова платит полную цену за prefill.

• Самые дорогие промахи часто создаёт не пользовательский текст, а обвязка вокруг API:tools,response_format,json_schema, сериализация, переключение режимов.
• В кластере с несколькими репликами стабильный prompt сам по себе не спасает. Если у вас round-robin без привязки к прогретому кэшу, одинаковые запросы начинают прогреваться независимо на разных машинах.
• В своей инфраструктуре всё ещё веселее: даже хороший общий кусок запроса можно потерять из-за вытеснения, особенностей хранения блоков и слишком маленького KV budget.

Быстро про механику: три условия, без которых кэш не сработает

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

Во-первых, у запросов должно буквально совпадать начало. Не “почти такое же”, а тот же поток токенов до точки, где система может использовать уже посчитанный префикс.

Во-вторых, запрос должен попасть туда, где это начало уже успело прогреться. В single-node setup это почти не заметно. В multi-replica это уже отдельная инженерная проблема.

В-третьих, сам KV-cache должен дожить до следующего запроса. Если его уже вытеснили, точное совпадение начала вам не поможет.

Всё остальное - детали реализации.

Синтетический кейс, на котором дальше будем всё ломать

Возьмём корпоративного AI-ассистента. В каждый запрос он отправляет длинныйsystem prompt, 14tool definitionsи короткий хвост истории чата. Это как раз тот режим, где кэш обычно должен работать хорошо: общая начальная часть длинная, повторов много, цена промаха заметная.

До релиза всё выглядит нормально:

prompt_tokensp50

cached_tokensp50

sticky / prefix-aware

Потом команда выкатывает три “безобидных” изменения:

1. Вsystem promptдобавляет текущее время иuser.company.
2. toolsначинает собирать из динамической структуры без жёсткой фиксации порядка.
3. После масштабирования на 4 реплики с моделью оставляет обычный round-robin.

После релиза модель та же, токенов почти столько же, а вот картина уже другая:

prompt_tokensp50

cached_tokensp50

round-robin

Ниже синтетический, но реалистичный кейс: цифры здесь иллюстративные. Это просто модель поломки с примерным порядком величин.

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

1. Волатильные данные в начале запроса

Это самый частый убийца hit rate. И самый банальный.

Проблема выглядит так:

Кажется, что это нормальная персонализация. На практике вы делаете каждый запрос уникальным с самых первых токенов. Один timestamp в начале - и весь хвост запроса уже другой. То же самое происходит сuser.name,session_id,request_idи любыми другими полями, которые меняются чаще, чем живёт кэш.

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

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

2. Невидимый дрейф шаблона: когда один и тот же запрос в системе собирается по-разному

Сам по себе лишний пробел в шаблоне - не катастрофа. Если вы один раз глобально поменяли prompt, кэш просто один раз остынет, а потом прогреется заново уже на новой версии.

Проблема начинается в другом месте: когда в системе одновременно живут несколько почти одинаковых вариантов одного и того же запроса. Один сервис добавляет один перевод строки, другой - два. Один путь отправляет изображение сdetail="low", другой - сdetail="high". Один SDK сериализует сообщение так, другой чуть иначе.

Глазами это “тот же prompt”. Для кэша - уже нет.

А в соседнем код-пути уже detail=“high” или тот же URL, но с другой query-строкой.

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

Самая неприятная часть этой поломки в том, что её часто ищут не там. Начинают дебажить сам кэш, хотя проблема в шаблонизаторе, рендеринге prompt’а, SDK или сериализации мультимодального ввода.

Поэтому нормализовать нужно не только user input, но и сам способ сборки запроса: пробелы, переводы строк, markdown-шаблоны, параметры изображений и сериализацию ссылок.

3. Tools, schema и response_format - это тоже начало запроса

Очень часто кэш ломает не сам prompt, а обычная обвязка вокруг API.

С инженерной точки зрения всё валидно. С точки зрения prefix caching вы сделали каждый запрос уникальным ещё до user message.

Фикс здесь скучный. И поэтому рабочий:

Аrequest_id, tenant context, trace id и прочую живую телеметрию лучше передавать отдельно, не внутрь кэшируемой схемы.

Это дорогая поломка, потому что schema и tools часто весят сотни и тысячи токенов. Один случайныйrequestIdвjson_schema- и общий тяжёлый кусок в начале запроса больше не общий.

4. Переписывание истории вместо добавления в конец (append-only)

Кэш любит диалог, который растёт в хвост. Он плохо переносит списки запросов, котором вы переписываете начало.

Проблема обычно появляется, когда команда начинает “оптимизировать” длинный контекст. Суммаризация ранних ходов. Агрессивное сжатие истории. Наивное обрезание. Переключение режимов через mutation system prompt.

Если хочется сохранить повторное использование, лучше расти в хвост:

Есть и более прямой способ на это смотреть: если вы действительно пересобираете контекст заново, считайте это новой сессией и не ждите старого hit rate.

Summarization не плохая идея сама по себе. Иногда она обязательна. Но это не бесплатное ускорение. Это обмен: вы уменьшаете длину контекста ценой того, что кэш с точки переписывания больше не совпадает.

5. Обычный балансировщик размазывает тёплый кэш по репликам

Даже стабильное начало запроса - это только половина задачи. Вторая половина - попасть туда, где этот запрос уже успели прогреть.

На одной только сборке prompt’а всё не заканчивается. Можно стабилизироватьsystem prompt, канонизироватьtools, зафиксировать schema - и всё равно не получить повторного использования, если одинаковые запросы разъезжаются по разным репликам.

Практически здесь нужен либоprompt_cache_key, либо роутинг с учётом прогретого кэша, либо хотя бы sticky routing на уровне gateway:

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

Это не теоретическая придирка к архитектуре. В production-стеке vLLM переход на prefix-aware routingподнималhit rate до 87.4% и давал около 70% экономии вычислений. То есть правильный роутинг здесь влияет не меньше, чем аккуратная сборка запроса.

6. Параллельный запуск по ещё не прогретому началу запроса

Это очень контринтуитивный баг.

Инженер думает так: “сейчас я отправлю 10 одинаковых длинных запросов, первый прогреет кэш, остальные выиграют”. На практике легко получить обратное.

Проблема не в стабильности prompt’а. Prompt может быть одинаковым. Порядок запуска - нет.

Рабочий сценарий - сначала прогреть общий кусок в начале запроса, и только потом веерить похожие вызовы:

Этот анти-паттерн неприятен тем, что его легко спутать с “почему-то низким hit rate у провайдера”, хотя проблема на самом деле в порядке и тайминге ваших же вызовов.

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

7. Кэш не доживает до следующего обращения

Последняя большая группа поломок - время жизни кэша.

Здесь уже можно всё сделать правильно на уровне сборки запроса и роутинга, а hit rate всё равно будет плохим.

Первый анти-паттерн - редкий трафик. Если “один и тот же” тяжёлый запрос приходит редко, обычный кэш в памяти будет каждый раз почти холодным.

Второй - под KV-кэш просто не хватает памяти. Если в трафике одновременно живёт больше “тёплых” префиксов, чем помещается в памяти, они начинают вытеснять друг друга. Снаружи это выглядит как случайный hit rate: то есть, то нет. На деле система просто снова и снова прогревает одни и те же куски запроса.

То есть для managed API это история про короткое окно жизни кэша. Для своей инфраструктуры - ещё и про настройки движка инференса и реальный объём доступной памяти.

Что мониторить, чтобы заметить проблему раньше счёта

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

Я бы смотрел минимум на четыре вещи.

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

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

В-третьих, поведение после изменений: деплоя, A/B-теста, изменения числа реплик, смены SDK или prompt-шаблона. Хороший дашборд должен отвечать на вопрос: после какого именно изменения кэш начал работать хуже.

В-четвёртых, сколько раз вы прогреваете одни и те же куски заново. В managed API это выглядит как скачки hit rate и latency на общих длинных запросах. В своей инфраструктуре - ещё и как заполненный KV-cache и вытеснение полезных блоков.

Чеклист перед деплоем

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

Начало запроса

• В начале только статичный и общий контент.
• Вся персонализация, время, request id, tenant-specific мелочь - в конец или в metadata.
• Один канонический рендеринг system prompt.

Обвязка вокруг API

• toolsстабильны по содержимому и порядку.
• JSON/schema сериализуются детерминированно.
• response_formatне содержит динамических полей вродеrequestId.
• Переключение режимов не мутирует базовый system prompt.

• Диалог растёт append-only.
• Summarization и compaction - это осознанный trade-off, а не “бесплатная оптимизация”.
• Truncation у длинных диалогов не ломает самый дорогой общий кусок в начале запроса.

• Для длинных общих префиксов есть stickiness:prompt_cache_key, affinity,prefix-awarerouting.
• Параллельный запуск не стартует раньше, чем успел прогреться первый запрос.

Время жизни кэша

• KV budget соответствует рабочему набору, а не “максимальному контексту из паспорта модели”.
• Есть наблюдаемость по вытеснению и повторному прогреву, а не только по среднемуcached_tokens.

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

Анти-паттернов много, но почти все они сводятся к трём поломкам: у запросов перестаёт совпадать начало, одинаковые запросы попадают на разные машины, или прогретый кэш слишком быстро исчезает.

И это главный практический вывод. Плохойprefix_cache_hitэто очень конкретная инженерная поломка: один timestamp, один плавающийtoolslist, один round-robin, один слишком маленький KV budget.

Если тема откликается, в своемканалея обычно разбираю именно такие инженерные развилки - где проблема выглядит как “что-то подросла latency”, а корень на самом деле в одной детали архитектуры.