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

Общая архитектура

Архитектура Dynamo

Dynamo — это распределенная среда выполнения для inference в генеративных AI-системах, которым нужно работать с высокой пропускной способностью, низкой задержкой и высокой надежностью при меняющемся трафике. Она не привязана к backend'у (SGLang, TRT-LLM, vLLM и другие) и построена вокруг трех взаимодействующих областей:

• Быстрый request path для генерации токенов
• Отзывчивый control path для масштабирования и размещения
• Устойчивый state path для повторного использования KV и восстановления после сбоев

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

Цели проектирования

Dynamo спроектирован так, чтобы одновременно достигать следующих целей:

1. Стабильность задержек: делать TTFT и ITL предсказуемыми при всплесках и смешанном трафике.
2. Эффективность GPU: разделять prefill и decode, чтобы каждый мог масштабироваться независимо.
3. Повторное использование вычислений: минимизировать пересчет KV за счет маршрутизации с учетом KV и управления жизненным циклом кэша.
4. Операционная устойчивость: считать падения worker'ов, перезапуски и перегрузку нормальными рабочими событиями.
5. Портируемость развертывания: поддерживать Kubernetes-native control paths и runtime-режимы вне Kubernetes.

Зачем нужна эта архитектура

Современное обслуживание LLM регулярно упирается в одни и те же узкие места:

• Дисбаланс prefill/decode оставляет GPU недозагруженными, когда меняется структура трафика (DistServe).
• Пересчет KV увеличивает TTFT и тратит вычисления впустую, если маршрутизация игнорирует пересечение кэша (DeepSeek).
• Давление на память из-за длинных контекстов и высокой конкуренции превышает емкость HBM без многоуровневого управления кэшем (KVBM, Mooncake, AIBrix, FlexKV, LMCache).
• Динамический спрос ломает предположения статического планирования ресурсов (AzureTrace).
• Реальные сбои (перезапуск pod'а, partition, перегрузка hot-spot) требуют полноценного поведения восстановления.

Dynamo решает эти ограничения, разделяя обслуживание, управление и распространение состояния на явные слои и контуры управления.

Обзор архитектуры

Модель системы

Request Plane (критический путь данных)

Request plane отвечает за выполнение запросов и ответов:

• Frontend принимает и нормализует запросы.
• Router выбирает worker'ов на основе нагрузки и пересечения KV.
• Prefill workers вычисляют KV-состояние промпта.
• Decode workers генерируют выходные токены.

Этот путь оптимизирован под минимальные накладные расходы и непрерывную потоковую выдачу токенов.

Control Plane (путь адаптации и оркестрации)

Control plane отвечает за управление желаемым состоянием:

• Planner вычисляет цели масштабирования по живым метрикам.
• Dynamo Operator приводит Kubernetes-ресурсы в соответствие с Dynamo CRD.
• Discovery + Endpoints/CRD обеспечивают liveness и discoverability.
• Grove/KAI Scheduler path обеспечивает размещение с учетом топологии и группированное масштабирование в многосерверных Kubernetes-развертываниях.
• Model Express — необязательная точка управления моделями, если она настроена.

Этот путь оптимизирован под корректность и сходимость к целевой емкости.

Storage & Events Plane (путь распространения состояния)

Storage/events plane отвечает за видимость и перемещение состояния кэша:

• KV Events публикуют переходы жизненного цикла кэша.
• KVBM управляет повторным использованием блоков, вытеснением и offload/recall между уровнями памяти.
• NIXL выполняет высокоскоростную передачу KV/данных между worker'ами и доменами памяти.

Этот путь оптимизирован под повторное использование кэша и эффективность передачи между worker'ами.

Сквозной сценарий запроса (Disaggregated Mode)

1. Клиент отправляет запрос в Frontend.
2. Frontend выполняет валидацию/предобработку и пересылает запрос в Router.
3. Router выбирает Prefill worker.
4. Prefill вычисляет KV и возвращает метаданные передачи.
5. Router выбирает Decode worker.
6. Decode получает KV-состояние, обычно через путь передачи NIXL.
7. Decode потоково отправляет токены обратно через Frontend.
8. KV Events обновляют видимость кэша для будущих решений маршрутизации.
9. KVBM может выполнять offload или recall KV-блоков в зависимости от давления и потенциала повторного использования.

Подробности на уровне потоков см. в Architecture Flow. Варианты передачи запросов см. в Request Plane.

Контуры управления

Serving Loop

Поддерживает выполнение запросов с низкой задержкой между frontend, router, prefill и decode worker'ами.

Planning Loop

Поддерживает согласование емкости со спросом:

• Planner потребляет runtime-метрики.
• Planner вычисляет цели для prefill/decode.
• Connector layer применяет цели к runtime-ресурсам.

Planner поддерживает стратегии на основе throughput и нагрузки. См. Planner Design.

Resilience Loop

Поддерживает непрерывность работы системы при сбоях:

• Проверки здоровья обнаруживают неисправные worker'ы.
• Liveness в Discovery удаляет устаревшие endpoints.
• Graceful shutdown завершает обработку уже начатых задач.
• Request migration/cancellation управляет поведением активных запросов.
• Load shedding предотвращает каскадный отказ при перегрузке.

См. Fault Tolerance.

Kubernetes-native реализация (CRD + Grove)

В Kubernetes-развертываниях та же архитектура отображается в декларативные ресурсы:

• Dynamo Operator приводит в соответствие DynamoGraphDeployment.
• Discoverability выводится из DynamoWorkerMetadata + EndpointSlices.
• Многосерверные развертывания на Grove моделируют группы worker'ов как PodCliqueSet и PodClique.
• Независимая эластичность prefill/decode представлена через PodCliqueScalingGroup с отдельными целями replicas и min.

Подписи на схеме, такие как PodClique A/B, ScalingGroup "Prefill", ScalingGroup "Decode" и (replicas, min), обозначают эту модель группированного масштабирования.

Режимы развертывания

Request plane можно представить двумя способами:

• Standalone mode (по умолчанию) — Dynamo Frontend является точкой входа запросов, а встроенный Dynamo Router выбирает worker'ы с использованием KV-aware scoring. Используется во всех локальных установках и в стандартном Kubernetes-развертывании.
• Gateway mode (GAIE) — Dynamo работает за Kubernetes-шлюзом Gateway API Inference Extension. Маршрутизацию с учетом KV на уровне шлюза выполняет Dynamo Endpoint Picker Plugin (EPP); Frontend работает как sidecar в --router-mode direct и учитывает выбор worker'а для каждого запроса, переданный через заголовки запроса.

Оба режима используют один и тот же control plane, storage/events plane и интеграции с backend'ами — различаются только точка входа запроса и место, где принимается решение о маршрутизации. См. руководство по Inference Gateway (GAIE) для настройки и справки по gateway mode.

Архитектура отказоустойчивости

Отказоустойчивость встроена на всех уровнях:

Layer	Mechanism	Practical effect
Request	Migration, cancellation	In-flight work can continue or terminate intentionally
Worker	Health checks, graceful shutdown, endpoint draining	Failed/terminating workers stop taking new traffic safely
System	Request rejection/load shedding	Prevents overload from propagating across workers
Infrastructure	Discovery lease expiry, event-path recovery	Stale membership is removed and traffic reroutes

Эта модель исходит из того, что сбои являются обычным, а не исключительным явлением.

Обоснование производительности

Disaggregated Serving

Разделение prefill и decode повышает загрузку и позволяет масштабировать каждую фазу отдельно.

Проверено на H100 с R1 Distilled Llama 70B FP8 на vLLM. 3K ISL / 150 OSL.

Маршрутизация с учетом KV

Маршрутизация с учетом пересечения кэша и сигналов нагрузки уменьшает повторные вычисления prefill и снижает задержку. Внешний промышленный кейс см. в статье How Baseten achieved 2x faster inference with NVIDIA Dynamo.

Проверено на 100K запросов к R1 с использованием R1 Distilled Llama 70B FP8 на 2 узлах H100. В среднем 4K ISL / 800 OSL.

KV Block Manager (KVBM)

KVBM увеличивает эффективную емкость кэша за счет многоуровневого offload/recall памяти.

Проверено на разных значениях QPS с использованием Qwen3-8B на H100. В среднем 20K ISL / 100 OSL.

Передача данных NIXL

NIXL снижает стоимость передачи KV в распределенном обслуживании за счет оптимизации межworker-передачи в разнородной памяти.

Модель реализации

• Rust для чувствительных к производительности runtime-компонентов.
• Python для интеграции backend'ов и расширяемости.
• Модульные границы подсистем, чтобы маршрутизация, планирование, память и транспорт могли развиваться независимо.

Связанная документация

• Architecture Flow
• Router Design
• Planner Design
• Discovery Plane
• Event Plane
• Request Plane
• Fault Tolerance
• Grove

Благодарности

Dynamo опирается на более ранние open-source-проекты:

• vLLM
• SGLang
• DistServe
• Mooncake
• AIBrix
• BentoML