Kubernetes для LLM: когда нужен, а когда просто мешает

Каждый второй запрос на Private AI начинается с «развернуть LLM-кластер на Kubernetes». Через 15 минут разговора выясняется, что клиенту достаточно одного GPU-сервера с Docker Compose. Kubernetes — отличный инструмент, но он приносит накладные расходы, которые не всегда оправданы. Разбираемся, когда он реально нужен для LLM.

Что Kubernetes даёт для LLM

Плюсы хорошо известны:

• Автоскейлинг: поднимаем дополнительные реплики модели при росте нагрузки.
• Отказоустойчивость: упавший pod перезапускается автоматически.
• Multi-model hosting: одна платформа для десятков моделей и сервисов.
• Управление ресурсами: NVIDIA GPU Operator раздаёт видеокарты pod’ам по правилам.
• GitOps и CI/CD: единый подход к деплою через ArgoCD или Flux.

Для крупного AI-департамента с 10+ моделями и сотнями пользователей это реально полезно.

Что Kubernetes отбирает

Минусы обсуждают реже:

• Сложность: команда должна знать K8s, GPU Operator, сетевые CNI, storage. Одного DevOps мало — нужен нормальный SRE.
• Overhead: control plane, kubelet, мониторинг съедают 10–20% ресурсов ноды.
• Отладка сложнее: проблема может быть в CNI, scheduler, GPU-драйвере, vLLM — нужен опыт разбираться.
• Время на запуск: первый production-ready K8s-кластер с GPU — 2–4 недели. Docker Compose — день.

Если у вас 1 модель и 50 пользователей, это всё ненужная ноша.

Простой критерий выбора

Сформулировали правило на основе 15+ развёртываний:

Kubernetes оправдан, если выполняется хотя бы два условия:

1. Будет 3+ моделей на одном кластере (LLM, embeddings, reranker, vision, etc.).
2. Пиковая нагрузка кратно больше базовой (автоскейлинг реально используется).
3. Есть специалист, который отвечает за кластер.
4. Планируется мультитенантность (разные команды делят одни ресурсы).
5. Уже есть Kubernetes-инфраструктура в компании, куда можно встроиться.

Если ни один пункт не выполняется — берите Docker Compose или просто systemd. Через полгода всегда можно переехать.

Типовые архитектуры

Малый кластер (1–3 GPU, 1 модель)

Стек: Docker Compose + vLLM + Nginx + Prometheus.

Что даёт: простой запуск, минимальный overhead, понятная отладка. Подходит для 90% корпоративных ассистентов на стартовом этапе.

Сроки запуска: 3–5 дней.

Средний кластер (4–8 GPU, 2–4 модели)

Стек: Kubernetes + NVIDIA GPU Operator + vLLM/TGI + Ingress + Grafana + Loki.

Что даёт: автоскейлинг, multi-model, готовность к росту.

Сроки запуска: 2–3 недели для команды с опытом K8s.

Крупный кластер (10+ GPU, 5+ моделей, мультитенантность)

Стек: Kubernetes + Kubeflow/KServe + Istio + MLflow + ArgoCD + комплекс мониторинга.

Что даёт: полноценная MLOps-платформа, RBAC между командами, независимые релизы моделей.

Сроки запуска: 1–2 месяца + непрерывное развитие.

Частая ошибка: «сразу начнём с Kubernetes, чтобы потом не переделывать»

На бумаге это звучит разумно: лучше сразу правильно. На практике получается:

• 3–4 недели команда ковыряется с настройкой кластера, вместо того чтобы заниматься моделью.
• Бюджет разъедается на DevOps-работы, которые не дают бизнес-ценности.
• К моменту выхода в production половина команды устала, приоритеты сместились.
• По итогу проект откладывается, Kubernetes-кластер недогружен.

Лучший подход: на MVP поднимаем на Docker. Через 3–4 месяца работы в проде, когда появляется второе-третье использование — мигрируем на Kubernetes. К этому моменту понятно, какая нагрузка реально есть, и что именно автоскейлить.

Альтернативы, о которых забывают

Кроме Docker Compose и Kubernetes, есть несколько промежуточных вариантов:

• Nomad (HashiCorp): проще K8s, поддерживает GPU, хватает для 90% средних кластеров.
• Docker Swarm: простой кластер поверх Docker, хороший вариант для 2–4 нод.
• Ray: специально для ML-нагрузок, встроенная поддержка моделей и scheduling.
• Systemd + Ansible: иногда достаточно, если у вас один GPU-сервер и всё, что нужно — надёжный запуск.

Выбор зависит от уровня команды и стратегии. Никакого «K8s по умолчанию».

Короткий чек-лист

Перед тем как начинать с Kubernetes, ответьте на 5 вопросов:

1. Сколько моделей будет на кластере через 6 месяцев?
2. Какая разница между пиковой и базовой нагрузкой?
3. Кто в команде умеет администрировать K8s с GPU?
4. Есть ли уже Kubernetes в компании (не-AI сервисы)?
5. Сколько мы готовы потратить на overhead (в часах и деньгах)?

Если ответы — «1 модель», «не знаю», «пока никто», «нет», «не готовы» — вам не нужен Kubernetes. Нужен хороший Docker Compose.

Итог

Kubernetes — мощный инструмент, но для LLM он оправдан примерно в 40% случаев. Остальным достаточно одного GPU-сервера, Docker и мониторинга. Миграция на K8s «когда реально понадобится» проходит без драмы: контейнеры те же, манифесты переписываются за неделю.

Если вы сомневаетесь, какая архитектура подойдёт вашему проекту — на 30 минут разберём нагрузку и состав команды и дадим честную рекомендацию.