Кешування промптів (Prompt Caching & KV Cache Reuse)(Кешування префіксів промптів та повторне використання KV-кешу)

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) переконайтеся, що сесії різних користувачів не використовують спільний префікс із конфіденційними персональними даними.