Kubernetes без границ: Managed Kubernetes как вычислительный центр для ИИ

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

Меня зовут Александр Прохоров. Я эксперт команды разработки Developer Productivity в VK Cloud. В статье расскажу, почему классическая инфраструктура тормозила развитие ИИ-проектов и какой подход к управлению вычислительными ресурсами стал ответом на эти вызовы.

Эволюция инфраструктуры

За последние десять лет инфраструктура для ИИ значительно преобразовалась:

• До 2019 года всё строилось на bare metal и виртуальных машинах. Соответственно, требовались выделенные GPU-серверы, ручная настройка драйверов CUDA, а также предполагалось статическое распределение ресурсов. Чтобы масштабироваться, нужно было закупать физическое оборудование — и от заявки до готовой среды проходили недели.

• С 2020 года пришли контейнеры и ранний Kubernetes. Появился GPU device plugin, NVIDIA GPU Operator, первые попытки оркестрации. Но scheduling всё ещё во многом настраивался руками, а отладка GPU-задач оставалась болезненной.

Но сегодня фактически начинается эпоха Cloud-Native AI, которая предполагает использование managed-кластеров с GPU из коробки, автомасштабирование GPU-нод, технологий разделения карт — MIG, vGPU, time-slicing, S3-CSI для огромных датасетов. По сути — Zero-Ops для ML-платформ. И переход к новому типу ИИ-инфраструктуры имеет конкретные предпосылки. О них чуть детальнее.

Нюансы традиционной ИИ-инфраструктуры 

Классический подход к GPU-инфраструктуре создавался в эпоху предсказуемых HPC-задач с фиксированными ресурсами. Но в условиях современных ИИ-нагрузок проявляются определенные недостатки привычной модели:

• Медленный Time-to-GPU. Использование традиционной инфраструктуры предполагает недели ожидания оборудования под каждый новый проект. Для ИИ, где скорость экспериментов критична, это убийственно.

• Расточительное использование GPU. Без возможности разделения ресурсов дорогие карты простаивают до 70% времени, что нерационально и не позволяет задействовать весь потенциал имеющегося оборудования. 

• Разрозненный стек инструментов. Обучение и инференс нередко соединяются хрупкими ручными интеграциями, что может оказаться критично и сказаться на точности работы нейросети.

То есть, используя традиционную инфраструктуру, можно столкнуться с риском переплаты в 3-5 раз из-за простоя оборудования. В итоге работать с ИИ становится неоправданно затратно. 

Но и это не всё. Ситуацию несколько усугубляет то, что ИИ-нагрузка принципиально другая.

• Потребление ресурсов нестабильно — пакетное обучение и всплески инференса вместо ровного предсказуемого трафика. 

• GPU нельзя намертво закреплять за одной машиной — это слишком дорого. 

• Скорость экспериментов требует, чтобы инфраструктура поднималась и гасла за минуты, а не за недели. 

• Существует жесткая конкуренция за ресурсы, поэтому нужно уметь делить мощность одной GPU между несколькими командами. Классическая модель «одна машина — один сервер» под это просто не заточена.

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

Новый стандарт для AI

По данным ежегодного исследования «CNCF Annual Cloud Native Survey The infrastructure of AI’s future» 66% организаций сегодня запускают ИИ-нагрузки на Kubernetes. Причем:

• 23% размещают в K8s все свои инференс-нагрузки;

• 43% — часть задач. 

То есть две трети рынка уже задействуют k8s при работе с нейросетями.

Примечательно, что другую позицию занимает заметное меньшинство: 

• 18% не используют Kubernetes для инференса и не планируют;

• 12% не используют K8s вовсе;

• лишь 4% выбрали другое решение. 

Таким образом можно констатировать, что тренд очевиден и однонаправлен.

Выбор в пользу Kubernetes во многом определяют три фундаментальные причины:

• Изоляция. Контейнер нативно изолирован, воспроизводим и переносим. Это идеальная среда для независимых ML-экспериментов: запустил, проверил, погасил.

• Требовательность к железу. Классические виртуальные машины медленные для тяжелых моделей. А Kubernetes позволяет поднимать bare-metal-ноды буквально по кнопке, с максимальной мощностью GPU и сети.

• Стандарт усиливает сам себя. Вся экосистема современных AI-инструментов — Kubeflow, KServe, Ray — создаётся сразу под Kubernetes. То есть, выбирая K8s, можно получить доступ ко всей этой экосистеме напрямую.

Более того, Kubernetes одновременно решает две задачи, в которые упёрся рынок: минимизирует простой оборудования и позволяет выкатываться за минуты. Так, k8s:

• дробит нагрузку мельче, чем виртуалки, а также эффективно делит и утилизирует GPU;

• позволяет запускаться и выкатываться за минуты, а не недели;

• гарантирует портируемость — манифест работает где угодно, воспроизводимо, без привязки к вендору.

Разворачивайте кластеры
с Managed Kubernetes

Автоматизируйте деплой
и снижайте затраты на инфраструктуру
до 60%

Попробовать

Варианты доступа к GPU

Одно из преимуществ работы с Kubernetes заключается в том, что с GPU можно взаимодействовать в разных слоях инфраструктуры в зависимости от задачи. Например:

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

• Kubernetes — GPU-ноды в кластере. Видеокарты как пул с автомасштабированием, оркестрация обучения и инференса в одном контуре. Оптимально, когда нужна оркестрация ML.

• Bare Metal — прямой доступ к железу. Физический сервер целиком, без виртуализации, вся мощность под тяжёлые задачи. Вариант для сценариев, где нужна максимальная производительность. 

Например, в случае Bare Metal физический воркер можно по запросу за минуты подключить через API, UI или Infrastructure-as-Code к managed-кластеру как обычная нода, а Control plane остаётся на стороне облачного вендора.

Причем создание, обновление и мониторинг остаются полностью managed — можно получить мощь голого железа, не теряя удобства облака.

Примечание: Выбор в пользу Bare Metal вместо виртуализации зачастую оправдан, поскольку для обучения больших моделей и работы с большим количеством данных каждый процент мощности на счету. И именно в случае bare metal воркер работает с железом напрямую. Нет оверхеда гипервизора, локальные NVMe-диски, 100% GPU и сети. В случае работы со сверхтяжелыми моделями это может заметно ускорить обучение. 

Барьеры перехода на Kubernetes 

Стоит признать, что Kubernetes пока остаётся слишком сложным.

Так, в уже упомянутом исследовании «CNCF Annual Cloud Native Survey The infrastructure of AI’s future» среди топ-трудностей 2025 года респонденты поставили на первое место даже не технологии, а инженерную культуру: для 47% главной проблемой стали изменения в работе команды. Наряду с этим — нехватка обучения, безопасность, CI/CD, мониторинг, сама сложность администрирования.

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

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

О Zero-Ops и эволюции управления

Zero-Ops — подход, при котором облако берёт на себя рутину Kubernetes и устраняет скрытые затраты на поддержку сложной инфраструктуры. Пользователь работает с приложениями и моделями, а не с внутренностями кластера. Причем Zero-Ops глобально меняет подходы к работе с K8s-инфраструктурой:

• Традиционный подход подразумевает ручное обновление каждого кластера, реактивную работу с инцидентами и ручной разбор аварий, создание тикетов во внутренний ИТ на каждое изменение, ручную сборку мониторинга под каждую команду. И с учетом подобного объема задач один инженер способен обслуживать всего 3-5 кластеров.

• Zero-Ops базируется на переходе к более продвинутым практикам: автоматические rolling-updates и self-update, self-healing без участия человека, self-service через API, UI и IaC, встроенная наблюдаемость и политики безопасности на все кластеры сразу. Благодаря этому один инженер может обслуживать пятьдесят и более кластеров, то есть эффективность команды растет в десять раз.

При этом, безусловно, каждая компания реализует Zero-Ops по-своему. Например, в VK Cloud Zero-Ops строится на четырёх принципах:

• Self-Healing — автовосстановление нод и control plane без инженера; 

• Self-Service — создание кластеров через UI, API и IaC без тикетов и ожидания;

• Policy-as-Code — автоматические политики безопасности;

• встроенная наблюдаемость — Prometheus и Grafana из коробки, без ручной настройки. 

Дополнительно VK Cloud продвигает и другие лучшие практики, среди которых:

• GPU-as-a-Service — карта доступна за минуты, а не недели. Этот ресурс должен быть легко доступен так же, как RAM и CPU для команды, с MIG, vGPU и time-slicing по запросу. 

• Унифицированная инфраструктура — единый контур train / serve / data, S3-CSI для петабайтных датасетов, встроенный ML-стек из аддонов.

Так, сегодня уже работают GPU-ноды, GPU Operator, MIG, S3-CSI, pay-as-you-go, мульти-GPU. В ближайших планах — DRA, vGPU, bare-metal GPU. На горизонте — мульти-кластерная GPU-федерация, serverless-инференс и AutoML.

Что в итоге

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

И практика показывает, что Kubernetes является вполне эффективной альтернативой классической ИИ-инфраструктуре: дробит нагрузку, делит карты между командами и объединяет обучение с инференсом в один управляемый контур.

Особенно заметен выигрыш, когда работа с Kubernetes ведётся в облаке, где команда может сосредоточиться непосредственно на моделях, данных и бизнес-гипотезах, делегируя рутину эксплуатации вендору. Например, такие условия получают пользователи при работе с Managed Kubernetes от VK Cloud. Причем в облаке можно выстроить сразу всю инфраструктуру под ИИ, используя также Object Storage для хранения сырых данных и датасетов, VK Data Platform для аналитики и ML и VK AI Space для создания и запуска мультиагентных ИИ‑систем.