# vLLM tensor-parallel-size: когда несколько GPU нужны одной модели

Как работает tensor-parallel-size в vLLM: распределение одной модели, топология GPU, ограничения архитектуры и сравнение с двумя репликами.

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

`--tensor-parallel-size` в vLLM задаёт участие нескольких GPU в распределённом выполнении одной модели. Это отличается от запуска независимых копий. Две карты с 24 GB не становятся единой 48 GB автоматически: движок должен поддерживать распределение архитектуры, а обмен между устройствами создаёт дополнительные требования и накладные расходы.

## Начните с причины объединения

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

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

## Проверьте совместимость архитектуры

Поддержка модели в движке не отменяет ограничений конкретной схемы параллелизма. У архитектуры могут быть требования к разделению тензоров и поддерживаемым числам устройств. Проверьте журнал и [справочник serve](https://docs.vllm.ai/en/stable/cli/serve/), а для выбора стратегии — [официальную оптимизацию](https://docs.vllm.ai/en/stable/configuration/optimization/).

В качестве примера синтаксиса для двух совместимых устройств используется `vllm serve MODEL --tensor-parallel-size 2`. Здесь `MODEL` нужно заменить проверенным checkpoint. Команда не подтверждает доступность двух карт и не является обещанием, что произвольная модель разделится именно таким способом.

## Исследуйте физическое соединение

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

Сценарий двух потребительских карт в настольном компьютере отличается от специализированной серверной платформы. На одной материнской плате второй слот может работать в другом режиме, а два ускорителя — делить ресурсы. Полезные развилки приведены в статьях [о PCIe](/ru/journal/gpu-pcie-bandwidth/) и [о нескольких GPU](/ru/journal/multi-gpu/).

## Сравните распределение и реплики

| Вариант | Что размещается | Что проверять |
| --- | --- | --- |
| Одна модель на двух GPU | Части одной вычислительной задачи | Совместимость, обмен, задержка |
| Две независимые копии | Полная модель на каждой карте | Очередь, маршрутизация, общий поток |
| Один более ёмкий GPU | Модель на одном устройстве | Вместимость, контекст, доступность |

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

## Практические выводы

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

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