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.

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

В этом документе описано, как Dynamo реализует миграцию запросов, чтобы корректно обрабатывать сбои worker'ов во время генерации текста LLM. Миграция запросов позволяет продолжающимся запросам переходить на другие worker'ы, когда исходный worker становится недоступен, обеспечивая отказоустойчивость и более удобный пользовательский опыт.

Обзор

Миграция запросов реализована через оператор Migration, который находится в конвейере обработки LLM между оператором Backend и бэкендом сервиса. Когда worker выходит из строя во время обработки запроса, система миграции сохраняет частичное состояние генерации и воссоздает запрос на новом worker'е, чтобы продолжить с места, где остановился предыдущий worker.

Компоненты архитектуры

Migrator

Система миграции встроена в конвейер обработки LLM между предварительной обработкой на frontend и фактическими бэкендами сервиса. Такое расположение позволяет ей перехватывать все потоки обмена данными и прозрачно управлять сценариями сбоев.

Основные обязанности:

• Перехватывает все запросы и ответы, проходящие через конвейер
• Определяет сценарии отказа worker'ов по шаблонам ошибок
• Управляет логикой повторных попыток с настраиваемыми лимитами миграции
• Отслеживает частичное состояние ответа для бесшовного продолжения

Настройка лимита миграции

Лимит миграции настраивается на уровне frontend и глобально применяется ко всем моделям, обслуживаемым этим frontend. Этот параметр задает максимальное число раз, когда запрос может быть перенесен на другой worker:

• Поведение по умолчанию: миграция запрещена (migration_limit=0)
• Задается флагом --migration-limit на frontend
• Применяется ко всем моделям, обслуживаемым frontend

Настройка максимальной длины последовательности

Параметр максимальной длины последовательности определяет, как долго система миграции будет кэшировать состояние токенов для запроса. Как только общая длина последовательности (prompt + сгенерированные токены) превышает этот лимит, миграция для этого запроса отключается, а отслеживание токенов останавливается:

• Поведение по умолчанию: без лимита (--migration-max-seq-len не задан)
• Задается флагом --migration-max-seq-len или переменной окружения DYN_MIGRATION_MAX_SEQ_LEN на frontend
• Предотвращает неограниченный рост потребления памяти при кэшировании длинных последовательностей
• Граница: значение ровно на лимите все еще допускает миграцию; отключает ее только строгое превышение
• Проверка выполняется и при инициализации запроса (длина prompt), и во время генерации (prompt + выходные токены)

Отслеживание состояния токенов и миграция запросов

Основа системы миграции - возможность сохранять и продолжать частичные генерации за счет управления состоянием токенов. Это гарантирует, что если worker выходит из строя в середине генерации, новый worker сможет бесшовно продолжить с точного места сбоя.

Процесс накопления токенов

Когда запрос обрабатывается и от worker'а поступают ответы, система миграции отслеживает каждый успешно сгенерированный токен:

1. Начальное состояние запроса: система начинает с исходного предварительно обработанного запроса, содержащего исходные токены prompt.

2. Отслеживание ответов: по мере поступления каждого ответа от worker'а система миграции извлекает вновь сгенерированные токены и добавляет их к последовательности токенов запроса. Так накапливаются все сгенерированные токены.

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

Сценарии запуска миграции

Система миграции обрабатывает два различных сценария отказа:

1. Миграция нового запроса (сбой начального соединения)

Сценарий: worker недоступен при создании начального соединения.

Шаблон ошибки: система обмена данными сообщает, что выбранный экземпляр worker'а недоступен.

Процесс миграции:

• Обнаруживает сбой соединения во время начальной настройки потока
• Уменьшает счетчик повторных попыток миграции
• Пытается создать новый поток с исходным запросом
• Частичного состояния сохранять не нужно, поскольку генерация еще не начиналась

2. Миграция выполняющегося запроса (обрыв в середине потока)

Сценарий: соединение потеряно во время активной генерации после получения частичных ответов.

Шаблон ошибки: завершение потока обнаружено до окончания генерации.

Процесс миграции:

1. Обнаружение сбоя: система определяет обрыв потока через мониторинг ошибок.

2. Сохранение состояния: к этому моменту последовательность токенов запроса содержит и исходные токены prompt, и все успешно сгенерированные токены от отказавшего worker'а.

3. Создание нового потока: создается новый поток с накопленным состоянием запроса, чтобы у нового worker'а был полный контекст.

4. Продолжение: новый worker получает запрос с полным контекстом токенов и продолжает генерацию с точного места, где остановился предыдущий worker.

Бесшовный поток токенов и эволюция состояния запроса

С точки зрения клиента поток токенов выглядит непрерывным и без прерываний. Клиент получает токены от первого worker'а до момента сбоя, а затем бесшовно продолжает получать токены от резервного worker'а, не замечая самой миграции.

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

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

Миграция прозрачна, потому что:

1. Во время перехода токены не теряются и не дублируются
2. Новый worker получает полный контекст через накопленную последовательность токенов
3. Генерация продолжается с точного места сбоя
4. Поток ответов сохраняет единый формат и тайминг

Этот механизм накопления токенов гарантирует, что миграции действительно бесшовны: вся вычислительная работа сохраняется, а качество генерации не ухудшается при переходе между worker'ами.

Преимущества

1. Отказоустойчивость: система продолжает работать при сбоях отдельных worker'ов
2. Эффективное использование ресурсов: частичные генерации сохраняются, а не запускаются заново
3. Бесшовный пользовательский опыт: пользователи не сталкиваются с прерываниями при сбоях worker'ов
4. Настраиваемое поведение: лимиты миграции позволяют подстраивать систему под требования развертывания
5. Отсутствие потери токенов: полное сохранение состояния генерации между миграциями

Соображения по проектированию

Система миграции спроектирована с учетом нескольких важных архитектурных соображений:

Поддержка нескольких моделей: поскольку frontend может одновременно обслуживать несколько моделей, лимит миграции настраивается на уровне frontend и единообразно применяется ко всем моделям, что упрощает эксплуатационное управление.

Управление состоянием: система тщательно отслеживает не только последовательности токенов, но и метаданные вроде оставшегося бюджета токенов, условий остановки и параметров сэмплирования, чтобы обеспечить полное сохранение состояния.

Обработка ошибок: система миграции различает разные типы отказов и применяет для каждого сценария подходящую стратегию восстановления.

Мониторинг и метрики

Система миграции предоставляет метрики Prometheus для мониторинга активности миграции. Эти метрики доступны на endpoint /metrics frontend'а (порт по умолчанию 8000):

• dynamo_frontend_model_migration_total: счетчик, отслеживающий общее число миграций запросов
  • Labels:
    • model: имя обслуживаемой модели
    • migration_type: либо new_request (сбой начального соединения), либо ongoing_request (обрыв в середине потока)
• dynamo_frontend_model_migration_max_seq_len_exceeded_total: счетчик, отслеживающий число случаев, когда миграция была отключена из-за превышения длиной последовательности заданного --migration-max-seq-len
  • Labels:
    • model: имя обслуживаемой модели

Пример вывода метрик:

dynamo_frontend_model_migration_total{migration_type="ongoing_request",model="Qwen/Qwen3-0.6B"} 3
dynamo_frontend_model_migration_total{migration_type="new_request",model="Qwen/Qwen3-0.6B"} 1
dynamo_frontend_model_migration_max_seq_len_exceeded_total{model="Qwen/Qwen3-0.6B"} 2

Эти метрики можно использовать, чтобы:

• отслеживать надежность worker'ов и шаблоны отказов
• настраивать оповещения о чрезмерной частоте миграций, которая может указывать на проблемы инфраструктуры
• оценивать эффективность механизмов отказоустойчивости
• отслеживать, как часто достигается --migration-max-seq-len, что может указывать на необходимость изменить лимит

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

Известные ограничения

Несколько вариантов (n > 1)

Миграция запросов не поддерживается для совместимых с OpenAI запросов, которые запрашивают несколько сгенерированных вариантов при n > 1. Dynamo отключает миграцию для таких запросов, даже если --migration-limit больше 0.

Почему: генерация нескольких вариантов ведет отдельное состояние вывода для каждого варианта. При миграции частично завершенного запроса пришлось бы независимо передавать для каждого варианта состояние сгенерированных токенов, оставшийся бюджет токенов, состояние завершения и состояние декодера. Текущий путь миграции сохраняет только одно состояние продолжения, поэтому повторная попытка для перемешанного запроса n > 1 могла бы продублировать или потерять вывод, специфичный для отдельных вариантов.

Это ограничение не затрагивает обычные запросы с одним вариантом, где n не указан или равен 1.

Guided Decoding (структурированный вывод)

Миграция запросов не поддерживается для запросов, использующих guided decoding (structured output / JSON schema). Когда worker выходит из строя в середине потока во время запроса с guided decoding, ошибка передается клиенту вместо попытки миграции.

Почему: inference-бэкенды инициализируют конечный автомат (FSM) guided decoding заново для каждого нового запроса и продвигают его только по вновь сгенерированным токенам, а не по токенам контекста/prompt. Когда частично завершенный запрос мигрирует на нового worker'а, новый worker воспроизводит уже сгенерированные токены как контекст, но запускает FSM с корня схемы. Это несоответствие между состоянием токенов и состоянием FSM приводит к поврежденному выводу - обычно к дублированному или вложенному JSON.

Это ограничение одинаково относится ко всем бэкендам (vLLM, SGLang, TRT-LLM).

Путь на будущее: поддержка миграции для запросов с guided decoding потребует сериализации и восстановления состояния FSM между worker'ами либо прогонки предыдущих выходных токенов через FSM на новом worker'е. Это отмечено как возможное улучшение в будущем.

Операционное влияние

Миграция запросов фундаментально меняет способ обработки сбоев: система переходит от подхода "fail-fast" к модели "graceful degradation". Этот архитектурный сдвиг обеспечивает более высокую доступность и лучшее использование ресурсов, сохраняя при этом тот же внешний API-контракт для клиентов.