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

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

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

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

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

Що таке «примарний GPU» (і чому це трапляється)

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

Невідповідність ідентичності: Ви очікували модель X з 80GB; отримали модель Y з vBIOS, який бреше, або плату з відключеними функціями.
Невідповідність стану: «Нова» насправді відновлена; «відновлена» насправді була у майнінгу або в крипто-датацентрі з важким навантаженням.
Невідповідність можливостей: Це правильний кристал, але тепловий режим, PCIe-канал, подача живлення або стабільність пам’яті скомпрометовані.
Невідповідність середовища: GPU — справжній, але ваш драйвер, ядро, прошивка, PCIe-топологія або шар віртуалізації роблять його поводитися ніби підробка.

Сучасні GPU — це стек: PCIe device IDs, vBIOS, VPD-поля, ідентифікатори плати, серійники, запобіжники, телеметрія ECC і драйвер, який переводить маркетинг у реальність. Зловмисники, сумнівні реселери та чесні помилки всі націлені на одну слабку точку: ви довіряєте мітці більше, ніж телеметрії.

Моя упередженість: ставтеся до кожного GPU як до накопичувача. Ви не поставите випадковий уживаний SSD у кластер бази даних без читання SMART, перевірки прошивки та burn-in. Тут те саме — тільки GPU можуть виходити з ладу більш креативно.

Жарт №1: «Легко використаний майнінг-карт» — це як «легко використаний парашут». Може бути в нормі, але ви не хочете дізнатися правду під час польоту.

Кілька фактів та історія, що пояснюють сучасний безлад

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

Підробки GPU існували до ери AI. Значно до LLM підробники перепрошивали карти нижчого рівня під моделі вищого класу, щоб обдурити геймерів і професійних користувачів.
Прошивки vBIOS перепрошивали десятиліттями. Ентузіасти використовували це, щоб розблокувати функції, змінити криву вентиляторів або видавити продуктивність — створивши інструменти й досвід, які потім використали підробники.
Бум криптовалют 2017–2018 нормалізував «флот карт». Ця хвиля породила величезні обсяги дуже вживаних карт, які пізніше повернулися на ринок перепродажу, часто косметично очищеними.
Датацентрові GPU стали мішенню ланцюга постачання, коли вони стали дефіцитними. Коли строки постачання зросли, брокери з’явилися в одну ніч. Дехто легітимний; дехто — фактично сервіси маршрутизації електронних відходів.
PCIe-топологія зараз має більше значення. Сучасні сервери мають складну розводку ліній, біфуркацію, ретаймери й кілька root complex — тому «повільно» може бути проблемою платформи, а не карты.
Телеметрія ECC змінила правила гри. Багато датацентрових GPU відкривають лічильники коригованих/некоригованих помилок. Це подарунок — якщо ви насправді дивитеся.
MIG і SR-IOV ускладнюють ідентичність. Розподіл і віртуалізація можуть зробити легітимний GPU «неправильним», якщо ви не знаєте, у якому режимі він.
Теплопровідні матеріали старіють швидше, ніж каже маркетинг. Прокладки і термопаста деградують; вентилятори зношуються; елементи VRM дрейфують. Відновлена карта, що «проходить завантаження», може бути в одному термальному циклі від тротлінгу.

Модель загроз: як підроблені та відновлені GPU вас обманюють

1) «Воно перераховується, отже воно справжнє» — це пастка

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

2) Три поширені схеми шахрайства

Перепрошити карту нижчої моделі як вищу: Часто провалюється під навантаженням, показує дивний обсяг пам’яті або має неконсистентні device ID між інструментами.
Продавати відремонтовані плати як «нові»: Перероблені компоненти, замінені чіпи пам’яті або «reballed» GPU. Іноді стабільні, іноді ні. Збої можуть бути періодичними й залежними від тепла.
Продавати ex-fleet/ex-mining як «refurbished»: Кристал може бути справжнім. Проблема — ресурс життя: вентилятори, VRAM і VRM. Майнингова навантаження дуже жорстка: постійне навантаження, постійне тепло, часті експерименти з undervolting/overclocking.

3) Непривабливий збій: неоднозначність у закупівлях

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

4) Мислення надійності, перефразовано

Цитата (перефразована думка): Ідея John Allspaw полягає в тому, що надійність — це результат системного мислення: припущення — ворог, а зворотні зв’язки — ліки.

Швидкий план діагностики (перші/другі/треті перевірки)

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

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

Чи бачить його ядро постійно? Перевірте перерахування PCIe і журнали ядра.
Чи погоджується драйвер? Порівняйте lspci проти nvidia-smi (або ROCm-інструментів) на предмет консистентності.
Чи здоровий PCIe-лінк? Швидкість і ширина лінку. Карта x16, що працює на x4, — на практиці «примара».

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

Розмір пам’яті і стан ECC. Чи повідомляє вона очікуваний VRAM? ECC увімкнено/вимкнено відповідно до норми SKU?
Часові частоти і ліміти потужності. Чи є тротлінг по живленню? Чи застрягла карта в низькому P-state?
Тепловий режим під навантаженням. Чи починає вона тротлити негайно?

Третій: доведіть стабільність коротким burn-in

Запустіть контрольний стрес-тест. Слідкуйте за Xid-помилками, сплесками ECC, скиданнями.
Перевірте персистентність і перезавантаження. Деякі шахрайства проявляються лише після холодного завантаження або циклу живлення.
Порівняйте з еталоном. Той самий клас хоста, той самий драйвер, той самий тест.

Мета — відокремити: «погана карта» vs «погана платформа» vs «погана конфігурація» за менше ніж годину. Якщо не можете — у вас не проблема діагностики, а прогалина в спостережуваності.

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

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

Завдання 1: Підтвердити ідентичність PCIe-пристрою та вендора

cr0x@server:~$ sudo lspci -nn | egrep -i 'vga|3d|nvidia|amd'
01:00.0 3D controller [0302]: NVIDIA Corporation GA100 [A100 PCIe 80GB] [10de:20b5] (rev a1)

Що це означає: Ви отримуєте пару vendor/device ID ([10de:20b5]) і читаєму назву. ID важче підробити, ніж маркетингову назву.

Рішення: Якщо device ID не відповідає придбаному SKU — зупиніться. Не «подивіться, чи працює». Відкрийте тикет прийому та ізолюйте обладнання.

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

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

Що це означає: LnkCap — що апарат підтримує; LnkSta — що фактично погоджено. «(ok)» — ваш друг.

Рішення: Якщо ширина x8/x4 або швидкість 8GT/s, коли очікуєте 16GT/s, усувайте проблеми платформи: посадка карти, вибір слоту, налаштування BIOS, біфуркація, ретаймери. Скарга «підроблений GPU» часто виявляється помилкою «неправильного слота», який вбраний у маску.

Завдання 3: Перевірити журнали ядра на помилки, пов’язані з GPU

cr0x@server:~$ sudo dmesg -T | egrep -i 'nvrm|xid|pcie|aer' | tail -n 25
[Mon Jan 21 09:13:42 2026] NVRM: loading NVIDIA UNIX x86_64 Kernel Module  550.54.14  Tue Dec 17 20:41:24 UTC 2025
[Mon Jan 21 09:14:03 2026] pcieport 0000:00:03.0: AER: Corrected error received: 0000:01:00.0
[Mon Jan 21 09:14:03 2026] nvidia 0000:01:00.0: AER: PCIe Bus Error: severity=Corrected, type=Physical Layer

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

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

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

cr0x@server:~$ nvidia-smi -L
GPU 0: NVIDIA A100-PCIE-80GB (UUID: GPU-3b2c1c39-1d1a-2f0a-8f1a-1f5c8f5c2a11)

Що це означає: Стек драйвера перераховує GPU і відкриває UUID. Це інвентарний ідентифікатор, який слід відслідковувати в CMDB, а не «слот 1».

Рішення: Якщо lspci показує GPU, але nvidia-smi — ні, підозрівайте невідповідність драйвера, помилку завантаження модуля ядра, проблеми Secure Boot або GPU, який не ініціалізується.

Завдання 5: Зняти повні поля інвентарю для подальшого порівняння

cr0x@server:~$ nvidia-smi -q | egrep -i 'Product Name|Product Brand|VBIOS Version|Serial Number|GPU UUID|Board Part Number|FRU Part Number' -A0
Product Name                    : NVIDIA A100-PCIE-80GB
Product Brand                   : NVIDIA
VBIOS Version                   : 94.00.9F.00.02
Serial Number                   : 0324XXXXXXXXXX
GPU UUID                        : GPU-3b2c1c39-1d1a-2f0a-8f1a-1f5c8f5c2a11
Board Part Number               : 699-2G133-0200-000
FRU Part Number                 : 900-2G133-0200-000

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

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

Завдання 6: Перевірити розмір пам’яті, режим ECC і лічильники ECC

cr0x@server:~$ nvidia-smi --query-gpu=name,memory.total,ecc.mode.current,ecc.errors.corrected.volatile.total,ecc.errors.uncorrected.volatile.total --format=csv
name, memory.total [MiB], ecc.mode.current, ecc.errors.corrected.volatile.total, ecc.errors.uncorrected.volatile.total
NVIDIA A100-PCIE-80GB, 81920 MiB, Enabled, 0, 0

Що це означає: VRAM і ECC — це базові перевірки. Зростання коригованих помилок при легкому використанні може вказувати на старіння або пошкодження пам’яті.

Рішення: Якщо VRAM неправильний — зупиніться. Якщо кориговані ECC зростають під час burn-in — ізолюйте: ця карта не для продакшен-тренувань або інференсу з SLA.

Завдання 7: Перевірити ліміти потужності та причини тротлінгу

cr0x@server:~$ nvidia-smi --query-gpu=power.draw,power.limit,clocks.current.sm,clocks_throttle_reasons.active --format=csv
power.draw [W], power.limit [W], clocks.current.sm [MHz], clocks_throttle_reasons.active
45.12 W, 250.00 W, 210 MHz, Not Active

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

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

Завдання 8: Підтвердити покоління PCIe з точки зору драйвера

cr0x@server:~$ nvidia-smi -q | egrep -i 'PCIe Generation|Link Width' -A2
PCIe Generation
    Max                         : 4
    Current                     : 4
Link Width
    Max                         : 16x
    Current                     : 16x

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

Рішення: Якщо Current нижче за Max у стабільному стані під навантаженням — можливо застрягли в низькопотужному режимі через налаштування BIOS або ASPM.

Завдання 9: Перевірити температуру, вентилятор і негайну поведінку тротлінгу

cr0x@server:~$ nvidia-smi --query-gpu=temperature.gpu,temperature.memory,fan.speed,pstate --format=csv
temperature.gpu, temperature.memory, fan.speed [%], pstate
36, 40, 30 %, P8

Що це означає: Температури в стані простою мають бути адекватні. Під навантаженням слід слідкувати за температурою пам’яті; пам’ять може тротлити раніше за ядро.

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

Завдання 10: Перевірити обчислювальну функціональність мінімальним CUDA-семплом

cr0x@server:~$ /usr/local/cuda/samples/1_Utilities/deviceQuery/deviceQuery | egrep -i 'Device 0|CUDA Capability|Total amount of global memory|Result'
Device 0: "NVIDIA A100-PCIE-80GB"
  CUDA Capability Major/Minor version number:    8.0
  Total amount of global memory:                 81161 MBytes (85014073344 bytes)
Result = PASS

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

Рішення: Якщо compute capability не відповідає очікуванням — «A100» може бути іншою архітектурою, або ваш контейнер/стек драйверів видає хибні дані через несумісні бібліотеки.

Завдання 11: Запустити короткий burn-in і стежити за Xid/ECC подіями

cr0x@server:~$ sudo gpu-burn -d 60
Burning for 60 seconds.
GPU 0: 0.0%  (0/1024 MB)
GPU 0: 100.0%  (1024/1024 MB)
Tested 1 GPUs:
  GPU 0: OK

Що це означає: Швидкий burn-in не доводить довготривале здоров’я, але виявляє негайну нестабільність: погані чіпи VRAM, граничну подачу живлення, перегрів.

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

Завдання 12: Перевірити поведінку скидання GPU (корисно для хитких відновлених)

cr0x@server:~$ sudo nvidia-smi --gpu-reset -i 0
GPU 00000000:01:00.0 was reset.

Що це означає: Функція reset працює — знак, що GPU коректно реагує на управління.

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

Завдання 13: Перевірити IOMMU-групування для passthrough/ізоляції

cr0x@server:~$ for d in /sys/kernel/iommu_groups/*/devices/*; do echo "$d"; done | egrep '01:00.0|01:00.1'
/sys/kernel/iommu_groups/42/devices/0000:01:00.0
/sys/kernel/iommu_groups/42/devices/0000:01:00.1

Що це означає: Якщо ви робите passthrough, «містичні» поведінки GPU можуть бути пов’язані з IOMMU та ACS. Легітимний GPU може виглядати примарним, коли він згрупований з іншими пристроями.

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

Завдання 14: Підтвердити persistence mode і політики compute mode

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

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

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

Завдання 15: Виявити віртуалізацію/MIG, що змінює те, що ви «бачите»

cr0x@server:~$ nvidia-smi -q | egrep -i 'MIG Mode' -A2
MIG Mode
    Current                     : Enabled
    Pending                     : Enabled

Що це означає: При увімкненому MIG ви можете не бачити «один великий GPU» у вашому планувальнику так, як очікуєте. Люди постійно помилково діагностують це як «відновлену неправильну VRAM».

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

Завдання 16: Порівняти PCIe-помилки в режимі реального часу під стресом

cr0x@server:~$ sudo journalctl -k -f | egrep -i 'aer|xid|nvrm'
Jan 21 09:22:41 server kernel: NVRM: Xid (PCI:0000:01:00): 13, Graphics SM Warp Exception
Jan 21 09:22:41 server kernel: pcieport 0000:00:03.0: AER: Uncorrected (Non-Fatal) error received: 0000:01:00.0

Що це означає: Живе корелювання під навантаженням — як ви відокремлюєте «повільно» від «зламано». Xid 13 часто пов’язаний з обчисленням; рядок AER вказує на проблеми каналу.

Рішення: Якщо AER-помилки з’являються лише в одному шасі/слоті — виправте платформу. Якщо вони переслідують GPU — це ризик апаратури; поводьтеся відповідно.

Жарт №2: Найдорожчий GPU — це той, що пройшов закупівлю і впав під час першого on-call.

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

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

Середня SaaS-компанія вирішила перенести inference внутрішньо. Вони купили невелику партію «датацентрових GPU» через брокера, бо затверджений дистриб’ютор мав ліст очікування. Перевірка при прийомі була проста: встановити ноду в стійку, запустити nvidia-smi, підтвердити рядок назви, потім передати платформній команді.

Все виглядало нормально тиждень. Потім латентність model-serving почала повільно зростати так, що не відповідало навантаженню. Автоскейл додавав вузли, що тимчасово допомагало, але потім ні. SRE на чергуванні помітив закономірність: вузли з нової партії були послідовно повільніші, але тільки під піковим навантаженням. Панелі списували це на «варіацію моделі». Бізнес звинувачував «дані». Класика.

Справжня причина — неправильне припущення: «Якщо nvidia-smi каже A40, то це A40». Пристрої були справжніми NVIDIA-платами, але вони погодилися на нижчу ширину PCIe через невідповідність слота/risер у цьому поколінні шасі. При легкому навантаженні ніхто не помічав. Під важким навантаженням вузьке місце PCIe зробило передачі пакетів і копії хост-устрій повільними, і планувальник продовжував ставити високопродуктивні моделі на ці вузли.

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

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

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

Потім навчальні завдання почали падати дивними способами: out-of-memory на розмірах, що «мають вміщатися», непослідовна продуктивність і кілька контейнерів, що повідомляли менший VRAM, ніж очікувалось. Команда запідозрила підробку обладнання, бо симптоми співпадали з інтернет-фольклором: «карта бреше про пам’ять». Вони ескалували до закупівель, ті — до юридичного, і так далі.

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

Виправлення було оперативним: явне маркування профілів MIG, admission control, щоб заборонити повно-GPU задачі на sliced-пристроях, і належний endpoint ідентифікації GPU, що повідомляє режим MIG і розміри інстансів. Обладнання було невинним; жартівником був шар абстракції.

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

Фінтех-компанія з суворим контролем змін ставилася до GPU як до будь-якого іншого критичного компонента. Кожна вхідна карта проходила через приймальний стенд: запис PCI ID, vBIOS версій, запуск 30-хвилинного стрес-тесту, логування ECC-лічильників до і після, і збереження результатів в базі активів, прив’язану до GPU UUID.

Одного кварталу вони купили змішану партію: деякі нові, деякі від постачальника-реставратора, всі з легітимних каналів. Частина пройшла початкові тести, але показала невеликий ріст коригованих ECC під час стресу. Недостатньо для краху. Достатньо, щоб бути підозріло. Приймальний стенд автоматично їх відфільтрував, бо політика була «зростання ECC під час burn-in = карантин». Нудне правило, послідовно застосоване.

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

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

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

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

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

Корінь: PCIe-лінк погодився на нижчу ширину/швидкість (x4/x8, Gen3 замість Gen4), часто через неправильний слот, проблеми riser-а або біфуркацію BIOS.

Виправлення: Перевірте LnkSta через lspci -vv і nvidia-smi -q. Перемістіть у відомий робочий слот x16. Вимкніть несподівану біфуркацію. Замініть riser/retimer, якщо помилки лишаються.

2) Симптом: «nvidia-smi показує правильну назву, але розмір пам’яті неправильний»

Корінь: Увімкнений MIG, або ви дивитесь на інстанс GPU, а не на повний GPU. Або прошивка невідповідна чи шахрайське перепрошивання.

Виправлення: Перевірте режим MIG. Якщо MIG вимкнений і пам’ять все ще неправильна — порівняйте PCI ID і vBIOS-поля; ізолюйте карту і перевірте на відомому робочому хості.

3) Симптом: «GPU зникає після ребута або під навантаженням»

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

Виправлення: Перевірте dmesg на AER і Xid. Переконайтесь у правильному підключенні живлення. Перевірте повітряний потік шасі та криву вентиляторів. Переповторіть тест в іншій ноді, щоб ізолювати карту від платформи.

4) Симптом: «Під час стресу зростають кориговані ECC-помилки»

Корінь: Деградація VRAM або попереднє сильне використання. Іноді також викликано перегрівом пам’яті через погані прокладки.

Виправлення: Ізолюйте для продакшену. Перевірте тепловий режим; переконайтеся у правильній установці охолодження. Якщо зростання лишається — повертайте по RMA.

5) Симптом: «Частоти застрягли низько; GPU ніколи не бустить»

Корінь: Ліміт потужності зафіксований низько, теплове обмеження, persistence/config проблеми або робота у обмеженому режимі в спільному середовищі.

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

6) Симптом: «Драйвер завантажується, але CUDA-семпл падає»

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

Виправлення: Узгодьте версії драйвера і CUDA runtime. Запустіть deviceQuery спочатку на хості, потім в контейнері. Якщо на хості падає — це апаратна/драйверна проблема; якщо лише в контейнері — виправляйте стек контейнера.

7) Симптом: «Багато виправлених PCIe-помилок, але навантаження в більшості працюють»

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

Виправлення: Перемістіть GPU в інший слот або хост. Очистіть/огляньте конектори. Оновіть BIOS/прошивку. Якщо помилки лишаються в слоті — лагодьте платформу; якщо помилки переслідують GPU — оцінюйте ризик.

8) Симптом: «Дві карти звітують один і той же серійник або серійник відсутній»

Корінь: Ланцюг відновлення перепрограмував VPD-поля, або інструмент/прошивка звітує некоректно.

Виправлення: Ведіть інвентар за GPU UUID і PCI ID, а не лише за серійником. Якщо аномалії серійників корелюють з іншими дивностями — ізолюйте партію і наполягайте на поясненні від постачальника.

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

Крок 0: Правила закупівлі (до того, як гроші покинуть офіс)

Пишіть специфікації закупівлі як інженер, не як маркетолог. Вкажіть точну модель, розмір пам’яті, форм-фактор, інтерконект (PCIe vs SXM) і прийнятний статус відновлення.
Вимагайте походження і умови. Потрібна письмова підтвердження статусу new/refurb, гарантія і умови повернення. Якщо не хочуть підписуватись — і вам не варто.
Попросіть vBIOS і номери деталей заздалегідь. Легітимні постачальники зазвичай можуть надати типовий діапазон vBIOS/PN або хоча б підтвердити їх.
Залиште бюджет часу на приймальні тести. Обладнання без приймальних тестів — просто дороге випадкове придбання.

Крок 1: Фізичний прийом (фаза «не вражайтеся від упаковки»)

Фотографуйте етикетки, конектори і будь-які індикатори втручання. Не заради драми — щоб довести стан при прибутті.
Огляньте контакт PCIe на предмет зносу, залишків або ознак переробки.
Огляньте роз’єми живлення на предмет теплового знебарвлення.
Перевірте гвинти радіатора на сліди інструменту; важка реставрація лишає шрами.

Крок 2: Базовий софт-інвентар (10 хвилин на ноду)

Запишіть lspci -nn, lspci -vv link state та nvidia-smi -q identity-поля.
Запишіть GPU UUID, версію vBIOS і номери деталей плати.
Переконайтесь, що версії драйверів узгоджені по всьому парку перед оцінкою продуктивності.

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

Підтвердіть ширину і покоління PCIe в стані простою і під навантаженням.
Підтвердіть налаштування BIOS: Above 4G decoding, Resizable BAR політики (якщо застосовно), ASPM, біфуркація, SR-IOV/MIG очікування.
Підтвердіть адекватність живлення: правильні кабелі, потужність PSU і відсутність несподіваних спільних ліній.

Крок 4: Політика burn-in і телеметрії (зробіть так, щоб погане залізо важко було пропустити)

Стресуйте щонайменше 30 хвилин для карт, що йдуть у продакшен; довше, якщо можете дозволити.
Зафіксуйте лічильники ECC до і після.
Запишіть журнали ядра під час стресу (AER, Xid).
Критерії відмови: будь-яка некоригована ECC, будь-яке збільшення коригованих ECC під час burn-in, повторювані Xid-скидання, постійний AER під навантаженням.

Крок 5: Розгортання в продакшен (поетапно, марковане, оборотне)

Розгорніть спочатку в canary-пул. Запустіть реальні навантаження з безпечним радіусом ураження.
Міткуйте ноди з GPU UUID і статусом приймання в інвентарі планувальника.
Налаштуйте алерти: дельти ECC, частота Xid, тепловий тротлінг, рівні помилок PCIe.
Майте план відступу: швидка ізоляція/дренаж GPU-ноди і чіткий RMA-процес.

Часті питання

1) Чи може підроблений GPU пройти `nvidia-smi`?

Так, у сенсі, що видимі для софта рядки можуть бути змінені. Але підробити все послідовно важко: PCI ID, compute capability, поведінка пам’яті під навантаженням, телеметрія ECC і стабільність. Саме тому ви перехресно перевіряєте.

2) Яка найкраща одинична перевірка «автентичності»?

Її немає. Якщо змушують вибрати: почніть з lspci -nn device ID плюс короткий стрес-тест під спостереженням ECC/Xid і стану PCIe. Ідентичність без стабільності — міраж.

3) Чи завжди погана ідея купувати відновлені GPU?

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

4) Чим відрізняються відмови майнінгових GPU?

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

5) Якщо ECC вимкнено, чи можна виявити проблеми з пам’яттю?

Можна, але пізніше і болючіше. Без ECC-тілів ви більше покладаєтесь на стрес-тести, помилки додатків і крахи. Для надійності в продакшені краще вибирати SKU з ECC і увімкненою ECC.

6) Чому ширина PCIe така важлива, якщо обчислення відбуваються на GPU?

Бо ви все одно переміщуєте дані: батчі, ваги, активації, препроцесинг/постпроцесинг, чекпоінти і міжвузлову комунікацію. GPU з урізаним PCIe-каналом може виглядати як «повільний код моделі», поки ви не виміряєте це.

7) Яким має бути тривалість burn-in?

Для прийому: 30 хвилин ловить багато речей. Для високопріоритетних кластерів: 2–12 годин краще, особливо для відновлених. Мета — не досконалість, а виявлення ранніх відмов і граничної пам’яті.

8) Що робити, якщо GPU справжній, але має дивну версію vBIOS?

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

9) Чи може віртуалізація зробити справжній GPU підробкою?

Абсолютно. MIG, vGPU, passthrough і невідповідність runtime контейнера можуть змінити звітований обсяг пам’яті, імена пристроїв і навіть експозицію можливостей. Завжди перевіряйте на «чистому» хості перед ескалацією до «шахрайства».

10) Що зберігати в базі активів для GPU?

Як мінімум: GPU UUID, PCI vendor/device IDs, номери плат, версія vBIOS, мапінг хост/слота і результати приймальних тестів (ECC до/після, результат стресу, логи). Серійні номера допомагають, але не робіть на них єдину ставку для аудиту.

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

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

Перестаньте довіряти рядкам імен. Перехресно перевіряйте PCI ID, поля vBIOS і можливості, що звітуються драйвером. Записуйте їх при прийманні.
Вимірюйте платформу, а не лише карту. Підтвердіть ширину/швидкість PCIe і стежте за AER під навантаженням. Багато «поганих GPU» насправді — погані слоти, riser-и або налаштування BIOS.
Впровадьте політику відмови, яку ви реально виконуватимете. Дельта ECC, Xid-шторми і тепловий тротлінг під час burn-in — це не «особливості». Це ранні попередження.

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