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