Agent optimization в Microsoft Foundry начинается не с снижения token cost, а с цены успешного outcome. Для agentic system это важнее, потому что один результат часто требует нескольких model requests.
Главная проблема здесь не в модели как таковой, а в том, что prototype легко превращается в production default. В прототипе обычно выбирают сильнейшую available model, кладут в prompt весь возможный контекст и проверяют, что идея работает. Это логично на этапе валидации, но плохо масштабируется экономически, потому что один agent loop может включать десяток model requests.
Дальше система начинает платить за лишнюю сложность дважды. Во-первых, разные AI workloads имеют разную природу: classification, extraction, formatting, summarization и multi-step reasoning не требуют одинаковой мощности. Во-вторых, каждая ошибка в loop создает новые turns, повторные calls к tool и лишние tokens. Поэтому стоимость успешного outcome определяется не только ценой одного request, но и числом turns, которые удалось избежать.
Из этого и вытекает решение: runtime optimization должна распределять нагрузку по задачам, а не отправлять все запросы на один frontier model. Microsoft Foundry дает для этого четыре рычага: model routing, выбор deployment strategy, prompt caching и tuning через optimizer. Это прагматичный набор, потому что каждый рычаг можно применять отдельно, измерять по quality bar и откатывать, если trade-off не держится.
Первый рычаг — model router in Foundry Models. Он оценивает incoming request и перенаправляет его к подходящей underlying model через единый endpoint и single deployment. Routing modes позволяют сдвигать баланс в сторону cost, quality или компромисса между ними. Model subsets, которые теперь align with Azure Policy, ограничивают выбор approved allow-list там, где нужен compliance boundary, а built-in failover добавляет resilience, если одна model недоступна.
Второй рычаг — deployment choice. Standard deployments дают гибкость и pay-as-you-go pricing. Priority processing подходит для interactive applications, где важна более ровная latency. Provisioned Throughput Units, или PTUs, помогают при predictable demand и sustained throughput. Для large asynchronous workloads, таких как document processing, classification и evaluation runs, Foundry предлагает Batch deployments, которые могут дать up to 50% lower costs, если immediate response не требуется.
Здесь важен архитектурный компромисс. Один и тот же продукт может содержать разные traffic patterns, и у каждого из них своя экономическая логика. Developer-facing tools могут жить на Standard. Chat experiences часто требуют Priority. Agentic applications с постоянной нагрузкой выигрывают от PTUs. Background jobs вроде document analysis или knowledge extraction можно вынести в Batch, не затрагивая end-user experience.
Третий рычаг — fine-tuning и caching. Fine-tuning полезен тогда, когда behavior стабилен, а volume достаточно высок, чтобы окупить effort. В этом случае smaller model может приблизиться к large model на конкретной задаче, потому что learns task, tone or format. Это снижает rate и сокращает prompts, но не является универсальным ответом: если задача часто меняется, экономический смысл тоньше.
Agents особенно cache effective, потому что system instructions, tool schemas и policy text повторяются на каждом turn. Prompt caching позволяет reuse previously processed prefix вместо повторной обработки. Важно сохранить структуру prompt: stable content должен идти первым, а volatile content — ниже. Если наверх поставить timestamp, user name или другой изменяемый фрагмент, cache hit не сработает, потому что exact match на старте prompt нарушится.
Кэширование работает и на уровне инфраструктуры. Если перед Foundry inference APIs стоит gateway, имеет смысл выбрать semantic-cache-aware gateway, например AI Gateway в Azure API Management. Оно помогает поддерживать session affinity к тем же endpoints и лучше использовать cache across sessions and users. Deterministic tool results тоже можно держать в собственном store с TTL, который соответствует частоте изменения данных.
Четвертый рычаг — instruction optimization и observability. Prompt optimizer переписывает system instructions по best practices prompt engineering и показывает reasoning for each change. Agent optimizer in Foundry Agent Service идет дальше: он прогоняет agent по dataset из real tasks, генерирует candidate configurations, score-ит их и ранжирует. Он может менять instructions, skills, tool descriptions и model selection, а dataset может строиться на собственных agent traces.
Без наблюдаемости здесь не работает ни одна оптимизация. Foundry observability дает per-request signals: input and output tokens, cache hit rate, latency, actual served model и evaluation scores. В этой схеме особенно важны две метрики: cost per request и cost per completed outcome. Первая показывает локальную эффективность. Вторая показывает, сколько бизнес реально заплатил за завершенную задачу с учетом turns и retries.
Практический вывод простой. Сначала измеряйте cost, latency и task success вместе. Затем держите standing evaluation set, который любая optimization должна пройти перед release. После этого связывайте traces, evaluation sets, budgets, alerts и cost tagging в Azure, чтобы regression была видна сразу, а не в конце месяца. В этом и состоит инженерная логика статьи: экономия не должна ломать quality, safety и latency, а правильная система должна улучшать все три параметра одновременно.