Решения
Multi‑GPU и multi‑node: стратегии параллелизма, NCCL и топологии
Задача страницы. Помочь выбрать стратегию масштабирования (на одном узле и на кластере), понять, когда достаточно data‑parallel, а когда нужны шардирование модели (FSDP/ZeRO), tensor/pipeline‑параллелизм, и как топология (NVLink/NVSwitch/сеть) влияет на производительность.
Когда масштабировать и «что именно»
- Хотите выше throughput при том же размере модели → начните с data parallel (DDP). Модель копируется на каждый GPU, градиенты синхронизируются all‑reduce; профиль «быстро и просто», но память параметров дублируется на всех девайсах.
- Модель не влезает в один GPU → используйте шардирование модели (FSDP/ZeRO), чтобы распределить параметры/градиенты/состояния оптимизатора между участниками.
- Даже после шардирования узкое место — математика слоя → добавляйте tensor parallel (деление внутри слоя) и/или pipeline parallel (деление по слоям), комбинируя с DDP в «3D‑параллелизм».
Три оси параллелизма — кратко
Data parallel (DDP)
Каждый процесс тренирует полную копию модели на своей доле данных; после backward выполняется all‑reduce градиентов (NCCL). Отлично масштабируется по узлам, но дублирует память модели.
Model sharding (FSDP / ZeRO)
FSDP шардирует параметры, градиенты и состояния оптимизатора между процессами, загружая «кусок» модели на каждый GPU и сокращая пиковое потребление VRAM; вдохновлён идеями ZeRO из DeepSpeed (стадии 1–3).
Tensor / Pipeline parallel
- Tensor parallel режет крупные матричные операции внутри слоя (например, attention/FFN), требуя скоростной связи между GPU. Реализовано, в частности, в Megatron‑LM.
- Pipeline parallel делит сеть по слоям на стадии; микро‑батчи «текут» по конвейеру, уменьшая idle‑время; есть варианты расписаний (в т.ч. interleaved), комбинируется с DDP/TP.
NCCL и топологии связи
дают значительно более высокую пропускную способность и низкие задержки по сравнению с PCIe; TP обычно стоит «паковать» внутри NVLink‑домена.
NCCL поверх высокоскоростной сети (например, RoCE/IB или быстрый Ethernet). Для PP/DP межузловая связь обычно переносится легче, чем для TP.
Как выбрать стратегию (решающее дерево)
- Модель помещается в память 1 GPU?
— Да → DDP (простота, масштабируемость).
— Нет → FSDP/ZeRO (шардирование модели/состояний). - Всё ещё упираетесь в вычисления/скорость слоя?
— Добавьте TP (внутрислойное деление) и оставьте FSDP/ZeRO для экономии памяти. - Глубокая модель, хорошие ссылки между узлами?
— Добавьте PP (деление по слоям) и «намотайте» микро‑батчи для заполнения конвейера. - Большой кластер?
— Комбинируйте DDP × TP × PP (3D‑параллелизм) и подбирайте факторы под топологию кластера.
Инференс на нескольких GPU/узлах
- vLLM поддерживает распределённый инференс (tensor/pipeline‑parallel) и масштабирование реплик; удобно для высоких TPS при генерации.
- TensorRT‑LLM (в т.ч. через бэкенд Triton) использует MPI/коллективы и поддерживает режимы распределённого запуска на нескольких GPU/узлах для минимальной латентности.
Быстрый старт: типовые команды
Одноузловой DDP (8 GPU):
torchrun --standalone --nproc_per_node=8 train.py --config cfg.yaml
См. основы DDP и рекомендации по разбиению данных/эмбеддингу самплеров.
Многоузловой запуск (2 узла):
# На узле rank 0
torchrun --nnodes=2 --node_rank=0 --nproc_per_node=8 \
--rdzv_backend=c10d --rdzv_endpoint=<host0>:29500 train.py
# На узле rank 1
torchrun --nnodes=2 --node_rank=1 --nproc_per_node=8 \
--rdzv_backend=c10d --rdzv_endpoint=<host0>:29500 train.py
Проверьте согласованность world_size = nnodes * nproc_per_node и доступность rendezvous‑порта.
DeepSpeed (ZeRO/FSDP‑подходы):
deepspeed --num_gpus=8 train.py --deepspeed ds_config.json
Выбирайте ZeRO‑стадии/оффлоады в конфиге в зависимости от VRAM и пропускной способности сети.
Практические настройки, которые «делают погоду»
- Микро‑батчи и grad accumulation. Для PP количество микро‑батчей ≥ числу стадий, чтобы заполнить конвейер; для DDP/FSDP — используйте accumulation для выхода на целевой эффективный батч.
- Чекпоинтинг активаций. Снижает пик памяти, особенно полезен в TP/PP‑схемах. (См. общий гайд по оптимизации производительности.)
- Размещение по топологии. TP внутри NVLink/NVSwitch; PP/DP — между узлами; минимизируйте сквозные «дорогие» обмены.
- Коллективы NCCL. Следите за балансом all‑reduce/all‑gather/reduce‑scatter; избыточные обмены «съедают» масштабирование.
Типовые композиции (ориентиры)
- Средние LLM (влезают в 1 GPU по параметрам): DDP × (grad_accum) — просто и быстро.
- Крупные LLM (не влезают): FSDP (или ZeRO‑3) × DDP; при необходимости добавить TP для ускорения слоёв.
- Очень глубокие сети/много узлов: PP × TP × DDP с расписанием конвейера (interleaved, 1F1B), под NVLink/межузловую сеть.
Типичные проблемы и диагностика
- Зависания/таймауты. Несогласованные world_size/rank, закрытый rendezvous‑порт, разные версии NCCL/драйверов. Проверьте запуск «hello‑world» и конфигурацию сети перед тренировкой.
- Низкая загрузка GPU. Конвейер не заполнен (PP), «узкие» коллективы NCCL, горячие точки в I/O. См. чек‑лист в /solutions/performance-tuning/.
- Out‑of‑memory. Снизьте размер микро‑батча, включите checkpointing, перейдите на FSDP/ZeRO‑3.
Навигация по смежным страницам