Дефіцит GPU: як геймери стали жертвами побічних наслідків

Що насправді сталося: дефіцит — це черга

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

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

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

Два числа, що тихо вирішують вашу долю

• Час на розгортання: будівництво нових напівпровідникових потужностей вимірюється роками, а не кварталами.
• Маргінальна цінність за годину GPU: якщо дата-центр може виставляти рахунок за GPU за корпоративними тарифами 24/7, одноразовий роздрібний продаж менш привабливий — особливо при обмеженій пропозиції.

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

Швидкі факти та історичний контекст (список «о, тепер зрозуміло»)

Ось конкретні пункти, які роблять останні кілька років хаосу з GPU менш загадковими — і більш прогнозованими.

1. Сучасні GPU залежать від просунутого пакування (наприклад, підходи типу CoWoS для високопродуктивних обчислень), і потужність пакування може стати вузьким місцем, навіть якщо є ємність по вафлях.
2. Постачання GDDR-пам’яті має значення: відеокарта — це не «GPU плюс вентилятор». Якщо виділення VRAM обмежені, плати не відвантажуються.
3. Час постачання довгий за своєю суттю: виробництво напівпровідників планується заздалегідь; «зробіть більше в останню хвилину» не працює.
4. Консолі конкурують за ті самі ланцюги поставок: коли зростає випуск нових поколінь консолей, вони забирають субстрат, пам’ять і логістику, які також потрібні для споживчих GPU.
5. Попит від майнінгу криптовалют зростав циклічно і є особливо еластичним: майнери купують, поки прибутковість не впаде, а потім скидають використані карти на ринок.
6. Дата-центри нормалізували апаратне прискорення: GPU стали стандартом для тренування ML і дедалі частіше для інференсу, зміщуючи «найкращий кремній» у бік корпоративного застосування.
7. Зміни поколінь PCIe не були головним вузьким місцем, але вони збільшили апаратні витрати й оновлення материнських плат — підвищивши загальні витрати на збірку.
8. Логістика епохи COVID не лише сповільнила доставку; вона спотворила прогнози. Коли всі замовляють у паніці, прогнозування стає астрологією зі складними таблицями.
9. Якість ринку вживаних карт погіршилась після періодів інтенсивного майнінгу: більше карт з деградованими вентиляторами, проблемами з терміками VRAM та періодичними збоями.

Зсув попиту: геймери проти трьох індустрій із більшими бюджетами

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

1) Хмара та корпоративний сектор: GPU як двигун доходу

Хмарні провайдери не купують GPU через любов до трасування променів. Вони купують їх, бо GPU перетворює електроенергію на рахунки. Обладнання стоїть у стояках, амортизується роками, використовується майже 24/7 і тарифи виставляються погодинно. Рівень використання змінює все.

Споживчі GPU часто простоюють. Навіть віддані геймери сплять, працюють або виходять на вулицю. GPU в дата-центрі не спить; він просто змінює орендарів.

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

2) ШІ: крива попиту, якій байдуже до ваших вихідних

Навантаження ШІ — ідеальний шторм для попиту на GPU: підходить для паралельних обчислень, вимогливе до продуктивності й дедалі необхідніше для продуктів, що конкурують. Компанії, які раніше використовували CPU-ферми, почали відокремлювати GPU-кластери. Потім вони зрозуміли, що інференс теж хоче GPU. Потім вони зрозуміли, що інференс хоче їх постійно.

А оскільки ШІ нині — питання ради директорів у багатьох компаніях, бюджет на GPU йде з «стратегічних інвестицій», а не з «ИТ-бюджету». Це означає менше обмежень при закупівлях і більше готовності підписувати довгі зобов’язання.

3) Крипта і спекуляція: попит, що надходить як DDoS

Бум майнінгу поводився як DDoS-атака на роздрібні запаси. Він був нечутливий до ціни, поки прибутковість не впала. Результат — не просто «більше покупців», а клас покупців, оптимізованих під закупівлю обсягів, часто з автоматизацією і готовністю платити понад MSRP.

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

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

Сторона пропозиції: фабрики, пакування, пам’ять і нудні обмеження

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

Ємність по вафлях і ноди процесу

Просунуті GPU часто використовують передові техпроцеси, де ємність обмежена і ділиться зі смартфонними SoC, серверними CPU та іншим високомаржинальним кремнієм. Коли кілька індустрій хочуть одного й того самого нода, хтось отримує раціонування. Вгадайте, хто не має багаторічного контракту take-or-pay?

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

Вихід придатних кристалів: частина, яку ніхто не хоче пояснювати на касі

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

Пакування та підложки: тихий вузький концентратор

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

Пам’ять і компонентні плати

VRAM — це окремий ланцюг постачання. Виробництво GDDR конкурує з іншими ринками пам’яті, а партнери з плат залежать від стабільного постачання компонентів VRM, конденсаторів і роз’ємів. Нестача навіть невеликого компонента може зупинити весь готовий продукт, бо неможливо відвантажити «майже завершений GPU».

Логістика і розподіл по рітейлу

І нарешті, доставка й роздріб мають значення. Коли запаси тонкі, рішення про розподіл підсилюють сприйняття: якщо регіон отримує невелику партію, вона миттєво розкупляється і виглядає як «ніде немає». Насправді запаси є, просто не там, де ви дивитесь, не тоді, коли ви дивитесь, і не в тій формі, яку ви хочете (вітаємо, примусові набори товарів).

Динаміка ринку: боти, набори товарів і чому «MSRP» стало перформансом

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

Боти та шторм повторних запитів

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

Набори товарів і «завантаження каналу»

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

Перекупники: симптом, а не корінь

Перекупники не створили дефіцит; вони його експлуатували. В термінах SRE вони — не інцидент. Вони — голосний сусід, який показує, що у вашій системі немає квот.

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

Погляд операційників: GPU — розділений ресурс, і розділені ресурси зловживають

У виробничих системах дефіцит перетворюється на політику. Дефіцит GPU перетворився на економіку. Та сама механіка.

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

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

Вернер фон Ґогельс (CTO AWS) має відому операційну мантру — парафразована ідея: «Все ламається, постійно». В світі GPU «все» включає ланцюги постачання і замовлення на закупівлю.

Дефіцит GPU змінює моделі відмов

• Ризик ємності зміщується вліво: ви виявляєте нестачі під час планування, а не під час розгортання — якщо ви дисципліновані. Якщо ні — виявляєте їх під час простою і вдаєте, що це було непередбачувано.
• Продуктивність стає бюджетом: ви перестаєте питати «це швидко?» і починаєте питати «це швидко за ват/за долар/за одиницю доступності?»
• Багатоорендність ускладнюється: спільне використання GPU (MIG, vGPU, контейнери) стає звичним, і ефекти «гучного сусіда» посилюються.

Для геймерів операційний урок простий: ви не конкуруєте з іншими геймерами. Ви конкуруєте з використанням. GPU, що рендерить вашу гру 2–4 години на день, ринково менш «цінний», ніж GPU, який здають в оренду 24/7 для тренування моделей, інференсу або обчислювальних симуляцій.

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

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

Середня SaaS-компанія вирішила додати апаратне прискорення відео в свій продукт. Команда зробила все правильно на папері: побудували прототип, нагрузили його і підтвердили, що один GPU-інстанс може обробити очікувану пропускну здатність. Всі були задоволені. Дата запуску зафіксована.

Хибне припущення було тихе: вони вважали, що GPU в закупівельних термінах «як CPU». Вони очікували масштабування шляхом запуску нових інстансів у момент потреби. Інфраструктурний код підтримував це. Архітектура підтримувала це. Рунбуки підтримували це. Постачальник — ні.

Тиждень запуску настав, і попит перевищив прогнози. Автоскейл намагався додати вузли з GPU. У хмарного акаунту був ліміт. Запит на підвищення ліміту потрапив у чергу. Тим часом завантаження клієнтів накопичувалося, затримки зростали, і повторні спроби посилювали беклог. Сервіс не відмовив одразу; він деградував повільно, а це найдорогоцінніший тип відмови, бо ви продовжуєте надавати поганий досвід замість того, щоб скидати навантаження.

Огляд інциденту був неприємним, бо ніхто нічого «не зламав». Система поводилася саме так, як задумано. Дизайн просто ігнорував, що ємність GPU не нескінченна й не миттєво забезпечується. Їхні заходи включали додавання резервного CPU-шляху (гірша якість, повільніше), запровадження контролю входу для завантажень і попереднє резервування ємності GPU — хоч це й вдарило по бюджету.

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

Міні-історія №2: оптимізація, що дала зворотний ефект

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

Першого дня графіки використання виглядали фантастично. GPU сиділи близько 90–95%. Команда святкувала. Наступного тижня час тренувань погіршився. Не трохи — дуже непередбачувано. Деякі задачі завершувалися швидко; інші повзли й таймаутувалися. Інженери звинувачували мережу, потім сховище, потім код моделі.

Справжня проблема була в конкуренції за пам’ять і накладних витратах на контекстні переключення. Перенавантаживши паралельність, вони спричинили часті витіснення VRAM, додаткові запуски ядер і збільшені передачі по PCIe. Їхнє «високе використання» частково було накладними витратами. Кластер був зайнятий, а не продуктивний. В термінах SRE: вони оптимізували метрику, а не досвід користувача.

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

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

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

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

Коли критичний пайплайн збірки почав падати через партію ненадійних GPU (вентилятори рано виходили з ладу під безперервним навантаженням), студія одразу ж замінила їх з буфера, ізолювала погану партію і відправила реліз вчасно. Ніяких героїчних ночей у war room. Просто нудний план, виконаний як щось важливе.

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

План швидкої діагностики: що перевірити першим, другим, третім

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

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

• Чи присутній очікуваний GPU і чи встановлений очікуваний драйвер?
• Чи високе використання, коли має бути, або GPU просто простоює, поки задача чекає на щось інше?
• Чи карта обмежена по потужності або термічно дроселює?

Друге: визначте домінантну категорію вузького місця

• Обчислювально-залежне: високе завантаження GPU, стійкі частоти, VRAM близький до очікуваного, низький час очікування CPU.
• Залежне від пам’яті: VRAM на межі, велике навантаження контролера пам’яті, часті алокації, page faults/OOM kills.
• Обмежене пайплайном даних: видимі пилкоподібні коливання використання GPU; високий CPU iowait; повільні зчитування зі сховища; насичена мережа.
• Обмежене планувальником: домінує час у черзі; GPU простоюють, бо задачі не можуть розміститися через політику, фрагментацію або нестачу VRAM для підходу.

Третє: вирішіть масштабувати вгору, масштабувати горизонтально або виправляти пайплайн

• Масштабувати вгору, якщо ви обчислювально-залежні і не можете ефективно паралелити.
• Масштабувати горизонтально, якщо робоче навантаження добре шардиться і мережа/сховище витримають.
• Виправляти, якщо низьке використання через голодування вводу, погане батчування, надмірні передачі або неправильні драйвери.

Короткий жарт №2: Якщо ваш GPU працює на 2% використання, вітаю — ви побудували надзвичайно дорогий обігрівач з PCIe.

Практичні завдання (з командами): перевірити, діагностувати та вирішити

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

Завдання 1: Підтвердити, що ядро бачить GPU

cr0x@server:~$ lspci -nn | egrep -i 'vga|3d|nvidia|amd'
01:00.0 VGA compatible controller [0300]: NVIDIA Corporation Device [10de:2684] (rev a1)

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

Рішення: Якщо відсутній — зупиніться. Перевірте фізичні конектори живлення, налаштування BIOS (Above 4G decoding) і конфігурацію слотів материнської плати перед тим, як звинувачувати драйвери.

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

cr0x@server:~$ nvidia-smi
Wed Jan 22 11:02:13 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 RTX A5000               Off | 00000000:01:00.0 Off |                  N/A |
| 30%   49C    P2              112W / 230W |   8120MiB / 24576MiB |     76%      Default |
+-----------------------------------------+----------------------+----------------------+

Що це означає: Драйвер завантажений, GPU активний, видно використання і пам’ять. P2 вказує на стан продуктивності; не завжди макс. частоти.

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

Завдання 3: Спостерігати використання з часом, щоб виявити шаблони голодування

cr0x@server:~$ nvidia-smi dmon -s pucm
# gpu   pwr  u  c  m
# Idx     W  %  %  %
    0   115 78 68 33
    0   112 12 10 31
    0   118 81 70 35

Що це означає: Пилкоподібні коливання (78% потім 12% потім 81%) часто вказують на затримки завантаження даних або точки синхронізації.

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

Завдання 4: Перевірити частоти GPU і причини дроселювання

cr0x@server:~$ nvidia-smi -q -d CLOCK,POWER,THERMAL | sed -n '1,120p'
==============NVSMI LOG==============
Clocks
    Graphics                    : 1815 MHz
    SM                          : 1815 MHz
    Memory                      : 7001 MHz
Power Readings
    Power Draw                  : 118.34 W
    Power Limit                 : 230.00 W
Temperature
    GPU Current Temp            : 50 C
    GPU Shutdown Temp           : 95 C
    GPU Slowdown Temp           : 83 C

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

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

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

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

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

Рішення: Якщо несподівано (повинно бути x16) — перевірте розподіл ліній на материнській платі, налаштування BIOS, райзери та вибір слоту. Виправте це перед купівлею нового обладнання.

Завдання 6: Перевірити завантаження системи і вузькі місця CPU (GPU простоює, бо CPU не може підживити)

cr0x@server:~$ mpstat -P ALL 1 3
Linux 6.5.0 (server) 	01/22/2026 	_x86_64_	(32 CPU)

11:03:01 AM  CPU   %usr %nice %sys %iowait %irq %soft %steal %idle
11:03:02 AM  all  72.10  0.00  8.20    9.80 0.00  0.60   0.00  9.30
11:03:03 AM  all  70.85  0.00  7.95   10.10 0.00  0.55   0.00 10.55

Що це означає: Високий iowait (~10%) вказує на затримки зі сховищем. CPU також зайнятий. GPU може чекати дані.

Рішення: Якщо iowait високий — переходьте до метрик диска і поведінки кешів/наборів даних. Ще не чіпайте налаштування GPU.

Завдання 7: Виявити затримки сховища, що спричиняють затримки конвеєра

cr0x@server:~$ iostat -xz 1 3
avg-cpu:  %user   %nice %system %iowait  %steal   %idle
          68.50    0.00    8.00   10.20    0.00   13.30

Device            r/s     rkB/s   rrqm/s  %rrqm r_await rareq-sz     w/s     wkB/s   w_await aqu-sz  %util
nvme0n1         220.0  35200.0     0.0   0.00    1.20   160.0    40.0   9600.0    2.10   0.55  35.0
sda             180.0   7200.0     2.0   1.10   22.50    40.0    30.0   2400.0   18.90   6.10  98.0

Що це означає: sda завантажений приблизно на 98% з очікуваннями ~20ms. Це класичне «GPU голодує через повільний диск».

Рішення: Перемістіть набори даних на NVMe, додайте кешування або передзавантаження/буферизацію в ОЗП. Більше GPU не допоможе, якщо sda — пляшка в горлі.

Завдання 8: Перевірити тиск пам’яті і свопінг (тихий вбивця продуктивності)

cr0x@server:~$ free -h
               total        used        free      shared  buff/cache   available
Mem:           125Gi        98Gi       3.2Gi       2.1Gi        24Gi        18Gi
Swap:           16Gi       6.8Gi       9.2Gi

Що це означає: Використання свопу немале. Якщо ваш даталоадер починає свопитись, GPU чемно простоює, поки ОС агресивно треше пам’ять.

Рішення: Зменшіть розмір батча, виправте витоки пам’яті, додайте ОЗП або переналаштуйте кешування. Свопінг у пайплайні GPU — це самостійно спричинений простій.

Завдання 9: Спостерігати за пам’яттю і використанням по процесах

cr0x@server:~$ nvidia-smi pmon -c 1
# gpu        pid  type    sm   mem   enc   dec   jpg   ofa   command
    0      24711     C     72    31     0     0     0     0   python
    0      25102     C      4     2     0     0     0     0   python

Що це означає: Одна задача використовує GPU; інша майже нічого не робить, але все одно тримає ресурси.

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

Завдання 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 — узгодьте базові образи контейнерів/тулкіт і драйвер. Фіксуйте версії; не використовуйте «вільний політ».

Завдання 11: Перевірити повідомлення про помилки GPU у логах ядра

cr0x@server:~$ sudo dmesg -T | egrep -i 'nvrm|xid|amdgpu|gpu fault' | tail -n 20
[Wed Jan 22 10:41:10 2026] NVRM: Xid (PCI:0000:01:00): 31, pid=24711, name=python, Ch 0000002b, intr 00000000

Що це означає: Xid-помилки можуть вказувати на баги драйвера, нестабільні частоти, перегрів або апаратні несправності.

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

Завдання 12: Перевірити подачу живлення (недостатня напруга = дивні збої)

cr0x@server:~$ sudo sensors | egrep -i 'in12|in5|in3|vcore|temp' | head
Vcore:        +1.08 V
in12:        +11.76 V
in5:          +5.04 V
temp1:        +42.0°C

Що це означає: Шини у межах норми. Провал 12V під навантаженням GPU може спричиняти «випадкові» перезавантаження.

Рішення: Якщо шини виходять за специфікації під навантаженням — замініть PSU або перерозподіліть кабелі живлення (окремі PCIe-кабелі, не дезі-чейн).

Завдання 13: Перевірити обмеження cgroup/контейнера (GPU присутній, але задача повільна)

cr0x@server:~$ cat /sys/fs/cgroup/cpu.max
200000 100000

Що це означає: CPU обмежений (еквівалент 2 ядер). Ваша GPU-задача може бути задушена CPU-лімітами для попередньої обробки.

Рішення: Підвищте CPU-ліміти для GPU-подів/контейнерів або винесіть попередню обробку. GPU-прискорення не виправдовує голодування хоста.

Завдання 14: Заміряти пропускну здатність мережі для віддалених наборів даних

cr0x@server:~$ ip -s link show dev eth0 | sed -n '1,20p'
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP mode DEFAULT group default qlen 1000
    RX:  bytes  packets  errors  dropped  overrun  mcast
    9876543210  8765432  0       12       0       0
    TX:  bytes  packets  errors  dropped  carrier  collsns
    1234567890  2345678  0       3        0        0

Що це означає: Є дропи. Якщо RX-drops зростають під час тренувань/стримінгу, ви можете втрачати пропускну здатність і блокувати вхідні дані.

Рішення: Дослідіть налаштування буферів NIC, затори на комутаторі, невідповідність MTU або перемістіть дані локально. GPU-пайплайни не люблять джіттер.

Завдання 15: Визначити «час у черзі» vs «час виконання» у контексті планувальника (приклад Slurm)

cr0x@server:~$ squeue -u $USER -o "%.18i %.9P %.8j %.8T %.10M %.10l %.6D %R"
12345678 gpu        trainA   RUNNING   00:21:10  02:00:00      1 node17
12345679 gpu        trainB   PENDING   00:00:00  02:00:00      1 (Resources)

Що це означає: Очікує через ресурси, а не через помилку задачі. Вузьке місце — алокація, а не код.

Рішення: Якщо час у черзі домінує — розгляньте зменшення запитів GPU на задачу, політики пакування, MIG/vGPU або планування на непікові періоди.

Завдання 16: Швидка оцінка вживаної GPU на предмет попереднього зносу (перевірка вентиляторів і терміки)

cr0x@server:~$ nvidia-smi --query-gpu=fan.speed,temperature.gpu,power.draw,power.limit --format=csv
fan.speed, temperature.gpu, power.draw, power.limit
30 %, 51, 119.02 W, 230.00 W

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

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

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

1) «Використання GPU низьке, отже нам потрібно більше GPU»

Симптоми: 5–20% використання GPU, великий час виконання, пилкоподібний nvidia-smi dmon.

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

Виправлення: Перемістіть набори даних на NVMe/локальний SSD, збільшіть число воркерів даталоадера, закріпіть пам’ять, батчуйте агресивніше, профілюйте час CPU vs GPU.

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

Симптоми: Той самий код, повільніший пропуск; час від часу Xid-помилки; дивна нестабільність.

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

Виправлення: Фіксуйте версії драйверів. Перевіряйте оновлення на canary-вузлах. Узгоджуйте контейнери з підтримуваним CUDA runtime драйвера.

3) «У нас закінчилась VRAM, то купимо більшу карту»

Симптоми: OOM-помилки, сторінкова передача, великі зупинки, крахи під час піку використання.

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

Виправлення: Використовуйте змішану точність, gradient checkpointing (ML), зменшуйте батчі, повторно використовуйте буфери, обмежуйте кеші, перезапускайте довгоживучі процеси.

4) «GPU встановлено, але додаток працює на CPU»

Симптоми: CPU завантажений; GPU простоює; у логах додатка видно CPU-бекенд.

Корінь проблеми: Відсутні runtime-бібліотеки, контейнер не налаштований для доступу до GPU, неправильні прапори збірки.

Виправлення: Перевірте за допомогою nvidia-smi всередині контейнера, забезпечте NVIDIA Container Toolkit, перевірте LD_LIBRARY_PATH і вибір пристрою у фреймворку.

5) «Вживана GPU була вигідною угодою, а потім почала падати»

Симптоми: Краї під навантаженням, шум вентиляторів, високі температури, періодичні артефакти.

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

Виправлення: Протестуйте під навантаженням перед довірям; замініть вентилятори/пасту/термопрокладки; понижуйте напругу або обмежуйте потужність; якщо сумніваєтесь — не ставте в критичну систему.

6) «Наш кластер GPU ‘зайнятий’, але завершення робіт повільніше»

Симптоми: Високе використання, велика черга, гірша пропускна здатність.

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

Виправлення: Впровадьте квоти VRAM на задачу, налаштуйте паралельність, використовуйте MIG/vGPU доречно, вимірюйте швидкість завершення задач, а не лише використання.

7) «Ми купили GPU, але не встигаємо їх змонтувати»

Симптоми: Обладнання в коробках, не розгорнуте; проекти затримуються.

Корінь проблеми: Обмеження по живленню/охолодженню, місце в стійках, PDU, кабелі, процес прошивки, готовність образів драйверів.

Виправлення: Плануйте живлення й охолодження заздалегідь; стандартизуйте образи; підготуйте прошивку; майте процес burn-in; ставте розгортання як виробничий сервіс.

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

Для геймерів: купуйте розумніше, не зліше

1. Визначте свій фактичний вузький пункт: чи обмежені ви GPU, CPU, VRAM або роздільною здатністю/частотою монітора? Не оновлюйте без діагностики.
2. Реалістично орієнтуйтеся на VRAM: сучасні ігри та текстурні пакети штрафують за малу VRAM більше, ніж за трохи слабші ядра.
3. Віддавайте перевагу перевіреним каналам: уникайте сірих ринків, якщо вам не до вподоби судові суперечки та повернення.
4. Негайно тестуйте під навантаженням: програвайте реальне навантаження, перевіряйте температури, частоти та стабільність, поки повернення ще прості.
5. Бюджетуйте всю систему: якісний PSU, повітряний потік і конструкція корпуса можуть перетворити преміальну карту на дроселюючу машину.
6. Будьте гнучкими щодо покоління: старе покоління за розумну ціну може перевершити сучасне за космічну ціну, особливо якщо ви обмежені CPU.

Для команд: ставте ємність GPU як виробничу ємність

1. Прогнозуйте попит щомісяця: відстежуйте GPU-години, а не лише «кількість GPU».
2. Розділяйте інтерактивні та пакетні задачі: не дозволяйте ad-hoc задачам пожирати планову роботу.
3. Резервуйте базову ємність: зобов’яжіться мінімумом, який точно використовуєте; стрибайте вгору стратегічно.
4. Вимірюйте наскрізну пропускну здатність: продуктивність конвеєру, а не лише використання GPU.
5. Побудуйте запасний шлях: гірша якість або повільніший CPU-шлях кращі за повний простій, коли GPU недоступні.
6. Стандартизуйте образи і драйвери: фіксація версій зменшує «працює на вузлі A» проблеми.
7. Плануйте живлення й охолодження: GPU з охотою перетворюють ватти на тепло. Інфраструктура має встигати.
8. Тримайте невеликий буфер: кілька запасних карт/вузлів можуть перетворити затримку постачання на непомітну подію.

Реалістична перевірка закупівель (те, чого інженери уникають)

1. Знайте свої часи постачання і замовляйте до того, як «потрібно» буде обладнання.
2. Підтверджуйте алокації письмово: «очікуємо відвантаження» — не план.
3. Кваліфікуйте альтернативи: декілька SKU, декілька постачальників, декілька партнерів з платами.
4. Бюджетуйте запасні частини та відмови: DOA трапляється. Ранні відмови трапляються. Не робіть із цього кризу.

FAQ

1) Чому виробники GPU просто не збільшили виробництво?

Тому що виробництво обмежене потужностями фабрик, виходом придатних кристалів, пакуванням, постачанням VRAM і довгими горизон�ами планування. Ви не можете «автоскейлити» фабрики.

2) Чи були перекупники основною причиною відсутності GPU?

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

3) Чи справді майнінг так сильно вплинув?

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

4) Чи є попит ШІ новим «постійним» драйвером дефіциту?

Попит ШІ більш структурно стійкий, ніж майнінг, бо пов’язаний з дорожніми картами продуктів і постійними інференс-навантаженнями. Він також концентрує покупну силу в руках менших і більших покупців.

5) Чи повинні геймери купувати вживані GPU під час або після дефіциту?

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

6) Чому я бачу GPU «в наявності» тільки в наборах товарів?

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

7) Як система може мати високе завантаження GPU, але все одно бути повільною?

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

8) Який найшвидший спосіб визначити, чи я обмежений GPU або даними?

Спостерігайте використання GPU у часі (nvidia-smi dmon) і корелюйте з iowait CPU (mpstat) і затримками диска (iostat). Пилкоподібне використання GPU плюс високий iowait зазвичай означає обмеження даними.

9) Чи завжди карти з більшою VRAM кращі для ігор?

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

10) Що повинна робити організація, якщо квоти хмарних GPU блокують масштабування?

Попередньо узгодьте квоти і резервовану ємність, підтримуйте запасні режими і проектуйте планувальники для граціозної деградації. Квота — це залежність від ємності; ставтеся до неї як до такої.

Висновок: реалістичні наступні кроки

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

Зробіть це далі:

1. Діагностуйте перед витратами: підтвердіть, чи ви обмежені GPU, VRAM, CPU або пайплайном. Команди вище допоможуть швидко дійти до істини.
2. Плануйте під обмеження: якщо ви команда — ставте ємність GPU як виробничу ємність — прогнозуйте, резервуйте і тримайте буфер.
3. Купуйте за стабільність: уникайте сумнівних блоків живлення, поганого повітряного потоку і підозрілих вживаних карт, якщо вам важливий аптайм (а він важливий, навіть якщо ви називаєте це «стабільністю кадрів»).
4. Припиніть культ використання: чи ви геймер, чи керуєте кластером — оптимізуйте досвід користувача: плавні кадри або передбачуване завершення задач, а не одну гарну метрику.

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