Как PCIe bottleneck проявляется в multi-GPU инференсе?

Краткий тезис

PCIe bottleneck в multi-GPU инференсе возникает из-за колоссальной разницы в пропускной способности между шиной PCIe (до 64 ГБ/с для Gen5 x16) и прямыми межсоединениями GPU, такими как NVLink (до 900 ГБ/с на H100). При использовании tensor parallelism, требующей частых синхронных обменов активациями и градиентами между GPU, PCIe становится узким местом, резко увеличивая latency инференса. NVLink решает эту проблему, обеспечивая высокоскоростное прямое соединение GPU, что критически важно для больших моделей и agentic RAG-систем, где время ответа агента напрямую зависит от скорости инференса.

1. Термины: PCIe, NVLink, multi-GPU inference, tensor parallelism

• PCIe (Peripheral Component Interconnect Express) — стандартная шина для подключения периферийных устройств (включая GPU) к процессору и друг к другу через чипсет/CPU. Пропускная способность одного линка Gen5 x16 — 64 ГБ/с в одну сторону (128 ГБ/с двунаправленно).
• NVLink — высокоскоростное прямое соединение между GPU от NVIDIA, обеспечивающее пропускную способность до 900 ГБ/с на H100 (18 линков по 50 ГБ/с каждый). Позволяет GPU обмениваться данными без участия CPU/PCIe.
• Multi-GPU inference — запуск одной модели на нескольких GPU для уменьшения latency или увеличения пропускной способности. Используется для больших моделей, не помещающихся в память одной GPU.
• parallelism|Tensor parallelism — стратегия параллелизма, при которой слои модели разрезаются по измерениям тензоров (например, веса матрицы делятся между GPU). Каждый GPU вычисляет часть выхода, после чего требуется all-reduce для объединения результатов. Требует очень частых коммуникаций на каждом шаге forward pass.

2. Архитектура multi-GPU систем: PCIe switch vs NVSwitch

В современных серверах GPU могут соединяться двумя способами:

NVSwitch — это специализированный коммутатор, который обеспечивает полную топологию «каждый с каждым» (all-to-all) с максимальной пропускной способностью. В системах без NVSwitch (например, 2 GPU на одной плате) NVLink может быть прямым соединением между двумя GPU.

3. Пропускная способность: сравнение PCIe поколений и NVLink

Ключевой факт: NVLink на H100 в 14 раз быстрее PCIe Gen5 x16 (900 vs 64 ГБ/с). Даже PCIe Gen5 уступает NVLink в 14 раз. Это делает PCIe непригодным для tensor parallelism на больших моделях.

4. Tensor parallelism и коммуникационные паттерны

При tensor parallelism (TP) каждый GPU хранит часть весов одного слоя. На каждом forward pass:

1. Каждый GPU вычисляет свою часть линейного преобразования (например, X @ W_i).
2. Затем требуется all-reduce для суммирования результатов со всех GPU (или reduce-scatter + all-gather для некоторых вариантов).

Размер передаваемых данных: для скрытой размерности d и N GPU, каждый GPU передаёт d/N элементов (например, float16 — 2 байта). Для модели с d=8192 и N=8 это 2 КБ на один all-reduce. Но таких all-reduce много — по одному на каждый слой. Для модели с 80 слоями и длиной последовательности 4096 токенов, общий объём коммуникаций может достигать сотен мегабайт за один forward pass.

Влияние PCIe bottleneck: при PCIe latency ~10 мкс на сообщение и пропускной способности 64 ГБ/с, время передачи 1 МБ составит ~16 мкс. Но при большом количестве мелких сообщений (каждый all-reduce — маленький пакет) latency доминирует. NVLink с latency ~1 мкс и пропускной способностью 900 ГБ/с даёт выигрыш в 10–50 раз.

5. Pipeline parallelism и его влияние на bottleneck

Pipeline parallelism (PP) делит модель по слоям: каждый GPU обрабатывает несколько последовательных слоёв. Коммуникации происходят только на границах между GPU (передача активаций вперёд и градиентов назад). Объём передаваемых данных — размер скрытого состояния (например, 8192 * 4096 * 2 байта = 64 МБ для batch size 1). Такие передачи происходят реже (один раз на микро-батч), поэтому PCIe bottleneck менее критичен, чем для TP. Однако при большом количестве GPU в pipeline (например, 16) и частых микро-батчах, PCIe всё равно может стать узким местом.

6. Data parallelism и all-reduce операции

Data parallelism (DP) — каждый GPU хранит полную копию модели, обрабатывает разные батчи данных. Коммуникации нужны только для синхронизации градиентов (all-reduce) после backward pass. Размер all-reduce равен размеру модели (например, 7B параметров * 2 байта = 14 ГБ). При DP на PCIe время all-reduce может быть огромным (14 ГБ / 64 ГБ/с = 0.22 с только на передачу, плюс latency). NVLink ускоряет это до 14 ГБ / 900 ГБ/с = 0.016 с. Однако для инференса DP обычно не используется (каждая GPU делает независимый инференс), поэтому bottleneck проявляется в основном при TP и PP.

7. Измерение bottleneck: профилирование и метрики

Для обнаружения PCIe bottleneck используют профилировщики:

• NVIDIA Nsight Systems — показывает временные диаграммы коммуникаций и вычислений.
• PyTorch Profiler — записывает события CUDA и NCCL.
• NCCL (NVIDIA Collective Communications Library) — библиотека для коллективных операций; её логи показывают, какой транспорт используется (PCIe, NVLink, InfiniBand).

Метрики:

• Compute/Communication overlap — доля времени, когда GPU вычисляет одновременно с передачей данных. Если overlap мал, bottleneck силён.
• Time per all-reduce — замер latency для разных размеров сообщений.
• Bus utilization — загрузка шины PCIe (можно посмотреть через nvidia-smi topo -m и nvidia-smi).

8. Стратегии смягчения bottleneck: оптимизация коммуникаций

Если NVLink недоступен (например, в облачных инстансах без NVSwitch), можно:

• Использовать pipeline parallelism вместо tensor parallelism — меньше коммуникаций.
• Увеличить размер батча — чтобы амортизировать latency PCIe на больший объём данных.
• Применить коммуникационные оптимизации NCCL: NCCL_ALGO=Ring (кольцевой all-reduce) или NCCL_PROTO=Simple (для маленьких сообщений).
• Использовать InfiniBand (если есть) — пропускная способность до 400 ГБ/с (HDR), что быстрее PCIe, но медленнее NVLink.
• Сжать градиенты/активации (например, FP16 -> FP8) — уменьшает объём передаваемых данных.
• Переключиться на модель меньшего размера или использовать quantization (INT8/FP4) — модель помещается в одну GPU, multi-GPU не нужен.

9. Пример кода: профилирование времени передачи через PCIe vs NVLink

import torch
import torch.distributed as dist
import os

# Инициализация распределённой среды (предполагается 2 GPU)
dist.init_process_group(backend='nccl')
rank = dist.get_rank()
world_size = dist.get_world_size()

# Создаём тензор на GPU
tensor = torch.randn(1024, 1024, dtype=torch.float16, device=f'cuda:{rank}')

# Замер времени all-reduce
start = torch.cuda.Event(enable_timing=True)
end = torch.cuda.Event(enable_timing=True)

start.record()
dist.all_reduce(tensor, op=dist.ReduceOp.SUM)
end.record()
torch.cuda.synchronize()

elapsed_ms = start.elapsed_time(end)
print(f"Rank {rank}: all-reduce 2 MB took {elapsed_ms:.2f} ms")

# Чтобы увидеть, какой транспорт используется, можно установить
# os.environ['NCCL_DEBUG'] = 'INFO'
# В логах будет строка NCCL INFO Using network: PCIe или NVLink

Ожидаемый результат: на системе с NVLink время будет в 5–10 раз меньше, чем на PCIe.

10. Влияние на agentic RAG: почему это важно для агентов

В agentic RAG агент (LLM) выполняет несколько шагов: планирование, retrieval, вызов инструментов, генерация ответа. Каждый шаг требует инференса LLM. Если инференс медленный из-за PCIe bottleneck, общее время ответа агента растёт. Для агентов, работающих в реальном времени (чат-боты, ассистенты), это критично. Использование multi-GPU с NVLink позволяет:

• Уменьшить latency инференса в 2–5 раз для больших моделей (70B+).
• Обрабатывать больше запросов в секунду (throughput).
• Поддерживать сложные multi-step агентов без превышения таймаутов.

Таким образом, понимание PCIe bottleneck — не просто техническая деталь, а фактор, влияющий на архитектуру agentic RAG-системы.

Пет-проект для закрепления

Задача: Написать скрипт, который измеряет время all-reduce для тензоров разных размеров (1 КБ, 1 МБ, 100 МБ) на двух GPU, и определяет, используется ли NVLink или PCIe.

Инструменты: Python, PyTorch, NCCL, nvidia-smi, nvidia-smi topo -m.

Шаги:

1. Установить PyTorch с поддержкой CUDA и NCCL.
2. Написать скрипт, который инициализирует dist.init_process_group(backend='nccl').
3. Для каждого размера тензора (от 256 до 2^24 элементов float16) запустить all-reduce 100 раз, усреднить время.
4. Вывести таблицу: размер, среднее время, пропускная способность (размер/время).
5. Запустить с NCCL_DEBUG=INFO и проанализировать логи: если видно NVLink — NVLink используется, если PCIe — bottleneck.
6. Сравнить с теоретической пропускной способностью PCIe Gen5 (64 ГБ/с) и NVLink (900 ГБ/с).

Ожидаемый результат: График зависимости времени от размера сообщения, на котором видно резкое увеличение latency для маленьких сообщений на PCIe (из-за latency) и насыщение пропускной способности на больших сообщениях. Для NVLink время будет значительно меньше.

Связь с другими вопросами

Навигация

• Предыдущий: 306
• Следующий: 308
• Индекс: 00. Индекс разборов