Як налаштувати NVLink на виділеному сервері

NVLink — це фірмовий високошвидкісний міжз’єднувач GPU від NVIDIA, який замінює шину PCIe як основний канал зв’язку між GPU — а в окремих архітектурах — між GPU та CPU. Він забезпечує двонаправлену пропускну здатність до 600 GB/s на з’єднання на апаратному забезпеченні покоління Hopper, порівняно з теоретичним максимумом близько 64 GB/s на PCIe 5.0 x16. Для таких робочих навантажень, як навчання великих мовних моделей, моделювання молекулярної динаміки або багатоGPU-інференс, ця різниця не є незначною — вона є архітектурною.

Цей посібник містить повне покрокове керівництво виробничого рівня з налаштування NVLink на виділеному сервері: від фізичного встановлення апаратного забезпечення та налаштування стеку драйверів до перевірки топології, інтеграції на рівні застосунків та поточного моніторингу продуктивності.

Що таке NVLink насправді — і чим він не є

NVLink — це не просто швидший кабель. Це когерентна, точка-точка міжз’єднувальна матриця, вбудована безпосередньо в кристал GPU. Кожна лінія NVLink передає дані в обох напрямках одночасно, використовуючи серіалізований протокол диференціальної сигналізації. Кілька ліній об’єднуються в одне логічне з’єднання, а кілька з’єднань можуть підключати одну й ту саму пару GPU для адитивної пропускної здатності.

Важливо, що NVLink підтримує когерентний доступ до пам’яті кешу. Це означає, що GPU A може зчитувати з пам’яті фреймбуфера GPU B без проміжного зберігання даних через оперативну пам’ять хоста або контролер пам’яті CPU. Саме ця властивість уможливлює модель програмування «уніфікованої пам’яті» в CUDA — єдиний віртуальний адресний простір, що охоплює кілька фізичних пам’ятей GPU.

Чим NVLink не є: він не є заміною NVSwitch у великомасштабних системах. У конфігураціях з більш ніж двома GPU NVIDIA використовує NVSwitch — спеціалізований чип комутації з перехресною комутацією — для забезпечення повного NVLink-з’єднання між усіма вузлами. Наприклад, DGX A100 використовує шість чипів NVSwitch, щоб надати кожному з восьми GPU A100 повну пропускну здатність NVLink до кожного іншого GPU одночасно. Якщо ви будуєте двоGPU-робочу станцію або чотириGPU-сервер із підтримуваним мостом, ви працюєте з прямими NVLink-з’єднаннями. Якщо ви працюєте з вісьмома або більше GPU, ви майже напевно перебуваєте в зоні NVSwitch.

Пропускна здатність NVLink за поколінням GPU

Розуміння максимальної пропускної здатності вашого конкретного апаратного забезпечення є необхідним перед бенчмаркінгом або плануванням потужностей.

PCIe 4.0 x16 забезпечує приблизно 32 GB/s двонаправленої пропускної здатності. PCIe 5.0 x16 подвоює це значення приблизно до 64 GB/s. Навіть двоз’єднувальний споживчий міст NVLink на картах RTX 3090 забезпечує майже вдвічі більшу пропускну здатність, ніж PCIe 5.0 — а GPU для центрів обробки даних перебувають у зовсім іншій категорії.

Передумови та сумісність апаратного забезпечення

Перш ніж торкатися будь-якого конфігураційного файлу, підтвердьте наступне:

Сумісність GPU. NVLink доступний не на всіх GPU NVIDIA. Споживчі карти нижче RTX 2080 Ti не підтримують його. RTX 4080 не підтримує NVLink, незважаючи на те, що є картою вищого класу — лише RTX 4090 підтримує його в поколінні Ada. Завжди перевіряйте офіційний аркуш специфікацій GPU NVIDIA для вашого конкретного SKU.

Міст NVLink. Для споживчих і просьюмерських GPU потрібен фізичний роз’єм моста NVLink. Ці мости є специфічними для покоління — міст Turing не підійде до карти Ampere. GPU для центрів обробки даних (A100, H100) у форм-факторі SXM використовують фірмову плату мезонінного типу і не використовують дискретний міст.

Материнська плата та відстань між слотами PCIe. Міст NVLink вимагає, щоб два GPU знаходилися в суміжних слотах PCIe x16 з певним фізичним проміжком. Більшість споживчих мостів охоплюють два слоти. Деякі мости вищого класу охоплюють три слоти. Перевірте крок слотів вашої материнської плати відносно розмірів моста перед покупкою.

Налаштування BIOS. Увімкніть «Above 4G Decoding» та «Resizable BAR» (також відомий як Smart Access Memory на платформах AMD) у UEFI. Деякі системи також вимагають вимкнення CSM (Compatibility Support Module) для забезпечення повного виділення адресного простору PCIe для кількох GPU.

Подача живлення. Два GPU вищого класу під повним навантаженням з прискоренням NVLink можуть споживати в сукупності 600W або більше. Переконайтеся, що ваш блок живлення має достатній запас і що роз’єми живлення GPU підключені до окремих шин, де це можливо.

Операційна система. Цей посібник охоплює Linux (Ubuntu 22.04 LTS / Debian 12) як основну цільову платформу, яка є стандартним середовищем для робочих навантажень ШІ та HPC на Виділених серверах. Кроки, специфічні для Windows, зазначені там, де вони суттєво відрізняються.

Крок 1: Фізичне встановлення GPU та моста

Повністю вимкніть сервер і від’єднайте його від мережі живлення. Заземліть себе за допомогою антистатичного браслета перед тим, як торкатися будь-яких карт PCIe.

1. Зніміть заглушки слотів PCIe для цільових слотів.
2. Вставте перший GPU у основний слот x16 (зазвичай найближчий до CPU).
3. Вставте другий GPU у суміжний слот x16, переконавшись, що фізичний проміжок відповідає вашому мосту NVLink.
4. Надійно встановіть обидві карти, поки фіксатори PCIe не клацнуть.
5. Підключіть усі необхідні роз’єми живлення PCIe від блока живлення до кожного GPU. Не використовуйте послідовно з’єднані роз’єми для карт з високим TDP — використовуйте окремі кабелі від блока живлення.
6. Вирівняйте міст NVLink над золотими контактними майданчиками на верхньому краї обох GPU. Натисніть рівномірно вниз, поки він повністю не встановиться. Частково встановлений міст призведе до того, що з’єднання мовчки не спрацює або працюватиме зі зменшеною шириною.
7. Якщо ваші GPU підтримують подвійні мости NVLink (наприклад, RTX 2080 Ti має два роз’єми NVLink), встановіть обидва мости для максимальної пропускної здатності.
8. Закрийте корпус і підключіть живлення.

Крок 2: Налаштування BIOS та UEFI

Завантажтеся в налаштування UEFI (зазвичай Del або F2 під час POST).

• Увімкніть Above 4G Decoding.
• Увімкніть Resizable BAR, якщо підтримується.
• Встановіть швидкість з’єднання PCIe на Auto або Gen4/Gen5 відповідно до вашого апаратного забезпечення.
• Вимкніть CSM, якщо ваша ОС завантажується через UEFI.
• Збережіть і вийдіть.

Крок 3: Встановлення драйверів NVIDIA на Linux

NVIDIA надає кілька шляхів встановлення. Метод менеджера пакетів є кращим для серверних середовищ, оскільки він інтегрується з DKMS (Dynamic Kernel Module Support), який автоматично перебудовує модуль ядра після оновлень ядра.

Спочатку додайте репозиторій пакетів NVIDIA та встановіть драйвер:

sudo apt-get update
sudo apt-get install -y software-properties-common
sudo add-apt-repository -y ppa:graphics-drivers/ppa
sudo apt-get update
sudo apt-get install -y nvidia-driver-545 nvidia-dkms-545

Замініть 545 на останню версію гілки виробничого рівня, доступну для вашого GPU. Ви можете запитати доступні версії за допомогою:

apt-cache search nvidia-driver | grep "^nvidia-driver"

Після встановлення перезавантажтеся:

sudo reboot

Після перезавантаження перевірте, чи драйвер завантажився правильно:

nvidia-smi

У виводі мають бути перераховані обидва GPU з їх версією драйвера, сумісністю версії CUDA та поточним станом живлення. Якщо відображається лише один GPU, друга карта може бути неправильно встановлена або мати проблему з подачею живлення.

Критична пастка: Якщо у вас завантажено Nouveau (драйвер NVIDIA з відкритим вихідним кодом), він конфліктуватиме з фірмовим драйвером. Явно додайте його до чорного списку:

echo -e "blacklist nouveaunoptions nouveau modeset=0" | sudo tee /etc/modprobe.d/blacklist-nouveau.conf
sudo update-initramfs -u
sudo reboot

Крок 4: Встановлення набору інструментів CUDA

Повна можливість NVLink — зокрема однорангового доступу до пам’яті та колективних комунікацій — вимагає набору інструментів CUDA. Встановіть його через репозиторій NVIDIA CUDA для найнадійнішого збігу версій:

wget https://developer.download.nvidia.com/compute/cuda/repos/ubuntu2204/x86_64/cuda-keyring_1.1-1_all.deb
sudo dpkg -i cuda-keyring_1.1-1_all.deb
sudo apt-get update
sudo apt-get install -y cuda-toolkit-12-4

Додайте бінарні файли та бібліотеки CUDA до середовища вашої оболонки:

echo 'export PATH=/usr/local/cuda/bin:$PATH' >> ~/.bashrc
echo 'export LD_LIBRARY_PATH=/usr/local/cuda/lib64:$LD_LIBRARY_PATH' >> ~/.bashrc
source ~/.bashrc

Перевірте встановлення:

nvcc --version

Ви маєте побачити вивід, що ідентифікує версію компілятора CUDA. Також запустіть зразок CUDA deviceQuery, якщо у вас встановлені зразки — він перерахує обидва GPU та повідомить про прапорці можливостей NVLink.

Крок 5: Перевірка топології та стану NVLink

Це найважливіший діагностичний крок. nvidia-smi надає кілька підкоманд спеціально для перевірки NVLink.

Перевірте матрицю топології системи:

nvidia-smi topo -m

Вивід є матрицею, що показує тип міжз’єднання між кожною парою пристроїв у системі. Шукайте мітки NV# між вашими GPU, де # — кількість мостів NVLink, що їх з’єднують. Мітка NV2 означає, що два мости NVLink активні. Мітка PIX або PHB означає, що GPU спілкуються через PCIe — NVLink не активний.

Приклад виводу для правильно налаштованої двоGPU-системи:

        GPU0    GPU1    CPU Affinity    NUMA Affinity
GPU0     X      NV2     0-23            0
GPU1    NV2      X      0-23            0

Перевірте стан з’єднання NVLink для кожного GPU:

nvidia-smi nvlink --status -i 0

Це показує стан кожного порту NVLink на GPU 0. Активні з’єднання відображатимуть стан Active та узгоджену швидкість.

Перевірте лічильники помилок NVLink:

nvidia-smi nvlink --errorcounters -i 0

Ненульові значення лічильників повторних спроб або відновлення вказують на проблему фізичного рівня — частково встановлений міст, пошкоджений роз’єм або проблеми цілісності сигналу через недостатню подачу живлення.

Моніторинг пропускної здатності NVLink у реальному часі:

nvidia-smi nvlink -s

Це виводить накопичені лічильники пропускної здатності. Для моніторингу дельти в реальному часі поєднайте це з watch:

watch -n 1 nvidia-smi nvlink -s

Крок 6: Увімкнення та перевірка однорангового доступу до пам’яті

Когерентний доступ до пам’яті NVLink вимагає увімкнення однорангового (P2P) доступу на рівні CUDA. Ви можете перевірити це програмно:

cat << 'EOF' > check_p2p.py
import subprocess
result = subprocess.run(['nvidia-smi', 'topo', '-p2p', 'r'], capture_output=True, text=True)
print(result.stdout)
EOF
python3 check_p2p.py

Або використайте програму CUDA C з cudaDeviceCanAccessPeer(). Для швидкої перевірки зразки CUDA simpleP2P та p2pBandwidthLatencyTest є визначальними інструментами:

cd /usr/local/cuda/samples/1_Utilities/p2pBandwidthLatencyTest
make
./p2pBandwidthLatencyTest

Вивід покаже двонаправлену пропускну здатність між парами GPU. Через NVLink ви маєте бачити значення, що відповідають таблиці пропускної здатності вище. Якщо ви бачите пропускну здатність рівня PCIe (~10–30 GB/s), P2P через NVLink не активний — перевірте, чи міст повністю встановлений і чи жодні налаштування IOMMU не блокують однорангового доступу.

Міркування щодо IOMMU: На платформах AMD EPYC та деяких Intel Xeon IOMMU може бути увімкнено за замовчуванням і може блокувати P2P-доступ GPU. Якщо P2P не працює, додайте iommu=pt (режим прозорості) або amd_iommu=on iommu=pt до командного рядка ядра в /etc/default/grub:

sudo nano /etc/default/grub
# Add iommu=pt to GRUB_CMDLINE_LINUX_DEFAULT
sudo update-grub
sudo reboot

Крок 7: Налаштування фреймворків глибокого навчання для використання NVLink

Сучасні фреймворки автоматично виявляють NVLink через NCCL (NVIDIA Collective Communications Library), але розуміння того, як перевіряти та налаштовувати цю поведінку, є необхідним для виробничих розгортань.

Змінні середовища NCCL для оптимізації NVLink:

export NCCL_DEBUG=INFO
export NCCL_P2P_LEVEL=NVL        # Force NVLink for P2P transfers
export NCCL_SHM_DISABLE=0        # Keep shared memory enabled
export NCCL_SOCKET_IFNAME=eth0   # Specify network interface for multi-node

Встановлення NCCL_DEBUG=INFO змушує NCCL виводити виявлення топології під час виконання. Ви побачите рядки на кшталт [0] NCCL INFO Channel 00 : 0[...] -> 1[...] via NVL, що підтверджують використання NVLink для міжGPU-передач.

Перевірка багатоGPU-конфігурації PyTorch:

import torch

print(f"CUDA available: {torch.cuda.is_available()}")
print(f"GPU count: {torch.cuda.device_count()}")

for i in range(torch.cuda.device_count()):
    for j in range(torch.cuda.device_count()):
        if i != j:
            can_access = torch.cuda.can_device_access_peer(i, j)
            print(f"GPU {i} -> GPU {j} P2P access: {can_access}")

Якщо can_device_access_peer повертає True для обох напрямків, DataParallel та DistributedDataParallel PyTorch автоматично використовуватимуть NVLink для синхронізації градієнтів.

Перевірка багатоGPU-конфігурації TensorFlow:

import tensorflow as tf

gpus = tf.config.list_physical_devices('GPU')
print(f"Detected GPUs: {len(gpus)}")
for gpu in gpus:
    print(gpu)

# Enable memory growth to prevent TF from allocating all VRAM at startup
for gpu in gpus:
    tf.config.experimental.set_memory_growth(gpu, True)

TensorFlow використовує NCCL для колективних операцій під час роботи з MirroredStrategy, тому наведені вище змінні середовища NCCL застосовуються однаково.

Крок 8: Бенчмаркінг продуктивності NVLink

Перш ніж запускати виробничі навантаження, встановіть базовий рівень продуктивності. Це також слугує регресійним тестом після оновлень драйверів або змін апаратного забезпечення.

Тест пропускної здатності NCCL all-reduce (найбільш репрезентативний бенчмарк для розподіленого навчання):

git clone https://github.com/NVIDIA/nccl-tests.git
cd nccl-tests
make CUDA_HOME=/usr/local/cuda
./build/all_reduce_perf -b 8 -e 512M -f 2 -g 2

Прапорець -g 2 вказує два GPU. Зверніть увагу на стовпець busbw — це ефективна пропускна здатність шини. Через NVLink на картах RTX 3090 ви маєте бачити значення, що наближаються до 100 GB/s. Через PCIe очікуйте 20–30 GB/s.

Бенчмарк cuBLAS GEMM для навантажень, обмежених обчисленнями:

/usr/local/cuda/extras/demo_suite/bandwidthTest --mode=shmoo

Крок 9: Поточний моніторинг та сповіщення

Для виробничих середовищ рекомендованим підходом є nvidia-smi у режимі демона або інтеграція з Prometheus через dcgm-exporter.

Встановіть DCGM (Data Center GPU Manager):

sudo apt-get install -y datacenter-gpu-manager
sudo systemctl enable nvidia-dcgm
sudo systemctl start nvidia-dcgm

Запитайте метрики, специфічні для NVLink, через DCGM:

dcgmi dmon -e 1011,1012,1013,1014

Ідентифікатори полів 1011–1014 відповідають лічильникам пропускної здатності NVLink (TX/RX на з’єднання). Їх можна експортувати до Prometheus і візуалізувати в Grafana для довгострокового аналізу тенденцій.

Для більш легкого моніторингу простий цикл nvidia-smi охоплює основне:

nvidia-smi dmon -s pucvmet -d 5

Прапорці -s pucvmet вмикають звітування про живлення, використання, тактову частоту, VRAM, пропускну здатність пам’яті, ECC та температуру з інтервалом 5 секунд.

NVLink проти PCIe проти NVSwitch: коли застосовується кожна архітектура

Поширені режими відмов та усунення несправностей

NVLink не виявлено після фізичного встановлення. Запустіть nvidia-smi topo -m та перевірте наявність PIX замість NV#. Переустановіть міст. Перевірте, що обидва GPU знаходяться на одному кореневому комплексі PCIe — GPU на різних сокетах CPU, з’єднані через QPI/UPI, не утворять пару NVLink навіть із встановленим мостом.

Пропускна здатність P2P відповідає швидкостям PCIe, незважаючи на міст NVLink. IOMMU майже напевно блокує однорангового доступу. Застосуйте параметр ядра iommu=pt, як описано вище.

Помилки NVLink накопичуються в nvidia-smi nvlink --errorcounters. Проблема фізичного рівня. Перевірте контактні майданчики роз’єму моста на наявність сміття або пошкоджень. Спробуйте переустановити міст. Якщо помилки зберігаються, сам міст може бути несправним.

NCCL не використовує NVLink, незважаючи на те, що топологія показує NV2. Явно встановіть NCCL_P2P_LEVEL=NVL. Також перевірте сумісність версії NCCL з вашою версією CUDA — невідповідності змушують NCCL повертатися до спільної пам’яті або транспорту через сокети.

Встановлення драйвера завершується помилками DKMS. Заголовки ядра для вашого поточного ядра можуть бути не встановлені. Виправте за допомогою:

sudo apt-get install -y linux-headers-$(uname -r)
sudo dkms autoinstall

Вибір правильної серверної інфраструктури для навантажень NVLink

Налаштування NVLink є настільки ефективним, наскільки ефективна базова серверна платформа. Кілька факторів інфраструктури безпосередньо впливають на продуктивність NVLink на практиці:

Топологія PCIe. На двосокетних платформах EPYC або Xeon лінії PCIe розподілені між обома CPU. GPU, підключені до різних CPU, спілкуються через міжсокетну матрицю (Infinity Fabric або UPI), що додає затримку та зменшує ефективну пропускну здатність для передач GPU-GPU, які мають перетинати межу сокета. По можливості встановлюйте GPU, з’єднані NVLink, у слоти PCIe, підключені до одного сокета CPU.

Пропускна здатність пам’яті. Навіть коли NVLink обробляє передачі GPU-GPU, підсистема пам’яті CPU залишається вузьким місцем для прийому даних. Платформи з високопропускною DDR5 або HBM зменшують час, витрачений на проміжне зберігання даних перед їх надходженням до GPU.

Пропускна здатність сховища. Великі контрольні точки моделей та навчальні набори даних вимагають швидкого сховища. NVMe SSD зі швидкістю послідовного читання вище 7 GB/s запобігають перетворенню рівня сховища на вузьке місце під час завантаження даних.

Охолодження. Два GPU з високим TDP під тривалим навантаженням з прискоренням NVLink виділяють значну кількість тепла. Забезпечте достатній потік повітря або потужність рідинного охолодження. Теплове дроселювання знизить тактові частоти GPU та зведе нанівець перевагу пропускної здатності, яку забезпечує NVLink.

Для команд, що виконують багатоGPU-навчання ШІ або HPC-симуляції, Виділені сервери зі сховищем NVMe та root-доступом забезпечують необхідний контроль над апаратним забезпеченням для реалізації повної конфігурації, описаної в цьому посібнику. Для навантажень з прискоренням GPU зокрема, GPU Хостинг пропонує попередньо налаштовані середовища з вже встановленими драйверами NVIDIA. Команди, яким потрібна гнучка база для користувацьких середовищ CUDA, також можуть знайти VPS Хостинг корисним для розробки та тестування перед масштабуванням до виділеного апаратного забезпечення.

Ключові висновки та контрольний список рішень

Перш ніж розгортати NVLink у виробництві, перевірте кожен пункт:

• Апаратне забезпечення підтверджено: Обидва GPU знаходяться в списку сумісності NVLink NVIDIA для вашого конкретного SKU, а не лише для сімейства продуктів.
• Покоління моста збігається: Покоління моста NVLink відповідає поколінню GPU (міст Turing для GPU Turing, міст Ampere для GPU Ampere).
• Фізичне встановлення перевірено: nvidia-smi topo -m показує NV1 або NV2 між парами GPU, а не PIX або PHB.
• P2P-доступ підтверджено: p2pBandwidthLatencyTest повідомляє про пропускну здатність рівня NVLink (а не рівня PCIe).
• IOMMU вирішено: Якщо працюєте на EPYC або Xeon, iommu=pt встановлено в параметрах ядра.
• Транспорт NCCL підтверджено: Вивід NCCL_DEBUG=INFO показує via NVL для міжGPU-каналів.
• Лічильники помилок чисті: nvidia-smi nvlink --errorcounters показує нульові помилки повторних спроб та відновлення після стрес-тесту.
• Моніторинг активний: DCGM або nvidia-smi dmon реєструє пропускну здатність NVLink та метрики помилок у постійному сховищі.
• Тепловий запас підтверджено: Обидва GPU підтримують цільові тактові частоти під повним навантаженням без теплового дроселювання.
• Версії драйвера та CUDA зафіксовано: Виробничі середовища використовують зафіксовані версії драйверів, керовані через DKMS, щоб запобігти порушенню конфігурації через ненавмисні оновлення.

Часті запитання

Чи працює NVLink на всіх картах NVIDIA RTX?

Ні. Підтримка NVLink суттєво варіюється навіть у лінійці RTX. Наприклад, RTX 4080 не підтримує NVLink, незважаючи на те, що є картою вищого класу Ada Lovelace. Лише RTX 4090 підтримує NVLink у цьому поколінні. Завжди перевіряйте технічний паспорт конкретного GPU, а не сімейства продуктів.

Чи можна використовувати NVLink з різними моделями GPU?

Загалом, ні. NVLink вимагає, щоб обидва GPU були однієї моделі та покоління. NVIDIA офіційно не підтримує конфігурації NVLink зі змішаними моделями, і стек драйверів не встановить однорангове NVLink-з’єднання між різними GPU, навіть якщо фізичні роз’єми сумісні.

Що станеться, якщо міст NVLink буде видалено під час роботи системи?

Система не вийде з ладу негайно, але будь-які активні P2P-передачі через NVLink завершаться невдачею, що зазвичай призведе до того, що запущений застосунок CUDA видасть помилку CUDA та завершить роботу. GPU повернуться до PCIe для наступних операцій. Гаряче від’єднання моста не підтримується і ризикує фізичним пошкодженням контактних майданчиків.

Чи використовується NVLink автоматично PyTorch та TensorFlow, чи потрібна явна конфігурація?

Обидва фреймворки використовують NCCL для колективних багатоGPU-операцій, і NCCL автоматично виявляє топологію NVLink. Однак завжди слід перевіряти за допомогою NCCL_DEBUG=INFO, що NCCL дійсно вибирає транспортний шлях NVLink. У деяких конфігураціях — особливо з увімкненим IOMMU або невідповідними версіями NCCL/CUDA — NCCL мовчки повертається до повільніших транспортів.

Як визначити, чи NVLink насправді покращує пропускну здатність навчання?

Запустіть своє навчальне завдання з NCCL_P2P_DISABLE=1 (примусово PCIe), а потім без нього (дозволяє NVLink). Порівняйте час ітерації або кількість зразків за секунду. Для навантажень з інтенсивною комунікацією, таких як навчання великих трансформерів з частими операціями all-reduce, NVLink зазвичай скорочує час синхронізації між GPU на 40–70% порівняно з PCIe, що безпосередньо призводить до скорочення часу епох.