ИИ-агенты в продуктиве: решает не количество ускорителей, а архитектура вокруг них
Другая нагрузка, а не просто большая
Один из сценариев для ИИ-ассистента — это продвинутый поиск: сотрудник задает вопрос, модель отвечает, пускай даже по выделенной вертикали знаний. Запросы приходят нерегулярно, модель одна, аудитория ограничена, да и сценарий в итоге не соответствует критериям готовности (DoD — Definition of Done) и ожиданиям бизнеса. Агенты и сложные агентные системы устроены иначе. Они получают бизнес-задачу, планируют последовательность действий, ищут информацию в корпоративных документах, обращаются к учетным системам, передают контекст между шагами и доменами и при необходимости подключают другие модели, работая в связке с оркестратором ресурсов. Одно обращение пользователя превращается в цепочку из десятков вызовов.
При этом агент или агентную систему чаще всего проектируют с целью выполнить бизнес-задачу, не учитывая эффективность использования ресурсов. Причина простая: эти системы создают подразделения, у которых один из KPI — ROI процесса с применением ИИ, и из виду часто упускается совокупная стоимость владения (TCO) инфраструктуры, которая не сводится к расходам на закупку оборудования, электричество и сопровождение.
Переход от ассистентов к агентам меняет прежде всего профиль нагрузки. Вместо редких запросов появляется непрерывный многопользовательский инференс, одновременно работают модели разного класса, идет поиск по корпоративным данным, а права доступа нужно проверять на каждом шаге. Если коротко, агентный слой в пилоте и в продуктивной среде может отличаться, а энтропия в метриках эффективности и вероятности попасть в цель на масштабном prod-ландшафте оказывается в разы дороже намеченного объема инвестиций. Это делает внедрение ИИ абсолютно неэффективным.
Пилот этого не показывает даже при функциональном и нагрузочном тестировании. В нем обычно одна-две модели, небольшая группа пользователей, заранее подготовленные данные и инженеры, которые вручную поддерживают работу сервиса. Проблемы проявляются, когда аудитория вырастает до сотен и тысяч сотрудников, с агентным слоем или слоями начинают взаимодействовать другие подсистемы, а сценариев становится больше десятка. Сначала растут задержки, очереди и число реплик моделей, затем команды начинают конкурировать за ускорители, а каждое новое ИИ-решение обходится почти так же дорого, как первое.
Первый потолок: ускорители одновременно простаивают и перегружены
В типичной пилотной инсталляции каждое подразделение получает свой сервер, модель занимает ускоритель целиком, очередь задач ведется вручную. В результате средняя утилизация GPU в корпоративных инсталляциях без оркестрации составляет около 30%. При этом в пиковые часы те же ускорители становятся узким местом. Бизнес делает вывод, что нужно докупить оборудование, и, как следствие, сроки ИИ-проектов и инициатив сдвигаются.
Но главная задача не в том, чтобы купить ускорители, а в том, чтобы сделать их общим, безопасным и управляемым ресурсом. Для этого нужны очереди, квоты и приоритеты, возможность запускать изолированные задачи разных команд на одном GPU, разделение интерактивной и пакетной нагрузки, маршрутизация запросов на модели подходящего размера.
К примеру, в нашей Машине искусственного интеллекта Скала^р эту роль выполняет платформа управления ИИ-задачами Скала^р Спектр ИИ. Планировщик распределяет задачи во времени, позволяет делить ускоритель между командами и бронировать ресурсы. При таком подходе утилизация вырастает до 70–85%, а один ускоритель с планировщиком по объему выполненных задач заменяет полтора-два ускорителя без него. Это позволяет масштабировать инференс без линейного увеличения парка оборудования, а прогноз роста инфраструктуры и потребления ресурсов становится более точным, что, в свою очередь, влияет на экономику всей ИИ-стратегии.
Второй потолок: сеть и данные
У агента появляется внешний контекст: документы, векторные базы, хранилища, программные интерфейсы учетных систем и сервис-деска. Если сеть и системы хранения спроектированы по остаточному принципу, модель ждет данные, а пользователь видит рост времени ответа, хотя ускорителей формально достаточно. Или, что еще хуже, создаются необязательные новые реплики ресурсоемких LLM и инструментов, занимающие дорогостоящие мощности.
В ИИ-кластере важно не только само оборудование, но и то, как оно собрано, связано и по какой логике утилизируются его ресурсы. Каждый потерянный процент пропускной способности кластера может стоить миллионы рублей. В промышленном контуре сети интерконнекта, хранения, доступа пользователей и управления разделяют и резервируют, а топологию рассчитывают так, чтобы сетевые задержки занимали меньше процента от времени операции. Слой данных, куда входят интеграционная шина, векторный поиск и объектное хранилище, закладывают в архитектуру сразу, а не подключают после запуска.
Третий потолок: безопасность самого агента
Ассистент в худшем случае раскрывает избыточную информацию в ответе. Агент действует: читает данные, вызывает внешние системы, может изменять записи. Каждая интеграция означает новую границу доступа и новый риск. Среди угроз — промпт-инъекции, в том числе через загруженные документы, отравление базы знаний для RAG, утечка чувствительной информации и неограниченное потребление ресурсов модели.
У агента не должно быть общих широких прав. Доступ проверяется в контексте конкретного пользователя, действия и ресурса, каждое действие агента журналируется, для критичных операций нужна дополнительная авторизация или подтверждение человеком, а на случай нештатной ситуации предусмотрена «красная кнопка». Персональные данные и коммерческую тайну маскируют еще до передачи в модель, а запросы проходят фильтрацию на уровне шлюза. Нейтрализовать эти угрозы на уровне платформы проще, чем дорабатывать каждое приложение по отдельности.
Архитектурный выбор определяет предел роста
Решения, принятые на этапе пилота, сложнее всего исправить потом. Я бы выделил шесть элементов, которые стоит заложить сразу, даже если первая инсталляция небольшая:
- единый контур идентификации и разграничения доступа;
- стандартизированный доступ к моделям через API;
- сквозная наблюдаемость от запроса пользователя до вызова инструмента;
- ресурсная модель с квотами и приоритетами;
- масштабируемые сеть и хранилище;
- воспроизводимое развертывание и жизненный цикл моделей, включая практики внедрения и использования инструментов.
Собрать инфраструктуру из отдельных компонентов можно, если у компании сильная инженерная команда и есть время на интеграцию. Но основные затраты в промышленном агентном контуре связаны не с покупкой серверов, а с совместимостью HW→SW→AI, нагрузочным тестированием, настройкой политик безопасности и сопровождением. В программно-аппаратном комплексе эту работу берет на себя разработчик: стек проверен заранее, поддержка осуществляется через единое окно. Настройка под задачи заказчика все равно нужна, но она не повторяется при каждом запуске новой модели.
Как понять, что инфраструктура готова
Готовность к промышленной эксплуатации определяется не числом ускорителей, а тем, насколько измерима и управляема вся цепочка и насколько эффективной окажется инвестиция. Я советую отслеживать время ответа и долю запросов в рамках SLA, полезную утилизацию GPU и время ожидания в очереди, долю задач, которые агент выполнил без эскалации к человеку, скорость и актуальность поиска по корпоративным данным, полноту аудита действий агентов, срок подключения новой модели или сценария и стоимость одной выполненной задачи.
Пилотный проект отвечает на вопрос, полезен ли ИИ, а промышленная эксплуатация — можно ли доверить ему бизнес-процесс. И выигрывает здесь не тот, у кого больше GPU, а тот, кто получает больше успешно решенных бизнес-задач на каждый час работы ускорителя.
Опубликовано 25.09.2026
