ТЕХНИЧЕСКОЕ ЗАДАНИЕ: Развернуть NCCL бенчмарк на 2-8 GPU

1. Цель задачи

Освоить запуск и интерпретацию результатов стандартного бенчмарка nccl-tests (all_reduce_perf) на кластере с несколькими GPU (2–8 штук). Научиться выявлять узкие места в меж-GPU коммуникации: различать пропускную способность NVLink (прямое соединение GPU) и PCIe (через CPU/Root Complex). В результате вы сможете быстро оценить реальную производительность interconnect и диагностировать типовые проблемы (неправильная топология, driver/cuda-версии, конфигурация MPI).

Ключевой результат Запуск all_reduce_perf на 2, 4, 8 GPU, запись результатов (bandwidth, latency), построение графика зависимости пропускной способности от размера сообщения и идентификация bottleneck (NVLink vs PCIe).

2. Исходные данные

Если нет реального кластера с GPU — симулируем:

1. Используйте инстанс с одной GPU и запустите all_reduce_perf с -b 8 -e 128M -f 2. Это даст данные только для одного узла, но можно сымитировать multi-GPU, указав -g 2 --cuda_graph_launch.
2. Альтернативно: возьмите опубликованные таблицы результатов из документации NVIDIA (NVLink vs PCIe) и на их основе постройте график-анализ.
3. Для симуляции bottleneck: установите переменные окружения NCCL_ALGO=Ring и NCCL_NET_GDR_LEVEL=0 (отключение GPU Direct RDMA), чтобы увидеть более низкую пропускную способность и сравнить с нормальным режимом.

3. Технологический стек

4. Этапы выполнения

Этап 1: Установка и проверка окружения (30–45 минут)

Действия

1. Проверить наличие GPU и драйвера

   • nvidia-smi — вывести список GPU, убедиться что видно все 2–8 карт.
   • Зафиксировать версию драйвера и архитектуры (например, A100, V100, H100).

2. Проверить CUDA и NCCL

   • nvcc --version (CUDA 11.0+).
   • dpkg -l | grep nccl или rpm -qa | grep nccl — убедиться, что NCCL установлен (обычно входит в CUDA Toolkit).
   • Если нет — установить sudo apt install libnccl-dev libnccl2 (Ubuntu) или sudo yum install libnccl.

3. Клонировать и собрать nccl-tests

   git clone https://github.com/NVIDIA/nccl-tests.git
   cd nccl-tests
   make MPI=0   # если MPI не нужен для одной ноды; MPI=1 если есть MPI и multi-node
   

   • В случае ошибок убедиться, что CUDA bin и lib в PATH и LD_LIBRARY_PATH.

4. Проверить топологию NVLink

   • nvidia-smi topo]] -m]] — вывести матрицу связности (PIX, PXB, NODE, NV). NV означает NVLink.
   • nvidia-smi nvlink -s — статус NVLink линков (количество активных, ошибки CRC).
   • Ожидаемый результат этапа Окружение готово, топология зафиксирована, бинарник all_reduce_perf собран.

Этап 2: Запуск all_reduce_perf для 2, 4, 8 GPU (30–45 минут)

Действия

1. Запустить тест для 2 GPU

   ./all_reduce_perf -b 8 -e 128M -f 2 -g 2 -n 5 -w 5
   

   • Опции: -b 8 (min size 8 bytes), -e 128M (max size 128MB), -f 2 (factor 2 — размер удваивается), -g 2 (число GPU), -n 5 (число итераций для статистики), -w 5 (warmup).
2. Повторить для 4 GPU и 8 GPU:
   • Изменить -g на 4 и 8 (если доступно). Если GPU меньше 8, используйте то, что есть (например, 4).
3. Записать вывод в файл

   ./all_reduce_perf -b 8 -e 128M -f 2 -g 2 -n 5 -w 5 | tee results_nccl_2gpu.log
   

4. Запустить с принудительным отключением NVLink (для контраста):
   • NCCL_ALGO=Ring NCCL_NET_GDR_LEVEL=0 ./all_reduce_perf -b 8 -e 128M -f 2 -g 2 -n 5 -w 5 — это приведёт к использованию только PCIe (через P2P или CPU), bandwidth будет ниже.
   • Записать как results_pcie.log. Ожидаемый результат этапа Сырые данные по bandwidth и latency для каждого размера сообщения, для разных конфигураций GPU (2,4,8) и для режима PCIe-only.

Этап 3: Парсинг результатов и построение графика (30–40 минут)

Действия

1. Считать данные из логов с помощью Python:

   • В выводе all_reduce_perf столбцы: size, count, type, redop, root, time, algbw, busbw.
   • algbw — алгоритмическая пропускная способность (GB/s), busbw — фактическая bandwidth шины (обычно algbw * (n-1)/n для all_reduce).
   • Пример парсинга (регулярками или pandas):

     import pandas as pd
     # текст лога в строку
     lines = """size       count   type   redop    root     time   algbw   busbw 
     8          1024    float  sum     -1      0.01     0.001   0.001
     16         1024    float  sum     -1      0.01     0.003   0.003
     ..."""
     # используем github.com/NVIDIA/nccl-tests/blob/master/doc/PERFORMANCE.md для формата
     

   • Удобнее использовать готовый скрипт parse_nccl_tests.py, но можно написать свой.

2. Построить график log-log plot: размер сообщения (bytes) vs bus bandwidth (GB/s).

   • Добавить линии для разных количеств GPU и для PCIe-only.
   • Добавить горизонтальные линии для теоретических пиков NVLink и PCIe (например, NVLink 4.0: 900 GB/s aggregated для 8 GPU, PCIe Gen5 x16: ~60 GB/s).

   import matplotlib.pyplot as plt
   plt.loglog(sizes, bw_2gpu, label='2 GPU (NVLink)')
   plt.loglog(sizes, bw_pcie, label='2 GPU (PCIe)')
   # ...
   plt.legend()
   

3. Определить bottleneck точка, где кривая выходит на плато или существенно ниже теоретического пика.

   • Если все кривые сливаются до определенного размера сообщения (например, <1MB) — это latency-bound, после — bandwidth-bound.
   • Сравнить с теоретическими линиями. Ожидаемый результат этапа График в PNG/SVG, чётко показывающий разницу NVLink vs PCIe.

Этап 4: Анализ и выводы (15–20 минут)

Действия

1. Зафиксировать максимальные bandwidth для каждой конфигурации:
   • Найти из данных busbw для самого большого размера сообщения (128MB).
   • Сравнить с паспортными данными:
     • NVLink 3.0 (V100): 600 GB/s aggregated (8 GPU).
     • NVLink 4.0 (A100): 900 GB/s aggregated.
     • PCIe 4.0 x16: ~32 GB/s (unidirectional).
2. Выявить bottleneck
   • Если bandwidth для 8 GPU не растёт линейно относительно 2 GPU => проблема в топологии (например, не все NVLink линки активны).
   • Если bandwidth в режиме NCCL_NET_GDR_LEVEL=0 близка к PCIe => подтверждение, что в нормальном режиме используется NVLink.
3. Написать краткий отчёт (3-5 предложений):
   • Например: "На кластере с 4 GPU A100 all_reduce достигает 400 GB/s при 128MB, что соответствует 4 NVLink линкам на GPU (4×50 GB/s). PCIe дает только 25 GB/s; основное узкое место — latency на маленьких сообщениях." Ожидаемый результат этапа Заполненный раздел анализа в файле README.

Этап 5: Проверка воспроизводимости и альтернативные протоколы (20–30 минут)

Действия

1. Запустить с разными алгоритмами
   • NCCL_ALGO=Ring (уже сделано), NCCL_ALGO=Tree, NCCL_ALGO=CollNet.
   • Сравнить результаты — убедиться, что Ring самый медленный для больших сообщений, Tree быстрее, CollNet ещё быстрее (на поддерживаемых GPU).
2. Проверить влияние NCCL_PROTO
   • NCCL_PROTO=LL (Low Latency), NCCL_PROTO=SIMPLE (высокая пропускная способность).
3. Запустить тест с -c 2 (используя только 2 канала NVLink) и сравнить.
   • NCCL_NCHANNELS=2 или флаг -c 2. Ожидаемый результат этапа Понимание влияния алгоритмов и протоколов на производительность.

5. Критерии приемки (Definition of Done)

• all_reduce_perf успешно собран и запущен на 2/4/8 GPU.
• Собраны логи для всех конфигураций (минимум 2,4,8 GPU + PCIe simulation).
• Построен график log-log bandwidth vs message size с подписями.
• На графике отмечены теоретические пики NVLink и PCIe для данной архитектуры.
• В выводах явно указано, где bottleneck (NVLink, PCIe, latency).
• Проведен эксперимент с отключенным NVLink (PCIe-only) для контраста.
• Проверено влияние хотя бы двух алгоритмов (Ring, Tree).
• Создан файл README.md с описанием окружения, команд запуска, графиком и интерпретацией.

6. Ожидаемый результат

Основной артефакт Каталог (например, nccl_benchmark_results) со следующими файлами:

• results_nccl_2gpu.log (и аналоги для 4, 8, pcie)
• bandwidth_plot.png — график.
• README.md — отчёт, включающий:
  • Информацию о кластере (GPU, драйвер, CUDA, топология).
  • Команды запуска.
  • Таблицу пиковых bandwidth для каждого размера.
  • Вывод о bottleneck.
• Дополнительно (опционально): analysis.py — скрипт для парсинга и построения графика.

7. Возможные сложности и их решение

8. Бюджет времени (оценка)

9. Связанные вопросы из базы знаний

10. Чек-лист самопроверки

• Я проверил, что nvidia-smi видит все GPU и их топология соответствует ожидаемой.
• Я убедился, что all_reduce_perf собрался без ошибок.
• Я запустил тесты минимум для 2, 4, 8 GPU (или доступного количества) и записал вывод в лог.
• Я построил график с нормальной шкалой (log-log) и отметил теоретические пики.
• Я выполнил тест с отключением NVLink (через переменные окружения) для контраста.
• В отчёте я объяснил, почему на маленьких размерах bandwidth мала (latency), а на больших упирается в пик интерконнекта.
• Я зафиксировал bottleneck: NVLink недогружен или уже насыщен; если насыщен — предложил что делать (увеличить число каналов, использовать Tree).