Кеширование Промптов (Prompt Caching & KV Cache Reuse)

1. Обзор концепции и системная проблема

В современной разработке с использованием агентов (например, Claude Code или Cursor) каждый диалог состоит из десятков итераций. При этом 90–95% информации в каждом запросе является полностью статичной:

• Системный промпт с правилами проекта (5 000 токенов).
• Схемы 20 подключенных MCP-инструментов (10 000 токенов).
• Проиндексированные файлы документации и кода (40 000 токенов).

Без кеширования на каждой реплике разработчика сервер вынужден заново прогонять все 55 000 статических токенов через матрицы трансформера (Prefill Phase):

1. Высокая финансовая стоимость: Вы платите полную цену за чтение одних и тех же 55 000 токенов 30 раз за сессию.
2. Большая задержка (High TTFT): Время до появления первого символа ответа растягивается на 5–10 секунд, убивая ощущение интерактивного вайбкодинга.
3. Расточительство ресурсов GPU: Вычислительные мощности видеокарт тратятся на повторение детерминированных расчетов.

Prompt Caching устраняет этот оверхед: сервер один раз вычисляет состояние внимания для статического префикса, фиксирует его в сверхбыстрой памяти HBM и мгновенно подхватывает готовое состояние при следующих вызовах.

2. Архитектурная таксономия и ментальная модель

Архитектура кеширования промптов строится вокруг следующих концептуальных слоев:

• 1. Структура префиксов (Prefix Hierarchy): Промпт проектируется как матрешка от наиболее статичного до наиболее динамичного: [Static System Prompt] -> [MCP Tool Definitions] -> [Cached Project Context] -> [Dynamic Turn History] -> [User Input].
• 2. Экономика состояний кеша:
  • Cache Write: первое обращение или запись после изменения префикса. Стоит на 25% дороже стандартного ввода, так как требует фиксации состояния в памяти.
  • Cache Hit / Read: повторное обращение к неизменному префиксу. Предоставляет скидку 80–90% от базовой стоимости входных токенов.
• 3. Точки сохранения (Breakpoints): Специфические маркеры в структуре запроса, которые сообщают движку инференса, где именно заканчивается стабильный блок, подлежащий сохранению.
• 4. Механизмы поиска кеша:
  • Radix Tree / Prefix Trie: структура данных в памяти сервера инференса (например, в vLLM / SGLang), которая мгновенно находит самый длинный общий цепочку токенов среди активных сессий.

3. Технический пайплайн и внутренняя механика

Жизненный цикл запроса с использованием Prompt Caching:

1. Serialization & Hash Verification (Хеширование префикса): Клиент отправляет массив сообщений. Сервер берет последовательность токенов от начала до первой точки cache_control и рассчитывает криптографический хеш префикса.
2. Trie Lookup (Поиск в дереве кешей): Менеджер памяти GPU проверяет, есть ли в наличии живой блок KV-кеша для этого хеша.
   • Если найдено (Cache Hit) — вычисление Prefill пропускается, сохраненные матрицы $K$ и $V$ мгновенно подключаются к вычислительному графу.
   • Если не найдено (Cache Miss) — сервер проводит полное вычисление и асинхронно записывает результат в буфер.
3. Dynamic Suffix Processing (Обработка суффикса): Трансформер вычисляет внимание исключительно для нового фрагмента — последнего сообщения пользователя (например, 200 токенов вместо 50 000).
4. Immediate Decoding & TTL Refresh (Генерация): Модель начинает генерацию ответа уже через 200–400 миллисекунд, а таймер жизни кеша сбрасывается на новый 5-минутный интервал.

4. Практические инженерные сценарии в продакшене

01. Многошаговые сессии разработки в Claude Code и Cursor

Агент выполняет сложный 15-шаговый рефакторинг. Благодаря кешированию кодовая база проекта (100 000 токенов) кешируется на шаге 1. На шагах 2–15 пользователь платит только за дельту правок, экономя до 85% общей стоимости разработки за вечер.

02. Кеширование больших библиотек инструментов MCP

Подключение 30 сложных корпоративных инструментов требует детальных JSON-схем, занимающих 12 000 токенов. Кеширование блока инструментов гарантирует, что разработчик не переплачивает за их описание на каждом банальном вопросе в чате.

03. Высоконагруженные корпоративные ассистенты с базы знаний

Чат-бот внутренней поддержки использует единый кешированный системный документ (регламенты, инструкции, FAQ) объемом 50 000 токенов. Тысячи сотрудников отправляют запросы одновременно, попадая в один и тот же кешированный слой на кластере моделей, обеспечивая минимальное время отклика.

5. Подводные камни, типовые ошибки и безопасность

• Утечка динамических данных в префикс (Timestamp Invalidation): Наиболее распространенная инженерная ошибка — добавление динамической строки типа Current Time: 2026-09-09 12:15:30 в начало системного промпта. Это каждую секунду изменяет первые токены и на 100% ломает кеширование для всех последующих модулей. Вынесите динамические переменные в финальные сообщения.
• Холодный старт после простоя: Если между шагами разработчика прошло более 5 минут, кеш испаряется. Следующий запрос снова оплачивается по тарифу Cache Write с задержкой на инициализацию.
• Смешивание прав доступа (Multi-Tenant Cache Bleed): На self-hosted серверах (vLLM) убедитесь, что сессии разных пользователей не используют общий префикс с конфиденциальными персональными данными.