Больше интересного про инференс, AI-инфраструктуру и практику с LLM я публикую в Telegram-канале @fuckup_files.

Когда модель не влезает в одну видеокарту, в vLLM появляются три флага: --tensor-parallel-size, --pipeline-parallel-size и --data-parallel-size. Их часто выставляют наугад, по принципу «поставлю побольше — будет быстрее», а потом удивляются, почему инференс на двух картах работает медленнее, чем на одной. Это статья про то, чем tensor parallel vs pipeline parallel vs data parallel отличаются на самом деле, что именно каждый из них «разрезает», и как выбрать правильный вид параллелизма (parallelism) под своё железо.

Разберём три (а на самом деле четыре) способа раскидать LLM по нескольким GPU, их компромиссы по памяти, сети и задержке, и дадим короткий алгоритм выбора.

TL;DR

• Tensor Parallel (TP) режет каждый слой поперёк: все GPU считают один и тот же слой одновременно. Много коммуникации (all-reduce на каждом слое) → нужна быстрая шина (NVLink). Снижает задержку одного запроса.
• Pipeline Parallel (PP) режет модель по слоям на стадии: каждая GPU держит свой кусок слоёв. Коммуникации мало (передача активаций на границах) → терпит PCIe и Ethernet между серверами. Растит throughput, но создаёт «пузырь» (bubble).
• Data Parallel (DP) не режет модель вообще: поднимает несколько полных копий и раскидывает по ним запросы. Линейный рост throughput, но модель должна влезать в свою группу GPU.
• Expert Parallel (EP) — четвёртое измерение, только для MoE: эксперты раскладываются по GPU.

Сначала проверь: а нужен ли вообще multi-GPU

Самая частая ошибка — лезть в параллелизм, не посчитав память. Прежде чем разрезать модель, проверь два варианта попроще:

1. Посчитай VRAM честно. Веса — это не вся история: KV cache и overhead вполне могут добавить ещё столько же. Разбор с формулами — в статье Сколько VRAM нужно для LLM.
2. Ужми модель. Квантизация (quantization) часто превращает «не влезает в 24 ГБ» в «влезает с запасом», без всякого multi-GPU. Что выбрать под своё железо — в статье Квантизация LLM в 2026.

Если после этого модель всё равно не влезает в одну карту — или влезает, но не держит нужный поток запросов — тогда выбираем вид параллелизма.

Что вообще можно «разрезать»

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

• По ширине слоя (матрицы внутри слоя) → Tensor Parallel.
• По глубине (сами слои) → Pipeline Parallel.
• По потоку запросов (копии модели) → Data Parallel.

Дальше — про каждую ось отдельно: что режется, сколько коммуникации, и где оно ломается.

Data Parallel (DP): просто больше реплик

Самый простой случай. Модель влезает в одну GPU (или в одну небольшую TP-группу), но одна копия не вытягивает нужный RPS. Решение — поднять несколько одинаковых копий и поставить перед ними балансировщик, который раскидывает запросы.

• Что режется: ничего в самой модели. Режется только поток запросов между репликами.
• Память: каждая реплика держит полную копию весов и свой KV cache. DP не помогает влезть в память — он помогает обслужить больше запросов.
• Коммуникация: на инференсе между репликами её почти нет (только роутинг на балансировщике). Это принципиально отличается от Data Parallel в обучении, где после каждого шага идёт тяжёлый all-reduce градиентов — про это в статье Distributed Data Parallel Training.
• Эффект: throughput растёт почти линейно по числу реплик, задержка одного запроса не меняется.

Отдельно стоит знать: в vLLM есть режим data-parallel attention для MoE — attention-часть реплицируется как DP, а эксперты раскладываются через Expert/Tensor Parallel. Но это уже про MoE, к этому вернёмся ниже.

Tensor Parallel (TP): режем каждый слой поперёк

Здесь модель не помещается в одну карту, и мы режем каждый слой на N частей. Большие матрицы (проекции attention, MLP) делятся между GPU по столбцам/строкам, и все карты считают один и тот же слой одновременно, каждая — свой кусок.

• Что режется: веса внутри каждого слоя. На N карт каждая держит ~1/N весов и ~1/N KV cache.
• Коммуникация: дорогая. После attention-блока и после MLP-блока нужно собрать результаты — это две операции all-reduce на каждый слой. У 32-слойной модели это десятки коллективных операций на один forward, с большим объёмом данных. Поэтому TP упирается в пропускную способность шины между GPU.
• Железо: TP хорош там, где есть NVLink. Если карты соединены только через PCIe (или это что-то вроде L40S без быстрого интерконнекта), all-reduce начинает съедать весь выигрыш — и multi-GPU может оказаться медленнее одной карты на коротких ответах. Доки vLLM прямо рекомендуют в таком случае брать pipeline parallel вместо tensor parallel.
• Эффект: снижает задержку (latency) одного запроса — вычисление одного forward честно параллелится. Но только при быстрой шине.
• Ограничение: размер TP должен делить число attention-голов (и размерности скрытого слоя). --tensor-parallel-size 8 на модели, где голов не кратно 8, просто не стартует.

# одна нода, 4 GPU с NVLink, модель не влезает в одну карту
vllm serve Qwen/Qwen3-32B --tensor-parallel-size 4

Pipeline Parallel (PP): режем модель по слоям

Тот же случай — модель не влезает, — но режем по другой оси. Слои делятся на группы (стадии), и каждая GPU держит свою группу слоёв. Запрос проходит стадию 1 → стадия 2 → … → выход.

• Что режется: глубина. GPU №1 держит слои 0–15, GPU №2 — слои 16–31 и т.д.
• Коммуникация: дешёвая. Между стадиями передаётся только активация на границе — это point-to-point, маленький объём. Поэтому PP терпит медленную сеть: PCIe внутри ноды, обычный Ethernet между серверами.
• Проблема — «пузырь» (pipeline bubble): пока запрос идёт по стадии 1, стадии 2–N простаивают. Если запросов мало, GPU большую часть времени ничего не делают. Лечится большим числом одновременных запросов, которые заполняют конвейер — здесь как раз спасает continuous batching в vLLM.
• Эффект: в основном растит throughput при высокой конкуренции. Задержку одного запроса PP не снижает (и даже чуть добавляет на передачах).
• Ограничение: число слоёв желательно кратно размеру PP (vLLM умеет и неравномерный split, но тогда следи за балансом памяти — перекошенная стадия словит OOM первой).

PP — это основной механизм, когда нужно объединить несколько серверов с GPU для одной модели. Практический разбор такого запуска на Ray + vLLM — в статье Распределённый запуск LLM на нескольких GPU с Ray и vLLM.

Expert Parallel (EP): четвёртое измерение для MoE

В 2026 почти все флагманские открытые модели — это Mixture-of-Experts: DeepSeek V4, Qwen 3.x, Kimi K2.x, GLM. У MoE параметров много (например, «1.6T всего, 49B активных»), но на каждый токен работает лишь часть экспертов.

Для таких моделей появляется Expert Parallel: эксперты (отдельные FFN-блоки) раскладываются по разным GPU, и токены маршрутизируются к нужным экспертам. vLLM умеет комбинировать data-parallel attention с expert/tensor parallel для MoE-слоёв. Главная боль EP — дисбаланс нагрузки: токены распределяются по экспертам неравномерно, и часть GPU перегружается, а часть простаивает.

EP — большая отдельная тема (DeepEP, балансировка, large-scale serving на десятках карт), про неё будет отдельный пост. Здесь достаточно запомнить: для MoE это четвёртое измерение параллелизма поверх TP/PP/DP.

Как это комбинируется: гибридный параллелизм

В реальных конфигурациях оси комбинируются. Общее число GPU под одну копию модели:

world size = tensor_parallel_size × pipeline_parallel_size

а сверху можно поднять несколько таких копий через Data Parallel.

Каноническая схема для нескольких серверов: TP внутри ноды (там быстрый NVLink) + PP между нодами (там обычная сеть).

# две ноды по 8 GPU: TP=8 внутри каждой ноды, PP=2 между нодами
vllm serve <model> \
  --tensor-parallel-size 8 \
  --pipeline-parallel-size 2 \
  --distributed-executor-backend ray

# модель влезает в 1 GPU, нужен throughput — поднимаем реплики
vllm serve <model> --data-parallel-size 4

Внутри одной ноды vLLM использует multiprocessing (mp); для нескольких нод — ray. Как подбирать размер самих GPU-нод под inference — в статье Проектирование кластеров Kubernetes: выбор размера рабочих узлов.

Как выбрать: короткий алгоритм

1. Модель влезает в одну GPU?
   • Да, но не хватает RPS → Data Parallel (реплики за балансировщиком).
   • Нет → дальше.
2. Одна нода, есть NVLink?
   • Да → Tensor Parallel на число карт.
   • Нет (только PCIe / L40S) → Pipeline Parallel.
3. Несколько серверов? → TP внутри ноды + PP между нодами.
4. Модель — MoE? → добавляем Expert Parallel (+ DP attention).

Главный принцип: TP — там, где быстрая шина; PP — там, где сеть медленная; DP — когда модель уже влезает.

Где ломается

• TP по PCIe. All-reduce на каждом слое упирается в шину; на коротких ответах две карты в TP могут быть медленнее одной. Лечится переходом на PP или быстрым интерконнектом.
• PP при низкой конкуренции. Конвейер пустой → «пузырь» → GPU простаивают. Нужен поток запросов, заполняющий все стадии.
• Число голов не делится на TP size. vLLM не стартует. Проверь num_attention_heads % tensor_parallel_size == 0.
• Неравномерный split слоёв в PP. Перекошенная стадия ловит OOM раньше других, хотя суммарно памяти хватает.
• Путаница в world size. tensor_parallel_size × pipeline_parallel_size должно совпадать с числом выделенных GPU. Лишние/недостающие карты — частая причина «не поднимается».
• TP между серверами. Тянуть tensor parallel через Ethernet между нодами — почти всегда катастрофа по задержке. Между нодами — PP.

Частые вопросы

Сколько GPU нужно? Минимум — чтобы веса + KV cache влезли в выбранную TP×PP-группу (см. расчёт VRAM). Дальше число карт = tp × pp, и при необходимости умножаем на число реплик DP.

Нужен ли NVLink для tensor parallel? Очень желателен. Без быстрого интерконнекта TP теряет смысл — берите pipeline parallel.

Можно ли pipeline parallel между двумя серверами? Да, это типовой сценарий: PP отлично работает поверх обычной сети, потому что между стадиями передаются только активации.

Что быстрее — TP или PP? Для задержки одного запроса на ноде с NVLink — TP. Для throughput на слабой сети или без NVLink — PP. На двух серверах обычно комбинируют оба.

TP или DP, если модель влезает в одну карту? DP. TP в этом случае только добавит коммуникацию и, скорее всего, замедлит.

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

• Сначала посчитай VRAM и попробуй квантизацию — возможно, multi-GPU не нужен вовсе.
• Внутри ноды с NVLink, когда модель не влезает → Tensor Parallel.
• Между серверами или без NVLink → Pipeline Parallel (или TP внутри ноды + PP между).
• Модель влезает, но мало RPS → Data Parallel-реплики за балансировщиком.
• MoE-модели → добавляй Expert Parallel.
• Держи в голове два инварианта: world size = tp × pp и num_heads % tp == 0.

Параллелизм — это не «крутилка скорости», а выбор оси разреза под конкретное железо и нагрузку. Разрежешь не по той оси — получишь медленнее, чем на одной карте.

Заинтересовало? Больше практических разборов про LLM, инференс и AI-инфраструктуру — в моём Telegram-канале @fuckup_files.