Агентам искусственного интеллекта необходима специализированная инфраструктура. Селена Чеккинель, старший менеджер по маркетингу продуктов компании CoreWeave, рассказывает на портале The New Stack о том, как оптимизировать среды выполнения для многоэтапных агентных рабочих процессов.

Вы создали отличного агента, но что-то пошло не так, когда он перешёл в продакшен.

В тестовой среде ваш агент эффективно самостоятельно просматривал запросы на слияние (PR). Он читал различия, искал в коде связанные использования, запускал набор тестов, проверял, не остался ли красный индикатор CI после предыдущего коммита, и составлял комментарий — и всё это до того, как вы сами закончили читать diff.

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

Агент не меняется. Меняется среда выполнения, и именно это определяет, остается ли время ревью стабильным или увеличивается.

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

Вот почему эффективность вашего агента зависит от вашей инфраструктуры.

Разница между обслуживанием инференса чат-бота и агента ИИ заключается не просто в том, что один из них «более функционален». Они выполняют работу по-разному:

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

Такая модель выполнения меняет требования к инфраструктуре для агентов ИИ.

Вместо оптимизации для отдельных запросов инференса система должна поддерживать длительные рабочие процессы, задержка и надежность которых зависят от каждого компонента в цепочке.

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

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

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

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

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

Но пользователь видит не сбой в оркестрации. Он видит агента, который завис или сдался.

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

Второе отличие в агентных рабочих процессах застает команды врасплох: шаблоны спроса и их влияние на стоимость инференса.

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

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

• Пауза: агент ожидает ответа от внешнего API или базы данных, поэтому графический процессор (GPU), обслуживающий этот процесс, не выполняет задач по инференсу, а накопленный контекст может быть вытеснен из памяти GPU на время ожидания.
• Всплеск: как только внешние системы возвращают результаты, инференс возобновляется одновременно для множества процессов, создавая кратковременные и резкие скачки нагрузки на GPU, причем каждый процесс заново обрабатывает весь накопленный контекст.

Если при мониторинге загрузки GPU вы видите картину, напоминающую кардиограмму — ровную линию с резкими скачками в моменты получения результатов от инструментов, — это характерный признак. Это означает, что вы выделяете ресурсы исходя из средних показателей, тогда как нужно ориентироваться на пиковые; именно здесь чаще всего происходит незаметный, но критический рост задержки на уровне 99-го перцентиля (p99).

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

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

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

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

• Стабильная производительность на всей протяженности цепочки. Инфраструктура должна обеспечивать неизменную задержку при выполнении многоэтапных процессов, использующих различные инструменты.
• Масштабируемость, отвечающая скачкообразным нагрузкам. Инфраструктура должна быстро масштабироваться при колебаниях спроса на инференс, не требуя резервирования мощностей в периоды простоя.
• Предсказуемые затраты даже при динамических нагрузках. Счет за инфраструктуру должен отражать фактическое потребление ресурсов.
• Ничто из этого не устраняет скачки нагрузки, но меняет способ их обработки системой. Достаточно мощный одновременный всплеск или рабочий процесс, накапливающий значительный объем контекста перед паузой, все равно требуют определенных затрат. Цель — не нулевые затраты или отсутствие лимитов, а их предсказуемость.

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