Ера майнінгу: як криптовалюти зламали ціни на GPU (знову й знову)

Що насправді змінилося: від геймерського заліза до товарної інфраструктури

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

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

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

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

Факти й контекст, які пояснюють цикли

• Bitcoin рано відійшов від GPU-майнінгу. SHA-256 майнінг для Bitcoin перейшов від CPU до GPU до FPGA/ASIC за кілька років, спрямувавши GPU-майнерів на альткоїни.
• Ера Scrypt (Litecoin) була великою ранньою хвилею тиску на GPU. До появи Scrypt ASIC, GPU були основною платформою для Scrypt-майнінгу і викликали дефіцити в роздрібі.
• Ethereum з Ethash довго тримав GPU в ролі релевантного ресурсу. «Memory hardness» Ethash робив GPU економічно вигідними роками, утримуючи попит довго.
• Попит майнерів синхронізований глобально. Зміни прибутковості поширюються миттєво—одні й ті самі панелі, одні й ті самі пули, одні й ті самі калькулятори—тому сплески попиту не локальні.
• Переход до Proof-of-Stake змінив профіль попиту. Перехід Ethereum на PoS зменшив один із найбільших джерел постійного GPU-майнінгу, але ринок і далі зберігає відповідні рефлекси.
• Логістика COVID збільшила амплітуду цінових коливань. Затримки в доставці та обмежені компоненти (не лише GPU) перетворили нормальні дефіцити на довготривалі перебої інфраструктури.
• Ціни на електроенергію та регулювання мають значення. Прибутковість майнінгу тісно залежить від вартості електроенергії; зміни політик чи тарифів можуть перемістити попит між країнами, впливаючи на регіональний доступ.
• Партнери з платами (AIB) тихо випускали «майнінг-версії». З’явилися безвентиляторні карти й спеціалізовані SKU під час піків—часто з іншими гарантіями та характеристиками перепродажу.

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

Як майнінг механічно ламає ціни на GPU

1) Він перетворює роздрібний інвентар на тонкий шар поверх оптового ринку

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

2) Він створює ставку, що ігнорує ваш випадок використання

Рендеринг потребує VRAM, стабільності драйвера та відсутності помилок пам’яті. Геймеру важливий фреймрейт. Майнеру — ефективність на ват і стабільність протягом місяців.
Коли попит домінують майнери, ціноутворення плаває до функції вартості майнінгу — а не до вашої.

3) Він тягне за собою весь стек у зону ураження: БП, райзери, материнські плати, вентилятори

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

4) Він спотворює ринок вживаних і робить «ремонт» мистецтвом

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

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

5) Він карає «just-in-time» закупівлі

Якщо ви купуєте GPU тільки коли «потрібні», ваш бюджет тепер пов’язаний із прибутковістю крипти та глобальною логістикою.
Це не гнучкість. Це гра на удачу з PowerPoint-презентацією.

Парафразоване ідея, часто приписувана Werner Vogels (CTO Amazon): Усе ламається, весь час; проєктуйте так, ніби відмова — норма. (парафраз)
Ставтеся до доступності й надійності GPU так само.

OEM, AIB, дистриб’ютори: тихі підсилювачі

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

Повадки AIB: сортинг, охолодження та реальність гарантій

Партнери з платами випускають кілька варіантів «одного й того ж GPU», відрізняючи їх якістю кулера, міцністю VRM, кривими вентиляторів і заводськими розгону.
Попит майнерів поглинає все, але особливо цінує карти з гарною ефективністю та стабільною пам’яттю.
Саме такі карти ви хочете для вузлів інференсу ML, що мають працювати тихо й холодно.

Умови гарантії можуть бути пасткою. Деякі SKU мають обмежене гарантійне покриття при продажі через певні канали або регіони.
Якщо ви купуєте сіро на ринку, щоб обійти дефіцит, ви можете виграти покупку й програти RMA.
Рахунок-фактура — не актив. Гарантія — частина активу.

Повадки дистриб’юторів: алокація та бандлування

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

Повадки хмар: ємність стає преміальним сервісом

Доступність GPU в хмарі — функція закупівлі провайдера плюс внутрішня пріоритизація.
Коли попит зростає, інстанси з GPU або зникають, або блокуються квотами.
У такому середовищі ваш інфраструктурний план має мати альтернативи: менші GPU, резервні шляхи на CPU або стратегії преремптивних потужностей.

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

Ринок вживаних GPU після майнінгу: що виходить з ладу, які брехні та що виживає

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

Реальні режими відмов

• Зношення вентиляторів і підшипників. Майнінгові ферми працюють вентиляторами постійно. Навіть якщо кристал GPU в порядку, вентилятори можуть бути на межі виходу з ладу.
• Деградація термопрокладок. Гарячі чіпи пам’яті й VRM залежать від прокладок, які стискаються, висихають і втрачають ефективність.
• Помилки пам’яті під тривалим навантаженням. Майнінг інтенсивно навантажує пам’ять; маргінальна VRAM може пройти легкі тести і впасти під годинами навантаження.
• Напруга PCIe та окиснення конекторів. Багаторазові вставляння, райзери й запилені середовища можуть погіршити цілісність сигналу.
• Модифікації BIOS. Деякі майнери прошивають BIOS для іншої поведінки енергоспоживання чи таймінгів пам’яті. Це може створити нестабільність для ваших навантажень.
• Втома ланцюга живлення. VRM, що працювали довго гарячими, можуть зноситися, особливо на дешевших платах.

Що виживає краще, ніж думають

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

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

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

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

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

Припущення було простим: однаковий модельний номер GPU означає однакову поведінку. На практиці половина флоту мала інші варіанти плат і дизайн VRM.
Під тривалим навантаженням один варіант працював приблизно на 10–15°C гарячіше по температурі переходу пам’яті.
Він не падав відразу. Він деградував продуктивність через термальне троттлінг та періодичні помилки CUDA, які виглядали як баги в ПЗ.

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

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

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

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

Потім почали зростати помилки. Не жорсткі збої—м’які. Поодинокі ECC-події на деяких картах, спорадичні таймаути NCCL, тренувальні задачі, що «зависали».
Команда звинувачувала мережу. Потім бекенд сховища. Потім планувальник. Класичне перекладання вини в розподілених системах.

Причиною було теплове поводження VRAM і VRM. «Оптимізація» зняла резерви.
За певних умов оточення частина вузлів увійшла в режим, коли GPU не падав зовсім; вони працювали некоректно.
Планувальник підсилював проблему, постійно розміщуючи великі роботи на тих самих «швидких» вузлах.

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

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

Фінансова компанія мала невелику, але важливу GPU-інфраструктуру для ризик-аналітики та внутрішнього ML.
Вони ніколи не намагалися «вгадати» ринок. Замість цього вони вели план поступової заміни, тримали невеликий буфер запасних карт і наполягали на прогріванні перед тим, як GPU йшов у продакшен.

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

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

Результат не був «нуль проблем». Це було швидке локалізування. У продакшен-системах саме це купують за рахунок нудної правильності: менший радіус ураження.

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

Спочатку: чи GPU справді є вузьким місцем?

• Перевірте завантаження GPU, частоти й споживання потужності під навантаженням.
• Перевірте насичення CPU, чергу запуску процесів і навантаження на IRQ (особливо при високошвидкісному мережевому трафіку).
• Перевірте пропускну здатність диска/мережі, якщо ви підгодовуєте моделі чи датасети.

Далі: чи є троттлінг (енергія, тепло або драйвер)?

• Шукайте причини тротлінгу «Pwr» або «Thrm».
• Підтвердіть режим persistence, application clocks і ліміти потужності.
• Підтвердіть температури: ядра GPU, температура переходу пам’яті (memory junction), та hotspot.

Потім: чи платформа вам бреше (PCIe, прошивка, райзери, помилки)?

• Перевірте швидкість/ширину лінку PCIe. GPU, що застряг на x4 Gen3, може виглядати як «повільний CUDA».
• Проскануйте журнали ядра на предмет AER/PCIe скоригованих помилок та Xid помилок.
• Перевірте, чи версії драйверів/бібліотек відповідають вашому CUDA-стеку та середовищу контейнерів.

Четверте: чи завантаження правильно сформоване?

• Розміри batch-ів і налаштування data loader-ів можуть обмежувати CPU або сховище, а не GPU.
• Налаштування змішаної точності може перевести вас від compute-bound до memory-bound (або навпаки).
• NUMA-розміщення може тихо зменшувати пропускну здатність.

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

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

Завдання 1: Ідентифікувати точні GPU і варіанти плат

cr0x@server:~$ nvidia-smi -L
GPU 0: NVIDIA GeForce RTX 3090 (UUID: GPU-2a1b...)
GPU 1: NVIDIA GeForce RTX 3090 (UUID: GPU-9c7d...)

Значення: У вас є назви моделей, але не партнер плати/ревізія.

Рішення: Якщо відбувається дебаг «однакових» GPU з різною поведінкою, потрібні глибші PCI ID і версії VBIOS (наступне завдання).

Завдання 2: Захопити версію VBIOS і ідентифікатор плати

cr0x@server:~$ nvidia-smi -q | egrep -i "Product Name|VBIOS Version|Board Part Number" -n
12:    Product Name                    : NVIDIA GeForce RTX 3090
48:    VBIOS Version                   : 94.02.42.40.3A
52:    Board Part Number               : 900-1G136-2540-000

Значення: VBIOS і board part number скажуть, чи ви змішуєте варіанти.

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

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

cr0x@server:~$ nvidia-smi -q | egrep -i "PCIe Generation|Link Width" -n
140:    PCIe Generation
141:        Current                     : 3
142:        Max                         : 4
146:    Link Width
147:        Current                     : x8
148:        Max                         : x16

Значення: GPU працює на Gen3 x8, хоча може Gen4 x16.

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

Завдання 4: Виявити причини тротлінгу (енергія/тепло)

cr0x@server:~$ nvidia-smi -q -d PERFORMANCE | egrep -i "Clocks Throttle Reasons|Thermal|Power" -n
25:    Clocks Throttle Reasons
26:        Idle                         : Not Active
27:        Applications Clocks Setting   : Not Active
28:        SW Power Cap                  : Active
29:        HW Slowdown                   : Not Active
30:        HW Thermal Slowdown           : Not Active

Значення: Ви обмежені за потужністю (software).

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

Завдання 5: Слідкувати в реальному часі за завантаженням, потужністю і температурами під навантаженням

cr0x@server:~$ nvidia-smi dmon -s pucvmt
# gpu   pwr gtemp mtemp sm   mem   enc   dec   mclk  pclk
# Idx     W     C     C   %     %     %     %   MHz   MHz
  0     345    78    96  92    84     0     0  9751  1725

Значення: Висока температура пам’яті (mtemp) близько до межі; тривалі навантаження можуть спричинити троттлінг VRAM або помилки.

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

Завдання 6: Перевірити журнали ядра на NVIDIA Xid помилки (апаратна/драйверна нестабільність)

cr0x@server:~$ sudo journalctl -k -b | egrep -i "NVRM: Xid|pcie|AER" | tail -n 8
Jan 13 09:14:21 server kernel: NVRM: Xid (PCI:0000:65:00): 79, GPU has fallen off the bus.
Jan 13 09:14:22 server kernel: pcieport 0000:40:01.0: AER: Corrected error received: id=00e0

Значення: «Fallen off the bus» вказує на проблеми PCIe/прошивки/живлення, іноді — на помираючу карту.

Рішення: Евакуюйте вузол. Пересадіть GPU, перевірте лінії PSU, відключіть райзери, оновіть BIOS і протестуйте знову. Якщо повторюється — RMA/списання.

Завдання 7: Підтвердити, що версія драйвера відповідає очікуванням CUDA у userspace

cr0x@server:~$ nvidia-smi | head -n 5
Tue Jan 13 09:16:01 2026
+-----------------------------------------------------------------------------+
| NVIDIA-SMI 550.54.14    Driver Version: 550.54.14    CUDA Version: 12.4     |
+-----------------------------------------------------------------------------+

Значення: Драйвер 550.x, вказує сумісність з CUDA 12.4.

Рішення: Якщо ваш контейнер постачається з старим CUDA runtime, воно може все одно працювати, але невідповідності проявляються як дивні runtime-помилки. Фіксуйте і стандартизуйте.

Завдання 8: Перевірити видимість CUDA-пристроїв всередині контейнера

cr0x@server:~$ docker run --rm --gpus all nvidia/cuda:12.4.1-base-ubuntu22.04 nvidia-smi -L
GPU 0: NVIDIA GeForce RTX 3090 (UUID: GPU-2a1b...)
GPU 1: NVIDIA GeForce RTX 3090 (UUID: GPU-9c7d...)

Значення: Рантайм контейнера бачить GPU правильно.

Рішення: Якщо GPU не з’являються тут, проблема в рантаймі/конфігурації (nvidia-container-toolkit, дозволи), а не в «продуктивності GPU».

Завдання 9: Перевірити режим persistence (щоб уникнути дивних холодних запусків)

cr0x@server:~$ nvidia-smi -q | egrep -i "Persistence Mode" -n | head
78:    Persistence Mode                : Disabled

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

Рішення: На серверних вузлах увімкніть persistence mode для стабілізації запусків задач (наступне завдання).

Завдання 10: Увімкнути persistence mode (операційна стабільність)

cr0x@server:~$ sudo nvidia-smi -pm 1
Enabled persistence mode for GPU 00000000:65:00.0.
Enabled persistence mode for GPU 00000000:66:00.0.

Значення: Драйвер тримає пристрої ініціалізованими.

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

Завдання 11: Встановити консервативний ліміт потужності (стабільність важливіша за рекорди)

cr0x@server:~$ sudo nvidia-smi -pl 300
Power limit for GPU 00000000:65:00.0 was set to 300.00 W from 350.00 W.
Power limit for GPU 00000000:66:00.0 was set to 300.00 W from 350.00 W.

Значення: Ви встановили обмеження потужності; зазвичай це покращує температуру і навантаження на VRM з невеликим падінням пропускної здатності.

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

Завдання 12: Перевірити лічильники ECC-помилок (на GPU з підтримкою ECC)

cr0x@server:~$ nvidia-smi -q -d ECC | egrep -i "Single Bit|Double Bit" -n | head -n 20
110:    Single Bit ECC Errors
111:        Volatile
112:            Device Memory            : 0
120:    Double Bit ECC Errors
121:        Volatile
122:            Device Memory            : 0

Значення: ECC-подій не зафіксовано (добре). Якщо ви бачите зростання виправлених помилок, карта може деградувати або перегріватися.

Рішення: Будь-яка ненульова кількість незворотних (double-bit) — це привід негайно евакуювати й замінити в продакшені.

Завдання 13: Стрес-тест обчислень і пам’яті GPU (базовий burn-in)

cr0x@server:~$ sudo apt-get update >/dev/null && sudo apt-get install -y stress-ng >/dev/null
cr0x@server:~$ stress-ng --gpu 1 --gpu-ops 200000 --timeout 10m --metrics-brief
stress-ng: info:  [21434] dispatching hogs: 1 gpu
stress-ng: metrc: [21434] gpu              200000 ops in 600.02s, 333.32 ops/s

Значення: Простий GPU-стрес працював 10 хв. Це не повна кваліфікація, але спливає миттєва нестабільність.

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

Завдання 14: Виміряти, чи ви обмежені вводом/виводом при підгодовуванні GPU

cr0x@server:~$ iostat -xz 1 5
Linux 6.5.0 (server) 	01/13/2026 	_x86_64_	(64 CPU)

avg-cpu:  %user   %nice %system %iowait  %steal   %idle
          18.20    0.00    4.10    9.80    0.00   67.90

Device            r/s     rkB/s   rrqm/s  %rrqm r_await rareq-sz     w/s     wkB/s w_await wareq-sz  aqu-sz  %util
nvme0n1         920.0  148000.0     2.0   0.2    6.80   160.9     55.0   12000.0   4.20   218.2    6.45   92.0

Значення: Високий %util і iowait вказують, що сховище може бути вузьким місцем при завантаженні даних, що призводить до недопостачання GPU.

Рішення: Кешуйте датасети локально, збільшіть кількість prefetch worker-ів, перейдіть на швидше NVMe або паралелізуйте читання. Не купуйте більше GPU, щоб виправити повільні диски.

Завдання 15: Перевірити NUMA і CPU-affinity (уникати штрафів при крос-сокет)

cr0x@server:~$ lscpu | egrep -i "NUMA node|Socket"
Socket(s):             2
NUMA node(s):          2
NUMA node0 CPU(s):     0-31
NUMA node1 CPU(s):     32-63

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

Рішення: Прив’язуйте data loader-и і процеси GPU до найближчого NUMA-нодa при погоні за продуктивністю або стабільністю.

Завдання 16: Перевірити насичення мережі (тренування й розподілені навантаження)

cr0x@server:~$ ip -s link show dev eno1 | sed -n '1,8p'
2: eno1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP mode DEFAULT group default qlen 1000
    link/ether 3c:ec:ef:12:34:56 brd ff:ff:ff:ff:ff:ff
    RX:  bytes packets errors dropped  missed   mcast
    9876543210  8765432      0      12       0       0
    TX:  bytes packets errors dropped carrier collsns
    12345678901 7654321      0       0       0       0

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

Рішення: Дослідіть кільця NIC, узгодженість MTU, затори на комутаторах або перемістіть датасет локально. Не звинувачуйте «CUDA» за втрачені пакети.

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

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

1) Симптом: «Завантаження GPU низьке, але CPU в порядку»

Корінь: Сховище або мережа не можуть підживити конвеєр даних (iowait, високий %util диска, повільні віддалені читання).

Виправлення: Виміряйте за допомогою iostat, кешуйте датасети на локальному NVMe, збільшіть prefetch, використовуйте послідовні формати або передшардируйте дані.

2) Симптом: «Однакові вузли мають різну пропускну здатність»

Корінь: Змішані варіанти плат GPU, різні VBIOS, різні ліміти потужності або різна ширина PCIe-лінку.

Виправлення: Проведіть інвентаризацію з nvidia-smi -q, нормалізуйте ліміти потужності, перевірте Gen/width PCIe і розподіліть вузли по окремих пулах.

3) Симптом: «Випадкові CUDA-помилки через години, а не одразу»

Корінь: Тепловий дрейф пам’яті/VRM, маргінальна VRAM або деградація вентиляторів/термопрокладок, характерні для вживаної майнінгової техніки.

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

4) Симптом: «GPU впав з шини»

Корінь: Проблеми цілісності сигналу PCIe (райзери, слоти), нестабільність PSU або апаратний відмова GPU.

Виправлення: Вийміть райзери, пересадіть карти, перевірте оновлення BIOS/прошивки, підтвердіть запас PSU і списуйте/RMA при повторенні.

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

Корінь: Новий драйвер змінив поведінку управління енергією або порушив очікування вашого CUDA/userspace.

Виправлення: Фіксуйте версії драйверів по кластеру, тестуйте на канаркових вузлах, тримайте пакети для відкату, стандартизуйте базові образи контейнерів.

6) Симптом: «Ми купили дешеві вживані GPU, а тепер надійність жахлива»

Корінь: Немає кваліфікаційного ворота; ви ставилися до апаратного забезпечення як до програмного (відвантажили зараз — виправимо потім).

Виправлення: Впровадьте burn-in, пороги помилок/температур для прийому, відстежуйте серійні номери і історію, і закладіть бюджет на списання.

7) Симптом: «Ми не можемо купити GPU, проєкт заблоковано»

Корінь: Just-in-time закупівлі в волатильному товарному ринку.

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

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

Контрольний список закупівель (як купувати GPU, щоб вас не обвели навколо пальця)

1. Визначте вашу функцію цінності. Для інференсу важливіший обсяг пам’яті та енергоефективність, ніж пікові FLOPs. Для тренувань домінують міжз’єднання й пропускна здатність VRAM.
2. Відмовіться від залежності від одного SKU. Плануйте принаймні два прийнятні варіанти GPU і кілька варіантів плат.
3. Питайте партнера по платі + ревізію + умови гарантії. «Однакова модель» — не є специфікацією.
4. Наполягайте на мові алокації в контрактах. Не лише «best effort». Вам потрібні вікна доставки і правила заміщення.
5. Закладайте бюджет на запчастини. Невеликий буфер кращий за екстрену покупку за піковими цінами.
6. Встановіть політику максимальної ціни. Якщо треба переплатити, робіть це навмисно з дозволом керівництва, а не панічними закупівлями.

Контрольний список прийому вживаних GPU (ставте їх як диски)

1. Зафіксуйте ідентифікацію. Серійний номер, UUID, board part number, версія VBIOS і фізичний стан.
2. Почистіть і огляньте. Пил, корозія, люфт вентиляторів, пошкоджені конектори. Якщо відчуваєте запах паленого, зупиняйтесь і карантуйте.
3. Базовий тест. Перевірте ширину/швидкість PCIe і проведіть стрес-тест, логуючи температури й помилки.
4. Теплова ремедіація. Замінюйте вентилятори/прокладки, коли температури високі або нестабільні; не «надійтесь», що охолодження спрацює у стояку.
5. Впуск з порогами. Будь-які повторні Xid, AER-шторм або тепловий розгін — відхиляти/списувати.

Контрольний список операцій в продакшені (тримайте вузли GPU нудними)

1. Стандартизуйте драйвери й контейнери. Фіксуйте версії, тестуйте на канарках, автоматизуйте відкат.
2. Увімкніть persistence mode. Зменшіть дивні холодні старти і стабілізуйте час запуску задач.
3. Капайте потужність і моніторте троттлінг. Віддавайте перевагу стабільному пропуску перед піковими бенчмарками.
4. Моніторьте температури й помилки як першокласні SLO сигнали. Здоров’я GPU — це не «проблема апаратної команди», коли воно ламає ваш сервіс.
5. Автоматично евакуйуйте при поганих сигналах. Якщо помилки ростуть або PCIe стає нестабільним, виведіть вузол з пулу раніше, ніж він спричинить інцидент для кількох команд.
6. Відстежуйте історію по карті. Відстеження за серійним номером краще за гадання, який «GPU0» сьогодні проклятий.

Контрольний список планування ємності (вижити під час наступного буму)

1. Квантифікуйте GPU-години, а не кількість GPU. Ваш попит залежить від навантажень; вимірюйте його у пропускній здатності задач і латентності.
2. Моделюйте волатильність цін. Ставте вартість GPU як змінну, а не константу.
3. Проектуйте шляхи дегрейду. Менші batch-и, інференс на CPU для низькоприоритетних запитів або спрощення моделей під час дефіциту.
4. Тримайте закупівельний «ранвей». Якщо час постачання місяці — ваш горизонт планування має бути довшим ніж один спринт.

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

Q1: Чи майнінг «спричинив» всі сплески цін на GPU?

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

Q2: Чому майнери переплачують усім?

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

Q3: Чи всі екс-майнінгові GPU погані?

Ні. Деякі в порядку, особливо якщо їх undervolt-или й тримали холодними. Але варіативність висока.
Якщо ви не можете зробити burn-in і відстеження здоров’я — не купуйте їх у продакшен.

Q4: Який найкорисніший метрик для моніторингу в продакшені?

Причини троттлінгу плюс тренд температур. Саме по собі завантаження може брехати; троттлінгований GPU може бути «завантаженим», але робити менше роботи.
Слідкуйте за потужністю, частотами і тим, чи ви досягаєте теплових або енергетичних лімітів.

Q5: Чи слід піднімати ліміти потужності для більшої продуктивності?

Лише після того, як ви довели, що не обмежені термально і що рівень помилок залишається стабільним під тривалими прогонками.
У продакшені стабільність — це фіча. Тюнінг лімітів потужності має відбуватися через канарку і з планом відкату.

Q6: Як уникнути наступного дефіциту?

Уникнути його неможливо; можна уникнути здивування. Тримайте буфер, контрактуйте алокацію, приймайте багатоваріантне планування і будуйте шляхи деградації навантажень.

Q7: Чи хмара — безпечний вихід, коли GPU дефіцитні?

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

Q8: Який найбільший операційний ризик при змішаному флоті GPU?

Непередбачуваність. Різне охолодження, VBIOS і енергетична поведінка дають різну продуктивність і характеристики відмов.
Без тегування і планувальної обізнаності ви будете дебажити «програмні» проблеми, які насправді апаратні.

Q9: Чи стандартизуватися на «дата-центрових» GPU, щоб уникнути цього?

Це допомагає в підтримуваності і часто в доступності, але не дає абсолютного імунітету. І дата-центрові частини теж можуть опинитися в дефіциті.
Справжня перевага — передбачувані термальні характеристики, перевірені прошивки і гарантійні/RMA-шляхи, що відповідають вашим операційним потребам.

Висновок: наступні кроки, що тримають вас поза зоной ураження

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

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

• Сьогодні: Проведіть інвентаризацію GPU за board part number і VBIOS і почніть тегувати вузли відповідно.
• Цього тижня: Додайте причини троттлінгу, температури і лічильники Xid/AER у моніторинг з автоматичною евакуацією.
• Цього кварталу: Перепишіть політику закупівель, включивши алокацію, правила заміщення і буферні запаси. І застосуйте її.
• Перед наступним бумом: Побудуйте шлях деградації навантаження, щоб дефіцит означав «повільніше», а не «падіння».

Ціни на GPU ще не раз зламаються. Ваше завдання — переконатися, що ваші системи не ламаються разом із ними.