Знаете ли платформы для оркестрации контейнеров с GPU
Что проверяют
Понимаете ли вы, как GPU попадает в контейнер и как им делятся задачи обучения и инференса. Следом обычно спрашивают, как запустить на одной карте несколько лёгких моделей или как поставить распределённое обучение сразу на несколько узлов.
Как отвечать
Базовый слой одинаков везде: драйвер NVIDIA на хосте и NVIDIA Container Toolkit, который пробрасывает устройство в контейнер. Локально это docker run --gpus all, в Docker Compose блок deploy.resources.reservations.devices.
Основная платформа сейчас Kubernetes:
- device plugin: публикует карты узла как ресурс
nvidia.com/gpu. Под просит его вlimitsи только целым числом; - NVIDIA GPU Operator: ставит на узлы драйверы, toolkit, device plugin и DCGM exporter для метрик утилизации;
- совместное использование: MIG режет A100 и H100 на изолированные части, time-slicing делит карту между подами по времени, в свежих версиях Kubernetes есть Dynamic Resource Allocation для гибкого описания устройств;
- очереди и gang scheduling: Kueue или Volcano, чтобы распределённое обучение стартовало, только когда свободны все нужные GPU;
- ML-обвязка: Kubeflow для обучения, KubeRay для Ray, KServe для инференса.
Кроме Kubernetes стоит знать Slurm: в исследовательских кластерах он всё ещё стандарт для обучения, контейнеры там запускают через enroot и pyxis. Управляемые варианты: GKE, EKS, AKS, Yandex Managed Service for Kubernetes с GPU-узлами. OpenShift это тот же Kubernetes, GPU Operator там тоже поддерживается.
Где спотыкаются
Называют Docker Swarm и Mesos рабочими вариантами. Для GPU-нагрузок в новых проектах их практически не берут, экосистема живёт в Kubernetes.
Забывают про узлы: не вешают taint на GPU-ноды, и туда сваливаются обычные поды, занимая дорогую машину. Или не сверяют версию CUDA в образе с драйвером на хосте.
Считают, что GPU делится как CPU. Запрос 0.5 карты не сработает, а time-slicing без MIG не изолирует память: одна модель может занять всю видеопамять и уронить соседей.