← Все статьи
#LLM#prompt-caching#стоимость#Anthropic

Prompt caching: как мы снизили счёт за LLM в 4 раза одной строкой

2026-04-24

Prompt caching: как мы снизили счёт за LLM в 4 раза одной строкой

Самая частая дыра в бюджете на LLM — не выбор модели, не длинные ответы, а повторная отправка одного и того же контекста в каждом запросе. Системный промпт на 3000 токенов, база знаний на 15000, примеры на 2000 — и так 500 раз в день. Платите каждый раз, как за первый.

Prompt caching решает это за 10 строк кода и без потери качества. Разбираю, как он работает на Anthropic API и почему большинство команд его не включают из-за одной неправильной интуиции.

Что такое prompt caching

Идея простая. Claude API даёт пометить части промпта как кешируемые. Первый запрос стоит дороже обычного (x1.25), но результат промпта-префикса сохраняется на сервере на 5 минут (или на 1 час в extended варианте). Каждый следующий запрос с тем же префиксом:

  • Не пересчитывается
  • Стоит в 10 раз дешевле за эти токены (0.1x от input price)
  • Отвечает быстрее — нет повторной обработки большого префикса

Экономия прямо пропорциональна доле повторяющегося контекста. В моей практике:

  • RAG-бот с фиксированной базой на 20k токенов → -75% расходов
  • Агент с длинным системным промптом + tools → -60%
  • Code assistant, читающий один и тот же файл-контекст → -80%

Как включить (Anthropic SDK, Node/Python)

Одно поле cache_control на нужном блоке:

const resp = await client.messages.create({
  model: "claude-sonnet-4-6",
  max_tokens: 2000,
  system: [
    {
      type: "text",
      text: BIG_SYSTEM_PROMPT,
      cache_control: { type: "ephemeral" }
    }
  ],
  messages: [{ role: "user", content: userQuery }]
});

Всё. На первом запросе в ответе увидите cache_creation_input_tokens: 3000, на последующих — cache_read_input_tokens: 3000 и цена за них в 10 раз ниже.

Где ставить точки кеша

Порядок блоков имеет значение. Кеш работает по префиксу: если изменится хоть один байт до точки cache_control, кеш инвалидируется и пересоздастся.

Правильная иерархия (от стабильного к изменчивому):

  1. tools (если есть) — меняются редко
  2. system — статичный
  3. База знаний / контекст документа — меняется на новых сессиях
  4. История диалога — растёт
  5. Новое сообщение пользователя — меняется всегда

До 4 точек cache_control на запрос. Обычная схема: одна на конце system, одна на конце истории.

Почему команды не включают

Три причины, которые слышу чаще всего.

"У нас динамический промпт, кешировать нечего." Проверьте токенами, не интуицией. Запустите логирование: сколько токенов в system vs. user message. В 80% случаев system занимает 70% запроса, а вы его переписываете между юзерами — а не между запросами одного юзера.

"Страшно, что что-то сломается." Не сломается. Кеш либо попадает, либо нет — корректность ответа идентична. Единственный риск — неправильно поставить точку (до изменчивой части), тогда просто не будет экономии. Смотрите cache_read_input_tokens в ответе.

"5 минут TTL — бесполезно, у нас запросы раз в час." Во-первых, extended cache (1 час) снимает вопрос. Во-вторых, даже 5 минут покрывают типичную сессию чата, RAG-бота, агента, пишущего цепочку действий. Раз в час — это не LLM-продукт, а cron-задача, там действительно не имеет смысла.

Edge-кейсы

Тулы с динамическими параметрами. Если tools в JSON генерируется на лету (например, список доступных функций меняется по роли пользователя), кеш будет мимо. Фикс: разделить tools на статичную и динамическую части, cache_control поставить на границе.

Разные модели, один кеш. Кеш привязан к модели. Перейдёте с Sonnet на Haiku — пересоздастся.

Счёт за cache_creation. Первый запрос платите 1.25x. Если в итоге запрос не повторится (например, пользователь ушёл) — это чистый убыток. В системах с низким попаданием в кеш (менее 20%) caching делает хуже. Меряйте hit rate в метриках.

Что измерять

Добавьте в логи три поля из ответа API:

  • cache_creation_input_tokens
  • cache_read_input_tokens
  • input_tokens (некешированные)

Cache hit rate = cache_read / (cache_read + input_tokens). Цель — выше 60%. Ниже 30% — пересмотрите, куда ставите cache_control.

Что сделать сегодня

Найдите один endpoint с самым большим трафиком. Посмотрите структуру промпта. Если там больше 1000 статичных токенов до первого изменчивого — добавьте cache_control. Замерьте счёт через неделю.

Разовое изменение, окупается на первых десятках запросов.

Нужна помощь оптимизировать LLM-стоимость под ваш сценарий? Напишите. Это входит в пакет "Аудит AI-инфраструктуры".