NVIDIA vs AMD vs Intel: що потрібно конкуренції, щоб зберегти здоровий глузд

Що повинна забезпечувати конкуренція (і що їй слід припинити)

«NVIDIA vs AMD vs Intel» зазвичай подають як порівняння продуктивності, і продуктивність — це важливо. Але в продакшні продуктивність — це третє питання. Перш за все: чи зможемо ми запускати це надійно? По‑друге: чи зможемо ми це передбачувано купувати? По‑третє: чи зможемо ми змінити рішення пізніше?

1) Конкуренція має тримати програмні екосистеми чесними

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

• Стабільних, документованих ядер і драйверів, які не ламають userland при патч‑релізі.
• Паритету інструментів (профайлери, дебагери, телеметрія), щоб SRE могли діагностувати проблеми без докторської з легенд постачальника.
• Кращих стандартів (IR компілятора, runtime API, шаблони дистрибуції контейнерів), бо клієнти вимагають портативності, коли мають вибір.

2) Конкуренція має зробити ланцюжки постачань менш абсурдними

Дорожні карти апаратного забезпечення тепер — бізнес‑дорожні карти. Якщо ваш запуск навчання залежить від одного SKU, який може поставити лише один постачальник, у вас немає інфраструктурного плану. У вас прогноз погоди.

3) Конкуренція має підштовхувати енергоефективність як першокласний критерій

У 2026 році «вартість» обчислень визначається електроенергією, охолодженням, лімітами щільності у стійці та людьми, які це обслуговують. Найкращий акселератор — той, що досягає ваших цілей по латентності/продуктивності, не змушуючи вас перебудовувати дата‑центр під нього.

Цитата, яку варто закріпити у папці закупівель: «Hope is not a strategy.» — General Gordon R. Sullivan. В оперуванні це практично філософія моніторингу.

Короткий жарт №1: Ринок GPU — єдине місце, де «доступно» вважається просунутою функцією.

Кілька фактів і історія, які досі мають значення

Шість‑десять конкретних фактів не вирішать вашу архітектуру, але вони убережуть від мислення «це все нова річ». Ось дев’ять, що досі впливають на рішення:

1. CUDA (представлена в 2006) перетворила GPU на загальнопрофільну обчислювальну платформу, а не лише графічне устаткування. Це створило гравітаційне поле бібліотек і звичок розробників.
2. AMD купила ATI у 2006, успадкувавши таланти і продуктові лінії GPU, і провела роки, узгоджуючи пріоритети «графіка‑перший» і «обчислення‑перший».
3. OpenCL (Khronos, 2009) обіцяла крос‑вендорні обчислення на GPU. Теоретично дала портативність; на практиці багато робочих навантажень отримали «портативний біль продуктивності».
4. HBM (High Bandwidth Memory) стала визначальною перевагою для датапаралельних акселераторів: це не лише FLOPS, а й здатність годувати ядра без їхнього голодування.
5. PCIe традиційно був вузьким місцем для переміщення даних GPU↔CPU; апгрейди поколінь допомагають, але неакуратна топологія все одно вбиває продуктивність.
6. NVLink висунув високу пропускну здатність GPU↔GPU як диференціатор продукту, особливо для тренувань, які потребують швидкого all‑reduce.
7. ROCm дозрівав нерівномірно між поколіннями GPU і дистро Linux; ситуація поліпшилася, але «матриця підтримки» досі є реальним операційним обмеженням.
8. oneAPI від Intel — стратегічна спроба уніфікувати програмування CPU, GPU та акселераторів — корисна, коли працює, і фруструюча, коли екосистема навколо неготова.
9. Інференс змінив економіку: тренування дає заголовки, але стабільний інференс у масштабі — там, де вирішуються вартість на токен, енергія та простота операцій.

Ці факти — не вікторина. Вони пояснюють, чому існує програмний ров NVIDIA, чому можливість AMD постійно повертається, і чому історія Intel нерозривно пов’язана з CPU‑платформою та корпоративними відносинами.

Як мислити про NVIDIA vs AMD vs Intel, не обманюючи себе

Більшість порівнянь — або фанатські війни, або театральність закупівель. Ось продакшн‑погляд: розглядайте кожного постачальника як пакет кремній + драйвер + runtime + бібліотеки + інструменти + поведінка підтримки + ланцюжок постачань. GPU — найменша частина проблеми.

NVIDIA: дефолт, з причин, що не лише технічні

Найбільша перевага NVIDIA — не сирі показники. Це те, що CUDA стала центром тяжіння для ML‑інструментів, плюс довга історія доставки досвіду розробника, що працює «з коробки» частіше, ніж ні. У продакшні це означає:

• Швидший час до першого успіху для команд без глибоких знань компіляторів/руттаймів.
• Краще покриття екосистеми: ядра, реалізації attention, рантайми для інференсу, інструменти квантізації, профайлери.
• Більш передбачувана підтримка в стандартних Linux‑середовищах (ще не ідеально; нічого не ідеально).

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

AMD: правдоподібний кремній, зрілість софта — вирішальний фактор

Основна цінність AMD проста: сильний потенціал продуктивності і шанс розбити монокультуру. Але в продакшні ROCm судять не за слайдами; його оцінюють по:

• Чи підтримується і стабільний саме ваша комбінація дистро/ядра.
• Чи ключові фреймворки і ядра дають очікувану продуктивність без героїчного тюнінгу.
• Чи ваша команда може дебажити й профілювати проблеми з такою ж швидкістю, як на CUDA.

AMD може виграти багато, де клієнти готові стандартизувати середовище, ретельно валідувати і вимагати відповідальності від постачальника. Програє там, де команди очікують «встановив і помолився».

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

Позиція Intel унікальна: вона вже володіє великою частиною CPU‑платформи, відносинами з закупівельниками і «нудними, але критичними» корпоративними каналами. Ставка — що oneAPI і GPU Intel можуть запропонувати прийнятний шлях акселерації, який вписується в існуючі парки.

На практиці Intel зазвичай цікавіша, коли:

• Ваші навантаження вже виграють від Intel CPU і ви хочете тіснішої інтеграції.
• Ви дбаєте про довгострокову стабільність постачальника і корпоративні моделі підтримки.
• Ви готові прийняти, що деякі куточки екосистеми будуть менш зрілі, ніж CUDA‑перші шляхи.

Як виглядає здорова конкуренція

Це не «троє рівних у всьому». Так не буває. Здорова конкуренція це:

• Щонайменше два життєздатні варіанти для ваших найважливіших робочих навантажень.
• Портативні архітектури, де бізнес‑логіка не одружена на одному API постачальника.
• Бенчмарки, які ви запускаєте самі, прив’язані до ваших даних, розмірів батчів, SLO по латентності.

Програмні стеки: CUDA, ROCm, oneAPI та реальна вартість «портативності»

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

Три шари, які слід розділити

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

• Шар фреймворку: PyTorch, TensorFlow, JAX, XGBoost, стеки для сервінгу на кшталт Triton Inference Server.
• Шар ядер/бібліотек: аналоги cuDNN/hipDNN, BLAS, ядра attention, квантізація, колективна комунікація.
• Шар рантайму/драйвера: CUDA runtime/driver, стек ROCm, Level Zero/oneAPI рантайми.

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

Що робити в продакшні

• Віддавайте перевагу фреймворкам, що вже підтримують кілька бекендів для вашого класу робочих навантажень, навіть якщо сьогодні ви розгортаєте на одному постачальнику.
• Уникайте кастомних CUDA‑розширень, якщо лише це не необхідно. Якщо потрібно — ізолюйте їх за чітким інтерфейсом і тримайте CPU‑фолбек для тестування коректності.
• Побудуйте «CI‑ланку портативності»: запускайте щотижневу джобу на непервинному вендорі, щоб варіант залишався живим.

Короткий жарт №2: «Ми зробимо це портативним пізніше» — це софтверний варіант «я почну бекапи після цього деплою».

Операційна реальність: драйвери — частина вашого застосунку

У світі GPU «застосунок» включає в себе:

• Версію ядра
• Версію драйвера GPU
• Прошивку (GPU, NIC, іноді материнська плата)
• Версії runtime контейнера і device plugin
• Опції збірки фреймворку

Якщо ви не прив’язуєте і не валідуєте це так само ретельно, як зміни схеми бази даних, ви обираєте випадкові відмови.

Апаратні реалії: пам’ять, інтерконекти і чому PCIe завжди підозрюваний

Коли продуктивність погана, люди звинувачують «GPU». На практиці це часто пропускна здатність пам’яті, топологія або голодування з боку CPU. Ось ручки, що справді рухають стрілку.

HBM — ємність і пропускна здатність: тихе обмеження

Для тренувань і великих батчів інференсу ємність HBM визначає, чи можна тримати активності і KV‑кеш у пам’яті. Пропускна здатність HBM визначає, чи витрачають ваші обчислювальні блоки життя на очікування.

Правило прийняття рішення: якщо ви бачите низьке завантаження обчислень, але високий тиск контролера пам’яті, вам не потрібно «більше TFLOPS». Потрібна краща поведінка з пам’яттю: злиті ядра, кращі розміри батчів, квантізація або інший SKU з більшою пропускною здатністю.

Зв’язки GPU↔GPU і GPU↔CPU: топологія важить більше за бренд

Інтерконект — це те, де живе або вмирає багатографічне тренування. Якщо ваш all‑reduce повільний, ви можете мати найкращий GPU на папері і все одно програти дешевшій машині з кращою топологією. Потрібно знати:

• Чи йде трафік GPU↔GPU через fabric на кшталт NVLink, чи стрибає через PCIe?
• Чи розподілені GPU по сокетах CPU з поганою NUMA‑вирівнянням?
• Чи розташовано NIC на «неправильному» root complex, змушуючи крос‑сокетні переходи?

Потужність і термальні режими: стрибки продуктивності, яких не видно в бенчмарках

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

Закупівлі для SRE: питання, які ваш постачальник не поставить

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

Що слід вимагати перед покупкою

• Підтримувана матриця софта: точні версії ОС, діапазони ядер, версії драйверів і очікування щодо runtime контейнерів.
• Історія оновлення прошивки: як ви патчите в масштабі, як часто і що ламається?
• Очікування RMA і запасних комплектуючих: терміни постачання, крос‑шип і що означає «відмова» в їхніх логах.
• Сумісність телеметрії: чи можна отримати потрібні метрики без пропрієтарних агентів, що конфліктують із вашим середовищем?
• Чітка документація топології інтерконекту для SKU сервера, який ви дійсно купуєте, а не для референс‑дизайну.

Що слід побудувати всередині

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

Швидкий план діагностики: що перевіряти першим/другим/третім, щоб швидко знайти вузьке місце

Це послідовність «припиніть суперечки, почніть вимірювати». Вона працює для всіх постачальників, бо базується на фізиці й ОС, а не на бренді.

Перше: чи GPU реально використовується?

• Перевірте завантаження, частоти, споживання енергії та використання пам’яті.
• Якщо завантаження низьке, але завдання «повільне», ймовірно ви прив’язані до CPU, I/O або заблоковані на синхронізації.

Друге: чи переміщення даних — справжній вузький гід

• Шукайте високий PCIe RX/TX при низьких обчисленнях.
• Перевірте швидкість/ширину лінка PCIe (x16 vs x8; Gen5 vs Gen4) і локальність NUMA.
• Для multi‑GPU валідуйте peer‑to‑peer і колективну пропускну здатність.

Третє: чи фреймворк не переходить на повільний шлях?

• Підтвердіть, що потрібний бекенд активний (CUDA/ROCm/oneAPI) і ключові операції використовують прискорені ядра.
• Слідкуйте за логами на предмет попереджень «fallback» і несподіваного розміщення пристрою.

Четверте: чи вузол стабільний під тривалим навантаженням?

• Перевірте тротлінг (термали/потужність), помилки ECC і скидання драйвера.
• Перевірте журнали ядра на предмет PCIe/AER‑помилок та подій на зразок GPU Xid.

П’яте: чи кластер scheduller вам не брешуть?

• Перевірте здоров’я device plugin, обмеження cgroup, конфігурацію MIG/партиціонування та інтеграцію runtime контейнера.
• Підтвердіть, що ви не перевантажуєте CPU/пам’ять для GPU‑завдань (поширено в Kubernetes).

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

Це реальні, виконувані перевірки. Використовуйте їх під час інцидентів, планування ємності та вендорських bake‑off. Мета — не збирати тривіальні дані; а приймати рішення.

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

cr0x@server:~$ lspci -nn | egrep -i 'vga|3d|display'
01:00.0 3D controller [0302]: NVIDIA Corporation Device [10de:2330] (rev a1)
21:00.0 Display controller [0380]: Advanced Micro Devices, Inc. [AMD/ATI] Device [1002:74a1] (rev c1)

Що це означає: Ви бачите, які пристрої постачальників присутні та їхні PCI ID. Змішані парки нормальні; змішані драйвери на одному вузлі зазвичай — ні.

Рішення: Якщо пристрій не відповідає тому, що ви думали розгорнути, зупиніться. Виправте інвентар і планування перед тим, як щось оптимізувати.

Завдання 2: Перевірити ядро і деталі ОС (звідси починається сумісність драйверів)

cr0x@server:~$ uname -r
6.5.0-17-generic

Що це означає: Версія ядра впливає на модулі DKMS, поведінку IOMMU і матриці підтримки вендора.

Рішення: Якщо ви поза підтримуваним діапазоном ядра вендора, ви займаєтесь науковим проєктом. Поверніться на підтримуване ядро.

Завдання 3: Швидкий огляд здоров’я NVIDIA (завантаження, енергія, частоти)

cr0x@server:~$ nvidia-smi
Tue Jan 21 02:31:09 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 H100 PCIe                 On | 00000000:01:00.0 Off |                    0 |
| N/A   61C    P0              280W / 350W|  62480MiB / 81559MiB |     92%      Default |
+-----------------------------------------+----------------------+----------------------+

Що це означає: Високий GPU‑Util з високим споживанням енергії і стабільним станом P0 свідчить, що GPU виконує роботу. Низьке завантаження при високому використанні пам’яті часто означає, що дані в пам’яті, але обчислення простівають (конвеєр даних, синхронізація або неефективні ядра).

Рішення: Якщо GPU‑Util низький, перемістіть фокус на CPU/I/O/планування або на випадок відкату фреймворку.

Завдання 4: Огляд здоров’я AMD ROCm (якщо встановлено ROCm)

cr0x@server:~$ rocm-smi
========================ROCm System Management Interface========================
GPU[0]          : GPU ID: 0x74a1
GPU[0]          : Temp (Sensor edge) (C): 58.0
GPU[0]          : Average Graphics Package Power (W): 240.0
GPU[0]          : VRAM Total (B): 68719476736
GPU[0]          : VRAM Used (B): 42949672960
GPU[0]          : GPU use (%): 88

Що це означає: Та сама логіка, що й для NVIDIA: завантаження/енергія/температура показують, чи задіяний акселератор і чи є він термічно навантажений.

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

Завдання 5: Перерахунок Intel GPU (Level Zero)

cr0x@server:~$ /usr/bin/zeinfo | head
Level Zero API version: 1.13
Driver version: 1.3.29735
Devices:
  Device 0: Intel(R) Data Center GPU

Що це означає: Підтверджує, що Level Zero runtime бачить пристрій і драйвер завантажений.

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

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

cr0x@server:~$ sudo lspci -s 01:00.0 -vv | egrep -i 'LnkCap|LnkSta'
LnkCap: Port #0, Speed 32GT/s, Width x16
LnkSta: Speed 16GT/s (downgraded), Width x8 (downgraded)

Що це означає: Карта може працювати PCIe Gen5 x16, але зараз вона працює як Gen4 x8. Це податок на продуктивність, іноді катастрофа.

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

Завдання 7: Перевірити NUMA‑топологію (GPU розміщено далеко від ваших CPU-потоків)

cr0x@server:~$ numactl --hardware
available: 2 nodes (0-1)
node 0 cpus: 0-31
node 1 cpus: 32-63
node 0 size: 256000 MB
node 1 size: 256000 MB

Що це означає: Система з двома сокетами. Якщо GPU прикріплено до node 1, а ваш dataloader працює на node 0, ви платите за крос‑сокетну латентність і пропускну здатність.

Рішення: Прикріпіть CPU‑потоки і алокацію пам’яті до NUMA‑ноди, локальної для GPU, для стабільності пропускної здатності і хвостової латентності.

Завдання 8: Відобразити PCI‑пристрої на NUMA‑ноди

cr0x@server:~$ cat /sys/bus/pci/devices/0000:01:00.0/numa_node
1

Що це означає: Цей GPU локальний для NUMA‑ноди 1.

Рішення: Запустіть pipeline вводу і CPU‑передобробку на node 1 (або свідомо прийміть втрати).

Завдання 9: Перевірити налаштування IOMMU (може шкодити латентності і P2P)

cr0x@server:~$ dmesg | egrep -i 'iommu|dmari' | head
[    0.112345] DMAR: IOMMU enabled
[    0.112900] DMAR: Intel(R) Virtualization Technology for Directed I/O

Що це означає: IOMMU увімкнено. Це часто необхідно для віртуалізації та ізоляції, але неправильні налаштування можуть лама��ти P2P або знижувати продуктивність.

Рішення: Якщо вам потрібен GPU peer‑to‑peer або максимальна пропускна здатність, валідуйте рекомендований режим IOMMU вендора (увімкнено, passthrough або конкретні параметри ядра) і протестуйте.

Завдання 10: Знайти помилки ядра, пов’язані з GPU (AER, скидання, подібні Xid події)

cr0x@server:~$ sudo journalctl -k -S -2h | egrep -i 'nvrm|xid|amdgpu|pcie|aer|gpu reset' | tail
Jan 21 01:44:10 server kernel: pcieport 0000:00:01.0: AER: Corrected error received: id=00e0
Jan 21 01:44:10 server kernel: amdgpu 0000:21:00.0: GPU reset begin!
Jan 21 01:44:14 server kernel: amdgpu 0000:21:00.0: GPU reset succeeded

Що це означає: Виправлені помилки PCIe і скидання GPU. Навіть «виправлені» помилки корелюють з ненадійними riser’ами, маргінальним живленням або поганими лініями.

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

Завдання 11: Підтвердити, що runtime контейнера бачить GPU (Kubernetes або standalone)

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

Що це означає: Контейнер має доступ до GPU і стек драйвера правильно підключений через runtime.

Рішення: Якщо це не працює — виправляйте runtime контейнера/device plugin/дозволи перед тим, як чіпати код додатка.

Завдання 12: Перевірити виділення GPU в Kubernetes (чи дійсно вам призначено GPU?)

cr0x@server:~$ kubectl describe pod infer-7c9b6d6c6f-2kqnx | egrep -i 'node:|nvidia.com/gpu|amd.com/gpu|intel.com/gpu|limits|requests'
Node:           gpu-node-12/10.10.12.34
Limits:
  nvidia.com/gpu:  1
Requests:
  nvidia.com/gpu:  1

Що це означає: Pod заплановано з ресурсом GPU і видно, на якому вузлі він знаходиться.

Рішення: Якщо requests/limits відсутні, ви працюєте на CPU і ваша «повільність GPU» насправді — «немає GPU». Виправте манифест і контролі admission.

Завдання 13: Перевірити тротлінг CPU і steal‑час (GPU‑завдання можуть бути голодними по CPU)

cr0x@server:~$ mpstat -P ALL 1 3
Linux 6.5.0-17-generic (server)  01/21/2026  _x86_64_  (64 CPU)

02:32:01 AM  CPU   %usr  %sys  %iowait  %steal  %idle
02:32:02 AM  all   85.1   8.2     1.3     0.0    5.4
02:32:03 AM  all   88.0   9.1     0.7     0.0    2.2

Що це означає: CPU сильно завантажений; якщо ваш dataloader і мережа працюють на CPU, GPU‑завантаження може падати в очікуванні вводу.

Рішення: Збільште виділення CPU для GPU‑pod, налаштуйте кількість воркерів dataloader або перемістіть передобробку з критичних вузлів.

Завдання 14: Перевірити насичення дискового I/O (вхідний pipeline для тренувань)

cr0x@server:~$ iostat -xz 1 3
Device            r/s     rkB/s   await  %util
nvme0n1         120.0   98000.0   18.2   99.5

Що це означає: NVMe завантажено майже на 100% і високе очікування. Ймовірно GPU чекає даних.

Рішення: Кешуйте датасети локально, використовуйте кращий шардинг, збільшіть read‑ahead або перейдіть на сховище з вищою пропускною здатністю. Не купуйте більше GPU, щоб вирішити дискове вузьке місце.

Завдання 15: Перевірити стан мережі (розподілене тренування all‑reduce, віддалене сховище)

cr0x@server:~$ ip -s link show dev eth0
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP mode DEFAULT group default qlen 1000
    RX: bytes  packets  errors  dropped  missed  mcast
    9834212345  8123456  0       0        0       0
    TX: bytes  packets  errors  dropped  carrier collsns
    11233455667  9234567  0       0        0       0

Що це означає: Помилок і втрат немає (добре). Якщо бачите зростання помилок/втрат, розподілене тренування буде виглядати як «повільність GPU», але насправді це повторні передачі і затори.

Рішення: Виправте прошивку NIC, кабелі, конфігурацію комутатора або перенесіть колективні операції на виділену fabric.

Завдання 16: Перевірити hugepages і тиск пам’яті (фолти сторінок шкодять)

cr0x@server:~$ grep -E 'HugePages_Total|HugePages_Free|MemAvailable' /proc/meminfo
MemAvailable:   182345672 kB
HugePages_Total:    4096
HugePages_Free:     3900

Що це означає: Hugepages в основному вільні і пам’ять доступна; добрий базовий стан. Якщо MemAvailable низьке, пагінг на стороні CPU може блокувати pipeline даних і підвищувати латентність.

Рішення: Запобігайте overcommit пам’яті на GPU‑вузлах; встановлюйте правильні обмеження pod; ізолюйте вузли для GPU‑навантажень.

Три корпоративні міні‑історії (як це провалюється в реальних компаніях)

Міні‑історія 1: Інцидент через хибне припущення

У компанії був блискучий новий кластер для інференсу. Та сама модель, той самий контейнерний образ, ті самі Kubernetes‑манифести. План розгортання був чистий: додавати вузли поступово, дозволити autoscaler робити решту. Дашборд виглядав нормально — поди працювали, GPU «виділені», і сервіс повертав відповіді.

Потім хвостова латентність подвоїлася. Нічого явно не ламалося. Завантаження GPU було низьким, CPU — високим, а логи додатка були заповнені нешкідливими попередженнями, які ніхто ніколи не читав.

Хибне припущення: «Якщо pod запитує GPU, він його використовуватиме». Насправді рантайм моделі всередині контейнера не відповідав драйверному стеку на нових вузлах. Фреймворк виявив невідповідність і тихо відкотився на CPU для кількох ключових операцій. Не всі операції — достатньо, щоб сервіс «працював», але повільніше, щоб SLO плакали.

Виправлення було нудним: вирівняти версію драйвера з очікуваним рантаймом контейнера, додати стартову перевірку, яка фейлить pod, якщо бекенд не активний, і запровадити маркування вузлів, щоб несумісні вузли не могли бути обрані. Постмортем був ще нудніший: «Ми мали протестувати точний образ вузла в канарці». Правильно. І болісно.

Міні‑історія 2: Оптимізація, що зіграла проти

Команда тренувань хотіла скоротити час епохи. У них був новий multi‑GPU бокс з швидким інтерконектом і вони вирішили підняти кількість воркерів dataloader і збільшити prefetching. У маленькому тесті це спрацювало: завантаження GPU зросло і кроки стали швидшими.

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

«Оптимізація» збільшила навантаження на CPU і churn пам’яті, що підвищило температуру шасі і штовхнуло платформу в маргінальну стабільність. GPU були в порядку; сервер — ні. Під сталим навантаженням поєднання термалу і поганої цілісності сигналу PCIe викликало скидання. Кластер виглядав як софтварна проблема, бо завдання перезапускалося і продовжувало працювати — просто повільніше, галасніше і з накопиченням беку.

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

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

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

Під час циклу безпеки оновлення ядра пройшло загальним парком. GPU‑вузли були виключені політикою. Хтось поскаржився — «чому GPU‑вузли особливі?» — і відповідь була як завжди: бо невідповідності ядро/драйвер — це не веселий спосіб проводити вихідні.

Дві тижні потому вендор випустив оновлення драйвера для покращення стабільності під певним шаблоном навантаження. Команда розгорнула його на малому канарному пулі, прогнала повний набір тренувань і інференс‑бенчмарків і дивилася логи на предмет виправлених PCIe‑помилок і тротлінгу. Лише потім розгорнули глобально.

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

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

1) Симптом: низьке завантаження GPU, але завдання повільне

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

Виправлення: Перевірте CPU (mpstat), диск (iostat) і логи активації бекенду. Фейліть швидко, якщо бекенд не активний. Прикріпіть CPU/пам’ять до NUMA‑ноди локальної для GPU.

2) Симптом: багатографічне тренування повільніше, ніж математика масштабування одного GPU

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

Виправлення: Перевірте топологію (PCIe/NVLink‑подібні зв’язки), забезпечте локальність NIC, тонко налаштуйте розміри батчів і накопичення градієнтів, і ізолюйте мережу для колективів.

3) Симптом: чудова продуктивність в бенчмарку, посередня в продакшні

Корінь: Бенчмарк вкладається в кеш/HBM і не моделює реальний I/O, патерни запитів або хвостову латентність. Термальне тротлінг під сталим навантаженням.

Виправлення: Бенчмарк з реальними послідовностями, конкуренцією і тривалістю. Моніторте частоти і енергію під сталим навантаженням. Встановлюйте стабільні power caps за потреби.

4) Симптом: випадкові «пристрій зник» / скидання GPU

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

Виправлення: Карантин вузла. Перевірте journalctl -k на AER/логі скидань GPU. Валідуйте ширину/швидкість PCIe‑лінка. Оновіть прошивку/драйвер у канарці, потім розгорніть.

5) Симптом: сплески латентності інференсу кожні кілька хвилин

Корінь: Фонове компактування, читання датасету, автоскейлер, збірка сміття CPU або зміни частот GPU через енергоменеджмент.

Виправлення: Прогрійте моделі, попередньо виділіть пул пам’яті, закріпіть частоти/потужність де потрібно і усуньте шумних сусідів (ізоляція CPU і I/O).

6) Симптом: портування з CUDA на «портативний» бекенд компілюється, але значно повільніше

Корінь: Відсутні оптимізовані ядра (attention, layernorm, варіанти GEMM), інша поведінка ф’южнінгу або відкат до універсальних реалізацій.

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

7) Симптом: Kubernetes показує GPU виділені, але в контейнері GPU не видно

Корінь: Несумісність device plugin, неправильна конфігурація runtime контейнера, недостатні дозволи або відсутні vendor hooks у контейнері.

Виправлення: Валідуйте мінімальний GPU‑контейнерний тест, перевірте логи device plugin і стандартизуйте конфігурацію runtime між пуллами вузлів.

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

Покроково: вибір постачальника (або змішування постачальників) без жалю

1. Запишіть свій реальний мікс робочих навантажень. Тренування vs інференс, розміри батчів, режими точності, довжини послідовностей, пам’ятний відбиток і шаблони комунікації.
2. Визначте два метрики для кожного навантаження: один продуктивності (пропускна здатність або час навчання) і один бізнес‑метрик (вартість на токен, вартість на епоху, енергія на запит).
3. Виберіть три репрезентативні тести, які ви зможете запускати на кожній платформі: (a) стабільний інференс, (b) тривале тренування, (c) тест відновлення після відмови (drain вузла + reschedule).
4. Побудуйте золотий образ для кожної платформи з зафіксованими версіями ядра/драйвера/рантайму і відтворюваним пайплайном збірки.
5. Валідуйте топологію (швидкість/ширина PCIe, локальність NUMA, розташування NIC) перед запуском будь‑якого бенчмарку. Інакше ви бенчмаркуєте свої помилки.
6. Запускайте тривалі тести (години, не хвилини). Слідкуйте за частотами, температурами, виправленими PCIe‑помилками і скиданнями.
7. Визначте свою позицію щодо портативності явно: «CUDA‑перший але портативна архітектура», або «multi‑backend CI», або «поки один постачальник». Притворятись, що ви зробите всі три — шлях до смерті бюджету.
8. Операціоналізуйте оновлення: канарка, план rollback і автоматизовані health checks, які швидко фейлять при шляхах відкату.
9. Переговорюйте підтримку як SRE: вимага��йте чіткі шляхи ескалації для проблем з драйверами і визначте, які логи/телеметрія потрібні для відкриття кейсу.

Контрольний список: перед тим як звинувачувати вендора GPU

• PCIe‑лінк не знижено (швидкість і ширина відповідають очікуванням).
• NUMA‑вирівнювання правильне для CPU‑потоків і алокацій пам’яті.
• Під навантаженням немає виправлених PCIe‑помилок у логах ядра.
• Пайплайн зберігання не насичений.
• Для розподілених задач помилок/втрат мережі немає.
• Фреймворк використовує очікуваний бекенд і не відкатується тихо.
• Термали і потужність стабільні; немає сталого тротлінгу.

Контрольний список: як зберегти конкуренцію всередині організації

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

FAQ

1) Чи варто нам стандартизуватися на одному постачальнику, щоб зменшити операційну складність?

Стандартизуйте процес, а не постачальника. Один вендор простіший, поки ним усе гаразд — поки ціни, терміни постачання і несподіванки дорожньої карти не створять нову складність. Якщо можете собі дозволити, тримайте невеликий пул другого постачальника, щоб зберегти важіль і «м’язи» портативності.

2) Чи завжди погано прив’язуватися до CUDA?

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

3) Який прихований номер один вбивця продуктивності?

PCIe і проблеми топології. Знижений лінк (Gen5 x16 працює як Gen4 x8) або крос‑сокетний трафік може знищити перевагу дорожчого GPU.

4) Для інференсу що важить більше: обчислення чи пам’ять?

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

5) Чи можна покладатися на «портативні» API і очікувати майже однакову продуктивність?

Очікуйте функціональної портативності, а не паритету продуктивності. Продуктивність приходить із тюнінгованими ядрами, стратегіями ф’южнінгу і зрілими бібліотеками. Портативність варта зусиль; просто закладайте бюджет на бекенд‑специфічне тюнінгування.

6) Як запобігти тихому відкату на CPU?

Додайте явні стартові перевірки у ваш сервіс/завдання, які верифікують, що бекенд активний і що невелика операція з тензорами виконується на пристрої. Якщо ні — аварійно завершити і голосно повідомити. «Працює, але повільно» — найгірший режим відмови.

7) Чи потрібні окремі золоті образи для кожного вендора?

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

8) Який розумний спосіб бенчмаркувати постачальників?

Використовуйте ваші реальні моделі і реальні патерни запитів. Запускайте тривалі тести. Вимірюйте хвостову латентність, стабільність (скидання, виправлені помилки) і операційні терори (інструменти, простота оновлення). Якщо ви вимірюєте лише пікову пропускну здатність протягом п’яти хвилин — ви бенчмаркуєте оптимізм.

9) Чи є power caps хаком чи кращою практикою?

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

10) Який найпростіший спосіб зберегти опційність між вендорами?

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

Наступні кроки, які ви реально можете виконати

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

1. Інструментуйте в першу чергу: додайте метрики GPU‑завантаження, частот, енергії, пам’яті, PCIe‑помилок і сигналів вибору бекенду в моніторинг. Якщо ви цього не бачите, ви не можете торгуватися.
2. Побудуйте лінію портативності: щотижневий CI‑прогін на непервинному вендорі. Не має бути швидким. Має бути реальним.
3. Загартуйте флот: золоті образи, зафіксовані версії, канарні розгортання і автоматизовані health checks, які швидко фейлять при шляхах відкату.
4. Бенчмарк як оператор: тривалі прогони, реальні дані, реальна конкуренція і інжекція відмов (drain вузла, рестарт, reschedule) для вимірювання поведінки відновлення.
5. Закуповуйте як SRE: документація топологій, матриці підтримки, стратегія прошивки і шляхи ескалації підтримки — це не «приємні додатки». Це різниця між доставкою і гасінням пожеж.

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