В этом материале
Где находятся маршрутизация Dynamo, планирование и перенос кэша относительно движка инференса и когда для нагрузки достаточно обычного сервиса vLLM.
Dynamo и vLLM не являются просто двумя взаимозаменяемыми программами генерации ответа. vLLM предоставляет движок инференса и функции сервинга. NVIDIA Dynamo добавляет среду координации распределённых компонентов, в том числе движков. Полезное сравнение начинается с обязанностей, которые нужно согласовать в развёртывании, а не с выбора победителя по названию продукта. Один и тот же сервис способен использовать оба проекта одновременно.
Нарисуйте карту ответственности
Отметьте токенизацию, планирование внутри воркера, исполнение модели и генерацию токенов. Затем добавьте выбор воркера, согласование пулов prefill и decode, планирование ёмкости и перенос повторно используемого состояния. Некоторые обязанности встречаются на разных уровнях: подпишите реализацию, которая действительно отвечает за каждую из них.
Введение в Dynamo описывает модульные маршрутизацию, планирование и перемещение данных. Эти функции решают задачи координации. Они не означают автоматического увеличения памяти GPU или качества модели при одной лишь смене внешней среды исполнения.
Учтите совместное использование
NVIDIA публикует обзор backend vLLM для Dynamo. Поэтому выбор «либо одно, либо другое» вводит в заблуждение: vLLM может исполнять модель внутри топологии Dynamo. Конкретные сочетания функций всё равно требуют проверки по документированной матрице версий.
Отделяйте обычный сервинг от поддержки определённого коннектора разнесённых фаз, квантования и менеджера кэша. Наличие backend в списке не обещает беспрепятственного сочетания всех независимых возможностей двух проектов. Фиксируйте версии, которые действительно проверили вместе, и границы полученного результата.
Определите смысл распределения
Руководство vLLM по параллелизму уже описывает варианты исполнения на нескольких GPU и узлах. Добавление Dynamo не является обязательным условием для любой модели, размещённой на нескольких ускорителях.
Уточните нерешённую проблему: размещение весов, масштабирование реплик, выбор воркера со знакомым контекстом или независимый размер пулов prefill и decode. Для этого нужны разные механизмы. Попытка решить проблему размещения модели одним слоем оркестрации оставляет нетронутыми реальные требования к тензорной раскладке и связям между ускорителями.
Сравните полную стоимость эксплуатации
Возьмите небольшую топологию сервиса за базу. Добавляйте компоненты координации для определённого эксперимента, сохраняя модель и трассу запросов. Измеряйте полезно завершённую работу, задержку первого токена и стриминга, восстановление после потери воркера и труд оператора.
Включите discovery, метрики, решения планировщика и сервисы передачи в эксплуатационный бюджет. Улучшенное размещение бывает ценно, но новая управляющая зависимость также усложняет диагностику. Опишите компоненты, необходимые для завершения обычного запроса, и способы обнаружения их отказа, а не только нормальный путь прохождения данных.
Выбирайте по недостающей функции
Небольшое развёртывание вполне может остаться сервисом vLLM с обычным управлением репликами. Для большого развёртывания с измеримыми проблемами локальности кэша или размещения фаз координирующая среда может оказаться оправданной. Решение должно следовать наблюдаемому ограничению, а не внешней сложности схемы архитектуры.
Для распределённой GPU-сети дополнительно различайте быстрые кластерные соединения и связь между партнёрскими площадками через WAN. Поддержка распределённого исполнения не отменяет физику сети. До обещания общего пула определите границы независимо обслуживающих площадок и тесно связанных групп исполнения.
Материалы по теме
vLLM tensor-parallel-size: когда несколько GPU нужны одной модели, Скорость потока и задержка: как выбрать рабочий режим GPU.