Чіплетні GPU: чому ідея логічна — і надзвичайно складна

Чому чіплетні GPU мають сенс (і чому всі їх хочуть)

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

Пояснення простими словами

Чіплетний GPU розбиває великий кристал на кілька менших кристалів (чіплетів) і зшиває їх високошвидкісним інтерконектом. Ви отримуєте:

• Кращий вихід придатних кристалів: менші кристали мають менше дефектів на кристал, отже більше придатних частин з пластиною.
• Масштабованість: «більший GPU» будується додаванням чіплетів замість переробки монструозного кристала.
• Повторно використовувані компоненти: комбінування обчислювальних плит, кеш-плит, IO-плит.
• Гнучкість технологічних вузлів: розміщайте SRAM‑щільний кеш на одному вузлі, обчислення на іншому, IO — на дешевшому вузлі.

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

Що змінюється, коли GPU стає «розподіленим»

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

Чіплетні GPU — це не лише апаратне забезпечення. Це контракт між:

• пакуванням (як фізично з’єднуються кристали),
• інтерконектом (пропускна здатність/латентність/порядок),
• архітектурою пам’яті (розташування HBM, мапування адрес, когерентність),
• компілятором/рантаймом (розміщення кернелів, розподіл роботи),
• драйверами та ОС (експозиція топології),
• та вашим застосунком (шляхи доступу, які ви могли не помічати як крихкі).

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

Складність: видавати кілька кристалів за один GPU

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

1) Інтерконект: пропускна здатність — заголовок, латентність — рахунок

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

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

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

2) Розміщення пам’яті: HBM швидкий; віддалений HBM — «доволі швидкий»

Чіплетні GPU майже завжди тримають HBM поруч із деякими кристалами. Якщо ваш робочий навантаження може залишатися локальним — ви виграєте. Якщо ні — доступ до віддаленої пам’яті стає податком.

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

3) Узгодженість і кеші: тонкий вбивця продуктивності

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

GPU вже грають у хитрощі з когерентністю (різні рівні кешу, некогерентні регіони, атомарні операції зі спеціальними правилами). Чіплети підвищують ставки. Якщо ви хочете семантику «одного GPU», вам потрібно:

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

4) Планування роботи: де виконувати кернел тепер важливо

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

• Який чіплет виконує які блоки?
• Де знаходяться дані?
• Яка вартість міжчіплетної комунікації?
• Що відбувається, коли кілька кернелів конкурують за один і той самий інтерконект?

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

5) Надійність: більше компонентів — більша площа відмов

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

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

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

Одна перефразована ідея від відомого голосу з надійності (приписано): Werner Vogels часто стверджує, що «все ламається, тому проєктуйте на відмови». Чіплетні GPU — це те гасло в кремнії.

Цікавинки та історія, що мають значення

Кілька контекстних пунктів, які справді змінюють ваше мислення про чіплетні GPU, а не тільки факти для слайдів:

1. Предел ретікла фотолітографії — жорстка стеля: ви не можете надрукувати довільно великий монолітний кристал за одне експонування, тож «просто зробіть його більшим» рано чи пізно перестає бути варіантом.
2. Вихід придатних кристалів падає нелінійно з площею кристала: великі кристали не лише дорожчі; вони частіше відмовляють, роблячи топові SKU вправою бінування і молитов.
3. Мультикристальні модулі (MCM) — не новинка: виробники CPU десятиліттями випускали багатокристальні пакети, але шаблони доступу GPU жорсткіші, бо тиск на пропускну здатність і синхронізацію постійний.
4. HBM змінила гру пакування: переміщення пам’яті на інтерпозер поруч із GPU штовхнуло індустрію до просунутого пакування, що є передумовою для чіплетів.
5. Інтерконекти — тепер продукт: те, що колись було внутрішнім проєктуванням fabric, дедалі частіше експонується як «ширина лінка» і «топологія», впливаючи на закупівлі та планування ємності.
6. ПЗ для GPU вже має справу з «кількома пристроями»: тренування на кількох GPU та колективні комунікації існують, але чіплети прагнуть сховати складність multi-die під абстракцією одного пристрою — це складніше, ніж чесно признатися, що це multi-device.
7. NUMA давно дає цей урок: уніфікована пам’ять з нерівномірним доступом працює чудово, поки ваш аллокатор і планувальник не розійдуться щодо ваших «гарячих» шляхів доступу.
8. Консолі та мобільні SoC давно змішують гетерогенні блоки: чіплети розширюють цю модульність у високопродуктивні обчислення, але з суворішими вимогами до латентності й пропускної здатності.

Де це ламається в продакшні: реальні вузькі місця і як вони проявляються

Обриви продуктивності, що виглядають як «випадковий регрес»

Класичний симптом: той самий код, той самий розмір вхідних даних, інший день — раптом на 15–30% повільніше. Без очевидного падіння завантаженості GPU. Без явного вузького місця CPU. Причина часто — розміщення — буфер опиняється «віддаленим» від чіплета, що виконує гарячий кернел, або планувальник змінює розподіл блоків.

Хвостова латентність і джиттер

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

Зіткнення в інтерконекті: «невидиме сповільнення»

У монолітному GPU багато внутрішніх шляхів надпроектовані для типових навантажень. У чіплетному GPU інтерконект — спільний ресурс з ім’ям. Два кернели, що були нормальними поодинці, можуть конкурувати при спільному плануванні, і ви не побачите цього у звичних графіках «завантаження SM».

Міни коректності (рідко, але дорого)

Більшість проблем чіплетних GPU — це проблеми продуктивності. Найгірші — проблеми коректності, які проявляються лише в специфічних умовах синхронізації й порядку пам’яті — зазвичай коли атомарні операції перетинають межі чіплетів або коли копії peer-to-peer перекриваються з обчисленням.

Жарт №2: «Він пройшов юніт-тести» — прекрасна фраза, наче «парашут відкрився зрештою».

Три короткі корпоративні історії з поля бою

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

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

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

Вони два дні дивилися на лічильники NIC і телеметрію комутаторів. Нічого. Потім хтось запустив мікробенчмарк, який торкався сторінок пам’яті в стрибковому шаблоні, і знайшов бімодальну латентність. Рантайм часто розміщував «гарячі» шардінги embedding віддалено від виконавчого чіплета, що ламало SLO по часу кроку.

Фікс був ганебно простий: зафіксувати гарячі шардінги у пам’яті, локальній до чіплета, який виконує embedding‑навантаження, і реструктурувати фазу оновлення, щоб пакетувати міжчіплетний трафік. Глибший урок не в «зафіксуй пам’ять». Він у тому, щоб «не трактувати уніфікований простір адрес як уніфіковану модель витрат».

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

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

На чіплетному обладнанні це перекриття стало пробкою. Двигун префетчу і обчислювальні кернели почали конкурувати на тих самих міжчіплетних шляхах. Замість приховування латентності перекриття її посилило: промахи кешу викликали віддалені вибірки, віддалені вибірки конкурували з асинхронним DMA, а арбітраж інтерконекту карав обидва. Завантаженість GPU лишалась високою, але час кроку погіршився і джиттер виросла.

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

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

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

Команда платформи мала звичку, що здавалася параноїдальною: для кожного нового покоління GPU вони щоночі запускали невеликий набір «перевірок санітарності топології». Не бенчмарки. Перевірки. Ширина лінків, звітувані NUMA‑відстані, peer‑доступ, лічильники ECC, базові мікробенчмарки для локального та віддаленого доступу до пам’яті.

Одного ранку набір сигналізував, що на кількох вузлах швидкість лінка між чіплетами нижча, ніж очікувалося. Ніхто ще не скаржився; навчальні роботи все ще завершувалися. Але варіанс підбирався, і вузли були підсвідомо повільніші.

Виявилось, що партія систем мала налаштування прошивки, яке викликало перетривку лінків за певних теплових умов. Апарат не відвалився голосно; він тихо адаптувався, знижуючи швидкість. Команда ізолювала вузли, застосувала оновлення прошивки і пере-кваліфікувала їх перед наступним великим запуском моделі.

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

Практичні завдання: команди, виводи, рішення (12+)

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

Завдання 1: визначити моделі GPU і версії драйверів

cr0x@server:~$ nvidia-smi
Tue Jan 21 10:12:44 2026
+-----------------------------------------------------------------------------+
| NVIDIA-SMI 550.54       Driver Version: 550.54       CUDA Version: 12.4     |
|-------------------------------+----------------------+----------------------+
| GPU  Name        Persistence-M| Bus-Id        Disp.A | Volatile Uncorr. ECC |
| Fan  Temp  Perf  Pwr:Usage/Cap|         Memory-Usage | GPU-Util  Compute M. |
|-------------------------------+----------------------+----------------------+
|  0  H100 SXM5            On   | 00000000:41:00.0 Off |                    0 |
|  1  H100 SXM5            On   | 00000000:61:00.0 Off |                    0 |
+-----------------------------------------------------------------------------+

Що це означає: Встановіть базу: версія драйвера/CUDA і SKU GPU. Зміни продуктивності, пов’язані з чіплетами, часто корелюють з оновленнями драйвера.

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

Завдання 2: показати топологію GPU (лінки, афінітет NUMA)

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

Що це означає: «NV4» вказує на клас високошвидкісного зв’язку GPU‑GPU; CPU/NUMA афінітет показує, які сокети «ближчі».

Рішення: Якщо афінітет CPU перетинає сокети несподівано — прив’яжіть задачу до найближчого NUMA‑вузла та поміряйте знову.

Завдання 3: підтвердити ширину/швидкість PCIe для кожного GPU

cr0x@server:~$ sudo lspci -s 41:00.0 -vv | egrep -i "LnkCap|LnkSta"
LnkCap: Port #0, Speed 16GT/s, Width x16
LnkSta: Speed 16GT/s (ok), Width x16 (ok)

Що це означає: Якщо лінк натренований на нижчу швидкість (x8, нижчий GT/s), хости-пристрій передачі й деякі шляхи peer постраждають.

Рішення: Будь‑яке «(downgraded)» або зменшена ширина: ізолюйте вузол, перевірте BIOS/прошивку, перемонтуйте riser‑и/кабелі якщо доречно.

Завдання 4: інспектувати NUMA‑топологію з ОС

cr0x@server:~$ numactl -H
available: 2 nodes (0-1)
node 0 cpus: 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15
node 0 size: 256000 MB
node 1 cpus: 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31
node 1 size: 256000 MB

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

Рішення: Прив’яжіть CPU‑потоки і розподіли хост‑пам’яті до NUMA‑вузла, що ближчий до GPU(ів).

Завдання 5: перевірити статус IOMMU (може впливати на DMA)

cr0x@server:~$ cat /proc/cmdline
BOOT_IMAGE=/vmlinuz root=/dev/nvme0n1p2 ro iommu=pt intel_iommu=on

Що це означає: «iommu=pt» зазвичай зменшує витрати на трансляцію для DMA пристроїв.

Рішення: Якщо бачите строгий IOMMU при інтенсивних DMA‑навантаженнях — тестуйте passthrough режим у вікні технічного обслуговування.

Завдання 6: спостерігати такти GPU, споживання енергії і причини тротлінгу

cr0x@server:~$ nvidia-smi -q -d CLOCK,POWER,PERFORMANCE | egrep -i "Clocks|Power Draw|Perf|Throttle"
Performance State                  : P0
Power Draw                         : 612.45 W
Clocks
    Graphics                        : 1410 MHz
    SM                              : 1410 MHz
    Memory                          : 1593 MHz
Clocks Throttle Reasons
    Thermal Slowdown                : Not Active
    Power Brake Slowdown            : Not Active

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

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

Завдання 7: перевірити лічильники ECC (ранній сигнал про хворі лінки/пам’ять)

cr0x@server:~$ nvidia-smi -q -d ECC | egrep -i "Volatile|Uncorr|Corr"
Volatile Uncorr. ECC                    : 0
Volatile Corr. ECC                      : 12

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

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

Завдання 8: підтвердити peer-to-peer доступ між GPU

cr0x@server:~$ nvidia-smi topo -p2p r
GPU0 GPU1
GPU0  X   OK
GPU1 OK   X

Що це означає: «OK» вказує, що P2P підтримується/увімкнений; якщо «N/A» або «Disabled», перехід між пристроями йде через хост.

Рішення: Якщо P2P недоступний несподівано — перевірте налаштування BIOS (ACS), параметри драйвера і привілеї контейнера.

Завдання 9: виміряти локальний vs віддалений доступ мікробенчмарком (швидка санітарка)

cr0x@server:~$ /usr/bin/time -f "elapsed=%e" python3 -c 'import torch; a=torch.randn(8192,8192,device="cuda"); b=a.t().contiguous(); torch.cuda.synchronize()'
elapsed=0.41

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

Рішення: Якщо варіація велика — зафіксуйте афінітет процесу і контроль аллокатора; потім порівняйте знову.

Завдання 10: захопити завантаження GPU і пропускну здатність пам’яті в часі

cr0x@server:~$ nvidia-smi dmon -s pucvmt -d 1 -c 5
# gpu  pwr  u  c  v  m  t
# Idx  W    %  %  %  %  C
0      610  85 99  0  72 68
0      612  83 99  0  73 69
0      608  40 98  0  70 69
0      611  86 99  0  72 68
0      613  84 99  0  73 69

Що це означає: Провал у завантаженості при стабільних тактах може вказувати на стади (часто пам’ять/інтерконект).

Рішення: Скоординуйте провали з таймлайном кернелів; якщо відсоток пам’яті залишається високим, а обчислення падає — підозрюйте віддалений доступ або контенцію.

Завдання 11: перевірити, чи контейнер бачить очікувані пристрої і топологію

cr0x@server:~$ nvidia-container-cli info | egrep -i "NVRM|CUDA|Device Index"
NVRM version:   550.54
CUDA version:   12.4
Device Index:   0
Device Index:   1

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

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

Завдання 12: перевірити логи ядра і PCIe/AER на нестабільність лінків

cr0x@server:~$ sudo journalctl -k -S -2h | egrep -i "AER|pcie|Xid|NVRM" | tail -n 8
Jan 21 09:12:01 server kernel: pcieport 0000:40:01.0: AER: Corrected error received: id=00e0
Jan 21 09:12:01 server kernel: pcieport 0000:40:01.0: PCIe Bus Error: severity=Corrected, type=Physical Layer, (Receiver ID)
Jan 21 09:12:02 server kernel: NVRM: Xid (PCI:0000:41:00): 48, pid=29133, errorString=Double Bit ECC Error

Що це означає: Corrected AER‑спам плюс Xid GPU — сигнал про ризик надійності. Чіплетні лінки можуть підвищити чутливість.

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

Завдання 13: підтвердити афінітет CPU запущеної задачі

cr0x@server:~$ ps -o pid,psr,comm -p 29133
  PID PSR COMMAND
29133  27 python3

Що це означає: Процес наразі запланований на CPU‑ядеро 27 (ймовірно NUMA‑вузол 1 в прикладі вище).

Рішення: Якщо GPU ближчий до NUMA‑вузла 0 — зафіксуйте процес/потоки на вузол 0 і перевірте ще раз.

Завдання 14: застосувати NUMA‑прив’язку для ранного прогону бенчмарку

cr0x@server:~$ numactl --cpunodebind=0 --membind=0 python3 -c 'import os; print("ok");'
ok

Що це означає: Ви можете форсувати локальність для CPU і розподілів хост‑пам’яті.

Рішення: Якщо час кроку покращився і варіація знизилась — ваше вузьке місце включає локальність на боці хоста (часто пропускають у дискусіях «тільки GPU»).

Швидка діагностика — план дій

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

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

• Перевірте такти і причини тротлінгу (Завдання 6).
• Перевірте ширину/швидкість PCIe і AER‑логи (Завдання 3 і 12).
• Перевірте лічильники ECC (Завдання 7).

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

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

• Звіт топології GPU (Завдання 2).
• OS‑топологія NUMA (Завдання 4).
• Доступність P2P (Завдання 8).
• Видимість контейнера (Завдання 11).

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

Третє: скорелюйте продуктивність з фазами і контенцією

• Запустіть простий мікробенчмарк багаторазово і шукайте бімодальність (Завдання 9).
• Захопіть чассерію завантаження/пам’яті під час повільного прогону (Завдання 10).
• Прив’яжіть NUMA і порівняйте (Завдання 13–14).

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

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

1) Симптом: бімодальний час кроку (швидкі/повільні запуски чергуються)

Корінь: розміщення пам’яті або планувальник нестабільні; гарячі дані іноді опиняються «віддаленими» від виконавчого чіплета.

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

2) Симптом: висока завантаженість GPU, низька пропускна здатність

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

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

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

Корінь: змінилися евристики планування; нові за замовчуванням для P2P, поведінки на кшталт MIG, або політики алокації пам’яті.

Виправлення: A/B‑тест драйверів; зафіксуйте відому‑добру версію для продакшну; документуйте версії, валідовані під ваші патерни навантаження.

4) Симптом: інколи Xid помилки під великим навантаженням, зникають після перезавантаження

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

Виправлення: перевірте AER і тренди ECC; ізолюйте вузол; оновіть прошивку; перевірте охолодження та подавання енергії; замініть підозрілі компоненти.

5) Симптом: пропускна здатність декількох процесів колапсує при увімкненні перекриття/пефетчу

Корінь: самозаподіяний колапс конгестії на міжчіплетному fabric через занадто багато in-flight трансферів.

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

6) Симптом: «P2P підтримується», але трансфери все одно повільні

Корінь: P2P існує, але маршрутизовано повільнішим шляхом (наприклад, інший клас лінка), або ACS/IOMMU налаштування змушують об’їзд.

Виправлення: перевірте топологію, налаштування PCIe, і виміряйте ефективну пропускну здатність; не припускайте, що «OK» означає «достатньо швидко».

7) Симптом: P99 інференсу стрибає без насичення CPU

Корінь: арбітраж fabric, треш кешів між чіплетами або контенція від фонових DMA.

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

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

Чеклист при закупівлі (перед покупкою флоту)

1. Вимагайте деталі топології: скільки плит, як прикріплено HBM і чи ховає «один пристрій» NUMA‑поведінку.
2. Запитайте про поведінку інтерконекту під контенцією: що відбувається, коли змагаються кілька рушіїв (обчислення, DMA, колективи).
3. Перевірте зрілість драйвера: вимагаєте версію, яку можна зафіксувати, і канал підтримки для регресій продуктивності.
4. Тестуйте ваші найгірші кернелі: не лише GEMM; включіть embedding‑и, scatter/gather, атомарні та нерегулярні доступи.
5. Вимагайте телеметрію: лічильники стану лінків, виправлені помилки і будь‑яка поведінка авто-дауншифта.

Чеклист при запуску обладнання в датацентрі

1. Зняти базову лінію ширини/швидкості PCIe на кожному вузлі (Завдання 3) і зберегти її.
2. Записати топологію GPU (Завдання 2) і переконатися, що вона відповідає очікуваній конфігурації SKU.
3. Перевірити ECC‑базу в стані простою і після burn‑in (Завдання 7).
4. Запустити набір мікробенчмарків локальності, щоб виявити «віддалені» штрафи (повторити Завдання 9 і ваші власні).
5. Переконатися, що рантайм контейнера бачить правильні пристрої (Завдання 11).
6. Налаштувати алерти на AER, Xid і тренди виправлених ECC (Завдання 12 + збір метрик).

Чеклист триажу продуктивності (коли робота повільна)

1. Підтвердити стан вузла: тротлінг, тренування лінків, ECC (Завдання 6, 3, 7).
2. Захопити топологію і афінітет: GPU topo, NUMA, афінітет CPU (Завдання 2, 4, 13).
3. Перезапустити з NUMA‑прив’язкою і порівняти (Завдання 14).
4. Захопити чассерію завантаження (Завдання 10) під час повільної фази.
5. Зменшити конкуренцію: запустити самостійно на вузлі, щоб побачити, чи це через контенцію.
6. Змінювати одну змінну за раз: розмір батчу, налаштування перекриття, поведінку аллокатора, версія драйвера.

Чеклист проєктування (для інженерів, що пишуть кернелі/моделі)

1. Припускайте NUMA: тримайте гарячі дані близько до обчислення, що їх використовує.
2. Мінімізуйте тонкі атомарні операції та синхронізацію між чіплетами.
3. Надавайте перевагу масовим трансферам над ping‑pong трафіком.
4. Вимірюйте штрафи локальності явно; не покладайтеся на маркетингову риторику «уніфікованої пам’яті».
5. Проєктуйте для передбачуваного розміщення: стабільне шардування кращe за хитрий динамічний міграційний підхід у продакшні.

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

1) Чи чіплетні GPU — це фактично те саме, що multi‑GPU?

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

2) Якщо вендор показує уніфікований простір адрес, навіщо турбуватися про локальність?

Тому що уніфікований простір адрес — про зручність, не про фізику. Якщо якась пам’ять на один інтерконект‑хоп далі, вартість доступу змінюється. Для кернелів з високою пропускною здатністю «один хоп» — різниця між піком і плато.

3) Які робочі навантаження найгірше страждають на чіплетних дизайнах?

Нерегулярні доступи до пам’яті, embedding‑и, scatter/gather, графові навантаження, тонкозернинна синхронізація, ядра з великою кількістю атомарних операцій і все, що часто змушує cacheline‑и «скакати» між кристалами.

4) Які робочі навантаження отримують найбільшу вигоду?

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

5) Це головно апаратна проблема чи програмна?

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

6) Як чіплети впливають на налагодження і спостережуваність?

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

7) Чи слід уникати чіплетних GPU для продакшну сьогодні?

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

8) Який перший операційний контроль варто впровадити?

Планування, що знає топологію. Якщо ваш планувальник кластера не може розміщати задачі з афінітетом GPU/CPU і ізолювати галасливих сусідів, ви проведете своє життя, пояснюючи джиттер.

9) Чи «контенція fabric» насправді вимірювана?

Іноді безпосередньо через лічильники вендора, часто — опосередковано через аналіз таймлайну і контрольовані експерименти: запустіть single‑tenant vs multi‑tenant, увімкніть/вимкніть перекриття і подивіться, як змінюється час кроку з конкуренцією.

10) Яке найпоширеніше хибне переконання?

Що «один GPU пристрій» означає «однорідну латентність і пропускну здатність». Саме це переконання приводить до розривів продуктивності, що здаються надприродними.

Висновок: практичні подальші кроки

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

Наступні кроки, які справді працюють у продакшні:

• Побудуйте базу топології для кожного вузла: швидкості лінків, афінітет NUMA, статус P2P, лічильники ECC.
• Зробіть планувальник обізнаним про топологію: колокатуйте CPU‑потоки і пам’ять з GPU, які вони живлять, і ізолюйте робочі навантаження, що конфліктують на fabric.
• Ранньо вимірюйте чутливість до локальності: додавайте мікробенчмарки і «детектори бімодальності» в кваліфікацію, а не в постмортем.
• Контролюйте конкуренцію і перекриття: лімітуйте in‑flight трансфери і не припускайте, що більше перекриття — це завжди більше продуктивності.
• Зафіксуйте і документуйте версії драйверів: розглядайте драйвер/рантайм як частину апаратного набору, бо для чіплетів він фактично є ним.

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