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

Переборы DynoSim

DynoSim sweep выполняет множество симулированных испытаний для разных топологий-кандидатов, настроек роутера и входных данных временной модели, а затем ранжирует результаты с учетом ограничений SLA и бюджета GPU. Используйте sweep, когда одного запуска DynoSim недостаточно и нужно исследовать пространство проектных вариантов перед проверкой на реальных GPU.

Текущий Python API — dynamo.profiler.utils.replay_optimize. В документации "DynoSim sweep" используется как продуктовый термин, при этом пока сохраняется существующее имя реализации.

На какие вопросы это отвечает

Sweep отвечает на конкретный вопрос о развертывании:

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

какая топология, разбиение worker-ов и настройки роутера дают лучший симулированный результат?

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

форму tensor parallel для worker-ов prefill и decode
количество worker-ов prefill и decode
кредит перекрытия KV-router
масштабирование prompt-load
целевые показатели пропускной способности, TTFT, ITL или сквозной задержки

Это эвристический поиск по симулированным состояниям, а не точный оптимизатор по всем допустимым конфигурациям.

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

flowchart LR
    A["TP search<br/>choose TP shape<br/>(prefill_tp, decode_tp)<br/>under GPU budget"] --> B["Worker search<br/>choose worker split<br/>(prefill_workers, decode_workers)<br/>for the chosen TP"]
    B --> C["Router search<br/>choose routing mode<br/>and router cost knobs"]
    C --> D["DynoSim run evaluations"]
    D --> E["Feasible candidates"]
    E --> A

Каждое состояние-кандидат оценивается средой запуска DynoSim. Оптимизатор записывает метрики каждого запуска, отфильтровывает кандидатов, нарушающих ограничения SLA или бюджета GPU, и возвращает лучшее допустимое состояние вместе с полной таблицей оцененных вариантов для анализа.

Спуск ориентирован на бюджет: на каждом шаге выполняется отсечение до состояний около границы бюджета, поэтому sweep приходит к форме TP/worker, которая фактически использует доступный бюджет GPU, а не к точке с максимальной пропускной способностью на GPU. В агрегированных sweep-ах измерения TP и worker сворачиваются в (tp, workers), но в остальном используется та же идея.

Структура спецификации

Публичный API принимает один ReplayOptimizeSpec, состоящий из:

Спецификация	Назначение
`EngineSpec`	Модель, backend и JSON-подобные аргументы движка. Дезагрегированные sweep-ы используют аргументы движка prefill и decode; агрегированные sweep-ы используют `baseEngineArgs`.
`HardwareSpec`	SKU GPU и общий симулированный бюджет GPU
`WorkloadSpec`	Параметры синтетической рабочей нагрузки или файл трассы
`SLASpec`	Необязательные границы TTFT, ITL, сквозной задержки и p95
`RouterSpec`	Режим роутера, sweep по overlap-score-credit, sweep по prefill-load-scale и базовая конфигурация KV-router
`objective`	Цель ранжирования, например пропускная способность, средний TTFT или средняя сквозная задержка
`maxParallelEvals`	Количество оценок кандидатов, запускаемых параллельно

Имена полей используют lowerCamelCase, чтобы соответствовать концепциям DynamoGraphDeploymentRequest. Имена методов остаются в snake_case, чтобы соответствовать соглашению Pydantic.

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

Запускайте из корня репозитория.

Используйте виртуальное окружение проекта:

.venv/bin/python --version

Если Python bindings пока не импортируются, сначала соберите их:

.venv/bin/maturin develop --uv -m lib/bindings/python/Cargo.toml

В примере по умолчанию используется тайминг на базе AIC:

AIC перечисляет плотные TP-кандидаты
для конфигураций-кандидатов используется тайминг движка на базе AIC

Установите aiconfigurator в окружение проекта:

uv pip install --python .venv/bin/python aiconfigurator

Если обычная установка не загружает пригодные perf-данные, переустановите пакет из исходного checkout-а, где материализованы реальные системные данные:

uv pip install --python .venv/bin/python --force-reinstall /path/to/aiconfigurator

Если настройка DynoSim sweep завершается ошибками AIC из-за отсутствующих perf-баз данных или ошибок разбора вроде KeyError: 'gemm_dtype', проверьте установленные файлы в:

.venv/lib/python*/site-packages/aiconfigurator/systems/data/...

Если эти файлы начинаются с version https://git-lfs.github.com/spec/v1, у вас заглушки-указатели Git LFS вместо реальных perf-таблиц. Установите aiconfigurator из checkout-а или wheel, который содержит реальные материализованные LFS-полезные данные в systems/.

При запуске напрямую из исходного checkout-а сделайте Python-пакеты из репозитория доступными:

export PYTHONPATH=lib/bindings/python/src:components/src

Если sweep использует несколько процессов worker-ов, предпочитайте настоящий файл скрипта вместо heredoc. В macOS дочерним worker-ам ProcessPoolExecutor нужен стабильный путь к модулю, а модуль-драйвер должен защищать точку входа через if __name__ == "__main__":.

Для логов KV-router этот фильтр сохраняет вывод читаемым, не скрывая полезный вывод info:

export DYN_LOG='info,dynamo_kv_router::scheduling::selector=warn'

Запуск примера

Каноническая отправная точка — добавленный в репозиторий скрипт-драйвер:

.venv/bin/python components/src/dynamo/profiler/utils/replay_optimize/example.py \
  --max-parallel-evals 4

Пример по умолчанию ищет по синтетической дезагрегированной рабочей нагрузке KV-router, используя тайминг кандидатов на базе AIC. Он печатает лучшее допустимое состояние и таблицу лучших допустимых конфигураций.

В примере используются:

модель: Qwen/Qwen3-32B
backend: vllm
SKU GPU: h200_sxm
всего симулированных GPU: 16
режим роутера: kv_router
синтетическая рабочая нагрузка:
- isl=32768
- osl=256
- requestCount=5000
- concurrency=200
- sharedPrefixRatio=0.5
- numPrefixGroups=50

Бюджет GPU — это симулированное ограничение поиска. Для локального запуска поиска вам не нужны 16 реальных GPU.

Базовые аргументы движка остаются консервативными:

block_size=512
enable_prefix_caching=True
явный worker_type для prefill и decode

В примере намеренно опущен num_gpu_blocks; DynoSim на базе AIC оценивает емкость для каждой TP-формы кандидата, если базовый вход явно ее не фиксирует.

Эта настройка не навязывает специфичные для планировщика узкие места, такие как:

enable_chunked_prefill
малый max_num_seqs
закрепленный max_num_batched_tokens

Добавляйте их только тогда, когда эксперимент специально посвящен ограничениям планировщика.

Запуск по трассе

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

.venv/bin/python components/src/dynamo/profiler/utils/replay_optimize/example.py \
  --trace-file /path/to/mooncake_trace.jsonl \
  --arrival-speedup-ratio 1.0 \
  --max-parallel-evals 4

В качестве публичной отправной точки скачайте трассу FAST'25 toolagent:

curl -sL \
  https://raw.githubusercontent.com/kvcache-ai/Mooncake/refs/heads/main/FAST25-release/traces/toolagent_trace.jsonl \
  -o /tmp/toolagent_trace.jsonl

Затем запустите:

.venv/bin/python components/src/dynamo/profiler/utils/replay_optimize/example.py \
  --trace-file /tmp/toolagent_trace.jsonl \
  --arrival-speedup-ratio 1.0 \
  --max-parallel-evals 4

В режиме трассы:

traceFile указывает на JSONL-вход в стиле Mooncake
arrivalSpeedupRatio сжимает или растягивает процесс поступления запросов в трассе
параметры только для синтетического режима, такие как isl, osl, requestCount, concurrency, sharedPrefixRatio и numPrefixGroups, игнорируются

Важные замечания для публичной трассы toolagent:

набор данных использует hash_ids в стиле Mooncake с 512 токенами на блок
базовый API run_trace_replay(...) по умолчанию использует trace_block_size, равный 512
WorkloadSpec пока не предоставляет отдельное поле traceBlockSize

Настройка sweep

Рассматривайте пример драйвера как отправную точку, а не как неизменяемую среду запуска. Изменяйте его под свой поиск:

измените форму WorkloadSpec или переключитесь на источник трассы через traceFile
добавьте границы SLA в SLASpec, например ttft, itl, e2eLatency или их p95-варианты
измените RouterSpec.overlapCredits в допустимом диапазоне от 0.0 до 1.0
измените RouterSpec.prefillLoadScales, когда хотите сильнее или слабее учитывать TTFT/нагрузку на стороне prompt
выводите другие столбцы из result.evaluated_df или result.feasible_df
сохраняйте таблицы в CSV или Parquet для последующего анализа

Полезные оси варьирования:

HardwareSpec.totalGpus
RouterSpec.overlapCredits
RouterSpec.prefillLoadScales
WorkloadSpec.sharedPrefixRatio
WorkloadSpec.numPrefixGroups
базовые аргументы движка prefill/decode

Если вы хотите напрямую сравнить стратегии маршрутизации, используйте RouterSpec(mode="both") вместо поиска только по KV-router по умолчанию.

Выходные данные

Оптимизатор возвращает DenseReplayOptimizationResult с:

best_feasible: лучшее посещенное состояние, которое удовлетворяет всем настроенным ограничениям SLA и бюджета GPU
best_infeasible: лучшее посещенное состояние, которое нарушает хотя бы одну границу SLA или бюджет
evaluated_df: все посещенные состояния
feasible_df: только допустимые состояния

Обычные столбцы для проверки:

топология: prefill_tp, decode_tp, prefill_workers, decode_workers
маршрутизация: router_mode, overlap_score_credit, prefill_load_scale
бюджет: total_gpus_used Это симулированный GPU-след состояния-кандидата, а не количество GPU, фактически выделенных на машине, где выполняется поиск.
пропускная способность: output_throughput_tok_s
поведение кэша: prefix_cache_reused_ratio
задержка: mean_ttft_ms, mean_tpot_ms, mean_e2e_latency_ms

DataFrame отчета по-прежнему использует ключи метрик Rust-раннера DynoSim (mean_ttft_ms, mean_tpot_ms, mean_e2e_latency_ms), хотя входной SLASpec использует camelCase-имена в стиле DGDR (ttft, itl, e2eLatency). SLASpec содержит внутреннюю карту преобразования.

В локальном тестировании синтетическая настройка по умолчанию дала нетривиального победителя по среднему E2E примерно в таком диапазоне:

prefill_tp=4, decode_tp=1, prefill_workers=3, decode_workers=4, overlap_score_credit=0.5, prefill_load_scale=1.0
output_throughput_tok_s ~= 970, prefix_cache_reused_ratio ~= 0.5, mean_ttft_ms ~= 42800, mean_tpot_ms ~= 35, mean_e2e_latency_ms ~= 51900

Рассматривайте эти значения как диапазоны для sanity-check, а не как фиксированные утверждения.

Связь с запусками DynoSim

Запуск DynoSim отвечает на вопрос "как работает эта конкретная конфигурация?" DynoSim sweep отвечает на вопрос "какую конфигурацию стоит попробовать следующей?"

Для финальной проверки переносите допустимых кандидатов в live-развертывание Mocker или в AIPerf-бенчмарк на реальных GPU. DynoSim предназначен для сужения пространства поиска перед проверкой в кластере, а не для ее замены.

На какие вопросы это отвечает​

Как это работает​

Структура спецификации​

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

Запуск примера​

Запуск по трассе​

Настройка sweep​

Выходные данные​

Связь с запусками DynoSim​