Исследование Azure: агентным нагрузкам нужен агент-ориентированный runtime

Новый препринт arXiv, частично основанный на производственных трассах Microsoft Azure, вносит важную поправку в привычный разговор о корпоративных агентных системах. Агент — это не просто LLM-эндпоинт с подключёнными инструментами. Это меняющийся граф исполнения: в рамках одного запроса чередуются инференс модели, вызовы инструментов, планирование, координация и работа на стороне хоста.

Это различие существенно, поскольку каждый участок графа по-разному нагружает машину. Работа «Architectural Implications of Agentic AI Workflows» была подана 5 августа исследователями из Университета Техаса в Остине и Microsoft Azure. Авторы утверждают, что для агентных нагрузок нужны runtime-подходы, отличные и от обычных веб-сервисов, и от изолированного LLM-инференса.

Что изменилось: в разговор о runtime пришли производственные данные

Исследование объединяет 24-часовую трассу производственных агентных запросов в Microsoft Azure с контролируемыми экспериментами на SWE-Agent, Trae, CORAL и Owl. Контролируемые тесты проводились на сервере с 96-ядерным AMD EPYC 7V12 и восемью GPU NVIDIA A100 при параллелизме от одной до 32 задач.

Главное наблюдение не в том, что агенты требуют много вычислений. Их спрос на ресурсы фрагментирован и изменчив. Запрос переходит между инференсом, оркестрацией и исполнением инструментов, а не следует относительно устойчивому профилю веб-запроса или пакетной инференс-задачи. В данных Azure время исполнения инструментов для более чем 27% запросов было сопоставимо со временем инференса или превышало его. Поэтому работа CPU на стороне хоста часто оказывается на критическом пути.

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

“В агентной системе исполнение — не фоновая деталь за моделью. Это часть самой работы.

Что не изменилось: универсального правила консолидации нет

Статья не предлагает универсальный рецепт, как разместить больше агентной работы на меньшем числе машин. Особенно ясно это видно по результатам с GPU. В Owl консолидация высвободила треть GPU, повысила пропускную способность генерации на 82% и сократила хвостовую задержку в 2,5 раза. В CORAL протестированная конфигурация сбора свободных ресурсов снизила пропускную способность на 71% и ухудшила хвостовую задержку в 16 раз.

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

Чтобы проверить этот тезис, исследователи создали Agora — исследовательский прототип runtime для стандартных серверов. Agora использует незанятую ёмкость CPU и GPU, разделяет ядра CPU по runtime-ролям, сохраняет affinity задач и меняет политики в зависимости от структуры workflow и нагрузки. Это не продукт Microsoft Azure, и Agora не развёртывался во всём производственном парке Azure. Трасса парка использовалась для характеристики нагрузок, а Agora отдельно оценивался на open-source фреймворках.

В тестах CPU-harvesting при низкой нагрузке на четырёх фреймворках Agora обеспечил в среднем 95% автономной пропускной способности colocated-нагрузки при замедлении агента менее чем на 3%. Для режимов низкой и высокой нагрузки статья сообщает о среднем восстановлении 74% пропускной способности, росте утилизации CPU на 31% и росте задержки агентов на 3,3%. Это результаты прототипа, а не общее обещание производительности; результат CORAL как раз объясняет необходимость такой осторожности.

Почему это важно: решения runtime — это решения управления

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

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

Это не означает, что планировщик становится системой авторизации или что runtime автоматически решает задачи соответствия требованиям. Agora не демонстрирует ни механизмы безопасности, ни применение политик. Архитектурный вывод уже и практичнее: слой исполнения должен открывать операционное состояние, которым могут пользоваться системы управления. Размещение, runtime-роль, параллелизм, affinity, бюджет ресурсов, задержка в очереди и распределение задержек не должны оставаться невидимой облачной механикой, если от них зависит безопасное и предсказуемое завершение делегированного процесса.

Проектировать runtime как поверхность контроля

Агент-ориентированный runtime должен воспринимать workflow не только как контейнер или запрос к модели. Он должен различать фазы и роли, сохранять сигналы, необходимые для управления ими, и делать компромиссы явными. Тогда операторы смогут задавать разные ожидания по производительности для исследовательской задачи с низким риском, ответа клиенту и чувствительного ко времени финансового или операционного действия.

• Назначайте бюджеты ресурсов и лимиты параллелизма для agent workflow и его runtime-ролей, а не только для общего кластера или модельного эндпоинта.
• Разделяйте мощности планировщика, оркестрации и запуска инструментов там, где этого требует профиль нагрузки; не предполагайте, что один пул будет одинаково предсказуем для всех трёх.
• Наблюдайте за очередями, конкуренцией на хосте, хвостовыми задержками, использованием ускорителей и длительностью работы инструментов наряду с метриками модели и журналами действий.
• Считайте изменение политики размещения или консолидации контролируемым операционным изменением: оно требует подтверждений для конкретной нагрузки, а не предположений для всего парка.
• Используйте runtime-сигналы в решениях о допуске и эскалации: процесс, не получивший нужных условий исполнения, должен отложить работу, безопасно деградировать или передать её человеку.

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

Поэтому организациям, строящим устойчивую автономию, стоит расширить понятие управления агентами. Разрешения отвечают, допустимо ли действие. Контроль runtime помогает установить, способна ли система выполнить это действие в условиях, которые организация считает приемлемыми. При масштабировании обе части необходимы для ответственного исполнения.