Создание облака для агентских сервисов (Agentic Service Cloud)

Источник: Mavenir•

Создание облака для агентских сервисов (Agentic Service Cloud)

Задача заключается вовсе не в создании очередного универсального облака. Наша цель — построить недостающий уровень управления (control plane), который сделает разнородные ИИ-ресурсы пригодными для использования в качестве доверенных агентских сервисов.

*Блог Джитина Бхандари (Jitin Bhandari), исполнительного вице-президента NeoCloud Platform and Forward Deployment Engineering в Mavenir

Семь возможностей, превращающих ИИ-инфраструктуру в доверенную платформу

С чего продолжился Документ 1

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

В этом документе ставится следующий вопрос: что именно необходимо построить?

Ответ заключается не в создании более совершенной модели. По прогнозам Gartner, к 2029 году по меньшей мере 70% организаций, использующих производственный агентский ИИ в инфраструктуре и операциях, столкнутся с серьезными инцидентами в области обслуживания, безопасности или затрат, частично связанными с недостаточным объемом средств контроля во время выполнения (runtime controls). Как отмечает Gartner, письменные политики физически не могут помешать агенту совершить разрушительную ошибку.

Задача заключается вовсе не в создании очередного универсального облака. Наша цель — построить недостающий уровень управления (control plane), который сделает разнородные ИИ-ресурсы пригодными для использования в качестве доверенных агентских сервисов.

Я называю это облаком для агентских сервисов (Agentic Service Cloud): специализированной платформой, которая объединяет открытую инфраструктуру и экосистемы моделей, сохраняя за собой ключевые элементы управления, за которые клиенты действительно готовы платить — обеспечение соответствия требованиям, многоарендность, подтверждающие данные (evidence) и экономику.

Почему концепция «full stack» не должна означать «создать абсолютно всё»

Нижние уровни стека быстро стандартизируются на основе открытых стандартов:

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

Рассматривая это с точки зрения провайдера CSP или NeoCloud, мы получаем следующий руководящий принцип — выборочное владение:

  • Заимствовать из открытого исходного кода: движки обслуживания (serving engines), планировщики, оркестрацию, агентские фреймворки, протоколы инструментов, средства оценки и детекторы защитных барьеров (guardrails).
  • Получать от партнеров: дата-центры, электроэнергию, ускорители, доступ к передовым моделям (frontier models), платежные системы, налоговые сервисы и главную бухгалтерскую книгу.
  • Контролировать самостоятельно: иерархию арендаторов, политики, доказательную базу (evidence), экономику полезного вывода и коммерческие взаимоотношения.

Облако для агентских сервисов интегрирует стандартизируемые компоненты и удерживает те точки контроля, которые определяют доверие и экономику.

Возможность 1: Абстракция гетерогенной инфраструктуры

Лишь немногие CSP или развивающиеся NeoClouds будут владеть всеми продаваемыми ими мощностями. Их парки оборудования будут сочетать в себе собственные, арендованные и предоставляемые партнерами ускорители от NVIDIA, AMD и кремниевые чипы, оптимизированные под инференс, которые размещаются на центральных, региональных и периферийных площадках.

Декодирование (Decode) — фаза генерации токен за токеном при инференсе — ограничено пропускной способностью памяти, и именно здесь конкурируют альтернативные архитектуры ускорителей. Платформа, которая ориентируется только на одно семейство ускорителей, делает рискованную ставку на наименее устоявшуюся часть стека. Следовательно, платформа должна:

  • Представлять собственные, арендованные и партнерские мощности в виде единого пула с возможностью планирования, причем источник ресурса фиксируется для учета затрат и вопросов суверенитета.
  • Различать анонсированные, законтрактованные, обеспеченные электроэнергией, принятые в эксплуатацию и приносящие доход мощности; их смешение является частой причиной коммерческих ошибок.
  • Размещать рабочие нагрузки с учетом задержки (latency), стоимости, юрисдикции и соответствия конкретному ускорителю, а не только на основе доступности.

Возможность 2: Инференс как управляемый сервис

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

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

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

Возможность 3: Управление средой выполнения агентов и инструментами

Долго работающий агент ведет себя как распределенная система с учетными данными. Первой проблемой является идентификация. По данным Cloud Security Alliance, нечеловеческие идентификационные данные в среднем превышают количество человеческих пользователей примерно в 45 раз, менее чем у каждой четвертой организации есть официальные политики создания или удаления ИИ-идентификаторов, а более 16% вообще не отслеживают новые ИИ-идентификаторы.

  • Уникальная идентичность для каждого агента с делегированными полномочиями с ограничением по времени.
  • Авторизация инструментов на уровне протокола, благодаря которой каждый вызов MCP или API модерируется, логируется и тарифицируется.
  • Средства контроля сеансов и памяти, определяющие, что агент может запоминать и в течение какого времени.
  • Ограниченная автономия: пороги уверенности, одобрение человеком важных действий, верификация и откат (rollback).

Возможность 4: Корпоративные знания и контекст

Агенты надежны ровно настолько, насколько надежен контекст, с которым они работают. Как отмечалось в Документе 1, операторы называют междоменную интеграцию, качество данных и информационные изоляты (дата-силосы) главными препятствиями на пути к автономии — это проблемы данных, а не моделей.

Простой векторный поиск часто испытывает трудности с вопросами, зависящими от иерархии, приоритетности и перекрестных ссылок. В одном из исследований федеральных нормативных актов США за 2026 год сообщалось о повышении точности на 70% при использовании поиска, дополненного графами знаний, по сравнению с RAG исключительно на основе векторов; результаты будут различаться в зависимости от домена, но структура и онтология имеют решающее значение.

  • Поиск, графы знаний и доменные онтологии, кодирующие организационный контекст.
  • Происхождение (lineage) от исходных данных до ответа, а также подтверждение происхождения (provenance) для каждой модели, адаптера и версии промпта.
  • Защита неявных корпоративных и национальных знаний, благодаря которой клиенты сохраняют право собственности на интеллектуальные продукты, созданные на основе их данных.

Возможность 5: Многоарендность корпоративного уровня

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

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

Возможность 6: Суверенитет как доказуемый факт

Концепция резидентности отвечает на вопрос «где». Суверенитет также отвечает на вопросы о том, кто может принудительно получить доступ, кто может администрировать систему, что покидает периметр и может ли клиент доказать это. Практическая модель охватывает домены контроля, включая данные, модели, ключи, операции, телеметрию, поддержку, программные обновления, юридическое лицо, цепочку поставок, непрерывность бизнеса, процедуру выхода (exit) и независимый аудит (assurance).

Регулирование превращает это в обязанность по ведению учета. Статья 12 Закона ЕС об искусственном интеллекте требует, чтобы системы ИИ высокого риска поддерживали автоматическое логирование событий в течение всего жизненного цикла; в соответствии с Цифровым омнибусом 2026 года обязательства для автономных систем высокого риска применяются с декабря 2027 года.

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

Возможность 7: Агентская экономика

Поскольку агентское потребление является более масштабным и неравномерным, коммерческий уровень становится системой управления, а не второстепенным инструментом выставления счетов.

  • Авторизация до начала использования. Резервирование бюджета перед запуском агента, повторная авторизация в процессе его работы и остановка по исчерпании бюджета. Системы онлайн-тарификации в телекоммуникациях контролируют потребление в реальном времени таким образом уже не один десяток лет; теперь те же принципы применимы и к токенам. Многие инструменты для биллинга ИИ создавались с расчетом на выставление счетов постфактум на основе измерений.
  • Учет токенов, рабочих процессов и результатов. Токены остаются базовой единицей, но покупатели все чаще хотят платить за решенные инциденты, завершенные транзакции или услуги с гарантированным уровнем обслуживания (SLA).
  • Сверка затрат и доходов. Затраты поставщика на собственные, партнерские и арендованные мощности сопоставляются с доходами в разере арендаторов, моделей и юрисдикций.
  • Многосторонние расчеты. Распределение доходов, разрешение споров и гарантии расчетов между моделями, агентами, API и поставщиками инфраструктуры.

Роль инженеров передового развертывания (FDE)

Платформа не превращается в готовый производственный результат сама по себе. Данные, опубликованные Business Insider, показывают, что количество вакансий для инженеров передового развертывания выросло примерно на 729% в годовом исчислении по состоянию на апрель 2026 года — это сигнал о том, что дефицитным ресурсом теперь является именно развертывание, а не модели. Для поставщиков коммуникационных услуг (CSP) и NeoCloud роль FDE должна заключаться в следующем:

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

Показателем эффективности работы является снижение уровня кастомизации для каждого нового клиента. Если каждое развертывание уникально, провайдер управляет консалтинговым агентством, а не платформой.

В операторских сетях сложнейшими задачами никогда не были отдельные компоненты. Трудность заключалась в одновременной поддержке множества арендаторов, вендоров и коммерческих отношений в рамках единой инфраструктуры в реальном времени и с предоставлением доказательств. Этот опыт работы в компании Mavenir формирует мое мнение о том, что ни один отдельный уровень не является непреодолимым барьером (moat): ценность заключается в интеграции этих семи возможностей в рамках единой границы доверия при соблюдении единой модели управления и коммерческой модели — то, что немногие клиенты могут легко воссоздать самостоятельно.

Примечание: Фреймворки, пороговые значения и сроки этапов в этой серии материалов являются рекомендациями автора, а не отраслевыми стандартами. Моделирование вендоров отмечено соответствующим образом.

Пять вопросов для проверки стратегии использования платформы

  • Какими из семи возможностей мы обладаем сегодня, а какие мы неявно передаем на аутсорсинг?
  • Можем ли мы присвоить каждому агенту идентификатор и остановить его во время выполнения?
  • Можем ли мы разместить регулируемого субарендатора на той же инфраструктуре, что и наши собственные рабочие нагрузки, без создания отдельной среды?
  • Можем ли мы предоставить доказательства суверенитета по первому требованию, а не только в ответ на аудит?
  • Можем ли мы авторизовать расходы до запуска агента и сопоставить затраты с доходами после его завершения?

Что дальше

Наличие платформы — это еще не все. Провайдеру по-прежнему необходимо решить, что продавать в первую очередь, кому, по какой цене, на чьих мощностях и через каких партнеров. Часть 3 — «От “железа” к агентским доходам» превращает платформу в бизнес.

Открытие рынка → Проектирование платформы → Коммерческая реализация

Какая из семи возможностей дается вашей организации сегодня труднее всего? Напишите мне, чтобы получить одностраничный контрольный список возможностей, который поможет оценить, что вам следует развивать самостоятельно, внедрять или получать от партнеров.

Ссылки

  • Gartner, Agentic AI Fails Where Governance Stops (сентябрь 2026 г.)
  • Анонсы проектов CNCF / llm-d (2026 г.); отчеты о стеке инференса на KubeCon EU 2026
  • Анонсы Linux Foundation Agentic AI Foundation; дорожная карта MCP 2026 г.
  • Пресс-релиз Nutanix, 7 апреля 2026 г.
  • Данные об использовании токенов OpenRouter (2026 г.)
  • Cloud Security Alliance: State of Non-Human Identity and AI Security (январь 2026 г.); The NHI Governance Vacuum (май 2026 г.)
  • Опрос TM Forum Autonomous Networks (2026 г.)
  • Chakraborty & Guha, Knowledge Graph RAG, arXiv:2604.14220 (2026 г.)
  • Закон ЕС об искусственном интеллекте, статья 12; Регламент (ЕС) 2026/1744 (Digital Omnibus) — подлежит юридической экспертизе
  • Данные Indeed через Business Insider (май 2026 г.)

О чём эта статья

Ещё в разделе «Телеком и сети»

Все →

Ещё от Mavenir