Кэширование LLM в 2026: как сократить счёт за API в 10 раз

ПОЧЕМУ СЧЁТ ЗА API РАСТЁТ БЫСТРЕЕ ТРАФИКА

Классическая ловушка 2026 года: агент, RAG-пайплайн или чат-бот тащит в каждый запрос один и тот же гигантский контекст — системный промпт на 5к токенов, набор few-shot примеров, документацию, определения инструментов. Пользователь спрашивает одно короткое предложение, а вы платите за 6000 входных токенов заново. Тысяча запросов в день — и вы прогоняете один и тот же префикс тысячу раз по полной цене.

Input-токены дешевле output, но именно на раздутом входе горит бюджет продакшн-нагрузки. Классификация, суммаризация, tool-heavy агенты — везде повторяется стабильная «шапка». Кэширование убирает эту переплату: провайдер один раз обрабатывает префикс, сохраняет промежуточное состояние модели и на следующих запросах отдаёт его почти даром.

ЧТО ТАКОЕ PROMPT CACHING НА САМОМ ДЕЛЕ

Главное, что нужно усвоить про prompt caching: это префиксное совпадение. Кэш-ключ выводится из точных байтов отрендеренного промпта до контрольной точки. Любое изменение байта в позиции N инвалидирует кэш для всего, что идёт после N.

Порядок рендеринга запроса фиксирован: сначала tools, затем system, затем messages. Контрольная точка на последнем блоке системного промпта закэширует и инструменты, и систему вместе. Отсюда единственное правило, из которого следует вся оптимизация:

• Стабильное — вперёд. Неизменный контент (замороженный системный промпт, детерминированный список инструментов) идёт до контрольной точки.
• Волатильное — назад. Таймстампы, per-request ID, меняющийся вопрос — после последней контрольной точки. Иначе каждый запрос уникален и кэш никогда не читается.

ЭКОНОМИКА: СКОЛЬКО РЕАЛЬНО ЭКОНОМИТ КЭШ

Разберём цифры, потому что тут вся суть стоимости. У Anthropic кэш работает через мультипликаторы к базовой цене входных токенов:

Отсюда точка безубыточности. С TTL 5 минут кэш окупается уже на двух запросах: 1.25x (запись) + 0.1x (чтение) = 1.35x против 2x без кэша. С TTL 1 час нужно минимум три запроса: 2x + 0.2x = 2.2x против 3x. Часовой TTL держит запись живой в паузах бурстового трафика, но удвоенная цена записи требует больше чтений, чтобы отбиться.

Теперь про «в 10 раз». Если у вас 10к токенов стабильного контекста и 100 запросов поверх него: без кэша это 100 × 10к = 1млн токенов по 1x. С кэшем — один раз 10к × 1.25 + 99 раз 10к × 0.1 ≈ 12.5к + 99к ≈ 111.5к «эквивалентных» токенов. Кэшируемая часть подешевела примерно в 9 раз. По замерам сообщества на реальных агентских нагрузках экономия на input-части обычно ложится в диапазон 5-10x — точная цифра зависит от доли стабильного префикса в общем объёме.

КАК ВКЛЮЧИТЬ: CACHE_CONTROL НА ПРАКТИКЕ

Самый простой вариант — top-level автокэширование: провайдер сам ставит контрольную точку на последний кэшируемый блок. Для тонкого контроля — cache_control на конкретных блоках. Рабочий пример на Python с Anthropic SDK:

import anthropic

client = anthropic.Anthropic()

# Большой стабильный документ кэшируем, вопрос — нет
response = client.messages.create(
    model="claude-opus-4-8",
    max_tokens=1024,
    system=[
        {
            "type": "text",
            "text": LARGE_STABLE_CONTEXT,          # 10k+ токенов доков
            "cache_control": {"type": "ephemeral"} # TTL по умолчанию 5 минут
        }
    ],
    messages=[{"role": "user", "content": "Суммируй ключевые пункты"}],
)

# Проверяем, что кэш реально сработал
u = response.usage
print("записано в кэш:", u.cache_creation_input_tokens)  # платим ~1.25x
print("прочитано из кэша:", u.cache_read_input_tokens)    # платим ~0.1x
print("некэшировано:", u.input_tokens)                    # полная цена

Для часового TTL: "cache_control": {"type": "ephemeral", "ttl": "1h"}. Максимум 4 контрольные точки на запрос. cache_control вешается на любой блок — системный текст, определение инструмента, блок сообщения (text, image, tool_result, document).

МИНИМАЛЬНЫЙ ПРЕФИКС: ПОЧЕМУ КЭШ МОЛЧА НЕ РАБОТАЕТ

Частая жалоба: поставил cache_control, а cache_creation_input_tokens — ноль. Ошибки нет, кэша тоже. Причина — префикс короче минимума. Он зависит от модели:

Промпт на 3к токенов закэшируется на Sonnet 4.5, но молча не закэшируется на Opus 4.8. Свежие релизы SDK и изменения лимитов удобно отслеживать в каталоге REDDYX — там же подборки инструментов для замера токенов и профилировки промптов.

ТИХИЕ УБИЙЦЫ КЭША: ЧЕК-ЛИСТ АУДИТА

Если cache_read_input_tokens стабильно ноль при одинаковых на вид запросах — где-то в префиксе прячется инвалидатор. Пройдитесь по списку, это самая частая причина слитого бюджета на кэширование:

1. datetime.now() / Date.now() в системном промпте — префикс меняется каждый запрос.
2. uuid4() или request-ID в начале контента — то же самое, каждый запрос уникален.
3. json.dumps(d) без sort_keys=True или итерация по set — недетерминированная сериализация, байты плывут.
4. Интерполяция session/user-ID в системный промпт — per-user префикс, ноль переиспользования между юзерами.
5. Условные секции системного промпта (if flag: system += ...) — каждая комбинация флагов = отдельный префикс.
6. Набор инструментов, который меняется по юзеру или по ходу диалога — инструменты рендерятся в позиции 0, любое изменение рушит весь кэш.

Лечится одинаково: вынести динамику после последней контрольной точки, сделать её детерминированной или просто удалить, если она не несёт нагрузки. Смена модели тоже инвалидирует кэш целиком — кэши scoped по модели.

ПРОДВИНУТОЕ: ПРОГРЕВ, ОКНА И ПАРАЛЛЕЛЬ

Прогрев кэша

Чтобы убрать задержку холодного промаха на первом живом запросе, шлите на старте запрос с max_tokens: 0. Провайдер прогонит prefill, запишет кэш на вашей контрольной точке и вернётся сразу с пустым content — output-токены не тарифицируются, платите только за запись. Имеет смысл, когда задержка первого запроса видна пользователю и есть момент до трафика (старт приложения, деплой). При непрерывном трафике прогрев не нужен — первый живой запрос сам прогреет кэш.

Окно 20 блоков

Каждая контрольная точка идёт назад максимум на 20 контентных блоков в поисках прежней кэш-записи. В агентских циклах с кучей tool_use/tool_result один ход легко даёт больше 20 блоков — тогда следующая точка не находит прежний кэш и молча промахивается. Лечится промежуточной точкой каждые ~15 блоков.

Параллельные запросы

Кэш-запись становится читаемой только после того, как первый ответ начал стримиться. N параллельных запросов с одинаковым префиксом все платят полную цену — никто не читает то, что остальные ещё пишут. Для fan-out: шлите 1 запрос, дождитесь первого токена, потом запускайте остальные N−1.

КОГДА КЭШ НЕ НУЖЕН

Не кэшируйте, если промпт меняется с самого начала каждый запрос. Если первые 1к токенов различаются от вызова к вызову — переиспользуемого префикса нет, cache_control только платит премию за запись при нуле чтений. Также нет смысла кэшировать префикс короче минимума модели — штраф холодной записи там пренебрежимо мал. И не прогревайте спекулятивно десятки разных префиксов: каждый — это запись по ~1.25x, суммарно легко перекроет сэкономленную задержку.

Если ковыряете кэширование, замер токенов и оптимизацию LLM-пайплайнов на продакшене — я каждый день выкладываю разбор свежих инструментов и репозиториев по этой теме в Telegram-канал REDDYX AI — новые репозитории каждые 30-60 минут.