Kubernetes для моделей: GPU-ноды, autoscaling, Helm

Как GPU попадает в кластер

Сам по себе Kubernetes про GPU не знает. На узел ставят драйвер и device plugin (модуль, который объявляет устройство) от NVIDIA. После этого узел сообщает кластеру ресурс nvidia.com/gpu, и pod может его попросить. Правила из документации kubernetes.io (08.10.2026): GPU указывают в limits; если и в requests, значения должны совпадать. GPU выдаётся целыми устройствами, дробно его не попросить.

NVIDIA GPU Operator ставит весь набор разом: драйвер, container toolkit, device plugin, метки узлов по типу GPU и мониторинг DCGM (счётчики GPU). Метки нужны, чтобы различать карты: accelerator=l40s и accelerator=t4 — разные узлы для разных моделей.

Делить одну карту можно двумя способами. MIG (Multi-Instance GPU) режет карту на изолированные части со своей памятью, это умеют только дата-центровые карты вроде A100 и H100. Time-slicing (разделение по времени) объявляет одну карту, например, как четыре ресурса, но документация NVIDIA прямо пишет: «there is no memory or fault-isolation between replicas». Годится для dev, не для двух клиентов на одной карте.

Только модели на GPU-узлах: taint плюс affinity

GPU-узел дорогой, и на нём не должен поселиться сборщик журналов. Обратно: сервер модели не должен уехать на CPU-узел. Нужны два механизма вместе.

• Taint (метка-отталкиватель) на GPU-пуле: nvidia.com/gpu=present:NoSchedule. Pods без разрешения туда не попадут.
• Toleration (разрешение) плюс node affinity (притяжение к узлам с меткой) у сервера модели.

Документация формулирует ловушку так: «Tolerations allow scheduling but don't guarantee scheduling». Toleration только разрешает pod попасть на узел, но не тянет его туда. Без affinity сервер модели может оказаться на CPU-узле и не запуститься. Фраза для интервью: «taint repels everyone else, toleration plus affinity puts the model there».

Холодный старт: посчитай, из чего он состоит

Новая копия модели на новом узле проходит четыре этапа. Скорости ниже — допущения для примера, их надо мерить на своей платформе.

Итого 4–6 минут до readiness. Что с этим делают: веса не в image и версионируются отдельно; cache весов рядом с узлом; заранее скачанные образы; тёплый минимум копий в рабочие часы; масштабирование по расписанию перед предсказуемым пиком (утро, день зарплаты). И startup probe с бюджетом больше худшего случая (урок a7-1).

Autoscaling: почему не CPU

HPA (Horizontal Pod Autoscaler) меняет число копий по метрике. Формула из документации: desiredReplicas = ceil(currentReplicas × currentMetricValue / desiredMetricValue). Цикл — раз в 15 с, отклонения в пределах 10 % игнорируются, уменьшение копий сглаживается окном 300 с, увеличение — без окна. Пример: 4 копии, в очереди в среднем 30 запросов на pod, цель 10 → ceil(4 × 30 / 10) = 12 копий.

Почему не CPU. Сервер модели упирается в GPU и в память под KV cache (кэш ключей и значений внимания для каждого разговора), а CPU почти не растёт с нагрузкой. Масштабировать по CPU — масштабировать по шуму. Посчитаем память. На один token нужно 2 × layers × kv_heads × head_dim × bytes. Для модели с 32 слоями, 8 KV heads, head_dim 128 в FP16: 2 × 32 × 8 × 128 × 2 = 131 072 байта ≈ 128 КиБ. Разговор на 8 000 tokens ≈ 1 ГиБ. На GPU с 80 ГБ, где 70 ГБ заняли веса, остаётся около 10 ГБ — примерно 10 таких разговоров одновременно. Поэтому сигнал для масштабирования — глубина очереди, число ожидающих запросов и занятость KV cache из метрик сервера, через custom metrics HPA или KEDA (надстройка для масштабирования по событиям).

KEDA умеет scale to zero (ноль копий без нагрузки). Для GPU-сервера в рабочие часы это плохая идея: первый клиент ждёт те самые 4–6 минут. Если pod не помещается на существующие узлы, Karpenter или Cluster Autoscaler создают новый узел. Это две петли подряд — копии, потом узлы, — отсюда минуты.

Сервер модели внутри pod

vLLM — стандартный выбор: PagedAttention (KV cache страницами, без дыр в памяти), continuous batching (на каждом шаге генерации в пакет добавляются новые запросы и убираются законченные), prefix caching, API, совместимый с OpenAI, квантизация. KServe — платформа поверх Kubernetes с ресурсом InferenceService, autoscaling вплоть до нуля и canary для моделей; vLLM работает внутри как backend. TGI от Hugging Face на 08.10.2026 в maintenance mode, авторы сами советуют vLLM, SGLang или llama.cpp.

Helm и GitOps: как это всё описать

Манифестов становится десятки, и для dev, staging и prod они отличаются парой чисел. Helm упаковывает их в chart (пакет шаблонов); values — параметры среды (-f values-prod.yaml, правый файл побеждает, --set сильнее файлов); release — установленный экземпляр с историей ревизий. helm upgrade даёт новую ревизию, helm rollback RELEASE REVISION возвращает прежнюю. Типовая схема: один chart агента и три файла values.

GitOps идёт дальше: желаемое состояние кластера лежит в Git, а контроллер Argo CD сравнивает его с живым. Расхождение помечается OutOfSync. Это даёт банку три вещи: аудит (каждое изменение production — commit с автором и review), откат (revert commit) и видимый дрейф (ручная правка kubectl edit сразу видна).