[Перевод] Ваша платформа Kubernetes готова к контейнерам. Готова ли она к ИИ?

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

Переход уже начался. По данным CNCF 2025 Annual Cloud Native Survey, 66% организаций, которые размещают генеративные ИИ-модели, используют Kubernetes для части или всех инференс-нагрузок. Однако ежедневно развёртывают ИИ-модели лишь 7% организаций. Этот разрыв показывает разницу между запуском ИИ-нагрузок в Kubernetes и платформой, которая готова непрерывно эксплуатировать ИИ в production.

Проблема заметна и внутри платформенных команд. Исследование 2025 State of AI in Platform Engineering2 показало, что 35% таких команд всё ещё не оркестрируют ИИ-нагрузки. Это говорит о разрыве между внедрением ИИ и зрелостью операционных платформ, необходимых для его масштабной поддержки.

ИИ не требует от платформенных команд отказываться от Cloud Native-практик. Kubernetes, GitOps, observability, автоматизация и самообслуживание по-прежнему составляют ценный фундамент. Однако ИИ предъявляет дополнительные требования к вычислительным ресурсам, планированию, доставке моделей и эксплуатации.

Команда VK Cloud перевела статью о том, что должно измениться, чтобы Kubernetes-платформа была готова к эксплуатации ИИ-нагрузок.

Расширьте модель ресурсов за пределы CPU и памяти

ИИ часто воспринимают как GPU-нагрузку, хотя production-конвейеры ИИ гораздо неоднороднее.

Подготовка и предобработка данных, retrieval, оркестрация и прикладная логика могут работать на CPU, тогда как для обучения и инференса нужны GPU или другие ускорители. Одна ИИ-нагрузка нередко зависит сразу от нескольких типов ресурсов.

Это меняет требования к планированию. Платформенным командам нужно учитывать тип и доступность ускорителей наряду с CPU, памятью, топологией и особенностями самой нагрузки.

Kubernetes развивается в этом направлении. Например, Dynamic Resource Allocation (DRA) позволяет нагрузкам гибче и декларативнее запрашивать специализированное оборудование.

Задача не сводится к тому, чтобы открыть приложениям доступ к GPU. Гетерогенные вычисления должны стать частью единой модели ресурсов Kubernetes.

Расширьте CI/CD на жизненный цикл модели

Команды Cloud Native сделали доставку приложений повторяемой с помощью CI/CD и GitOps. ИИ добавляет в этот процесс ещё один ключевой артефакт — модель.

Вместо привычного конвейера:

Код → сборка → тестирование → развёртывание

командам может потребоваться управлять более сложной цепочкой:

Код + модель + конфигурация → оценка → развёртывание → наблюдение → обновление

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

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

Наблюдайте за нагрузкой, а не только за кластером

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

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

• использование ускорителей и их памяти;

• время планирования и ожидания в очереди;

• задержку инференса;

• время загрузки модели;

• пропускную способность и состояние endpoint.

Не нужно создавать для ИИ отдельный стек мониторинга. Достаточно расширить существующую Cloud Native observability, чтобы в контексте одной нагрузки можно было сопоставить инфраструктурную, прикладную и специфичную для ИИ телеметрию.

Так проще ответить на вопрос, на который не отвечает одна лишь метрика использования GPU: где именно нагрузка проводит время в ожидании?

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

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

Попробовать

Дайте разработчикам ИИ эталонный путь

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

Платформенная команда может предоставить стандартизированный путь самообслуживания, в котором уже учтены типовые инфраструктурные и операционные решения:

Модель → ресурсы → развёртывание → endpoint → observability → политика

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

Это тот же принцип платформенной инженерии, который упростил доставку Cloud Native-приложений. Разница в том, что эталонный путь3 теперь должен учитывать модели и ускорители наряду с контейнерами, CPU и памятью.

Сделайте ИИ ещё одной production-нагрузкой

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

У Cloud Native-сообщества уже есть зрелые практики оркестрации, декларативной инфраструктуры, автоматизированной доставки, observability, политик и самообслуживания разработчиков. Их можно расширить для ИИ, не создавая отдельную операционную модель.

Kubernetes-платформа готова к ИИ, если команды могут единообразно развёртывать ИИ-нагрузки, наблюдать их end-to-end, выделять необходимые ресурсы и давать разработчикам единый путь от эксперимента к production.

Вопрос уже не в том, способен ли Kubernetes запускать ИИ. Важно, станет ли эксплуатация ИИ-нагрузок в Kubernetes такой же рутинной, как работа с любыми другими production-нагрузками.

Если эта публикация вас вдохновила и вы хотите поддержать автора — не стесняйтесь нажать на кнопку