Кэш вместо повторного запроса: как агенты экономят токены и энергию

Осенью 2024 года Anthropic и OpenAI в течение нескольких месяцев выкатили кэширование части запроса (prompt caching) для своих API. Идея простая: если вы каждый раз отправляете модели один и тот же длинный системный промпт, документ или контекст, провайдер сохраняет их обработанное представление и не считает заново. Для разработчика это счёт в разы меньше и ответ быстрее. Но у той же оптимизации есть второй эффект, о котором говорят реже: повторный расчёт того же самого контекста — это потраченные впустую вычисления, а значит и электричество. Меньше повторов — меньше нагрузка на дата-центр.

Отсюда выросла идея, которую в англоязычных сообществах разработчиков стали называть zero waste agents: строить агентов так, чтобы они не гоняли одни и те же данные через модель по кругу. Кэш здесь не только про деньги, но и про то, чтобы не жечь ресурсы на работу, которую уже сделали минуту назад.

Что именно кэшируется и зачем

Языковая модель обрабатывает входной текст, разбивая его на токены¹ и прогоняя через слои трансформера. Для длинного контекста это дорогая операция — и по деньгам, и по вычислениям. Если 90% запроса от вызова к вызову не меняется (тот же свод правил, та же база знаний, та же инструкция агенту), считать это 90% заново каждый раз — прямая потеря.

Prompt caching решает это так: провайдер запоминает промежуточное состояние для неизменного префикса запроса. При следующем вызове с тем же началом он берёт готовое состояние из кэша и досчитывает только новую часть — ваш свежий вопрос.

Экономия на API у обоих крупных провайдеров существенная: чтение из кэша тарифицируется заметно дешевле обычных входных токенов. Точные коэффициенты и время жизни кэша периодически меняются, поэтому актуальные цифры смотрите в документации Anthropic и OpenAI, а не в пересказах.

Самый экологичный запрос к модели — тот, который вы не отправили дважды. Кэш просто делает это правило дешёвым.

Откуда берётся «экологичность»

Прямой связи «сэкономил токен — спас планету» тут нет, и честнее говорить осторожно. Но логика такая: inference (генерация ответа обученной моделью) потребляет энергию на каждый прогон через GPU. Повторная обработка идентичного контекста — это работа, результат которой уже был получен. Кэш её устраняет.

Публичных измерений именно энергетического эффекта prompt caching в пересчёте на киловатт-часы автор не встречал — приводить конкретную цифру экономии CO2 было бы выдумкой. Что можно утверждать обоснованно: меньше обработанных токенов означает меньше GPU-времени, а GPU-время в дата-центре напрямую конвертируется в электричество и охлаждение. Масштаб зависит от того, насколько повторяющиеся у вас нагрузки.

Где повторов особенно много

• Чат-боты поддержки. Один и тот же длинный системный промпт с правилами компании — на каждое сообщение каждого пользователя.
• Агенты с инструментами. Описание доступных функций и инструкций не меняется между шагами, а отправляется на каждом.
• RAG-приложения². Крупные документы, которые пользователь обсуждает в нескольких вопросах подряд.
• Пакетная обработка. Тысячи запросов с одинаковой инструкцией и разными данными на входе.

Кэш провайдера — не единственный слой

Prompt caching на стороне API убирает повторный расчёт префикса. Но самый радикальный способ не тратить вычисления — вообще не обращаться к модели, если ответ уже известен. Здесь работают два разных приёма, которые часто путают.

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

Кому это пригодится, а кому нет

Пригодится:

• Командам, у которых один длинный системный промпт обслуживает большой поток пользователей — экономия и на счёте, и на латентности заметна сразу.
• Агентам с фиксированным набором инструментов и инструкций, делающим много шагов подряд.
• Сервисам с типовыми повторяющимися вопросами, где уместен exact-match или аккуратно настроенный semantic cache.

Даст мало или навредит:

• Приложениям, где почти каждый запрос уникален и короткий — кэшировать нечего, а на организацию кэша уйдёт больше усилий, чем он сэкономит.
• Задачам, где ответ обязан быть свежим на каждый вызов (котировки, статусы заказов): закэшированный ответ здесь прямая ошибка.
• Случаям с редкими вызовами: время жизни кэша ограничено, и до повторного обращения он успеет протухнуть.

Как внедрять, чтобы был толк

1. Посмотрите на структуру своих запросов: вынесите неизменную часть (инструкции, правила, справочный контекст) в начало, переменную — в конец. Prompt caching работает по совпадающему префиксу.
2. Включите кэширование префикса в API согласно документации вашего провайдера и проверьте по счёту, что чтение из кэша действительно тарифицируется дешевле.
3. Для типовых вопросов добавьте слой exact-match поверх модели — самый безопасный из «ответных» кэшей.
4. Semantic cache вводите последним и с консервативным порогом близости, обязательно логируя, какие запросы он счёл совпадающими.
5. Настройте инвалидацию: если справочные данные обновились, кэш ответов на них нужно сбрасывать, иначе система будет уверенно врать.

Термин zero waste agent остаётся скорее лозунгом сообщества, чем стандартом с метриками. Но за ним стоит здравая инженерная привычка: считать, сколько лишней работы делает ваша система, и убирать повторы. Побочный бонус в виде меньшего энергопотребления — приятный, но вторичный по отношению к прямой выгоде в деньгах и скорости.

¹ Токен — фрагмент текста, которым оперирует модель: часто это часть слова. Стоимость запроса к API считается в токенах на входе и на выходе.

² RAG (Retrieval-Augmented Generation) — подход, при котором модель отвечает, опираясь на подтянутые из базы документы, а не только на то, что запомнила при обучении.