Телеком-операторы уже используют машинное обучение для предиктивного обслуживания, чат-ботов и обнаружения аномалий. Однако переход к автономным сетям уровня 4 (AN L4), где сети принимают решения на основе намерений и управляются с минимальным участием человека, упирается в архитектурную проблему: как построить безопасную и надежную AI-обвязку, которая соединяет вероятностные рассуждения ИИ с детерминированным телеком-исполнением операторского класса.
Подключение больших языковых моделей (LLM) напрямую к критическим функциям сети — серьезный операционный риск. Решение, сгенерированное ИИ, может быть неверным, противоречить политике, основываться на устаревших данных или быть опасным в непредвиденных условиях. Ошибочное изменение в production-ядре или сети радиодоступа (RAN) способно нарушить целевые показатели качества, дестабилизировать контур управления или затронуть зависимые функции.
Почему автономным сетям нужна AI-обвязка
Современный ИИ требует плотных кластеров ускорителей, высокопроизводительных сетей и специализированного управления памятью для KV-кэша. Размещение таких нагрузок на легаси-архитектурах телекома создает проблемы на нескольких уровнях:
- Фрагментация данных: телеметрия, потоки аварий и топология часто живут в разрозненных системах вендоров с разными схемами данных.
- Отсутствие операционной ткани для агентов: агентам нужны единая система идентификации, детальный RBAC и контроль политик.
- Инфраструктурные узкие места: инференс ИИ требует иных ресурсов и планирования, чем контейнерные сетевые функции (CNF): доступ к ускорителям, NUMA, PCIe, SR-IOV/RDMA должны сосуществовать с детерминированной задержкой и изоляцией телеком-нагрузок.
Стандарты и open-source инициативы (ETSI, TM Forum, O-RAN Alliance, Linux Foundation) разрабатывают отдельные части архитектуры. Чтобы свести их воедино, нужна открытая платформа, которая описывается четырьмя взаимодействующими плоскостями:
- Плоскость контекста: телеметрия, топология, инвентаризация, аварии, состояние сервисов, графы знаний.
- Плоскость рассуждений: модели ИИ и агенты, которые диагностируют, прогнозируют и интерпретируют намерения.
- Плоскость управления: идентификация, политики, валидация, оркестрация, механизмы замкнутого цикла.
- Плоскость исполнения: CNF, RAN, ядро, транспорт, облачная инфраструктура.
Ключевой принцип — разделение пути чтения (read path) для наблюдения и рассуждений и пути записи (write path) для управления и исполнения. ИИ может интерпретировать контекст и предлагать действия, но детерминированные механизмы политик и валидации решают, какие изменения реально дойдут до сети.
Облачный фундамент от Canonical
Canonical предлагает открытый стек для единой среды, где модели ИИ и сетевые функции сосуществуют на общей инфраструктуре:
- MAAS — автоматизация обнаружения bare-metal серверов, управления прошивками и provisioning для GPU-серверов и edge-платформ.
- Ubuntu и real-time ядра — поддержка аппаратного ускорения, низколатентных сетей (SR-IOV, DPDK) и конфиденциальных вычислений. Свежий релиз Ubuntu 26.04.1 LTS уже доступен для установки.
- Canonical Kubernetes и MicroCloud — оркестрация и облачная инфраструктура для распределенных edge-развертываний.
- Juju и charmed operators — инкапсуляция day-2 операционной логики и автоматизированных обновлений.
Тот же фундамент может размещать инференс: inference snaps позволяют упаковать vLLM и llama.cpp как повторяемые версионируемые рабочие нагрузки, а Juju обеспечивает их жизненный цикл.
Стандартизация агентов через MCP
Для перехода от правил к агентному ИИ нужен стандартизованный способ обнаружения и запроса сетевого контекста. Индустрия движется к протоколу MCP (model context protocol), которым управляет Linux Foundation в рамках Agentic AI Foundation (AAIF). MCP — это уровень совместимости, а не движок политик или сетевой контроллер.
MCP обеспечивает:
- Совместимость и получение контекста: агенты могут единообразно запрашивать телеметрию, состояние кластера и диагностику в гетерогенных системах.
- Композируемость: операторы могут быстро добавлять новые сетевые возможности через MCP-серверы.
- Безопасность: MCP стандартизует вызов инструментов и предоставляет фреймворк авторизации, но его нужно сочетать с существующими системами идентификации, RBAC и аудита.
Через MCP можно безопасно открыть агентам read-oriented инструменты наблюдения за кластером, не рискуя несанкционированными изменениями.
Безопасное исполнение: политики и GitOps как предохранители
Изменяющие состояние операции должны идти по отдельному контролируемому пути записи. Агент не должен иметь прямого доступа к live-элементам сети. Представимый рабочий процесс:
- Контекст и планирование (read path): агент собирает контекст через MCP, анализирует телеметрию (Prometheus/OpenTelemetry) и формулирует план (например, масштабирование UPF или перераспределение среза O-RAN).
- Оценка политики и рисков: движок политик проверяет, разрешено ли действие, учитывая идентичность агента, домен, критичность сервиса, время, состояние обслуживания, свежесть данных, ожидаемый радиус поражения и конкурентные изменения.
- Декларативный коммит (write path): агент выражает предложение как изменение конфигурации в Git-репозитории или через модель Juju.
- Валидация и цифровые двойники: CI/CD пайплайн проверяет изменение на цифровом двойнике сети или в pre-production среде.
- Контроль человека: если радиус поражения превышает порог, коммит автоматически отправляется на ревью оператору.
- Согласование и откат: декларативные контроллеры (FluxCD, charmed operators) приводят желаемое состояние в live-сеть.
- Замкнутый цикл: пост-деплойный мониторинг проверяет, что состояние сети остается в заданных границах, и при необходимости запускает откат.
Важно учитывать разные масштабы времени: LLM не должен находиться внутри миллисекундного контура управления RAN. Быстрые детерминированные контуры остаются в нативных контроллерах, а ИИ работает на более медленных масштабах для диагностики и планирования.
Безопасность и конфиденциальный ИИ
Традиционное шифрование недостаточно, когда данные расшифровываются в памяти во время инференса. Конфиденциальный ИИ использует аппаратные доверенные среды (AMD SEV-SNP, Intel TDX, NVIDIA Confidential GPUs) для защиты данных и весов моделей во время использования. Сервис удаленной аттестации проверяет криптографические измерения от прошивки хоста до runtime инференса перед выдачей ключей.
Canonical поддерживает конфиденциальный ИИ:
- Ubuntu 26.04 LTS — интегрированная поддержка AMD SEV-SNP и Intel TDX на хосте и в гостевой ОС.
- Ubuntu Core — неизменяемый транзакционный образ гостевой ОС со snaps, снижающий дрейф конфигурации.
Ускорение разработки с Canonical Workshop
Разработчикам нужен быстрый доступ к AI-рантаймам (Ollama, OpenCode, vLLM, llama.cpp) и SDK (CUDA, ROCm), но платформенные команды должны обеспечивать изоляцию. Canonical Workshop решает это противоречие: инженеры запускают песочные среды одной командой snap install workshop --classic.
Workshop-среды определяются YAML-спецификациями и работают в непривилегированных системных контейнерах LXD, что создает дополнительную границу изоляции для экспериментальных или склонных к галлюцинациям агентов. Модульные SDK запрашивают контролируемый доступ к GPU, host-разделам и SSH-агентам. Одна и та же спецификация переиспользуется на машинах разработчиков, в CI/CD и на тестовых стендах.
Что это значит для операторов
Уровень AN L4 — это не просто установка LLM на существующий стек. Требуется скоординированная open-source архитектура, объединяющая возможности кремния, облачную оркестрацию, конфиденциальное исполнение, стандартизованные интерфейсы агентов и детерминированные предохранители. Стек Canonical — от MAAS и Ubuntu Confidential VMs до Charmed MLOps и Workshop — дает операторам контроль над данными и инфраструктурой и повторяемый путь к операционализации ИИ в преддверии 6G. Интересно, что и в ядре Linux ИИ находит применение: Торвальдс с помощью ИИ исправил баг в драйвере Intel Xe за 18 перезагрузок, а Canonical финансирует PhD-проект по автоматическому переводу C в Rust для Ubuntu.
Частые вопросы
Что такое Autonomous Networks Level 4?
Это уровень автономности сети, при котором сеть принимает решения на основе намерений, выполняет прогнозное управление и замкнутый цикл с минимальным вмешательством человека. ИИ интерпретирует контекст и предлагает действия, но исполнение контролируется детерминированными механизмами.
Почему нельзя подключить LLM напрямую к сети?
Решение ИИ может быть неверным, устаревшим или опасным. Прямой доступ модели к критическим функциям создает риск нарушения целевых показателей, дестабилизации контуров управления и каскадных сбоев. Поэтому нужен раздельный путь чтения и записи.
Что такое MCP и зачем он нужен?
MCP (Model Context Protocol) — стандартизованный протокол для взаимодействия ИИ-агентов с данными и инструментами. Он позволяет агентам единообразно запрашивать телеметрию и диагностику в гетерогенных системах, избегая вендор-локов и фрагментации интеграций.
Как обеспечивается безопасность изменений, предложенных ИИ?
Изменения проходят через декларативный GitOps-пайплайн: оценку политик, валидацию на цифровом двойнике, контроль человека при большом радиусе поражения и автоматический откат при нарушении границ. Сам агент не имеет прямого доступа к live-сети.
Что такое конфиденциальный ИИ?
Это защита данных и моделей во время обработки с помощью аппаратных доверенных сред (AMD SEV-SNP, Intel TDX, NVIDIA Confidential GPUs). Удаленная аттестация проверяет целостность окружения перед выдачей ключей, что особенно важно для телекома с реальным абонентским трафиком.
Нужны ли отдельные инфраструктуры для ИИ и сетевых функций?
Не обязательно. Облачный фундамент Canonical позволяет размещать ИИ и CNF на общей инфраструктуре, но при необходимости выделять ускорители или изолировать ресурсы. Это снижает затраты на параллельные стеки.
Как ускорить разработку AI-агентов без риска для production?
Canonical Workshop запускает песочные среды в LXD-контейнерах с контролируемым доступом к GPU и другим ресурсам. Спецификации версионируются в Git и переиспользуются в CI/CD, что ускоряет путь от прототипа до production.
Источник: ubuntu.com