Сколько стоит одновременная работа нескольких AI Agent? Расходы на токены, параллельные задачи и серверные ресурсы

Считайте стоимость одновременной работы нескольких AI Agent по полной цепочке задачи, а не по числу агентов: отдельно записывайте входные и выходные токены, вызовы инструментов, повторы и время использования сервера. На этой неделе добавьте идентификаторы задач в журналы и проведите нагрузочную проверку на реальных рабочих сценариях. Такой подход подходит, если вы создаёте параллельный процесс и должны контролировать его бюджет и стабильность.

Эта инструкция пригодится разработчикам серверной части, которым нужна стоимость каждой задачи; техническим основателям, планирующим расходы и маржу; специалистам эксплуатации, которым важно совместить параллельность с устойчивой работой среды.

До первого запуска: цепочка задачи вместо счёта агентов

Один агент не равен одному обращению к модели. Он может сначала составить план, затем вызвать инструмент, передать его результат модели, уточнить ответ и повторить действие после сбоя. Главный агент может делегировать работу нескольким дочерним агентам, а затем собрать их результаты. Поэтому смета вида «цена одного диалога × число агентов» пропускает значительную часть расходов.

Начните с описания цепочки. Для каждого типа задачи обозначьте:

• Главного и дочерних агентов. Кто создаёт подзадачи, а кто исполняет их?
• Вызовы модели. На каком этапе возникает каждый запрос и какую модель вы используете?
• Передаваемый контекст. Какие инструкции, история и результаты инструментов попадают в следующий запрос?
• Инструменты. Какие действия выполняются вне модели и создают ли они отдельные расходы?
• Повторы и циклы. Что запускает повтор, кто его прекращает и может ли цепочка повторять одно действие без продвижения к результату?

Присвойте задаче устойчивый идентификатор и передавайте его через дочерние процессы, обращения к модели и инструменты. Записывайте идентификаторы родительской задачи и отдельного вызова. Тогда по журналу можно восстановить, например, что неудачный запрос запустил повтор, а тот снова передал полный контекст.

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

Для первичной оценки используйте формулу на уровне задачи:

Стоимость модели = сумма по всем вызовам (входные единицы × цена входа + выходные единицы × цена выхода) + отдельно тарифицируемые компоненты.

Подставляйте действующие тарифы и единицы измерения именно того API, который вызывается. Не заменяйте их одной условной ценой «за агента»: такой расчёт потеряет различие между входом, выходом и дополнительными функциями. Отдельной строкой добавьте стоимость вычислительной среды, хранения и сети. Разделение важно: модельный счёт и серверная нагрузка растут по разным причинам.

Параллельно определите границы задачи. Где должен завершиться агент? Что считается успешным результатом? Как система поступает, если инструмент недоступен или модель вернула непригодный ответ? Без этих правил невозможно отличить полезный повтор от бесконечного цикла и оценить стоимость завершённого результата.

Перед нагрузочным тестом: стоимость и ресурсы в отдельных журналах

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

Для наблюдаемости свяжите журналы вызовов с трассировками и метриками. В описании сигналов OpenTelemetry выделены трассировки, метрики и журналы: трассировка помогает пройти путь одной задачи, метрики показывают изменение нагрузки, а журналы дают детали конкретных событий. Проставляйте общий идентификатор задачи во всех трёх видах данных. Тогда запрос «почему эта задача задержалась и сколько она вызвала запросов?» можно проверить, а не оценивать по общему счёту.

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

• число модельных вызовов и токенов на одну завершённую задачу;
• длина очереди, время ожидания и полная длительность задачи;
• процессорное время и пиковое потребление памяти;
• сетевой обмен, ошибки инструментов и повторы;
• стоимость API и стоимость среды за один завершённый результат.

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

Важно: параллельный запуск может увеличить число задач, завершённых за период, но не делает отдельную цепочку бесплатнее. Если каждое выполнение по-прежнему передаёт большой контекст или запускает лишние повторы, общий счёт растёт вместе с объёмом работы.

Перед тестом зафиксируйте конфигурацию эксперимента: сценарии, версию инструкций, выбранные модели, лимит активных задач и правила повтора. После изменения любого из этих условий сравнивайте результаты осторожно. Иначе вы не поймёте, что именно повлияло на затраты.

Первый расчёт: сценарии нагрузки вместо придуманной сметы

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

Для каждой группы задач рассчитайте следующие величины:

• ожидаемое число завершённых задач за выбранный период;
• средние и верхние наблюдаемые значения входных и выходных токенов;
• количество модельных обращений, обращений к инструментам и повторов;
• время работы среды и занятость ресурсов;
• расходы на постоянное хранение, обмен данными и фоновые задания.

Низкий сценарий может предполагать малое число задач и обычную структуру вызовов; ожидаемый — текущую планируемую нагрузку; высокий — рост очереди, более длинный контекст или повышенную долю ошибок. Опишите, почему вы включили каждое допущение. Например: «высокий сценарий предполагает повторную обработку части задач при недоступности инструмента». Не маскируйте предположение под прогноз.

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

Для актуальных правил начисления сверяйте не только страницу с тарифами, но и документацию по выставлению счетов. Смотрите, какие единицы учитываются, как отражаются разные типы данных и какие компоненты относятся к конкретному API. Цена без правильного объёма потребления не даёт полезной сметы.

После теста: корректировка и контроль на первой неделе

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

При расхождении ищите причину в цепочке:

• Длинный контекст. Проверьте, не передаются ли в каждый дочерний запрос история целиком и результаты, которые уже не нужны.
• Неудачные повторы. Разделите повторы из-за временной ошибки и повторы, вызванные неудачной логикой агента.
• Циклические вызовы. Установите, не возвращается ли процесс к одному инструменту без нового результата.
• Избыточное делегирование. Проверьте, оправдывает ли дополнительный агент свои вызовы и время выполнения.
• Злоупотребление инструментами. Определите, не использует ли агент действие чаще, чем нужно для выполнения задачи.

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

Как посчитать параллельные вызовы и бюджет

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

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

Постоянная работа: очереди, лимиты и расширение среды

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

Настройте ограничения на нескольких уровнях:

• предел активных запусков для каждой очереди;
• максимальное число повторов и условие окончательной остановки;
• лимит затрат на задачу или группу задач;
• общий сигнал о приближении к установленному вами бюджету;
• приостановку новых необязательных запусков при достижении порога.

Настраивайте значения по результатам теста и требованиям продукта, а не по универсальному числу. Предупреждение должно прийти достаточно рано, чтобы вы успели разобраться, но его порог зависит от допустимых расходов и времени реакции команды. Когда лимит срабатывает, журнал должен объяснить, какая задача или категория приблизила систему к нему.

Расширяйте серверную среду, если измерения показывают устойчивую очередь, превышение согласованного времени ожидания или нехватку ресурса при требуемом качестве выполнения. Сначала проверьте, что задержку не создаёт внешнее ограничение или неэффективный цикл. Масштабирование не исправит агент, который повторяет бесполезный вызов; оно может лишь позволить ему делать это быстрее и дороже.

Если вы используете оркестрацию контейнеров, документация по горизонтальному автомасштабированию Kubernetes описывает масштабирование числа реплик по целевым метрикам. Перед настройкой проверьте, что выбранная метрика связана с реальной перегрузкой. Для очереди агентов может быть важнее длина ожидания или загрузка процесса, чем один общий показатель CPU. Не задавайте пределы масштабирования, пока не проверили их нагрузочным тестом и не определили бюджет на дополнительное число процессов.

Выбор следующего действия: модель, процесс или среда

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

Используйте условия выбора:

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

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

Практический план на эту неделю

Перед первым запуском отметьте пункты, которые уже готовы:

• [ ] Каждая задача и каждый вызов связаны устойчивыми идентификаторами.
• [ ] В журнале различаются входные и выходные токены, модель, инструмент, попытка и результат.
• [ ] Метрики среды показывают процессор, память, сеть, время выполнения и очередь.
• [ ] Подготовлены сценарии низкой, ожидаемой и высокой нагрузки с явными предположениями.
• [ ] Есть отдельные лимиты для параллельности, повторов и бюджета.
• [ ] Проверен порядок действий при достижении предупреждения или остановочного порога.
• [ ] Смета обновляется по фактическим логам, а не по числу запущенных агентов.

Если не готовы идентификаторы и учёт вызовов, сначала сделайте их: без них нельзя надёжно объяснить отклонение бюджета. Если учёт уже работает, проведите тест на сценариях, включающих обычный запуск, инструмент и сбой, а затем скорректируйте пороги по наблюдаемым результатам.

Текущая серверная среда может оказаться предпочтительнее для постоянно работающих Linux-служб, плотной интеграции с существующей инфраструктурой или задач, которым требуются специфические сетевые условия. Но при разрозненных машинах и ручном запуске вы можете столкнуться с несопоставимыми журналами, трудным контролем параллельности и сложной проверкой воспроизводимости. Если тесту или сборке агента нужна именно macOS, аренда Mac через Hashvps позволит проверить эту часть процесса без покупки отдельного компьютера; если macOS не требуется, выбирайте среду, подходящую вашему развёртыванию. Перед решением можно сверить обзор услуг Hashvps и описание пакетов Hashvps, а затем подготовить список требований к тестовой среде.