# Data parallel и tensor parallel: реплики или разделённая модель?

Выбор независимых реплик или тензорного разделения по размещению модели, локальности кэша, границам отказа и измеренным коммуникациям.

Автор: Команда Retrivium
Обновлено: 2026-11-03
Канонический URL: https://retrivium.ai/ru/journal/data-parallel-vs-tensor-parallel-serving/
Language: ru

Добавление GPU может означать создание дополнительных реплик для запросов либо разделение вычислений одной модели между устройствами. Data parallel в сервинге и tensor parallel решают разные задачи. Их также можно сочетать: независимо планируемая реплика способна состоять из tensor-parallel группы. Поэтому перед сравнением ёмкости определите единицу исполнения, границу назначения запроса и фактическое количество копий весов.

## Проверьте размещение всей модели

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

[Руководство vLLM по параллелизму](https://docs.vllm.ai/en/stable/serving/parallelism_scaling/) связывает раскладку с размещением модели и оборудованием. Tensor parallel способен сделать модель исполнимой на нескольких устройствах, но добавляет коммуникации. Если полезная полная реплика помещается на одном GPU, независимое копирование становится отдельным вариантом вместо автоматического разбиения.

## Определите группу реплики

[Документация data parallel vLLM](https://docs.vllm.ai/en/latest/serving/data_parallel_deployment/) описывает несколько рангов сервинга и взаимодействие с другими раскладками. Не считайте каждый процесс полностью независимой копией на одном GPU: устройство группы зависит от архитектуры модели и конфигурации.

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

## Учтите локальность кэша

Новые реплики распределяют входящую работу, но одновременно разносят повторяемые префиксы по разным кэшам. [Руководство prefix caching](https://docs.vllm.ai/en/latest/features/automatic_prefix_caching/) объясняет значение подходящего сохранённого состояния. Нельзя оценивать выигрыш репликации по тесту, прогревающему только один воркер.

Повторите беседы с несколькими ходами наряду с независимыми запросами. Сравните обычный балансировщик с предполагаемой политикой сессий или локальности. Проверьте, не перегружает ли популярный контекст одну реплику при простое остальных. Копирование меняет возможности размещения, а не только количество счётчиков GPU на панели.

## Сравните равный бюджет оборудования

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

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

## Выберите решаемое ограничение

Используйте разделённую модель, когда размещение или измеренное исполнение оправдывает коммуникации. Добавляйте независимые группы, если нужно больше параллельных допустимых запросов и полную модель можно соответственно развернуть. Ни одна стратегия не гарантирует линейного роста полезной производительности от количества GPU.

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

## Материалы по теме

[vLLM tensor-parallel-size: когда несколько GPU нужны одной модели](/ru/journal/vllm-tensor-parallel-size/), [Prefix caching: когда повторяющийся контекст помогает GPU-пулу](/ru/journal/prefix-caching/).