Всем привет! Меня зовут Дима Матушкин, я инженер в команде Nova и занимаюсь развитием Nova AI.

В этой статье разберем одну из задач, с которой сталкивается почти любая команда, запускающая AI/ML-нагрузки в Kubernetes: как эффективно использовать GPU в кластере, где одновременно живут инференс, обучение, эксперименты, ноутбуки дата-сайентистов и batch-задачи.

На старте кажется, что достаточно установить NVIDIA GPU Operator, прокинуть видеокарты в Kubernetes и начать указывать nvidia.com/gpu в манифестах. Для простых сценариев этого действительно хватает. Но как только нагрузок становится больше, а GPU начинают конкурировать между собой, выясняется, что проблема не только в том, чтобы "выдать видеокарту" конкретному поду.

Нужно уметь запускать связанные поды как единое целое, управлять очередями, учитывать приоритеты, не ломать распределенные задачи из-за сетевой топологии и делить GPU так, чтобы дорогие ресурсы не простаивали. Обычный планировщик Kubernetes не закрывает эти сценарии комплексно, поэтому для Nova AI мы начали смотреть в сторону специализированных планировщиков для AI/ML нагрузок.

В рамках сравнения мы рассматривали три решения: Volcano, Kueue и KAI Scheduler. Ниже разберем, какие проблемы мы хотели решить, как с ними справляется каждый инструмент и что в итоге выбрали для нашей платформы.

Почему обычного планировщика Kubernetes недостаточно

Kubernetes хорошо справляется с базовой оркестрацией контейнеров. Он умеет размещать поды по нодам, учитывать requests и limits, работать с taints, tolerations, affinity и другими стандартными механизмами. Но AI/ML-нагрузки устроены сложнее обычных stateless-сервисов.

Мы сформулировали 5 проблем, которые для нас были ключевыми.

1. Нет полноценного группового планирования

Для распределенного обучения или инференса большой языковой модели часто нужны несколько GPU на разных узлах. Тензорный и пайплайновый параллелизм позволяют разложить модель по нескольким устройствам, но у такого подхода есть важное ограничение: если один из нужных подов не запустился, остальные поды уже не дают результата.

Например, если веса модели распределены между несколькими worker-подами, а ресурсов хватило только на часть из них, кластер формально что-то запустил, но рабочий инференс не появился. GPU при этом могут быть заняты.

Обычный планировщик Kubernetes работает с подами по отдельности. Он не воспринимает набор подов как одну логическую job, которую нужно либо запустить целиком, либо не запускать вообще. Для AI/ML это быстро превращается в потерю ресурсов.

2. Не хватает очередей и приоритетов

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

Пример: пользователь запускает ноутбук, занимает мощную GPU, а затем использует только небольшую часть ее возможностей. В это же время более важная задача, например инференс модели для чат-бота или RAG-системы, может не стартовать, потому что свободных GPU в кластере уже нет.

В таких сценариях нужен не просто факт наличия ресурса, а явная модель очередей: какие команды имеют гарантированную квоту, какие задачи могут ждать, какие должны вытеснять менее важные workload и как возвращать ресурсы обратно.

3. Планировщик не учитывает топологию GPU-кластера

Для распределенных AI-задач важно не только получить нужное количество GPU. Важно, где именно эти GPU находятся.

Если поды с частями одной модели окажутся рядом, например внутри одного сервера с NVLink или на узлах, связанных через InfiniBand или RoCE с GPU Direct, задача будет работать быстрее и предсказуемее. Если же часть трафика пойдет через обычную сеть, распределенный инференс или обучение будет работать неэффективно.

Поэтому планировщик должен понимать топологию кластера: какие ноды находятся ближе друг к другу, где есть быстрая связность, какие группы узлов подходят для конкретной распределенной job.

4. Нужно справедливое распределение ресурсов

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

Речь не только про GPU. AI/ML-задачи используют CPU, память и видеокарты одновременно. Если workload забирает много CPU и памяти на GPU-нодах, видеокарты могут остаться физически свободными, но новые GPU-задачи все равно не смогут стартовать из-за нехватки сопутствующих ресурсов.

Для таких случаев нужны алгоритмы справедливого распределения. Они должны учитывать несколько типов ресурсов сразу и не позволять одной очереди или одной команде монополизировать кластер.

5. Нужно динамически делить GPU

NVIDIA GPU Operator уже решает базовую интеграцию GPU с Kubernetes и поддерживает механизмы дробления видеокарт. Но в стандартном подходе конфигурацию часто нужно готовить заранее.

Например, если мы используем MIG, нужно заранее описать нужные профили, применить конфигурацию, промаркировать узлы и только после этого запускать workload. Если требования изменились, процесс приходится повторять.

На практике заранее не всегда понятно, какой профиль нужен конкретной задаче. Удобнее описать потребность на уровне workload: сколько нужно видеопамяти, сколько вычислительных ресурсов, сколько частей GPU. Дальше планировщик должен сам подобрать подходящее размещение.

Какие планировщики мы рассматривали

Ограничиваться набором отдельных доработок вокруг kube-scheduler не хочется. Нужен специализированный планировщик, который изначально рассчитан на batch, AI/ML и HPC-сценарии.

Мы сравнивали 3 решения.

Volcano — cloud-native batch scheduler для Kubernetes, ориентированный на AI/ML, HPC и другие вычислительно тяжелые нагрузки. Он добавляет собственные сущности для job, очередей, группового планирования и расширенной логики размещения.

Kueue — Kubernetes-native система очередей и admission control для batch workload. Важная особенность Kueue в том, что он не заменяет стандартный scheduler. Он управляет тем, когда workload можно допустить к запуску, работает с очередями, квотами и приоритетами, а само размещение затем передает стандартному планировщику Kubernetes.

KAI Scheduler — планировщик для AI-нагрузок, изначально развивавшийся в контексте Run:ai и NVIDIA. Его фокус — GPU-кластеры, распределенные job и повышение утилизации GPU.

Отдельно мы не включали в это сравнение HAMi как самостоятельный планировщик. HAMi важен как open-source платформа для управления гетерогенными AI-ресурсами и дробления GPU, AMD GPU, TPU и других устройств. Но его первичная задача отличается от задачи полноценного scheduler для AI/ML workload.

Gang Scheduling

Первая проверка — умеет ли планировщик запускать связанную группу подов как единое целое.

В AI/ML это базовый сценарий. Если распределенная задача требует четыре worker-пода, то запуск двух из них не решает задачу. Наоборот, он может занять GPU и оставить систему в нерабочем промежуточном состоянии.

Volcano

Volcano реализует gang scheduling через CRD PodGroup. Этот ресурс связывает несколько подов в одну логическую группу.

Пример манифеста PodGroup в Volcano

apiVersion: scheduling.volcano.sh/v1beta1
kind: PodGroup
metadata:
   name: test
   namespace: default
spec:
   minMember: 1
   minResources:
      cpu: "3"
      memory: "2048Mi"
   priorityClassName: high-priority
   queue: default

У PodGroup есть поле minMember, где можно указать минимальное число подов, которые должны быть запущены одновременно. Это удобно, например, для batch-инференса, где нужно управлять количеством параллельных процессов.

Также есть minResources: минимальный набор ресурсов, необходимый для запуска группы. Если в кластере нет нужного количества CPU, памяти или GPU, Volcano не будет запускать часть подов и ждать, что остальные когда-нибудь доедут следом.

При использовании более высокоуровневого VolcanoJob такие группы могут создаваться автоматически. По сути, VolcanoJob расширяет идею обычной Kubernetes Job, добавляя функции, которые нужны для batch и AI/ML-сценариев.

Kueue

Kueue подходит к проблеме иначе. Он реализует all-or-nothing поведение через настройку waitForPodsReady.

Пример настройки подхода all-or-nothing

waitForPodsReady:
      timeout: 10m
      recoveryTimeout: 3m
      blockAdmission: false
      requeuingStrategy:
            timestamp: Eviction | Creation
            backoffLimitCount: 5
            backoffBaseSeconds: 60
            backoffMaxSeconds: 3600

В этой модели Kueue ожидает, что все поды workload станут ready за заданный timeout. Если этого не произошло, размещение отменяется. Если задачу нужно вернуть в очередь, дополнительно настраивается requeuingStrategy.

Такой подход закрывает часть проблемы, но он менее гибкий. Логика завязана на ожидание готовности и timeout, а не на явное описание минимального состава группы и минимального набора ресурсов на уровне отдельной job.

KAI Scheduler

KAI Scheduler, как и Volcano, использует PodGroup. Отличие в том, что в составе KAI Scheduler есть компонент PodGrouper, который может создавать группы подов автоматически на основании примененного манифеста.

Пример манифеста PodGroup в Kai Scheduler

apiVersion: scheduling.run.ai/v2alpha2
kind: PodGroup
metadata:
      name: external-batch-job
spec:
      minMember: 2
      queue: default-queue
      subGroups:
            - name: workers
               minMember: 2

Например, обычная Kubernetes Job может быть объединена в PodGroup, а минимальное количество одновременно запущенных процессов можно задать через метки вроде kai.scheduler/batch-min-member.

Вывод

Volcano и KAI Scheduler решают gang scheduling близким способом: через явную сущность PodGroup. Kueue тоже умеет добиваться all-or-nothing поведения, но делает это через timeout и requeue-логику. Для наших сценариев модель Volcano выглядит более прямой и управляемой.

Очереди и приоритеты

Вторая проверка — как планировщик работает с очередями, квотами и приоритетами.

Для AI/ML-платформы это обязательная часть. В одном кластере могут быть production-инференс, фоновые задачи Airflow, обучение моделей и пользовательские эксперименты. Все они не должны конкурировать за GPU на равных.

Volcano

Volcano строит модель очередей вокруг собственного CRD Queue.

Пример манифеста Queue в Volcano

apiVersion: scheduling.volcano.sh/v1beta1
kind: Queue
metadata:
     name: child-queue-a
spec:
     reclaimable: true
     parent: root
     deserved:
          cpu: 64
          memory: 128Gi

У очереди можно задавать weight, capability и guarantee. Эти параметры позволяют описывать вес очереди, ее лимиты и гарантированную квоту ресурсов.

Также Volcano поддерживает два важных механизма перераспределения ресурсов. Preempt позволяет вытеснять менее важные задачи внутри одной очереди или внутри одной job, если более приоритетной задаче нужны ресурсы. Reclaim позволяет возвращать ресурсы между очередями. Если очередь вышла за свою гарантированную долю и помечена как reclaimable: true, ресурсы могут быть изъяты в пользу другой очереди, которой они сейчас нужнее.

Дополнительно Volcano поддерживает иерархические очереди. Это удобно для мультитенантных кластеров, где ресурсы нужно распределять не только между отдельными задачами, но и между командами, проектами или организационными единицами.

Kueue

Kueue использует связку ClusterQueue и LocalQueue.

Пример манифестов ClusterQueue и LocalQueue в Kueue

apiVersion: kueue.x-k8s.io/v1beta2 
kind: ClusterQueue
metadata:
     name: "cluster-queue"
spec:
     namespaceSelector: {} # match all.
     resourceGroups:
     - coveredResources: ["cpu", "memory", "pods"]
        flavors:
        - name: "default-flavor"
           resources:
           - name: "cpu"
              nominalQuota: 9
           - name: "memory"
              nominalQuota: 36Gi
           - name: "pods"
              nominalQuota: 5
--- 
apiVersion: kueue.x-k8s.io/v1beta2
kind: LocalQueue
metadata:
     namespace: team-a
     name: team-a-queue
spec:
     clusterQueue: cluster-queue

ClusterQueue описывает глобальную очередь на уровне кластера. Через нее можно управлять ресурсами вроде CPU, памяти и GPU, а также задавать правила допуска workload. LocalQueue живет в namespace и связывает workload с глобальной очередью. Это позволяет группировать похожие задачи внутри namespace, но при этом держать общий контроль ресурсов на уровне кластера.

Для централизованного управления квотами между глобальными очередями используется Cohort. Такая модель хорошо вписывается в Kubernetes, потому что Kueue остается admission control слоем и не подменяет собой весь процесс планирования.

KAI Scheduler

KAI Scheduler также использует кастомный ресурс Queue.

Пример манифеста Queue в Kai Scheduler

apiVersion: scheduling.run.ai/v2
kind: Queue
metadata:
     name: ml-team
spec:
     displayName: "ML Team"
     parentQueue: "research-team"
     priority: 200
     resources:
          cpu:
               quota: 500
               overQuotaWeight: 2
          gpu:
               quota: 1
               overQuotaWeight: 1

В очереди можно задавать quota, то есть гарантированно выделенные ресурсы, и limit, то есть максимально доступное количество ресурсов. Поле overQuotaPriority управляет порядком выдачи ресурсов очередям, которые уже вышли за свою гарантированную квоту.

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

Вывод

Все три решения умеют работать с очередями и приоритетами. Volcano и KAI Scheduler предлагают scheduler-native модель через собственный Queue. Kueue решает задачу в более Kubernetes-native стиле через admission control, ClusterQueue, LocalQueue и Cohort.

На этом критерии нельзя сказать, что один инструмент безусловно закрывает задачу, а остальные нет. Разница скорее в модели интеграции и в том, насколько глубоко планировщик сам участвует в принятии решений.

Topology-aware scheduling

Третья проверка — умеет ли планировщик учитывать топологию кластера.

Для обычного сервиса часто достаточно найти любую ноду с нужными ресурсами. Для распределенного AI workload этого мало. Если части одной задачи окажутся на узлах с плохой связностью, производительность может просесть настолько, что формально запущенная задача станет практически бесполезной.

Volcano

В Volcano для topology-aware scheduling используется концепция HyperNode.

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

Пример манифестов HyperNode в Volcano

apiVersion: topology.volcano.sh/v1alpha1
kind: HyperNode
metadata:
     name: s4
spec:
     tier: 2
     members:
     - type: HyperNode
       selector:
          exactMatch:
               name: "s0"
     - type: HyperNode
        selector:
          exactMatch:
               name: "s1"
---
apiVersion: topology.volcano.sh/v1alpha1
kind: HyperNode
metadata:
     name: s0
spec:
     tier: 1
     members:
     - type: Node
       selector:
          exactMatch:
               name: "node-0"
     - type: Node
        selector:
          exactMatch:
               name: "node-1"  

Несколько HyperNode могут объединяться в иерархию. Для этого используется tier: чем ниже значение tier, тем ближе гиперноды друг к другу и тем ниже ожидаемые задержки между узлами внутри этой зоны. На уровне VolcanoJob можно задавать максимальный tier для размещения. Так планировщик получает не только требование "найди мне GPU", но и ограничение по тому, насколько близко должны находиться узлы для распределенной задачи.

Топологию можно описывать вручную через метки на нодах. Для кластеров с InfiniBand или RoCE важнее другой вариант: Volcano может использовать autodiscovery через подключение к UFM, то есть Unified Fabric Manager от NVIDIA. Для нас это особенно важно, потому что в развитии Nova AI есть сценарии с RDMA, InfiniBand и RoCE.

Kueue

Kueue поддерживает topology-aware scheduling через ресурс Topology.

Пример манифеста Topology в Kueue

apiVersion: kueue.x-k8s.io/v1beta2
kind: Topology 
metadata:
     name: "default"
spec:
     levels:
     - nodeLabel: "cloud.provider.com/topology-block"
     - nodeLabel: "cloud.provider.com/topology-rack"
     - nodeLabel: "kubernetes.io/hostname"

С помощью меток на нодах можно описать физическое размещение узлов в датацентре и учитывать эту иерархию при размещении workload. Идея похожа: планировщик должен понимать, какие узлы ближе друг к другу, а какие находятся в разных зонах.

В сравнении с Volcano здесь для нас не хватало двух вещей: механики tier в том виде, в котором она есть у HyperNode, и autodiscovery топологии через UFM.

KAI Scheduler

KAI Scheduler использует по аналогии с Kueue CRD Topology, который также описывает физическое расположение нод через метки.

Пример манифеста Topology в Kai Scheduler

apiVersion: kai.scheduler/v1alpha1
kind: Topology
metadata:
     name: "cluster-topology"
spec:
     levels:
     - nodeLabel: "cloud.provider.com/topology-block"
     - nodeLabel: "cloud.provider.com/topology-rack"
     - nodeLabel: "kubernetes.io/hostname"

Для workload можно задавать правила размещения через аннотации kai.scheduler/topology-required-placement и kai.scheduler/topology-preferred-placement. Первая задает жесткие требования, вторая позволяет описать предпочтительное размещение через soft affinity.

Вывод

Все три решения могут учитывать топологию кластера. Но для нас Volcano оказался сильнее именно в деталях: HyperNode, tier и autodiscovery через UFM лучше ложатся на будущие сценарии Nova AI с RDMA, InfiniBand и RoCE.

Справедливое распределение ресурсов

Четвертая проверка — как планировщик не дает одной задаче или одной очереди забрать слишком большую долю кластера.

В AI/ML-кластере важно учитывать не один ресурс, а сразу несколько: CPU, память и GPU. Если смотреть только на GPU, можно получить перекос по CPU или памяти. Если смотреть только на CPU и память, можно плохо использовать видеокарты.

Volcano

Volcano реализует справедливое распределение через механизм Dominant Resource Fairness, или DRF.

DRF считает для каждой job ее dominant share: максимальную долю какого-либо ресурса относительно общего объема ресурсов в кластере. Например, если job использует небольшую долю CPU, но большую долю памяти, ее доминирующим ресурсом будет память.

При планировании Volcano отдает приоритет job с меньшим dominant share. Это помогает не допускать ситуации, когда одна задача забирает слишком большую долю дефицитного ресурса и мешает остальным workload.

Kueue

Kueue использует механизм Admission Fair Sharing.

Идея в том, чтобы учитывать историческое потребление ресурсов в рамках LocalQueue. Workload из очередей, которые потребляли меньше ресурсов, получают преимущество при допуске к запуску.

Также можно задавать веса для разных типов ресурсов. Это важно для GPU-кластеров, потому что одна GPU обычно ценнее одной единицы CPU или памяти, и планировщик должен уметь учитывать эту разницу.

KAI Scheduler

В KAI Scheduler справедливое распределение реализовано через Time Based Fairshare (очень похоже на механизм Admission Fair Sharing в Kueue).

Планировщик сохраняет исторические данные о потреблении ресурсов разными очередями в Prometheus. При запуске новых задач он учитывает, сколько ресурсов очереди потребляли за заданный период, и приоритизирует те, которые исторически получали меньше.

Если очередь долго находилась в нехватке ресурсов, она может получить преимущество перед очередями, которые уже активно использовали кластер.

Вывод

Все три планировщика решают задачу справедливого распределения, но делают это по-разному. Volcano использует DRF внутри scheduler, Kueue работает через admission fair sharing, KAI Scheduler опирается на историческое потребление и Prometheus.

С точки зрения результата все подходы направлены на одну цель: не дать одной очереди или одной job монополизировать ресурсы.

Динамическое дробление GPU

Последняя проверка для нас была самой прикладной: умеет ли планировщик помогать с дроблением GPU.

Это важный сценарий для платформы. Не все задачи требуют целую видеокарту. Часто workload нужен ограниченный объем видеопамяти и часть вычислительных ресурсов. Если выдавать под каждую такую задачу целую GPU, утилизация будет низкой.

Kueue

Kueue не предоставляет собственного механизма динамического дробления GPU на уровне планировщика.

Он может быть полезен для очередей, квот и admission control, но сам по себе не решает задачу выделения частей GPU под workload. Для нашего сравнения это важное ограничение.

KAI Scheduler

KAI Scheduler использует для GPU sharing механизм NVIDIA Time-Slicing.

Time-Slicing позволяет нескольким контейнерам разделять один физический GPU через быстрое переключение контекстов. Каждому процессу выделяется квант времени, а процессы выполняются по круговой схеме.

Плюс подхода в том, что он доступен почти на всех GPU NVIDIA, включая старые поколения. Это делает его универсальным и достаточно простым для включения.

Минус в отсутствии жесткой изоляции ресурсов. У workload нет гарантированной доли видеопамяти, процессы могут конфликтовать, а ошибки вроде out of memory придется контролировать на уровне приложения или дополнительной логики. Если контейнер получил доступ к GPU, он может запускать несколько процессов и использовать больше ресурсов, чем ожидалось.

Для некоторых сценариев этого достаточно. Но для production-нагрузок, где нужна предсказуемость, такой подход подходит не всегда.

Volcano

Volcano поддерживает более строгие механизмы совместного использования GPU: NVIDIA MIG и HAMi-Core.

MIG, или Multi-Instance GPU, — аппаратный механизм партиционирования. Он позволяет разделить один физический GPU на несколько независимых GPU-единиц с аппаратной изоляцией. Каждая часть получает выделенные вычислительные блоки, L2 cache, контроллеры памяти и отдельные пути к памяти.

Такой подход важен для production-сред, потому что одна задача не должна ломать соседнюю из-за неконтролируемого потребления видеопамяти. Ограничение MIG в том, что он поддерживается только на GPU новых поколений, начиная с архитектуры Ampere.

HAMi-Core работает иначе. Это библиотека libvgpu.so, которая внедряется в контейнеры с GPU-нагрузкой и располагается между CUDA Runtime и CUDA Driver. За счет LD_PRELOAD она загружается раньше CUDA-библиотек и перехватывает вызовы, связанные с выделением и освобождением памяти GPU, а также с использованием вычислительных блоков.

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

Вывод

По критерию динамического дробления GPU Volcano оказался для нас самым сильным вариантом. Kueue эту задачу не закрывает. KAI Scheduler использует Time-Slicing, но этот механизм не дает жесткой изоляции ресурсов. Volcano поддерживает MIG и HAMi-Core, поэтому лучше подходит для сценариев, где важны предсказуемость и стабильная работа нескольких workload на одном GPU.

Сводное сравнение

Если собрать все критерии в одну таблицу, получается такая картина.

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

Почему мы выбрали Volcano

Для Nova AI нам был нужен планировщик, который закрывает не одну отдельную проблему, а всю цепочку задач вокруг GPU workload.

Нам нужен gang scheduling, потому что распределенный инференс и обучение нельзя запускать частями. Нужны очереди и приоритеты, потому что в одном кластере живут production-задачи, фоновые пайплайны и пользовательские эксперименты. Нужен topology-aware scheduling, потому что распределенные AI-задачи чувствительны к сетевой связности между узлами. Нужна справедливая модель распределения ресурсов, чтобы одна команда или одна крупная job не забирала кластер целиком. И нам нужно динамическое дробление GPU, потому что выдавать целую видеокарту каждой небольшой задаче неэффективно.

Volcano оказался инструментом, который закрывает все эти пять направлений.

Особенно важными для нас стали 2 пункта.

Первый — работа с топологией через HyperNode и autodiscovery через UFM. В Nova AI мы планируем развивать сценарии с RDMA, InfiniBand и RoCE, поэтому планировщик должен понимать не только количество GPU, но и то, как узлы связаны между собой.

Второй — дробление GPU через MIG и HAMi-Core. Для платформы, где одновременно работают разные ML- и AI-нагрузки, важна изоляция ресурсов..

Поэтому в Nova AI мы остановились на Volcano как на целевом планировщике для AI/ML-задач.

Что дальше

В этой статье мы разобрали сам выбор: почему стандартного планировщика Kubernetes недостаточно для AI/ML-нагрузок, какие проблемы появляются в GPU-кластере и как с ними справляются Volcano, Kueue и KAI Scheduler.

В следующей части логично перейти от сравнения к практике и разобрать Volcano изнутри: как устроены циклы планирования, что такое actions и plugins, как работают enqueue, allocate, preempt, reclaim и backfill, и как все это применяется в реальных сценариях Nova AI.

Планируем показать 3 кейса:

• динамическое дробление GPU, где workload запрашивает не конкретный MIG-профиль, а нужный объем видеопамяти и вычислительных ресурсов;

• распределенный инференс LLM через KubeRay, где Volcano помогает запускать head- и worker-поды как единую группу;

• вытеснение низкоприоритетных задач, когда production-инференс должен получить GPU быстрее фоновой задачи.

Ставьте лайки и пишите комментарии, если эта статья была полезна и если желаете по-скорее увидеть вторую часть :)

Если вы запускаете AI/ML workload в Kubernetes, специализированный планировщик лучше закладывать в архитектуру заранее. На одном простом сервисе разница может быть незаметна. Но как только в кластере появляются очереди, распределенные модели и конкуренция за GPU, планирование становится отдельным инженерным слоем, от которого напрямую зависит утилизация и предсказуемость всей платформы.