Сегодня на Yandex Neuro Scale 2025 наша ML‑команда представила обновлённую AI Studio — платформу с большим набором инструментов для разработки ИИ‑агентов в единой end‑to‑end‑среде. Среди новинок — визуальный конструктор агентов, поддержка популярных API и реализация протокола MСP, механизмы AI search.
Агентские платформы уже какое‑то время находятся на пике популярности. Поэтому с одной стороны нашей задачей было учесть уже сформированные лидерами отрасли лучшие практики. А с другой — обобщить собственный опыт разработки и внедрения агентов, использующих большие языковые модели, и избавить разработчиков от проблем при инференсе.
Вместе с коллегами из команды разработки Анастасией Каримовой и Дмитрием Рыбалко покажем, как это устроено под капотом:
какие особенности эксплуатации нам нужно было учесть, чтобы найти баланс между производительностью и качеством;
как мы сталкивались с особенностями опенсорс‑инструментов для ML и учились справляться с этим разными способами;
как мы упростили создание голосовых агентов и заодно уменьшили latency запросов.
Какие бывают сложности при разработке ИИ-агентов
За последний год многие большие модели стали ещё доступнее — немало из них было выложено в опенсорс, при этом сравнение открытых моделей с проприетарными на стандартных бенчмарках показывает всё меньший разрыв по качеству.
Тем не менее, это по‑прежнему не позволяет «просто взять и скачать модель с Hugging Face, поднять её на виртуалке и сделать своего агента». На практике возникает много барьеров: для машинного обучения продакшн‑уровня нужна инфраструктура, а также большая исследовательская работа, чтобы достичь нужных метрик.
Именно поэтому возникает потребность в агентских платформах — а уже существующие платформы продолжают развиваться в ответ на новые запросы пользователей. Так, даже в рамках одной модели у разных провайдеров будет разное качество инференса модели:
Почему возникает эта разница? Вот лишь несколько проблем, с которыми сталкивались и мы сами как разработчики, и наши пользователи.
Нет выработанного стандарта с точки зрения инференса. Большое количество моделей, которые уже существуют на рынке, доступны в разных вариантах поставки. В индустрии есть несколько популярных публичных API: например, Anthropic API, OpenAI API — и многие опенсорс‑модели предоставляют режим совместимости с ними. В Yandex Cloud нас тоже очень просили предоставить возможности развернуть модели не только со своим нативным форматом, но и в режиме совместимости c OpenAI API. Мы добавили режим совместимости, но столкнулись с тем, что условия поддержки API регулярно меняются.
Изначально у нас на платформе был наш gRPC API и в дополнение к этому мы поддержали Chat Completions API от OpenAI с инструментами для генерации текста. Он не сохранял стейт, то есть был Stateless.
А между тем OpenAI пошли дальше и вслед за этим реализовали ещё два API:
Realtime API, для построения голосовых агентов, которые на вход получают аудио и синтезируют ответ.
Responses API — как для построения агентов, так и просто для чата с моделью.
Responses API — уже Stateful, что сильно отличается от прошлой реализации. Раньше пользователь создавал тред, получал его идентификатор, и все его сообщения были привязаны к одному треду, в рамках одного потока сообщений. С новым API у пользователя есть несколько способов управлять стейтом диалога: через Conversation API, который пока что поддерживается не везде, или с использованием древовидной структуры через previous_response_id.
Соответственно, у разработчика агентов появилась необходимость где‑то хранить это дерево, и если оно разветвлённое, это может добавить сложности.
Там, где стандарт уже наметился, он может быстро устареть. Один из немногих стандартов, описанных в мире ИИ, — это протокол MCP, Model Context Protocol, который регламентирует взаимодействие между LLM и внешними инструментами и источниками данных. При реализации Responses API это позволяет задать логику, когда бэкенд вызывает необходимые инструменты вместо пользователя — а ему самому уже не нужно писать код, чтобы обработать вызов.
Какие тут могут быть дополнительные задачи:
на бэкенде нужно хранить стейт этого вызова;
нужно реализовать механизм ожидания для тех операций, которые могут выполняться в фоне (например, если мы хотим проводить Deep Research, который может выполняться часы и дни).
Звучит не так сложно, но на практике с этим связано много тонкостей реализации.
Наш коллега Владислав Носивской уже рассказывал на JPoint, как в этой части у нас использовались очереди через Redis, и почему для этого также потребовалась связка с другими инструментами.
Для подобных задач мы всегда тестируем разные варианты, например, также пробовали использовать Temporal — но он не подошёл нам именно в контексте realtime‑задач.
Вдобавок к этому множество инструментов сейчас всё ещё работают со старой версией протокола MCP. В обозримом будущем планируется переход на новую — и с этим могут возникнуть новые интересные задачи.
Не всегда можно без проблем развернуть модели с помощью опенсорс‑инструментов. Для запуска моделей есть множество движков инференса:
vLLM
SGLang
Ollama
Triton
У каждого из них есть свои особенности. Как правило, когда выходит новая модель, опенсорс‑комьюнити добавляет её поддержку в движок.
Наиболее популярен vLLM, в нём достаточно быстро появляется поддержка новых моделей, но они могут работать не полностью. Например, когда не так давно OpenAI выложила в опенсорс две своих модели, под это появилась отдельная версия vLLM, но при запуске в Chat Completions API не работал вызов тулов. Исправить это можно с помощью различных парсеров, но в случае vLLM и gpt‑oss парсеров не было, и это было проблемой. Даже если парсеры есть, часто их поиск где‑то в комментариях на GitHub превращается в детективную историю.
Какие‑то баги в опенсорсе со временем исправляются, но не так быстро, как хотелось бы:
Например, сейчас в vLLM есть баг c поддержкой Qwen: во время вызова тулов в стримовом режиме через OpenAI часть аргументов могут просто пропасть. Issue висит уже пару месяцев, есть около пяти пул‑реквестов с решениями, но ни один из них пока не доделан.
Оценка моделей зависит от множества параметров. Чтобы выбрать подходящую модель для создания агента, разработчику как правило хочется покрутить разные варианты и сравнить показатели на примере своей задачи. Для этого применяются разные бенчмарки — их достаточно много в опенсорсе, у нас в Яндексе также есть свои.
Но у отдельного разработчика агентов не всегда есть понимание, какие параметры крутить, и как они будут отличаться в зависимости от движка и самого бенчмарка.
Когда мы разворачивали в облаке YandexGPT 5.1 и прогоняли на этой модели все приёмочные испытания, то увидели интересную ситуацию с тестом BFCL — это инструмент для оценки того, как модель вызывает функции.
Наши коллеги из ML‑команды отдали нам модель с результатами по BFCL около 70%. Мы развернули её у себя, запустили тот же самый тест и получили 60%. Только через три дня дебага кода и тестов нам стало понятно, в чём проблема: публичное имя, присвоенное модели, работало у нас как URI, то есть имело вид gpt://name. А вызов функции в тесте работал так: бралось имя модели, имя теста, из этого собиралась строчка и вызывалась через питоновский eval (что само по себе не совсем продакшн‑подход). Но из‑за двоеточия в названии нашей модели тест падал — чтобы исправить это быстро, пришлось сделать свой форк BFCL.
Отдельная боль — это хостинг моделей. Разные модели могут отличаться по типам квантования. У каждой модели есть веса, эти веса в каком‑то формате, и под разные типы видеокарт есть разные возможности квантования, перекомпиляции этих весов.
Для нас уже давно хорошим тоном стала квантизация моделей — процесс преобразования значений из представления с большим объёмом информации (обычно непрерывного множества) в более компактное представление, обычно из дискретного множества. Квантизация помогает сократить объёмы потребляемых ресурсов, например памяти, и одновременно повысить скорость инференса.
Наши коллеги уже много рассказывали про это, например, в статьях про квантизацию и ускорение инференса.
Важно уметь выбирать тип квантования весов, исходя как из точности мо��ели, так и из бизнес‑потребностей. За уменьшение потребления памяти мы часто платим точностью, и нужно уметь оценивать насколько эти потери приемлемы. Для опенсорсных моделей в перекомпиляции весов часто нет необходимости, обычно хватает готовых. Но иногда нужно поквантовать руками и подобрать подходящую технологию: есть варианты, которые просто сжимают веса, а есть технологии, которые пытаются делать это умно, сжимая только те веса, которые меньше всего используются.
Есть ещё одна проблема, которая станет актуальнее в перспективе: очень большие модели могут не поместиться на один хост.
У DeepSeek R1 уже 671B параметров — это 1342 Гб видеопамяти только на веса. А ещё нужна память под kv‑cache и активации.
Сейчас готовятся модели с ещё большим числом параметров. Например, Qwen3 Max, уже с триллионом параметров. Новый DeepSeek (в разработке) — тоже будет огромным.
По текущей статистике, наши пользователи чаще обращаются к моделям поменьше, но уже сейчас проблемы хостинга виднеются на горизонте. А значит для развёртывания будет необходима мультихостовая архитектура с возможностью доставки токенов на несколько машин и с распределённым KV‑кешем.
Единый подход для решения этой проблемы индустрией пока ещё тоже не выработан, есть варианты, например Prefill‑Decode Disaggregation: суть подхода в том, что чтение промта (Prefill) и генерация новой части (Decode) создают разные по профилю нагрузки на GPU.
А при работе с голосовыми агентами становятся особенно критичны задержки. До сих пор мы говорили про сложности при работе с разными моделями, однако в примерах чаще обращались к текстовым моделям. Но если мы проектируем голосового агента, появляются новые требования с точки зрения пользовательского опыта: разговор с голосовым помощником в идеале должен быть в режиме реального времени, без длинных пауз, как будто мы общаемся с человеком. А на задержки влияют и параметры сети, и архитектура решения, и используемые API.
Вот пример, с чем мы столкнулись при попытке реализовать агента через связку ASR + Responses API + TTS, если ничего не оптимизировать и дожидаться полной генерации:
В нашем случае это решилось за счёт оптимизаций уже на уровне платформы. Но если собирать пайплайн самому, такие длинные паузы вполне возможны.
Итого, что бывает важно учитывать при инференсе:
форматы парсеров тулов;
особенности работы и баги опенсорсных инструментов;
типы API, которые поддерживают эти инструменты;
типы квантования моделей;
типы видеокарт в наличии;
производительность;
а ещё отказоустойчивость и мониторинги.
Все эти факторы приводят к тому, что продакшн‑деплой моделей превращается в достаточно нетривиальную исследовательскую задачу — и у небольшой команды разработки агента для её решения не всегда есть достаточно времени и возможностей.
Как это решается в нашей платформе
К выходу обновлённой AI Studio мы хотели избавиться от барьеров, которые ограничивают разработку ИИ‑агентов для команд: от нехватки вычислительных ресурсов до ограничений в проведении экспериментов.
Получилось вот такое идеальное видение агентской платформы, которое мы запланировали реализовать.
Что здесь самое интересное из уже реализованного.
Единая Model Gallery для тестирования разных моделей. Нижний логический слой AI Studio — это модели, которые решают разные задачи. Если среди всего многообразия не получилось найти подходящей — можно дообучить, протестировать и подобрать подходящую конфигурацию.
С точки зрения пользовательского опыта, удобнее видеть всю информацию о доступных моделях в одном месте. Поэтому мы собрали их на единую витрину, включая опенсорсные модели, собственные модели Яндекса и дообученные модели, в том числе модели классификации, эмбеддингов и реранкинга.
При необходимости модели предварительно квантизируются, а у пользователя есть организационная и инфраструктурная поддержка для оптимизации деплоя. Поскольку инференс моделей регулярно преподносит что‑то новенькое — то для быстрого решения возникающих проблем у нас есть выделенная команда.
Поддержка Responses API. Существующая в опенсорсе поддержка Responses API, например, в том же vLLM, имеет свои ограничения: например, пока там в экспериментальном режиме поддерживается сохранение стейта в памяти, но это не готовое решение. Текущие опенсорсные решения подходят для совсем небольших и локальных сценариев использования, а для продакшн‑решений уже малопригодны. Для полной поддержки совместимости нужны ресурсы большой команды, недоступные отдельным разработчикам.
Вот что мы сделали для полной поддержки:
Поддержали стейты, авторизацию, долгоживущие сессии.
Поддержали синхронный, асинхронный и потоковый режимы.
Реализовали MCP Tool Calling в Responses API.
Поддержка Realtime API. Для обновлённой платформы мы поставили цель: при работе с голосовым интерфейсом от окончания фразы пользователя до начала ответа у нас должно быть точно меньше секунды. Как уже показано в первой части, связка TTS с Responses API, совсем не соответствовала целевой метрике.
Сначала мы попробовали решить задачу за счёт Streaming TTS, но и в этом случае показатель явно можно было улучшить:
Realtime API стал более подходящим решением, которое укладывается в целевую метрику:
На старте мы поддерживаем WebSockets‑версию, а на будущее также думаем о поддержке WebRTC.
Для максимальной живости голосовых агентов мы запустили также и стриминговый синтез. Он нативно встроен в Realtime API, но также может использоваться отдельно в сервисе SpeechKit. Благодаря поддержке стриминга, реплики для синтеза можно досылать по мере их появления (генерации моделью) и озвучивать максимально естественно в рамках одной сессии.
AI search. Инструменты веб‑поиска позволяют агентам при генерации ответа на запрос находить в интернете публичные документы с актуальными сведениями по теме запроса, и обобщать найденную информацию. Можно искать документы как на заданных сайтах, так и без ограничений по адресам.
В обновлённой платформе для поиска также появилась связка с новым API, совместимым с OpenAI — Vector Store API. Одновременно с этим мы добавили ещё несколько возможностей:
гибкое управление базой знаний: добавление и удаление файлов без перестроения индекса;
фильтрация по метаданным;
загрузка заранее подготовленных чанков;
использование только поиска без дальнейшей генерации.
Поддержка протокола MCP. В MCP Hub мы даём возможность как подключить внешний MCP‑сервер, так и создать свой MCP, который будет принимать запросы и распределять их между сервисами. Также можно трансформировать в MCP‑сервер любой API:
В случае с Responses API схема работы с MCP может выглядеть так:
В ближайшее время мы также учтём изменение стандартов и добавим поддержку MCP для Realtime API.
Демо: как это работает
Внутри AI Studio создадим на основе последней модели YandexGPT простого агента для службы комплаенса, который будет проверять контрагентов на благонадёжность:
Добавим инструменты RAG: загрузим в базу документы финансовой отчётности, которые необходимо использовать для поиска информации при проверке.
Дополнительно подключим поиск по материалам в интернете, чтобы найти сведения о важных публичных фактах о проверяемых компаниях.
Создадим MCP‑сервер для безопасного доступа к данным о компаниях из сервиса Контур.Фокус с помощью преднастроенного шаблона, протестируем работу агента и подключим дополнительные инструменты.
Готово! Другие сервисы также могут добавить свой API в MCP Hub — так что в ближайшее время таких шаблонов станет больше.
Помимо новых инструментов мы также предусмотрели возможности для плавной миграции. Не обязательно отказываться от прежних наработок, текущие решения по-прежнему можно вызывать через Function Calling.
Надеемся, всё это обеспечит большую гибкость разработки, где low-code-инструменты используются для быстрой проверки гипотез, а поддержка новых API, протоколов и возможностей поиска поможет лучше управлять качеством работы агентов.