Перейти к основному содержимому

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

Справочное руководство

Справочное руководство

Обзор​

Бэкенд vLLM в Dynamo интегрирует движки vLLM в распределенную среду выполнения Dynamo, обеспечивая дезагрегированное обслуживание, маршрутизацию с учетом KV и отмену запросов. Dynamo использует нативные события KV-кеша vLLM, механизмы передачи на основе NIXL и отправку метрик.

Dynamo vLLM использует нативный парсер аргументов vLLM: все аргументы движка vLLM передаются напрямую. Dynamo добавляет собственные аргументы для режима дезагрегации, передачи KV и эмбеддингов промпта.

Справочник аргументов​

Бэкенд vLLM принимает все аргументы движка из исходного проекта vLLM, а также аргументы, специфичные для Dynamo. Авторитетным источником всегда остается CLI:

python -m dynamo.vllm --help

Вывод --help организован в следующие группы:

  • Dynamo Runtime Options — Namespace, бэкенд discovery, плоскость запросов/событий, типы endpoint, парсеры tool/reasoning и пользовательские шаблоны чата. Эти параметры общие для всех бэкендов Dynamo и используют переменные окружения DYN_*.
  • Dynamo vLLM Options — режим дезагрегации, выбор токенизатора, sleep mode, мультимодальные флаги, конфигурация пайплайна vLLM-Omni, headless mode и ModelExpress. Эти параметры используют переменные окружения DYN_VLLM_*.
  • vLLM Engine Options — все нативные аргументы vLLM (--model, --tensor-parallel-size, --kv-transfer-config, --kv-events-config, --enable-prefix-caching и т. д.). См. документацию по аргументам vLLM serve.

Парсеры Tool и Reasoning​

Используйте --dyn-tool-call-parser и --dyn-reasoning-parser, чтобы сопоставить формат вывода модели, когда модель выдает вызовы tool и/или содержимое reasoning. Текущие поддерживаемые значения описаны в парсинге Tool Call (Dynamo) и парсинге Reasoning (Dynamo).

Эмбеддинги промпта​

Dynamo поддерживает эмбеддинги промпта vLLM: предварительно вычисленные эмбеддинги обходят токенизацию в Rust-фронтенде и декодируются в тензоры в worker.

  • Включаются с помощью --enable-prompt-embeds (по умолчанию отключено)
  • Эмбеддинги отправляются как PyTorch-тензоры в кодировке base64 через поле prompt_embeds в Completions API
  • Для больших эмбеддингов NATS должен быть настроен на максимальный payload 15MB (уже задано в развертываниях по умолчанию)

Согласованность хеширования для событий KV​

При использовании маршрутизации с учетом KV обеспечьте детерминированное хеширование во всех процессах, чтобы избежать расхождений в radix tree. Выберите один из следующих вариантов:

  • Задайте PYTHONHASHSEED=0 для всех процессов vLLM, если вы полагаетесь на встроенное хеширование Python для prefix caching.
  • Если ваша версия vLLM это поддерживает, настройте детерминированный алгоритм prefix caching:
vllm serve ... --enable-prefix-caching --prefix-caching-algo sha256

См. общие заметки о детерминированных идентификаторах событий в дизайне Router.

Корректное завершение работы​

Воркеры vLLM используют механизм корректного завершения работы в Dynamo. При получении SIGTERM или SIGINT:

  1. Отмена регистрации в discovery: worker удаляется из service discovery, поэтому новые запросы больше не маршрутизируются к нему
  2. Льготный период: выполняющимся запросам разрешается завершиться (настраивается через DYN_GRACEFUL_SHUTDOWN_GRACE_PERIOD_SECS, по умолчанию 5s)
  3. Очистка ресурсов: освобождаются ресурсы движка и временные файлы (каталоги Prometheus, адаптеры LoRA)

Все конечные точки vLLM используют graceful_shutdown=True, то есть перед выходом они ждут завершения выполняющихся запросов. Внутренний VllmEngineMonitor также проверяет работоспособность движка каждые 2 секунды и инициирует завершение работы, если движок перестает отвечать.

Подробнее см. в разделе корректное завершение работы.

Проверки работоспособности​

У каждого типа worker есть специализированная полезная нагрузка проверки работоспособности, которая проверяет полный пайплайн inference:

Тип workerСтратегия проверки работоспособности
Decode / AggregatedКороткий запрос генерации (max_tokens=1) с использованием BOS-токена модели
PrefillТа же структура полезной нагрузки, что и для decode, адаптированная под формат prefill-запроса
vLLM-OmniКороткий запрос генерации через AsyncOmni с BOS-токеном модели

Проверки работоспособности регистрируются в среде выполнения Dynamo и вызываются фронтендом или Kubernetes liveness probes. Полезную нагрузку можно переопределить через переменную окружения DYN_HEALTH_CHECK_PAYLOAD. Более широкая архитектура проверок работоспособности описана в разделе проверки работоспособности.

Отмена запросов​

Когда пользователь отменяет запрос (например, отключаясь от фронтенда), запрос автоматически отменяется на всех workers, освобождая вычислительные ресурсы.

PrefillDecode
Aggregated✅✅
Disaggregated✅✅

Подробнее см. документацию по архитектуре отмены запросов.

Миграция запросов​

Dynamo поддерживает миграцию запросов, чтобы корректно обрабатывать сбои workers. Когда эта функция включена, запросы могут автоматически переноситься на работоспособные workers, если worker дает сбой в середине генерации. Подробности настройки см. в документации по архитектуре миграции запросов.

См. также​