Чтобы получить чистое Markdown-содержимое этой страницы, добавьте .md к этому URL. Полный индекс документации см. на https://docs.nvidia.com/dynamo/llms.txt. Полное содержимое, включая справочник API и примеры SDK, см. на https://docs.nvidia.com/dynamo/llms-full.txt.
Planner
Почему для инференса LLM нужен другой автомасштабировщик
Масштабировать традиционный веб-сервис просто: отслеживать CPU или частоту запросов, добавлять реплики при высокой нагрузке и удалять их при низкой. Такие инструменты, как HPA и KEDA, хорошо подходят для этого, потому что связь между нагрузкой и задержкой примерно линейна: вдвое больше запросов означает примерно вдвое больше нагрузки на CPU, поэтому простая пороговая политика удерживает время ответа стабильным.
Инференс LLM нарушает эти предположения:
- Задержка зависит от содержимого запроса, а не только от числа запросов. Один запрос с промптом на 32K токенов потребляет на порядки больше вычислений, чем короткий запрос. Два запроса в секунду могут означать совершенно разную нагрузку на GPU в зависимости от длин входной и выходной последовательностей.
- Prefill и decode имеют разные характеристики масштабирования. В дезагрегированном обслуживании prefill ограничен вычислениями (масштабируется с длиной входа), а decode ограничен памятью (масштабируется с числом параллельных последовательностей и использованием KV-кэша). Одно число реплик не отражает оба фактора.
- Важные метрики не являются стандартными. SLA, которые важны пользователям, — Time to First Token (TTFT) и Inter-Token Latency (ITL) — плохо отображаются на загрузку CPU или пропускную способность запросов. HPA не может целиться в «держать P95 TTFT ниже 500 мс», потому что для этого нужно понимать связь между длинами последовательностей, давлением на память GPU и задержкой.
- Решения о масштабировании дороги. Запуск GPU worker занимает минуты, а не секунды. Избыточное масштабирование расходует GPU-часы по облачным ценам; недостаточное масштабирование нарушает SLA. Автомасштабировщик должен прогнозировать спрос, а не только реагировать на него.
Dynamo Planner — это автомасштабировщик, специально созданный для этих ограничений. Он понимает данные профилирования движков, отслеживает использование GPU по каждому worker, прогнозирует шаблоны трафика и принимает решения о масштабировании, напрямую ориентированные на SLA по TTFT и ITL, а не на косвенные метрики.
Начало работы: цели оптимизации
Planner предлагает три настройки optimization_target, которые управляют тем, как принимаются решения о масштабировании:
| Цель | Описание | Требует SLA? | Требует профилирования? |
|---|---|---|---|
throughput (по умолчанию) | Максимизирует пропускную способность за счет масштабирования на основе глубины очереди и использования KV-кэша. Масштабируется вверх, когда движки насыщены, и вниз, когда использование падает. | Нет | Нет |
latency | Минимизирует задержку, агрессивно масштабируясь, чтобы очереди оставались короткими. Масштабируется вверх при более низких порогах использования. | Нет | Нет |
sla | Нацеливается на конкретные значения SLA для TTFT/ITL с помощью регрессионных моделей производительности. Самый точный вариант, но требует настройки. | Да (ttft_ms, itl_ms) | Рекомендуется |
Рекомендуем начинать с цели throughput по умолчанию — она работает сразу, без какой-либо настройки. Переключайтесь на latency, если ваша рабочая нагрузка чувствительна к задержке, или на sla, когда вам нужно точное соблюдение SLA с профилированием перед развертыванием.
Только начинаете работать с Planner? Начните с руководства по Planner, где описан полный рабочий процесс, включая профилирование и развертывание.
Нужна координация нескольких DGD? См. руководство по Global Planner для координации с общей политикой между несколькими DGD и развертываний с несколькими пулами за одной конечной точкой.
Режимы масштабирования
Planner поддерживает два режима масштабирования, которые могут работать независимо или вместе:
- Масштабирование на основе пропускной способности: использует данные о производительности движка перед развертыванием (из self-benchmark или profiler) и прогноз трафика, чтобы вычислить число реплик, необходимое для достижения целей TTFT и ITL. Корректировки выполняются с более длинным интервалом (по умолчанию 180 с). Это основной режим для производственных развертываний.
- Масштабирование на основе нагрузки: использует ForwardPassMetrics (FPM) из плоскости событий Dynamo и подбирает онлайн-линейную регрессию для принятия решений о масштабировании. Данные перед развертыванием и KV Router не требуются. Корректировки выполняются с коротким интервалом (по умолчанию 5 с), чтобы быстро реагировать на всплески.
Когда включены оба режима, масштабирование на основе пропускной способности задает нижнюю границу емкости (долгосрочное планирование), а масштабирование на основе нагрузки обрабатывает корректировки в реальном времени выше этой границы.
Матрица возможностей
| Возможность | На основе пропускной способности | На основе нагрузки |
|---|---|---|
| Развертывание | ||
| Дезагрегированное | Поддерживается | Поддерживается |
| Агрегированное | Поддерживается | Поддерживается |
| LLM-фреймворк | ||
| SGLang | Поддерживается | Поддерживается |
| TensorRT-LLM | Поддерживается | Поддерживается |
| vLLM | Поддерживается | Поддерживается |
| Требует данных перед развертыванием | Да (self-benchmark или profiler) | Нет |
| Предикторы нагрузки | ARIMA, Prophet, Kalman, Constant | Н/Д |
| Router | ||
| Любой (round-robin, random и т. д.) | Поддерживается | Не поддерживается |
| KV Router | Поддерживается | Поддерживается |
| Коннекторы | ||
| KubernetesConnector | Поддерживается | Поддерживается |
| VirtualConnector | Поддерживается | Поддерживается |
Когда использовать тот или иной режим
- Масштабирование на основе пропускной способности следует включать всегда, когда доступны данные о производительности движка (через self-benchmark или профилирование перед развертыванием). Оно обеспечивает стабильное планирование емкости на основе прогноза.
- Масштабирование на основе нагрузки следует включать, когда трафик имеет всплески или его трудно прогнозировать. Оно быстро реагирует на изменения нагрузки в реальном времени и не требует данных перед развертыванием.
- Оба режима вместе: чтобы получить преимущества обоих подходов, включите оба. Масштабирование на основе пропускной способности задает нижнюю границу (долгосрочную емкость), а масштабирование на основе нагрузки обрабатывает всплески выше этой границы. Когда включены оба режима, используйте более длинный
--adjustment-intervalдля масштабирования на основе пропускной способности.
Быстрый старт
Предварительные требования
- Платформа Dynamo, установленная в Kubernetes (руководство по установке)
- Установленный kube-prometheus-stack (настройка метрик)
Режим по умолчанию (без настройки)
Planner работает сразу и не требует настройки. По умолчанию optimization_target установлен в throughput, что использует статические пороги глубины очереди и использования KV-кэша — SLA и профилирование не требуются:
# Minimal planner config — uses throughput optimization by default
features:
planner:
mode: disagg
backend: vllm
Для рабочих нагрузок, чувствительных к задержке:
features:
planner:
mode: disagg
backend: vllm
optimization_target: latency
Масштабирование на основе SLA (расширенный режим)
Для точного нацеливания на SLA с профилированием перед развертыванием задайте optimization_target: sla:
features:
planner:
optimization_target: sla
enable_throughput_scaling: true
enable_load_scaling: true
ttft_ms: 500.0
itl_ms: 50.0
pre_deployment_sweeping_mode: rapid
Самый быстрый путь к масштабированию на основе SLA — через DynamoGraphDeploymentRequest, который автоматически профилирует вашу модель. См. примеры Planner с готовыми для копирования манифестами DGDR.
Полный рабочий процесс см. в руководстве по Planner.
Текущие ограничения
Масштабирование на основе нагрузки
Масштабирование на основе нагрузки имеет следующие известные ограничения. Масштабирование на основе пропускной способности ими не затрагивается.
Требует ForwardPassMetrics (FPM). Масштабирование на основе нагрузки использует метрики по каждому движку и каждой итерации, доставляемые через плоскость событий Dynamo (ForwardPassMetrics). KV Router не требуется для масштабирования на основе нагрузки. Доступность FPM по backend:
- vLLM — поддерживается. Автоматически включается, когда движок использует
InstrumentedSchedulerи заданDYN_FORWARDPASS_METRIC_PORT. - TensorRT-LLM — поддерживается для worker без attention-DP (
attention_dp_size == 1); отключается приattention_dp_size > 1до появления выдачи FPM по каждому rank. - SGLang — pipeline подключен в Dynamo, но upstream-модуль FPM SGLang не включен в текущий runtime-образ SGLang 1.2.0. Предварительное требование к runtime-образу см. в разделе SGLang FPM.
Общие
Активные запросы во время масштабирования вниз. Когда Planner масштабирует worker вниз, worker завершается без ожидания завершения активных запросов. Запросы, которые находились в середине prefill на завершенном worker, завершатся ошибкой. В дезагрегированных развертываниях это также может затронуть decode worker, ожидавшие передачи KV-кэша от завершенного prefill worker. Обходной путь: задайте --min-endpoint таким значением, которое не позволит масштабироваться ниже вашего устойчивого базового уровня трафика, и используйте более низкое значение --loadbased-scaling-down-sensitivity, чтобы снизить частоту событий масштабирования вниз.
Документация
| Документ | Описание |
|---|---|
| Руководство по Planner | Развертывание, настройка, интеграция |
| Дизайн Planner | Архитектура и внутреннее устройство алгоритмов |
| Примеры Planner | Примеры YAML для DGDR, образцы конфигураций, расширенные паттерны |
| Руководство по Global Planner | Координация нескольких DGD, общие GPU-бюджеты, развертывания с несколькими пулами за одной конечной точкой |
Справочник конфигурации
Основные аргументы
| Аргумент | По умолчанию | Описание |
|---|---|---|
| Общие | ||
--namespace | $DYN_NAMESPACE или dynamo | Логическое пространство имен Dynamo |
--backend | vllm | Backend-фреймворк (sglang, trtllm, vllm) |
--mode | disagg | Режим Planner (disagg, prefill, decode, agg) |
--optimization-target | throughput | Цель масштабирования: throughput (пороги очереди/использования), latency (агрессивная низкая задержка), sla (нацеливание на SLA на основе регрессии) |
--environment | kubernetes | Среда развертывания |
ttft_ms | 500.0 | Целевое Time To First Token (мс) |
itl_ms | 50.0 | Целевая Inter-Token Latency (мс) |
--max-gpu-budget | 8 | Максимальное число GPU по всем worker |
--min-endpoint | 1 | Минимальное число реплик для каждого типа worker |
--decode-engine-num-gpu | 1 | GPU на decode engine |
--prefill-engine-num-gpu | 1 | GPU на prefill engine |
advisory | false | Режим только рекомендаций. Planner вычисляет и сообщает рекомендуемое число реплик, но не выполняет действия масштабирования и не меняет развертывание. |
| Масштабирование на основе пропускной способности | ||
--enable-throughput-scaling | true | Включить масштабирование на основе пропускной способности |
--adjustment-interval | 180 | Секунды между решениями масштабирования на основе пропускной способности |
--profile-results-dir | profiling_results | Путь к данным профилирования (NPZ/JSON) |
--load-predictor | arima | Модель прогнозирования (arima, prophet, kalman, constant) |
| Масштабирование на основе нагрузки | ||
--enable-loadbased-scaling | false | Включить масштабирование на основе нагрузки |
--loadbased-adjustment-interval | 5 | Секунды между обновлениями регрессии FPM и решениями масштабирования на основе нагрузки |
--max-num-fpm-samples | 64 | Максимальное число сохраняемых наблюдений FPM для регрессии |
--fpm-sample-bucket-size | 16 | Число buckets для удаления наблюдений (должно быть полным квадратом) |
--loadbased-scaling-down-sensitivity | 80 | Чувствительность масштабирования вниз 0-100 (0=никогда, 100=агрессивно) |
--loadbased-metric-samples | 10 | Число выборок метрик на интервал корректировки |
--loadbased-min-observations | 5 | Минимальное число наблюдений перед активацией регрессии |
Переменные окружения
| Переменная | По умолчанию | Описание |
|---|---|---|
DYN_NAMESPACE | dynamo | Логическое пространство имен Dynamo |
DYN_PARENT_DGD_K8S_NAME | (обязательно) | Имя родительского ресурса DGD K8s |
PROMETHEUS_ENDPOINT | http://prometheus-kube-prometheus-prometheus.monitoring.svc.cluster.local:9090 | URL Prometheus |
PLANNER_PROMETHEUS_PORT | 0 (отключено) | Порт для собственных метрик Prometheus у planner |
Мониторинг
Дашборд Grafana
Разверните дашборд planner:
kubectl apply -n monitoring -f deploy/observability/grafana-planner-dashboard-configmap.yaml
Дашборд показывает:
- Число worker и использование GPU во времени
- Наблюдаемые TTFT, ITL, частоту запросов, длины последовательностей
- Прогнозируемую нагрузку и рекомендуемое число реплик
- Состояние регрессионной модели FPM
Метрики Prometheus
Когда задан PLANNER_PROMETHEUS_PORT, planner обслуживает собственную конечную точку метрик. Экспортируемые ряды используют соглашение именования dynamo_planner_* (подчеркивания и стандартные суффиксы единиц измерения), заменяя старые имена в стиле planner:*.
Масштабирование на основе пропускной способности получает метрики трафика из общего для кластера сервера Prometheus:
- Число и длительность запросов
- Распределения TTFT и ITL
- Длины входных/выходных последовательностей
Planner может читать эти сигналы трафика либо из публичного Frontend, либо из локального для пула LocalRouter. Используйте throughput_metrics_source: "frontend" для развертывания с одним DGD. Используйте throughput_metrics_source: "router" для GlobalPlanner / развертываний с несколькими пулами, чтобы Planner каждого пула читал трафик собственного router, а не общей публичной конечной точки.
| Вход Planner | Источник Frontend | Источник Router |
|---|---|---|
| Число запросов | dynamo_frontend_requests_total | dynamo_component_router_requests_total |
| TTFT | dynamo_frontend_time_to_first_token_seconds | dynamo_component_router_time_to_first_token_seconds |
| ITL | dynamo_frontend_inter_token_latency_seconds | dynamo_component_router_inter_token_latency_seconds |
| Длительность запроса | dynamo_frontend_request_duration_seconds | dynamo_component_request_duration_seconds до появления метрик длительности, специфичных для router |
| Длина входной последовательности / ISL | dynamo_frontend_input_sequence_tokens | dynamo_component_router_input_sequence_tokens |
| Длина выходной последовательности / OSL | dynamo_frontend_output_sequence_tokens | dynamo_component_router_output_sequence_tokens |
| Доля попаданий KV | Недоступна из источника frontend | dynamo_component_router_kv_hit_rate |
Planner для пропускной способности использует число запросов, ISL, OSL и необязательную долю попаданий KV как основные входы прогноза трафика. TTFT, ITL и длительность запросов также собираются и экспортируются как наблюдаемая диагностика.
Масштабирование на основе нагрузки использует ForwardPassMetrics (FPM) из плоскости событий Dynamo:
- Wall time по каждой итерации, запланированные токены prefill/decode и состояние запросов в очереди
- Доставляется через
FpmEventSubscriberс автоматическим обнаружением движков и отслеживанием жизненного цикла - Scraping
/metricsу router не требуется
FPM наблюдает запланированную работу и очереди на стороне движка. Он не включает запросы, которые еще находятся в очереди LocalRouter до назначения движка.
Основные gauges на порту planner включают число реплик (dynamo_planner_num_prefill_replicas, dynamo_planner_num_decode_replicas), наблюдаемый трафик (dynamo_planner_observed_*), рекомендации по репликам (dynamo_planner_predicted_num_prefill_replicas, dynamo_planner_predicted_num_decode_replicas) и накопленную метрику dynamo_planner_gpu_hours.
Gauges прогноза пропускной способности dynamo_planner_predicted_requests_per_second, dynamo_planner_predicted_input_sequence_tokens и dynamo_planner_predicted_output_sequence_tokens подключены к прогнозу трафика для масштабирования на основе пропускной способности и экспортируются рядом с наблюдаемыми метриками длины последовательностей.
Режим advisory
Задайте advisory: true, чтобы запустить локальный Planner в режиме только рекомендаций. Это рекомендуется, когда вы оцениваете новую конфигурацию Planner, проверяете цели SLA или анализируете, как Planner реагировал бы на production-трафик, прежде чем разрешить ему масштабировать worker.
В режиме advisory Planner по-прежнему наблюдает трафик и данные FPM, вычисляет рекомендуемое число реплик prefill и decode, записывает сводки рекомендаций в логи, экспортирует метрики прогнозируемых реплик и включает рекомендации в диагностические отчеты. Рекомендации не применяются как решения о масштабировании: Planner не выполняет действия масштабирования, не отправляет изменения реплик в Kubernetes или GlobalPlanner и не изменяет развертывание.
Диагностические метрики
Дополнительные ряды поддерживают дашборды и офлайн-анализ:
- Оценки задержки на основе регрессии:
dynamo_planner_estimated_ttft_msиdynamo_planner_estimated_itl_msотражают максимальные оценочные TTFT и ITL из онлайн-регрессии по всем движкам. - Емкость движка:
dynamo_planner_engine_prefill_requests_per_secondиdynamo_planner_engine_decode_requests_per_secondсообщают емкость одного движка для prefill и decode при настроенном SLA. - Причины решений о масштабировании:
dynamo_planner_load_scaling_decisionиdynamo_planner_throughput_scaling_decision— это Enum gauges, в которых метки состояний кодируют, почему каждый режим выбрал масштабирование, удержание или пропуск (например,scale_up,no_fpm_data,set_lower_bound). - Глубины очередей FPM по движкам:
dynamo_planner_engine_queued_prefill_tokens,dynamo_planner_engine_queued_decode_kv_tokensиdynamo_planner_engine_inflight_decode_kv_tokensпомечаютсяworker_idиdp_rankдля каждого движка.
Диагностические HTML-отчеты
Planner может создавать периодические автономные диагностические HTML-файлы с интерактивными графиками Plotly.
Настройте это в PlannerConfig (или в эквивалентной YAML / привязке конструктора, которую использует ваше развертывание):
report_interval_hours: интервал в симулированном времени между отчетами (по умолчанию24.0часа); задайтеNone, чтобы отключить.report_output_dir: каталог, в который записываются HTML-файлы (по умолчанию./planner_reports).live_dashboard_port: порт для HTTP-дашборда реального времени (по умолчанию8080). Задайте0, чтобы отключить. Сервер aiohttp запускается на указанном порту и отдает текущие накопленные данные snapshot как интерактивный отчет Plotly по адресуhttp://<host>:<port>/. В отличие от периодических отчетов, live dashboard не очищает snapshots — он всегда показывает все данные, накопленные с последнего периодического отчета (или с запуска, если периодические отчеты отключены).
Отчеты агрегируют snapshots по каждому tick и используют TickInput.now_s для временных меток, поэтому ведут себя одинаково в live-запусках (wall clock) и в replay с симулированными часами. Типичные графики охватывают число worker, рекомендуемое число реплик, наблюдаемые и оценочные задержки в сравнении с целями SLA, частоту запросов, емкость движков, временные линии решений о масштабировании и длины входных/выходных последовательностей. На графике Replica Counts фактические реплики показаны линиями, а рекомендованное Planner число реплик prefill и decode показано дискретными маркерами в тех tick, где были сформированы рекомендации. Это особенно полезно с advisory: true, потому что такие рекомендации являются только предложениями.