PCIe і GPU: коли x8 підходить, а коли шкодить

November 8, 2025 • February 3, 2026 • Читання: 5 хв • Views: 0

Було корисно?

Десь у вашому парку серверів цілком робочий GPU тихо працює на PCIe x8. Ніхто не помічає, поки не сповільниться тренувальна задача, не почнуть пропускатись кадри у відеопайплайні або сервіс інференсу не отримає хвостову латентність, яка зіпсує всім день.

Потім починається дискусія: «x8 по суті те саме, що x16, правда?» Іноді так. Іноді таке припущення коштує тижнів інженерної роботи та бюджету на закупівлю. Це версія відповіді, з якою можна йти в продакшен.

Математика ліній, яку можна зробити в голові

PCIe — це послідовний інтерконект. Лінії — незалежні канали, які агрегують пропускну здатність. «x16» означає 16 ліній. «x8» означає 8 ліній. Поки що просто.

Що робить людей необачними — це те, що «покоління» PCIe змінює швидкість однієї лінії. GPU на Gen4 x8 може перевершити старий GPU на Gen3 x16 у чистій пропускній здатності між хостом і пристроєм. Це звучить як дрібниця, поки ви не сидите перед дашбордом і не дивуєтесь, чому один вузол повільніший, хоча «число ліній те саме». Ні — не те саме.

Правило великого пальця для пропускної здатності (достатньо для дебагу)

PCIe Gen3: ~1 GB/s на лінію в кожну сторону (після врахування кодування). Тож Gen3 x16 ≈ 16 GB/s, Gen3 x8 ≈ 8 GB/s.
PCIe Gen4: приблизно вдвічі більше за Gen3. Gen4 x8 ≈ Gen3 x16.
PCIe Gen5: приблизно вдвічі більше за Gen4. Тепер x8 може дати дуже велику пропускну здатність — якщо решта системи встигає за нею.

І пам’ятайте: PCIe — повнодуплексний. Канал може одночасно везти дані в обох напрямках. Більшість GPU-навантажень так не роблять. Вони буферно передають.

Є також тонка різниця між тим, що обіцяє маркетинг, і тим, що відчуває ваша програма: пропускна здатність — не те саме, що затримка, і багато «повільностей» GPU фактично пов’язані з синхронізацією або голодуванням CPU. PCIe x8 стає козлом відпущення, бо на нього легко вказати, як на мережу при відмові через DNS.

Коли PCIe x8 підходить (і можна перестати хвилюватися)

Якщо ви розглядаєте GPU як острів обчислень — завантажуєте дані раз, робите багато обчислень, відсилаєте назад невеликі результати — PCIe мало що значить. GPU проводить більшість часу, працюючи з HBM/GDDR з пропускною здатністю у сотнях GB/s до кількох TB/s. У порівнянні з цим PCIe виглядає як садовий шланг. Але якщо ви лише інколи з нього п’єте, то хто хвилюється?

Випадки, коли x8 зазвичай підходить

1) Тренування з адекватним pipeline завантаження

Класичне навчання в deep learning часто не обмежене PCIe, якщо ви робите ці три речі:

Тримайте розмір батчів достатнім, щоб не робити дрібні передачі постійно.
Використовуйте pinned memory та асинхронні копії, щоб GPU міг перекривати обчислення і передачі.
Не змушуйте CPU розпаковувати і попередньо обробляти дані так, ніби це 2009 рік.

У такому світі перехід з x16 на x8 може змінити час кроку на кілька відсотків. Іноді це просто шум. Якщо ви не вимірюєте, то просто розповідаєте історії.

2) Інференс з моделями, що залишаються в пам’яті

Якщо ваги моделі вже на GPU, а запити невеликі (токени тексту, embeddings, маленькі зображення), трафік по PCIe — це вхід/вихід, а не повна модель. Це зазвичай не насичує x8.

3) Графіка/рендеринг, що живе у VRAM

Багато ігор/рендерів стрімлять ресурси, але гарячий робочий набір знаходиться у VRAM. PCIe допомагає зі стрімінгом активів та епізодичними передачами, але це не постійний високошвидкісний потік. Саме тому ви бачите бенчмарки, де x8 майже не впливає на багато ігор, особливо при високих роздільностях, де GPU і так є обмежувачем.

4) Multi-GPU, де GPUs спілкуються через NVLink (або подібне)

Якщо трафік GPU↔GPU йде по NVLink, а трафік від хоста мінімальний, ширина PCIe може мати менший вплив. Але будьте обережні: CPU все ще оркеструє роботу, а storage/network все ще годують задачу. «Маємо NVLink» — не картка порятунку для поганої топології.

5) PCIe Gen4/Gen5 x8 з коректними DMA-патернами

Gen4 x8 часто підходить, бо це ефективно Gen3 x16. Gen5 x8 ще більш поблажливий. Найбільший практичний виграш від нових поколінь PCIe — не те, що ви можете йти швидше; а те, що ви зберігаєте продуктивність, використовуючи менше ліній, що спрощує трасування плати і бюджет ліній платформи.

Думка: Якщо ви на Gen4+ і ваше навантаження не постійно переміщує десятки GB/s між хостом і пристроєм, не витрачайте політичний капітал на «виправлення» x8. Витрачайте його на CPU-ядра, пропускну здатність пам’яті, сховище та шлях даних, який ви дійсно використовуєте.

Коли PCIe x8 шкодить (і як це проявляється)

PCIe x8 шкодить, коли GPU змушений поводитися як присдкований акселератор, якому потрібно постійне живлення від хоста, або коли топологія платформи перетворює «x8» на «x8, що ділиться завантаженим мостом із вашим NIC та NVMe RAID». Ось тоді сповільнення стають драматичними й негарними.

1) Навантаження з інтенсивним хост↔пристрій трафіком

Це проявляється у реальному житті як:

Великі пакетні ETL, які багаторазово пересувають дані через GPU, але не можуть тримати їх резидентними.
GPU-прискорені бази даних, що часто підвантажують сторінки.
Пайплайни відеоаналітики, що рухають багато нестиснених кадрів.
Наукові коди з великою кількістю коротких кернелів, де проміжні результати потрапляють назад на CPU.

Коли x8 є вузьким місцем, завантаження GPU часто виглядає «нормальним» у сплесках, але кінцева пропускна здатність низька, а CPU-потоки зависають на копіях. Затримка зростає, але це не чистий спад. Це виглядає як пила очікування.

2) Peer-to-peer, RDMA та «хитрі» шляхи даних

GPUDirect RDMA і GPU peer-to-peer відмінні — поки ні. Коли ні, часто винна топологія: GPU і NIC можуть не бути під одним root complex або конфігурація IOMMU додає додаткові трансляції. Ширина PCIe — лише один вимір; довжина шляху і мости між ними — інший.

3) Віртуалізація та passthrough середовища

У віртуалізованих середовищах ви можете отримати:

Зменшену ефективну ширину лінії через проводку слотів і біфуркацію.
Налаштування ACS/ARI, що змушують трафік проходити менш оптимальними шляхами.
Поведінку IOMMU, що змінює DMA-продуктивність.

Якщо ви запускаєте GPU для орендаря і вимірюєте тільки час кернела, ви пропускаєте реальний вузький канал. Вимірюйте час передачі. Вимірюйте від початку до кінця.

4) Кілька «x8» пристроїв, що ділять upstream-пропускну здатність

Слот може бути механічно x16 і електрично x16, але апстрім-лінк від PCIe switch до CPU може бути x16, що обслуговує чотири GPU. У такій конфігурації кожен GPU може узгодити x16 до switch і все одно програвати в агрегації через спільний uplink. «lspci каже x16» — це не кінець історії.

Жарт #1: Бюджет ліній PCIe — як розсадження в офісі: усі думають, що мають місце біля вікна, поки не прийде пожежник.

5) Тиха деградація: фізичний x16, узгоджено x8, пониження покоління

Класичний режим відмови: GPU в x16-слоті, але узгоджується як x8, або падає з Gen4 до Gen3. Задача виконується, графіки здаються правдоподібними, а продуктивність «трохи не та». Саме так і зникає час інженерів.

Причини включають погану цілісність сигналу (riser-кабелі, бекплейни), налаштування BIOS, проблеми з ретаймером, брудні контакти або плата, що ділить лінії з іншим пристроєм і перенаправляє під навантаженням чи в певній конфігурації.

Топологія важить більше, ніж визнають

PCIe — дерево: ендпоінти (GPU, NIC, NVMe) підвішені на свитчах, які підвішені на root complex (CPU-сокети). У двопроцесорних системах стає гостріше: GPU на сокеті 0, що спілкується з NIC на сокеті 1, може проходити через міжсокетний інтерконект (UPI/Infinity Fabric) і отримати як падіння пропускної здатності, так і збільшення затримки.

Ось де питання «x8 vs x16» стає неправильним. Правильні питання такі:

Який CPU-сокет володіє GPU?
Який сокет володіє NIC або контролером сховища, що годує GPU?
Чи є PCIe switch? Яка ширина та покоління його uplink?
Чи ділимо ми root порт з іншими важкими пристроями?

Думка: Якщо ви експлуатуєте multi-GPU вузли в продакшені, варто ставити топологію PCIe в розряд першокласного інвентарю, як модель CPU та обсяг RAM. Якщо ви не можете відповісти «під яким root complex знаходиться цей GPU?» з ваших записів про активи, ви літаєте в сліпу.

Нотатка про NUMA і чому вона обманює о 3 ранку

NUMA локальність впливає на:

CPU-потоки, що живлять GPU (copy engine все ще потребують оркестрації CPU).
Пропускну здатність хост-пам’яті (особливо якщо випадково використовуєте віддалену пам’ять).
Затримку до NIC/сховища, що надають вхідні дані.

Ви можете «виправити» уявний PCIe-горлечко, прив’язавши потоки data loader і розподіл пам’яті до NUMA-вузла, що локальний до GPU. Це не магія; це просто розміщення CPU і пам’яті ближче до root порту PCIe, до якого прикріплений GPU.

Цікавинки та коротка історія (те, що пояснює сучасні дивності)

Факт 1: PCIe замінив AGP і PCI(-X), перейшовши від спільної паралельної шини до комутованої серійної тканини, саме тому й з’явилися «лінії».
Факт 2: Перехід PCIe Gen3 на кодування 128b/130b різко зменшив накладні витрати порівняно з 8b/10b у Gen1/2; це частково пояснює, чому Gen3 відчувався як великий реальний стрибок.
Факт 3: Багато «x16» десктопних слотів механічно x16, але електрично x8 при заповненні кількох слотів; мультиплексування ліній на материнських платах старше більшості ML-фреймворків, про які сперечаються люди.
Факт 4: Тренування лінку PCIe може узгоджувати і ширину, і швидкість під час завантаження; коли якість сигналу маргінальна, системи часто знижують швидкість, а не відмовляють повністю.
Факт 5: Ранні стекі GPU для обчислень сильно покладались на CPU для оркестрації та управління пам’яттю, що робило поведінку PCIe більш видимою; новіші можливості зменшують передачі, але не усувають обмежень топології.
Факт 6: PCIe свитчі поширені у multi-GPU серверах; GPU може показувати «x16» для свитча, навіть якщо підключення свитча до CPU є реальним вузьким місцем.
Факт 7: «Resizable BAR» (та споріднені ідеї) з’явилися через давній біль навколо мапування великої пам’яті пристрою в адресний простір CPU; це може зменшити накладні витрати для деяких шаблонів доступу, але не створить пропускну здатність з нічого.
Факт 8: На двопроцесорних системах міжсокетний PCIe-трафік може обмежуватись міжсокетним лінком, внаслідок чого Gen4 x16 GPU поводиться, ніби він на значно тоншому каналі для певних шляхів.
Факт 9: Лічильники помилок PCIe (corrected errors) можуть повільно зростати довго, перш ніж хто-небудь помітить, і продуктивність може деградувати через повторні передачі навіть тоді, коли нічого «не падає».

Один операційний вислів, що добре старіє: Надія — це не план. — Gene Kranz.

Практичні завдання: команди, виводи та рішення

Нижче наведені реальні завдання, які ви можете виконати в Linux, щоб підтвердити ширину/швидкість лінку, топологію, NUMA-локальність, поведінку помилок PCIe і чи є PCIe справжнім обмежувачем. Кожне завдання включає, на що дивитись і яке рішення приймати далі.

Завдання 1: Перевірити ширину лінку та покоління, які повідомляє GPU

cr0x@server:~$ nvidia-smi -q -d PCI
==============NVSMI LOG==============
PCI
    Bus Id                    : 00000000:3B:00.0
    PCIe Generation
        Current               : 4
        Max                   : 4
    Link Width
        Current               : 8x
        Max                   : 16x

Що це означає: GPU може працювати в Gen4 x16, але наразі працює Gen4 x8. Це не обов’язково погано, але це конфігурація або результат, який потрібно пояснити.

Рішення: Якщо продуктивність нормальна — зафіксуйте це. Якщо продуктивність відстає — переходьте до перевірки топології й помилок; не беріться одразу за купівлю обладнання.

Завдання 2: Підтвердити статус лінку з регістрів можливостей PCIe

cr0x@server:~$ sudo lspci -s 3b:00.0 -vv | sed -n '/LnkCap:/,/LnkSta:/p'
        LnkCap: Port #0, Speed 16GT/s, Width x16, ASPM L1, Exit Latency L1 <16us
        LnkSta: Speed 16GT/s (ok), Width x8 (downgraded)

Що це означає: Пристрій і слот підтримують x16, але узгодили x8. Слово «downgraded» — цікаве.

Рішення: Розглядайте це як апаратну/прошивочну/шляхову проблему, поки не доведете інше: переставте слот, приберіть riser, перевірте BIOS, перевірте біфуркацію.

Завдання 3: Замапити дерево PCIe і виявити свитчі/аплінки

cr0x@server:~$ sudo lspci -tv
-[0000:3a]-+-00.0  Intel Corporation PCIe Root Port
           +-01.0-[3b]----00.0  NVIDIA Corporation Device
           \-02.0-[3c]----00.0  Mellanox Technologies NIC

Що це означає: GPU і NIC під одним root complex (гарний знак для GPUDirect RDMA і уникнення міжсокетних обхідних шляхів).

Рішення: Якщо GPU і NIC на різних root/sockets — прив’яжіть процеси або перемістіть карти, якщо можливо.

Завдання 4: Визначити NUMA-локальність GPU PCIe-пристрою

cr0x@server:~$ cat /sys/bus/pci/devices/0000:3b:00.0/numa_node
0

Що це означає: GPU локальний до NUMA вузла 0.

Рішення: Запускайте потоки data loader на вузлі 0 і виділяйте буфери хоста там (або свідомо використовуйте інтерлівінг).

Завдання 5: Перевірити топологію CPU-сокетів і розклад NUMA

cr0x@server:~$ lscpu | egrep 'Socket|NUMA node|Model name'
Model name:                           Intel(R) Xeon(R) Gold 6338 CPU @ 2.00GHz
Socket(s):                            2
NUMA node(s):                         2
NUMA node0 CPU(s):                    0-31
NUMA node1 CPU(s):                    32-63

Що це означає: Два сокети, два NUMA вузли. Міжвузловий трафік — реальний.

Рішення: Якщо GPU на node0, уникайте планування pipeline на node1, якщо не хочете втрачати продуктивність.

Завдання 6: Підтвердити, що драйвер ядра бачить очікувані MaxPayload/MaxReadReq

cr0x@server:~$ sudo lspci -s 3b:00.0 -vv | egrep 'MaxPayload|MaxReadReq'
        DevCtl: Report errors: Correctable- Non-Fatal- Fatal- Unsupported-
                MaxPayload 256 bytes, MaxReadReq 512 bytes

Що це означає: Розміри payload і read request впливають на ефективність, особливо при великій кількості дрібних передач.

Рішення: Якщо ви бачите незвично малі значення порівняно з нормою платформи, перевірте BIOS/прошивку та чи не обмежують їх ACS/quirks.

Завдання 7: Шукати повідомлення про скориговані помилки PCIe (тихий вбивця пропускної здатності)

cr0x@server:~$ sudo journalctl -k -b | egrep -i 'pcie|aer|Corrected|Uncorrected' | tail -n 8
pcieport 0000:3a:00.0: AER: Corrected error received: 0000:3a:00.0
pcieport 0000:3a:00.0: AER: PCIe Bus Error: severity=Corrected, type=Physical Layer
pcieport 0000:3a:00.0: AER:   device [8086:xxxx] error status/mask=00000001/00002000
pcieport 0000:3a:00.0: AER:    [ 0] RxErr

Що це означає: Помилки фізичного рівня (RxErr) часто означають проблеми з цілісністю сигналу: riser, слот, маргінальний лінк, ретаймер.

Рішення: Якщо скориговані помилки немалі — припиніть бенчмарки і почніть лагодити апаратний шлях і налаштування BIOS; повторні передачі можуть імітувати «таємничу x8 повільність».

Завдання 8: Перевірити узгоджену швидкість/ширину лінку через sysfs (зручно для скриптів)

cr0x@server:~$ cat /sys/bus/pci/devices/0000:3b:00.0/current_link_speed
16.0 GT/s
cr0x@server:~$ cat /sys/bus/pci/devices/0000:3b:00.0/current_link_width
8

Що це означає: Те саме, що lspci/nvidia-smi, але дружній до скриптів для фліту-перевірок.

Рішення: Побудуйте перевірку відповідності: тріггерити алерт, коли очікуваний SKU повинен бути x16, а показує x8.

Завдання 9: Підтвердити близькість GPU/NIC для GPUDirect RDMA

cr0x@server:~$ nvidia-smi topo -m
        GPU0    NIC0    CPU Affinity    NUMA Affinity
GPU0     X      PHB     0-31            0
NIC0    PHB      X      0-31            0

Що це означає: PHB вказує, що GPU і NIC ділять один і той же PCIe host bridge. Зазвичай це бажано.

Рішення: Якщо ви бачите SYS або менш локальний зв’язок — перегляньте розміщення слотів, налаштування BIOS або яку NIC ви прив’язуєте до робочих навантажень.

Завдання 10: Виміряти пропускну здатність хост↔пристрій за допомогою прикладу CUDA (якщо встановлено)

cr0x@server:~$ /usr/local/cuda/samples/1_Utilities/bandwidthTest/bandwidthTest --mode=shmoo --memory=pinned
[CUDA Bandwidth Test] - Starting...
Host to Device Bandwidth, 1 Device(s), Pinned memory
  Transfer Size (Bytes)    Bandwidth(MB/s)
  33554432                24000.0
Device to Host Bandwidth, 1 Device(s), Pinned memory
  Transfer Size (Bytes)    Bandwidth(MB/s)
  33554432                25000.0

Що це означає: ~24–25 GB/s відповідає реальному поведінці Gen4 x8 (варіюється залежно від платформи). Якщо ви очікували ~28–30+ або вдвічі більше і отримали менше — щось не так.

Рішення: Якщо пропускна здатність низька — перевірте пониження покоління, втрату ліній, помилки або спільний uplink. Якщо пропускна здатність у нормі — вузьке місце десь інше.

Завдання 11: Корелювати використання copy engine GPU та обчислень (швидка перевірка)

cr0x@server:~$ nvidia-smi dmon -s u -d 1
# gpu   sm   mem   enc   dec   mclk   pclk
# Idx    %     %     %     %   MHz    MHz
    0   15    20     0     0  9501   1410
    0   18    22     0     0  9501   1410

Що це означає: Низьке використання SM може означати голодування даними, але також може бути через дрібні кернели, вузьке місце на CPU або накладні синхронізації. dmon сам по собі — не доказ.

Рішення: Якщо SM% залишається низьким, а робота має бути обчислювально важкою — профілюйте передачі і поведінку CPU-потоків перед тим, як звинувачувати лінії PCIe.

Завдання 12: Підтвердити, що ви випадково не працюєте з віддаленою NUMA-пам’яттю

cr0x@server:~$ numastat -p $(pgrep -n python)
Per-node process memory usage (in MBs) for PID 24817 (python)
Node 0        18240.3
Node 1          512.7

Що це означає: Цей процес в основному використовує пам’ять вузла 0 — добре, якщо GPU на node0.

Рішення: Якщо пам’ять переважно віддалена від NUMA-вузла GPU, виправте pinning/виділення (systemd CPUAffinity, taskset, numactl, контейнерні cpusets).

Завдання 13: Перевірити симптоми спільного використання ліній у BIOS/прошивці (декілька ендпоінтів)

cr0x@server:~$ sudo lspci | egrep -i 'NVIDIA|Non-Volatile|Mellanox'
3b:00.0 VGA compatible controller: NVIDIA Corporation Device
3c:00.0 Ethernet controller: Mellanox Technologies Device
5d:00.0 Non-Volatile memory controller: Samsung Electronics NVMe SSD Controller

Що це означає: Зробіть інвентар важких споживачів. Якщо всі вони під одним root портом або одним uplink свитча — перевантаження цілком ймовірне.

Рішення: Використайте lspci -tv, щоб подивитись, чи ділять вони uplink; якщо так — перерозподіліть розміщення або прийміть контенцію і плануйте навантаження відповідно.

Завдання 14: Перевірити фактичне покоління PCIe на root порту також

cr0x@server:~$ sudo lspci -s 3a:00.0 -vv | egrep 'LnkCap:|LnkSta:'
LnkCap: Speed 16GT/s, Width x16
LnkSta: Speed 8GT/s (downgraded), Width x16 (ok)

Що це означає: Root порт працює на Gen3, навіть якщо GPU може Gen4. Це проблема узгодження на рівні платформи (налаштування BIOS, riser, ретаймер або примусова сумісність).

Рішення: Виправте швидкість спочатку; x16 Gen3 проти x8 Gen4 може давати подібну пропускну здатність, але несподіване пониження покоління часто корелює з проблемами сигналу і помилками.

Швидкий план діагностики

Це послідовність для випадку «20 хвилин і тревожний виклик». Мета — вирішити, чи є ширина/швидкість/топологія PCIe дійсним вузьким місцем, і якщо так — який важіль смикнути.

Перше: підтвердити, що лінк такий, як ви думаєте

Запустіть nvidia-smi -q -d PCI і зафіксуйте Current/Max покоління та ширину.
Запустіть sudo lspci -s <gpu> -vv і перевірте LnkSta на предмет пониження швидкості/ширини.
Перевірте sysfs current_link_speed і current_link_width для послідовних скриптових перевірок.

Рішення: Якщо ви бачите «downgraded», розглядайте це як реальну підказку, а не як дрібницю.

Друге: шукати тихі помилки та перенавчання лінку

Проскануйте логи ядра на наявність AER скоригованих помилок.
Якщо бачите сплески RxErr — не довіряйте бенчмаркам, лагодьте фізичний/прошивочний шлях.

Рішення: Скориговані помилки — це «система вас рятує». А водночас вони і стягують плату у вигляді повторних передач.

Третє: замапити топологію і NUMA-локальність

Використовуйте lspci -tv, щоб побачити, чи є свитч і що ділить той самий root.
Використовуйте nvidia-smi topo -m, щоб побачити GPU↔NIC близькість.
Перевірте /sys/bus/pci/devices/.../numa_node і прив’яжіть CPU-потоки за потреби.

Рішення: Якщо GPU і його «постачальник» (NIC/NVMe) на різних сокетах — виправте афінність або розміщення перед тим, як чіпати ширину PCIe.

Четверте: виміряти те, за що ви звинувачуєте PCIe

Запустіть host↔device bandwidth test (CUDA приклад або ваш мікробенч).
Профілюйте додаток: час копій проти часу обчислень. Якщо копії — мала частка, x8 не має великого значення.

Рішення: Якщо виміряна пропускна здатність близька до очікувань, а ви все ще повільні — швидше за все, проблема на боці CPU/шляху даних.

Три корпоративні міні-історії з практики

Міні-історія 1: Інцидент через неправильне припущення

Вони розгортали новий кластер для інференсу. Та сама модель GPU, той самий стек ПЗ, той самий контейнер. Єдина різниця — нова модель сервера, що обіцяла кращу щільність. Команда зробила, як більшість: подивилась на кількість GPU в стійці і посміхнулась.

Через два тижні on-call команда почала бачити періодичні сплески латентності. Не постійно. Не чисте регресування. Просто хвости, що погіршувались під піковим навантаженням. Сервіс був достатньо стабільний, щоб уникнути повної відмови — найнебезпечніший тип помилки: той, що дозволяє вам і надалі помилятися.

Перше припущення було, що модель стала більшою. Ні. Друге — мережа. Ні. Зрештою хтось запустив nvidia-smi -q -d PCI на «поганому» вузлі і помітив, що GPU узгоджуються як x8 замість x16. Команда знизала плечима: «x8 підходить». Потім вони зробили те, що дійсно відповідає на питання: виміряли host↔device пропускну здатність під піком, і вона була значно нижча, ніж на «хороших» вузлах.

Корінь проблеми — проводка слотів плюс налаштування биоса на біфуркацію. У цій моделі сервера заповнення певного NVMe riser-приводу примушувало сусідні GPU-слоти працювати в x8. Ніхто не документував це, бо це було «в гіді по платформі», а гіди читають, коли вже йде кров. Вони переставили NVMe riser в інший відсік, відновили x16 і хвостова латентність повернулась до норми.

Урок: «x8 підходить» — гіпотеза, а не факт. Ваша система охоче перетворить цю гіпотезу в порушення SLO.

Міні-історія 2: Оптимізація, що повернулась бумерангом

Команда платформ даних хотіла зменшити час навчання, прискоривши input pipeline. Вони зробили класичний хід: збільшили паралелізм, агресивно префетчили, тримали більше батчів в польоті. Використання GPU виглядало приємніше. Дашборди викликали аплодисменти.

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

Справжня проблема була в тому, що оптимізація збільшила хост↔пристрій трафік у дрібніших шматках і підвищила контенцію на root complex PCIe. На певних вузлах GPU були за свитчем, чий uplink вже був завантажений інтенсивними NVMe читаннями. Пул префетчу перетворив ці читання в більш стабільний потік — чудово для сховища, і жахливо для спільного uplink PCIe.

Коли вони припинили бездумне префетчинг і почали стажувати великі суміжні буфери (і прив’язувати їх), пропускна здатність стабілізувалась. Деякі вузли втратили трохи пікової швидкості, але p95 по всьому парку покращився — саме те, що їм було треба.

Урок: оптимізації, що підвищують конкуренцію, можуть підвищити контенцію. PCIe не нескінченний, і спільні uplink-и — це пастка, де «x8» перетворюється на «чому ми повільні».

Міні-історія 3: Нудна, але правильна практика, що врятувала день

Інша команда керувала змішаним кластером: тренування вдень, батч-інференс вночі. У них була політика: кожен апаратний SKU мав «маніфест відомої хорошої топології». Він включав, які слоти заповнювати, які налаштування BIOS потрібні і який «очікуваний стан PCIe лінку» для кожного GPU.

Це не було гламурно. Це була внутрішня wiki-сторінка і кілька скриптів, що запускались під час провізії. Скрипти перевіряли current_link_width, current_link_speed, NUMA-локальність і чи з’являлись AER помилки під час короткого стрес-тесту.

За один квартал вони почали бачити партію вузлів, що не проходили провізіонінг: GPU узгоджували Gen4, але випадково падали до Gen3 після теплого ребуту. Вузли все ще завантажувались, контейнерні завдання працювали, і вони пройшли б поверхневі smoke-тести. Але їхні перевірки зупинили це.

Вони ізолювали проблему до маргінальної партії riser-ів і замінили їх до того, як вузли пішли в продакшен. Ніхто поза командою не помітив. І це суть.

Жарт #2: Профілактичне обслуговування — як чищення зубів: усі погоджуються, що це працює, і майже ніхто цього не робить, поки щось не болить дорого.

Типові помилки: симптом → корінь → виправлення

1) Симптом: «GPU показує x8, продуктивність упала на 20–40%»

Корінь: Не лише x8 — зазвичай це пониження покоління (Gen4→Gen3), повторні передачі через скориговані помилки або спільний uplink через PCIe свитч.

Виправлення: Перевірте LnkSta на предмет пониження швидкості. Проскануйте логи на AER помилки. Замапте топологію lspci -tv. Виправляйте фізичний шлях (пересадіть, приберіть riser, замініть ретаймер), і переконайтесь, що BIOS налаштовано на потрібне покоління PCIe.

2) Симптом: «Один вузол повільніший за ідентичні вузли»

Корінь: Різна заповненість слотів, різне NUMA прикріплення або біфуркація, що викликана іншим пристроєм (NVMe riser, друга NIC).

Виправлення: Порівняйте nvidia-smi -q -d PCI і lspci -tv між вузлами. Стандартизуйте мапінг слотів. Додайте перевірки провізії на ширину/швидкість лінку і NUMA.

3) Симптом: «GPUDirect RDMA не допоміг (або стало гірше)»

Корінь: GPU і NIC не під тим самим host bridge, налаштування IOMMU/ACS змушують неідеальну маршрутизацію або RDMA трафік конкурує з іншими ендпоінтами.

Виправлення: Використайте nvidia-smi topo -m. Якщо GPU↔NIC не локальні (PHB/PIX), перемістіть карти або змініть NIC. Перевірте конфігурацію IOMMU і виміряйте знову.

4) Симптом: «Низьке використання GPU, люди звинувачують PCIe»

Корінь: Вузьке місце на боці CPU при препроцесінгу, однопотоковий input pipeline, віддалена NUMA-пам’ять або занадто малі батчі, що викликають часті синхронізації.

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

5) Симптом: «Після додавання другого GPU/NVMe все регресувало»

Корінь: Спільне використання ліній або перенавантаження uplink свитча. Платформа робить те, для чого її спроектували: компроміс.

Виправлення: Перегляньте бюджет ліній. Розподіліть важкі пристрої по root портам/сокетам. Якщо уникнути неможливо, плануйте навантаження так, щоб уникнути одночасних піків на спільному uplink.

6) Симптом: «lspci каже x16, але тест пропускної здатності низький»

Корінь: Спільний upstream лінк, тротлінг через помилки/повторні передачі, накладні IOMMU або малі MaxPayload/MaxReadReq, що взаємодіють з патерном передачі.

Виправлення: Підтвердьте топологію; перевірте AER логи; інспектуйте LnkSta root порту також; порівняйте MaxPayload/MaxReadReq з відомими «хорошими» вузлами.

Контрольні списки / покроковий план

Контрольний список A: Визначення, чи прийнятний x8 для конкретного GPU-навантаження

Виміряйте частку передач: Який відсоток часу кроку/запиту займають копії хост↔пристрій?
Виміряйте реальну пропускну здатність: Запустіть bandwidth microbench з pinned memory.
Перевірте покоління PCIe: Gen4 x8 може бути прийнятним; Gen3 x8 простіше наситити.
Перевірте топологію: Чи ділите ви uplink з NIC/NVMe? Ось підступ.
Перевірте NUMA: Чи локальні CPU-потоки і пам’ять до сокета GPU?
Рішення: Якщо копії <10% часу і пропускна здатність близька до очікуваної — приймайте x8. Якщо копії великі і пропускна здатність низька — виправляйте лінк або переробляйте архітектуру.

Контрольний список B: Стандартна валідація при провізії GPU-вузлів

Зафіксуйте current_link_speed і current_link_width для кожного GPU в інвентарі.
Відхиляйте провізію, якщо лінк понижений у порівнянні з манифестом платформи (з процесом винятків).
Запустіть короткий host↔device bandwidth тест і зберігайте результати як базу для порівняння.
Проскануйте journalctl -k на AER помилки після навантаження. Відхиляйте вузли, якщо частота помилок перевищує допустиму.
Зафіксуйте nvidia-smi topo -m і перевірте GPU↔NIC локальність, якщо ви покладаєтесь на RDMA.

Контрольний список C: Кроки виправлення, коли x8 справді шкодить

Усуньте фізичні проблеми: пересадіть GPU, приберіть/замініть riser, перевірте ретаймери, почистіть контакти.
Нормалізуйте BIOS: переконайтесь, що слот налаштований на потрібне покоління; вимкніть примусову сумісність, якщо вона не потрібна.
Виправте заповнення слотів: перемістіть NVMe/NIC, щоб припинити «крадіжку» ліній; уникайте біфуркації, що ділить лінії GPU навпіл.
Виправте NUMA афінність: прив’яжіть потоки data loader і розподіл пам’яті локально до GPU.
Зменшіть PCIe трафік: використовуйте більші батчі, стажуйте дані на GPU, використовуйте pinned memory, перекривайте копії з обчисленнями.
Повторно протестуйте: bandwidth microbench + end-to-end робота. Не приймайте «виглядає швидше».

Питання й відповіді

1) Чи PCIe Gen4 x8 по суті те саме, що Gen3 x16?

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

2) Якщо мій GPU на x8 замість x16, чи щось зламалося?

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

3) Чому мій GPU показує x8 «Current», але x16 «Max»?

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

4) Чи може riser-кабель або backplane справді змусити x8 або Gen3?

Так. Маргінальна цілісність сигналу часто дає стабільний, але повільніший лінк. Система віддає перевагу «працює на x8/Gen3» замість «не завантажується». Це хороша інженерна риса — і пастка для продуктивності.

5) Чи вирішує Resizable BAR обмеження пропускної здатності PCIe?

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

6) Чи x8 болючіший для multi-GPU тренувань?

Залежить від того, куди йде трафік синхронізації. Якщо GPUs переважно спілкуються по NVLink — PCIe важить менше. Якщо вони покладаються на хост-посередництво або ваш pipeline постійно звертається до хост-пам’яті — x8 може більше заважати.

7) Як зрозуміти, чи вузьке місце — PCIe чи мій input pipeline?

Виміряйте час передач проти часу обчислень. Запустіть host↔device bandwidth microbench. Якщо лінк здоровий, а додаток повільний — ймовірно, вузьке місце на боці CPU, сховища або синхронізацій.

8) У серверах зі свитчами PCIe, чи може «x16» бути оманливим?

Так. GPU може узгодити x16 до свитча, але кілька GPU можуть ділити uplink свитча до CPU. Треба зрозуміти весь шлях, а не лише лінк ендпоінта.

9) Яка найпоширеніша причина, чому GPU працює на Gen3 замість Gen4/Gen5?

За замовчуванням BIOS та цілісність сигналу. Вражаюча кількість «таємничих регресій» пояснюється налаштуваннями прошивки та маргінальними апаратними шляхами, що понижають лінк під час ребуту.

10) Чи завжди купувати платформи, що гарантують x16 на GPU?

Якщо ваше навантаження інтенсивно передає дані або вам потрібна передбачувана мульти-орендована продуктивність — так, заплатіть за лінії і топологію. Якщо ваші навантаження обчислювально важкі і добре спроектовані, ви часто можете пожертвувати лініями заради щільності — але обов’язково перевірте реальними бенчмарками перш ніж вирішувати.

Практичні наступні кроки

Зробіть три речі цього тижня, якщо ви експлуатуєте GPU в продакшені:

Задокументуйте реальність: зберіть current_link_width і current_link_speed для кожного GPU-вузла і додайте до запису активу.
Базовий тест пропускної здатності: запустіть pinned-memory host↔device bandwidth test на кожному апаратному SKU і збережіть результати як опорну точку.
Кодифікуйте топологію: випишіть правила заповнення слотів, що зберігають потрібний бюджет ліній і NUMA-локальність, і застосуйте їх під час провізії.

Тоді, коли хтось скаже «x8 по суті те саме», ви зможете відповісти як дорослий: «Іноді. Ось коли. Ось вимір. Ось виправлення.»