Знакомый сценарий: в каждый запрос уходит один и тот же блок. Системная инструкция на несколько страниц, описание схемы базы, кусок документации. Модель читает его с нуля при каждом обращении, и каждое чтение попадает в счёт.
Когда кэширование окупается
Нужны три условия одновременно:
- Повторяющийся блок крупный. Выгадывать на паре абзацев нет смысла.
- Он совпадает от запроса к запросу до последнего символа.
- Запросы приходят часто. Кэш живёт ограниченное время, и если пауза между обращениями затянулась, он не поможет.
Типичные случаи, где это работает: агент с длинным сводом правил, чат-бот поверх большой документации, пакетная обработка однотипных документов по общей инструкции.
Что ломает кэш
Изменился хотя бы один символ в повторяющейся части, и кэш промахивается. Классическая ошибка: вставить в инструкцию сегодняшнюю дату или идентификатор запроса. Кэш ломается на каждом вызове, а заметить это непросто.
Постоянное и переменное держите раздельно: постоянное вперёд, переменное в конец.
Порядок частей в запросе
Кэш читается с начала запроса. Поэтому стабильный блок идёт первым, меняющийся последним. Если переменная часть окажется в начале, из кэша выпадет и всё, что стоит после неё.
Как прикинуть экономию в деньгах
Возьмите размер повторяющегося блока, умножьте на число запросов в месяц и на цену входных токенов. Получится, сколько вы сейчас тратите только на повторную отправку одного и того же.
Теперь сравните с ценой чтения из кэша: она заметно ниже обычной цены входа.
Прикинуть всё на своих объёмах можно в калькуляторе на сайте.
Запись в кэш стоит дороже
Первая запись обходится дороже обычного чтения. Если вы обращаетесь к кэшу один-два раза, он невыгоден. Окупаться он начинает с третьего-четвёртого обращения.
Отсюда правило: не кэшируйте то, что используется один раз.
Итог
Кэширование выигрывает на крупном стабильном начале запроса при частых обращениях. Стабильное кладите вперёд, переменное в конец и следите, чтобы даты и идентификаторы не просочились в постоянную часть.