HBM пояснено: чому пам’ять стала вертикальною

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

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

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

HBM (High Bandwidth Memory) — відповідь індустрії на просте, але жорстке обмеження: неможливо нескінченно розширювати й прискорювати зовнішню пам’ять без перетворення плати на обігрівач і команди сигнал-інтегриті в штатних психологів. Тому пам’ять пішла вертикально — буквально укладається в стеки, щоб стати ближчою, ширшою й енергоефективнішою.

Яку проблему насправді вирішує HBM

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

Раніше ми боролися очевидним способом: піднімали тактові частоти DRAM і робили шину ширшою. Проблема в тому, що високошвидкісний I/O поза пакетом — неприємна справа. На великому масштабі ви боретесь із:

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

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

Головна ідея: HBM — про щільність пропускної здатності й енергоефективність, а не про якусь магічну DRAM. Та сама фізика DRAM, розумніша розводка.

Чому «вертикально» перемогло: фізика, пакування й енергія

«Іти вертикально» звучить як маркетинг, поки не подивишся на обмеження. «Традиційний» DRAM-пакет розміщує біти горизонтально: кілька дискретних чипів навколо GPU, кожен зі своїм високошвидкісним інтерфейсом. HBM укладає кілька пластин DRAM вертикально і спілкується з ними через TSV (Through-Silicon Vias). Це вирішує дві проблеми одночасно:

1) Розширити шину без апокаліпсису маршрутизації

HBM використовує надзвичайно широкі інтерфейси (думайте про тисячі бітів по всіх каналах). Ширша шина означає більше пропускної здатності при нижчій частоті. Нижча частота означає простіше сигнальне відтворення і менше I/O-споживання. І через те, що міжз’єднання короткі й щільні (мікророзплави на інтерпозері замість дюймів друкованої доріжки), зазори значно дружніші.

2) Знизити енергію на біт

Пропускна здатність без енергоефективності — просто інший тип відключення. Високошвидкісний I/O поза пакетом коштує багато енергії на біт. Коротке з’єднання HBM і нижча швидкість сигналів значно зменшують ці витрати. У реальних розгортаннях це часто означає: за тієї ж пропускної здатності прискорювачі на HBM дають кращу продуктивність на ват або ту саму продуктивність при нижчому ліміті потужності.

3) Тримати GPU підживленим під тривалим навантаженням

Тривале навантаження — тут ховаються неправди. Бенчмарки на 30 секунд можуть приховувати теплову чи енергетичну поведінку; виробничі запуски — ні. Пропускна здатність HBM допомагає при великих батчах, щільній лінійній алгебрі з великими активаціями або при пам’ятево-обмежених ядрах, що постійно завантажують канали HBM.

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

Жарт №1: HBM — це те, що відбувається, коли PCB каже «ні», фізика каже «ні», а продуктовий менеджер каже «все одно відвантажуємо».

Як працює HBM: стеки, TSV і широкі інтерфейси

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

Ментальна модель, яка не підведе

Стек: кілька пластин DRAM + базовий/логічний кристал.
TSV: вертикальні зв’язки через силікон, які дозволяють щільне з’єднання всередині стеку.
Канали: HBM експонує кілька незалежних каналів (і псевдо-каналів у нових поколіннях) для паралелізму.
Інтерпозер: силіконовий «маршрутизуючий шар», що з’єднує GPU і стеки пам’яті багатьма короткими проводами.

Суть не в тому, що TSV самі по собі дуже швидкі. Суть у тому, що стек плюс інтерпозер дають інтерфейс одночасно широкий, короткий і енергообґрунтований. Поєднання, яке важко отримати з дискретними чипами пам’яті навколо GPU.

Математика пропускної здатності без водевільу

Пропускна здатність приблизно: bus_width_bits × data_rate, мінус протокольні та планувальні накладні витрати. GDDR зазвичай женеться за високими швидкостями даних по вужчих шинах. HBM прагне широких шин при нижчих швидкостях. У будь-якому разі ви отримуєте пропускну здатність, але фізичні витрати різні:

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

HBM — по суті ставка на те, що просунуте пакування дешевше, ніж перетворювати всю вашу плату на високочастотний RF-проєкт.

Затримка: те, що люди неправильно розуміють

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

Якщо взяти одне на розгляд на архітектурних рев’ю: HBM — це гра за пропускну здатність і енергію, а не чудо затримки.

HBM проти GDDR: компроміси, які ви відчуваєте в продакшені

HBM і GDDR — обидва валідні відповіді на питання «як підключити багато пропускної здатності до великого чипа?». Вони просто платять різні рахунки.

Де перемагає HBM

Щільність пропускної здатності: багато ГБ/с у невеликому фізичному об’ємі.
Пропускна здатність на ват: особливо важливо, коли обмеження — енергетичний конверт стійки.
Короткі з’єднання: менше високошвидкісних проблем на рівні плати.

Де перемагає GDDR

Вартість і доступність: зазвичай простіше пакування і ширше постачання.
Гнучкість масштабування ємності: виробники плат іноді можуть додати більше чипів пам’яті простіше, ніж переробляти інтерпозер.
Ремонтопридатність і варіанти: менше екзотичних кроків пакування означає більше SKU-гнучкості.

Неприємний компроміс: ємність vs пропускна здатність vs вартість

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

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

Жарт №2: Відділ закупівель любить HBM, бо воно вчить усіх різниці між «прайс-листом» і «доступно цього кварталу».

Режими відмов: що ламається, як це виглядає, чому це важливо

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

Терміка: стеки не люблять сауни

Укладання пластин підвищує щільність потужності. Охолодження має бути відмінним і послідовним. Коли воно не таким, ви побачите:

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

Живлення: тихий вбивця пропускної здатності

Інтерфейси HBM широкі й активні. Погане живлення або надто агресивні ліміти потужності можуть зменшити частоту пам’яті або змусити GPU віддати пріоритет стабільності. Результат не завжди крах. Він гірший: постійне уповільнення на 8–15%, про яке ви будете сперечатися тижнями.

Міжз’єднання й вихідність упаковки: плата за стильність

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

Невідповідність програмного забезпечення: апарат хороший, а стек — ні

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

Цікаві факти та коротка історія (те, що люди забувають)

HBM стандартизовано JEDEC, що важливо, бо це сприяло узгодженості екосистеми щодо інтерфейсів і тестування.
Перші великі комерційні перемоги були в GPU, бо графіка й обчислення люблять пропускну здатність і можуть оплатити пакування.
2.5D інтерпозери були ключовим фактором: без щільних коротких з’єднань широка шина HBM була б непрактичною.
TSV досліджували роками до HBM; укладання логіки й пам’яті мав довгий шлях від «крутої демонстрації» до реального продукту.
Пропускна здатність на ват стала заголовним показником, коли обмеження дата-центрів по потужності загострилися; HBM виграв від цього безпосередньо.
HBM еволюціонував із псевдо-каналами й більшою паралельністю, щоб покращити ефективність при змішаних шаблонах доступу.
Ємність спочатку відставала від пропускної здатності, що вплинуло на продуктові рішення для моделей з великим слідом пам’яті.
Пакування й ланцюги постачання — стратегічні: доступність HBM кілька разів визначала, які SKU прискорювачів з’являться в значущому обсязі.
ECC стало обов’язковим у дата-центрах, і реалізації HBM часто інтегрують міцні RAS-фічі, бо безшумна корупція — це шлях до проблем у кар’єрі.

Три корпоративні міні-історії (анонімізовані, болісно знайомі)

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

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

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

Неправильне припущення було тонким: «Якщо GPU не логує ECC-помилок, пам’ять в порядку». На цій платформі секція за замовчуванням не експортувала коректовані лічильники ECC HBM у їхню систему моніторингу. Вони сигналили лише про фатальні Xid-події.

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

Справжній урок: ставтесь до «немає звітів про помилки» як до «немає звітів про помилки», а не «помилок немає». З HBM терміка може довести до тихих проблем коректності задовго до краху системи.

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

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

Потім почався продакшн. Кластер працював у змішаному режимі — тренування плюс інференс плюс ETL. Нові налаштування спричинили тиск на хост-пам’ять, частіше звільнення сторінок і зростання PCIe-переносів, коли зафіксовані буфери не вдавалося розмістити чисто. Деякі задачі почали підлагувати: GPU кілька секунд працював на повну, потім зависав у очікуванні входу.

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

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

Урок: якщо ви оптимізуєте використання HBM ігноруючи решту системи, ви можете перетворити проблему пропускної здатності на проблему потужності й планування. Це не виграш. Це перекладання проблеми.

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

Інша організація керувала кластерами HPC/AI, багатими на HBM, з звичкою, яка виглядала старомодно: кожен вузол мав «золоту базову лінію» продуктивності. Не трофейний бенчмарк. Набір повторюваних лічильників: тест пропускної здатності пам’яті, стійкий GEMM-тест, терміка під навантаженням і базовий рівень ECC-помилок. Вони зберігали це з прив’язкою до серійних номерів обладнання.

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

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

Вони замінили вентилятори, відкоригували криву, і варіативність зникла. Жодного драматичного простою. Жодного ескалації до керівництва. Просто надійність через рутину.

Урок: з HBM послідовність — це продуктивність. Нудні базові лінії — це те, як ви її купуєте.

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

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

Завдання 1: Ідентифікувати GPU і підтвердити наявність HBM

cr0x@server:~$ nvidia-smi -L
GPU 0: NVIDIA H100 SXM (UUID: GPU-aaaaaaaa-bbbb-cccc-dddd-eeeeeeeeeeee)
GPU 1: NVIDIA H100 SXM (UUID: GPU-ffffffff-1111-2222-3333-444444444444)

Що це означає: частини класу «SXM» зазвичай працюють із HBM; варіанти PCIe можуть відрізнятися. Це підказує, з яким класом апаратури ви маєте справу.

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

Завдання 2: Перевірити заявлений розмір пам’яті й чи поводиться він як HBM

cr0x@server:~$ nvidia-smi --query-gpu=name,memory.total --format=csv
name, memory.total
NVIDIA H100 SXM, 81920 MiB
NVIDIA H100 SXM, 81920 MiB

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

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

Завдання 3: Пошук причин тротлінгу (потужність/терміка), що можуть вражати такти пам’яті

cr0x@server:~$ nvidia-smi -q -d PERFORMANCE | sed -n '1,120p'
==============NVSMI LOG==============
Timestamp                                 : Sat Jan 13 12:15:03 2026
Driver Version                            : 550.54
CUDA Version                              : 12.4

Performance State                         : P0
Clocks Throttle Reasons
    Idle                                  : Not Active
    Applications Clocks Setting           : Not Active
    SW Power Cap                          : Active
    HW Slowdown                           : Not Active
    HW Thermal Slowdown                   : Not Active
    Sync Boost                            : Not Active
    SW Thermal Slowdown                   : Not Active

Що це означає: «SW Power Cap: Active» вказує, що GPU обмежений програмним лімітом потужності; це може зменшити ефективну пропускну здатність пам’яті.

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

Завдання 4: Спостерігати за завантаженням пам’яті й лічильниками пропускної здатності в реальному часі

cr0x@server:~$ nvidia-smi dmon -s pucm -d 1 -c 5
# gpu   pwr  temp   sm   mem   enc   dec  mclk  pclk
# Idx     W     C    %    %     %     %   MHz   MHz
    0   608    74   85   92     0     0  3200  1410
    0   612    75   83   93     0     0  3200  1410
    0   615    76   82   94     0     0  3200  1410
    0   620    77   80   95     0     0  3200  1410
    0   622    78   79   96     0     0  3200  1410

Що це означає: Високий mem з падінням sm часто вказує на пам’ятево-обмежені ядра. Такти пам’яті (mclk) що лишаються високими — ознака відсутності тротлінгу пам’яті в цю хвилину.

Рішення: Якщо mclk падає під тривалим навантаженням, перевірте терміку/потужність. Якщо mem низький, але час кроку високий, вузьке місце може бути в іншому місці (CPU-стаджинг, PCIe/NVLink, синхронізація).

Завдання 5: Перевірити режим ECC і лічильники помилок (коректність HBM і раннє попередження)

cr0x@server:~$ nvidia-smi -q -d ECC | sed -n '1,160p'
ECC Mode
    Current                               : Enabled
    Pending                               : Enabled

ECC Errors
    Volatile
        Single Bit
            Device Memory                 : 12
        Double Bit
            Device Memory                 : 0
    Aggregate
        Single Bit
            Device Memory                 : 128
        Double Bit
            Device Memory                 : 0

Що це означає: Існують коректовані помилки. Агреґовані лічильники показують довготермінову поведінку; volatile — нещодавню. Подвійні помилки серйозніші.

Рішення: Зростання коректованих помилок у зв’язці з температурою/навантаженням — сигнал обслуговування: перевірте охолодження, посадку, прошивку і розгляньте виведення вузла на прогрівання.

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

cr0x@server:~$ nvidia-smi --query-gpu=clocks.current.graphics,clocks.current.memory,clocks.applications.graphics,clocks.applications.memory --format=csv
clocks.current.graphics, clocks.current.memory, clocks.applications.graphics, clocks.applications.memory
1410 MHz, 3200 MHz, 1500 MHz, 3200 MHz

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

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

Завдання 7: Підтвердити підключення NVLink/NVSwitch (багато-GPU пропускна здатність може маскуватися як «HBM повільна»)

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

Що це означає: GPU підключені через NVLink (NV4 вказує на кілька лінків). Якби було «PHB» або «SYS», часто використовувався б PCIe/хост-шлях.

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

Завдання 8: Перевірити ширину/швидкість лінку PCIe (передачі хост→пристрій)

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

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

Рішення: Якщо бачите x8 замість x16 — пересідайте, перевірте налаштування BIOS ASPM, огляньте riser-и й перевірте проводку слотів материнської плати.

Завдання 9: Перевірити розташування CPU NUMA і чи ваш процес неправильно зафіксований

cr0x@server:~$ lscpu | egrep 'NUMA node|Socket|CPU\(s\)'
CPU(s):                               128
Socket(s):                            2
NUMA node(s):                         2
NUMA node0 CPU(s):                    0-63
NUMA node1 CPU(s):                    64-127

Що це означає: У вас два NUMA-вузли. Подача на GPU з «неправильного» CPU може додати затримки і зменшити ефективну пропускну здатність хост→пристрій.

Рішення: Якщо GPU приєднаний ближче до NUMA node1, а ваш даталоадер працює на node0, правильно зафіксуйте його (taskset/numactl) і переміряйте.

Завдання 10: Виміряти пропускну здатність хост-пам’яті і виявити вузьке місце на боці CPU

cr0x@server:~$ sudo apt-get -y install sysbench >/dev/null 2>&1
cr0x@server:~$ sysbench memory --memory-total-size=10G run | sed -n '1,25p'
sysbench 1.0.20 (using system LuaJIT 2.1.0-beta3)

Running the test with following options:
Number of threads: 1
Initializing random number generator from current time

Running memory speed test with the following options:
  block size: 1K
  total size: 10240MiB
  operation: write
  scope: global

Total operations: 10485760 ( 2074318.54 per second)

2048.00 MiB transferred (405.14 MiB/sec)

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

Рішення: Збільшіть кількість потоків, використайте кращий бенчмарк, і важливіше: якщо ваш вхідний конвеєр обмежений CPU, HBM не допоможе. Виправте конвеєр.

Завдання 11: Перевірити диск I/O латентність і пропускну здатність (бо «HBM повільна» часто означає «диск повільний»)

cr0x@server:~$ iostat -dx 1 3
Linux 6.5.0 (server) 	01/13/26 	_x86_64_	(128 CPU)

Device            r/s     rkB/s   rrqm/s  %rrqm r_await rareq-sz     w/s     wkB/s   w_await wareq-sz  aqu-sz  %util
nvme0n1         12.0    9800.0     0.0    0.0    3.20   816.7     45.0   72000.0    2.10  1600.0    0.10   8.0
nvme1n1          0.0       0.0     0.0    0.0    0.00     0.0      0.0       0.0    0.00     0.0    0.00   0.0

Що це означає: Низький await і низька завантаженість свідчать, що зберігання наразі не є вузьким місцем. Якщо await стрибає (десятки мс), ваш GPU може чекати на дані.

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

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

cr0x@server:~$ sudo dmesg -T | egrep -i 'nvrm|xid|nvlink' | tail -n 8
[Sat Jan 13 11:02:11 2026] NVRM: Xid (PCI:0000:3b:00): 31, pid=28419, Ch 0000002a, MMU Fault: ENGINE GRAPHICS
[Sat Jan 13 11:02:11 2026] NVRM: Xid (PCI:0000:3b:00): 45, pid=28419, Preemptive Channel Removal

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

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

Завдання 13: Підтвердити розміщення процесів і видимість GPU (уникнути випадкової конкуренції)

cr0x@server:~$ ps -eo pid,cmd | egrep 'python|torchrun|cuda' | head
28419 python train.py --config prod.yaml
29102 python inference_service.py --port 9000

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

Рішення: Забезпечте ізоляцію: cgroups, обмеження планувальника, MIG (якщо використовується) або виділити вузли під ролі.

Завдання 14: Перевірити CPU-тротлінг у cgroup (можливо, ваш даталоадер голодує)

cr0x@server:~$ cat /sys/fs/cgroup/cpu.stat 2>/dev/null || cat /sys/fs/cgroup/cpu/cpu.stat
usage_usec 983242341
user_usec  812341112
system_usec 170901229
nr_periods  220341
nr_throttled 18422
throttled_usec 992344121

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

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

Завдання 15: Швидка перевірка perf для виявлення пам’ятево-обмеженого CPU-препроцесінгу

cr0x@server:~$ sudo perf stat -p 28419 -e cycles,instructions,cache-misses -a -- sleep 5
 Performance counter stats for 'system wide':

     19,482,334,112      cycles
     21,104,993,881      instructions              #    1.08  insn per cycle
        982,334,112      cache-misses

       5.001234567 seconds time elapsed

Що це означає: Високі пропуски кешу з низьким IPC натякають, що CPU-сторона стоїть через пам’ять. Якщо препроцесінг обмежений пам’яттю, він може обмежувати GPU, незалежно від швидкості HBM.

Рішення: Зменште трафік пам’яті CPU (менше копій, кращі формати даних), додайте локальність (NUMA-пінгінг) або віднесіть декодування/аугментацію на інше обладнання.

Швидка методика діагностики

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

Перший крок: чи справді GPU обмежений пам’яттю?

Перевірте живе завантаження: nvidia-smi dmon -s pucm
Шукайте високий рівень пам’яті та відносно нижче завантаження SM під час фази уповільнення.
Якщо є, використайте профайлер і подивіться метрики «HBM throughput» або «dram_read/write throughput».

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

Другий крок: чи є тротлінг (потужність/терміка) і ви мовчки втрачаєте пропускну здатність?

nvidia-smi -q -d PERFORMANCE для причин тротлінгу
nvidia-smi dmon для падіння тактів пам’яті під навантаженням
Перевірте тренди температур і споживання потужності

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

Третій крок: чи вузьке місце вище за HBM?

Сховище: iostat, pidstat -d
CPU/NUMA: lscpu, numactl -H, cgroup-статистика
PCIe/NVLink: lspci, nvidia-smi topo -m

Рішення: Якщо джерело даних повільне, ваша HBM не має значення. Виправте джерело.

Четвертий крок: чи то вузол підозрілий, чи флот дрейфує?

Порівняйте з базовими лініями і сусідніми вузлами.
Перевірте тенденції ECC-помилок по вузлах.
Перевірте однорідність прошивок/драйверів.

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

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

1) Симптом: низьке завантаження GPU, але високе завантаження пам’яті

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

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

2) Симптом: пропускна здатність хороша перші 2 хвилини, потім падає і лишається низькою

Корінна причина: Тротлінг по терміці або потужності, що впливає на такти пам’яті або загальні такти GPU.

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

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

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

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

4) Симптом: тренування іноді дає NaN, немає очевидної помилки в ПЗ

Корінна причина: Нестабільність пам’яті, про що сигналізує зростання коректованих ECC-помилок, часто посилена термікою; або агресивні оверклок/прикладні такти.

Виправлення: Моніторте лічильники ECC, знизьте такти до стандартних, виправте охолодження, запустіть прогрівання і під карантинте уражені вузли.

5) Симптом: масштабування на кілька GPU погане; на одному GPU все нормально

Корінна причина: Вузьке місце інтерконекту (шлях через PCIe замість NVLink), неправильне NUMA-розміщення або патерн all-reduce, що обмежений мережею.

Виправлення: Перевірте топологію, забезпечте правильну локальність NIC/GPU, підтвердіть статус NVLink і налаштуйте параметри комунікації окремо від питань HBM.

6) Симптом: час копіювання пам’яті високий, але HBM має велику пропускну здатність

Корінна причина: Ви вимірюєте хост→пристрій передачі (PCIe/NVLink), а не пропускну здатність HBM на пристрої.

Виправлення: Розділіть метрики: пропускна здатність HBM — на пристрої. H2D/D2H — це шина/інтерконект. Оптимізуйте потрібний шлях.

7) Симптом: «ми перейшли на HBM GPU, нічого не прискорилося»

Корінна причина: Робоче навантаження обчислювально-обмежене, знаходиться в кеші або обмежено вхідним конвеєром, а не пропускною здатністю DRAM.

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

8) Симптом: випадкові зависання задач; GPU виглядає простим; CPU завантажений

Корінна причина: Проблеми з даталоадером/препроцесінгом або CPU-тротлінг у контейнерах.

Виправлення: Збільшіть виділення CPU, зафіксуйте на правильний NUMA-вузол, зменшіть препроцесінг та моніторьте cgroup-тротлінг.

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

Чек-лист: вибір HBM-апаратури (що вимагати перед покупкою)

Визначте вузьке місце: чи ваше навантаження обмежене пропускною здатністю? Доведіть це профілюванням.
Вимагайте стійкі бенчмарки: щонайменше 30–60 хвилин у реальних теплових умовах, а не коротке демо.
Запитайте про поведінку при лімітах потужності: як змінюється пропускна здатність при різних капах?
Підтвердіть телеметрію ECC: чи можете ви експортувати коректовані/некоректовані лічильники по GPU?
Перевірте топологію інтерконекту: NVLink/NVSwitch для багатогпу вузлів і локальність NIC для розподілених задач.
Плануйте постачання: припускайте час виконання й зміну SKU; проєктуйте планувальник для гетерогенності.

Чек-лист: введення HBM-кластера без жалю

Уніфікуйте версії драйверів і прошивок; заблокуйте їх у конфігураційному менеджменті.
Увімкніть і збирайте телеметрію GPU: температури, такти, причини тротлінгу, лічильники ECC.
Запустіть набір базових тестів на кожен вузол і зберігайте результати з серійними номерами.
Встановіть пороги оповіщення по: частоті тротлінгу, зміні рівня ECC і температурних відхиленнях серед сусідів.
Підтвердіть NUMA і PCIe/NVLink топологію і вбудуйте правильне пінгінг у runtime задач.
Зробіть тривалий тепловий прогін; відхиліть вузли, які дрейфують.

Покроково: коли користувач каже «HBM повільний»

Відтворіть на одному вузлі реальним запускам, а не мікробенчмарком.
Класифікуйте: пам’ятево-обмежено чи обчислювально-обмежено чи вхід-обмежено за живими лічильниками.
Перевірте тротлінг: причини потужності й терміки; підтвердіть такти пам’яті.
Перевірте джерело: латентність сховища, CPU-тротлінг, NUMA-пінгінг, тренінг PCIe-лінку.
Порівняйте з базою і сусідніми вузлами, щоб знайти дрейф обладнання.
Виправляйте на правильному рівні: спочатку охолодження/потужність, потім топологію/пінгінг, потім кернели/розміщення даних.

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

1) Чи HBM — це просто «швидша DRAM»?

Ні. Перевага HBM у пакуванні та інтерфейсі: дуже широка шина, короткі з’єднання, нижча частота, краща пропускна здатність на ват.

2) Чи HBM зменшує затримку?

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

3) Чому ми не можемо просто продовжувати використовувати GDDR і підвищувати частоту?

Можна, і так роблять. Але підвищення швидкостей даних по довших платах підвищує складність сигнальної цілісності й енергоспоживання I/O. HBM переміщує проблему в пакування, де інтерконект короткий і щільний.

4) Чому в мене величезна пропускна здатність HBM, але memcpy з хосту все одно повільний?

Бо копіювання хост→пристрій іде по PCIe або NVLink. Пропускна здатність HBM знаходиться на пристрої. Якщо ви стажуєте багато даних з хосту на крок, полагодьте шлях введення (кешування, більші батчі, кращий оверлап, більш швидкий інтерконект).

5) Чи HBM полегшує масштабування на кілька GPU?

Воно допомагає кожному GPU бути менш голодним, але масштабування зазвичай обмежують топологія інтерконекту, ефективність колективів і мережа. HBM не замінює хороший NVLink/NVSwitch або розумну конфігурацію all-reduce.

6) Яка найпоширеніша операційна проблема з HBM-системами?

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

7) Чи варто вимикати ECC заради продуктивності?

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

8) Як зрозуміти, чи моє навантаження виграє від HBM?

Профілюйте: якщо ви близькі до насичення пропускної здатності DRAM пристрою і завантаження SM обмежене пам’яттю — HBM допоможе. Якщо ви обчислювально-обмежені або обмежені входом — не допоможе.

9) Чому постачання HBM часто обмежене порівняно з іншою пам’яттю?

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

10) Чи «більше HBM-ємності» завжди краще?

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

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

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

Встановіть базові лінії для кожного вузла (пропускна здатність, терміка, ECC) і порівнюйте їх щотижня.
Пінгуйте оповіщення по причині тротлінгу, а не тільки по крашах. Тротлінг — це інцидент продуктивності, навіть коли система «здоровa».
Розділяйте вузькі місця: пропускна здатність HBM, пропускна здатність інтерконекту, CPU-препроцесінг і сховище — це різні труби. Вимірюйте кожну.
Швидко ізолюйте викиди. Дебаг «радісної повільності» серед користувачів дорожчий, ніж вилучення одного підозрілого вузла.

Одна перефразована ідея, варта запису на стікері, приписувана John Allspaw: Надійність виникає з того, як системи поводяться в реальних умовах, а не з довіри до діаграми проєкту.