Оптимизация стоимости AI агентов: как платить меньше за GPT и Claude

Когда у вас один AI-агент — расходы незаметны. Когда агентов становится 10, 16, 20 — счёт за API начинает удивлять. У меня работают 16 цифровых сотрудников: продажный бот, личный ассистент, модератор групп, мониторинг финансов, рассыльщик, генератор контента, агент по лидам, CEO-агент Альтрон и другие. В один момент я открыл статистику расходов и увидел: $200 только за неделю. В пересчёте на месяц — больше $800. При запланированном бюджете в $150.

Это был тот самый момент, когда стало ясно: автоматизация без контроля расходов — это как бизнес без бухгалтера. Работает, деньги тратятся, но куда именно — никто не смотрит. После двух вечеров аудита и оптимизации расходы упали до $45 в месяц. Экономия 77% при том же качестве работы всех агентов.

В этой статье разберу все стратегии оптимизации стоимости AI агентов — от выбора модели до локального запуска. С реальными цифрами, конкретными инструментами и примерами из практики.

Шаг 0: Аудит — что реально тратит токены

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

Как считать токены по агентам

Большинство команд хранят логи API-запросов в базе данных. Если у вас PostgreSQL, запрос для аудита выглядит примерно так: сгруппировать все вызовы API за последние 30 дней по имени агента, посчитать количество запросов, суммарный расход токенов и приблизительную стоимость. В OpenAI и Anthropic есть встроенная аналитика в личном кабинете — но там нет разбивки по агентам, если у вас один ключ на всё.

Решение простое: используйте разные API-ключи для разных агентов. Или добавляйте метаданные в заголовки запросов — OpenAI поддерживает поле user в запросах, которое можно использовать для идентификации агента. Тогда в дашборде вы увидите разбивку по «пользователям», то есть по агентам.

Что искать в аудите

Мой аудит показал три типичных паттерна, которые встречаются почти у всех, кто запускает агентов без контроля расходов:

• Холостые пробуждения. Агент просыпается каждый час, проверяет — ничего нет, засыпает. Каждая такая проверка стоит токенов. Мониторинг финансов у меня проверял базу каждый час, хотя данные обновляются раз в сутки. 23 из 24 проверок были абсолютно бессмысленны.
• Несоответствие модели задаче. Агент Alisa работала на Claude Opus — самой дорогой модели — и тратила $400 в месяц только на свою работу. 52% её пробуждений были пустыми. Задачи, которые она решала, спокойно решает Haiku за 1/20 цены.
• Длинный контекст без причины. Некоторые агенты передавали всю историю переписки — 200 сообщений — в каждый новый запрос. Это раздувает стоимость каждого вызова в 5–10 раз по сравнению с необходимым.

После аудита у вас будет список агентов с их реальной стоимостью в месяц и конкретные причины перерасхода. Только тогда имеет смысл переходить к оптимизации.

Стратегия 1: Выбор правильной модели

Это самый очевидный рычаг, но его игнорируют чаще всего. Разница в цене между «большой» и «маленькой» моделью огромная, а разница в качестве для большинства задач — минимальная или вовсе отсутствует.

GPT-4o-mini против GPT-4o — разница в цене в 16 раз. Claude Haiku против Opus — в 60 раз. Переключить агента с одной модели на другую — одна строчка кода. А сэкономить можно десятки долларов в месяц с каждого агента.

Как решить, какая модель нужна

Простое правило: начните с дешёвой модели и переходите к дорогой только если качество неприемлемо. Для 80% задач агентов хватает mini/Haiku варианта. Оставьте тяжёлые модели для:

• Генерации развёрнутых ответов клиентам, где тон и точность критичны
• Анализа сложных документов или нестандартных ситуаций
• Написания кода и технических решений
• Задач, где была проверена и подтверждена недостаточность более дешёвой модели

Отличный паттерн — двухуровневая маршрутизация. Первый запрос идёт на дешёвую модель: она классифицирует запрос и решает, нужна ли тяжёлая артиллерия. Только «горячие» запросы, требующие глубины, попадают на дорогую модель. Мой продажный бот работает именно так: GPT-4o-mini обрабатывает 90% диалогов, а GPT-4o подключается только для ключевых переговоров с горячими лидами.

Стратегия 2: Сжатие контекста

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

Скользящее окно вместо полной истории

Самый частый антипаттерн: передавать всю историю диалога с самого начала. Через 50 сообщений это превращается в огромный контекст, большая часть которого нерелевантна текущему вопросу. Решение — скользящее окно: передавайте только последние N сообщений. Для большинства задач достаточно последних 10–20 обменов. Всё, что старше — либо сжимайте в краткое резюме, либо выбрасывайте.

Я ограничил maxTurns для агента Alisa с 200 до 30 сообщений в контексте. Расходы на этого агента упали вдвое только от этого изменения. Качество ответов не ухудшилось — агент и так не помнил, что было 150 сообщений назад.

Оптимизация системного промпта

Системный промпт передаётся в каждый запрос. Если он весит 2000 токенов, а агент делает 100 запросов в день — это 200 000 токенов только на системный промпт. Пересмотрите каждое слово: убирайте повторения, примеры, которые не влияют на поведение, избыточные инструкции. Хороший системный промпт — короткий и конкретный.

Практика показывает: большинство системных промптов можно сократить на 30–50% без потери качества. Запустите A/B тест: короткий промпт против длинного. В большинстве случаев разницы в качестве нет, зато расходы падают.

Передавайте только нужные данные

Если агент работает с базой данных — не передавайте всю таблицу. Делайте точечные запросы и передавайте только релевантные строки. Мониторинг финансов, который раньше получал выгрузку всех транзакций за месяц, теперь получает только аномалии и итоговые суммы. Контекст уменьшился в 20 раз.

Стратегия 3: Кэширование ответов

Одинаковые вопросы не должны стоить денег каждый раз. Если сотни клиентов спрашивают «сколько стоит аренда?» или «есть ли бассейн?» — платить за генерацию каждого ответа через API бессмысленно.

Кэш на уровне приложения

Базовый подход: перед отправкой запроса в API проверяем, есть ли уже ответ на похожий вопрос в базе данных. Хэшируем нормализованный текст вопроса, смотрим в таблицу кэша. Если есть — отдаём готовый ответ. Если нет — делаем запрос, сохраняем результат.

Для продажного бота по недвижимости я добавил PostgreSQL-кэш для FAQ-ответов. Кэш сбрасывается раз в неделю или при обновлении данных по объектам. Результат: 40% запросов теперь обслуживается из кэша бесплатно. Средняя стоимость «ответа клиенту» упала в 1.7 раза.

Claude Prompt Caching

Anthropic предоставляет встроенный механизм кэширования промптов. Если у вас длинный системный промпт или большой документ, который передаётся в каждом запросе — его можно закэшировать на стороне Anthropic. Повторное использование закэшированного префикса стоит 10% от обычной цены. Для агентов с длинными системными промптами это даёт существенную экономию без какой-либо логики на вашей стороне — просто добавляете флаг `cache_control` к нужным частям запроса.

Семантическое кэширование

Более продвинутый вариант: кэшировать не по точному совпадению текста, а по семантическому сходству. Вопросы «сколько стоит вилла?», «какова цена аренды?» и «почём снять на неделю?» — семантически одинаковы. Используйте векторные embeddings для поиска похожих запросов в кэше. PostgreSQL с расширением pgvector справляется с этим без дополнительной инфраструктуры.

Стратегия 4: Debounce и батчинг

В групповых чатах особая динамика: сообщения приходят пачками. Пользователь пишет «привет», потом «хочу узнать», потом «про аренду виллы». Если агент отвечает на каждое сообщение отдельно — три запроса к API вместо одного. Debounce решает эту проблему.

Как работает debounce

Логика простая: получили новое сообщение — запускаем таймер на 3–5 секунд. Если за это время пришли ещё сообщения от того же пользователя — сбрасываем таймер и ждём снова. Только когда таймер истёк без новых сообщений — объединяем всё в один запрос и идём в API. Один запрос вместо трёх-пяти.

В групповых чатах с высокой активностью debounce даёт 60–70% экономии на API-вызовах. Модератор групп — самый активный агент — после внедрения debounce сократил количество запросов к API втрое. При этом скорость реакции почти не изменилась: 3-секундная задержка незаметна в диалоге.

Батч-обработка для фоновых задач

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

OpenAI Batch API предлагает 50% скидку для запросов, обработанных в батч-режиме с временем ответа до 24 часов. Если у вас есть задачи, которые не нужно решать мгновенно — это легкие деньги.

Стратегия 5: Предварительная фильтрация без AI

Не каждая задача требует AI. Это кажется очевидным, но на практике многие агенты прогоняют через модель всё подряд, включая то, что прекрасно решается простыми правилами.

Regex и словари для первого уровня

Модератор группы, который отправлял каждое сообщение в Claude Haiku для проверки на спам — типичный пример переплаты. 60–70% спама имеет очевидные паттерны: ссылки на казино, характерные фразы, кириллица в тексте для аудитории, которая пишет на индонезийском. Regex-фильтр на первом уровне отсеивает это за миллисекунды и бесплатно.

Я добавил трёхуровневую фильтрацию для модератора: сначала regex по известным паттернам спама, потом проверка по словарю нежелательных фраз, и только если оба уровня пропустили — запрос к AI. Расходы на модерацию упали на 65%, а скорость реакции выросла: regex срабатывает за 1–2 миллисекунды против 2–3 секунд у API.

Правила вместо AI для структурированных данных

Если задача сводится к проверке условий на структурированных данных — не нужен AI. Мониторинг финансов, который проверял «не превысил ли расход бюджет» — прекрасно делается SQL-запросом. Агент теперь вызывает AI только когда нужна интерпретация аномалии или генерация текста отчёта. Рутинные проверки делает скрипт.

Стратегия 6: Локальные модели для внутренних задач

Ollama позволяет запускать языковые модели прямо на сервере. Для внутренних задач, где данные конфиденциальны или качество коммерческих API избыточно, это даёт нулевые расходы на токены. Один раз инвестируете в сервер — потом AI-запросы бесплатны.

Что хорошо работает локально

Современные локальные модели — Llama 3, Mistral, Gemma — вполне конкурентоспособны для:

• Внутренней классификации и маршрутизации задач
• Извлечения структурированных данных из текста
• Суммаризации внутренних документов
• Обработки данных, которые нельзя передавать в облако
• Генерации шаблонных текстов по заданной структуре

Для задач, где важно качество ответа клиенту или нестандартные ситуации — лучше оставить облачные модели. Но для обработки данных «внутри» системы локальная модель вполне справляется и стоит ноль рублей за каждый запрос.

Гибридный подход

Оптимальный вариант для большинства компаний — гибрид. Внутренняя обработка, классификация и предварительный анализ — локально через Ollama. Финальная генерация ответов, работа с клиентами, сложный анализ — облачные модели. Такой подход может сократить расходы на API на 40–60% дополнительно к другим оптимизациям.

Стратегия 7: Адаптивные интервалы и event-driven архитектура

Polling — самый дорогой способ мониторинга. Агент просыпается каждую минуту, смотрит «есть ли что-то новое?», видит что нет, засыпает. И так 1440 раз в день. Платите за 1440 запросов, из которых 1400 ни к чему не привели.

Event-driven вместо polling

Правильная архитектура: агент просыпается только тогда, когда что-то произошло. Webhook вместо опроса. Telegram Bot API поддерживает webhooks — сообщение пришло, вызов агента произошёл. Никаких холостых проверок. Для баз данных — триггеры на изменение данных. Для файлов — inotify. Для внешних сервисов — webhooks и подписки на события.

Переход с polling на event-driven уменьшает количество API-вызовов на порядок. Вместо 1440 вызовов в день — ровно столько, сколько произошло реальных событий. Для большинства агентов это 10–100 событий в день, не больше.

Умные интервалы для задач, где webhook невозможен

Не всегда можно перейти на event-driven. Для таких случаев используйте адаптивные интервалы: агент проверяет реже в «тихое» время и чаще в активное. Финансовый мониторинг не нужен в 3 ночи — можно проверять раз в 6 часов. Модерация спама в рабочее время — каждую минуту, ночью — каждые 15 минут.

Также привяжите интервал к реальной частоте обновления данных. Если данные обновляются раз в сутки — нет смысла проверять каждый час. Найдите реальный паттерн обновлений для каждого агента и настройте расписание под него.

Реальные цифры: $200 → $45 в месяц

Вот как изменились расходы после применения всех стратегий на моём стеке из 16 агентов:

$155 в месяц экономии. $1860 в год. При этом ни один агент не стал работать хуже — несколько даже улучшились, потому что более короткий контекст означает более чёткие и релевантные ответы.

Больше всего удивил финансовый мониторинг. $18 в месяц уходило на то, чтобы агент каждый час смотрел в базу и говорил «всё нормально». Один SQL-запрос с триггером на аномалию заменил 90% этих вызовов. Агент теперь работает только тогда, когда реально что-то пошло не так.

Приоритет оптимизации: с чего начать

Если у вас мало времени и нужно получить результат быстро, вот порядок действий по убыванию ROI:

Быстрые победы (1–2 часа)

• Аудит расходов по агентам. Найдите самого дорогого агента. Скорее всего там и лежит основная проблема.
• Даунгрейд моделей. Переключите каждого агента на модель уровнем ниже и проверьте качество. В большинстве случаев разницы нет.
• Ограничение контекста. Уменьшите maxTurns или количество передаваемых сообщений. Начните с 20, при необходимости увеличьте.

Средние по сложности (2–8 часов)

• Кэш для повторяющихся запросов. Определите топ-20 самых частых вопросов к агенту и добавьте кэш.
• Regex-фильтрация для модераторов. Составьте список паттернов спама и добавьте предварительную проверку.
• Debounce для чат-агентов. 3–5 секунд задержки перед ответом, объединение сообщений.

Стратегические изменения (дни)

• Переход на event-driven архитектуру. Замена polling на webhooks и триггеры.
• Внедрение Ollama для внутренних задач.
• Семантическое кэширование с векторной базой данных.

ROI: когда дорогой агент всё равно окупается

Важное уточнение: оптимизация стоимости AI агентов — это не значит «сделать как можно дешевле». Это значит «платить ровно столько, сколько нужно, не больше». Есть задачи, где дорогая модель полностью оправдана.

Мой продажный бот для недвижимости обрабатывает клиентов, которые арендуют виллы от $3000 в неделю. Если качественный ответ GPT-4o закрывает сделку, которую GPT-4o-mini бы потерял — $5 на API полностью оправданы. Считайте не стоимость токенов, а стоимость ошибки и ценность сделки.

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

Инструменты для контроля расходов

Оптимизация — это не одноразовая задача. Расходы будут расти по мере добавления новых агентов и функций. Нужна система постоянного контроля.

Алерты на пороговые значения

Настройте алерт, который приходит в Telegram, если дневные расходы превысили заданную сумму. OpenAI и Anthropic поддерживают настройку лимитов в личном кабинете, но они не присылают уведомления до того, как лимит исчерпан. Лучше — собственный мониторинг, который проверяет расходы через API раз в час и присылает предупреждение при достижении 70% дневного бюджета.

Еженедельный отчёт по агентам

Автоматический отчёт каждый понедельник: топ-3 самых дорогих агента за неделю, динамика расходов, аномалии. Это 10 минут анализа в начале недели, которые предотвращают неприятные сюрпризы в конце месяца. Отчёт генерирует агент — он же и следит за своими «коллегами».

Лимиты по умолчанию для новых агентов

Каждый новый агент запускается с жёсткими лимитами: дешёвая модель по умолчанию, короткий контекст, редкий интервал. «Апгрейд» происходит только после того, как вы убедились, что более дорогие параметры дают измеримый результат. Это обратный подход к тому, с чего обычно начинают — «возьму GPT-4 на всякий случай».

Чеклист: проверьте своих агентов прямо сейчас

Если у вас работает хотя бы 2–3 AI-агента, пройдитесь по этому списку:

• Знаете ли вы стоимость каждого агента в месяц? Если нет — начните с мониторинга.
• Есть ли агенты, которые работают на GPT-4o или Claude Opus для задач уровня «ответить на FAQ»?
• Передаёт ли какой-то агент контекст длиннее 20 сообщений в каждом запросе?
• Есть ли агенты, которые делают polling чаще, чем обновляются данные?
• Кэшируются ли повторяющиеся запросы хотя бы для самых частых вопросов?
• Есть ли задачи, которые делает AI, но мог бы делать простой скрипт?
• Настроен ли алерт на превышение дневного бюджета?

Если на три и более вопроса ответ «нет» — у вас есть резерв для оптимизации. По опыту, в таких случаях расходы можно сократить на 40–60% за один рабочий день.