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.

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

Planner Dynamo - это контроллер автоскейлинга, который в реальном времени изменяет число реплик prefill- и decode-engine, чтобы выдерживать SLA по задержке. Он читает сигналы трафика (метрики Prometheus или вывод предиктора нагрузки) и профили производительности engine, чтобы решать, когда масштабироваться вверх или вниз.

Для краткого обзора см. обзор Planner. Для внутренних аспектов архитектуры см. Design Planner.

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

Planner поддерживает четыре целевых режима оптимизации, которые определяют, как принимаются решения о масштабировании:

• throughput (по умолчанию): использует статические пороги глубины очереди и утилизации KV cache. Не требует SLA-целей или профилирования. Работает сразу после установки.
• latency: тот же подход, что и throughput, но с более агрессивными порогами - масштабируется раньше и допускает меньше очереди. Подходит для workload'ов, чувствительных к задержке.
• load: использует заданные пользователем пороги токенов в очереди prefill и утилизации decode KV для реактивного масштабирования на основе load.
• sla: использует модели производительности на основе регрессии с конкретными целями TTFT/ITL. Поддерживает как масштабирование на основе throughput (предиктивное), так и на основе load (реактивное). Для опытных пользователей, которым нужен точный контроль SLA.

Когда что использовать:

• Начните с throughput (по умолчанию) - он работает сразу и не требует настройки.
• Переключитесь на latency, если у workload строгие требования к задержке и вы предпочитаете резервировать ресурсы, а не ставить запросы в очередь.
• Используйте load, когда нужен прямой контроль через пороги очереди prefill и утилизации decode KV.
• Используйте sla, когда у вас есть данные профилирования до развертывания и нужно целиться в конкретные значения TTFT/ITL.

Справочник PlannerConfig

Planner настраивается через JSON/YAML-объект PlannerConfig. При использовании profiler'а он размещается в секции features.planner спецификации DGDR:

features:
  planner:
    mode: disagg
    backend: vllm
    # optimization_target по умолчанию равен "throughput" - работает сразу после установки

Для масштабирования на основе SLA:

features:
  planner:
    optimization_target: sla
    enable_throughput_scaling: true
    enable_load_scaling: false
    pre_deployment_sweeping_mode: rapid
    mode: disagg
    backend: vllm

Чтобы оценить поведение Planner без изменения числа реплик, включите advisory mode:

features:
  planner:
    advisory: true

Advisory mode работает только как рекомендация. Planner вычисляет рекомендуемое число реплик, логирует его, экспортирует как диагностику и показывает в HTML-отчетах. Эти рекомендации не применяются как решения о масштабировании: Planner не выполняет действия масштабирования и не изменяет deployment.

Целевой режим оптимизации

Поле	Тип	Значение по умолчанию	Описание
optimization_target	string	throughput	throughput: масштабирование по порогам очереди/утилизации. latency: агрессивные пороги для низкой задержки. load: заданные пользователем пороги очереди prefill и утилизации decode KV. sla: масштабирование на основе регрессии с целями ttft_ms/itl_ms.

Когда optimization_target равен throughput, latency или load, масштабирование на основе load включается автоматически, а масштабирование на основе throughput отключается. Поля ttft_ms/itl_ms игнорируются.

Поля режима масштабирования (режим SLA)

Поле	Тип	Значение по умолчанию	Описание
enable_throughput_scaling	bool	true	Включает масштабирование на основе throughput (требуются данные производительности до развертывания). Используется только при optimization_target: sla.
enable_load_scaling	bool	false	Включает масштабирование на основе load. Используется только при optimization_target: sla.

При использовании optimization_target: sla должен быть включен хотя бы один режим масштабирования.

Прогон до развертывания

Поле	Тип	Значение по умолчанию	Описание
pre_deployment_sweeping_mode	string	rapid	Как генерировать данные производительности engine: rapid (симуляция AIC, ~30s), thorough (реальные GPU, 2-4h) или none (пропустить).

Когда включено масштабирование на основе throughput, Planner нужны данные производительности engine. При запуске он сначала пытается получить результаты self-benchmark из конечной точки Dynamo get_perf_metrics (см. PR #7779). Если они недоступны, он переходит к данным, сгенерированным profiler'ом (npz или JSON) в profile_results_dir. Оба источника преобразуются в ForwardPassMetrics и передаются в модель регрессии FPM.

Настройки масштабирования на основе Throughput

Поле	Тип	Значение по умолчанию	Описание
throughput_adjustment_interval_seconds	int	180	Количество секунд между решениями о масштабировании на основе throughput.
throughput_metrics_source	string	frontend	Источник traffic-метрик Prometheus для масштабирования на основе throughput: frontend читает метрики dynamo_frontend_* из публичного Frontend; router читает метрики dynamo_component_router_* из LocalRouter. Используйте router для pool-local Planner в развертываниях GlobalPlanner.
min_endpoint	int	1	Минимальное число endpoint'ов engine, которое нужно сохранять.
max_gpu_budget	int	8	Максимальное общее число GPU, которое Planner может выделить.
ttft_ms	float	500.0	Цель SLA по TTFT (мс) для решений о масштабировании.
itl_ms	float	50.0	Цель SLA по ITL (мс) для решений о масштабировании.

Настройки масштабирования на основе Load

Поле	Тип	Значение по умолчанию	Описание
load_adjustment_interval_seconds	int	5	Количество секунд между обновлениями регрессии FPM и решениями о масштабировании на основе load. Даже если включено только масштабирование на основе throughput, живые наблюдения FPM подаются в регрессию с этим интервалом. Должно быть меньше throughput_adjustment_interval_seconds.
max_num_fpm_samples	int	64	Максимальное число сохраняемых наблюдений FPM для регрессии.
fpm_sample_bucket_size	int	16	Количество bucket'ов для удаления устаревших наблюдений (должно быть полным квадратом).
load_scaling_down_sensitivity	int	80	Чувствительность масштабирования вниз от 0 до 100 (0=никогда, 100=агрессивно).
load_metric_samples	int	10	Количество сэмплов метрик, собираемых для каждого решения.
load_min_observations	int	5	Минимальное число наблюдений перед принятием решений о масштабировании.

Общие настройки

Поле	Тип	Значение по умолчанию	Описание
mode	string	disagg	Режим Planner: disagg, prefill, decode или agg.
backend	string	vllm	Backend: vllm, sglang, trtllm или mocker.
environment	string	kubernetes	Окружение выполнения: kubernetes, virtual или global-planner.
namespace	string	env DYN_NAMESPACE	Namespace Kubernetes для deployment.
advisory	bool	false	Режим только рекомендаций. Вычисляет, логирует, экспортирует и показывает рекомендованное число реплик, не выполняя действий масштабирования и не изменяя deployment.

Настройки прогнозирования трафика

Поле	Тип	Значение по умолчанию	Описание
load_predictor	string	arima	Метод прогнозирования: constant, arima, kalman или prophet.
load_predictor_log1p	bool	false	Применять преобразование log1p к данным нагрузки перед прогнозированием.
prophet_window_size	int	50	Размер окна (в секундах) для предиктора Prophet.
load_predictor_warmup_trace	string	null	Путь к trace-файлу warm-up для bootstrapping'а прогнозов.

Настройки фильтра Калмана

Поле	Тип	Значение по умолчанию	Описание
kalman_q_level	float	1.0	Шум процесса для компонента уровня.
kalman_q_trend	float	0.1	Шум процесса для компонента тренда.
kalman_r	float	10.0	Шум измерения.
kalman_min_points	int	5	Минимальное число точек данных до активации прогнозов Kalman.

Отчеты диагностики

Поле	Тип	Значение по умолчанию	Описание
report_interval_hours	float or null	24.0	Генерировать HTML-отчет диагностики каждые N часов (симулированного времени). Установите null, чтобы отключить периодическую генерацию отчетов.
report_output_dir	string	./planner_reports	Каталог для HTML-отчетов диагностики.
live_dashboard_port	int	8080	Порт HTTP-сервера live dashboard диагностики. Установите 0, чтобы отключить. Если включено, откройте http://host:port/, чтобы увидеть real-time Plotly-отчет накопленных снимков.

Те же диагностические сигналы, которые показываются в этих отчетах, также экспортируются как метрики Prometheus с префиксом dynamo_planner_* - например, оцененные TTFT/ITL (dynamo_planner_estimated_ttft_ms, dynamo_planner_estimated_itl_ms), рекомендуемое число реплик (dynamo_planner_predicted_num_prefill_replicas, dynamo_planner_predicted_num_decode_replicas), емкость по каждому engine и глубины очередей FPM, а также enum'ы решений о масштабировании load/throughput.

График Replica Counts накладывает фактические реплики prefill/decode на дискретные маркеры рекомендаций для рекомендованных Planner'ом реплик prefill/decode. Когда advisory: true, эти значения являются только рекомендациями; Planner записывает, что он сделал бы, но не применяет изменение.

Интеграция с Profiler

Когда profiler запускается с включенным Planner, он:

1. Выбирает лучшие конфигурации prefill и decode engine
2. Генерирует данные производительности engine (prefill TTFT vs ISL, decode ITL vs KV-cache utilization)
3. Saves the PlannerConfig and performance data into separate Kubernetes ConfigMaps
4. Добавляет service Planner в сгенерированный DGD, настроенный на чтение этих ConfigMap'ов

Planner получает конфигурацию через --config /path/to/planner_config.json, который монтируется из ConfigMap planner-config-XXXX. Данные профилирования монтируются из ConfigMap planner-profile-data-XXXX.

См. Profiler Guide для полного workflow профилирования и настройки pre-deployment sweeping.

Иерархические deployment'ы

Если нужен один публичный endpoint для модели, но несколько приватных DGD, оптимизированных под разные классы запросов, используйте иерархический deployment:

• один control DGD с Frontend, GlobalRouter и GlobalPlanner
• один или несколько DGD prefill pool
• один или несколько DGD decode pool

В текущем workflow профилирование нужно запускать независимо для каждого целевого pool, а затем вручную собрать итоговый control DGD вместе с pool DGD. См. Global Planner Guide.

См. также

• обзор Planner — почему для LLM inference нужен другой autoscaler
• Design Planner — архитектура и внутренности алгоритмов
• Planner Examples — примеры YAML DGDR, образцы конфигураций, продвинутые паттерны
• Global Planner Guide — координация нескольких DGD, общий GPU budget, multi-pool deployment с одним endpoint
• Profiler Guide — как генерируются данные профилирования