Увімкнення кешування промптів нічого мені не заощадило — навпаки, мій рахунок за OpenAI-API зріс приблизно на чверть. Винуватцем був один-єдиний рядок, який змінювався з кожним запитом: мітка часу, вбудована в системний промпт.

Провайдери LLM дозволяють розробникам кешувати фрагменти промптів, щоб знизити витрати на обробку токенів. Читання з кешу («hit») коштує лише одну десяту від звичайної вартості, тоді як запис у кеш («miss») коштує приблизно 1,25 × від норми. Якщо запис відбувається, але кешований фрагмент ніколи не зчитується, додаткова 25-відсоткова націнка витрачається марно. Саме це і сталося, коли через мітку часу промпт не міг збігтися з жодним існуючим записом у кеші.

Чому кешування може дати зворотний ефект

Кешування промптів працює шляхом зіставлення точної послідовності байтів кешованої частини. Провайдер хешує вхідні дані; якщо хеш збігається із збереженим записом, система повторно використовує попереднє обчислення і застосовує дешеву ставку за читання. Будь-яка зміна — навіть один символ — порушує збіг і змушує систему виконувати нове обчислення, яке тарифікується за вищою ставкою запису.

У моєму випадку системний промпт починався з:

Current session started: 2026-07-14T09:41:07Z

Оскільки мітка часу оновлювалася при кожному виклику API, перші кілька байтів запиту ніколи не були ідентичними. Провайдер сприймав кожен виклик як новий запис у кеші, нараховував премію за запис і ніколи не реєстрував читання. Результатом було постійне зростання cache_creation_input_tokens, тоді як cache_read_input_tokens залишався на нулі — це чітка ознака того, що кеш ніколи не спрацьовував.

Як виявити несправний кеш

Журнали використання, що надаються API, містять два ключові лічильники:

  • cache_creation_input_tokens — токени, що спричинили запис.
  • cache_read_input_tokens — токени, на які вплинуло читання з кешу.

Коли перший показник зростає, а другий залишається незмінним, це означає, що кеш не використовується повторно. Швидка перевірка полягає в тому, щоб повторити той самий запит двічі: якщо кеш працює, при другому виклику має спостерігатися стрибок токенів читання.

Як вирішити проблему

Рішення просте: переконайтеся, що кешована область є статичною для всіх викликів. Дотримуйтесь цих двох правил:

  1. Розміщуйте незмінний вміст на початку. Системні промпти, визначення інструментів або будь-які інструкції, що ніколи не змінюються, мають займати перші байти запиту.
  2. Додавайте змінний вміст наприкінці. Мітки часу, текст, створений користувачем, ID запитів або будь-які дані, що змінюються з кожним викликом, мають іти після кешованого сегмента.

Якщо зміститься хоча б один символ, хеш зміниться, і кеш знову не спрацює. Перестановка промпту так, щоб мітка часу була в кінці, відновлює частоту збігів у кеші та повертає рахунок до очікуваного низького рівня витрат.

Коли кешування справді допомагає

Кешування промптів найкраще проявляє себе в сценаріях, де один і той самий набір інструкцій використовується багато разів:

  • Цикли агентів (Agent loops), де ШІ неодноразово звертається до фіксованого набору інструментів.
  • Чат-сесії, які посилаються на довгий статичний документ, тоді як змінюється лише останній запит користувача.
  • Масове вилучення даних, де один і той самий промпт для парсингу застосовується до багатьох записів.

Для разових викликів, які щоразу містять новий контекст (наприклад, поодиноке запитання з унікальним вступом), кешування не дає переваг і може навіть збільшити витрати, якщо запит ненавмисно спровокує запис у кеш.

Приховані пастки

Навіть якщо сам промпт є статичним, запит може бути змінений на подальших етапах:

  • Проксі-сервери або агрегатори, які змінюють порядок або додають пробіли, можуть порушити побайтове зіставлення.
  • Шлюзові сервіси (Gateway services), які додають заголовки автентифікації або змінюють форматування JSON, можуть ненавмисно змінити кешований фрагмент.

Тестування через шлюз шляхом надсилання ідентичного запиту двічі та перевірки лічильників читання допомагає переконатися, що шлях кешування залишається цілісним.

Загальна картина витрат

25-відсоткова націнка на запис — це не штраф за використання кешування; вона відображає додаткові обчислювальні ресурси, необхідні для зберігання фрагмента для майбутнього повторного використання. Коли відбувається збіг у кеші (cache hit), вартість різко падає — часто до частки від звичайної ставки. Головне — дати системі фактично звернутися до кешу. Інакше ви платите премію без жодної економії.

Контраргумент: кешування не померло

Деякі розробники стверджують, що складність управління статичними та динамічними частинами промптів переважає потенційну економію. Такий погляд ігнорує той факт, що багато виробничих конвеєрів (pipelines) вже розділяють конфігурацію (статичну частину) та дані користувача (динамічну частину). Структуруючи промпти відповідним чином, можна без додаткових зусиль використовувати той самий механізм кешування, який допоміг розробникам оригінального API. Компромісом є лише необхідність дотримуватися певної дисципліни при проєктуванні промптів, а не фундаментальний недолік технології.

Що варто зробити далі

  • Щотижня відстежуйте два лічильники кешу у вашій панелі керування використанням.
  • Проводьте аудит побудови промптів, щоб переконатися, що будь-який змінний елемент розташований після закешованого блоку.
  • Проводьте A/B-тестування з кешуванням і без нього на репрезентативному робочому навантаженні, щоб кількісно оцінити реальну економію.
  • Перевіряйте шлюз (gateway), порівнюючи необроблені корисні навантаження (payloads) запитів до та після використання будь-якого проксі.

Висновок

Кешування промптів може різко скоротити витрати на LLM API, але лише за умови, що закешований сегмент є справді ідентичним у всіх викликах. Випадкова мітка часу або будь-який інший динамічний токен на початку промпту змушує систему щоразу виконувати дорогий запис, що збільшує рахунок. Розміщуючи статичні інструкції на початку, а мінливі дані — в кінці, ви дозволяєте кешу виконувати свою роботу та тримаєте витрати під контролем.