В этом материале
Выбор независимых реплик или тензорного разделения по размещению модели, локальности кэша, границам отказа и измеренным коммуникациям.
Добавление GPU может означать создание дополнительных реплик для запросов либо разделение вычислений одной модели между устройствами. Data parallel в сервинге и tensor parallel решают разные задачи. Их также можно сочетать: независимо планируемая реплика способна состоять из tensor-parallel группы. Поэтому перед сравнением ёмкости определите единицу исполнения, границу назначения запроса и фактическое количество копий весов.
Проверьте размещение всей модели
Оцените веса, рабочие буферы и состояние активных запросов для нужного контекста и конкурентности. Размещение при старте ещё не означает полезную конфигурацию сервинга. Оставьте запас памяти для реального набора запросов.
Руководство vLLM по параллелизму связывает раскладку с размещением модели и оборудованием. Tensor parallel способен сделать модель исполнимой на нескольких устройствах, но добавляет коммуникации. Если полезная полная реплика помещается на одном GPU, независимое копирование становится отдельным вариантом вместо автоматического разбиения.
Определите группу реплики
Документация data parallel vLLM описывает несколько рангов сервинга и взаимодействие с другими раскладками. Не считайте каждый процесс полностью независимой копией на одном GPU: устройство группы зависит от архитектуры модели и конфигурации.
Нарисуйте границу назначения запроса. Отметьте место его исполнения до завершения и совместно работающие ранги. Для гибридного варианта укажите число независимых групп и устройств в каждой. Это делает понятными учёт оборудования, реальную занятость памяти и область перезапуска при отказе одного процесса.
Учтите локальность кэша
Новые реплики распределяют входящую работу, но одновременно разносят повторяемые префиксы по разным кэшам. Руководство prefix caching объясняет значение подходящего сохранённого состояния. Нельзя оценивать выигрыш репликации по тесту, прогревающему только один воркер.
Повторите беседы с несколькими ходами наряду с независимыми запросами. Сравните обычный балансировщик с предполагаемой политикой сессий или локальности. Проверьте, не перегружает ли популярный контекст одну реплику при простое остальных. Копирование меняет возможности размещения, а не только количество счётчиков GPU на панели.
Сравните равный бюджет оборудования
Оставьте прозрачными суммарное число устройств, ревизию модели, трассу входов и генерацию. Сравните поддерживаемые раскладки по полезным завершениям, хвосту первого токена, равномерности вывода и памяти устройств. Включите время коммуникаций тензорных групп и неравномерность нагрузки реплик.
Проверьте потерю воркера. Отказ ранга связанной группы способен повлиять на сервис иначе, чем исчезновение независимой копии. Считайте недоступную ёмкость модели и время восстановления, а не просто процессы, оставшиеся запущенными после аварии.
Выберите решаемое ограничение
Используйте разделённую модель, когда размещение или измеренное исполнение оправдывает коммуникации. Добавляйте независимые группы, если нужно больше параллельных допустимых запросов и полную модель можно соответственно развернуть. Ни одна стратегия не гарантирует линейного роста полезной производительности от количества GPU.
Для нескольких площадок укажите самодостаточные реплики и устройства одной тесно связанной группы. Суммирование памяти удалённых машин в таблице не подтверждает работоспособный tensor parallel. Решение должно соответствовать фактической сети, задержкам и распределению ответственности за отказы в инфраструктуре провайдера.
Материалы по теме
vLLM tensor-parallel-size: когда несколько GPU нужны одной модели, Prefix caching: когда повторяющийся контекст помогает GPU-пулу.