Что такое prompt caching: как API повторно использует начало запроса

Prompt caching — это когда API запоминает начало вашего запроса и использует его снова, если следующий запрос начинается так же. Текст вы по-прежнему отправляете целиком, но провайдеру не нужно заново обрабатывать повторяющуюся часть, а некоторые провайдеры берут за неё меньше. Работает только с началом запроса и только если оно совпадает до символа.

Бот поддержки, который каждый раз перечитывает одну и ту же страницу#

Допустим, у вас бот поддержки на 2 000 обращений в день. Каждый запрос начинается с одних и тех же 3 000 токенов: тон ответов, правила возврата, условия доставки. Дальше идёт короткое сообщение клиента — например, «Где мой заказ?» (Если токены пока туманны, сначала загляните в что такое токен.)

Без кеша провайдер читает все 3 000 токенов правил заново для первого обращения, для второго и для двухтысячного. Одна и та же страница, прочитанная 2 000 раз. С кешем первый запрос платит полную цену за чтение, а следующие, начинающиеся с того же текста, могут использовать готовую работу.

Именно это описано в руководстве DeepSeek API (проверено 24 октября 2026): контекстный кеш включён по умолчанию, код менять не нужно, а следующий запрос с совпадающим префиксом считается «cache hit». Кешируется только вход. Ответ каждый раз генерируется заново.

Что значит «то же самое»: правило префикса#

Кеш сверяет запрос с первого символа. Как только ваш запрос стал отличаться от сохранённого, всё после этого места считается новым. Поэтому порядок в запросе важнее его длины.

Вот ошибка, которая тихо убивает кеш. Разработчик хочет, чтобы бот знал время, и ставит его в самое начало:

Текущее время: 14:03:22
Ты — ассистент поддержки магазина...
(3 000 токенов правил)

Время меняется каждую секунду, первая же строка отличается в каждом запросе, и ничего после неё совпасть уже не может. Лечится переносом изменчивого в конец:

Ты — ассистент поддержки магазина...
(3 000 токенов правил)
Текущее время: 14:03:22
Клиент: Где мой заказ?

Теперь 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 по prompt caching (проверено 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-совместимый API CheapTokens, ключ берётся в личном кабинете.

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 из примеров выше. Теперь упражнение на порядок: добавьте в самое начало SYSTEM строку с текущим временем (datetime.now()) и запустите снова. Запросы больше не имеют общего начала — они различаются с первой же строки. Поставьте ту же строку в конец промпта, и общее начало вернётся.

Короткий чек-лист для ваших промптов:

1. Сначала стабильное: инструкции, правила, описания инструментов, примеры.
2. В конце изменчивое: дата, имя пользователя, последнее сообщение.
3. Префикс должен совпадать посимвольно — даже лишний пробел считается.
4. Прежде чем удивляться, что ничего не кешируется, проверьте минимальный размер у провайдера.
5. Смотрите в поля usage после правки, а не до неё.

Чтобы посчитать свою нагрузку, откройте страницу цен и подставьте размеры входа и выхода или начните со страницы DeepSeek. Когда первый запрос заработает, та же оценка для любого вашего промпта занимает минуту. А о том, сколько стоят две стороны запроса, — в статье входные и выходные токены.