HBM у процесорах: коли пам’ять переміщується в пакет

Що фактично змінює HBM у процесорі

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

Коли HBM розміщується «на» CPU — зазвичай у тому ж пакеті, підключена короткими інтерконектами — три речі змінюються так, що оператори це помічають:

1) Пропускна здатність стає менш дефіцитною (поки не натрапите на наступну стіну)

Традиційні канали DDR покращувалися, але не в такому темпі, як кількість ядер і векторні блоки. HBM дає значно більше агрегованої пропускної здатності, що допомагає навантаженням,
які обмежені пропускною здатністю: стрімінгові аналітики, розріджена лінійна алгебра, великі сканування в пам’яті, векторний пошук і багато шаблонів inference для AI, що погано лягають в кеші.

2) Ємність стає більш дорогоцінною

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

3) NUMA стає дивнішим і важливішим

ОС часто показує HBM як окремий NUMA-вузол (або кілька вузлів). Це добре: це видно й керовано.
Це також погано: тепер ви можете випадково розмістити гарячі сторінки на повільному шарі, поки швидкий шар простоює — як зарезервований CPU в кластері Kubernetes, про який ніхто не просив.

Чому це відбувається зараз (і чому DDR не «падає»)

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

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

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

Цікаві факти та історія для планувальних нарад

• Факт 1: Проблема «memory wall» — коли швидкість CPU обганяє швидкість пам’яті — обговорюється з 1990-х і нікуди не поділася; її просто краще приховали кеші.
• Факт 2: HBM — це «3D-стекована DRAM», з’єднана через through-silicon vias (TSV), тому вона може відкривати дуже широкий інтерфейс без кошмару з конекторами.
• Факт 3: GPU прийняли HBM раніше, бо їхня пропускна здатність робить нестачу смішно помітною; CPU запізнилися частково через потребу в більших ємностях і ширшій сумісності навантажень.
• Факт 4: Багаторівневі системи пам’яті — не новина: мейнфрейми й деякі векторні системи використовували явні ієрархії пам’яті задовго до того, як сучасні сервери вдавали, що все плоске.
• Факт 5: Ранні експерименти з «пам’яттю в пакеті» показали повторювану тему: виграші в продуктивності реальні, але екосистема програмного забезпечення роками наздоганяє з розміщенням і налаштуванням.
• Факт 6: Сучасний Linux може показувати гетерогенну пам’ять як NUMA-вузли, даючи політику через numactl; складність у виборі політик, які не розваляться під навантаженням.
• Факт 7: Навантаження, що важко завантажують пропускну здатність, часто виглядають так, ніби «CPU зайнятий лише на 40%», що підштовхує людей масштабувати обчислення замість виправлення розміщення пам’яті.
• Факт 8: Вибір упаковки та пам’яті все більше пов’язаний з енергією: переміщення бітів через плату коштує енергії більше, ніж переміщення їх усередині пакета.
• Факт 9: Індустрія також просуває CXL для розширення та пулінгу пам’яті; HBM і CXL — це не стільки конкуренти, скільки різні відповіді на «швидко» проти «велике».

Чи стане пам’ять частиною пакета процесора?

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

Але «пам’ять стала частиною пакета» не означає «DIMM зникнуть». Це означає, що історія пам’яті стане багаторівневою:

• HBM на пакеті: невелика ємність, величезна пропускна здатність, відносно енергоефективно на біт, дорого за ГБ.
• DDR поза пакетом: велика ємність, хороша універсальна продуктивність, дешевше за ГБ, обмежене кількістю каналів і трасуванням на платі.
• Пам’ять поза хостом або пулінг (CXL): велика і гнучка, але з більшою затримкою; чудова для консолідації, але не для повного завантаження векторних блоків.

З системної точки зору: це не стільки «пам’ять переїхала в CPU», скільки «CPU отримав приватний буфет». Склад залишається — DDR.

Жарт №1: Якщо ви колись бачили, як CPU простоює через пам’ять, ви вже знаєте, що найшвидший компонент у сервері — це рахунок-фактура.

Затримка проти пропускної здатності: що часто плутають

Оператори люблять одне число. Пам’ять відмовляється підкорятися. Головний аргумент HBM — пропускна здатність, а не обов’язково нижча затримка, ніж у DDR у всіх випадках.
На практиці картина затримок залежить від реалізації, контролерів пам’яті та того, як ОС відображає сторінки.

Дві повторювані схеми відмов з’являються регулярно:

Навантаження, обмежені пропускною здатністю, що виглядають як CPU-завантажені

Конвеєр CPU «робить щось», але кількість виконаних інструкцій за такт низька. Ви додаєте ядра і майже не бачите зростання пропускної здатності.
HBM може вирішити це — якщо гарячі дані опиняться в HBM. Якщо ні, ви купили гоночний автомобіль і залили в нього бензин для газонокосарки.

Навантаження, чутливі до затримки, що ледь отримують вигоду

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

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

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

Моделі tiering HBM+DDR: кеш, NUMA-вузол чи явне розміщення

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

Модель A: HBM як прозорий кеш

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

Модель B: HBM як окремий NUMA-вузол («flat mode»)

Linux бачить HBM як окремий NUMA-вузол(и). Це режим зручний для оператора, бо ви можете прив’язувати процеси, задавати політику пам’яті й діагностувати розміщення.
Це також режим, у якому ви можете створити аварию однією єдиною скопійованою командою numactl.

Модель C: Розміщення, яким керує додаток

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

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

Які робочі навантаження отримують вигоду (а які ні)

Чудові кандидати

• Стрімінгові сканування та аналітика: колонкові сканування, конвеєри декомпресії, ETL-трансформації, що читають багато байтів і виконують помірну роботу на байт.
• Векторний пошук і операції з embedding: особливо коли робочий набір більший за кеш і доступи напівструктуровані.
• Наукові/HPC ядра: stencil-коди, FFT, варіанти лінійної алгебри і все, що історично скаржилося на пропускну здатність пам’яті.
• AI inference на CPU (в окремих випадках): не тому що CPU випереджає GPU, а тому що пропускна здатність може бути критичною, коли модель або активації важкі для пам’яті.

Маргінальні кандидати

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

Погані кандидати

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

Наслідки для SRE: нові вузькі місця, нові омани, нові дашборди

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

Зміни у плануванні ємності

Тепер ви плануєте дві ємності: загальна ОЗП (DDR+HBM) і «швидка ОЗП» (HBM).
Сервіс може «вміщатися в пам’ять» і одночасно «вистрибувати з HBM», що виглядає як регрес продуктивності без очевидного насичення ресурсів.

Зміни в обсервабельності

Потрібні метрики по вузлах NUMA, лічильники пропускної здатності (uncore/IMC) і статистика міграції сторінок, якщо платформа це підтримує.
Використання CPU вже не є навіть трохи достатнім.

Зміни в надійності

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

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

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

Перше: перевірте, що показує система

• Чи присутній HBM і видно як NUMA-вузли, чи він налаштований як кеш?
• Чи дійсно навантаження виділяє пам’ять з HBM, або просто «запущене на CPU, поруч із HBM»?

Друге: вирішіть, чи ви обмежені пропускною здатністю

• Перевірте лічильники пропускної здатності пам’яті та пропуски LLC.
• Шукайте низький IPC при високих затримках пам’яті.
• Підтвердіть, що додавання ядер не підвищує пропускну здатність.

Третє: підтвердіть розміщення і політику

• Перевірте використання пам’яті по NUMA-вузлах для процесу.
• Перевірте, чи автоматичне балансування NUMA не мігрувало сторінки з HBM.
• Підтвердіть афінність: прив’язка CPU без прив’язки пам’яті — напівзаходи.

Четверте: шукайте «наступну стіну»

• Міжсокетний трафік (remote NUMA), бурі когерентності кешу, контенція локів, вузькі місця PCIe.
• Якщо HBM допомагає трохи, але недостатньо, можливо, у вас змішані ліміти.

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

Це практичні завдання для on-call. Кожне містить команду, реалістичний вивід, що це означає, і яке рішення ви ухвалюєте.
Припущення: Linux-хост з root або sudo. Інструменти можуть вимагати пакетів, але самі команди стандартні та виконувані, де встановлені.

Завдання 1: Підтвердити топологію NUMA (чи взагалі у нас окремі вузли пам’яті?)

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

Що це означає: Два великі вузли і два менші вузли підказують про швидкий/малий шар (часто HBM) і великий шар (DDR), залежно від платформи.

Рішення: Визначте, які вузли — HBM, а які — DDR, перш ніж налаштовувати. Не прив’язуйтеся автоматично до «вузла 0» з інерції.

Завдання 2: Зіставити NUMA-вузли з типами пам’яті (DAX/pmem vs DRAM vs HBM-подібні)

cr0x@server:~$ for n in /sys/devices/system/node/node*; do echo "$n"; cat $n/meminfo | head -n 5; done
/sys/devices/system/node/node0
Node 0 MemTotal:       262144000 kB
Node 0 MemFree:        198930432 kB
Node 0 MemUsed:         63213568 kB
Node 0 Active:          21011200 kB
Node 0 Inactive:        18400320 kB
/sys/devices/system/node/node1
Node 1 MemTotal:       262144000 kB
Node 1 MemFree:        205019136 kB
Node 1 MemUsed:         57124864 kB
Node 1 Active:          20122304 kB
Node 1 Inactive:        17633280 kB
/sys/devices/system/node/node2
Node 2 MemTotal:        65536000 kB
Node 2 MemFree:         62691328 kB
Node 2 MemUsed:          2844672 kB
Node 2 Active:            412160 kB
Node 2 Inactive:          671744 kB
/sys/devices/system/node/node3
Node 3 MemTotal:        65536000 kB
Node 3 MemFree:         64513024 kB
Node 3 MemUsed:          1022976 kB
Node 3 Active:            210944 kB
Node 3 Inactive:          312320 kB

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

Рішення: Розглядайте node2/node3 як кандидати на HBM. Плануйте запуск тестових навантажень на них і вимірювання.

Завдання 3: Перевірити поточну політику NUMA для запущеного процесу

cr0x@server:~$ sudo cat /proc/12345/numa_maps | head -n 5
00400000 default file=/usr/bin/myservice mapped=4 N0=4
00a00000 default heap anon=512 N0=320 N2=192
7f2c84000000 default anon=2048 N1=2048
7f2c8c000000 interleave anon=4096 N2=2048 N3=2048

Що це означає: Хіп розподілено по вузлах, включно з N2/N3. Деякі відображення інтерлівовані.

Рішення: Якщо гаряча алокація не націлена в потрібний шар, відкоригуйте політику при запуску або алокатор. Не «оптимізуйте», прив’язуючи лише CPU.

Завдання 4: Підтвердити, чи автоматичне балансування NUMA мігрує сторінки

cr0x@server:~$ cat /proc/sys/kernel/numa_balancing
1

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

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

Завдання 5: Запустити навантаження, явно прив’язане до HBM-подібних вузлів (пам’ять + CPU)

cr0x@server:~$ numactl --cpunodebind=2 --membind=2 -- bash -lc 'python3 -c "a=bytearray(8*1024*1024*1024); print(len(a))"'
8589934592

Що це означає: Алокація вдалася на вузлі 2. Якщо вона завершується ENOMEM, ємність HBM менша, ніж ви припускали.

Рішення: Якщо вміщається — проводьте бенчмарки. Якщо ні — оберіть interleave або багаторівневу стратегію (гаряче в HBM, холодне в DDR).

Завдання 6: Швидко виміряти пропускну здатність пам’яті (smoke test, на зразок stream)

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

  42,118,443,002      cycles
  55,220,114,887      instructions              #    1.31  insn per cycle
     1,220,443,119      cache-misses
       410,221,009      LLC-load-misses

      10.003857036 seconds time elapsed

Що це означає: IPC ~1.31 з помітними пропусками LLC вказує на тиск пам’яті. Не остаточно, але це запах проблеми.

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

Завдання 7: Виявити віддалений доступ до NUMA (тихий податок затримки)

cr0x@server:~$ numastat -p 12345
Per-node process memory usage (in MBs) for PID 12345 (myservice)
Node 0          1200.45
Node 1          1188.20
Node 2           256.10
Node 3            12.05
Total           2656.80

Що це означає: Більшість пам’яті на Node0/Node1. Якщо потоки працюють на CPU Node2, ви платите за віддалений доступ.

Рішення: Узгодьте афінність CPU і пам’яті. Або перемістіть потоки під розміщення пам’яті, або мігруйте пам’ять під потоки.

Завдання 8: Перевірити афінність CPU для процесу (чи не загнали себе в кут?)

cr0x@server:~$ taskset -pc 12345
pid 12345's current affinity list: 16-23

Що це означає: Процес прив’язаний до CPU 16–23 (ймовірно node2). Якщо пам’ять на node0/1, віддалений трафік гарантований.

Рішення: Або підлаштуйте афінність під локальні DDR-вузли, або встановіть --membind/--preferred на node2, якщо це ваш HBM-ядро і ємності вистачає.

Завдання 9: Перевірити лічильники пропускної здатності/uncore через pcm (якщо встановлений)

cr0x@server:~$ sudo pcm-memory 1 -csv=/tmp/pcm.csv
PCM Memory Bandwidth Monitoring Utility
Time elapsed: 1.00 seconds
System Read Throughput(MB/s): 182400.12
System Write Throughput(MB/s): 62211.55

Що це означає: Пропускна здатність дуже висока; можливо, ви насичуєте DDR-канали або fabric. HBM має зменшити навантаження, якщо його використовувати правильно.

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

Завдання 10: Виявити усі збої сторінок і major faults (чи не підтороховуємо шари?)

cr0x@server:~$ pidstat -r -p 12345 1 5
Linux 6.5.0 (server)  01/12/2026  _x86_64_  (32 CPU)

12:01:11      UID       PID  minflt/s  majflt/s     VSZ     RSS   %MEM  Command
12:01:12     1000     12345   5020.00      0.00 28934144 2638820  8.12  myservice
12:01:13     1000     12345   4870.00      0.00 28934144 2638900  8.12  myservice

Що це означає: Високі minor faults нормальні під час алокації/first-touch; major faults вказували б на свопінг.

Рішення: Якщо major faults зростають у steady state, у вас проблеми з ємністю; HBM не допоможе, а іноді навіть загострить проблему.

Завдання 11: Перевірити статус transparent hugepages (THP може допомогти або зашкодити)

cr0x@server:~$ cat /sys/kernel/mm/transparent_hugepage/enabled
[always] madvise never

Що це означає: THP завжди ввімкнено. Це може покращити поведінку TLB для великих сканувань, але може також викликати спайки затримки через компактацію.

Рішення: Для сервісів, чутливих до затримки, розгляньте madvise і явну стратегію hugepage; для пакетних завдань, що навантажують пропускну здатність, always може бути прийнятним.

Завдання 12: Перевірити активність міграції сторінок (чи не скакають сторінки між шарами?)

cr0x@server:~$ grep -E 'pgmigrate|numa' /proc/vmstat | head
numa_pte_updates 18422011
numa_huge_pte_updates 11201
numa_hint_faults 920110
numa_hint_faults_local 610022
numa_pages_migrated 188440
pgmigrate_success 188102
pgmigrate_fail 338

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

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

Завдання 13: Підтвердити вільну пам’ять по вузлах перед примусовим membind (щоб уникнути OOM)

cr0x@server:~$ grep -H "MemFree" /sys/devices/system/node/node*/meminfo
/sys/devices/system/node/node0/meminfo:Node 0 MemFree:        198930432 kB
/sys/devices/system/node/node1/meminfo:Node 1 MemFree:        205019136 kB
/sys/devices/system/node/node2/meminfo:Node 2 MemFree:         62691328 kB
/sys/devices/system/node/node3/meminfo:Node 3 MemFree:         64513024 kB

Що це означає: Швидкі вузли мають значно менше вільної пам’яті. Жорстке --membind може впасти при навантаженні, хоча на машині досить DDR.

Рішення: Використовуйте --preferred або interleave для стійкості, якщо ви не впевнені, що алокації вміщуються в запас HBM.

Завдання 14: Швидко порівняти продуктивність: preferred vs interleave

cr0x@server:~$ /usr/bin/time -f "elapsed=%e cpu=%P" numactl --preferred=2 -- bash -lc 'dd if=/dev/zero of=/dev/null bs=1M count=4096 status=none'
elapsed=0.34 cpu=99%

cr0x@server:~$ /usr/bin/time -f "elapsed=%e cpu=%P" numactl --interleave=all -- bash -lc 'dd if=/dev/zero of=/dev/null bs=1M count=4096 status=none'
elapsed=0.52 cpu=99%

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

Рішення: Використовуйте preferred HBM для навантажень, що вимогливі до пропускної здатності, але перевіряйте стабільність під реальним тиском пам’яті.

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

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

Середня компанія перемістила latency-чутливий ранжувальний сервіс на нові хости, рекламовані як «HBM-enabled».
План міграції був простим: ті самі обмеження контейнерів, ті самі політики прив’язки CPU, та шаблон деплойменту. Швидший хардвер, той самий софт. Що може піти не так.

Перші кілька годин все виглядало добре. Потім p99 почав рости під час пікових трафіків, але завантаження CPU залишалося помірним.
Команда масштабувала горизонтально. Це трохи допомогло. Масштабували ще — допомогло менше. Тим часом використання пам’яті виглядало «в межах лімітів», і ніхто не бачив свопу.

Неправильне припущення: вони вірили, що HBM — прозорий кеш. На тій платформі його експонували як окремі NUMA-вузли,
і їхній деплоймент прив’язував CPU до «HBM-суміжного» вузла, в той час як алокації пам’яті за замовчуванням потрапляли до великого DDR-вузла через поведінку first-touch у warm-up-потоці.
Гарячі сторінки жили далеко, кожен запит платив віддаленим доступом, і міжз’єднання були перевантажені.

Виправлення було майже нудним: узгодити CPU і розміщення пам’яті, змінити warm-up щоб виконуватися на тому ж вузлі, що й обслуговуючі потоки, та використовувати --preferred замість жорсткого membind.
Продуктивність стабілізувалася одразу. Великий урок не в «HBM складний». Він у тому, що припущення про топологію — це продакшн-баги.

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

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

Для одного завдання бенчмарки були чудовими. Потім вони запустили два завдання на хості — і все впало.
Деякі запуски завершувалися помилкою out-of-memory, хоча на хості було багато DDR вільної. Інші «працювали», але були повільніші, ніж на старих хостах лише з DDR.

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

Виправили, трактуючи HBM як гарячий шар, а не весь будинок.
Вони тримали найгарячіший робочий набір у HBM, використовуючи preferred allocation, і відрегулювали конкурентність так, щоб агрегований гарячий набір вміщувався.
Задача трохи гірше показувала себе у одиночних бенчмарках, але значно швидше і надійніше працювала в продакшн-проході на вузол.

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

Команда платформи мала звичку, яку інженери любили кепкувати: для кожного нового класу апаратури вони проводили «нудний» комплект приймальних тестів.
Не набір красивих бенчів. Повторюваний чекліст: підтвердити топологію NUMA, перевірити саніті-пропускну здатність по вузлах, протестувати поведінку міграції сторінок, перевірити звіти ECC,
і зафіксувати базові показники під фіксованими версіями ОС і прошивки.

Коли перша партія HBM-серверів прибула, набір одразу виявив дивну річ: пропускна здатність одного NUMA-вузла була набагато нижчою за очікувану.
Хост не виглядав «зламаним». Ніяких помилок ядра. Ніяких очевидних термічних тривог. Просто повільніше, ніж мало б бути.

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

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

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

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

Корінь: Навантаження обмежене пропускною здатністю; ядра стоять у черзі через пам’ять або трафік когерентності.

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

2) Симптом: HBM-вузол має багато вільної пам’яті, але продуктивність не покращується

Корінь: Сторінки виділені в DDR через first-touch або поведінку алокатора; HBM не використовується.

Виправлення: Застосуйте numactl --preferred/--membind при запуску; перевірте, щоб warm-up виконувався на потрібному вузлі; валідируйте через /proc/<pid>/numa_maps.

3) Симптом: Раптові відмови алокацій (OOM) незважаючи на багато вільної ОЗП

Корінь: Жорстке прив’язування до невеликого HBM-слою; локальний вузол закінчився, хоча DDR має запас.

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

4) Симптом: p99 спайки з’являються після ввімкнення NUMA balancing

Корінь: Наклад витрат міграції сторінок, особливо з великими heap; ядро переміщує сторінки між шарами під навантаженням.

Виправлення: Налаштуйте або вимкніть NUMA balancing для конкретного сервісу; зробіть розміщення явним; зменшіть міграції, вирівнявши афінність CPU і політику пам’яті.

5) Симптом: Чудовий single-job бенчмарк, жахливе багатокористувацьке

Корінь: HBM — спільний обмежений шар; кілька задач витісняють або трешать гарячі сторінки одна одної.

Виправлення: Розділіть HBM за допомогою cgroup/NUMA-політик; плануйте менше завдань, що тиснуть на пропускну здатність, на хост; відокремлюйте шумних сусідів.

6) Симптом: Продуктивність погіршилась після переходу на великі сторінки

Корінь: Зростання витрат на компактацію/міграцію; фрагментація алокатора; невірна стратегія hugepage для патерну доступу.

Виправлення: Використовуйте madvise для THP; прив’язуйте huge pages лише для регіонів, що отримують вигоду; валідируйте по гістограмах затримки, а не по середніх показниках.

7) Симптом: Віддалений доступ до пам’яті зростає з часом, хоча афінність була встановлена

Корінь: Потоки мігрують, нові потоки стартують без прив’язки, або політика пам’яті успадковується непослідовно при exec/fork.

Виправлення: Запровадьте афінність на рівні менеджера сервісів; проаудіть створення потоків; перевіряйте після деплойту; валідируйте через numastat -p.

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

Покроковий план: оцінка HBM-хостів для навантаження

1. Класифікуйте навантаження: стрімінгове і пропускне? випадкове і чутливе до затримки? змішане? Якщо ви не можете класифікувати — ви ще не готові купувати залізо.
2. Підтвердіть, що апарат показує: перевірте, HBM в режимі кешу чи flat NUMA-вузлів. Зафіксуйте результат.
3. Отримайте базу на розміщенні в DDR: запустіть навантаження з обмеженням пам’яті до DDR-вузлів, щоб мати референс.
4. Тест preferred-розміщення в HBM: використайте --preferred перед тим, як застосовувати --membind.
5. Протестуйте поведінку при відмові: запустіть два інстанси на хості, потім три. Слідкуйте за ENOMEM і вибухами міграцій сторінок.
6. Перевірте віддалений доступ: підтвердіть, що афінність CPU і розміщення пам’яті залишаються вирівняними в steady state.
7. Слідкуйте за хвостовою затримкою: приймайте до уваги p99, а не лише середню пропускну здатність. Якщо міграції дають p99-спайки — це регресія.
8. Операціоналізуйте: впровадьте перевірки топології та валідацію розміщення в pipelines провізії та деплойменту.
9. Визначте політику планування: обмежуйте кількість bandwidth-heavy задач на хості; трактуйте HBM як квотований ресурс.
10. Виведіть дашборд: per-node використання пам’яті, міграції, індикатори віддаленого доступу та лічильники пропускної здатності мають бути видимі до першого інциденту.

Що робити і чого не робити для продакшну

• Робіть: трактуйте ємність HBM як жорстке виробниче обмеження. Відстежуйте її як дисковий простір.
• Робіть: перевіряйте розміщення через /proc/<pid>/numa_maps і numastat після деплойту.
• Робіть: починайте з --preferred, щоб уникнути крихких помилок алокації.
• Не робіть: не вважайте HBM «завжди швидшим». Деякі навантаження чутливі до затримки, а не до пропускної здатності.
• Не робіть: не прив’язуйте CPU без прив’язки пам’яті. Так ви створите віддалений доступ навмисно.
• Не робіть: не тестуйте лише single-tenant і не розгортайте в multi-tenant без повторного тестування. HBM змінює динаміку конкуренції.

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

1) Чи HBM у процесорах те саме, що «уніфікована пам’ять» у GPU?

Ні. GPU говорять про unified memory як про модель програмування між CPU/GPU адресними просторами. HBM у процесорах — це фізичний рівень пам’яті з іншим співвідношенням пропускної здатності/ємності,
зазвичай керований політиками ОС або алокаторами.

2) Чи HBM замінить DDR у серверах?

Не в широкому сенсі. HBM занадто дорогий за ГБ і занадто малий на сокет для загального флоту. Очікуйте гібридних систем: трохи HBM на пакеті плюс DDR для ємності.

3) Чи HBM завжди має нижчу затримку, ніж DDR?

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

4) Якщо я маю HBM, чи варто відключати CPU-кеші або змінювати налаштування кешу?

Ні. Кеші все ще важливі. HBM не замінює L1/L2/L3; він знижує тиск на підсистему пам’яті для даних, що промахуються в кеші.
Зосередьтеся на розміщенні й патернах доступу, а не на містичних налаштуваннях кешу.

5) Яка найпростіша безпечна політика для початку?

Почніть з numactl --preferred=<HBM node> замість суворого --membind.
Preferred використовує HBM, коли він доступний, але переходить на DDR замість помилок алокації.

6) Як це взаємодіє з контейнерами та Kubernetes?

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

7) Чи робить CXL HBM зайвим?

Ні. CXL чудовий для розширення та пулінгу пам’яті з вищою затримкою. HBM потрібен для пропускної здатності близько до обчислень.
У майбутньому може бути ієрархія: HBM (швидко), DDR (велике) і CXL (ще більше) одночасно.

8) Який найбільший операційний ризик із HBM-обладнаними CPU?

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

9) Що варто ставити на дашборди для флоту з HBM?

Використання пам’яті по NUMA-вузлах, індикатори віддаленої пам’яті, лічильники пропускної здатності (uncore), міграції сторінок і p99 затримки.
Саме по собі використання CPU — радше декоративне.

Практичні кроки далі

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

• Цього тижня: програйте «Швидкий план діагностики» на одному повільному навантаженні й визначте, чи ліміт — пропускна здатність, затримка чи віддалений NUMA.
• Цього місяця: побудуйте повторюваний набір приймальних тестів для нових класів апаратури: топологія, саніті-пропускна здатність, поведінка міграції і базовий p99 під контрольованим навантаженням.
• Перед купівлею заліза: моделюйте HBM як дефіцитний ресурс квоти і вирішіть, як ви будете планувати, спостерігати і запобігати перетворенню його на спільну трагедію.

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