Що таке кешування промптів? Як повторюваний промпт використовується повторно

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

Бот підтримки, який постійно перечитує ту саму сторінку#

Припустімо, ви керуєте ботом підтримки з 2 000 звернень на день. Кожен запит починається з тих самих 3 000 токенів: тон спілкування, правила повернення коштів, політика доставки. Після цього йде однорядкове повідомлення клієнта, щось на кшталт «Де моє замовлення?» (Якщо токени все ще незрозумілі, почніть з що таке токен.)

Без кешування провайдер знову читає всі 3 000 токенів правил для звернення номер 1, звернення номер 2 і звернення номер 2 000. Та сама сторінка, прочитана 2 000 разів. З кешуванням перший запит сплачує повну ціну за її читання, а пізніші запити, що починаються з того самого тексту, можуть повторно використати цю роботу.

Посібник API DeepSeek (перевірено 24 жовтня 2026 року) описує саме це: кешування контексту ввімкнено за замовчуванням, воно не потребує змін коду, а пізніший запит із перекривним префіксом вважається «влучанням у кеш». Кешується лише вхідні дані. Відповідь генерується заново щоразу.

Що вважається «тим самим»: правило префікса#

Кеш зіставляє з першого символу. Щойно ваш запит відрізняється від закешованого, усе після цієї точки є новим. Ось чому порядок вашого запиту важливіший за його довжину.

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

Current time: 14:03:22
You are a support assistant for a shop...
(3,000 tokens of rules)

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

You are a support assistant for a shop...
(3,000 tokens of rules)
Current time: 14:03:22
Customer: Where is my order?

Тепер 3 000 токенів правил ідуть першими й залишаються ідентичними. Та сама логіка охоплює два інші поширені випадки: довгий чат надсилає всю свою історію на кожному кроці, тож старі повідомлення — це готовий повторюваний початок (докладніше в чому довгий чат коштує дорожче), а агент повторює свої визначення інструментів та інструкції на кожному кроці.

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

Як це побачити: поля кешу в usage#

Вам не потрібно вгадувати, чи це спрацювало. Кожен провайдер повідомляє про це в частині usage відповіді, під власними назвами полів.

DeepSeek використовує два поля:

• prompt_cache_hit_tokens — вхідні токени, знайдені в кеші
• prompt_cache_miss_tokens — вхідні токени, яких там не було

Припустімо, ваше перше звернення підтримки повертається з prompt_cache_hit_tokens: 0 та prompt_cache_miss_tokens: 3200, а звернення за хвилину потому показує prompt_cache_hit_tokens: 3000 та prompt_cache_miss_tokens: 200. 3 000 токенів правил було повторно використано; лише нове повідомлення клієнта та кілька токенів прочитано з нуля. Якщо число влучань залишається нулем під час кожного виклику, подивіться на початок вашого запиту: щось там змінюється.

Anthropic працює інакше, бо ви позначаєте, що кешувати. Ви додаєте cache_control з типом ephemeral до запиту або до блоку вмісту:

{
  "model": "your-model-id",
  "max_tokens": 300,
  "system": [
    {
      "type": "text",
      "text": "You are a support assistant... (long rules)",
      "cache_control": {"type": "ephemeral"}
    }
  ],
  "messages": [{"role": "user", "content": "Where is my order?"}]
}

Згідно з документацією Anthropic щодо кешування промптів (перевірено 24 жовтня 2026 року), відповідь повідомляє три числа: cache_creation_input_tokens (записано в кеш зараз), cache_read_input_tokens (прочитано з нього) та input_tokens (те, що йшло після останньої точки розриву кешу). Припустімо, перший виклик показує cache_creation_input_tokens: 10000, cache_read_input_tokens: 0; другий показує 0 та 10000. Це запис у кеш, за яким іде читання з кешу.

На екрані є одна пастка. Промпти, коротші за мінімум моделі (512, 1 024 або 4 096 токенів, залежно від моделі), обробляються без кешування й без помилки. Ви побачите нулі в обох полях кешу й жодного попередження. Типовий час життя — 5 хвилин, він безкоштовно оновлюється під час кожного використання; необов'язковий ttl зі значенням 1h зберігає його довше.

Як це впливає на ваш рахунок#

Кешування змінює ціну повторюваної частини, тож варто порахувати один раз. Anthropic наводить множники до базової ціни вхідних даних: запис у кеш із 5-хвилинним часом життя коштує 1,25×, читання коштує 0,1× (0,05× для Opus 5.5 та Sonnet 5.5). Візьмімо префікс на 10 000 токенів, повторно використаний у 20 запитах протягом 5-хвилинного вікна, зі стандартним читанням 0,1×:

10 000 × 20 = 200 000 токенів за базовою ціною без кешування

10 000 × 1,25 = 12 500 для першого запиту, що записує кеш

19 × 10 000 × 0,1 = 19 000 для 19 запитів, що читають його

12 500 + 19 000 = 31 500 токен-еквівалентів із кешуванням

Отже, повторювана частина коштує значно менше ніж п'яту частину суми без кешування. Підступ: якщо 5 хвилин минають між запитами, наступний знову записує кеш за 1,25×, і рідко використовуваний префікс може врешті-решт коштувати дорожче, ніж без кешування взагалі.

Тепер бот із початку, як простий базовий показник за повною ціною. 2 000 запитів на день, 3 000 вхідних токенів і близько 300 вихідних токенів кожен:

2 000 × 3 000 = 6 000 000 вхідних токенів на день

2 000 × 300 = 600 000 вихідних токенів на день

Таблиця оцінює денне навантаження на кожній доступній моделі CheapTokens поряд з OpenRouter:

DeepSeek-V4-Flash дешевша за OpenRouter загалом, з урахуванням вхідних і вихідних даних разом, і навантаження легко вміщується: контекст 380K і до 32 768 вихідних токенів на відповідь. Це вартість навантаження за повною ціною: вхідні токени × ціна за токен. Довгий стабільний префікс — це місце, де ця частка вхідних даних найбільша.

Спробуйте самі за п'ять хвилин#

План: надішліть той самий довгий системний промпт двічі з різними запитаннями й подивіться на usage. Вставте свій текст правил у support_rules.txt (достатньо сторінки-двох тексту). Кінцева точка — сумісний з OpenAI CheapTokens API, а ключ можна взяти зі свого облікового запису.

from openai import OpenAI

client = OpenAI(base_url='https://api.cheaptokens.dev/v1', api_key='YOUR_API_KEY')

SYSTEM = open('support_rules.txt').read()  # long, never changes

for question in ['Where is my order?', 'Can I change the address?']:
    r = client.chat.completions.create(
        model='deepseek-ai/DeepSeek-V4-Flash-0731',
        messages=[
            {'role': 'system', 'content': SYSTEM},
            {'role': 'user', 'content': question},
        ],
        max_tokens=300,
    )
    print(r.usage)

Що перевірити у виводі: prompt_tokens показує, наскільки великий ваш запит. Обидва запити містять той самий текст SYSTEM, тож більша частина цього числа повторюється від запиту до запиту — приблизно розмір вашого файлу правил. Цей повторюваний початок — це частина, яку провайдер із кешуванням, як-от DeepSeek API або Anthropic вище, може повторно використати. Тепер вправа на порядок: додайте рядок із поточним часом (datetime.now()) на початок SYSTEM і запустіть знову. Два запити більше не мають спільного початку, бо вони відрізняються з найпершого рядка. Поставте той самий рядок у кінець промпту — і спільний початок повернеться.

Короткий контрольний список для ваших власних промптів:

1. Стабільний текст спочатку: інструкції, правила, визначення інструментів, приклади.
2. Змінний текст у кінці: дата, ім'я користувача, останнє повідомлення.
3. Зберігайте префікс побайтово ідентичним — навіть зайвий пробіл має значення.
4. Перевірте мінімальний розмір провайдера, перш ніж дивуватися, чому нічого не закешовано.
5. Дивіться на поля usage після зміни, а не до неї.

Щоб оцінити вартість власного навантаження, відкрийте сторінку цін і введіть свої розміри вхідних і вихідних даних, або почніть зі сторінки DeepSeek. Щойно перший запит спрацює, та сама оцінка займе хвилину для будь-якого промпту, який ви напишете. Про те, скільки коштують обидві сторони запиту, дивіться вхідні vs вихідні токени.