For clean Markdown content of this page, append .md to this URL. For the complete documentation index, see https://docs.nvidia.com/dynamo/llms.txt. For full content including API reference and SDK examples, see https://docs.nvidia.com/dynamo/llms-full.txt.

Многоузловые развертывания

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

Обзор

Dynamo поддерживает многоузловые развертывания через секцию multinode в спецификациях ресурсов. Это позволяет:

распределять нагрузки по нескольким физическим узлам
масштабировать GPU-ресурсы за пределы одной машины
поддерживать большие модели, которым требуется широкая tensor parallelism
достигать высокой доступности и устойчивости к сбоям

Базовые требования

Кластер Kubernetes: версия 1.24 или новее
GPU-узлы: несколько узлов с GPU NVIDIA
Высокоскоростная сеть: InfiniBand, RoCE или Ethernet с высокой пропускной способностью (рекомендуется для оптимальной производительности)

Продвинутая оркестрация многоузловых развертываний

Использование Grove (по умолчанию)

Для сложных многоузловых развертываний Dynamo интегрируется с продвинутыми системами оркестрации Kubernetes:

Grove: gang scheduling с учетом топологии сети и авто-масштабирование для AI-нагрузок
KAI-Scheduler: нативный для Kubernetes scheduler, оптимизированный для AI-нагрузок в масштабе

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

Возможности, доступные с Grove:

декларативная композиция AI-нагрузок
многоуровневое горизонтальное авто-масштабирование
настраиваемый порядок запуска компонентов
rolling updates с учетом ресурсов
Topology Aware Scheduling — размещение подов внутри стойки, блока или другого домена топологии для меньшей задержки

KAI-Scheduler — это нативный для Kubernetes scheduler, оптимизированный для AI-нагрузок в большом масштабе.

Возможности, доступные с KAI-Scheduler:

gang scheduling
размещение подов с учетом топологии сети
алгоритмы планирования, оптимизированные для AI-нагрузок
учет и распределение GPU-ресурсов
поддержка сложных ограничений планирования
интеграция с Grove для расширенных возможностей
оптимизации производительности для крупных развертываний

Предварительные требования

установленный на кластере Grove
(Необязательно) установленный на кластере KAI-Scheduler с созданной очередью по умолчанию dynamo. Если в ресурсе DGD не задана аннотация очереди, operator по умолчанию использует очередь dynamo. Пользовательские имена очередей можно задать через аннотацию nvidia.com/kai-scheduler-queue, но очередь должна существовать в кластере до развертывания.

KAI-Scheduler необязателен, но рекомендуется для расширенных возможностей планирования.

Использование LWS и Volcano

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

LWS: Установка LWS
Volcano: Установка Volcano

Volcano — нативный для Kubernetes scheduler, оптимизированный для AI-нагрузок в масштабе. Он используется вместе с LWS, чтобы обеспечить поддержку gang scheduling.

Основные понятия

Алгоритм выбора orchestrator

Dynamo автоматически выбирает лучший доступный orchestrator для многоузловых развертываний по следующей логике:

Когда доступны и Grove, и LWS:

По умолчанию выбирается Grove (рекомендуется для продвинутых AI-нагрузок)
LWS выбирается, если вы явно задали аннотацию nvidia.com/enable-grove: "false" в ресурсе DGD

Когда доступен только один orchestrator:

автоматически выбирается установленный orchestrator (Grove или LWS)

Интеграция scheduler:

С Grove: автоматически интегрируется с KAI-Scheduler, когда он доступен, и предоставляет:
- расширенное управление очередями через аннотацию nvidia.com/kai-scheduler-queue
- политики планирования, оптимизированные для AI
- размещение нагрузки с учетом ресурсов
С LWS: использует scheduler Volcano для gang scheduling и координации ресурсов

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

По умолчанию (Grove с KAI-Scheduler):

apiVersion: nvidia.com/v1alpha1
kind: DynamoGraphDeployment
metadata:
  name: my-multinode-deployment
  annotations:
    nvidia.com/kai-scheduler-queue: "dynamo"
spec:
  # ... your deployment spec

Примечание: Аннотация nvidia.com/kai-scheduler-queue по умолчанию имеет значение "dynamo". Если вы укажете собственное имя очереди, убедитесь, что эта очередь существует в кластере до развертывания. Доступные очереди можно проверить командой kubectl get queues.

Принудительное использование LWS:

apiVersion: nvidia.com/v1alpha1
kind: DynamoGraphDeployment
metadata:
  name: my-multinode-deployment
  annotations:
    nvidia.com/enable-grove: "false"
spec:
  # ... your deployment spec

Секция `multinode`

Секция multinode в спецификации ресурса определяет, на скольких физических узлах должна размещаться нагрузка:

apiVersion: nvidia.com/v1alpha1
kind: DynamoGraphDeployment
metadata:
  name: my-multinode-deployment
spec:
  # ... your deployment spec
  services:
    my-service:
      ...
      multinode:
        nodeCount: 2
      resources:
        limits:
          gpu: "2"            # 2 GPUs per node

Распределение GPU

Связь между multinode.nodeCount и gpu является мультипликативной:

multinode.nodeCount: количество физических узлов
gpu: количество GPU на узел
Всего GPU: multinode.nodeCount × gpu

Пример:

multinode.nodeCount: "2" + gpu: "4" = 8 GPU всего (4 GPU на узел на 2 узлах)
multinode.nodeCount: "4" + gpu: "8" = 32 GPU всего (8 GPU на узел на 4 узлах)

Согласование Tensor Parallelism

Tensor parallelism (tp-size или --tp) в вашей команде/аргументах должен совпадать с общим количеством GPU:

# Example: 2 multinode.nodeCount × 4 GPUs = 8 total GPUs
apiVersion: nvidia.com/v1alpha1
kind: DynamoGraphDeployment
metadata:
  name: my-multinode-deployment
spec:
  # ... your deployment spec
  services:
    my-service:
      ...
      multinode:
        nodeCount: 2
      resources:
        limits:
          gpu: "4"
      extraPodSpec:
        mainContainer:
          ...
          args:
            # Command args must use tp-size=8
            - "--tp-size"
            - "8"  # Must equal multinode.nodeCount × gpu

Поведение Operator для конкретных backend

Когда вы развертываете многоузловую нагрузку, Dynamo operator автоматически применяет конфигурации, специфичные для backend, чтобы включить распределенное выполнение. Понимание этих автоматических изменений помогает устранять неполадки и оптимизировать развертывания.

Backend vLLM

Для многоузловых развертываний vLLM operator автоматически выбирает и настраивает подходящий режим распределенного выполнения на основе ваших настроек parallelism:

Режимы развертывания

Operator автоматически определяет режим развертывания на основе конфигурации parallelism:

1. Режим Tensor/Pipeline Parallelism (одна модель на нескольких узлах)

Когда используется: когда world_size > GPUs_per_node, где world_size = tensor_parallel_size × pipeline_parallel_size
Сценарий: распределение одного экземпляра модели по нескольким узлам с помощью tensor или pipeline parallelism

Operator использует Ray для многоузловых развертываний tensor/pipeline parallel. Ray обеспечивает автоматическое управление placement group и запуск worker-ов на разных узлах.

Ведущий узел:

Команда: ray start --head --port=6379 && <original-vllm-command> --distributed-executor-backend ray
Поведение: запускает Ray head node, затем выполняет vLLM, который создает placement group, охватывающую всех Ray worker-ов
Проверки: все health probes остаются активными (liveness, readiness, startup)

Узлы-воркеры:

Команда: ray start --address=<leader-hostname>:6379 --block
Поведение: присоединяется к Ray cluster и блокируется; vLLM на leader создает Ray actors на этих worker-ах
Проверки: все probes (liveness, readiness, startup) автоматически удаляются

Ray executor vLLM автоматически создает placement group и запускает worker-ов по всему кластеру. Флаг --nnodes НЕ используется с Ray — он совместим только с backend mp.

2. Режим Data Parallel (несколько экземпляров модели на разных узлах)

Когда используется: когда world_size × data_parallel_size > GPUs_per_node
Сценарий: запуск нескольких независимых экземпляров модели на узлах с data parallelism (например, MoE-модели с expert parallelism)

Все узлы (Leader и Worker):

Вставляемые флаги:
- --data-parallel-address <leader-hostname> - адрес сервера координации
- --data-parallel-size-local <value> - количество data parallel worker-ов на узел
- --data-parallel-rpc-port 13445 - RPC-порт для координации data parallel
- --data-parallel-start-rank <value> - стартовый rank для этого узла (вычисляется автоматически)
Проверки: worker probes удаляются; leader probes остаются активными

Примечание: operator интеллектуально вставляет эти флаги в вашу команду независимо от ее структуры (прямые Python-команды или shell-обертки)

Почему Ray для многоузлового TP/PP?

vLLM поддерживает два backend для распределенного выполнения: ray и mp. Для многоузловых развертываний:

Ray executor: vLLM создает placement group и запускает Ray actors по всему кластеру. Worker-ы не запускают vLLM напрямую - процесс vLLM на leader управляет всем.
mp executor: каждый узел должен запускать собственный процесс vLLM с --nnodes, --node-rank, --master-addr, --master-port. Такой подход сложнее оркестрировать.

Дynamo operator использует Ray, потому что:

Это соответствует официальной multi-node документации vLLM (см. multi-node-serving.sh)
Оркестрация проще: только leader запускает vLLM, а worker-ам нужны лишь Ray agents
vLLM автоматически управляет созданием placement group и worker-ами

Поддержка Compilation Cache

Когда для volume mount задано useAsCompilationCache: true, operator автоматически устанавливает:

VLLM_CACHE_ROOT: переменную окружения, указывающую на точку монтирования cache

Backend SGLang

Для многоузловых развертываний SGLang operator вставляет параметры distributed training:

Ведущий узел

Вставляемые флаги: вставляет --dist-init-addr <leader-hostname>:29500 --nnodes <count> --node-rank 0
Проверки: все health probes остаются активными

Узлы-воркеры

Вставляемые флаги: вставляет --dist-init-addr <leader-hostname>:29500 --nnodes <count> --node-rank <dynamic-rank>
- node-rank автоматически определяется по stateful identity pod-а
Проверки: все probes (liveness, readiness, startup) автоматически удаляются

Примечание: operator интеллектуально вставляет эти флаги независимо от структуры вашей команды (прямые Python-команды или shell-обертки).

Backend TensorRT-LLM

Для многоузловых развертываний TensorRT-LLM operator настраивает коммуникацию на основе MPI:

Ведущий узел

SSH-конфигурация: автоматически настраивает SSH-ключи и конфигурацию из Kubernetes secret
MPI-команда: оборачивает вашу команду в mpirun с:
- корректным списком хостов, включая все worker-узлы
- SSH-конфигурацией для аутентификации без пароля на порту 2222
- распространением переменных окружения на все узлы
- активацией виртуального окружения Dynamo
Проверки: все health probes остаются активными

Узлы-воркеры

SSH daemon: заменяет вашу команду настройкой и запуском SSH daemon
- генерирует host keys в доступных пользователю каталогах (без привилегий)
- настраивает SSH daemon на прослушивание порта 2222
- настраивает authorized keys для доступа leader
Проверки:
- Проверки Liveness and Startup: удаляются (worker-узлы запускают SSH daemon, а не основное приложение)
- Проверка Readiness: заменяется проверкой TCP socket на SSH-порту 2222
  - Initial Delay: 20 seconds
  - Period: 20 seconds
  - Timeout: 5 seconds
  - Failure Threshold: 10

Дополнительная конфигурация

Переменная окружения: OMPI_MCA_orte_keep_fqdn_hostnames=1 добавляется на все узлы
SSH volume: автоматически монтирует secret с парой SSH-ключей (обычно называется mpirun-ssh-key-<deployment-name>)
Автоматическая генерация SSH-ключей: operator автоматически генерирует secret с парой SSH-ключей, когда обнаруживает многоузловой DynamoGraphDeployment. Ручное создание secret не требуется.

Конфигурация Compilation Cache

Operator поддерживает тома compilation cache для оптимизации backend:

Backend	Уровень поддержки	Переменные окружения	Точка монтирования по умолчанию
vLLM	Полная поддержка	`VLLM_CACHE_ROOT`	Задается пользователем
SGLang	Частичная поддержка	Нет (ожидается upstream)	Задается пользователем
TensorRT-LLM	Частичная поддержка	Нет (ожидается upstream)	Задается пользователем

Чтобы включить compilation cache, добавьте volume mount с useAsCompilationCache: true в спецификацию компонента. Для vLLM operator автоматически настроит необходимые переменные окружения. Для других backend будут созданы volume mount, но до появления поддержки upstream может потребоваться дополнительная настройка окружения.

Следующие шаги

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

SGLang: examples/backends/sglang/deploy/
TensorRT-LLM: examples/backends/trtllm/deploy/
vLLM: examples/backends/vllm/deploy/

Эти примеры демонстрируют правильное использование секции multinode с соответствующими ограничениями gpu и корректной настройкой tp-size.

Обзор​

Базовые требования​

Продвинутая оркестрация многоузловых развертываний​

Использование Grove (по умолчанию)​

Предварительные требования​

Использование LWS и Volcano​

Основные понятия​

Алгоритм выбора orchestrator​

Когда доступны и Grove, и LWS:​

Когда доступен только один orchestrator:​

Интеграция scheduler:​

Примеры конфигурации:​

Секция multinode​

Распределение GPU​

Согласование Tensor Parallelism​

Поведение Operator для конкретных backend​

Backend vLLM​

Режимы развертывания​

Почему Ray для многоузлового TP/PP?​

Поддержка Compilation Cache​

Backend SGLang​

Ведущий узел​

Узлы-воркеры​

Backend TensorRT-LLM​

Ведущий узел​

Узлы-воркеры​

Дополнительная конфигурация​

Конфигурация Compilation Cache​

Следующие шаги​

Обзор

Базовые требования

Продвинутая оркестрация многоузловых развертываний

Использование Grove (по умолчанию)

Предварительные требования

Использование LWS и Volcano

Основные понятия

Алгоритм выбора orchestrator

Когда доступны и Grove, и LWS:

Когда доступен только один orchestrator:

Интеграция scheduler:

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

Секция `multinode`

Распределение GPU

Согласование Tensor Parallelism

Поведение Operator для конкретных backend

Backend vLLM

Режимы развертывания

Почему Ray для многоузлового TP/PP?

Поддержка Compilation Cache

Backend SGLang

Ведущий узел

Узлы-воркеры

Backend TensorRT-LLM

Ведущий узел

Узлы-воркеры

Дополнительная конфигурация

Конфигурация Compilation Cache

Следующие шаги