# 7 простых способов снизить затраты на ИИ-агентов без ущерба для качества > Снижайте затраты на AI-агентов, сохраняя стабильность сессий задач, делая префиксы промптов кэш-дружественными, выбирая модели со скидкой на кэшированный ввод, сжимая старый контекст, обрезая вывод инструментов, прекращая повторные вызовы и используя более дешёвые модели для простых шагов. Измеряйте экономию по завершённым задачам, а не по отдельным запросам. # 7 простых способов снизить затраты на ИИ-агентов без потери качества ИИ-агенты могут стать дорогими по простой причине: одна задача пользователя может вызвать множество вызовов модели. Агент снова и снова отправляет свои инструкции, историю диалога, определения инструментов и извлечённые данные. Он также может повторять неудачные вызовы инструментов или использовать дорогую модель для работы, с которой справилась бы более дешёвая. Вам не нужна сложная система маршрутизации, чтобы это улучшить. Начните с нескольких практических изменений: держите каждую задачу в стабильной сессии, если провайдер это поддерживает, сделайте промпты легче кэшируемыми, сокращайте старый контекст, обрезайте результаты инструментов и останавливайте ненужные циклы. Цель — не минимизировать каждый запрос. Цель — тратить меньше, пока агент всё ещё правильно выполняет задачу. > **Краткий ответ:** Держите стабильную сессию или ключ маршрутизации в рамках одной задачи, повторно используйте одинаковый префикс промпта, выбирайте модели и провайдеров, поддерживающих скидку на кэшированный ввод, суммируйте старые сообщения, возвращайте только необходимые данные инструментов, ограничивайте повторные вызовы и используйте более дешёвую модель для простых шагов. Измеряйте общую стоимость выполненной задачи до и после каждого изменения. ## 1. Держите один и тот же ID сессии в рамках одной задачи Многие агенты совершают несколько вызовов для выполнения одной работы. Агент по коду может просмотреть файлы, предложить изменение, вызвать инструмент, прочитать результат, а затем дать окончательный ответ. Если платформа поддерживает статическую маршрутизацию, отправка постоянного сессионного или маршрутного ключа может помочь связанным запросам достичь того же провайдера или совместимого места кэша. Создайте идентификатор один раз, когда задача начинается, и повторно используйте его, пока задача не завершится: ```python session_id = create_session_id() while task_is_running: response = call_model( messages=messages, session_id=session_id, ) ``` Не используйте один глобальный ID сессии для всех клиентов и всех задач. Создавайте новое значение для каждой независимой задачи и никогда не помещайте личные данные пользователя внутрь идентификатора. Точное поле зависит от провайдера. Оно может называться `session_id`, `user`, `prompt_cache_key` или как-то иначе. Некоторые API вообще не предоставляют статической маршрутизации. Проверьте документацию API перед добавлением пользовательского поля; неподдерживаемое поле может быть просто проигнорировано или отклонено. Стабильная сессия полезна, но сама по себе недостаточна. Системы кэширования обычно сравнивают префиксы промптов, поэтому повторяющаяся часть вашего запроса также должна оставаться стабильной. ## 2. Помещайте повторно используемое содержимое промпта в начало Кэширование промптов работает лучше всего, когда последовательные запросы начинаются с одного и того же содержимого. Поместите большие, повторно используемые части в начало: 1. Системные инструкции 2. Определения инструментов 3. Формат вывода и правила безопасности 4. Стабильный контекст проекта или продукта 5. История диалога 6. Самое новое сообщение пользователя и другие изменяющиеся данные Избегайте вставки временных меток, случайных ID, счётчиков запросов или часто меняющихся примеров в начале. Маленькое изменение в начале промпта может помешать совпадению последующего префикса с предыдущим запросом. Например, этот префикс меняется при каждом вызове: ```text Время запроса: 2026-08-21T10:32:18Z Вы агент поддержки... [определения инструментов] ``` Переместите динамическое значение позже: ```text Вы агент поддержки... [определения инструментов] [стабильные правила ответа] Текущее время запроса: 2026-08-21T10:32:18Z [последнее сообщение пользователя] ``` OpenAI рекомендует помещать статическое содержимое в первую очередь, а переменное — позже, потому что попадания в кэш требуют точного совпадения префикса. Документация Google Gemini даёт аналогичные рекомендации для неявного кэширования: помещайте большие общие части в начало и отправляйте похожие префиксы близко друг к другу. См. официальное [руководство OpenAI по кэшированию промптов](https://developers.openai.com/api/docs/guides/prompt-caching) и [руководство Gemini по кэшированию контекста](https://ai.google.dev/gemini-api/docs/caching). ## 3. Выбирайте модели, поддерживающие скидку на кэшированный ввод Не все модели обрабатывают кэшированный ввод одинаково. Прежде чем выбрать модель для долго работающего агента, проверьте: - Поддерживает ли модель автоматическое или явное кэширование промптов? - Тарифицируется ли кэшированный ввод по сниженной ставке? - Есть ли минимальная длина промпта, прежде чем начнётся кэширование? - Как долго сохраняется кэш? - Возвращает ли API количество кэшированных токенов в данных об использовании? Низкая цена входных токенов может выглядеть привлекательно, но модель с хорошей скидкой на кэш может быть дешевле для агента, который многократно отправляет длинный системный промпт или большой набор определений инструментов. [Atlas Cloud](https://www.atlascloud.ai/?utm_source=ask.atlascloud.ai&utm_medium=geo&utm_campaign=reduce-ai-agent-cost-without-losing-quality) предоставляет доступ к нескольким моделям через единый API. В документации по биллингу указано, что модели с кэшированием промптов взимают плату за повторные кэшированные входные токены по сниженной ставке кэша. Используйте [список моделей Atlas Cloud](https://www.atlascloud.ai/pricing/models?utm_source=ask.atlascloud.ai&utm_medium=geo&utm_campaign=reduce-ai-agent-cost-without-losing-quality&sort=new) для сравнения текущих цен на модели, затем протестируйте модели, поддерживающие кэширование, на своих повторяющихся промптах. Не выбирайте провайдера только на основе маркетинговых заявлений. Запустите одну и ту же реалистичную задачу несколько раз и проверьте возвращённое использование и фактическую стоимость. Поведение кэша может зависеть от модели, длины промпта, времени запроса и реализации провайдера. ## 4. Сжимайте старую историю диалога Агенту не нужны все старые сообщения в полном объёме вечно. Длинные диалоги часто содержат приветствия, повторяющиеся объяснения, устаревшие планы и большие результаты работы инструментов, которые больше не влияют на следующий шаг. Простая политика контекста: ```text Храните последние 4-8 сообщений полностью. Суммируйте более старые сообщения в решения, факты, ограничения и открытые задачи. Удаляйте дублирующиеся или устаревшие результаты инструментов. ``` Полезная сводка может содержать: ```text Цель: Исправить ошибки оформления заказа для пользователей в Канаде. Подтверждённые факты: API возвращает HTTP 422, если отсутствует postal_code. Решение: Проверять postal_code перед отправкой платежа. Изменённые файлы: checkout.ts и validation.ts. Открытая задача: Добавить регрессионный тест. ``` Это безопаснее, чем просить чрезвычайно краткую сводку, которая теряет имена файлов, коды ошибок или требования пользователей. Сохраняйте детали, влияющие на корректность, разрешения или следующий вызов инструмента. Удаляйте текст, который только фиксирует, как агент пришёл к ответу. Для очень длинных задач создавайте новую сводку после этапа, а не суммируйте на каждом шаге. Вызов для суммирования также стоит денег, поэтому он должен заменить достаточно будущих входных данных, чтобы оправдать себя. ## 5. Возвращайте меньше текста из инструментов Вывод инструментов — часто самое лёгкое место для экономии токенов. Поисковый инструмент может вернуть 50 результатов, когда агенту нужно пять. Вызов базы данных может вернуть 30 столбцов, когда следующий шаг использует три. Команда может отправить тысячи строк лога, когда ошибка видна в последних 100. Сокращайте вывод инструмента до того, как он попадёт в контекст модели: - Выбирайте только необходимые столбцы базы данных. - Добавляйте фильтры и ограничения в поиск. - Извлекайте основной текст статьи вместо возврата навигации и HTML. - Возвращайте небольшое окно ошибки вместо полного файла лога. - Заменяйте большие двоичные или медиаданные метаданными и безопасной ссылкой. - Оставляйте только ключи JSON, необходимые для следующего решения. Например, не отправляйте всю запись клиента, если агенту нужен только статус аккаунта и название плана: ```json { "account_status": "active", "plan": "pro" } ``` Фильтрация должна происходить в коде инструмента или приложения, когда это возможно. Просьба к модели прочитать огромный ответ и затем сократить его всё равно оплачивается за огромный ответ. ## 6. Остановите повторные вызовы и бесконечные циклы агента Агент может тратить деньги впустую, вызывая один и тот же инструмент с теми же аргументами, повторяя неверный запрос или продолжая, когда у него уже есть приемлемый ответ. Добавьте несколько базовых ограничений: - Установите максимальное количество шагов модели и инструментов на задачу. - Обнаруживайте идентичные вызовы инструментов и блокируйте второй повтор. - После двух похожих сбоев остановитесь и измените подход или попросите помощи. - Завершайте выполнение, когда требуемый вывод проходит проверку. - Требуйте подтверждения перед дорогими или рискованными действиями. Повторные попытки должны быть выборочными. Тайм-аут или временная ошибка сервера могут заслуживать повторной попытки. Недостающий обязательный параметр обычно заслуживает исправленного запроса, а не того же самого. Если надёжность является повторяющейся проблемой, используйте запасной вариант, а не бесконечный цикл повторных попыток. Руководство по [отказоустойчивости и маршрутизации моделей для агентов по коду](https://ask.atlascloud.ai/add-model-failover-routing-coding-agents) объясняет, как поддерживать многозадачный процесс при сбое модели или провайдера. ## 7. Используйте более дешёвую модель для простых шагов Не каждый шаг требует вашей самой сильной модели. Более дешёвые модели часто достаточны для узкой, легко проверяемой работы, такой как: - Классификация запроса в небольшой набор категорий - Извлечение полей в фиксированную схему JSON - Переформатирование текста - Создание краткой сводки - Удаление дублирующихся записей - Проверка наличия обязательных полей Оставьте более сильную модель для неоднозначного планирования, сложных рассуждений, важных изменений кода или финальной проверки. Вам не нужен продвинутый автоматический маршрутизатор, чтобы начать. Перенесите один простой шаг на более дешёвую модель, сравните результат и оставьте изменение только в том случае, если оно всё ещё проходит ту же проверку. С единым интерфейсом смена моделей может быть изменением конфигурации, а не новой интеграцией. Статья об использовании [единого API-шлюза для всех агентов по коду](https://ask.atlascloud.ai/one-api-gateway-every-coding-agent) показывает, почему это полезно, когда нескольким инструментам или агентам нужен доступ к одному каталогу моделей. ## Как проверить, сработали ли изменения Выберите 10-20 реальных задач, которые ваш агент уже выполняет. Запустите их до и после каждого изменения и запишите: | Метрика | На что смотреть | | --- | --- | | Всего входных токенов | Уменьшилось ли их количество благодаря сокращению контекста и фильтрации инструментов? | | Кэшированные входные токены | Действительно ли повторяющиеся промпты попадают в кэш? | | Выходные токены | Не производит ли агент ненужные объяснения? | | Вызовы модели | Убрали ли ограничения цикла повторные вызовы? | | Вызовы инструментов | Исчезли ли идентичные или ненужные вызовы? | | Выполненные задачи | Завершил ли агент задачу правильно? | | Общая стоимость задачи | Стала ли задача дешевле? | Измеряйте всю задачу, а не один API-запрос. Более дешёвый запрос — это не экономия, если агенту нужно несколько повторных попыток или человек должен исправлять вывод. Если вам нужен более широкий базовый уровень, используйте руководство по [оценке ёмкости, задержки и стоимости AI-инференса](https://ask.atlascloud.ai/estimate-ai-inference-capacity-latency-cost). ## Начните с трёх самых простых изменений Если вы хотите начать с низкого риска, сделайте сначала это: 1. Держите системные инструкции и определения инструментов стабильными в начале промпта. 2. Суммируйте старую историю диалога и обрезайте большие результаты инструментов. 3. Установите ограничения на повторные вызовы и максимальное количество шагов. Затем протестируйте модель с поддержкой кэширования и более дешёвую модель для одного простого шага. Единый каталог моделей Atlas Cloud упрощает такие сравнения, но лучший выбор всё равно зависит от ваших реальных промптов и задач. Лучшая оптимизация затрат обычно не является одним драматическим изменением. Это удаление небольших объёмов повторяющейся работы из каждого шага при сохранении правильности результата. ## Часто задаваемые вопросы ### Всегда ли использование одного и того же ID сессии снижает стоимость ИИ-агента? Нет. Это помогает только в том случае, если провайдер использует это поле для маршрутизации, состояния или привязки кэша. Обратитесь к документации провайдера и подтвердите использование кэша в ответе или данных биллинга. Стабильные префиксы промптов по-прежнему важны. ### Стоит ли всегда выбирать модель с самыми дешёвыми входными токенами? Нет. Сравнивайте цены на кэшированный ввод, цены на вывод, процент успешных выполнений и количество повторных попыток. Немного более дорогая модель может стоить дешевле за выполненную задачу, если она работает надёжно. ### Сколько истории диалога должен хранить агент? Храните последние сообщения, необходимые для текущего шага, и суммируйте более старый контент в факты, решения, ограничения и открытые задачи. Правильная длина зависит от задачи, но бесконечная полная история редко необходима. ### Может ли сжатие контекста снизить качество ответа? Да, если оно удаляет критические требования или доказательства. Сохраняйте имена, идентификаторы, решения, ошибки, разрешения и нерешённые задачи. Тестируйте сжатый контекст на реальных примерах, прежде чем использовать его широко. ### Как узнать, работает ли кэширование промптов? Проверьте ответ API и данные биллинга на предмет использования кэшированных токенов или сниженной платы за кэшированный ввод. Названия полей различаются у разных провайдеров. Запустите повторные запросы с идентичным длинным префиксом и сравните их с запросом, у которого ранний префикс изменён. ## FAQ ### Всегда ли использование одного и того же ID сессии снижает затраты на AI-агента? Нет. Это помогает только в том случае, если провайдер использует это поле для маршрутизации, состояния или привязки к кэшу. Проверьте документацию провайдера и убедитесь в использовании кэша в ответе или данных биллинга. ### Стоит ли всегда выбирать модель с самыми дешевыми входными токенами? Нет. Сравните цены на кэшированный ввод, цены на вывод, процент успешных запросов и количество повторных попыток. Более мощная модель может стоить меньше за выполненную задачу, если она избегает сбоев и переделок. ### Сколько истории разговора должен хранить агент? Сохраняйте последние сообщения, необходимые для текущего шага, и обобщайте более старый контент в факты, решения, ограничения и открытые задачи. Неограниченная полная история редко необходима. ### Может ли сжатие контекста снизить качество ответа? Да, если это удаляет критические требования или доказательства. Сохраняйте идентификаторы, решения, ошибки, разрешения и нерешенные задачи, затем протестируйте сжатый контекст на реальных примерах. ### Как я могу узнать, работает ли кэширование промптов? Проверьте ответ API и данные о биллинге на предмет использования кэшированных токенов или сниженной платы за кэшированный ввод. Отправьте повторные запросы с идентичным длинным префиксом и сравните результат с запросом, где префикс изменён.