Кэширование префикса (также называют prompt caching или context caching) — одна из самых эффективных техник для снижения задержки и стоимости инференса LLM. Особенно полезно в продакшене, где часто повторяются структуры промптов: чаты, агенты, RAG-пайплайны.
Суть проста: если сохранить KV-кэш для одного запроса, то новый запрос с тем же префиксом может не пересчитывать эту часть промпта, а сразу использовать готовый результат.
Prefix caching отличается от семантического кэширования, где в базе хранятся полный ввод и вывод, и только точное совпадение (или очень похожий запрос) даёт кэш-хит.
Как работает кэширование префикса#
- На этапе prefill модель делает проход по всему входу и строит KV-кэш для attention.
- На этапе decode модель генерирует выходные токены по одному, используя кэшированные состояния из prefill. KV-пары для каждого токена хранятся в памяти GPU.
- Для нового запроса с тем же префиксом можно пропустить проход по кэшированной части и сразу продолжить с последнего токена префикса.
Это работает только если префикс совпадает полностью, включая пробелы и форматирование. Даже один символ разницы ломает кэш.
Например, чат-бот с таким системным промптом:
You are a helpful AI writer. Please write in a professional manner.Этот промпт не меняется от диалога к диалогу. Вместо пересчёта каждый раз, вы сохраняете его KV-кэш один раз. Когда приходят новые сообщения, используете этот кэш, обрабатывая только новую часть промпта.
Чем отличается KV caching от prefix caching#
KV caching — это хранение промежуточных attention-состояний каждого токена в памяти GPU. Изначально термин описывал кэширование внутри одного запроса, что критично для ускорения decode.
LLM работают авторегрессивно: на этапе decode каждый новый токен строится на основе предыдущих (т.е. с использованием KV-кэша). Без KV-кэша модель пересчитывала бы всё для каждого шага (а контекст только растёт), что крайне неэффективно.
Если распространить идею кэширования на несколько запросов, корректнее говорить о prefix caching. Поскольку вычисление KV-кэша зависит только от всех предыдущих токенов, разные запросы с одинаковым префиксом могут использовать один и тот же кэш и не пересчитывать его.
Как строить промпты для максимального кэш-хита#
Prefix caching помогает только при стабильных промптах. Вот лучшие практики для максимизации кэш-хитов:
- Ставьте статичный контент в начало: всё постоянное или редко меняющееся размещайте в начале промпта (системные сообщения, инструкции, общий контекст). Динамику и пользовательские данные — в конец.
- Группируйте похожие запросы: объединяйте запросы (особенно при обслуживании многих пользователей/агентов) с одинаковым префиксом, чтобы эффективнее переиспользовать кэш.
- Избегайте динамики в префиксе: не вставляйте timestamp, request ID и другие переменные в начало промпта — это снижает кэш-хит.
- Используйте детерминированную сериализацию: сериализация (например, JSON) должна быть стабильной по порядку ключей и структуре. Недетерминированная сериализация приводит к промахам кэша даже при одинаковом содержимом.
- Анализируйте кэш-хиты: регулярно проверяйте эффективность кэша и ищите точки для оптимизации.
Внедрение и прирост производительности#
Prefix caching может уменьшить вычисления и задержку на порядок в ряде сценариев.
- Anthropic Claude Sonnet поддерживает prompt caching: до 90% экономии и 85% снижения задержки для длинных промптов.
- Google Gemini делает скидку на кэшированные токены и отдельно считает стоимость хранения.
- Фреймворки vLLM, TensorRT-LLM, SGLang поддерживают автоматический prefix caching для разных open-source LLM.
В агентных пайплайнах эффект ещё сильнее: иногда соотношение входных и выходных токенов 100:1, и пересчёт больших промптов становится крайне дорогим.
Ограничения#
Для приложений с длинными повторяющимися промптами prefix caching может радикально снизить задержку и стоимость. Но со временем размер KV-кэша может стать очень большим. Память GPU ограничена, и хранение длинных префиксов для многих пользователей быстро её съедает. Нужны стратегии вытеснения кэша или многоуровневая память.
Open-source сообщество активно работает над распределёнными стратегиями сервинга. Подробнее см. prefix-aware routing.