«Фабрика искусственного интеллекта» — это не одна модель и не отдельный кластер Kubernetes, а общий пул графических процессоров GPU, который одновременно используют команды для разных задач: тонкой настройки, запуска инференса и оценки. В статье, опубликованной в блоге CNCF, отмечается, что настоящая корпоративная проблема заключается уже не только в обучении модели, а в предоставлении каждой команде безопасного и изолированного доступа к одному и тому же оборудованию при сохранении высокой загрузки GPU и измеримой стоимости.
Материал написал Hrittik Roy, CNCF Ambassador и Platform Advocate в vCluster. В статье представлено практическое описание построения такой среды поверх Kubernetes. Основная идея заключается в том, что Kubernetes предоставляет зрелую основу для контейнеров, RBAC, автоматического масштабирования и политик, однако для работы с ускорителями и изоляции арендаторов на одних и тех же узлах ему требуется дополнительная экосистема.
Узкое место — эффективность использования, а не только скорость инференса
GPU представляют собой крупнейшую статью капитальных затрат в инфраструктуре искусственного интеллекта, поэтому коэффициент загрузки становится экономически более важным показателем, чем достижение максимальной скорости в одном запуске. В статье рассматриваются две основные проблемы: модель распределения ресурсов и модель изоляции.
В традиционной модели device plugin рабочая нагрузка, например, запрашивает nvidia.com/gpu: 1 и резервирует целый GPU, даже если использует лишь десять процентов его ресурсов. Dynamic Resource Allocation, или DRA, ставший общедоступным в Kubernetes 1.34, позволяет планировщику работать с ускорителями как с устройствами, обладающими определёнными характеристиками, памятью и топологией. Однако он не разделяет GPU на доли автоматически: плотность размещения обеспечивается уровнем устройства, например HAMi — проектом на стадии Incubating в рамках CNCF, который устанавливает программные ограничения памяти и вычислений на уровне контейнера и поддерживает нескольких поставщиков ускорителей.
И наоборот, выделение отдельного оборудования каждой команде может обеспечить сильную изоляцию, но оставить значительную часть мощности неиспользованной. Поэтому в статье проводится различие между выделением целого GPU при строгих границах доверия и разделением GPU внутри одной зоны доверия для повышения плотности. NVIDIA MIG обеспечивает изоляцию памяти и отказов на аппаратном уровне, однако в статье отмечается, что его использование в качестве барьера между враждебными арендаторами всё ещё является предметом обсуждения; поэтому в условиях низкого доверия консервативным вариантом остаётся выделение целого GPU.
Уровни фабрики: от физического оборудования до рабочей нагрузки
Инфраструктура начинается с подготовки исходного оборудования. Узлы обнаруживаются, после чего проверяются GPU, состояние памяти ECC и идентификаторы сетевых карт; затем устанавливается образ операционной системы, включающий драйвер GPU, библиотеки CUDA и NCCL. Далее применяются соответствующие настройки BIOS, узлы проходят стресс-тесты и тесты NCCL для проверки того, что GPU соединены с полной пропускной способностью, а результат регистрируется в источнике истины, таком как NetBox. Этот процесс можно построить с помощью специализированного менеджера оборудования поставщика или открытых инструментов, таких как Metal3 вместе с Ironic или vMetal.
После распределения ресурсов такие инструменты, как KAI Scheduler и Volcano, выполняют групповое планирование с учётом топологии, а Kueue управляет очередями, допуском и квотами. На уровне рабочих нагрузок можно использовать vLLM для инференс-движков и KServe для предоставления стандартных конечных точек и автоматического масштабирования, а также NVIDIA Dynamo и llm-d для раздельного инференса в более крупных средах. Gateway API обеспечивает маршрутизацию, а LiteLLM добавляет шлюз, совместимый с интерфейсом OpenAI.
Платформа не ограничивается контейнерами. В статье объясняется, что среды обучения могут использовать Slurm через Slinky от SchedMD, который представляет службы Slurm как выделенные ресурсы и интегрирует их с GPU Operator и DRA. Кроме того, KubeVirt может запускать виртуальные машины как рабочие нагрузки Kubernetes, благодаря чему виртуальные машины и контейнеры управляются из одного пула с унифицированными правами и квотами.
Изоляция — это не просто пространства имён
В статье проблема изоляции разделяется на два уровня. На уровне управления модель tenant cluster предоставляет каждой команде виртуальный интерфейс Kubernetes, включающий сервер API, выделенные ресурсы, независимые правила допуска и RBAC, причём всё это запускается как рабочая нагрузка поверх одного базового кластера. Примером такого подхода служит vCluster, который позволяет использовать привычные инструменты, такие как kubectl, Helm и Argo CD, без проприетарных расширений.
Уровень данных требует изоляции сетей, хранилищ, квот и среды выполнения. Для CNI и политик можно использовать Cilium, а для высокоскоростного пути — Multus и SR-IOV; для передачи GPU-трафика между узлами применяются InfiniBand или RoCEv2. Также используются отдельные VPC через VXLAN и EVPN либо ключи разделения в InfiniBand, тогда как DPU-модули, такие как NVIDIA BlueField или AMD Pensando, переносят некоторые функции изоляции и шифрования с хост-процессора. В статье подчёркивается, что критерием настоящего облака является изоляция, обеспечиваемая аппаратно при необходимости, а не полагание только на пространства имён.
Что превращает пул ресурсов в облачный сервис?
Редакционный комментарий: Практическая ценность этого подхода заключается в переносе обсуждения с вопроса «какая модель быстрее?» на вопрос эксплуатации самой инфраструктуры. Платформа становится облачным сервисом не просто благодаря объединению GPU, а тогда, когда арендатор может создавать и удалять кластеры через API, Terraform или GitOps, а ресурсы описываются декларативно и управляются Flux или Argo CD с использованием идентификации OIDC и разрешений RBAC.
Сервису также необходимы понятные измерения и биллинг. В статье предлагается использовать данные DCGM для расчёта секунд GPU, а затем распределять их между арендаторами через OpenCost. Мониторинг и надёжность являются частью продукта, а не эксплуатационным дополнением: DCGM отслеживает деградацию, Node Problem Detector преобразует сигналы отказов в состояния узлов, а цикл обработки изолирует подозрительный узел и освобождает его до планирования новых рабочих нагрузок. Уровень безопасности включает такие инструменты, как Keycloak через OIDC, OpenBao вместе с External Secrets Operator, Kyverno или OPA для применения контролей, а также Falco и Trivy для безопасности среды выполнения и цепочки поставок.
Самым сложным испытанием остаётся переход от демонстрационного примера к широкомасштабной эксплуатации. Пример, в котором две команды запускают две модели на одном разделённом GPU, сам по себе не доказывает пригодность архитектуры при наличии сотен узлов и нескольких центров обработки данных. В статье упоминается роль инструментов валидации, таких как NVIDIA AI Cluster Runtime и программа Kubernetes AI Conformance, представленная вместе с выпуском 1.35, однако остаются открытыми эксплуатационные вопросы, касающиеся радиуса поражения, границ изоляции между арендаторами и выбора между пакетом NVIDIA DSX OS и сборкой уровней из открытых компонентов.
Итог заключается в том, что успех «фабрики искусственного интеллекта» зависит от сочетания плотности размещения, изоляции и биллинга с учётом топологии оборудования: расположения GPU относительно NVLink или NVSwitch, их подключения к сети InfiniBand или RoCE, а также положения GPU, NIC и CPU на узлах NUMA. Планирование рабочей нагрузки без учёта этих данных может замедлить операции коллективного обмена на самом медленном соединении, даже если на уровне программного обеспечения платформа выглядит исправной.