Каждая эпоха DataRobot сопровождалась открытым кодом. Последние вклады DataRobot в open source прямо решают те проблемы, из-за которых агенты ломаются в продакшене.
Создать агента сейчас — дело пары часов. Выбираешь фреймворк, подключаешь модель и систему извлечения знаний, добавляешь несколько инструментов, и к обеду уже работает демо. Трудности начинаются после демонстрации. Оказывается, выбранный сценарий работы далеко не самый точный и не самый дешёвый. Агенту приходится принимать решения в условиях неопределённости, а быстрых инструментов для оценки рисков нет. Как только им начинают пользоваться несколько команд, счета за инференс и задержки идут вразнос.
Это проблемы не самих фреймворков, а всего жизненного цикла агентов. Они проявляются на трёх этапах: проектирование рабочего процесса, принятие решений в условиях неопределённости во время выполнения и обслуживание результатов для реальных пользователей в масштабе.
Всё это знакомая территория. Открытый код DataRobot никогда не был второстепенным занятием. Он шёл в ногу с эволюцией платформы: сначала обучение прогностическому ИИ на открытых примерах, затем передача программируемого контроля над AutoML в руки команд, а теперь — создание инфраструктуры ровно для тех точек, где агенты выходят в продакшен.
Десятилетие демонстрации своей работы
Привычка выкладывать код в открытый доступ появилась ещё в 2014 году, когда команда опубликовала свой код, занявший призовые места на соревновании KDD Cup, вместе с блог-туториалами по градиентному бустингу, scikit-learn и регрессии в statsmodels. Репозиторий учебных материалов для дата‑сайентистов, а позже и серия ускорителей для генеративного ИИ выросли из того же убеждения: единственный способ по‑настоящему понять ИИ — собрать его самому, поэтому лучше давать людям работающий код, а не очередную научную статью. Всё это опиралось на R и Python SDK, которые превращали пробный аккаунт из вещи, по которой можно только щёлкать мышкой, в инструмент для полноценного скриптования.
Обучение отвечает на вопрос «как этому научиться». Следующий вопрос — «как доверять тому, что построено», и ответом стала оркестрация. Провайдер Pulumi и сопутствующий CLI позволили описывать рабочие процессы как код и воспроизводить их на чужой машине с тем же результатом, превратив AutoML из чёрного ящика в экспортируемую, проверяемую запись. Blueprint Workshop, Python‑клиент для программного построения и редактирования «чертежей» модели, распространил ту же идею на уровень самого моделирования: предобработка, алгоритмы, постобработка — теперь это код, а не просто узлы в интерфейсе.
После оркестрации логичным шагом стало владение процессом. Пользовательские модели и задачи, построенные на открытом фреймворке DRUM, позволяли командам приносить заранее обученные модели и собственные шаги предобработки в развёртывание, автоматически получая мониторинг, контроль и таблицу лидеров. Компонуемый ML на основе пользовательских задач означал, что в одном пайплайне можно смешивать алгоритмы платформы с проприетарной предобработкой, не выбирая что‑то одно.
Связующая нить между той эпохой и нынешней — Pulumi. Тот же декларативный шаблон, который когда‑то документировал прогностический пайплайн, теперь разворачивает инфраструктуру для агентов: шаблоны агентов для CrewAI, LangGraph и LlamaIndex поставляются с уже настроенным Pulumi. Инструменты сменились, но стремление к открытости и отказу от «огороженных садов» осталось.
Жизненный цикл агента и где он ломается
Прежде чем называть инструменты, стоит обозначить этапы. Агент проходит предсказуемый путь. Сначала вы проектируете рабочий процесс — как он извлекает информацию, рассуждает и отвечает. Во время выполнения ему нужно достаточно хорошо осмыслить неопределённый мир, чтобы действовать. А платформа должна обслуживать этого агента для множества пользователей, не нарушая целевые показатели уровня обслуживания и не разоряя бюджет. Каждый этап сопровождается сложным вопросом: syftr и Token Pool отвечают на два из них как проекты с открытым кодом, JointFM — на третий как проприетарная технология исследовательской команды DataRobot, а четвёртый проект ещё находится на рассмотрении.
syftr: проектируй рабочий процесс, а не угадывай
Первое решение при создании любой RAG‑системы или агента — и его же чаще всего пропускают — выбор конфигурации. Какая синтезирующая LLM, какая модель эмбеддингов, какой ретривер, размер фрагментов, нужно ли добавлять переранжирование, должен ли процесс вообще быть агентным. Пространство вариантов насчитывает более 10²³ уникальных комбинаций, и каждый выбор означает компромисс между точностью, задержкой и стоимостью. Большинство команд выбирают разумный на вид вариант по умолчанию и никогда не узнают, насколько далеко он отстоит от оптимального.
syftr ищет в этом пространстве, а не гадает. Он применяет многокритериальную байесовскую оптимизацию для нахождения Парето‑оптимальных потоков — таких конфигураций, где точность нельзя улучшить, не заплатив больше, а стоимость нельзя снизить, не потеряв в точности. Специализированный механизм ранней остановки отсеивает заведомо неоптимальные варианты до того, как они израсходуют бюджет на оценку, сокращая вычислительные затраты на поиск на 60–80%. На стандартных отраслевых бенчмарках RAG он находит рабочие процессы, которые снижают затраты до 13 раз при минимальных потерях точности.
syftr не заменяет суждение человека. Он даёт надёжную отправную точку для проектирования.
JointFM: даём агенту встроенного аналитика для решений в реальном времени
Спроектированный рабочий процесс позволяет собрать агента, но не помогает ему принимать сложные решения во время работы. Перебалансировка портфеля, хеджирование цепочек поставок, диспетчеризация энергии в сети — это решения в условиях неопределённости, которые зависят от полного совместного распределения множества взаимосвязанных исходов, в том числе от того, как они ведут себя в хвостах распределений. Классические количественные методы хорошо это моделируют, но медленны и хрупки. Стандартные фундаментальные модели временных рядов быстры, но прогнозируют каждый ряд изолированно, упуская перекрёстные зависимости, определяющие системный риск.
JointFM, фундаментальная модель от исследовательской команды DataRobot, закрывает этот пробел. В отличие от syftr и Token Pool, JointFM — проприетарная технология, а не открытый проект: пока результаты описаны в ранней исследовательской статье, без раскрытия метода и кода. Модель предварительно обучена на потоке синтетических стохастических дифференциальных уравнений, а не подогнана под один набор данных, поэтому она усваивает физику стохастической динамики и предсказывает полное совместное распределение будущих исходов за один проход: 10 000 выборок для 10 целевых переменных и 63 горизонтов примерно за 10 миллисекунд на одном GPU, с сокращением потерь энергии на 21,1% по сравнению с сильнейшим классическим методом при оценке без дообучения.
Именно скорость делает модель актуальной для агентов. Когда агент, принимающий решения, может пересчитать будущее за миллисекунды, учёт рисков становится частью каждого его действия, а не ночной пакетной задачей, которую человек ждёт до утра. Первое применение в финансах показало доходность с поправкой на риск на уровне классического бенчмарка, заменив ночной процесс на работу в реальном времени. Модель по построению не привязана к конкретной предметной области, поэтому те же возможности распространяются на энергетику и логистику.
Token Pool: обслуживай всех пользователей, не ущемляя ключевых
Даже хорошо спроектированный агент с быстрыми рассуждениями в реальном времени должен где‑то работать, чаще всего бок о бок с другими. Мультитенантный инференс натыкается здесь на стену. Выделенные эндпоинты оставляют простаивающие мощности GPU на неактивных моделях. Ограничения по частоте запросов считают все токены одинаковыми, хотя один запрос может стоить в разы больше процессорного времени GPU, чем другой. Ни один из подходов не позволяет заимствовать свободную ёмкость, и оба ломаются под всплесками, характерными для реального трафика инференса. Знакомая картина: пакетная задача одной команды забивает эндпоинт, и задержки в продакшене взлетают у всех.
Token Pool решает эту проблему на уровне API‑шлюза, не трогая сам рантайм инференса. Он выражает ёмкость в естественных для инференса единицах — пропускная способность по токенам, размер KV‑кэша, конкурентность — а не в количестве машин или подов. Пользователи получают доли от общего пула, а классы обслуживания (dedicated, guaranteed, elastic, spot, preemptible) задают порядок защиты при конфликтах. Механизм справедливости на основе «долга» предоставляет временно ограниченным рабочим нагрузкам компенсирующий приоритет позже, так что ни один клиент не остаётся без ресурсов и ни один не захватывает пул. Он работает как Kubernetes-нативный слой поверх vLLM или TensorRT-LLM.
При нагрузочном тестировании Token Pool удерживал 99-й перцентиль времени до первого токена ниже 1,2 секунды для гарантированных нагрузок, выборочно ограничивая трафик класса spot, тогда как базовый вариант без контроля доступа деградировал до более чем 19 секунд для всех типов нагрузки. Для всех, кто отвечает за экономику потребления или управление API, это недостающий примитив: ёмкость, выраженная в единицах, соответствующих реальной стоимости инференса.
kubectl apply -f examples/sample-tokenpool.yaml
kubectl apply -f examples/sample-entitlement.yamlЧто дальше: замыкаем цикл
Сегодня три выпущенных проекта работают как разрозненные звенья. Поиск на этапе проектирования выполняется один раз. Рассуждения во время выполнения не учитывают состояние обслуживающего слоя. Слой обслуживания навязывает политики, не передавая обратную связь выше. Рабочий процесс, найденный syftr в прошлом квартале, необязательно оптимален для текущего трафика, моделей и цен.
Следующий проект с открытым кодом соединит производственную телеметрию — реальные сигналы о стоимости, задержках и качестве, поступающие от обслуживающего слоя, — с уровнем оптимизации, чтобы рабочие процессы переоценивались на основе реальных продакшен-данных, а не единственного офлайн-бенчмарка. Проект ещё на рассмотрении и пока не имеет названия, но это естественный четвёртый этап после проектирования, рассуждения и обслуживания.
С чего начать
- Сборка: установите syftr с помощью
pip install git+https://github.com/datarobot/syftr.gitи запустите стартовый поиск - Сборка: разверните Token Pool на локальном кластере Kind, GPU не требуется
- Чтение: ознакомьтесь с руководством по мгновенной оптимизации портфеля для JointFM
В следующей части серии выйдут практические руководства: запуск первого поиска syftr и интерпретация Парето-фронта, вызов JointFM для прогнозов в реальном времени внутри агента, настройка Token Pool для защиты рабочей нагрузки от шумных соседей. Начните с того этапа жизненного цикла, который сейчас болит сильнее всего.