Как организовать GPU scheduling для multi-tenant LLM serving?

Краткий тезис

GPU scheduling для multi-tenant LLM serving — это распределение вычислительных ресурсов GPU между разными командами, продуктами или пользователями внутри одного кластера. Основные подходы включают физическую изоляцию (выделенные GPU), partitioning|временное разделение (планировщики вроде Kueue, Volcano), аппаратную изоляцию (MIG) и логические политики (fair share, priority/preemption). Выбор зависит от требований к изоляции, утилизации, справедливости и предсказуемости latency.

1. Термины и контекст

Multi-tenant LLM serving — ситуация, когда один кластер GPU обслуживает несколько арендаторов (tenants), каждый со своими моделями, нагрузками и SLA. Scheduling — процесс назначения GPU-ресурсов (целых карт, долей или времени) задачам инференса.

Ключевые цели

• Изоляция чтобы нагрузка одного tenant не влияла на latency других.
• Утилизация максимизация использования дорогих GPU.
• Fairness: равномерное распределение ресурсов между tenants.
• SLA compliance выполнение требований по latency и throughput.

2. Физическая изоляция (Dedicated GPU)

Простейший подход: каждому tenant выделяются фиксированные физические GPU.

Плюсы

• Максимальная изоляция (нет interference).
• Простота в реализации (partitioning|static partitioning).

Минусы

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

Когда использовать строгие SLA, модель очень большая (занимает всю GPU), мало tenants.

3. Временное разделение (Time‑sharing)

GPU выделяются на время выполнения задачи. Задачи ставятся в очередь, планировщик (например, Kueue из Kubernetes или Volcano) назначает им GPU по очереди.

Механизм

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

Плюсы

• Высокая утилизация.
• Возможность динамического распределения ресурсов.
• Поддержка gang scheduling (одновременный запуск группы задач).

Минусы

• Interference конкуренция за GPU во времени может вызывать задержки.
• Не подходит для real-time инференса с низкой latency (ожидание в очереди).

Пример конфигурации Kueue

apiVersion: kueue.x-k8s.io/v1beta1
kind: ResourceFlavor
metadata:
  name: gpu-flavor
spec:
  nodeLabels:
    accelerator: nvidia-tesla-a100
---

apiVersion: kueue.x-k8s.io/v1beta1
kind: ClusterQueue
metadata:
  name: tenant-a-queue
spec:
  resourceGroups:
    - coveredResources: ["nvidia.com/gpu"]
      flavors:
        - name: gpu-flavor
          resources:
            - name: "nvidia.com/gpu"
              nominalQuota: 4

4. MIG (Multi‑Instance GPU)

Аппаратная технология NVIDIA, позволяющая разделить одну GPU (A100, H100, H200) на до 7 изолированных инстансов (MIG instances). Каждый инстанс имеет собственные вычислительные блоки, память и кэш — полная аппаратная изоляция.

Как работает

• MIG конфигурируется на уровне драйвера (nvidia-smi mig).
• Каждый инстанс представляется как отдельное устройство в Kubernetes.
• Tenants получают изолированные «мини‑GPU» с гарантированными ресурсами.

Пример разделения A100 (80 ГБ):

Плюсы

• Аппаратная изоляция без потери производительности (в отличие от временного разделения).
• Подходит для моделей, помещающихся в меньшую память.
• Увеличивает утилизацию (одна карта обслуживает несколько tenants).

Минусы

• Ограниченное количество инстансов (до 7).
• Не все модели поддерживают работу на малых инстансах (требуется профилирование).
• Настройка и управление сложнее, чем физическая изоляция.

5. Fair share и гарантированные квоты

Fair share — политика, при которой каждый tenant гарантированно получает определённую долю кластера (например, 20%), но может использовать больше, если ресурсы свободны.

Механизмы

• Min‑max fairness каждому tenant выделяется минимум, излишки распределяются пропорционально.
• Weighted fair queuing (WFQ): tenants с большим весом получают больше ресурсов при конкуренции.
• Hierarchical resource quotas в Kubernetes можно задать namespace‑уровневые quota.

Пример политики в Kubernetes

apiVersion: v1
kind: ResourceQuota
metadata:
  name: tenant-a-quota
spec:
  hard:
    nvidia.com/gpu: 2
  scopeSelector:
    matchExpressions:
      - operator: In
        scopeName: PriorityClass
        values: ["high"]

Связь с priority/preemption

• Priority каждой задаче присваивается приоритет (число).
• Preemption: задача с более высоким приоритетом может вытеснить (preempt) низкоприоритетную, освободив GPU.

Важно вытеснение должно быть graceful (например, сохранить состояние модели и продолжить позже). Для инференса это часто неприемлемо (потеря запроса), поэтому preemption используют редко, только для batch‑задач.

6. GPU‑sharing: MPS и Time‑slicing

Помимо MIG, есть программные способы разделения одной GPU:

• MPS (Multi‑Process Service): CUDA‑runtime решение, позволяющее нескольким процессам одновременно отправлять ядра на GPU. Делит compute capacity, но память не изолирована (может переполниться).
• Time‑slicing (GPU sharing): драйвер NVIDIA (с поддержкой GPU Time‑Slicing) переключает контексты между задачами с квантами времени. Похоже на временное разделение, но на уровне одного GPU.
• Binpacking размещение нескольких маленьких моделей (или батчей) на одном GPU, чтобы увеличить occupancy.

Сравнение MIG, MPS, Time‑slicing:

7. Планировщики и фреймворки

8. Метрики и мониторинг

Для оценки качества GPU scheduling отслеживают:

• GPU Utilization — загрузка вычислительных блоков (SM).
• Memory Utilization — использование видеопамяти.
• Latency (P99) — время ответа для каждого tenant.
• Fairness (Gini coefficient) — равномерность распределения ресурсов.
• Preemption rate — частота вытеснения.
• Cost per request — итоговая стоимость обслуживания.

Пример сбора с NVIDIA DCGM

# Утилизация SM
nvidia-smi dmon -s p -d 1 -c 10

# Для MIG: nvidia-smi mig -i 0 -gi 1 -ci 0 -r

9. Рекомендации по выбору подхода

10. Пет-проект для закрепления

Задача Развернуть multi-tenant LLM serving на одной GPU A100 (или симуляторе) с MIG, двумя tenants (модель llama-7b и bert‑base) и Kueue.

Инструменты

• Docker, Kubernetes (minikube с GPU passthrough)
• NVIDIA MIG Manager, nvidia-device-plugin
• Kueue (установка через helm)
• vLLM или TGI для сервинга

Шаги:

1. Настроить MIG на GPU: создать два инстанса (1g.10gb и 2g.20gb).
2. Установить nvidia-device-plugin с MIG‑поддержкой.
3. Установить Kueue, создать две ClusterQueue: по одной на инстанс.
4. Запустить два Deployment с моделями, каждый использует свой MIG‑инстанс (в resource requests указать nvidia.com/gpu: 1).
5. Добавить LocalQueue для каждого tenant.
6. Запустить нагрузочный тест (locust или custom script) на оба эндпоинта.
7. Измерить latency, проверить изоляцию (если один tenant нагружен, у второго latency не растёт).

Ожидаемый результат

• Работающие сервисы на одном физическом GPU.
• P99 latency у tenant‑1 не зависит от нагрузки tenant‑2 (изоляция MIG).
• Kueue управляет очередями, приоритетами.

11. Связь с другими вопросами

12. Навигация

• Предыдущий: 825
• Следующий: 827
• Индекс: 00. Индекс разборов

Навигация

• Предыдущий: 825
• Следующий: 827
• Индекс: 00. Индекс разборов