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.

Руководство по Profiler

Обзор

Profiler Dynamo анализирует производительность инференса модели и генерирует оптимизированные конфигурации развертывания (DynamoGraphDeployment). Имея модель, железо и целевые SLA, он определяет лучшую стратегию параллелизации, выбирает оптимальные конфигурации движков prefill и decode и выдает готовый к развертыванию DGD YAML.

Profiler принимает на вход DynamoGraphDeploymentRequestSpec (DGDR) и использует AI Configurator (AIC) для моделирования производительности, перебора кандидатов и выбора конфигурации. Когда включен planner, profiler дополнительно генерирует кривые интерполяции движка, которые используются для autoscaling во время выполнения.

Рабочий процесс

• Что вы хотите развернуть (model)
• Как это должно работать (цели SLA: sla.ttft, sla.itl)
• Где это должно выполняться (необязательные предпочтения по GPU через hardware)
• Какой backend использовать (backend: auto, vllm, sglang или trtllm)
• Какой образ использовать (image)

Profiler проходит по следующему конвейеру:

flowchart TD
    Input["DGDR Spec"] --> Validate["Validate + Gate Checks"]
    Validate --> Strategy{searchStrategy?}

    Strategy -->|rapid| AICCheck{"AIC supports\nmodel/hw/backend?"}
    Strategy -->|thorough| Enumerate["Enumerate candidates\nvia AIC"]

    AICCheck -->|yes| Simulate["AIC Simulation\n+ Picking"]
    AICCheck -->|no| Naive["Naive Config\nGeneration"]

    Enumerate --> Deploy["Deploy + Benchmark\neach candidate"]
    Deploy --> Pick["AIC Picking"]

    Simulate --> DGDGen["DGD Generation"]
    Pick --> DGDGen
    Naive --> DGDGen

    DGDGen --> Interpolation["Interpolation\nCurves"]

    Interpolation --> MockerCheck{mocker?}
    MockerCheck -->|yes| MockerBase["generate_mocker_config()"]
    MockerCheck -->|no| PlannerCheck
    MockerBase --> PlannerCheck{planner?}
    PlannerCheck -->|yes| AddPlanner["add_planner_to_config()"]
    PlannerCheck -->|no| ProfileCheck
    AddPlanner --> ProfileCheck{"needs profile data?\n(thorough mocker or\nthorough throughput planner)"}
    ProfileCheck -->|yes| AddProfile["add_profile_data_to_config()"]
    ProfileCheck -->|no| Final
    AddProfile --> Final["final_config.yaml"]

Пошаговый разбор

1. Проверка: DGDR проходит валидацию — проверяются обязательные поля (image, hardware.gpuSku, hardware.numGpusPerNode), цели SLA и применяется набор gate checks (см. Проверки и ограничения).

2. Стратегия поиска: Profiler выбирает ветку в зависимости от searchStrategy:

   • Rapid: Использует симуляцию AIC для оценки производительности для разных конфигураций параллелизации. GPU не нужны, выполнение занимает около 30 секунд.
   • Thorough: Перебирает кандидатов на конфигурации параллелизации через AIC, разворачивает каждый на реальных GPU, бенчмаркает через AIPerf, а затем выбирает лучший. Занимает 2-4 часа, поддерживается только режим disagg.

3. Выбор: Profiler выбирает лучшую конфигурацию, используя один из трех режимов, автоматически определяемых по спецификации DGDR (см. Режимы выбора).

4. Генерация DGD: Выбранная конфигурация рендерится в полный DGD YAML через конвейер генератора AIC, включая корректную параллелизацию, количество реплик, контейнерный образ и монтирование PVC.

5. Интерполяция (planner/mocker по пропускной способности): Когда planner или mocker нужны данные о пропускной способности, profiler генерирует подробные кривые интерполяции производительности — TTFT от ISL для prefill и ITL от загрузки KV cache для decode. При thorough sweeping они сохраняются как NPZ-файлы и позже упаковываются в ConfigMap на этапе финальной сборки. При rapid sweeping вместо этого используются флаги модели производительности AIC или встроенная интерполяция, поэтому ConfigMap с profile data не создается.

6. Финальная сборка (3 компонуемых слоя):

   1. База mocker: Если включен mocker, базовый DGD заменяется шаблоном DGD для mocker (generate_mocker_config). Иначе сохраняется выбранный AIC DGD.
   2. Сервис planner: Если включен planner, в DGD добавляются pod Planner и его ConfigMap с конфигурацией planner (add_planner_to_config).
   3. Данные профиля: При thorough sweeping, если включен mocker или включено масштабирование planner по пропускной способности, создается ConfigMap с данными интерполяции и монтируется во все потребители — сервис Planner и/или worker'ы mocker (add_profile_data_to_config). Rapid sweeping этот ConfigMap не создает.

   Результат записывается в final_config.yaml.

Стратегии поиска

Быстрый режим

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

searchStrategy: rapid

• Поддерживает все backend: vLLM, SGLang, TensorRT-LLM
• Если сочетание model/hardware/backend не поддерживается AIC, выполняется откат к наивной конфигурации (расчет TP по fit в память)
• Во время профилирования не потребляются ресурсы GPU

Тщательный режим

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

searchStrategy: thorough

• Поддерживается только disaggregated mode
• Не поддерживает backend auto — укажите vllm, sglang или trtllm
• Занимает 2-4 часа в зависимости от числа кандидатов
• Дает наивысшую точность, так как измерения снимаются с реального железа

Режимы выбора

Profiler автоматически выбирает режим подбора на основе спецификации DGDR:

Автомасштабирование

Включается, когда planner включен (масштабирование включено в features.planner). Выбирает движки prefill и decode независимо, у каждого по 1 реплике. Масштабированием во время выполнения занимается planner.

Сопоставление нагрузки

Включается, когда задана целевая нагрузка (workload.requestRate или workload.concurrency). Находит конфигурацию, которая обслуживает целевую нагрузку с минимальным количеством GPU и при этом укладывается в SLA.

workload:
  requestRate: 5.0   # target 5 req/s

По умолчанию

Включается, когда нет planner и нет целевой нагрузки. Максимизирует пропускную способность при доступном бюджете GPU и соблюдении SLA.

Интеграция Planner

Когда planner включен, profiler генерирует данные интерполяции движка, необходимые для autoscaling по пропускной способности. Поле pre_deployment_sweeping_mode управляет тем, как эти данные создаются:

features:
  planner:
    optimization_target: sla              # required for throughput-based scaling and specific SLA targets
    pre_deployment_sweeping_mode: rapid   # rapid | thorough | none
    enable_throughput_scaling: true

optimization_target должен быть равен sla, чтобы enable_throughput_scaling и SLA-цели planner ttft_ms/itl_ms начали действовать. Значение PlannerConfig по умолчанию — throughput, которое использует статические пороги очереди/утилизации: оно молча переключает enable_throughput_scaling в false (поэтому pre-deployment profiling пропускается и planner-profile-data-XXXX не создается) и игнорирует любые значения features.planner.ttft_ms/itl_ms. На enable_load_scaling это не влияет (easy-mode оставляет load scaling включенным). Полное объяснение каждого значения optimization_target см. в руководстве по Planner.

• rapid: Использует симуляцию AIC для генерации кривых интерполяции (~30s, без GPU). Потребители используют флаги модели производительности AIC или встроенную интерполяцию, поэтому planner-profile-data-XXXX не создается.
• thorough: Разворачивает выбранную конфигурацию движка на реальных GPU и прогоняет sweep по диапазонам ISL/concurrency (2-4h). Когда нужны данные профиля, profiler упаковывает их в planner-profile-data-XXXX.
• none: Пропускает интерполяцию. Допустим только при использовании масштабирования по нагрузке без масштабирования по пропускной способности.

Сгенерированный DGD может включать такие ConfigMap:

• planner-config-XXXX: сериализованный JSON PlannerConfig (с profile_results_dir, указывающим на mount с данными профилирования)
• planner-profile-data-XXXX: данные интерполяции prefill и decode (JSON). Создается только когда pre_deployment_sweeping_mode: thorough и либо optimization_target: sla задан вместе с enable_throughput_scaling: true, либо включен mocker. Rapid mode этот ConfigMap не создает.

Полный справочник PlannerConfig см. в руководстве по Planner.

Мокер

Когда features.mocker.enabled: true, profiler выводит DGD для mocker, который имитирует поведение движка без реальных GPU. Это полезно для тестирования поведения planner и проверки конфигураций в масштабе.

Для mocker требуется pre-deployment sweeping, чтобы сгенерировать симулированные профили производительности — pre_deployment_sweeping_mode не может быть none, когда включен mocker.

Проверки и ограничения

Profiler применяет эти правила при запуске:

Условие	Поведение
searchStrategy: thorough + backend: auto	Отклоняется. Укажите конкретный backend.
enable_throughput_scaling: true без optimization_target: sla	Молча приводится к другому значению. PlannerConfig по умолчанию задает optimization_target как throughput, что переключает enable_throughput_scaling в false на этапе валидации. Явно укажите optimization_target: sla, чтобы оставить включенным масштабирование по пропускной способности.
enable_throughput_scaling: true + pre_deployment_sweeping_mode: none (или не задано)	Отклоняется. Масштабирование по пропускной способности требует pre-deployment sweeping.
enable_throughput_scaling: true + pre_deployment_sweeping_mode: rapid + AIC не поддерживается	Отклоняется. AIC не поддерживает это сочетание model/hardware/backend; переключите pre_deployment_sweeping_mode на thorough.
e2eLatency задан вместе с явно указанным ttft или itl	Отклоняется валидатором SLA. Укажите только e2eLatency; ttft и itl не нужно явно обнулять.
SLA недостижим	Записывается предупреждение, SLA обновляется до лучшего достижимого значения.
Для load-match требуется больше GPU, чем доступно	Записывается предупреждение.

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

Backend	Плотные модели	MoE-модели
vLLM	✅	🚧
SGLang	✅	✅
TensorRT-LLM	✅	🚧

Profiler выполняет sweep по следующим отображениям параллелизации для prefill и decode:

Архитектура модели	Отображение параллелизации для prefill	Отображение параллелизации для decode
MLA+MoE (DeepseekV3ForCausalLM, DeepseekV32ForCausalLM)	TEP, DEP	TEP, DEP
GQA+MoE (Qwen3MoeForCausalLM)	TP, TEP, DEP	TP, TEP, DEP
Other Models	TP	TP

Точная поддержка сочетания model x parallelization mapping зависит от backend. Profiler не гарантирует, что рекомендуемая конфигурация движков P/D поддерживается backend и не содержит ошибок.

Развертывание

Развертывание в Kubernetes (DGDR)

Рекомендуемый способ развертывания — через DGDR. Полные примеры DGDR YAML для случаев rapid, thorough, MoE, пользовательских SLA и overrides см. в Примерах Profiler.

Контейнерные образы

Каждый DGDR требует контейнерный образ для профилирования и развертывания:

• image (необязательно): контейнерный образ для profiling job. Он должен содержать код profiler и его зависимости.

spec:
  image: "nvcr.io/nvidia/ai-dynamo/dynamo-planner:1.2.0"  # dynamo-frontend for Dynamo < 1.1.0

Быстрый старт: развертывание через DGDR

Шаг 1: Создайте свой DGDR

Используйте пример конфигурации или создайте свой:

apiVersion: nvidia.com/v1beta1
kind: DynamoGraphDeploymentRequest
metadata:
  name: my-model-profiling
spec:
  model: "Qwen/Qwen3-0.6B"
  backend: vllm
  image: "nvcr.io/nvidia/ai-dynamo/dynamo-planner:1.2.0"  # dynamo-frontend for Dynamo < 1.1.0

Шаг 2: Примените DGDR

export NAMESPACE=your-namespace
kubectl apply -f my-profiling-dgdr.yaml -n $NAMESPACE

Шаг 3: Отслеживайте прогресс

# View status
kubectl get dgdr -n $NAMESPACE

# Detailed status
kubectl describe dgdr my-model-profiling -n $NAMESPACE

# Watch profiling job logs
kubectl logs -f job/profile-my-model-profiling -n $NAMESPACE

Фазы состояния DGDR:

• Pending: начальное состояние, идет подготовка к профилированию
• Profiling: выполняется profiling job (20-30 секунд для AIC, 2-4 часа для online)
• Ready: профилирование завершено, сгенерированная спецификация DGD доступна в status
• Deploying: идет генерация и применение конфигурации DGD
• Deployed: DGD успешно развернут и работает
• Failed: произошла ошибка (подробности см. в events)

Шаг 4: Получите доступ к своему развертыванию

# Find the frontend service
kubectl get svc -n $NAMESPACE | grep frontend

# Port-forward to access locally
kubectl port-forward svc/<deployment>-frontend 8000:8000 -n $NAMESPACE

# Test the endpoint
curl http://localhost:8000/v1/models

DGDR являются неизменяемыми. Чтобы обновить SLA или конфигурацию, удалите существующий DGDR и создайте новый.

Метод профилирования

Profiler следует процессу из 5 шагов:

1. Настройка железа: Используются значения по умолчанию или заданная пользователем конфигурация hardware. При необходимости операторы кластерного уровня могут включить автоматическое обнаружение GPU, чтобы определить характеристики по узлам кластера.
2. Определение диапазонов sweep: Автоматически определяются минимальное и максимальное число GPU на движок. Минимум задается размером модели и объемом VRAM GPU. Максимум ограничен одним узлом для плотных моделей и 4 узлами для MoE-моделей.
3. Sweep отображений параллелизации: Проверяется производительность движков с разными отображениями параллелизации с использованием входных ISL и OSL.
   • Для плотных моделей тестируются разные размеры TP как для prefill, так и для decode.
   • Для MoE-моделей (SGLang) оцениваются TEP и DEP как кандидаты для prefill и decode.
   • Prefill:
     • TP/TEP: измеряется TTFT при batch size = 1 (при условии, что ISL достаточно длинный, чтобы загрузить вычисления) без KV reuse.
     • DEP: attention использует data parallelism. Отправляется один burst с общей concurrency attention_dp_size × attn_dp_num_req_ratio (по умолчанию 4), а сообщаемый TTFT вычисляется как time_to_first_token.max / attn_dp_num_req_ratio из сводки AIPerf для этого burst.
   • Decode: Измеряется ITL при разном числе запросов in-flight, от 1 до максимума, который может удержать KV cache. Чтобы измерять ITL без влияния дополнительных prefill-запросов, скрипт включает KV-reuse и прогревает движок, отправляя те же самые prompts перед измерением.
4. Рекомендация: Выбирается оптимальное отображение параллелизации для prefill и decode, которое дает наибольшую пропускную способность на GPU при соблюдении SLA по TTFT и ITL.
5. Глубокое профилирование на рекомендованном P/D-движке: Выполняется интерполяция TTFT по ISL и ITL по активному KV cache и длине decode context для более точной оценки производительности.
   • Prefill: Измеряет TTFT и throughput на GPU для разных длин входа при batch size=1.
   • Decode: Измеряет ITL и throughput на GPU при разных нагрузках KV cache и длинах decode context.

AIPerf на реальных движках

Профилирует вашу модель, создавая реальные тестовые развертывания в Kubernetes и измеряя их производительность.

• Длительность: 2-4 часа
• Точность: максимальная (реальные измерения)
• Требования к GPU: полный доступ для тестирования разных отображений параллелизации
• Backend: vLLM, SGLang, TensorRT-LLM

Профилирование на базе AIPerf используется по умолчанию. Используйте searchStrategy: thorough для полного профилирования на реальных движках:

spec:
  searchStrategy: thorough  # Deep exploration with real engine profiling

Симуляция AI Configurator

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

• Длительность: 20-30 секунд
• Точность: оценочная (может ошибаться на необычных конфигурациях)
• Требования к GPU: нет
• Backend: все (vLLM, SGLang, TensorRT-LLM)

AI Configurator используется по умолчанию при searchStrategy: rapid:

spec:
  searchStrategy: rapid  # Fast profiling with AI Configurator simulation (default)

aicBackendVersion задает версию TensorRT-LLM, которую симулирует AI Configurator. Доступные версии см. в поддерживаемых возможностях AI Configurator.

Сейчас поддерживает:

• Backend: vLLM, SGLang, TensorRT-LLM
• Системы: H100 SXM, H200 SXM, B200 SXM, GB200 SXM, A100 SXM
• Модели: широкий спектр, включая GPT, Llama, Mixtral, DeepSeek, Qwen и другие

Полный список см. в документации AI Configurator.

Автоматическое обнаружение GPU

Оператор автоматически обнаруживает ресурсы GPU на узлах кластера, предоставляя сведения о hardware (модель GPU, VRAM, GPU на узел) и автоматически рассчитывая пространство поиска для профилирования.

Requirements:

• Cluster-scoped operators (рекомендуется): по умолчанию имеют права на чтение узлов. Обнаружение GPU работает автоматически.

УСТАРЕЛО: Следующее относится только к операторам с ограничением по namespace, которые устарели и будут удалены в будущем выпуске. Для новых развертываний используйте общекластерный режим.

• Namespace-scoped operators (устарело): обнаружение GPU включено по умолчанию при установке через Helm — chart автоматически создает нужные ClusterRole/ClusterRoleBinding

Для операторов с ограничением по namespace (устарело) обнаружение GPU управляется значением Helm:

# Обнаружение GPU включено (по умолчанию) — Helm автоматически предоставляет доступ только для чтения к узлам
helm install dynamo-platform ... --set dynamo-operator.gpuDiscovery.enabled=true

# Обнаружение GPU отключено — вы должны вручную задавать hardware config в каждом DGDR
helm install dynamo-platform ... --set dynamo-operator.gpuDiscovery.enabled=false

Если обнаружение GPU отключено, задайте hardware config вручную в DGDR:

spec:
  hardware:
    numGpusPerNode: 8
    gpuSku: h100_sxm
    vramMb: 81920

Если обнаружение GPU отключено и ручной hardware config не задан, DGDR будет отклонен на этапе admission.

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

Структура конфигурации DGDR

Вся конфигурация profiler задается через поля спецификации DGDR v1beta1:

apiVersion: nvidia.com/v1beta1
kind: DynamoGraphDeploymentRequest
metadata:
  name: my-deployment
spec:
  model: "Qwen/Qwen3-0.6B"
  backend: vllm
  image: "nvcr.io/nvidia/ai-dynamo/dynamo-planner:1.2.0"  # dynamo-frontend for Dynamo < 1.1.0

  searchStrategy: rapid  # or thorough
  autoApply: true

  workload: { ... }
  sla: { ... }
  hardware: { ... }
  features: { ... }
  overrides: { ... }

Конфигурация SLA (необязательно)

workload:
  isl: 3000      # Average input sequence length (tokens)
  osl: 150       # Average output sequence length (tokens)

sla:
  ttft: 200.0    # Target Time To First Token (milliseconds)
  itl: 20.0      # Target Inter-Token Latency (milliseconds)

• ISL/OSL: на основе ожидаемых шаблонов трафика
• TTFT: целевая задержка до первого токена (чем ниже, тем больше нужно GPU, влияет на prefill engine)
• ITL: целевая задержка генерации токенов (чем ниже, тем больше нужно GPU, влияет на decode engine)
• Компромиссы: более жесткие SLA требуют больше ресурсов GPU

Конфигурация hardware (необязательно)

hardware:
  gpuSku: h200_sxm            # GPU SKU identifier (auto-detected)
  vramMb: 81920               # VRAM per GPU in MiB
  totalGpus: 16               # Total GPUs available in the cluster
  numGpusPerNode: 8           # GPUs per node (for multi-node MoE)

• numGpusPerNode: определяет верхнюю границу числа GPU на узел для плотных моделей и настраивает Grove для многоузловых MoE-движков
• gpuSku: идентификатор GPU SKU, автоматически определяется контроллером

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

Стратегия поиска (необязательно)

Управляет глубиной поиска при профилировании:

spec:
  searchStrategy: rapid   # "rapid" (default) for fast sweep; "thorough" for deeper exploration

• rapid: выполняет быстрый sweep по отображениям параллелизации (по умолчанию)
• thorough: исследует больше конфигураций для потенциально лучших результатов

Конфигурация Planner (необязательно)

Передавайте аргументы в SLA planner через секцию features:

features:
  planner:
    planner_min_endpoint: 2                    # Minimum endpoints to maintain
    planner_adjustment_interval: 60            # Adjustment interval (seconds)
    planner_load_predictor: linear             # Load prediction method

Аргументы Planner используют префикс planner_. Полный список см. в документации SLA Planner.

PVC для Model Cache (для продвинутых сценариев)

Для больших моделей используйте заранее заполненный PVC с весами модели вместо загрузки из HuggingFace:

modelCache:
  pvcName: "model-cache"
  pvcModelPath: "hub/models--deepseek-ai--DeepSeek-R1"
  pvcMountPath: "/opt/model-cache"

Требования:

• PVC должен существовать в том же namespace, что и DGDR
• Веса модели должны быть доступны по пути {mountPath}/{pvcPath}

Конфигурация движка (автоматически настраивается)

Контроллер автоматически настраивает model и backend на основе полей верхнего уровня:

# Вы указываете:
spec:
  model: "Qwen/Qwen3-0.6B"
  backend: vllm

# Контроллер автоматически внедряет это в profiling job

Не следует вручную задавать model или backend в overrides для profiling config.

Использование существующих DGD-конфигов

Передайте базовый DGD-конфиг через секцию overrides:

overrides:
  dgd:
    apiVersion: nvidia.com/v1alpha1
    kind: DynamoGraphDeployment
    metadata:
      name: my-dgd
    spec:
      # ... your base DGD spec

Profiler использует DGD-конфиг как базовый шаблон, а затем оптимизирует его в соответствии с вашими SLA.

Интеграция

С SLA Planner

Profiler генерирует данные интерполяции, которые SLA Planner использует для решений об autoscaling.

Интерполяция Prefill (selected_prefill_interpolation/raw_data.npz):

• prefill_isl: одномерный массив протестированных длин входной последовательности
• prefill_ttft: одномерный массив TTFT (ms) для каждого ISL
• prefill_thpt_per_gpu: одномерный массив throughput (tokens/s/GPU) для каждого ISL

Интерполяция Decode (selected_decode_interpolation/raw_data.npz):

• max_kv_tokens: общая емкость KV tokens в decode engine
• x_kv_usage: одномерный массив активного использования KV в процентах [0, 1]
• y_context_length: одномерный массив проверенных средних длин context
• z_itl: одномерный массив ITL (ms) в каждой точке (KV usage, context length)
• z_thpt_per_gpu: одномерный массив throughput (tokens/s/GPU) в каждой точке

С Dynamo Operator

При использовании DGDR оператор Dynamo:

1. Автоматически создает profiling job
2. Сохраняет вывод profiler в ConfigMap (dgdr-output-<name> и, когда нужны данные thorough profile, planner-profile-data)
3. Генерирует оптимизированные конфигурации DGD
4. Развертывает DGD с интеграцией SLA Planner

Обработка ошибок

Сбой profiling job не повторяется на уровне Kubernetes Job (backoffLimit: 0). Большинство ошибок profiler — сбои валидации, неподдерживаемые сочетания model/hardware, отсутствующие configs — детерминированы и никогда не исправятся при повторной попытке, поэтому перезапуск полного цикла профилирования только зря потратит время GPU.

Когда profiler сообщает о сбое, sidecar output-copier записывает детали ошибки (phase, сообщение об ошибке, status profiler) в output ConfigMap и завершает работу успешно. Контроллер DGDR читает сбой из ConfigMap и переводит DGDR напрямую в фазу Failed с конкретной причиной сбоя на подэтапе (например, SweepingDecodeFailed, GeneratingDGDFailed). Используйте kubectl describe dgdr <name>, чтобы увидеть детали сбоя в conditions.

Сгенерированный DGD отслеживается через labels:

metadata:
  labels:
    dgdr.nvidia.com/name: my-deployment
    dgdr.nvidia.com/namespace: your-namespace

С Observability

Отслеживайте profiling job:

kubectl logs -f job/profile-<dgdr-name> -n $NAMESPACE
kubectl describe dgdr <name> -n $NAMESPACE

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

Ручное управление развертыванием

Отключите auto-deployment, чтобы просмотреть сгенерированный DGD перед применением:

spec:
  autoApply: false

Затем вручную извлеките и примените:

# Извлечь сгенерированный DGD из status DGDR
kubectl get dgdr my-deployment -n $NAMESPACE -o jsonpath='{.status.profilingResults.selectedConfig}' | kubectl apply -f -

# Или сохранить в файл для просмотра
kubectl get dgdr my-deployment -n $NAMESPACE -o jsonpath='{.status.profilingResults.selectedConfig}' > my-dgd.yaml

Развертывание Mocker

Разверните mocker deployment, который имитирует движки без GPU:

spec:
  model: <model-name>
  backend: trtllm
  features:
    mocker:
      enabled: true    # Deploy mocker instead of real backend
  autoApply: true

При thorough sweeping профилирование все равно выполняется на реальном backend, чтобы собрать данные производительности, и сохраняет их в planner-profile-data. При rapid sweeping mocker использует флаги модели производительности AIC вместо ConfigMap с profile data. Это полезно для крупномасштабных экспериментов, проверки поведения Planner и валидации конфигураций.

Доступ к артефактам профилирования

По умолчанию вывод profiler хранится в ConfigMap. Для подробных артефактов (графики, логи, сырые данные) подключите PVC через overrides:

overrides:
  profilingJob:
    template:
      spec:
        volumes:
        - name: profiling-output
          persistentVolumeClaim:
            claimName: "dynamo-pvc"

ConfigMap:

• dgdr-output-<name>: сгенерированная конфигурация DGD
• planner-profile-data: данные профилирования для потребителей Planner и mocker (JSON). Создается только при thorough sweeping, когда нужны profile data.

PVC artifacts (optional):

• графики производительности (PNG)
• конфигурации DGD для каждого профилированного развертывания
• артефакты профилирования AIPerf
• сырые данные профилирования (.npz files)
• логи profiler

Получение результатов из PVC:

kubectl apply -f deploy/utils/manifests/pvc-access-pod.yaml -n $NAMESPACE
kubectl wait --for=condition=Ready pod/pvc-access-pod -n $NAMESPACE --timeout=60s
kubectl cp $NAMESPACE/pvc-access-pod:/data ./profiling-results
kubectl delete pod pvc-access-pod -n $NAMESPACE

Графики результата производительности

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

Графики sweep отображений параллелизации:

• prefill_performance.png: TTFT от размера отображения параллелизации
• decode_performance.png: ITL от размера отображения параллелизации и числа запросов in-flight

Графики глубокого профилирования:

• selected_prefill_interpolation/prefill_ttft_interpolation.png: TTFT от ISL
• selected_prefill_interpolation/prefill_throughput_interpolation.png: Throughput от ISL
• selected_decode_interpolation/decode_itl_interplation.png: ITL от использования KV и длины context
• selected_decode_interpolation/decode_throughput_interpolation.png: Throughput от использования KV и длины context

Runtime-профилирование (SGLang)

Worker'ы SGLang предоставляют profiling endpoints для анализа производительности во время выполнения:

# Start profiling
curl -X POST http://localhost:9090/engine/start_profile \
  -H "Content-Type: application/json" \
  -d '{"output_dir": "/tmp/profiler_output"}'

# Выполните inference-запросы...

# Stop profiling
curl -X POST http://localhost:9090/engine/stop_profile

Просматривайте трассировки в chrome://tracing Chrome, Perfetto UI или TensorBoard.

Устранение неполадок

SLA недостижим

Profiler пишет предупреждение и обновляет SLA до лучшего достижимого значения. Чтобы улучшить результаты:

• Ослабьте цели SLA (увеличьте TTFT/ITL)
• Добавьте больше ресурсов GPU
• Попробуйте другой backend
• Используйте меньшую или квантованную модель

Профилирование занимает слишком много времени

• Используйте searchStrategy: rapid для профилирования примерно за 30 секунд
• Уменьшите детализацию интерполяции
• Сократите пространство поиска GPU через ограничения hardware

Не хватает памяти во время профилирования

• Уменьшите max_batch_size в конфигурации движка
• Пропустите более крупные конфигурации TP, ограничив hardware
• Используйте квантованную версию модели

Ошибки Image Pull

Убедитесь, что image pull secret настроены в вашем namespace для container registry.

См. также

• README Profiler — краткий обзор и матрица возможностей
• Примеры Profiler — полные примеры DGDR YAML
• Руководство по Planner — справочник PlannerConfig и режимы масштабирования
• Справочник API DGDR — полная спецификация DGDR