Для чистой Markdown-версии этой страницы добавьте .md к этому URL. Полный индекс документации см. в https://docs.nvidia.com/dynamo/llms.txt. Полное содержимое, включая справочник API и примеры SDK, см. в https://docs.nvidia.com/dynamo/llms-full.txt.

Руководство по развертыванию модели

Это руководство объясняет, как развернуть вашу модель в Dynamo с помощью DynamoGraphDeploymentRequest (DGDR). Если вы уже прошли Быстрый старт и хотите понять, как DGDR работает от начала до конца, как выбрать правильные настройки для вашей модели и как избежать типичных ошибок, это руководство для вас.

Справочник по spec DGDR, описания полей и фазы жизненного цикла см. в Справочнике DGDR.

Что такое DGDR?

DGDR — это Custom Resource Dynamo с подходом deploy-by-intent. Вместо того чтобы вручную собирать spec развертывания с настройками parallelism, количеством реплик и лимитами ресурсов, вы описываете что хотите запустить (модель, backend, SLA-цели), а DGDR автоматизирует остальное:

1. Spec — Вы отправляете DGDR с моделью, ожиданиями по workload и необязательными SLA-целями.
2. Hardware Discovery — operator обнаруживает GPU-оборудование вашего кластера (SKU, VRAM, количество на узел) через DCGM или node labels.
3. Profiling — profiler анализирует вашу модель на обнаруженном оборудовании, используя либо быстрое моделирование, либо тщательный бенчмарк на реальном GPU.
4. Генерация DGD — profiler создает оптимизированный spec DynamoGraphDeployment (DGD) с лучшей стратегией parallelization, количеством реплик и конфигурацией ресурсов.
5. Проверка (когда autoApply: false) — сгенерированный DGD сохраняется в .status.profilingResults.selectedConfig, чтобы вы могли его просмотреть и при необходимости изменить перед развертыванием.
6. Deploy — operator создает DGD, который поднимает inference pod.
7. Planner (необязательно) — если включен, Planner отслеживает живой трафик и корректирует количество реплик во время выполнения, чтобы соблюдать ваши SLA-цели.

┌──────┐    ┌───────────┐    ┌──────────┐    ┌─────────────┐    ┌────────┐    ┌─────────┐
│ Spec │───▶│ Hardware  │───▶│ Profiler │───▶│ Generated   │───▶│ Deploy │───▶│ Planner │
│      │    │ Discovery │    │          │    │ DGD         │    │        │    │ (opt.)  │
└──────┘    └───────────┘    └──────────┘    └─────────────┘    └────────┘    └─────────┘
                                                   │
                                          autoApply: false?
                                             ▼ Проверка

Выбор стратегии поиска

Поле searchStrategy управляет тем, как profiler исследует конфигурации. Ваш выбор зависит от того, сколько времени вы готовы потратить и насколько близко к оптимуму вам нужно.

Быстрая (по умолчанию)

searchStrategy: rapid

Использует моделирование на базе AIC в стиле DynoSim, чтобы искать конфигурации развертывания без запуска реального инференса. Завершается примерно за 30 секунд и не потребляет GPU-ресурсы во время profiling.

Используйте rapid, когда:

• Только начинаете или быстро итеративно вносите изменения
• Запускаете в CI/CD pipeline
• Ваш GPU SKU есть в матрице поддержки AIC

Ограничения:

• Если AIC не поддерживает комбинацию model/hardware/backend, profiler переходит на наивную конфигурацию по памяти (базовый расчет TP), которая может быть не оптимальной.
• Результаты симуляции могут отличаться от производительности на реальном оборудовании для необычных конфигураций.

Тщательная

searchStrategy: thorough
backend: vllm  # must specify a concrete backend

Перебирает возможные конфигурации параллелизации, разворачивает каждую на реальных GPU и бенчмаркит с помощью AIPerf. Занимает 2–4 часа.

Используйте thorough, когда:

• Настраиваете production и вам нужна максимально оптимальная конфигурация
• Ваше оборудование не поддерживается AIC (например, PCIe GPU)
• Вам нужны измеренные, а не симулированные данные производительности

Ограничения:

• Только disaggregated mode — thorough не запускает aggregated-конфигурации.
• backend: auto не поддерживается — нужно указать vllm, sglang или trtllm. DGDR будет отклонен, если использовать auto с thorough.
• Требует GPU-ресурсы — profiler разворачивает реальные inference engine в вашем кластере во время profiling.

Матрица поддержки AIC

Стратегия rapid опирается на модели производительности AIC. Сейчас AIC поддерживает:

GPU SKU

Поддерживается (rapid)	Пока не поддерживается (используйте thorough)
H100 SXM	V100 (SXM/PCIe)
H100 PCIe	T4
H200 SXM	MI200, MI300
A100 SXM
A100 PCIe
A30
B200 SXM
GB200 SXM
L40S
L4

Некоторые SKU в rapid-mode используют только оценочные данные AIC, пока не доступны измеренные профили. Используйте searchStrategy: thorough, когда вам нужно profiling, измеренный на оборудовании, для случаев, где доступна только оценка или неподдерживаемого SKU.

При ручном указании GPU SKU используйте формат в нижнем регистре с подчеркиваниями (например, h100_sxm, а не H100-SXM5-80GB). Полный список см. в Справочник DGDR — формат SKU.

Backend

Все три backend поддерживаются как для rapid, так и для thorough:

Бэкенд	Плотные модели	MoE-модели
vLLM	✅	🚧 В разработке
SGLang	✅	✅
TensorRT-LLM	✅	🚧 В разработке

Если вы разворачиваете Mixture-of-Experts (MoE) модель (например, DeepSeek-R1, Qwen3-MoE), используйте SGLang в качестве backend для полной поддержки. vLLM и TRT-LLM имеют частичную поддержку MoE, которая все еще находится в разработке.

Стратегии параллелизации

Profiler выбирает разные стратегии параллелизации в зависимости от архитектуры модели:

Архитектура модели	Prefill	Decode
MLA+MoE (DeepSeek-V3, DeepSeek-R1)	TEP, DEP	TEP, DEP
GQA+MoE (Qwen3-MoE)	TP, TEP, DEP	TP, TEP, DEP
Плотные модели (Llama, Qwen и т. д.)	TP	TP

Кэширование модели

Настройте кэширование модели до развертывания, если верно хотя бы одно из условий:

• Ваша модель большая (>70B параметров) — загрузка сотен GB на каждый pod занимает часы
• Вы масштабируетесь до большого числа реплик — каждый pod загружает полную модель независимо, а HuggingFace будет ограничивать параллельные загрузки
• Вам нужен быстрый старт pod при событиях масштабирования

Как это работает с DGDR

Добавьте в DGDR spec секцию modelCache, указывающую на предварительно заполненный PVC:

spec:
  model: meta-llama/Llama-3.1-70B-Instruct
  modelCache:
    pvcName: model-cache
    pvcMountPath: /home/dynamo/.cache/huggingface
    pvcModelPath: hub/models--meta-llama--Llama-3.1-70B-Instruct/snapshots/<commit-hash>

operator монтирует этот PVC в pvcMountPath только для чтения в profiling job и передает его в сгенерированный DGD, чтобы и profiling, и serving использовали кэшированные веса.

pvcModelPath должен быть HuggingFace snapshot path внутри PVC — hub/models--<org>--<model>/snapshots/<commit-hash>. Это соответствует layout, который создает huggingface-cli download, когда HF_HOME указывает на mount point. Замените <org>--<model>, подставив вместо / значение -- в model ID, а <commit-hash> — фактической ревизией snapshot. См. Кэширование модели, как узнать hash после загрузки.

Настройка

1. Создайте ReadWriteMany PVC — см. Руководство по установке — общее хранилище для вариантов, зависящих от провайдера (EFS, Azure Lustre, GKE Filestore).
2. Запустите однократный job загрузки, чтобы заполнить PVC.
3. Укажите PVC в поле modelCache вашего DGDR.

Полное пошаговое руководство с YAML-примерами см. в Кэшировании модели.

Private и gated-модели

Для моделей, требующих аутентификацию (например, gated HuggingFace models), создайте Kubernetes Secret с именем hf-token-secret и ключом HF_TOKEN:

kubectl create secret generic hf-token-secret \
  --from-literal=HF_TOKEN=<your-token> \
  -n $NAMESPACE

Profiler и развернутые pod автоматически будут использовать этот токен.

Включение Planner

Planner предоставляет автомасштабирование во время выполнения для disaggregated-развертываний. Он корректирует количество реплик prefill и decode, чтобы соответствовать вашим SLA-целям по мере изменения трафика.

spec:
  features:
    planner:
      enabled: true
  sla:
    ttft: 500    # Target time to first token (ms)
    itl: 50      # Target inter-token latency (ms)

Режимы масштабирования Planner

Режим	Описание	Требуется Prometheus?
throughput (по умолчанию)	Статические пороги глубины очереди и KV-cache; масштабирование по насыщению	Нет
latency	То же, что throughput, но с более агрессивными порогами	Нет
sla	Регрессионные модели для целевых значений TTFT/ITL; используют данные profiling и живые метрики	Да

Требование к Prometheus

Цель оптимизации sla читает живые метрики TTFT/ITL из Prometheus. Если вы хотите автомасштабирование на основе SLA, установите Prometheus до создания DGDR. Инструкции по настройке см. в Руководстве по установке — Prometheus.

Режимы throughput и latency используют внутренние сигналы глубины очереди и работают без Prometheus.

См. Руководство по Planner для расширенной настройки и подробностей поведения масштабирования.

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

Моделям, которым требуется больше GPU, чем дает один узел (например, DeepSeek-R1 на 8-GPU узлах), нужна многоузловая оркестрация.

Grove и KAI Scheduler

Grove требуется для многоузловых DGDR-развертываний. Он обеспечивает gang scheduling (все pod в группе запускаются вместе или не запускаются вовсе), согласованное масштабирование и размещение с учетом сетевой топологии. Operator вернет ошибку, если вы попытаетесь выполнить многоузловое развертывание без Grove или LeaderWorkerSet (LWS).

KAI Scheduler необязателен, но рекомендуется вместе с Grove для планирования с учетом GPU и оптимизации топологии.

См. Руководство по установке — Grove + KAI Scheduler для инструкций по настройке и матрицы совместимости.

Высокоскоростная сеть (RDMA)

Disaggregated serving передает данные KV cache между prefill и decode workers. Понимание сетевого стека помогает диагностировать проблемы производительности:

Уровень	Что это такое
NIXL	Библиотека Dynamo для передачи KV cache. Перемещает данные между prefill и decode pod.
UCX / libfabric	Низкоуровневые фреймворки связи, которые использует NIXL.
RDMA	Remote Direct Memory Access — общий способ передачи данных между машинами без участия CPU.
InfiniBand	Высокоскоростной стандарт сети RDMA. Часто используется on-prem и в Azure (AKS).
RoCE	RDMA over Converged Ethernet — RDMA поверх стандартного Ethernet-оборудования.
EFA	AWS Elastic Fabric Adapter — сеть AWS с поддержкой RDMA для EKS.
GPUDirect RDMA	Позволяет данным напрямую проходить между GPU и сетевым адаптером, полностью обходя память CPU.
NCCL	NVIDIA Collective Communications Library — отвечает за communication внутри модели (TP/PP) внутри pod. Отдельно от NIXL.

Без RDMA NIXL переходит на TCP, что вызывает ~40-кратное падение TTFT (с ~355 мс до 10+ секунд).

Включите RDMA, если:

• Вы запускаете многоузловые disaggregated-развертывания
• Вам нужна низкая задержка передачи KV cache между workers

См. Руководство по установке — Network Operator / RDMA для инструкций по настройке, зависящих от провайдера, а также Руководство по разделенной коммуникации для подробностей о транспорте и ожиданиях по производительности.

Ограничения sweep для MoE-моделей в многоузловых сценариях

Profiler выполняет sweep MoE-моделей максимум по 4 узлам (для плотных моделей: максимум 1 узел на engine во время sweep). Если вашей MoE-модели нужно больше 4 узлов с GPU, profiler выберет лучшую конфигурацию в этих пределах, а вам может потребоваться вручную скорректировать количество реплик.

Выбор бэкенда

Поле backend управляет тем, какой inference engine используется. Значение по умолчанию (auto) позволяет profiler выбрать лучший backend, но в следующих случаях backend лучше указать явно:

Сценарий	Рекомендуемый backend
MoE-модели (DeepSeek-R1, Qwen3-MoE)	sglang (полная поддержка MoE)
Используется searchStrategy: thorough	Любой кроме auto (обязательно)
Кэширование компиляции TensorRT-LLM	trtllm (добавьте PVC для compilation cache)
Нужен load-based planner scaling (FPM)	vllm (любая конфигурация) или trtllm (только non-attention-DP). FPM для SGLang подключен в Dynamo, но upstream module отсутствует в runtime image 1.2.0.

TensorRT-LLM не поддерживает Python 3.11. Если в вашей среде используется Python 3.11, используйте vllm или sglang вместо него.

Поведение бэкенда в многоузловом режиме

Каждый бэкенд по-разному обрабатывает многоузловый inference:

• vLLM: Использует Ray для multi-node TP/PP. Ray head работает на leader, agents — на workers.
• SGLang: Использует флаги --dist-init-addr, --nnodes, --node-rank для распределенной настройки.
• TRT-LLM: Основан на MPI. Operator автоматически генерирует SSH keypairs; leader запускает mpirun.

Типичные проблемы

OOM во время profiling или serving

• Причина: Модель не помещается в GPU-память при выбранном размере TP.
• Исправление: Убедитесь, что hardware.totalGpus достаточно велико для вашей модели. Profiler вычисляет минимальный TP из размера модели и VRAM, но крайние случаи (большая длина контекста, накладные расходы KV cache) могут потребовать больше GPU, чем минимум.

Лимит автоопределения GPU

Operator ограничивает автоматически определенное число GPU значением 32. Если в вашем кластере больше GPU и вы хотите, чтобы profiler использовал их, задайте hardware.totalGpus явно:

spec:
  hardware:
    totalGpus: 64

Не удается запланировать profiling job

У GPU-узлов часто есть taints. Добавьте tolerations через поле overrides:

spec:
  overrides:
    profilingJob:
      template:
        spec:
          containers: []    # обязательный placeholder
          tolerations:
            - key: nvidia.com/gpu
              operator: Exists
              effect: NoSchedule

Spec DGDR неизменяем

Когда DGDR входит в фазу Profiling, spec уже нельзя изменить. Если вам нужно скорректировать настройки, удалите DGDR и создайте его заново:

kubectl delete dgdr my-model -n $NAMESPACE
kubectl apply -f updated-dgdr.yaml -n $NAMESPACE

DGD остается после удаления DGDR

Удаление DGDR не удаляет созданный им DGD. Это сделано намеренно — DGD продолжает обслуживать трафик независимо. Чтобы убрать все полностью:

kubectl delete dgdr my-model -n $NAMESPACE
kubectl delete dgd my-model-dgd -n $NAMESPACE

В целом: примеры рабочих сценариев

Небольшая плотная модель (быстрый старт)

Небольшая модель на одном узле с rapid profiling — самый простой случай:

apiVersion: nvidia.com/v1beta1
kind: DynamoGraphDeploymentRequest
metadata:
  name: qwen-small
spec:
  model: Qwen/Qwen3-0.6B

Большая плотная модель с SLA-целями

Модель на 70B с кэшированием модели, SLA-целями и включенным Planner:

apiVersion: nvidia.com/v1beta1
kind: DynamoGraphDeploymentRequest
metadata:
  name: llama-70b
spec:
  model: meta-llama/Llama-3.1-70B-Instruct
  backend: vllm
  searchStrategy: rapid
  autoApply: false
  modelCache:
    pvcName: model-cache
    pvcMountPath: /home/dynamo/.cache/huggingface
    pvcModelPath: hub/models--meta-llama--Llama-3.1-70B-Instruct/snapshots/<commit-hash>
  sla:
    ttft: 500
    itl: 50
  workload:
    isl: 4000
    osl: 1000
    requestRate: 10
  features:
    planner:
      enabled: true

MoE-модель (DeepSeek-R1)

Большая MoE-модель, которой требуется многоузловое развертывание, backend SGLang и thorough profiling:

apiVersion: nvidia.com/v1beta1
kind: DynamoGraphDeploymentRequest
metadata:
  name: deepseek-r1
spec:
  model: deepseek-ai/DeepSeek-R1
  backend: sglang
  searchStrategy: thorough
  autoApply: false
  modelCache:
    pvcName: model-cache
    pvcMountPath: /home/dynamo/.cache/huggingface
    pvcModelPath: hub/models--deepseek-ai--DeepSeek-R1/snapshots/<commit-hash>
  sla:
    ttft: 2000
    itl: 100
  hardware:
    totalGpus: 32
  features:
    planner:
      enabled: true
  overrides:
    profilingJob:
      template:
        spec:
          containers: []
          tolerations:
            - key: nvidia.com/gpu
              operator: Exists
              effect: NoSchedule

Предварительные требования для этого развертывания:

• Grove и KAI Scheduler установлены
• RDMA настроен для эффективной передачи KV cache
• Модель кэшируется на общем PVC
• Prometheus установлен (для масштабирования Planner на основе SLA)

Дополнительные материалы

• Справочник DGDR — Справочник по spec, фазы жизненного цикла, команды мониторинга
• Примеры DGDR — Готовый YAML для разных сценариев
• Руководство по Profiler — Алгоритмы profiling, выбор режимов, gate checks
• Руководство по Planner — Режимы масштабирования, справочник PlannerConfig
• Кэширование модели — Настройка PVC, ModelExpress и ModelStreamer
• Создание развертываний — Ручной DGD spec для настроенных вручную конфигураций
• Многоузловые развертывания — Подробности Grove, LWS и multi-node
• Разделенная коммуникация — NIXL, RDMA и сеть