GPU простаивает из-за узкого места в сети или неправильно сконфигурированных драйверов — типичная ситуация, когда кластер из 8 A100 выдаёт лишь 30% утилизации. Причина чаще всего лежит не в самих картах, а в том, как настроено окружение: медленный Interconnect, неправильные параметры NCCL, неоптимизированное хранилище. Мы за 5+ лет настроили более 20 GPU-кластеров и знаем, как выжать максимум из каждого ампер-часа. Подход простой: убираем узкие места по всей цепочке — от драйверов до планировщика задач.
Почему оборудование — только половина успеха?
Даже топовые карты не дадут прироста, если остальная система не сбалансирована. NVIDIA A100 (80GB SXM) с NVLink (600 GB/s внутри узла) и H100 (80GB SXM5) с HBM3 (3.35 TB/s) — мощные инструменты, но они требуют соответствующей инфраструктуры. Без InfiniBand и параллельной файловой системы (GPFS, Lustre) вы получите утилизацию GPU 30–50% вместо 85%+. Мы проектируем кластеры с учётом ваших рабочих нагрузок: для LLM с tensor parallelism критична скорость NVLink, для data parallelism — пропускная способность InfiniBand между узлами.
Как проверить производительность кластера после настройки?
После настройки обязательно проводим тесты AllReduce с помощью nccl-tests. Для 8x A100 ожидаемая пропускная способность — >280 GB/s при размере сообщения 1GB. Если значение ниже — ищем узкое место: NUMA affinity, версию драйвера, конфигурацию коммутатора. Также запускаем benchmark training для вашей модели (например, GPT-2 или BERT) и сравниваем throughput с ожидаемым. По данным NVIDIA, правильная настройка NUMA может дать прирост до 20%.
Процесс настройки GPU-кластера
- Аудит текущей инфраструктуры и требований — объём датасетов, тип моделей, ожидаемая частота обучения.
- Проектирование — выбор карт, количество узлов, тип Interconnect, файловая система.
- Установка драйверов и CUDA — production-версии, настройка persistence mode, оптимизация power limit.
- Настройка NCCL — fine-tuning параметров, тестирование AllReduce bandwidth (цель >280 GB/s на 8x A100).
- Интеграция с планировщиком — Slurm для batch-обучения или Kubernetes + GPU Operator для контейнеризации.
- Мониторинг и оптимизация — DCGM, Prometheus, дашборды с ключевыми метриками.
- Документация и обучение команды — как запускать задачи, диагностировать проблемы.
Пример: установка драйверов и CUDA
# Ubuntu 22.04 apt install linux-headers-$(uname -r) nvidia-driver-535 wget https://developer.download.nvidia.com/compute/cuda/12.3.0/local_installers/cuda_12.3.0_545.23.06_linux.run sh cuda_12.3.0_545.23.06_linux.run --silent --toolkit # cuDNN tar -xvf cudnn-linux-x86_64-8.9.7.29_cuda12-archive.tar.xz cp cuda/include/cudnn*.h /usr/local/cuda/include cp cuda/lib64/libcudnn* /usr/local/cuda/lib64 ldconfig nvidia-smi; nvcc --version Настройка NCCL и тестирование interconnect
apt install libnccl2 libnccl-dev git clone https://github.com/NVIDIA/nccl-tests cd nccl-tests && make ./build/all_reduce_perf -b 1G -e 4G -f 2 -g 8 # Ожидается: 1GB ~280 GB/s, 4GB ~300 GB/s (algbw) Выбор Interconnect: InfiniBand против Ethernet
| Параметр | InfiniBand HDR | Ethernet 100GbE |
|---|---|---|
| Пропускная способность | 200 Gbps | 100 Gbps |
| Латентность | ~1 µs | ~3–5 µs |
| Scaling efficiency для LLM | 85–90% | 60–70% |
| Поддержка RDMA | Нативная | Требуется RoCEv2 |
Для multi-node обучения с tensor parallelism InfiniBand — обязательное требование. Ethernet допустим только при малом числе узлов (2–4) или для inference.
Сравнение конфигураций: одноузловой vs multi-node
| Параметр | Одноузловой (8x GPU) | Multi-node (32+ GPU) |
|---|---|---|
| Interconnect | NVLink (600 GB/s) | InfiniBand HDR (200 Gbps) |
| Хранилище | Local NVMe | Параллельная ФС (Lustre) |
| Планировщик | Slurm / Kubernetes | Slurm + gang scheduling |
| Типичная задача | Fine-tuning LLaMA 7B | Pre-training GPT-3 175B |
Детали настройки NCCL
NCCL использует алгоритмы Tree, Ring и NVLS. Для H100 рекомендуется включить NVLS (NVLink Shared) для ускорения all-reduce. Параметр NCCL_ALGO=NVLS может дать прирост 10-15%. Также важен NCCL_IB_HCA для указания InfiniBand интерфейсов. Более подробно о NCCL можно прочитать в официальном репозитории.
Оркестрация: Slurm или Kubernetes?
Slurm — стандарт HPC, лучше для долгих batch-задач с фиксированным числом GPU. Kubernetes + GPU Operator — для контейнеризации и динамического выделения ресурсов. Мы помогаем выбрать подходящий вариант и настроить gang scheduling, чтобы все GPU-поды запускались одновременно.
Установка GPU Operator (Helm)
helm repo add nvidia https://helm.ngc.nvidia.com/nvidia helm install gpu-operator nvidia/gpu-operator --namespace gpu-operator --create-namespace --set driver.enabled=true --set toolkit.enabled=true Пример job для Slurm
#!/bin/bash #SBATCH --nodes=4 #SBATCH --ntasks-per-node=8 #SBATCH --gres=gpu:8 #SBATCH --partition=a100 #SBATCH --time=48:00:00 srun python train.py --nproc_per_node=8 --nnodes=4 Мониторинг: DCGM Exporter и метрики
helm install dcgm-exporter nvidia/dcgm-exporter Ключевые метрики: GPU utilisation (>85%), memory copy utilisation, NVLink bandwidth, power usage.
Типичные ошибки при настройке
- Пропуск настройки NUMA affinity — приводит к потере 10–20% производительности.
- Использование одного раздела файловой системы для датасетов и чекпоинтов — узкое место IO.
- Отсутствие тестов AllReduce между узлами — часто выявляется только в продакшене.
- Неправильные параметры планировщика (timeout, backfill) — GPU простаивают.
Результаты и гарантии
После настройки кластера вы получаете:
- Утилизацию GPU не ниже 85% при стандартных нагрузках.
- Scaling efficiency 85–90% для multi-node обучения.
- Документированную процедуру развёртывания и мониторинга.
Мы гарантируем, что настроенный кластер будет работать стабильно, а при возникновении проблем — окажем поддержку в рамках соглашения. Оценим ваш проект за 1–2 дня. Свяжитесь для консультации и получите предварительную оценку. Закажите настройку и забудьте о простоях GPU.