Microsoft разделила контроль затрат AI-агентов на лимиты, бюджеты и ROI

Счёт за модель теряет контекст агента

Microsoft завершила серию The Economics of Agent Optimization материалом о постоянном управлении расходами. Исходная проблема появляется при масштабировании: один deployment обслуживает несколько агентов, один агент обращается к нескольким моделям и инструментам, а один полезный результат требует многих turns. В агрегированном invoice уже трудно увидеть, какая команда, agent или workflow создали расход.

Cost management в Microsoft Foundry показывает оценочную стоимость проектов, отдельных агентов, токенов и моделей. Каждый Foundry project автоматически связывается с project tag на underlying usage, поэтому FinOps-команда может распределять траты по business unit, команде или workload. При этом Microsoft Cost Management и итоговый invoice остаются системой учёта для финансовой сверки; интерфейс Foundry предназначен прежде всего для операционных решений.

Наблюдаемость дополняет сумму объяснением. AI Gateway может выдавать token metrics по API, product, user, subscription, gateway и backend, а tracing в Foundry фиксирует tool usage, retries, latency, tokens и cost конкретного запуска. Evaluations добавляют quality, safety, groundedness и task completion, позволяя проверить, не куплено ли снижение цены ценой неприемлемого качества.

Budget alert — не circuit breaker

Microsoft проводит важную границу между финансовым предупреждением и исполнением политики в request path. Foundry Control Plane вместе с AI Gateway может задать tokens-per-minute и суммарные token quotas на уровне проекта. Превышение rate limit возвращает `429 Too Many Requests`, исчерпание quota — `403 Forbidden`; периоды квоты могут быть часовыми, дневными, недельными, месячными или годовыми.

Для правил между проектами и поставщиками Azure API Management предлагает policy `llm-token-limit`: ключом может быть subscription, application, team, customer или workload identity. Microsoft заявляет единый governance pattern для OpenAI-compatible APIs, Anthropic Messages API, MCP servers и agent-to-agent APIs, а также load balancing и circuit breakers для проблемного backend.

Эти пределы не абсолютно точны. Счётчики поддерживаются каждым gateway независимо, а параллельные запросы способны ненадолго превысить границу, потому что окончательное число токенов известно после ответа. Значит, quota превращает бесконтрольный расход в предсказуемую область, но для строгой финансовой гарантии нужно отдельно учитывать concurrency, распределённые gateways и цену выбранной модели.

Финансовый бюджет работает после потребления

Microsoft Cost Management budgets используют billing data с фактическими ценами, credits и purchasing commitments. Они могут уведомлять владельцев о приближении actual или forecasted cost к порогу и запускать через Azure Monitor action group пользовательский workflow — например, ticket, сообщение операционной команде или automation runbook.

Но такие бюджеты не являются мгновенным spending cap: они реагируют на billing data уже после потребления. Token limit срабатывает раньше и способен отклонить новый model call. Поэтому Microsoft рекомендует оба слоя — request-time containment для работающего агента и финансовые budgets для accountability и планирования.

Пока слои используют разные единицы: платформа ограничивает токены, финансы планируют доллары, а стоимость токена зависит от модели и offer. Microsoft сообщает, что работает над dollar-denominated budgets, более точной attribution и controls ближе к месту исполнения, но описывает их как будущие возможности. Их нельзя считать доступной production-функцией до отдельного релиза.

ROI сравнивает стоимость не с нулём, а с результатом

ROI for agents in Foundry сейчас находится в private preview. Команда задаёт отслеживаемые outcomes — например, successful task completion, customer satisfaction или case deflection — назначает им business value и описывает критерий успеха. Система связывает outcomes со стоимостью моделей и инструментов и рассчитывает value generated, total cost, net value и ROI.

Dashboard позволяет сравнивать версии агентов по average value per conversation, pass rate и improvement percentage, а затем переходить от низкого ROI к конкретным traces. Там причиной может оказаться слишком крупная модель, повторяющиеся tool calls или workflow, который расходует токены, не достигая значимого результата.

Эта схема полезна только при честной модели ценности. Если outcome легко отметить, но он не соответствует доходу, экономии времени, качеству или риску бизнеса, красивый ROI закрепит неверную цель. Поэтому сначала нужен проверяемый контракт результата и attribution, затем — стоимость выполнения. В предложенной Microsoft системе traces объясняют действие, evaluations — качество, cost attribution — источник расхода, а ROI — целесообразность дальнейшего масштабирования.