Это одна из ключевых концепций в MLOps
Фреймворки для deep learning (TensorFlow, PyTorch и т. д.) требуют, чтобы во время обучения были запущены все воркеры.
Допустим, training job требует 8 воркеров, каждый из которых запрашивает по 1 GPU.
В Kubernetes-кластере свободно только 5 GPU.
Без gang scheduling стандартный scheduler обрабатывает каждый Pod независимо.
В результате 5 worker Pod'ов будут запланированы, а ещё 3 останутся в статусе Pending.
При этом 5 запущенных воркеров фактически не смогут начать обучение. GPU будут заняты, пока система ждёт оставшиеся воркеры.
При использовании gang scheduling scheduler сначала проверяет, достаточно ли ресурсов для запуска всего training job.
Если ресурсов хватает, все worker Pod'ы планируются одновременно.
Если нет — не планируется ни один Pod. Пять свободных GPU остаются доступными для других job'ов.
Это можно назвать подходом – «всё или ничего».
В первую очередь gang scheduling позволяет избежать неэффективного использования GPU из-за частично запланированных распределённых workload'ов.
Kubeflow Trainer поддерживает gang scheduling из коробки через
podGroupPolicy.Он работает с установленными в кластере плагинами для gang scheduling, например Coscheduling.
👉 DevOps Portal