Бессерверная архитектура должна быть первой моделью выполнения, которую команды оценивают для рабочих нагрузок ИИ-агентов. Многие агенты проводят большую часть времени в ожидании, а постоянно работающие вычисления заставляют команды платить за каждую минуту простоя. В study of more than 35,000 production coding-agent sessions средняя продолжительность сеанса работы LLM или вызова инструментов составляла лишь 20% от его общего времени. Всё остальное время система простаивала между шагами, а её песочница оставалась выделенной.
Согласно Gartner’s 2026 CIO and Technology Executive Survey, ИИ-агенты демонстрируют самую агрессивную кривую внедрения среди всех измеренных технологий, однако темпы роста опережают зрелость платформ, что затрудняет масштабирование агентов. Когда Google Cloud опросила более 1400 руководителей высшего звена ИТ-сферы для своего исследования 2026 State of AI Infrastructure report, 83% из них заявили, что им потребуются модернизации инфраструктуры для поддержки агентного ИИ промышленного уровня. Команды могут воспринимать проблему готовности как повод выделить постоянные вычисления, развернуть новый кластер, расширить существующую платформу или даже выбрать другую топологию развертывания. Бессерверная архитектура предлагает менее инвазивный путь масштабирования агентного ИИ.
В бессерверной модели платформа выделяет мощности по мере поступления запросов и масштабирует их до нуля при прекращении запросов, поэтому команды могут добавлять рабочие нагрузки агентов без управления кластером. Хотя некоторым агентам требуются выделенные мощности, многие из них могут работать в бессерверном режиме. Длительные процессы могут использовать долговечные бессерверные рабочие процессы для сохранения прогресса и высвобождения вычислительных ресурсов во время ожидания, а затем возобновлять работу, когда готов следующий шаг.
В этой статье мы объясним, как протестировать бессерверный режим по умолчанию для ваших рабочих нагрузок агентов и скорректировать подход по мере поступления производственных данных. Мы рассмотрим, как:
- Определить, использует ли агент вычислительные ресурсы с перерывами
Определить, использует ли агент вычислительные ресурсы с перерывами
- Скомпоновать более длительные или возобновляемые процессы агентов в виде долговечного бессерверного рабочего процесса
Скомпоновать более длительные или возобновляемые процессы агентов в виде долговечного бессерверного рабочего процесса
- Сравнить поведение в рабочей среде и стоимость с постоянно активными или выделенными мощностями
Сравнить поведение в рабочей среде и стоимость с постоянно активными или выделенными мощностями
- Использовать производственные данные, чтобы переносить только те шаги, требования к задержке или времени выполнения которых оправдывают другое размещение рабочей нагрузки
Использовать производственные данные, чтобы переносить только те шаги, требования к задержке или времени выполнения которых оправдывают другое размещение рабочей нагрузки
Оценить, требуются ли вашей рабочей нагрузке ИИ-агента непрерывно доступные вычислительные ресурсы
Отношение к рабочим нагрузкам агентов так, будто все они принадлежат к одной категории, может привести к тому, что команды выделят непрерывно доступные вычислительные ресурсы до того, как узнают, требуются ли они рабочей нагрузке. Создав профиль выполнения рабочей нагрузки, вы сможете определить, нужны ли агенту выделенные воркеры или он может безопасно работать по запросу.
Создание профиля выполнения рабочей нагрузки для принятия решения о размещении
Профиль выполнения фиксирует характеристики рабочей нагрузки и требования к времени выполнения, которые определяют, где и как должна выполняться рабочая нагрузка агента. Размещение рабочей нагрузки описывает процесс выбора модели выполнения для рабочего процесса агента или отдельного шага, например, вычисления по запросу, минимальное количество экземпляров, прогретый сервис или пул выделенных воркеров.
Создание профиля выполнения проясняет, какие ресурсы должны оставаться доступными, когда ни один шаг агента не выполняется активно. Например, если доступны должны быть только долговечное состояние и триггер для следующего шага, бессерверный рабочий процесс может подойти лучше всего.
Мы рекомендуем включить следующие входные данные в ваш профиль выполнения:
- Триггер и шаблон поступления
Триггер и шаблон поступления
- Шаблон ответа, например синхронный, асинхронный или потоковый
Шаблон ответа, например синхронный, асинхронный или потоковый
- Пиковая скорость поступления и продолжительность всплеска
Пиковая скорость поступления и продолжительность всплеска
- Пиковая параллельность
Пиковая параллельность
- Целевое время отклика, например максимально приемлемое время до получения первого результата или завершения
Целевое время отклика, например максимально приемлемое время до получения первого результата или завершения
- Время активных вычислений на один запуск
Время активных вычислений на один запуск
- Общее прошедшее время на один запуск
Общее прошедшее время на один запуск
- Использование вычислительных ресурсов за ожидаемое рабочее окно
Использование вычислительных ресурсов за ожидаемое рабочее окно
- Максимальная продолжительность шага
Максимальная продолжительность шага
- Требования к памяти и ЦП
Требования к памяти и ЦП
- Требования к ускорителю, локальному хранилищу, постоянному соединению и частной сети
Требования к ускорителю, локальному хранилищу, постоянному соединению и частной сети
Входные данные в вашем профиле выполнения показывают, когда поступает спрос и как быстро он накапливается. Если вы полагаетесь только на ежедневные средние показатели, вы можете выбрать модель выполнения, которая не подходит для данной рабочей нагрузки.
Например, для рабочей нагрузки, получающей 1000 событий в день, в среднем приходится менее одного события в минуту, что создает впечатление, будто достаточно небольшого постоянно работающего воркера. Дневное среднее значение скрывает тот факт, что все 1000 событий поступают в виде ночного пакета. Когда пакет поступает, воркер может быть перегружен или не успеть обработать пакет в рамках требуемого времени. Анализируя пиковую скорость поступления, продолжительность всплеска и время, в течение которого спрос остается нулевым, вы можете определить, подходят ли вычисления по запросу. В этом случае режим по запросу подходит хорошо, если бессерверная платформа способна поглотить всплеск, а нижестоящие системы могут справиться с возникающей параллельностью.
Отделите активные вычисления от общего прошедшего времени
Соотношение времени активных вычислений за один запуск к общему прошедшему времени за один запуск является ранним сигналом для размещения рабочей нагрузки. Низкий коэффициент усиливает аргументы в пользу выполнения по запросу, в то время как высокий коэффициент может указывать на то, что выделенные воркеры могут быть более экономичными, особенно в сочетании со стабильным поступлением запросов. Следующая анимация показывает один запуск агента, в котором вычисления по запросу выполняются только короткими всплесками, в то время как постоянно работающий воркер остается выделенным на протяжении всего запуска, включая длительные периоды ожидания между шагами.
Для новой рабочей нагрузки агента создайте первоначальный профиль выполнения на основе ожидаемого трафика, репрезентативного прототипа или результатов нагрузочного тестирования. Если вы используете Datadog, трассировки Agent Observability и APM могут помочь вам измерить общее прошедшее время за запуск и продолжительность отдельных шагов на уровне модели, инструментов и приложения. Мониторинг бессерверных вычислений (Serverless Monitoring) может измерять продолжительность выполнения каждого бессерверного компонента, что вносит вклад в время активных вычислений запуска. Он также может сообщать объем вызовов, параллельность, использование ЦП и памяти. Если вы используете AWS Lambda, расширенные метрики также сообщают об использовании ЦП и процессорном времени. После развертывания обновите профиль выполнения с помощью производственных измерений.
Скомпонуйте более длительные или возобновляемые запуски агентов в виде долговечных бессерверных рабочих процессов
Запуск агента, который завершается в рамках одного вызова, может не требовать долговечной оркестрации. В таких случаях использование функции или бессерверного контейнера позволяет избежать лишних затрат и сложности. Если запуски охватывают несколько шагов или требуют приостановки и возобновления, оптимальным выбором может стать долговечный бессерверный рабочий процесс.
Долговечный бессерверный рабочий процесс объединяет компоненты с разными ролями. Например:
- Оркестратор записывает прогресс и решает, когда каждый блок готов к выполнению.
Оркестратор записывает прогресс и решает, когда каждый блок готов к выполнению.
- Бессерверные примитивы выполнения, такие как функции, бессерверные контейнеры или управляемые задания, выполняют активную работу.
Бессерверные примитивы выполнения, такие как функции, бессерверные контейнеры или управляемые задания, выполняют активную работу.
- Внешние хранилища сохраняют артефакты и данные приложений, которые переживают процесс выполнения.
Внешние хранилища сохраняют артефакты и данные приложений, которые переживают процесс выполнения.
Мы рекомендуем разделить выполнение агента на ограниченные единицы работы. Каждая единица работы должна иметь определенные входные данные, выходные данные, а также условия завершения или сбоя. После завершения каждой ограниченной единицы работы или паузы в рабочем процессе оркестратор может записать его прогресс. В дальнейшем рабочий процесс может возобновиться с контрольной точки, а не перезапускать весь запуск целиком. Если шаг завершается с ошибкой, оркестратор может повторить его без повторного выполнения уже завершенных шагов. Спроектируйте каждый шаг так, чтобы повторная попытка не дублировала внешние побочные эффекты, такие как отправка повторного письма или двойное списание средств с клиента. На следующем скриншоте из Datadog Serverless Monitoring показан рабочий процесс AWS Step Functions, разделенный на ограниченные шаги, с входными данными, выходными данными и статусом, которые оркестратор записал при завершении шага deliveryShipper.
Чтобы определить, где рабочий процесс может сделать паузу, сопоставьте выполнение агента от триггера до завершения и классифицируйте каждое ожидание как ответ инструмента, задержку при ограничении частоты запросов (rate-limit backoff) или одобрение человеком. Рабочий процесс может освободить вычислительные ресурсы в момент ожидания, если он может сохранить свое состояние и возобновить работу по таймеру, событию или обратной связи (callback). Если шаг должен поддерживать работу процесса (например, для потоковой передачи ответа или поддержания постоянного соединения), он не может приостанавливаться и может потребовать предварительно прогретых вычислительных ресурсов.
Облачные и управляемые службы предоставляют различные модели программирования для надежных бессерверных рабочих процессов. AWS Step Functions и Google Cloud Workflows координируют шаги с помощью конечного автомата или внешнего определения рабочего процесса. Azure Durable Functions и AWS Lambda durable functions позволяют разработчикам описывать как шаги, так и ожидания в коде приложения. В обеих моделях прогресс рабочего процесса сохраняется независимо от вычислительного процесса, выполняющего отдельный шаг. Если вы используете эти службы, Datadog Serverless Monitoring может сопоставить выполнения рабочих процессов с данными телеметрии от функций, чтобы вы могли определить, где возникли ошибки или задержка — на отдельном шаге или на уровне оркестрации.
Отделите фреймворк агента от надежной оркестрации рабочего процесса
Многие команды используют фреймворки агентов, такие как LangChain или Vercel AI SDK, для ускорения развертывания. Отчет Datadog State of AI Engineering показал, что внедрение фреймворков агентов почти удвоилось в период с 2025 по 2026 год. Фреймворки агентов могут существенно различаться по масштабу: некоторые из них управляют вызовами моделей, выбором инструментов и циклом агента, в то время как другие поддерживают контрольные точки (checkpointing) или персистентное состояние рабочего процесса.
Когда внешний надежный оркестратор координирует рабочий процесс, мы рекомендуем, чтобы он отвечал за состояние рабочего процесса, планирование и возобновление, в то время как фреймворк агента управляет взаимодействием с моделями и инструментами в рамках каждого ограниченного шага. Такое разделение обязанностей позволяет процессу фреймворка завершаться без потери прогресса рабочего процесса и предотвращает бесконечную работу цикла агента на протяжении всего рабочего процесса.
Сравните выполнение по требованию с прогретой и выделенной емкостью для рабочих нагрузок AI-агентов
Профиль выполнения может помочь вам сравнить каждый вариант размещения рабочей нагрузки при одинаковой нагрузке. Затраты при работе по требованию обычно увеличиваются пропорционально активному времени вычислений и активности рабочего процесса, в то время как прогретая и выделенная емкость генерируют расходы, пока выделенные вычисления простаивают. На следующей диаграмме показан разговорный агент, использующий оба типа размещения: чат-сервис на прогретой емкости передает первый ответ в режиме реального времени, а остальная часть выполнения работает как надежный бессерверный рабочий процесс, который не несет вычислительных затрат во время ожидания.
При сравнении выполнения по требованию с прогретой и выделенной емкостью учитывайте продолжительность вычислений, переходы оркестрации, хранение состояния, передачу данных по сети и данные телеметрии. Вы можете не учитывать расходы на модели и инструменты, если они остаются неизменными при разных вариантах размещения, но включайте эти расходы, если повторные попытки, сбои или повторная работа приводят к тому, что при одном из вариантов размещения генерируется больше вызовов.
Вместо цен на вызовы сравнивайте стоимость одного успешного запуска. Складывайте затраты, создаваемые каждой попыткой выполнения в течение одного и того же рабочего окна, включая успешные, неудачные и прерванные запуски. Затем разделите общую сумму на количество запусков, которые достигли условия завершения рабочей нагрузки.
Например, допустим, исследовательский агент запускает 100 запусков в течение 1-дневного рабочего окна. 80 запусков приводят к созданию готового отчета, 15 завершаются с ошибкой после понесения затрат на вычисления и оркестрацию, а 5 прерываются в ожидании одобрения. В совокупности 100 запусков создают расходы, связанные с выполнением, в размере 12 долларов США. Поскольку только 80 запусков достигают определенного условия завершения, стоимость одного успешного запуска составляет 12 долларов США ÷ 80, или 0,15 доллара США. Деление той же стоимости на все 100 инициированных запусков дало бы 0,12 доллара США и скрыло бы стоимость безуспешной работы.
Если для выполнения целевого показателя времени отклика требуется, чтобы экземпляры оставались готовыми к работе, включите стоимость минимальной емкости. Платформа по-прежнему может масштабироваться автоматически выше этого базового уровня, но она не может сократить объем вычислений до нуля в периоды простоя. В результате развертывание сочетает в себе фиксированные базовые расходы и расходы, зависящие от использования. Мы рекомендуем пересмотреть сравнение, если устойчивая загрузка увеличится. Постоянно занятые вычисления снижают экономическое преимущество выделения ресурсов по требованию и могут сделать пул воркеров подходящего размера более экономичным.
Используйте производственные данные для изменения размещения рабочей нагрузки вашего AI-агента
После запуска в производство следите за поведением агента во время его выполнения в бессерверном рабочем процессе. Сравнивая производственные метрики с вашим профилем выполнения, вы можете определить, когда архитектуру следует изменить для устранения возникающих ограничений по задержке или времени выполнения.
Прежде чем менять размещение шага, подтвердите источник проблемы. Например, если трассировка показывает, что ненужные вызовы поиска (retrieval) или обращения к модели составляют большую часть задержки, сохранение воркера в прогретом состоянии не решит эту проблему с задержкой. Напротив, если запуск вычислений потребляет значительную часть бюджета времени отклика, прогретая емкость может помочь.
Если вы используете Datadog, APM и Agent Observability могут показать распределение задержки запуска агента в рамках одной трассировки. Следующая запись начинается с распределения задержки запуска агента на диаграмме flame graph в Datadog APM, а затем открывает один из вызовов модели в Agent Observability, чтобы показать полные входные и выходные данные вызова, включая вызовы инструментов, сделанные агентом.
APM показывает, сколько времени занимает каждый шаг выполнения агента. Agent Observability фиксирует полные входные и выходные данные каждой операции, выполняемой агентом, включая вызовы моделей, вызовы инструментов и поисковые запросы. Вы также можете просмотреть модель, использование токенов и предполагаемую стоимость каждого вызова модели.
Сопоставьте каждый операционный сигнал с реакцией на размещение
При анализе сигналов оценивайте запуск, активное время вычислений, постоянную параллельность и стоимость успешного запуска в комплексе. Интерпретируйте каждый сигнал в соответствии с целевым временем отклика рабочей нагрузки и соответствующими лимитами емкости или стоимости. Например, хотя задержка запуска в 500 миллисекунд может быть приемлемой для ночного анализа, она способна негативно повлиять на пользовательский опыт во время взаимодействия с клиентом. В следующей таблице перечислены распространенные рабочие сигналы, то, что каждый из них говорит о рабочей нагрузке, и возможные варианты корректировки ее размещения.
Перемещайте только те шаги, которые требуют иного размещения
Рабочие сигналы могут применяться к одному шагу, а не ко всему рабочему процессу. Если задержка запуска, постоянное использование вычислительных ресурсов или ограничение времени выполнения влияют на конкретный шаг, перенесите этот шаг на предварительно прогретую или выделенную емкость, сохранив при этом долговечную оркестрацию и периодические шаги бессерверными.
Например, диалоговый агент может использовать предварительно прогретую службу для потоковой передачи своего первоначального ответа и запускать долговечный бессерверный рабочий процесс для последующего поиска. Это позволяет решить проблему с путем, чувствительным к задержкам, не поддерживая вычислительные ресурсы в активном состоянии, пока более длительная работа ожидает модели, инструменты или ввод данных человеком. Продолжайте сравнивать производственные измерения с профилем выполнения по мере изменения трафика, цен провайдера и требований к рабочей нагрузке. Вы можете увеличить или уменьшить предварительно прогретую и выделенную емкость, когда эти измерения обосновывают иное размещение.
Основные выводы по залогам успеха ИИ-агентов на бессерверной архитектуре
Бессерверный подход — отличная отправная точка для рабочих нагрузок агентов, использующих вычисления периодически. Долговечное выполнение позволяет рабочим процессам сохранять прогресс во время пауз и высвобождать вычислительные ресурсы между шагами. Предварительно прогретая или выделенная емкость становится уместной, когда это оправдано измеренной задержкой, постоянной загрузкой или требованиями к времени выполнения.
Начните с одной типичной рабочей нагрузки агента и создайте ее профиль выполнения. Используйте этот профиль для оценки бессерверного размещения, а затем сравните поведение в продакшене и стоимость успешного запуска с альтернативами. Если ограничение затрагивает отдельный шаг, измените размещение только этого шага, оставив остальной рабочий процесс бессерверным.
Чтобы начать оценку развертывания, используйте Datadog Serverless Monitoring для мониторинга производительности выполнения и Agent Observability для исследования активности моделей и инструментов. Чтобы начать мониторинг систем и рабочих процессов, поддерживающих ваши ИИ-агенты,
