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

Оригинал тут: https://unionailoop.substack.com/p/the-evolution-and-future-of-ai-orchestration
2 июля 2025 г. – Кетан Умаре — генеральный директор и соучредитель Union.ai. Ранее он занимал несколько руководящих должностей в Lyft, Oracle и Amazon, работая с облачными технологиями, распределенными системами хранения данных, картографией и системами машинного обучения.

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

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

Настоящим узким местом являются не модели или вычисления – это мы.

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

1. Зарождение оркестрации: ETL и микросервисы

2012 – ETL
Оркестрация впервые появилась для обеспечения ETL (извлечение, преобразование, загрузка), где планировщики, такие как Airflow, управляли приемом и преобразованием данных на больших хранилищах данных.

Диаграмма: Процесс ETL

• Извлечение:** Извлекает и проверяет данные из различных источников.
• Преобразование:** Обрабатывает и организует извлеченные данные, чтобы сделать их пригодными для использования.
• Загрузка:** Перемещает преобразованные данные в репозиторий данных.

2014 – Микросервисы
Поскольку использование постоянно растущих объемов данных стало более критичным для инноваций, возникла потребность в оркестрации микросервисов, где системы, такие как AWS Step Functions или Cadence, обеспечивали надежное выполнение вызовов сервисов и повторные попытки в транзакционных системах.

На ранних этапах оркестрация в основном сосредоточивалась на упорядочивании или определении, когда и как вызывать функцию, запускать скрипт или запускать контейнер. Трудоёмкие вычисления перекладывались на традиционные вычислительные движки, такие как Spark, AWS Batch, GCP Cloud Run или, позже, K8s. Оркестрация не касалась вычислений, и ей это было не нужно.

2. Машинное обучение: оркестрация встречается с вычислениями

2017 – ML-конвейеры
ML привнесло новые требования: дорогие вычисления и отказоустойчивость.

В отличие от микросервисов или пакетного ETL, рабочие процессы ML представляют собой долгосрочные процессы, тесно связанные с инфраструктурой. Графические процессоры, на которые сейчас в большей степени полагаются, особенно для нужд обучения ML, являются более дорогими, чем центральные процессоры. Обучение моделей, их оценка, настройка гиперпараметров — все это требует динамического распределения ресурсов GPU или CPU. А поскольку эти процессы занимают гораздо больше времени, отказоустойчивое восстановление после сбоев стало гораздо важнее.

Эти потребности породили оркестраторы ML-конвейеров, такие как Flyte, которые до сих пор являются открытыми решениями для оркестрации, на которые полагается большинство команд.

2021 – Управляемая оркестрация ML
По мере того как оркестрация ML становилась более сложной, она ложилась более тяжелым бременем на команды ML, данных и платформ, которым нужно было поддерживать инфраструктуру. Им нужны были системы оркестрации, которые определяли DAG (ориентированный ациклический граф), выделяли ресурсы, управляли жизненным циклом задач и чисто масштабировались до нуля.

Платформы оркестрации, такие как Union.ai, Prefect и Airflow, появились для снятия инфраструктурной нагрузки с оркестрации. С появлением эпохи ИИ они стали гораздо популярнее для команд, создающих рабочие процессы ИИ/ML, как критически важную часть своей работы.

3. Агентные системы: оркестрация в эпоху ИИ

2025 – ИИ и агентная оркестрация
Сейчас мы вступаем в новую фазу: оркестрацию интеллектуальных агентов и систем ИИ.

Агенты — это автономные, способные сохранять состояние программы (часто управляемые большими языковыми моделями), которые могут планировать, рассуждать и действовать. И оркестрация критически важна для их успеха в масштабе. Почему?

1. Они зависят от интеграций. Агенты часто полагаются на внешние инструменты (API, базы данных, модели), и эти взаимодействия должны управляться.
2. Они принимают динамические решения. Агенты часто уточняют результаты за несколько проходов, подобно настройке гиперпараметров или рекурсивному исключению признаков в ML.
3. Они делегируют. Один агент может вызывать другого, который может разветвляться на новые инструменты или рабочие процессы.
4. Они требуют вычислений. Рассмотрим агентов, которые решают парсить веб или выполнять код. Если мы думаем об агентах как о программистах, то быстро понимаем, что оркестрация без доступа к вычислениям ограничивает их автономию.

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

Это отражает идеи Anthropic: создание эффективных агентов означает управление инструментами, адаптацию стратегий и надежное оркестрирование долгосрочных фоновых задач. Оркестрация здесь — это не статический DAG. Это динамический цикл.

Будущая инфраструктура разработки ИИ

“По некоторым оценкам, более 80% проектов ИИ терпят неудачу – это вдвое превышает процент неудач проектов в области информационных технологий, которые не связаны с ИИ”. – RAND

По мере созревания ML и агентных систем в 2025 году и далее, команды, создающие их, обнаруживают, что общие потребности в разработке ИИ выходят на первый план. Это не гипотетические проблемы. Мы видели их вживую у реальных клиентов и в продуктах, которые они создают.

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

Заключение:

Слой инфраструктуры разработки ИИ

Мы вступаем в мир, где оркестрация — это не просто “что запускается дальше”, но “что думает дальше”.

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

Агенты и современные ML-системы требуют нового слоя в наших технологических стеках: инфраструктуры разработки ИИ.

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

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

Будущее оркестрации обеспечивает основу для слоя инфраструктуры разработки ИИ, будучи:

• Динамичной** – адаптирующей структуру рабочего процесса на основе условий выполнения.
• Эфемерной** – запускающей и останавливающей ресурсы по мере необходимости в рабочих процессах.
• Мультиагентной и мультичеловеческой** – оркеструющей сотрудничество между автономными системами и командами.
• Надежной и наблюдаемой** – обеспечивающей видимость и восстановление для систем, которые работают автономно.
• Безопасной** – управляющей доступом и выполнением в различных распределенных рабочих нагрузках.

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

Вопрос больше не “как запустить этот конвейер?”, а “как позволить системам решать, что запускать, когда запускать и как делать это надежно в масштабе?”