ATI проти NVIDIA: чому це суперництво не закінчується

Чому це суперництво не закінчується (це не особисто, це про експлуатацію)

Рішення щодо покупки GPU виглядають як продуктова дискусія, поки ви їх не експлуатуєте. Потім це починає нагадувати
ризики ланцюга постачання, матриці сумісності ядро/драйвер, дивні прошивки та «чому контейнер раптово перестав бачити пристрій».
ATI/AMD проти NVIDIA триває, бо кожна сторона оптимізує різне визначення «працює».

NVIDIA історично розглядає драйвер і обчислювальний стек як ретельно контрольований продукт. Ви отримуєте зв’язну історію:
CUDA, cuDNN, NCCL, TensorRT і модель драйвера, яка залишається послідовною між дистрибутивами — за ціною того, що драйвер
часто поводиться як гість у світі Linux-ядра, а не як громадянин. Це ефективно, швидко, і іноді відчувається як робота з
пропрієтарним RAID-контролером: дивовижно, поки вам не треба, щоб внутрішні механізми узгодилися з вашим конкретним ядром,
композитором або політикою безпеки.

Сучасна історія AMD більше про роботу в upstream: AMDGPU в ядрі, Mesa в userland, більш «нормальна» поведінка Linux.
Це, як правило, приємніше в експлуатації — менше дивних клеїв, менше бінарних блобів, краща відповідність очікуванням дистрибутивів
щодо графіки. Але в обчисленнях тяжіння до стандартів дає про себе знати: встановлена база CUDA — це захист, а ROCm досі має
гострі краї в підтримці апаратури, пакуванні та довгому хвості бібліотек.

Якщо ви очікуєте універсального переможця — ви сповідуєте релігію. Краще: оберіть режими відмов, з якими ви готові жити.
Якщо ви працюєте з ML, ваші стандартні налаштування формуються під CUDA, поки не доведено протилежне. Якщо ви керуєте
Linux-робочими станціями в масштабі, апстрімна інтеграція і передбачувана робота з ядром зазвичай важливіші за результат у
бенчмарках.

Історичні факти, що й досі визначають рішення

Минуле тут не тривіальність. Воно пояснює, чому певні API стали стандартними, чому драйверні стеки мають такий вигляд і чому
ваш менеджер з продажу використовує слово «roadmap» як заклинання.

8 контекстних пунктів (конкретно, не музейно)

1. ATI було придбано AMD у 2006 році. Це змінило стимули: GPU стали частиною платформи CPU+GPU,
   вплинувши на інтегровану графіку, APU і пізніше на позиціювання «відкритих драйверів».
2. NVIDIA представила CUDA у 2006 році. Воно не було першим у «GPU-обчисленнях», але стало стандартом, бо
   було придатним для використання, стабільним і невтомно просувалося в академії та індустрії.
3. OpenCL не змістив CUDA з трону. Воно існує, працює, відносно портативне і часто слугує «найменшим спільним
   знаменником», у який вендори не завжди однаково інвестували.
4. Траєкторія відкритих драйверів AMD була багаторічним поворотом. Перехід від старих пропрієтарних стеків до
   AMDGPU/Mesa був не лише ідеологією; це був виживальний крок для сумісності з Linux і довіри розробників.
5. Світ GPGPU нормалізував «вендорно-специфічне прискорення». CUDA — очевидний приклад, але багато ML і HPC
   бібліотек закладають припущення щодо ядер, поведінки пам’яті та інструментів профілювання, прив’язані до одного вендора.
6. Ігрова індустрія спричинила агресивну зміну функцій. Зміни в моделях шейдерів, async compute, ray tracing та
   frame-gen роблять «останній драйвер» привабливим — і одночасно небезпечним в експлуатації.
7. Графічні стеки змінювалися під ногами у всіх. Адаптація Wayland і сучасні композитори виявили різні точки тертя
   для пропрієтарних та апстрімних моделей драйверів, особливо для мультиекранів і змінної частоти оновлення.
8. Продуктові лінійки дата-центрів розійшлися від споживчої поведінки. ECC VRAM, телеметрія, управління потужністю та
   функції віртуалізації зробили припущення «це майже той самий кремній» ризиковими.

Дві філософії: закрите й відшліфоване проти відкритого та інтегрованого

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

Сила NVIDIA: тяжіння екосистеми та «одне місце відповідальності»

Найбільший актив NVIDIA — не сирі TFLOPS. Це очікування, що CUDA буде доступна, інструменти — зрілі, а наступна бібліотека, яку ви
pip-install, матиме колесо для CUDA раніше, ніж для чогось іншого. Профілювання послідовне. Підтримка вендора структурована.
У продакшні це важливо: ви можете стандартизувати образи, базові AMI та провізіювання вузлів навколо стеку, який поводиться схоже
між поколіннями обладнання.

Вартість — vendor lock-in і модель драйвера, яка може ігнорувати правила вашого дистрибутива. Оновлення ядра стають питанням
управління змінами. Secure Boot стає обговоренням, а не чекбоксом. І коли еволюціонують сервери відображення, ви чекаєте на сумісність.

Сила AMD/ATI: узгодженість з upstream і «нативна для Linux» поведінка

Наявність AMDGPU в ядрі та Mesa як основного 3D-стеку означає менше екзотичних сюрпризів. Ви отримуєте ті самі процеси реліз-інженерії,
що й для решти Linux. Налагодження може бути прозорішим. І для багатьох графічних робочих навантажень — особливо на сучасних дистрибутивах —
AMD може бути варіантом «просто працює» так, як це колись було немислимо.

Вартість проявляється в обчисленнях і довгому хвості: обмеження підтримки апаратури ROCm, складнощі з фіксацією версій та факт, що багато
upstream-проєктів іще трактують NVIDIA як «ціль», а все інше — як «найкраща спроба».

Оціночна порада: якщо ваш бізнес залежить від певного ML-фреймворка сьогодні, вважайте NVIDIA за замовчуванням, якщо ви не маєте
перевіреного шляху для ROCm. Якщо ж бізнес залежить від Linux-робочих станцій, що мають працювати через оновлення ядра, розглядайте AMD
як стандарт і змушуйте NVIDIA заслужити виняток.

Драйвери, ядра та тонке мистецтво не вивести робочу станцію з ладу

GPU одночасно — обчислювальний пристрій і пристрій відображення. Ці ролі перетинаються в архітектурі драйвера. Шлях відображення дбає
про композитори, modesetting, suspend/resume та дивності мультиекранів. Обчислювальний шлях дбає про стабільні user-space бібліотеки,
послідовне виявлення пристроїв і передбачувану поведінку пам’яті.

Інтеграція з ядром: upstream проти out-of-tree

Основний драйвер AMD є частиною ядра. Це не гарантує досконалості, але означає, що регресії видимі та виправні в тих самих робочих процесах,
що й решта ОС. Пропрієтарний модуль ядра NVIDIA історично жив поза деревом, з іншим темпом і обмеженнями. Ситуація покращується з новими підходами,
але в експлуатації ви все ще маєте планувати зв’язок ядро-драйвер як пріоритетний ризик.

Графічні стеки: Xorg прощає, Wayland чесний

Xorg дозволяє вендорам приховувати недоліки. Wayland робить більше частин каналу явними, і це виявляє невідповідності: явна синхронізація,
управління буферами, маршрутизація між GPU і поведінка VRR. Якщо ви розгортаєте робочі станції розробників або VDI, ваш вибір вендора
часто зводиться до «якій сукупності багів ми хочемо володіти».

Цитата про надійність (парафразована ідея)

Сподівання — це не стратегія. — парафразована ідея, часто цитована в колах опсів/надійності

Ставтеся до вибору вендора GPU як до вибору контролера зберігання: ви бенчмаркуєте, так. Але також тестуєте оновлення, відновлення після відмов
і спостережливість. Ось де суперництво стає реальним.

Обчислювальні стекі: CUDA, ROCm, OpenCL та сила стандартів

Практична причина, чому суперництво не припиняється: CUDA стала стандартним припущенням для «GPU-обчислень». Коли тисяча
внутрішніх скриптів, ноутбуків, контейнерів і сторонніх інструментів припускають CUDA, зміна вендора стає проєктом міграції —
не просто закупівлею.

CUDA: шлях по освітленій дорозі

CUDA — це не просто API; це ціла екосистема дебагерів, профайлерів, математичних бібліотек, бібліотек для колективних операцій та
конвенцій пакування. Ця екосистема зменшує варіативність. Варіативність — те, що викликає інциденти опівночі.

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

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

ROCm може бути відмінним, коли ви на підтримуваному обладнанні та версіях. Продуктивність може бути конкурентною, а історія відкритих
інструментів приваблива. Але операційна пастка — це «майже підтримувано». GPU може працювати з графікою добре, але бути проблемою в обчисленнях.
А невелика невідповідність драйверів може перетворитися на відсутність пристроїв у контейнерах.

OpenCL і «портативні» API

OpenCL — класична відповідь на лоцкін. Але багато команд взаємодіють з ним опосередковано. Деякі програми використовують його для конкретних
ядер або старої прискореної логіки. У 2026 році портативність часто досягається за допомогою фреймворків вищого рівня, які обирають бекенди.
Це прогрес, але і борг абстракції: коли продуктивність погана, ви опиняєтеся в дебагу бекенда, від якого хотіли уникнути.

Оціночна порада: якщо ви хочете портативності — проектуйте її з самого початку. Не купуйте NVIDIA, не пишіть всюди CUDA, а потім «плануйте»
міграцію на AMD пізніше. Це не план; це казка перед сном.

Реалії дата-центрів: ECC, ліміти потужності, терміка та режими відмов

У дата-центрах GPU відмовляють як і будь-які інші компоненти: терміка, живлення, прошивка та деградація кремнію. Різниця в тому, що
збої GPU часто виглядають як баги додатків. Ваше навчання «розійшлося». Рендер має артефакти. Транскоди мають тонкі спотворення. Робоча станція
зависає, але вузол ще відповідає на ping. Вітаємо: у вас тепер проблема виявлення.

ECC VRAM та безшумні помилки даних

ECC у VRAM — це нудно. Нудно — це добре. Якщо ви робите ML-тренування, наукові обчислення, фінансовий аналіз або що-небудь, де важлива правильність,
вважайте ECC вимогою. Якщо ваша лінійка GPU не підтримує його, компенсуйте перевірками валідації і резервуванням та прийміть ризик явно.

Управління енергоспоживанням як важіль продакшну

Дата-центрові GPU можна обмежити за потужністю, щоб відповідати тепловим рамкам. Це не лише про рахунки за електрику; це про те, щоб не
виводити автоматичні вимикачі, не перегрівати шасі і не спричиняти каскади тротлінгу. Інструменти вендорів відрізняються, але принцип той самий:
знайте свої ліміти потужності, вимірюйте причини тротлінгу і встановлюйте обмеження свідомо.

Віртуалізація і розподілення пристроїв

NVIDIA має зрілі історії щодо vGPU у багатьох середовищах. AMD зробила прогрес, але операційна доступність сильно залежить від вашого гіпервізора,
ядра і конкретного SKU. Якщо ви робите VDI або мультиорендний розподіл GPU, не припускайте «це GPU, отже він віртуалізується». Тестуйте весь стек:
ліцензування, хост-драйвери, гостьові драйвери і моніторинг.

Жарт №1: GPU без телеметрії — як масив зберігання без SMART: ви все ще можете його запускати, але швидко навчитеся смиренню.

Три міні-історії з корпоративного світу (з болем)

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

Середня аналітична компанія розгорнула нові GPU-вузли для пайплайну з комп’ютерного зору. Рішення закупити було «сучасні AMD-карти, хороше
співвідношення ціни/продуктивності, дружні до Linux». Кластер був на Kubernetes, і ментальна модель команди була проста: «Якщо вузол бачить GPU,
то й поди побачать GPU».

Хибне припущення: виявлення пристроїв і інтеграція з рантаймом контейнерів поводяться однаково між вендорами. Насправді їхні існуючі плагіни
пристроїв і базові образи були підлаштовані під CUDA. Поди почали падати з «no GPU devices found», але тільки на нових вузлах. Планувальник
постійно переміщував завдання. Черга зростала. SLA просіли.

Першою реакцією була класична витрата часу: переставляли карти та переінсталювали вузли. Нічого не змінилося. GPU були в порядку.
Модулі ядра були завантажені. Але user-space бібліотек у контейнерах не вистачало, і плагін кластера не вмів правильно рекламувати ці пристрої.

Вони виправили це, розглядаючи стек GPU як частину графа залежностей додатка. Нові пулли вузлів отримали явні лейбли, окремі образи і валідаційне
завдання при завантаженні, яке підтверджувало видимість пристрою та тривіальний тест ядра. Урок був неприємний, але цінний: апаратна парність
безглузда, якщо рантайм-припущення специфічні для вендора.

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

Медіакомпанія виконувала GPU-прискорені відеотранскоди на змішаному флоті машин. Інженер помітив «недовикористання» GPU і запропонував швидкий
виграш: упакувати більше конкурентних транс-кодів на одну карту та підняти тактові частоти, щоб стабілізувати пропускну спроможність.

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

Справжня проблема була в тепловій і енергетичній поведінці під тривалим навантаженням. «Оптимізація» зняла запас міцності і штовхнула карти у часті
тротлінги та транзиторні помилки. Деякі робочі навантаження не падають голосно; вони деградують якість або падають недетерміновано. Агресивне
упакування також посилило фрагментацію VRAM і тиск на пам’ять.

Відкат був нудний: обмежити одночасні роботи, зафіксувати ліміти потужності і вводити admission control з урахуванням температури. Постмортем:
GPU не був недовикористаним; він резервував маржу стабільності. Ви можете витратити цю маржу, але готуйтеся платити відсотки.

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

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

Одного місяця рутинне оновлення ОС внесло регресію драйвера GPU, яка виявлялася лише під специфічним патерном колективних комунікацій.
Канарковий вузол зловив це за кілька годин. Логи роботи були дивними, але послідовними: періодичні NCCL-timeout під навантаженням.

Оскільки у команди був прописаний план відкату, вони повернули канарку до попередньої пари драйвер/ядро і лишили решту флоту недоторканою.
Подали баг продавцю і чекали на патч.

Ніяких героїчних дій. Жодних all-hands інцидентів. Ні «ми втратили три дні тренувань». Нудна практика — канаркування оновлень GPU-стеку —
зробила всю різницю між спокійним вівторком і тижнем хаосу.

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

Якщо ви експлуатуєте GPU, вам потрібний м’яз пам’яті перевірок, які скажуть: «Чи видимий GPU? Чи він здоровий? Чи тротлить? Чи стек драйвера
у нормі? Чи вузьке місце — в обчисленні, пам’яті, CPU, I/O чи мережі?»

Нижче — прагматичні завдання для Linux. Вони написані для реальної експлуатації: вказують, що означає вивід і яке рішення прийняти далі.

Завдання 1: Визначити GPU і драйвер ядра, що використовується

cr0x@server:~$ lspci -nnk | grep -A3 -E "VGA|3D|Display"
01:00.0 VGA compatible controller [0300]: NVIDIA Corporation GA102 [GeForce RTX 3090] [10de:2204] (rev a1)
        Subsystem: Micro-Star International Co., Ltd. [MSI] Device [1462:3895]
        Kernel driver in use: nvidia
        Kernel modules: nvidiafb, nouveau, nvidia_drm, nvidia

Що це означає: Ядро використовує nvidia, але nouveau також присутній як опція модуля.

Рішення: Якщо ви бачите конфліктні модулі (наприклад, завантажений nouveau), додайте його до чорного списку і перебудуйте initramfs; інакше ви ризикуєте нестабільним modesetting або проблемами з безголовим обчисленням.

Завдання 2: Підтвердити здоров’я драйвера NVIDIA і базову телеметрію

cr0x@server:~$ nvidia-smi
Tue Jan 13 11:20:10 2026
+-----------------------------------------------------------------------------------------+
| NVIDIA-SMI 550.54.14              Driver Version: 550.54.14      CUDA Version: 12.4     |
|-----------------------------------------+------------------------+----------------------|
| GPU  Name                 Persistence-M | Bus-Id          Disp.A | Volatile Uncorr. ECC |
| Fan  Temp   Perf          Pwr:Usage/Cap |           Memory-Usage | GPU-Util  Compute M. |
|                                         |                        |               MIG M. |
|=========================================+========================+======================|
|   0  NVIDIA A10                    Off  | 00000000:01:00.0  Off  |                  0   |
|  35%   58C    P2              118W / 150W|   6120MiB / 24564MiB   |     72%      Default |
+-----------------------------------------+------------------------+----------------------+

Що це означає: Драйвер завантажено, GPU використовується, потужність нижча за ліміт, ECC показує 0 некоригованих помилок.

Рішення: Якщо nvidia-smi зависає або повідомляє помилки, припиніть і виправте проблеми з драйвером/модулем перед дебагом додатків. Якщо ECC-помилки ростуть, плануйте RMA або ізолюйте карту.

Завдання 3: Перевірити присутність AMD GPU і стан драйвера

cr0x@server:~$ sudo lshw -c display -short
H/W path           Device     Class          Description
========================================================
/0/100/1.0         card0      display        Advanced Micro Devices, Inc. [AMD/ATI] Navi 31 [Radeon RX 7900 XTX]
/0/100/1.0/0       /dev/fb0   display        AMDGPU framebuffer

Що це означає: Система бачить AMD/ATI GPU і використовує AMDGPU framebuffer.

Рішення: Якщо показує vesa або немає framebuffer, ймовірно, у вас проблема з драйвером/initramfs або невідповідністю прошивки.

Завдання 4: Перевірити логи ядра на скидання, зависання або помилки прошивки

cr0x@server:~$ sudo journalctl -k -b | egrep -i "amdgpu|nvidia|gpu|xid|ring|timeout" | tail -n 20
Jan 13 11:02:41 server kernel: NVRM: Xid (PCI:0000:01:00): 79, pid=24118, GPU has fallen off the bus.
Jan 13 11:02:41 server kernel: pcieport 0000:00:01.0: AER: Corrected error received: 0000:00:01.0
Jan 13 11:02:42 server kernel: nvidia 0000:01:00.0: AER: can't recover (no error_detected callback)

Що це означає: «Fallen off the bus» плюс PCIe AER натякають на апаратну нестабільність (живлення, riser, перегрів) більше, ніж на баг додатка.

Рішення: Переставте карты, перевірте кабелі живлення, зменшіть швидкість PCIe в BIOS і перевірте терміку, перш ніж переписувати код.

Завдання 5: Переконатися, що вузли пристрою існують (поширена причина помилок у контейнерах)

cr0x@server:~$ ls -l /dev/nvidia* 2>/dev/null || echo "no nvidia device nodes"
crw-rw-rw- 1 root root 195,   0 Jan 13 11:19 /dev/nvidia0
crw-rw-rw- 1 root root 195, 255 Jan 13 11:19 /dev/nvidiactl
crw-rw-rw- 1 root root 195, 254 Jan 13 11:19 /dev/nvidia-modeset

Що це означає: Вузли пристроїв існують; user space може спілкуватися з драйвером.

Рішення: Якщо відсутні, ваш драйвер не завантажено або udev-правила не спрацювали. Виправте створення вузлів перед тим, як чіпати Kubernetes-плагіни.

Завдання 6: Перевірити вузли пристроїв AMD і налаштування DRM

cr0x@server:~$ ls -l /dev/dri
total 0
drwxr-xr-x 2 root root        100 Jan 13 10:58 by-path
crw-rw---- 1 root root  226,   0 Jan 13 10:58 card0
crw-rw---- 1 root render 226, 128 Jan 13 10:58 renderD128

Що це означає: DRM-вузли існують. Обчислювальні фреймворки часто потребують доступу до renderD128.

Рішення: В контейнерах переконайтеся, що процес користувача в правильній групі або що ви передали пристрій; інакше ви побачите «permission denied», що маскується під «no GPU».

Завдання 7: Підтвердити, який OpenGL/Vulkan драйвер ви справді використовуєте (Mesa чи пропрієтарний)

cr0x@server:~$ glxinfo -B | egrep "OpenGL vendor|OpenGL renderer|OpenGL version"
OpenGL vendor string: AMD
OpenGL renderer string: AMD Radeon RX 7900 XTX (radeonsi, navi31, LLVM 17.0.6, DRM 3.54, 6.6.12)
OpenGL version string: 4.6 (Core Profile) Mesa 24.0.3

Що це означає: Ви на Mesa/radeonsi, а не на якомусь fallback-рендерері.

Рішення: Якщо рендерер показує «llvmpipe», ви на програмному рендерингу. Припиніть бенчмаркувати ігри та виправте стек відображення.

Завдання 8: Перевірити температуру GPU і натяки на тротлінг (загальні sensors)

cr0x@server:~$ sensors | egrep -i "edge|junction|gpu|amdgpu" | head
amdgpu-pci-0100
edge:         +62.0°C
junction:     +88.0°C

Що це означає: Junction temp висока; підтримуване навантаження може тротлити або давати помилки при поганому повітрообміні.

Рішення: Якщо junction близька до граничних значень під нормальним навантаженням, виправте повітрообмін шасі або зменшіть ліміт потужності до того, як бігти шукати «випадкові» крахи.

Завдання 9: Перевірити завантаження GPU і використання за процесами (NVIDIA)

cr0x@server:~$ nvidia-smi pmon -c 1
# gpu        pid  type    sm   mem   enc   dec   command
    0      24118     C    72    41     0     0   python
    0      10211     G     3     1     0     0   Xorg

Що це означає: Один обчислювальний процес домінує; Xorg мінімальний.

Рішення: Якщо бачите багато дрібних процесів, кожен з невеликим SM, але великою пам’яттю, ви можете мати накладні витрати; консолідуйте батчі або збільшіть роботу на запуск.

Завдання 10: Підтвердити видимість CUDA toolkit у вашому рантаймі

cr0x@server:~$ nvcc --version
nvcc: NVIDIA (R) Cuda compiler driver
Copyright (c) 2005-2025 NVIDIA Corporation
Cuda compilation tools, release 12.4, V12.4.131

Що це означає: CUDA-компілятор встановлено в цьому середовищі.

Рішення: Якщо додатки падають з «CUDA not found», а nvidia-smi працює, ваш контейнер або venv не мають user-space бібліотек; виправляйте збірку образу, а не хост-драйвер.

Завдання 11: Перевірити видимість ROCm (AMD compute)

cr0x@server:~$ /opt/rocm/bin/rocminfo | head -n 12
ROCk module is loaded
=====================
HSA Agents
==========
*******
Agent 1
  Name:                    gfx1100
  Uuid:                    GPU-XX
  Marketing Name:          AMD Radeon RX 7900 XTX

Що це означає: ROCm-стек бачить GPU як HSA-агента.

Рішення: Якщо ROCm не бачить GPU, але графіка працює, ймовірно, у вас непідтримувана комбінація ROCm/обладнання. Зупиніться і вирівняйте версії або апарат.

Завдання 12: Виявити CPU-вузькі місця, що маскуються під «повільний GPU»

cr0x@server:~$ mpstat -P ALL 1 3
Linux 6.6.12 (server)  01/13/2026  _x86_64_  (64 CPU)

11:21:01 AM  CPU   %usr %nice %sys %iowait %irq %soft %steal %idle
11:21:02 AM  all   92.10 0.00 3.22   0.04 0.00 0.30  0.00  4.34
11:21:02 AM    7   99.70 0.00 0.30   0.00 0.00 0.00  0.00  0.00

Що це означає: CPU насичені; одне ядро задіяне на повну. GPU може чекати підготовки вводу, декомпресії, overhead Python або потоків даталоадера.

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

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

cr0x@server:~$ sudo lspci -s 01:00.0 -vv | egrep -i "LnkSta|LnkCap"
LnkCap: Port #0, Speed 16GT/s, Width x16, ASPM L1, Exit Latency L1 <64us
LnkSta: Speed 8GT/s (downgraded), Width x8 (downgraded)

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

Рішення: Пересуньте GPU у слот, перевірте BIOS, перевірте riser/кабель і підтвердіть підключення слота. Якщо знижено навмисно (поділені лінії), плануйте відповідно.

Завдання 14: Переконатися, що I/O не голодує GPU (поширено для тренувань)

cr0x@server:~$ iostat -xz 1 3
Device            r/s     w/s   rkB/s   wkB/s  await  %util
nvme0n1         220.0    15.0  54000.0  8000.0  18.5  92.0

Що це означає: NVMe на 92% завантаженості з високим await; ваш даталоадер може бути I/O-зв’язаний і пізно підживлювати GPU.

Рішення: Кешуйте датасети локально, збільшіть read-ahead, використайте швидше сховище або попередньо шардуйте/стискайте дані по-іншому. Проблема з «використанням GPU» може бути проблемою диска.

Завдання 15: Перевірити мережеві вузькі місця для багатовузлового тренування

cr0x@server:~$ sar -n DEV 1 3 | egrep "IFACE|eno1"
11:22:11 AM IFACE   rxpck/s   txpck/s    rxkB/s    txkB/s   rxcmp/s   txcmp/s  rxmcst/s
11:22:12 AM eno1    8200.00   9100.00  980000.00 1040000.00   0.00      0.00     0.00

Що це означає: Ви близькі до лінійної швидкості (приблизно 10GbE у KB/s). All-reduce може наситити це і блокувати GPU.

Рішення: Оновіть fabric, увімкніть RDMA де доречно, або налаштуйте розміри батчів/накопичення градієнтів, щоб зменшити частоту синхронізації.

Завдання 16: Підтвердити, що рантайм контейнера бачить GPU (приклад NVIDIA)

cr0x@server:~$ docker run --rm --gpus all nvidia/cuda:12.4.1-base-ubuntu22.04 nvidia-smi
Tue Jan 13 11:23:19 2026
+-----------------------------------------------------------------------------------------+
| NVIDIA-SMI 550.54.14              Driver Version: 550.54.14      CUDA Version: 12.4     |
+-----------------------------------------------------------------------------------------+

Що це означає: Інтеграція хост-драйвера і рантайму контейнера працює.

Рішення: Якщо це не працює, виправте nvidia-container-toolkit і конфігурацію рантайма перед тим, як звинувачувати ваш ML-фреймворк.

Жарт №2: Вибір між AMD і NVIDIA — як вибір між двома базами даних: хтось буде неправий, і, можливо, це будете ви.

Плейбук швидкої діагностики: знайти вузьке горлечко швидко

Коли продуктивність падає або завдання падають, вам нема часу на філософію. Потрібен відтворюваний порядок триажу, що ріже шум. Ось порядок,
який зазвичай працює у реальних флотах.

Перше: «Чи GPU взагалі здоровий і видимий?»

• Видимість апаратури: lspci -nnk показує пристрій і потрібний драйвер ядра.
• Телеметрія: nvidia-smi працює (NVIDIA) або rocminfo працює (ROCm) і не каже помилок.
• Логи ядра: проскануйте journalctl -k -b на предмет скидань, Xid, таймаутів кілець, помилок завантаження прошивки.

Умова зупинки: Якщо ви бачите шуми PCIe/AER, «fallen off the bus», таймаути кілець або спам прошивки — спочатку розглядайте це як платформну проблему.

Друге: «Чи GPU тротлить або голодний?»

• Терміка: sensors або телеметрія вендора. Слідкуйте за junction-temp під тривалим навантаженням.
• Ліміти потужності: порівняйте usage/cap (NVIDIA: nvidia-smi). Шукайте стійкі P-state на низькому рівні.
• Підживлення пайплайну: перевірте CPU (mpstat), диск (iostat) і мережу (sar -n DEV).

Умова зупинки: Якщо CPU завантажений або диск на 90% завантаженості — виправте це. GPU не працюють на мареннях.

Третє: «Чи стек програмного забезпечення неузгоджений?»

• Вирівнювання версій: версія драйвера проти версії тулкіта (CUDA/ROCm) і очікувань фреймворку.
• Контейнери: валідируйте відомим мінімальним контейнерним тестом (наприклад, nvidia/cuda).
• Дозволи: вузли пристроїв і членство в групах (/dev/nvidia*, /dev/dri/renderD*).

Умова зупинки: Якщо мінімальний контейнер падає, дебаг додатка передчасний.

Четверте: «Чи це невідповідність робочого навантаження?»

• Ядра, обмежені пам’яттю, проти обчислювально-обмежених ядер: якщо пропускна здатність VRAM — ліміт, купівля додаткових SM не допоможе.
• Малі розміри батчів: GPU витрачає час на запуск ядер, а не на роботу.
• Накладні синхронізації: масштабування на кілька GPU обмежене інтерконектом або мережею.

Рішення: Оптимізуйте форму робочого навантаження (батчінг, пайплайн даних, точність, об’єднані операції) перед тим, як міняти вендора з розчарування.

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

1) «GPU встановлений, але мій контейнер каже, що GPU немає»

Симптоми: Логи додатка показують «CUDA device not found» або кількість пристроїв ROCm = 0 всередині контейнерів.

Корінь: Відсутня інтеграція рантайма контейнера (NVIDIA toolkit), неправильний плагін пристрою або вузли пристроїв не змонтовані/не мають прав.

Виправлення: Провалідуйте мінімальним контейнером (docker run --gpus all ... nvidia-smi), потім вирівняйте конфігурацію рантайма і плагіна під вендора.

2) «Продуктивність погіршилась після оновлення ядра»

Симптоми: Те ж навантаження, менше використання GPU, нові підвисання/зависання, інколи графічні глюки композитора.

Корінь: Несумісність ядро/драйвер, регресія в DRM-стеку або проблеми збірки пропрієтарних модулів після оновлення.

Виправлення: Закріплюйте ядро+драйвер як одиницю, робіть канаркові оновлення і тримайте шлях відкату. Для робочих станцій явно перевіряйте поведінку Wayland/Xorg.

3) «Тренування повільніше, але GPU показує 30% використання»

Симптоми: Низьке використання GPU, високі CPU, активний диск або стиснення мережі.

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

Виправлення: Профілюйте CPU і I/O; кешуйте датасети на швидкому локальному NVMe; збільшуйте кількість воркерів для лоадера; попроцесуйте дані офлайн; розгляньте GPU-прискорене декодування.

4) «Випадкові жорсткі зависання під навантаженням»

Симптоми: Вузол перестає відповідати, GPU зникає, логи ядра показують Xid або таймаути кілець, інколи AER-події.

Корінь: Проблеми з живленням, тепловий розгін, непевні riser-и, нестабільна домовленість PCIe або баги прошивки, що виявляються під тривалим навантаженням.

Виправлення: Зменшіть ліміт потужності, покращте повітрообмін, пересуньте карти, замініть riser-и, оновіть BIOS/прошивку, протестуйте на нижчому PCIe-gen і ізолюйте підозрілі GPU.

5) «Ми оптимізували паралелізм, і тепер якість виходу непослідовна»

Симптоми: Артефакти відео, рідкісні крахи енкодера, недетерміновані збої, інколи NaN-значення.

Корінь: Тепловий тротлінг або тиск пам’яті, що посилюють крайові баги; фрагментація VRAM; надто багато контекстів.

Виправлення: Зменшіть конкуренцію, встановіть обмеження потужності/терміки, впровадьте admission control і перевіряйте коректність вибірково.

6) «Wayland багатодисплейний — наче привид»

Симптоми: Мерехтіння, дивна поведінка VRR, програми підгальмовують на одному моніторі, випадкові чорні екрани після resume.

Корінь: Взаємодія явної синхронізації драйвера/композитора, змішані частоти оновлення або проблеми маршрутизації між GPU.

Виправлення: Тестуйте на відомо стабільній парі драйвер/композитор; розгляньте Xorg для критичних робочих станцій; стандартизуйте конфігурації моніторів; уникайте змішування VRR та non-VRR панелей у fleet-розгортаннях.

Чек-листи / покроковий план

Чек-лист A: Вибір AMD чи NVIDIA для нового розгортання

1. Визначте «стандартну екосистему» навантаження. Якщо це ML з популярними фреймворками та сторонніми інструментами, вважайте CUDA-першим, поки не доведено протилежне.
2. Прийміть позицію щодо оновлень. Якщо потрібно відстежувати останні ядра (робочі станції розробників), узгодженість з upstream — серйозна перевага.
3. Перерахуйте незмінні вимоги: ECC? віртуалізація? SR-IOV/vGPU? конкретні кодеки? вимоги до стеку відображення?
4. Оберіть підтримувану матрицю, а не продукт. Вибирайте (SKU GPU, версія драйвера, версія ядра, версія дистрибутива, базовий образ контейнера) як протестовану одиницю.
5. Запустіть burn-in тест. 24–72 години тривалого навантаження плюс цикли suspend/resume (якщо робоча станція), додайте мульти-GPU тести (якщо кластер).
6. Сплануйте спостережливість. Потрібна пер-вузлова телеметрія GPU і алерти на температуру, ECC-помилки, тротлінг і скидання пристроїв.

Чек-лист B: Безпечні оновлення GPU-стеку (драйвери/тулкіти)

1. Зробіть інвентар поточних версій і зафіксуйте їх (драйвер, тулкіт, ядро, прошивка).
2. Оновіть один канарковий вузол першим. Запускайте репрезентативні робочі навантаження, а не синтетичні бенчмарки.
3. Перевірте логи ядра на нові попередження після burn-in.
4. Провалідируйте доступ контейнера до GPU відомим мінімальним образом.
5. Тільки потім розгортайте на невеликий відсоток, а потім по всьому флоту.
6. Тримайте артефакти відкату готовими: попередні пакунки, запис ядра і теги контейнерів.

Чек-лист C: Коли ви підозрюєте, що GPU «повільний»

1. Підтвердьте швидкість/ширину лінку (домовленість PCIe).
2. Підтвердьте ліміт потужності і поведінку P-state.
3. Підтвердьте терміку і сигнали тротлінгу.
4. Заміряйте насичення CPU і «гарячі» ядра.
5. Заміряйте диск і мережу на предмет насичення.
6. Лише потім профілюйте ядра GPU і поведінку пам’яті.

FAQ

1) Чи «ATI проти NVIDIA» ще актуально, якщо ATI стала AMD?

Так, бо назва бренду змінилася, але базове протистояння залишилося: спадщина GPU AMD проти NVIDIA. Люди й досі кажуть «ATI», як опси кажуть «ethernet», коли мають на увазі «мережа». Це неточно, але суперництво реальне.

2) Для Linux-робочих станцій що менш болюче?

Якщо ви хочете менше сюрпризів при змінах ядра і композитора, upstream-модель драйвера AMD часто плавніша.
NVIDIA може працювати відмінно, але оновлення драйвера варто трактувати як подію зміни, а не як фонований процес.

3) Для машинного навчання сьогодні AMD може замінити NVIDIA?

Іноді так — особливо з ROCm на підтримуваному обладнанні і добре протестованих фреймворках. Але CUDA залишається стандартним припущенням у багатьох інструментах і попередньо зібраних бінарниках. Якщо вам потрібна максимальна сумісність з мінімальною інтеграцією, NVIDIA — практичний вибір.

4) Чому CUDA «перемагає», навіть коли апарат сильний?

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

5) Чи означає пропрієтарні драйвери автоматично «нестабільність»?

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

6) Чи варто платити за ECC VRAM?

Якщо важлива коректність — так. Безшумна корупція даних — це тип помилки, який проходить через дашборди і виявляється як «модель стала дивною» або «рендер має артефакти». ECC не вирішує все, але значно знижує ризик.

7) Яка найпоширеніша причина поганої роботи GPU у продакшні?

Голодування: CPU-препроцесинг, повільне сховище або синхронізація мережі. GPU стає видимим компонентом, тому його й звинувачують. Виміряйте весь пайплайн, перш ніж міняти апарат.

8) Чи варто стандартизувати на одного вендора по всій компанії?

Стандартизуйте по платформах, де можливо. Один вендор для ML-кластерів може зменшити варіативність інструментів. Інший вендор для Linux-робочих станцій може зменшити проблеми зі стеком відображення. Мета — менше матриць сумісності, а не ідеологічна чистота.

9) Коли варто свідомо обрати «нестандартний» варіант?

Коли ви можете довести це на вашому конкретному робочому навантаженні і готові взяти на себе інтеграцію. Якщо команда має експертизу ROCm і моделі у вас добре працюють там, AMD може стати стратегічною вигодою за вартістю/продуктивністю. Якщо потрібна максимальна стороння сумісність, оберіть NVIDIA і витратьте час на спостережливість замість портингу.

Наступні кроки, які можна зробити цього тижня

Суперництво ATI/AMD проти NVIDIA не закінчиться, бо його підживлюють реальні компроміси: інтеграція з upstream проти екосистемного лоцкіну, відкритість проти відшліфованості,
сумісність проти контролю. Ви не вирішите це діаграмою бенчмарків. Ви вирішите це операційним наміром.

1. Запишіть вашу підтримувану матрицю (SKU GPU, драйвери, ядро, дистро, образи контейнерів). Якщо це не записано — це не підтримується.
2. Побудуйте процес канаркування для оновлень GPU-стеку. Один вузол першим. Завжди.
3. Додайте телеметрію і алерти на температуру, тротлінг, скидання і ECC-помилки. Якщо ви цього не бачите — ви не володієте проблемою.
4. Запустіть практичні завдання вище на одному здоровому вузлі і одному «проблемному» і порівняйте виводи. Більшість таємниць — це різниці.
5. Оберіть вендора, базуючись на ваших обмеженнях: тяжіння CUDA для ML, узгодженість з upstream для Linux-флотів, апаратні функції (ECC/віртуалізація) для дата-центрів.

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