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

Бенчмаркинг Dynamo

В этом руководстве показано, как проводить бенчмаркинг развертываний Dynamo с помощью AIPerf — полноценного инструмента для измерения производительности inference для generative AI. AIPerf предоставляет подробные метрики, панели мониторинга в реальном времени и автоматическую визуализацию — вы запускаете его напрямую против своих точек доступа.

Вы можете проводить бенчмаркинг любой комбинации:

• DynamoGraphDeployments
• Внешние HTTP-точки доступа (vLLM, llm-d, AIBrix и т. д.)

Выбор подхода к бенчмаркингу

Клиентский режим запускает бенчмарки на вашей локальной машине через port-forwarding. Серверный режим запускает бенчмарки напрямую внутри Kubernetes-кластера, используя внутренние URL сервисов.

Если кратко: Нужны высокая производительность и нагрузочное тестирование? Серверный режим. Нужна быстрая проверка или сравнение? Клиентский режим.

Используйте клиентский бенчмаркинг, когда:

• Вы хотите быстро проверить развертывания
• Вы хотите сразу получить доступ к результатам на локальной машине
• Вы сравниваете внешние services или развертывания (не обязательно только Dynamo)
• Вам нужно запускать бенчмарки с ноутбука или рабочей станции

→ Перейти к бенчмаркингу на клиенте (локально)

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

• У вас есть среда разработки с доступом к kubectl
• Вы проводите проверку производительности с высокими требованиями к нагрузке и скорости
• Вы сталкиваетесь с тайм-аутами или проблемами производительности при клиентском бенчмаркинге
• Вам нужна оптимальная сетевая производительность без накладных расходов от port-forwarding
• Вы запускаете автоматизированные конвейеры CI/CD
• Вам нужны изолированные среды выполнения
• Вам нужно постоянное хранение результатов в кластере

→ Перейти к серверному бенчмаркингу (в кластере)

Краткое сравнение

Возможность	Клиентский режим	Серверный режим
Расположение	Ваша локальная машина	кластер Kubernetes
Сеть	Требуется port-forwarding	Прямой DNS сервиса
Настройка	Быстро и просто	Требует ресурсов кластера
Производительность	Ограничена локальными ресурсами, может завершаться по timeout при высокой нагрузке	Оптимальная производительность кластера, выдерживает высокую нагрузку
Изоляция	Общая среда	Изолированное выполнение job
Результаты	Локальная файловая система	Persistent volumes
Лучше всего подходит для	Низкой нагрузки	Высокой нагрузки

Обзор AIPerf

AIPerf — это отдельный инструмент для бенчмаркинга, доступный в PyPI. Он предустановлен в контейнерных образах Dynamo. Основные возможности:

• Измеряет задержку, пропускную способность, TTFT, межтокенную задержку и многое другое
• Несколько режимов нагрузки: concurrency, request-rate, воспроизведение трасс
• Автоматическая визуализация с помощью aiperf plot (кривые Парето, временные ряды, телеметрия GPU)
• Интерактивный режим панели мониторинга для исследования в реальном времени
• Паттерны поступления (Poisson, constant, gamma) для реалистичной симуляции трафика
• Фазы прогрева, постепенное наращивание и балансировка нагрузки по нескольким URL

Важно: Параметр --model должен совпадать с моделью, развернутой на endpoint.

Полную документацию см. в документации AIPerf.

---

Бенчмаркинг на клиенте (локально)

Клиентский бенчмаркинг выполняется на вашей локальной машине и подключается к Kubernetes-развертываниям через port-forwarding.

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

1. Окружение Dynamo в контейнере - вы должны работать внутри Dynamo container с предустановленным AIPerf или установить его локально:

   pip install aiperf

2. HTTP-точки доступа - убедитесь, что у вас есть HTTP-точки доступа для бенчмаркинга. Это могут быть:

   • DynamoGraphDeployments, доступные через HTTP-точки доступа
   • Внешние сервисы (vLLM, llm-d, AIBrix и т. д.)
   • Любая HTTP-точка доступа, обслуживающая модели, совместимые с OpenAI

Сценарий работы

Шаг 1: Подготовьте кластер и разверните сервис

Настройте кластер Kubernetes с NVIDIA GPU и установите Dynamo Kubernetes Platform, следуя руководству по установке. Затем разверните свои DynamoGraphDeployments, используя документацию по развертыванию.

Шаг 2: Выполните port-forward и запустите один бенчмарк

Дождитесь готовности модели. Перед бенчмаркингом убедитесь, что развертывание полностью загрузило модель. Проверьте логи pod или вызовите health endpoint (curl http://localhost:8000/health) — перед продолжением он должен возвращать 200 OK.

# Port-forward the frontend service
kubectl port-forward -n <namespace> svc/<frontend-service-name> 8000:8000 > /dev/null 2>&1 &

# Run a single benchmark
aiperf profile \
    --model <your-model-name> \
    --url http://localhost:8000 \
    --endpoint-type chat \
    --streaming \
    --concurrency 10 \
    --request-count 100 \
    --synthetic-input-tokens-mean 2000 \
    --output-tokens-mean 256

В результате данные попадут в artifacts/, а в консоль будет выведена сводная таблица:

                                NVIDIA AIPerf | LLM Metrics
┏━━━━━━━━━━━━━━━━━━━━━┳━━━━━━━━━┳━━━━━━━━━┳━━━━━━━━━┳━━━━━━━━━┳━━━━━━━━━┳━━━━━━━━━┳━━━━━━━━━┓
┃              Metric ┃     avg ┃     min ┃     max ┃     p99 ┃     p90 ┃     p50 ┃     std ┃
┡━━━━━━━━━━━━━━━━━━━━━╇━━━━━━━━━╇━━━━━━━━━╇━━━━━━━━━╇━━━━━━━━━╇━━━━━━━━━╇━━━━━━━━━╇━━━━━━━━━┩
│ Time to First Token │  234.56 │  189.23 │  298.45 │  289.34 │  267.12 │  231.12 │   28.45 │
│                (ms) │         │         │         │         │         │         │         │
│     Request Latency │ 1234.56 │  987.34 │ 1567.89 │ 1534.23 │ 1456.78 │ 1223.45 │  156.78 │
│                (ms) │         │         │         │         │         │         │         │
│ Inter Token Latency │   15.67 │   12.34 │   19.45 │   19.01 │   18.23 │   15.45 │    1.89 │
│                (ms) │         │         │         │         │         │         │         │
│  Request Throughput │   31.45 │     N/A │     N/A │     N/A │     N/A │     N/A │     N/A │
│      (requests/sec) │         │         │         │         │         │         │         │
└─────────────────────┴─────────┴─────────┴─────────┴─────────┴─────────┴─────────┴─────────┘

Фактические значения зависят от размера модели, оборудования, batch size и сетевых условий. В клиентский бенчмарк входят накладные расходы от port-forwarding — для точного измерения производительности используйте серверный бенчмаркинг.

Чтобы остановить port-forward после завершения, используйте kill %1 (или kill <PID>).

Шаг 3: свип по concurrency для анализа фронтира Парето

Чтобы понять, как ведет себя развертывание на разных уровнях нагрузки, выполните свип по concurrency. Каждый уровень concurrency отправляет достаточно запросов для устойчивых измерений (max(c*3, 10)):

MODEL="<your-model-name>"
URL="http://localhost:8000"

for c in 1 2 5 10 50 100; do
    aiperf profile \
        --model "$MODEL" \
        --url "$URL" \
        --endpoint-type chat \
        --streaming \
        --concurrency $c \
        --request-count $(( c * 3 > 10 ? c * 3 : 10 )) \
        --synthetic-input-tokens-mean 2000 \
        --output-tokens-mean 256 \
        --artifact-dir "artifacts/deployment-a/c$c"
done

Примечание: Подбирайте уровни concurrency в соответствии с возможностями развертывания. Очень высокая concurrency на небольшом развертывании (например, c250 на одной GPU) приведет к ошибкам сервера. Начните с меньших значений и повышайте их, пока не найдете точку насыщения.

Шаг 4: [Если сравниваете] Протестируйте второе развертывание

Удалите deployment A и разверните deployment B с другой конфигурацией. Завершите предыдущий port-forward (kill %1), затем повторите:

kubectl port-forward -n <namespace> svc/<frontend-service-b> 8000:8000 > /dev/null 2>&1 &

for c in 1 2 5 10 50 100; do
    aiperf profile \
        --model "$MODEL" \
        --url "$URL" \
        --endpoint-type chat \
        --streaming \
        --concurrency $c \
        --request-count $(( c * 3 > 10 ? c * 3 : 10 )) \
        --synthetic-input-tokens-mean 2000 \
        --output-tokens-mean 256 \
        --artifact-dir "artifacts/deployment-b/c$c"
done

Шаг 5: Сгенерируйте визуализации

# Сравнить все прогоны — автоматически обнаруживает каталоги с несколькими прогонами
aiperf plot artifacts/deployment-a artifacts/deployment-b

# Или сравнить все подкаталоги внутри родительского каталога
aiperf plot artifacts/

# Запустить интерактивную панель мониторинга для анализа
aiperf plot artifacts/ --dashboard

AIPerf автоматически строит графики на основе доступных данных:

• TTFT vs Throughput — найдите баланс между отзывчивостью и пропускной способностью (всегда создается для сравнений с несколькими запусками)
• Кривые Парето — пропускная способность на GPU против latency и интерактивности (создается только если доступны данные телеметрии GPU — добавьте --gpu-telemetry во время профилирования, если работает DCGM)
• Временные ряды — TTFT, ITL и latency по каждому запросу во времени (создается для анализа одного запуска)

Ниже приведен пример фронтира Парето из свипа по concurrency для Qwen3-0.6B на 8x H200 с vLLM, показывающий компромисс между пользовательским опытом (tokens/sec на пользователя) и эффективностью ресурсов (tokens/sec на GPU):

Подробности по настройке графиков, классификации экспериментов и темам см. в AIPerf Visualization Guide.

Сценарии использования

• Сравнение DynamoGraphDeployments (например, aggregated против disaggregated конфигураций)
• Сравнение разных бэкендов (например, SGLang против TensorRT-LLM против vLLM)
• Сравнение Dynamo и других платформ (например, Dynamo против llm-d против AIBrix)
• Сравнение разных моделей (например, Llama-3-8B против Llama-3-70B против Qwen-3-0.6B)
• Сравнение разных конфигураций оборудования (например, H100 против A100 против H200)
• Сравнение разных стратегий параллелизации (например, разное число GPU или конфигурации памяти)

Краткая справка по AIPerf

Часто используемые параметры

aiperf profile [OPTIONS]

REQUIRED:
  --model MODEL               Model name (must match the deployed model)
  --url URL                   Endpoint URL (e.g., http://localhost:8000)

COMMON OPTIONS:
  --endpoint-type TYPE        Endpoint type: chat, completions, embeddings (default: chat)
  --streaming                 Enable streaming responses
  --concurrency N             Number of concurrent requests
  --request-rate N            Target requests per second (alternative to --concurrency)
  --request-count N           Total number of requests to send
  --benchmark-duration N      Run for N seconds instead of a fixed request count
  --synthetic-input-tokens-mean N   Average input sequence length in tokens
  --output-tokens-mean N      Average output sequence length in tokens
  --artifact-dir DIR          Output directory for results (default: artifacts/)
  --warmup-request-count N    Warmup requests before measurement
  --ui TYPE                   UI mode: dashboard, simple, none (default: dashboard)

Полную справку по CLI см. в aiperf profile --help или в документации CLI.

Длина выходной последовательности

Чтобы задать конкретную длину выхода, передайте ignore_eos и min_tokens через --extra-inputs:

aiperf profile \
    --model <model> \
    --url http://localhost:8000 \
    --endpoint-type chat \
    --streaming \
    --concurrency 10 \
    --output-tokens-mean 256 \
    --extra-inputs max_tokens:256 \
    --extra-inputs min_tokens:256 \
    --extra-inputs ignore_eos:true

Как интерпретировать результаты

Каждый запуск aiperf profile создает каталог артефактов со следующими файлами:

• profile_export_aiperf.json — структурированные метрики (latency, throughput, TTFT, ITL и т. д.)
• profile_export.jsonl — сырые данные по каждому request
• profile_export_aiperf.csv — метрики в формате CSV

Результаты организуются в соответствии с указанным --artifact-dir. Для concurrency sweep обычно используют такой шаблон:

artifacts/
├── deployment-a/
│   ├── c1/
│   │   ├── profile_export_aiperf.json
│   │   └── profile_export.jsonl
│   ├── c10/
│   ├── c50/
│   └── c100/
├── deployment-b/
│   ├── c1/
│   ├── c10/
│   ├── c50/
│   └── c100/
└── plots/                    # Создается командой `aiperf plot`
    ├── ttft_vs_throughput.png
    ├── pareto_curve_throughput_per_gpu_vs_latency.png      # Если доступны данные GPU telemetry
    └── pareto_curve_throughput_per_gpu_vs_interactivity.png # Если доступны данные GPU telemetry

---

Серверный бенчмаркинг (в кластере)

Серверный бенчмаркинг выполняется непосредственно внутри Kubernetes-кластера, убирая накладные расходы от port-forwarding и позволяя проводить нагрузочное тестирование на высокой нагрузке.

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

1. Кластер Kubernetes с NVIDIA GPU и настроенным namespace Dynamo (см. документацию Dynamo Kubernetes Platform)
2. Хранилище: PersistentVolumeClaim, настроенный с нужными permissions (см. deploy/utils README)
3. Docker image с AIPerf (runtime images Dynamo уже включают его)

Быстрый старт

Шаг 1: Разверните свой DynamoGraphDeployment

Разверните его, используя документацию по развертыванию. Убедитесь, что у него опубликован frontend service и модель полностью загружена до запуска бенчмарков — проверьте логи pod или убедитесь, что health endpoint возвращает 200 OK.

Шаг 2: Настройте и запустите job бенчмаркинга

Сначала отредактируйте benchmarks/incluster/benchmark_job.yaml, чтобы он соответствовал вашему развертыванию:

• Model name: обновите переменную MODEL
• Service URL: обновите переменную URL (для доступа между namespace используйте <svc_name>.<namespace>.svc.cluster.local:port)
• Concurrency levels: скорректируйте цикл for c in ...
• Docker image: при необходимости обновите поле image

Затем разверните:

export NAMESPACE=benchmarking

# Развернуть job бенчмаркинга
kubectl apply -f benchmarks/incluster/benchmark_job.yaml -n $NAMESPACE

# Отслеживать job
kubectl logs -f job/dynamo-benchmark -n $NAMESPACE

Шаг 3: Получите результаты

# Создать access pod (пропустите, если он уже запущен)
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/results ./results

# Очистка
kubectl delete pod pvc-access-pod -n $NAMESPACE

Шаг 4: Постройте графики

aiperf plot ./results

Доступ к сервису из другого namespace

При обращении к сервисам в других namespace используйте полный Kubernetes DNS:

# Same namespace
--url http://vllm-agg-frontend:8000

# Different namespace
--url http://vllm-agg-frontend.production.svc.cluster.local:8000

Мониторинг и отладка

# Проверить статус job
kubectl describe job dynamo-benchmark -n $NAMESPACE

# Следить за логами
kubectl logs -f job/dynamo-benchmark -n $NAMESPACE

# Проверить статус pod
kubectl get pods -n $NAMESPACE -l job-name=dynamo-benchmark

# Отладить failed pod
kubectl describe pod <pod-name> -n $NAMESPACE

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

1. Service not found: убедитесь, что frontend service вашего DynamoGraphDeployment работает
2. PVC access: проверьте, что dynamo-pvc правильно настроен и доступен
3. Image pull issues: убедитесь, что Docker image доступен из кластера
4. Resource constraints: скорректируйте limits ресурсов, если job выселяется

# Проверить статус PVC
kubectl get pvc dynamo-pvc -n $NAMESPACE

# Убедиться, что service существует и имеет endpoints
kubectl get svc -n $NAMESPACE
kubectl get endpoints <service-name> -n $NAMESPACE

---

Тестирование с DynoSim / Mocker

Для разработки и тестирования Dynamo предоставляет DynoSim и mocker backend, чтобы имитировать LLM inference без реальных GPU-ресурсов. Это полезно для:

• Тестирования развертываний без дорогой GPU-инфраструктуры
• Разработки и отладки логики router, planner или frontend
• Конвейеров CI/CD, которым нужно проверять инфраструктуру без запуска модели
• Проверки фреймворка бенчмаркинга, чтобы убедиться, что окружение работает до использования реальных бэкендов

Mocker — это живой симулированный движок в DynoSim: он имитирует API и поведение реальных бэкендов (SGLang, TensorRT-LLM, vLLM), но генерирует мок-ответы вместо реального inference. Используйте DynoSim Runs для одного прогона симулированной нагрузки/конфигурации и DynoSim Sweeps, когда хотите перебрать много кандидатных конфигураций.

Примеры использования и параметры настройки см. в Live Simulation with Mocker.

---

Расширенные возможности AIPerf

AIPerf умеет гораздо больше, чем базовое профилирование. Ниже перечислены функции, особенно полезные для бенчмаркинга Dynamo:

Возможность	Описание	Документация
Воспроизведение трасс	Воспроизведение production traces для детерминированного бенчмаркинга	Trace Replay
Паттерны поступления	Распределения трафика Poisson, constant и gamma	Arrival Patterns
Плавное наращивание	Плавный разгон concurrency и request rate	Ramping
Фаза прогрева	Устранение влияния cold start на измерения	Warmup
Балансировка нагрузки по нескольким URL	Распределение запросов по нескольким точкам доступа	Multi-URL
Телеметрия GPU	Сбор метрик DCGM во время бенчмаркинга	GPU Telemetry
Анализ goodput	Измерение пропускной способности на основе SLO	Goodput
Анализ timeslice	Разбор производительности по временным срезам	Timeslices
Многоходовые диалоги	Бенчмаркинг многоповоротного chat workload	Multi-Turn
Классификация экспериментов	Семантические цвета baseline и treatment на графиках	Plotting