MCM-графіка: що може піти не так і як постачальники це виправляють

Чим MCM-графіка відрізняється (і чому це має хвилювати операції)

MCM‑графіка — це ідея, що «GPU» більше не є монолітичною частиною кремнію. Це пакет із кількома активними кристалами — обчислювальні тайли, IO‑кристали, стекові модулі пам’яті, кеш‑кристали — з’єднаними високошвидкісними інтерконектами й сучасним пакуванням (2.5D інтерпозери, силіконові мости, органічні підложки, різновиди мікробампів).

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

1. Більше каналів, які можуть відмовити. Кожен додатковий перехід die‑to‑die — це місце, де сигнал, синхронізація, тренування лінків або шум живлення можуть піти боком.
2. Більше арбітражу у прошивці. Один монолітний кристал міг приховувати внутрішню складність за «все працює». MCM вимагає більше тренування при завантаженні, управління лінками, обробки помилок і іноді переналаштувань під час роботи.
3. Більше способів «працювати майже нормально». Часткова деградація стає звичною: один тайл тротлить, один стек пам’яті генерує ECC‑корекції, один лінк пере‑тренується під навантаженням. Ваші дашборди показують «GPU працює», але SLO кажуть протилежне.

Операційна пастка: інженери ставляться до MCM GPU як до великих версій торішніх моделей. Та сама стратегія з драйверами, ті ж теплові припущення, той самий підхід «якщо пройшло burn‑in — добре». Це припущення швидко старіє.

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

Цікаві факти й контекст (коротко і по суті)

• Чіплети — це не новинка. Багатокристальні пакети існували десятиліттями; змінилася щільність пропускної здатності й пакування, що дозволяє їм поводитися як один пристрій на рівні GPU.
• HBM зробив «рівень пакету» новою материнською платою. Коли стекова пам’ять стоїть поряд з обчисленням на інтерпозері, багато «DIMM‑ерських» шаблонів відмов зникають — і з’являються нові (локальна терміка стеку, межі PHY, поведінка ECC по стеку).
• Рання multi‑GPU (SLI/CrossFire) — неправильна ментальна модель. Це було «кілька пристроїв через PCIe». MCM — «один пристрій з внутрішніми fabrics», що змінює ізоляцію помилок і семантику ресетів.
• Економіка виходу чіпів — головний драйвер. Менші кристали дають кращий вихід; постачальники можуть бінувати тайли, відключати слабкі одиниці та будувати продуктові лінійки без ставок на один гігантський ретикл.
• Сучасне пакування — окрема доменна надійність. Мікробампи, підплавлення й викривлення підложки можуть створювати часово‑залежні відмови, що виглядають як «випадкові зависання драйвера».
• Тренування інтерконнекту тепер критичне при завантаженні. Помилки тренування лінків можуть проявлятися як переривчаста енумерація або падіння продуктивності, що трапляється лише після холодного завантаження.
• Телеметрія стала кращою, але інтерпретація — складнішою. Ви отримуєте лічильники по кожному лінку, ECC по кожному стеку, тротлинг по кожному тайлу… і потік хибних спрацьовувань, якщо пороги наївні.
• Функції RAS дедалі визначають продукт. Кориговані помилки й поведінка ізоляції — це вже частина продуктової обіцянки, а не лише приємний додаток для HPC.

Режими відмов: що ламається в реальному світі

1) Нестабільність die‑to‑die інтерконнекту: «він не зламався, він просто іноді повільний»

MCM GPU живуть і помирають завдяки своїм внутрішнім fabrics: die‑to‑die лінки, кеш‑коерентні інтерконекти, PHY з’єднання пам’яті і інколи зовнішні fabric‑лінки типу NVLink між пакетами. Ці лінки мають тренування, еквалізацію й поведінку корекції помилок, які можуть змінюватись з температурою, напругою або старінням.

Як це проявляється:

• Флуктуація продуктивності: p95‑латентність подвоюється без очевидних змін у завантаженні.
• Переривчасті зависання під піковим навантаженням, часто під час all‑reduce або інтенсивного P2P‑трафіку.
• Лічильники коригованих помилок поступово ростуть; некориговані помилки викликають ресет GPU або завершення задачі.

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

2) Живлення та перехідна реакція: ваш PSU невинний, це не його рейли

MCM збільшує локальні перехідні струми: кілька тайлів перемикаються в унісон, вибухи HBM, спайки активності fabric. VRM плати й регулятори на пакеті мають встигати. Якщо ні — ви отримуєте поведінку, схожу на brownout, що виглядає як баги в софті.

Як це проявляється:

• Ресети GPU під час різких наростань навантаження (старт задачі, численні виклики ядер, переходи у змішаній точності).
• Логи ядра показують «GPU fallen off the bus» або ресети PCIe‑лінку.
• Частіші помилки при вищих лімітах потужності або агресивних boost‑налаштуваннях.

3) Теплові градієнти всередині пакету: середня температура бреше

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

Як це проявляється:

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

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

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

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

Як це проявляється:

• GPU видимий ОС, але створення контекстів у CUDA/ROCm/OpenCL відмовляється.
• Файлові вузли пристрою існують; інструменти повідомляють «OK»; задачі падають одразу.
• Лише повний ребут хоста відновлює нормальну поведінку.

5) ECC та RAS‑телеметрія: корекції — це попередження, а не медалька

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

Як це проявляється:

• Повільне наростання коригованих помилок, потім раптові завершення задач.
• Незрозумілі «illegal memory access» помилки, що корелюють з подіями ECC.
• Вищі ставки помилок на конкретних GPU або позиціях в шасі.

6) Поведінка PCIe і BAR: лінк до хоста все ще важливий

Навіть якщо внутрішній GPU складається з чіплетів, хост бачить пристрій PCIe. MCM GPU можуть збільшити навантаження MMIO, чутливість до розмірів BAR і складність ресетів. Resizable BAR та налаштування IOMMU можуть допомогти або нашкодити залежно від якості прошивки.

Як це проявляється:

• Пристрій енумерується, але драйвер не ініціалізується після оновлення прошивки.
• Логи PCIe Advanced Error Reporting (AER) показують сплески коригованих помилок під час навантаження.
• P2P‑трансфери повільніші за очікуване або час від часу тайм‑аутяться.

7) Планування драйвера та «приховані припущення» симетрії

Деякі ранні проєкти MCM відкривають асиметрію: IO‑кристал проти обчислювальних, спільні кеші або різні домени афінності пам’яті. Якщо драйвер припускає рівномірну латентність, він може розміщувати роботу підоптимально. Якщо ваш застосунок припускає симетрію, він може посилити проблему.

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

8) Мікроконтролери прошивки: прихована операційна система всередині GPU

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

Як це проявляється:

• Проблеми, що зникають після оновлення прошивки (або з’являються після нього).
• Проблеми, що відтворюються лише після warm reboot, а не cold boot.
• «Застряг у низькому енергетичному стані» або «не піднімається у boost» без термальної причини.

9) Старіння на рівні пакування: коли «працює в QA» ≠ «працює у 14‑му місяці»

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

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

Як постачальники патчать MCM‑графіку на практиці

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

Шар патчів 1: оновлення прошивки (VBIOS, прошивка пристрою, образи мікроконтролерів)

Патчі прошивки зазвичай спрямовані на:

• Тренування лінків та еквалізація: кращі пресети, довші вікна тренування, логіка повторних спроб, налаштована для маргінальних каналів.
• Управління живленням: менш агресивні переходи в boost, інші заходи щодо провалів напруги, переглянуті послідовності power‑gating.
• Політика RAS: коли ресетити, коли ізолювати, коли працювати в урізаному режимі; пороги ескалації коригованих помилок.
• Обробка ресетів: поліпшення відновлення без перезавантаження хоста.

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

Шар патчів 2: зміни в драйвері ядра

Драйвери патчать поведінку апаратури. Типові шаблони:

• Налаштування таймаутів: уникати хибного виявлення зависань при довших ядрах або важчих fabrics.
• Краще декодування помилок: відображення криптичних кодів помилок у дієві категорії; експозиція лічильників по лінках.
• Обхідні шляхи: відключення оптимізації, що викликає баг апаратури (таке трапляється).
• Поліпшення ресетів: спроба ресету тайла перед повним ресетом пристрою; кращий cleanup контекстів.

Шар патчів 3: користувацькі бібліотеки та рантайми

CUDA/ROCm/OpenCL‑стеки, бібліотеки колективів та ML‑фреймворки інколи постачають пом’якшення:

• Інші алгоритми за замовчуванням для all‑reduce, коли P2P нестабільний.
• Консервативніша поведінка пулінгу пам’яті, щоб зменшити напругу через фрагментацію.
• Перевірки здоров’я, що виявляють «зомбі‑пристрої» і відмовляються швидко.

Шар патчів 4: BIOS платформи та PCIe‑quirks

Оновлення BIOS/UEFI материнської плати можуть змінити ASPM PCIe, поведінку тренування лінку, обробку BAR і дефолти IOMMU. На деяких платформах це різниця між «рідкісними коригованими помилками» і «щоденними ресетами шини».

Як постачальники вирішують, що патчити спочатку

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

Що вам робити: ставтеся до прошивки/драйвера GPU як до єдиного зв’язаного блоку. Не «просто оновлюйте драйвер» ізольовано і не дивуйтеся, коли несумісність прошивки призводить до нових режимів відмов.

Жарт №2: Реліз‑ноти постачальника схожі на прогноз погоди: корисні, іноді помилкові, але попередження шторму ігнорувати не варто.

План швидкої діагностики

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

Перше: визначте, це лінк до хоста, здоров’я пристрою чи навантаження

1. Санітність хост‑лінку: PCIe AER, зміни швидкості/ширини лінку, «fallen off the bus», помилки IOMMU.
2. Стан пристрою: лічильники ECC, причини тротлінгу, Xid/логи ресетів драйвера, помилки fabric.
3. Кореляція з навантаженням: чи відбувається це лише на певних ядрах, розмірах батчів або паттернах комунікації?

Друге: класифікуйте відмову як «деградація» або «жорстка відмова»

• Деградація: пропускна здатність впала, латентність зросла, кориговані помилки зростають, частоти нестабільні. Дія: злити задачі + розслідувати, можливо налаштування прошивки/драйвера, перевірка повітряного потоку.
• Жорстка відмова: некориговані ECC, петлі ресетів GPU, пристрій зникає. Дія: негайно карантинити GPU/вузол, зберегти логи, не панікувати з безладними операціями.

Третє: визначте обсяг і радіус ураження

• Тільки один GPU: підозрюйте маргінальність апаратури або слот/PSU/локальний повітряний потік.
• Весь вузол: підозра на BIOS платформи, ядро, живлення, бекплейн або оновлення драйвера.
• Ряд/шасі: підозра на охолодження, розподіл живлення, rollout прошивки або брак партії вузлів.
• Кластер‑широко після зміни: підозра на несумісність софту/прошивки або поведінку планувальника.

Четверте: оберіть найменш ризикований захід, що дає час

• Знизити power cap / тимчасово відключити boost.
• Налаштувати криву вентиляторів або покращити повітряні шляхи; перевірити температуру на впуску.
• Відключити проблемний P2P‑шлях / змінити алгоритм колективів.
• Закріпити на стабільних комбінаціях драйвера+прошивки; відкатати, якщо регресія очевидна.
• Карантинити певні GPU з ростучими ECC або повторними ресетами.

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

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

Завдання 1: Перевірити видимість GPU та стан persistence

cr0x@server:~$ nvidia-smi -L
GPU 0: NVIDIA A100-SXM4-80GB (UUID: GPU-2d3f...)
GPU 1: NVIDIA A100-SXM4-80GB (UUID: GPU-9a11...)

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

Рішення: Якщо GPU відсутній або з’являється час від часу — негайно перевірте PCIe AER і dmesg; не витрачайте час на логи ML‑фреймворку.

Завдання 2: Прочитати логі драйвера/ядра про ресети і події шини

cr0x@server:~$ sudo dmesg -T | egrep -i "nvrm|xid|pcie|aer|amdgpu|iommu" | tail -n 20
[Mon Jan 21 08:12:44 2026] NVRM: Xid (PCI:0000:41:00): 79, pid=22341, GPU has fallen off the bus.
[Mon Jan 21 08:12:44 2026] pcieport 0000:40:01.0: AER: Corrected error received: 0000:40:01.0
[Mon Jan 21 08:12:44 2026] pcieport 0000:40:01.0: PCIe Bus Error: severity=Corrected, type=Physical Layer, (Receiver ID)

Що це означає: «Fallen off the bus» — це подія класу host‑link/power/reset. AER physical layer помилки вказують на цілісність сигналу або нестабільність лінку.

Рішення: Якщо ви бачите повторні сплески AER навколо відмов — ставте це як апаратну/платформну проблему у пріоритет: слот, riser, кабель (якщо є), налаштування BIOS PCIe, перехідні напруги.

Завдання 3: Переконатися, що ширина/швидкість PCIe не знизилися

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

Що це означає: Пристрій може працювати в Gen4 x16, але зараз працює в Gen3 x8. Це провал продуктивності і часто симптом маргінальної цілісності сигналу або BIOS‑квірку.

Рішення: Якщо відбувся дауншифт — пересуньте/пересадіть GPU/riser, оновіть BIOS платформи, розгляньте примусове встановлення покоління PCIe в BIOS для стабільності і порівняйте з відомо‑добрими вузлами.

Завдання 4: Перевірити статус Resizable BAR (поширене джерело «працює, але дивно»)

cr0x@server:~$ sudo lspci -s 41:00.0 -vv | egrep -i "Resizable BAR|BAR 1|Region 0" -n
55: Region 0: Memory at 3a000000000 (64-bit, prefetchable) [size=16M]
61: Resizable BAR: Current Size: 256MB, Supported: 256MB 512MB 1GB 2GB 4GB

Що це означає: Розмір BAR впливає на ефективність мапування апертур пам’яті GPU процесором. Деякі комбінації прошивки/драйвера сильно регресують при певних розмірах.

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

Завдання 5: Перевірити частоти GPU, потужність і причини тротлінгу

cr0x@server:~$ nvidia-smi -q -d CLOCK,POWER,TEMPERATURE | egrep -i "GPU Current Temp|Power Draw|Power Limit|Clocks|Throttle" -n | head -n 60
118: GPU Current Temp            : 78 C
141: Power Draw                  : 345.22 W
142: Power Limit                 : 400.00 W
210: Clocks
214:     Graphics                : 990 MHz
230:     Memory                  : 1215 MHz
310: Clocks Throttle Reasons
314:     SW Power Cap            : Active
318:     HW Thermal Slowdown     : Not Active

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

Рішення: Якщо продуктивність низька і активний SW power cap — перевірте політику ліміту потужності; розгляньте підвищення ліміту або згладжування стрибків навантаження.

Завдання 6: Інспектувати лічильники ECC (кориговані помилки важливі)

cr0x@server:~$ nvidia-smi -q -d ECC | egrep -i "Volatile|Aggregate|Correctable|Uncorrectable" -n | head -n 80
60: Volatile ECC Errors
62:     Single Bit
64:         Device Memory        : 120
70:     Double Bit
72:         Device Memory        : 0
90: Aggregate ECC Errors
92:     Single Bit
94:         Device Memory        : 8421

Що це означає: Накопичуються кориговані ECC‑помилки. Волатильні лічильники скидаються при перезавантаженні; агрегати — зберігаються через перезавантаження (залежно від реалізації).

Рішення: Якщо кориговані помилки швидко зростають або корелюють з гарячими періодами — злити цей GPU з задач, що чутливі до латентності, і перевірити охолодження та оновлення прошивки/драйвера. Якщо з’являються double‑bit (некориговані) — негайно карантинити.

Завдання 7: Отримати статус fabric / NVLink‑класу лінків (де доступно)

cr0x@server:~$ nvidia-smi nvlink --status
GPU 0: Link 0: Up
GPU 0: Link 1: Up
GPU 1: Link 0: Up
GPU 1: Link 1: Down

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

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

Завдання 8: Перевірити лічильники PCIe AER вживу (якщо доступно) через journal

cr0x@server:~$ sudo journalctl -k --since "10 min ago" | egrep -i "AER:|PCIe Bus Error" | tail -n 20
Jan 21 08:11:05 server kernel: pcieport 0000:40:01.0: AER: Corrected error received: 0000:40:01.0
Jan 21 08:11:05 server kernel: pcieport 0000:40:01.0: PCIe Bus Error: severity=Corrected, type=Physical Layer

Що це означає: Кориговані помилки фізичного шару часто вказують на маргінальні лінки. Одна‑дві помилки можуть бути шумом; сплески під навантаженням — закономірність.

Рішення: Якщо лічильник зростає з активністю GPU — надавайте пріоритет платформним виправленням: пересадити, змінити налаштування BIOS, замінити riser або перемістити GPU в інший слот для перевірки.

Завдання 9: Підтвердити стан IOMMU (взаємодіє з ресетами і P2P)

cr0x@server:~$ dmesg -T | egrep -i "iommu|dmar" | head -n 20
[Mon Jan 21 07:58:01 2026] DMAR: IOMMU enabled
[Mon Jan 21 07:58:01 2026] DMAR: Intel(R) Virtualization Technology for Directed I/O

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

Рішення: Якщо ви бачите DMA mapping fault або дивну поведінку P2P — протестуйте з відомими‑добрими налаштуваннями IOMMU (включно з passthrough) на канарці перед змінами на весь флот.

Завдання 10: Виміряти використання GPU проти використання пам’яті, щоб виявити «очікування по fabric»

cr0x@server:~$ nvidia-smi dmon -s pucm -d 1 -c 5
# gpu   pwr gtemp mtemp    sm   mem   enc   dec
# Idx     W     C     C     %     %     %     %
    0   210    74     -     12     85     0     0
    1   205    73     -     15     88     0     0

Що це означає: Використання SM низьке, а пам’ять висока: навантаження memory‑bound, застоюється або чекає на трансфери. В MCM внутрішні проблеми fabric можуть маскуватись під «memory‑bound».

Рішення: Якщо цей паттерн з’явився раптово після зміни або лише на певних GPU — підозрюйте тротлінг, дауншифт лінків або проблему fabric/лінку, а не «модель стала гірша».

Завдання 11: Перевірити ресети GPU і події persistence через інструменти постачальника (приклад NVIDIA)

cr0x@server:~$ nvidia-smi -q | egrep -i "Reset Status|Pending|Retired Pages" -n | head -n 80
420: Reset Status
424:     Reset Required          : No
610: Retired Pages
614:     Single Bit ECC          : 2
618:     Double Bit ECC          : 0

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

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

Завдання 12: Нагрузити шлях інтерконнекту, який ви реально використовуєте (не іграшковий бенч)

cr0x@server:~$ python3 -c "import torch; import time; x=torch.randn(8192,8192,device='cuda'); torch.cuda.synchronize(); t=time.time(); y=x@x; torch.cuda.synchronize(); print('matmul_s', time.time()-t)"
matmul_s 0.7421183586120605

Що це означає: Простий таймінг ядра для sanity‑перевірки. Це не валідує весь стек, але допомагає відокремити «GPU кардинально повільний/зламаний» від «мережа кластера палає».

Рішення: Якщо одно‑GPU стабільний, але multi‑GPU задачі падають — фокусуйтеся на P2P/NVLink/PCIe‑топології та бібліотеках колективів. Якщо одно‑GPU нестабільний — фокусуйтеся на терміці/живленні/драйвері/прошивці по вузлу.

Завдання 13: Перевірити топологію і P2P‑здатність (приклад NVIDIA)

cr0x@server:~$ nvidia-smi topo -m
        GPU0    GPU1    CPU Affinity
GPU0     X      NV1     0-31
GPU1    NV1      X      0-31

Що це означає: GPU мають швидкий лінк (NV1). Якщо ви очікували NVLink, а бачите «PHB» або «SYS», ваш трафік піде через PCIe/CPU і ваша модель продуктивності неправильна.

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

Завдання 14: Підтвердити версії (драйвер, прошивка) і припинити запускати загадкові комбінації

cr0x@server:~$ nvidia-smi
Wed Jan 21 08:14:02 2026
+-----------------------------------------------------------------------------+
| NVIDIA-SMI 550.54.14    Driver Version: 550.54.14    CUDA Version: 12.4     |
+-----------------------------------------------------------------------------+

Що це означає: У вас конкретна версія драйвера. Зв’яжіть це з інвентарем версій прошивки; «latest» — не стратегія інвентаризації.

Рішення: Якщо відмови корелюють з недавнім rollout‑ом драйвера — зафіксуйте й відкатайте на підмножині. Якщо корелюють з прошивкою — координуйте погоджене оновлення/відкат.

Завдання 15: Перевірити CPU frequency scaling і IRQ‑шторм (GPU не живе сам по собі)

cr0x@server:~$ sudo turbostat --Summary --quiet --show Avg_MHz,Busy%,Bzy_MHz -i 2 -n 3
Avg_MHz  Busy%  Bzy_MHz
  1020   12.34    8270
   980   10.90    8205
  1005   11.80    8250

Що це означає: Якщо CPU застряг на низькій частоті через політику живлення або термальні обмеження, це може створити вузьке місце в подачі даних, запуску та I/O — особливо для дрібних ядер або інтенсивного control‑plane трафіку.

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

Завдання 16: Швидка перевірка NIC і RDMA (тут багато multi‑GPU задач падає)

cr0x@server:~$ ip -s link show dev eth0 | head -n 12
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 9000 qdisc mq state UP mode DEFAULT group default qlen 1000
    RX:  bytes  packets  errors  dropped  missed   mcast
    9876543210  1234567  0       0        0        12
    TX:  bytes  packets  errors  dropped  carrier collsns
    8765432109  2345678  0       0        0       0

Що це означає: Немає помилок/відкидань. Якщо ви бачите помилки — ваш «GPU hang» може бути тим, що задача чекає на мережеві колективи.

Рішення: Якщо мережеві помилки корелюють зі стагнаціями — триажуйте мережу першочергово. Якщо мережа чиста і лише певні пари GPU падають — поверніться до P2P‑лінків і топології GPU.

Три корпоративні міні‑історії (анонімізовано, правдоподібно і болісно реальне)

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

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

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

Врешті‑решт один SRE порівняв «хороший вузол» і «поганий вузол» пліч‑о‑пліч. Поганий вузол показував поступове зростання коригованих HBM‑помилок, корельоване з вищою температурою впуску повітря у верхній частині стійки. Нічого драматичного. Просто нахил.

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

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

Команда продуктивності хотіла вирвати трохи додаткової пропускної здатності. Вони підняли ліміти потужності GPU і ввімкнули найагресивніший boost, дозволений постачальником. Бенчмарки покращилися. Роллаут пішов масово, бо канаркові тести були короткими й графіки виглядали добре.

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

Насправді все було нудною фізикою: нова політика живлення збільшила перехідні кроки навантаження, і частина плат/платформ мала менший запас. Внутрішні fabrics і PCIe‑лінки виявилися чутливішими до таких провалів, ніж попередні монолітні GPU. Відмови були рідкісні, щоб прослизнути через короткі тести, але часті, щоб зруйнувати SLO у продакшені.

Відкат до консервативних лімітів потужності зупинив ресети. Потім вони поволі повернули підганяння, з довшими soak‑тестами і явним моніторингом на PCIe AER‑сплески та зміни причин тротлінгу. Урок: у світі MCM «більше потужності» не є безкоштовним регулятором продуктивності; це також важіль надійності.

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

Інша організація вела суворий матрицю апаратного+прошивки. Кожен вузол звітував версію драйвера, VBIOS/прошивки, BIOS платформи й невеликий набір RAS‑лічильників в CMDB‑подібну систему. Це було нудно. Інженери скаржилися, що це сповільнює rollout.

Потім постачальник випустив оновлення драйвера, що на папері покращило продуктивність, але внесло рідкісний баг ресету на конкретному stepping‑у прошивки. Лише підмножина вузлів мала той stepping — через партію закупівлі посеред року. Змішані флоти трапляються; робити вигляд, що їх нема, — не допомагає.

Коли почалися відмови, їм не потрібен був тиждень археології. Вони запитали: «покажи вузли з драйвером X і прошивкою Y і зростаючим PCIe AER». Перетин був малий і чіткий. Вони закріпили ті вузли на старішому драйвері, решту лишили на новому і продовжили деплой.

Це не було геройством. Це була дисципліна інвентаризації і поетапні rollout‑и. Краща відповідь на інцидент — не гадати.

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

1) Симптом: раптове падіння пропускної здатності на підмножині вузлів

Корінь: дауншифт PCIe‑лінку (Gen4→Gen3, x16→x8) після пере‑тренування через маргінальну цілісність сигналу або проблеми з riser.

Виправлення: Перевірити статус лінку через lspci -vv; пересадити GPU/riser, оновити BIOS платформи, розглянути примусове покоління PCIe, замінити підозрілі riser.

2) Симптом: переривчасте «GPU fallen off the bus» під навантаженням

Корінь: перехідні/маргінальні проблеми VRM, іноді підсилені агресивними лімітами потужності/boost або недостатнім запасом PSU.

Виправлення: Тимчасово знизити power cap; перевірити PSU і кабелювання; оновити прошивку GPU; виконати довші soak‑тести перед повторним увімкненням агресивних налаштувань.

3) Симптом: задачі падають лише в multi‑GPU, single‑GPU тести проходять

Корінь: проблеми fabric/P2P/NVLink‑класу лінків, невідповідність топології або чутливість алгоритмів колективів до помилок лінку.

Виправлення: Перевірити nvidia-smi topo -m і статус лінків; переключити алгоритм колективів або тимчасово відключити P2P; запланувати апаратний огляд, якщо лінк впав.

4) Симптом: зростання коригованих ECC, але «ще немає відмов»

Корінь: тепловий градієнт, маргінальний HBM PHY, старіння пакування. Це часто є предиктивним сигналом.

Виправлення: Корелювати швидкість ECC з температурою впуску і швидкістю вентиляторів; покращити охолодження; оновити прошивку/драйвер; карантинити, якщо швидкість перевищує базу або зростають retire‑сторінки.

5) Симптом: GPU видимий ОС, але рантайм відмовляється створювати контексти

Корінь: частковий ресет залишив пристрій в неконсистентному стані; невідповідність драйвер/прошивка; застарілий стан демона persistence.

Виправлення: Спробувати ресет GPU, підтримуваний постачальником; якщо ненадійно — перезавантажити вузол; забезпечити відповідні комбінації драйвера+прошивки і консистентні налаштування persistence.

6) Симптом: флуктуація продуктивності при стабільному завантаженні

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

Виправлення: Перевірити причини тротлінгу; шукати сплески AER; стабілізувати політику живлення; оновити прошивку, що покращує тренування лінків.

7) Симптом: після оновлення деякі вузли не ініціалізують драйвер GPU

Корінь: взаємодія BIOS платформи + Resizable BAR + драйвер, або незадоволена залежність прошивки.

Виправлення: Стандартизувати налаштування BIOS; валідувати стан Resizable BAR; відкатати драйвер на вражений hardware stepping; уникати змішаних налаштувань по флоту.

8) Симптом: «випадкові» відмови слідують за тим самим фізичним GPU по хостах

Корінь: маргінальність апаратної частини або старіння на рівні пакування; лічильники помилок розкажуть історію.

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

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

Коли ви купуєте або впроваджуєте MCM GPU

1. Вимагайте матрицю підтримки драйвер+прошивка і ставте її як контракт, а не рекомендацію.
2. Плануйте збір телеметрії: ECC (по стеку, якщо доступно), лічильники лінків, причини тротлінгу, лічильники ресетів.
3. Стандартизуйте налаштування BIOS платформи: політика покоління PCIe, Resizable BAR, режим IOMMU.
4. Проєктуйте з урахуванням теплового запасу: цілі по температурі впуску, політики вентиляторів та валідацію повітряних шляхів на рівні стійки.
5. Проведіть soak‑тести, що імітують продакшн (тривалість має значення; важливі вибухоподібні навантаження).

Коли ви розгортаєте нову прошивку/драйвер

1. Канарте на репрезентативних hardware stepping‑ах і розміщеннях у стійці (гарячі/холодні зони).
2. Трекуйте: PCIe AER‑сплески, ширина/швидкість лінку, швидкість коригованих ECC, retire‑сторінки, події ресетів.
3. Тримайте артефакти для відкату готовими (пакети драйверів, образи прошивки, відомий‑добрий BIOS‑профіль).
4. Розгортайте поступово; зупиняйтеся при першій ознаці нового підпису помилки.
5. Ніколи не змінюйте прошивку, драйвер і BIOS одночасно, якщо ви не любите невизначеність.

Коли ви в інциденті

1. Класифікуйте: деградація чи жорстка відмова.
2. Зберігайте докази: dmesg/journal, логи постачальника, лічильники ECC до перезавантаження, якщо можливо.
3. Спочатку перевірте стан PCIe‑лінку і AER; це швидко і часто вирішує.
4. Мітігуйте з найменшим радіусом ураження: злити/карантинити GPU чи вузол; знизити power cap.
5. Лише потім занурюйтесь у симптоми на рівні фреймворку.

Коли ви будуєте довгострокову надійність

1. Алертуйте по швидкостях, а не лише по абсолютним порогам (кориговані ECC на годину краще за «ECC > 10,000»).
2. Тримайте «відомо‑добрий» базовий вузол для порівнянь.
3. Автоматизуйте карантин для повторюваних підписів ресетів і зростаючих лічильників помилок.
4. Ведіть інвентар: прошивка/VBIOS GPU, драйвер, ядро, BIOS платформи та мапування слотів/riser.
5. Періодично запускайте перевірки лінків і пропускної здатності, щоб ловити тихі дауншифти.

FAQ

1) Чи MCM GPU за своєю суттю менш надійні за монолітні GPU?

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

2) Який найпоширеніший індикатор «це апаратура»?

Повторні події PCIe AER під навантаженням, дауншифти лінку та повідомлення «fallen off the bus». Це не ваш Python‑код, що поводиться некоректно.

3) Чи ігнорувати кориговані ECC‑помилки?

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

4) Чому проблеми з’являються лише після warm reboot?

Бо тренування лінків і послідовності ініціалізації прошивки можуть відрізнятися між cold boot і warm reset. Деякі маргінальні канали проходять по одному шляху, але не по іншому.

5) Чи зазвичай оновлення прошивки покращують стабільність?

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

6) Які метрики слід оповістити для MCM GPU?

Швидкість коригованих ECC, некориговані події, retire‑сторінки, лічильники ресетів, причини тротлінгу (потужність/терміка), ширина/швидкість PCIe, і PCIe AER‑сплески. Додавайте статус fabric‑лінків там, де доступно.

7) Чи «GPU використання низьке, пам’ять висока» завжди означає проблему моделі?

Ні. Це може означати, що задача memory‑bound, але в MCM‑системах це також може вказувати на внутрішні проблеми fabric, пере‑тренування лінків, тротлінг або вузькі місця на хості, що подають дані на GPU.

8) Як вирішити між карантином GPU і заміною всього вузла?

Якщо проблема слідує за GPU при переміщенні в відомо‑хороший хост — карантин/RMA GPU. Якщо кілька GPU відмовляють в одному хості/слоті/стійці — підозрюйте живлення платформи, терміку, BIOS, riser або бекплейн.

9) Чи може Resizable BAR спричинити реальні проблеми у продакшені?

Так — переважно через взаємодії прошивки/драйвера. Стандартизуйте налаштування і валідуйте з вашою точною комбінацією драйвер+прошивка; не дозволяйте їй відрізнятись по флоту.

10) Який найкращий «перший тест», коли продуктивність виглядає неправильно?

Перевірте стан PCIe‑лінку (lspci -vv), потім причини тротлінгу і живлення/терміки, далі ECC і логи ресетів. Швидко, об’єктивно і зазвичай вирішально.

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

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

Що робити далі, у порядку пріоритету:

1. Стандартизувати й інвентаризувати матрицю драйвер+прошивка+BIOS. Змішані загадкові комбінації — шлях до моторошних кластерів.
2. Алертувати по трендах: швидкість коригованих ECC, AER‑сплески, дауншифти лінків, підписи ресетів.
3. Операціоналізувати карантин для повторних порушників. Не дозволяйте одному маргінальному GPU отруїти чергу задач.
4. Розгортати поетапно з soak‑тестами, що відображають продакшн, включно з вибухоподібними фазами і multi‑GPU колективами.
5. Тримати швидкий цикл діагностики, що починається з PCIe/лінків/терміки перед заглибленням у логи фреймворку.

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