Еволюція VRAM: від простого GDDR до повної божевільності

Що таке VRAM насправді (і чим він не є)

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

Уявіть шлях пам’яті GPU як інженер зберігання:
обчислювальні блоки — це ваші CPU; VRAM — ваш локальний NVMe; PCIe — мережевий лінк; системна RAM — віддалене сховище; диск — катастрофа.
Ви можете змусити це «працювати». Вам не сподобається рахунок.

Реальна ієрархія: кеші, VRAM, пам’ять хоста і зв’язок між ними

Більшість дискусій про продуктивність VRAM зриваються через те, що люди пропускають ієрархію:

• Вбудовані кеші (L2, іноді L1/shared memory) — крихітні, але швидкі й критичні для повторного використання.
• VRAM (GDDR/HBM) — ваш пул масивної пропускної здатності; латентність гірша за кеш, але передбачувана.
• Пам’ять хоста — величезна, але «далека»; навіть з хитрими трюками це інша планета за латентністю.
• PCIe / NVLink — горло; коли воно є вузьким місцем, все інше неважливе.

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

Цитата, яку варто витатуювати в рунбуці

Парафразована ідея — Джин Амдал: «Прискорення системи обмежене тією частиною, яку ви не покращили.»

Факти та історичний контекст (конкретно, не музейно)

1. Рання “VRAM” була буквально відеопам’яттю, призначеною для буферів кадру та дисплейних конвеєрів; 3D-прискорення перетворило її на лінію подачі для обчислень.
2. GDDR еволюціонував з DDR SDRAM, але віддавав перевагу пропускній здатності та сигналізації над абсолютною латентністю; GPU переносять латентність, запускаючи інші warps.
3. Ширина шини стала маркетинговим полем бою: 128-біт, 256-біт, 384-біт і навіть 512-біт використовувалися для масштабування пропускної здатності без екзотичного пакування.
4. GDDR5 допоміг нормалізувати “ефективні” швидкості передач у специфікаціях; що важливо оперативно — це підтримувана пропускна здатність при вашому шаблоні доступу.
5. HBM перемістив поле бою з PCB у пакет: кремнієві інтерпозери й стекувані кристали замінили величезну кількість трасування та проблем з шумом живлення.
6. ECC на VRAM став масовим у датацентрових GPU, бо тихі помилки у великому масштабі — не «рідкісні», а «щотижня».
7. Компресія пам’яті GPU стала реальною функцією пропускної здатності для графіки й інколи для обчислень; це залежить від робочого навантаження і не є безкоштовною.
8. Уніфікована пам’ять і перевикористання існують, бо люди завжди виділятимуть більше, ніж мають; продуктивність — це покарання.

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

Від GDDR до GDDR6X: епоха широких шин

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

Математика пропускної здатності, яка справді важлива

Заголовкове число — це пропускна здатність пам’яті:

• Bandwidth ≈ (data rate per pin) × (bus width) ÷ 8

Приклад: 16 Gbps на пін у 256-бітній шині дає ~512 GB/s пікової теоретичної пропускної здатності. Досягнута вами пропускна здатність може бути значно нижчою залежно від шаблонів доступу, конкуренції та поведінки контролера.

Чому GDDR був «простим» (і чому він перестав бути простим)

«Простий» — відносно. GDDR завжди був вимогливим:

• Багато дискретних чипів навколо пакета GPU, кожен із високошвидкісними лініями, які треба вирівнювати за довжиною.
• Велика складність живлення, бо перемикання цих сигналів на високій частоті дорогі.
• Теплове розподілення по платі: чіпи пам’яті нагріваються; вони поруч із VRM; повітряний потік ніколи не такий хороший, як у CAD-макеті.

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

Оперативна реальність: чому «та сама ємність VRAM» поводиться по-різному

Два GPU можуть обидва мати «24 GB VRAM» і при цьому радикально відрізнятися:

• Один може мати 384-бітну шину, інший — 256-бітну.
• Один може працювати на вищих ефективних швидкостях, але знижувати частоту при нагріванні.
• Один може мати краще планування контролера пам’яті для вашого шаблону (рандомний vs стрімінговий).
• Один може мати більший L2 кеш, який приховує латентність пам’яті й зменшує трафік VRAM.

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

Поява HBM: складання пам’яті як серверної стояка

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

Що HBM змінює на фізичному рівні

HBM вертикально стекує кілька DRAM-дій та з’єднує їх TSV (through-silicon vias). Замість 8–12 дискретних чипів навколо GPU ви отримуєте кілька стеків на пакеті.
Інтерфейс надзвичайно широкий, що є ключовим: ви отримуєте величезну пропускну здатність без потреби в божевільній швидкості на піні.

Практично це означає:

• Коротші проводи (в пакеті) → краща цілісність сигналу.
• Нижча частота для даної пропускної здатності → часто краща енергоефективність на біт.
• Зростає складність пакування → ризик виходу придатних виробів, вартість і обмеження постачання.

Прихований виграш: менше обмежень на рівні плати

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

Прихована вартість: масштабування ємності та сегментація продукту

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

Жарт 2: HBM — це те, що трапляється, коли ви кажете апаратним інженерам «маршрутизація складна», і вони відповідають, винайшовши 3D-місто.

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

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

Тиск на пропускну здатність: звідки він у реальних навантаженнях

• Вища роздільна здатність і складніші шейдери у графіці стимулювали трафік текстур і буферів кадру.
• Тренування AI по суті є генератором трафіку пам’яті: активації, градієнти, стан оптимізатора і часті операції читання/запису.
• Inference при малих батчах може бути чутливим до латентності й недружнім до кешу, підвищуючи навантаження на VRAM і PCIe.
• Наукові обчислення часто торкаються великих масивів з обмеженим повторним використанням; ваша швидкість — це швидкість підсистеми пам’яті.

Тиск на ємність: чому «просто додати VRAM» не вирішує всього

Ємність важлива, коли робочий набір не вміщується. Але коли вміщається, часто ви обмежені тим, наскільки швидко можете його потікати.
Підступ: люди купують ємність VRAM, щоб вирішити проблеми пропускної здатності, а потім дивуються, чому продуктивність майже не змінюється.

Практичне правило:

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

Чому «швидкість» VRAM — це не одне число

Пікова пропускна здатність ≠ стійка пропускна здатність. Стійка залежить від:

• Шаблону доступу: згруповані vs розкидані, кроки, повторне використання.
• Рівня попадань у кеш: більший L2 може перетворити «bound по VRAM» на «bound по кешу», що зазвичай краще.
• Паралелізму: занадто мало паралелізму — і ви не ховаєте латентність; занадто багато — і трясе кеші.
• Теплової поведінки: зниження частоти пам’яті може тихо урізати пропускну здатність і створити «випадкові» регресії.

Інженерні компроміси: вартість, енергія, вихідність і надійність

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

GDDR: простіше масштабувати доступність, складніше приборкати плату

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

HBM: елегантна пропускна здатність, складне пакування

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

Надійність у реальному світі: ECC, обробка помилок і «м’які» відмови

Якщо ви робите навчання ML або довгі HPC-запуски, безшумна корупція — більший ворог, ніж падіння. Падіння голосне; корупція дорога й тиха.
ECC на VRAM допомагає, але не робить вас безсмертними. Вам все одно потрібні:

• Моніторинг помилок (зростання коригованих помилок — сигнал тривоги).
• Тепловий моніторинг (тепло прискорює відмови й викликає тротлінг).
• Політики карантину для GPU, які починають некоректно поводитися під навантаженням.

Примітка для продакшена: «Завдання завершилось» — це не те саме, що «вихід коректний». Розглядайте помилки пам’яті GPU як події цілісності даних, а не як події продуктивності.

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

Міні-історія 1: Інцидент, спричинений хибним припущенням (ємність ≠ локальність)

Команда розгорнула новий inference-сервіс на флоті GPU з достатнім VRAM. Модель вміщалася комфортно. Ніхто не очікував, що пам’ять стане темою.
Латентність у стенді виглядала нормально. Продакшен стартував теж добре, потім погіршився під час пікових вікон трафіку. Не різкий обрив, а повільне псування.

Перший інстинкт on-call був на розмір батчу. Його зменшили, побачили певне поліпшення і оголосили перемогу. Через два дні схожий патерн повернувся.
Справжній симптом був у тому, що завантаження GPU коливалося, а використання CPU хоста зроставало. Система виконувала роботу — просто не ту, за яку платили.

Хибне припущення: «Якщо модель вміщається у VRAM, то пам’ять не є вузьким місцем». Насправді шлях запиту виконував динамічну токенізацію й випадкову попередню обробку на CPU. Кожен запит викликав кілька невеликих хост→девайс передач. Під навантаженням ці передачі серіалізувалися за насиченим PCIe шляхом і купою точок синхронізації.

Виправлення було непрезентабельним: з’єднати попередню обробку, пакетні передачі, використовувати pinned host memory для стабільного DMA і видалити неявні синхронізації девайса в обробнику запитів.
Ємність VRAM не була вузьким місцем. Локальність і поведінка передач були.

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

Міні-історія 2: Оптимізація, що обернулась проти (розумне повторне використання пам’яті vs фрагментація)

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

У продакшені частина навантажень почала падати з помилками out-of-memory, хоча nvidia-smi показував багато вільного VRAM.
Ще гірше: збої були голосні й періодичні. Перезапуск сервісу зазвичай «вирішував» проблему, поки не переставав. Класична allocator-строка, але на GPU.

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

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

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

Міні-історія 3: Нудна, але правильна практика, що врятувала ситуацію (бюджети помилок для здоров’я VRAM)

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

Потім новий тренувальний запуск почав давати трохи гірші метрики. Не катастрофа. Просто послідовно гірше. Люди сперечалися про дрейф даних, випадкові зерна та налаштування оптимізатора.
Тим часом один вузол показав підвищення коригованих помилок VRAM під час періодів високих температур. Планувальник запусків ставив туди кілька прогонів тижнями.

Оскільки організація мала нудну практику, вузол автоматично злили і GPU поставили в карантин. Тренування перезапустили в іншому місці.
Метрики повернулися в очікувані діапазони. Без героїчного дебагу, без полювання на відьом.

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

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

Це ті перевірки, які ви можете виконати під час інциденту, не перетворюючи його на науковий проєкт.
Команди орієнтовані на Linux і припускають інструменти NVIDIA там, де релевантно. Адаптуйте за потреби.

Завдання 1: Визначити GPU, драйвери і чи ОС бачить те, що ви думаєте

cr0x@server:~$ nvidia-smi
Tue Jan 13 10:41:05 2026
+---------------------------------------------------------------------------------------+
| NVIDIA-SMI 550.54.14    Driver Version: 550.54.14    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. |
|                                         |                      |               MIG M. |
|=========================================+======================+======================|
|  0  NVIDIA A100-PCIE-40GB           On  | 00000000:17:00.0 Off | 0                    |
|  1  NVIDIA A100-PCIE-40GB           On  | 00000000:65:00.0 Off | 0                    |
+-----------------------------------------+----------------------+----------------------|

Що це означає: Підтверджує інвентар GPU, версію драйвера та базові сигнали здоров’я.

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

Завдання 2: Слідкувати за використанням VRAM і завантаженням з часом (виявити тряску, сплески і простої)

cr0x@server:~$ nvidia-smi dmon -s pucm -d 1
# gpu   pwr  ut   mem   sm   enc  dec  mclk  pclk
# Idx     W   %     %    %     %    %   MHz   MHz
    0   210  35    88   34     0    0  1215  1410
    1   115   5    12    3     0    0   405   585

Що це означає: GPU 0 має велике використання пам’яті (88%) з помірним завантаженням; GPU 1 переважно простоїть.

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

Завдання 3: Підтвердити ширину і покоління PCIe (тихий вбивця пропускної здатності)

cr0x@server:~$ nvidia-smi -q | sed -n '/PCI/,+12p'
    PCI
        Bus                             : 0x17
        Device                          : 0x00
        Domain                          : 0x0000
        Bus Id                          : 00000000:17:00.0
        PCIe Generation
            Max                         : 4
            Current                     : 3
        Link Width
            Max                         : 16x
            Current                     : 8x

Що це означає: Ви очікували Gen4 x16; отримали Gen3 x8. Це реальний вузький горлом для передач.

Рішення: Розглядайте це як апаратну/платформну проблему (слот, BIOS, riser, бiфуркація). Не витрачайте час на «оптимізацію» кернелів, поки шина обмежена.

Завдання 4: Перевірити NUMA-локальність (розміщення пам’яті CPU впливає на host→device передачі)

cr0x@server:~$ nvidia-smi topo -m
        GPU0    GPU1    CPU Affinity    NUMA Affinity
GPU0     X      PHB     0-31            0
GPU1    PHB      X      32-63           1

Що це означає: GPU0 локальний для NUMA вузла 0, GPU1 для вузла 1. «PHB» вказує на те, що трафік переходить через PCIe Host Bridge.

Рішення: Закріпіть CPU-потоки і виділіть пам’ять хоста на правильному NUMA-вузлі. Ігнорування цього призведе до штучного підвищення латентності.

Завдання 5: Виявити проблеми ECC VRAM (тренди коригованих помилок — ранні попередження)

cr0x@server:~$ nvidia-smi -q -d ECC | sed -n '1,120p'
ECC Mode
    Current                         : Enabled
    Pending                         : Enabled
ECC Errors
    Volatile
        Single Bit
            Device Memory           : 12
        Double Bit
            Device Memory           : 0
    Aggregate
        Single Bit
            Device Memory           : 893
        Double Bit
            Device Memory           : 0

Що це означає: Є кориговані помилки і вони можуть рости. Подвійних (некоригованих) — нуль, добре.

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

Завдання 6: Перевірити використання VRAM по процесах (знайти реального забіяку)

cr0x@server:~$ nvidia-smi --query-compute-apps=pid,process_name,used_memory --format=csv
pid, process_name, used_memory [MiB]
18422, python, 31748 MiB
19103, python,  6020 MiB

Що це означає: PID 18422 володіє VRAM. Тепер у вас є ціль.

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

Завдання 7: Шукати причини тротлінгу (ваша пропускна здатність може танути)

cr0x@server:~$ nvidia-smi -q -d PERFORMANCE | sed -n '1,140p'
Performance State                    : P2
Clocks Throttle Reasons
    Idle                            : Not Active
    Applications Clocks Setting     : Not Active
    SW Power Cap                    : Active
    HW Slowdown                     : Not Active
    HW Thermal Slowdown             : Not Active

Що це означає: Активний софтовий ліміт потужності; годинники можуть бути стримані.

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

Завдання 8: Корелювати активність GPU з CPU і I/O навантаженням (не звинувачуйте VRAM за проблеми сховища)

cr0x@server:~$ pidstat -dru -p 18422 1 5
Linux 6.5.0 (server)  01/13/2026  _x86_64_  (64 CPU)

10:41:18 PM   UID       PID   %usr %system  %CPU   RSS   kB_rd/s kB_wr/s  iodelay  Command
10:41:19 PM  1001     18422  220.0     8.0 228.0  18G    5120.0    120.0        8  python

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

Рішення: Збільшіть prefetching, використовуйте швидше локальне сховище або стадіонуйте набори даних. Не ганяйтеся за пропускною здатністю VRAM, коли ви голодуєте GPU.

Завдання 9: Перевірити hugepages і ліміти блокування пам’яті (pinned memory потребує підтримки ОС)

cr0x@server:~$ ulimit -l
64

Що це означає: Процес може заблокувати лише 64 KB пам’яті. Алокації pinned host memory можуть не вдаватися або деградувати.

Рішення: Для сервісів, що залежать від pinned memory, підніміть ліміти memlock (обережно) через systemd або політику безпеки, а потім перевірте поведінку.

Завдання 10: Переглянути системні логи на події PCIe/NVRM (апаратні проблеми маскуються під «повільний код»)

cr0x@server:~$ journalctl -k -S -2h | egrep -i 'nvrm|pcie|aer|xid' | tail -n 20
Jan 13 08:55:02 server kernel: pcieport 0000:00:03.1: AER: Corrected error received: id=00e1
Jan 13 08:55:02 server kernel: pcieport 0000:00:03.1: PCIe Bus Error: severity=Corrected, type=Physical Layer
Jan 13 08:55:02 server kernel: NVRM: Xid (PCI:0000:17:00): 79, GPU has fallen off the bus.

Що це означає: Помилки PCIe і Xid, що вказує на випадіння GPU з шини. Це не «проблема оптимізації».

Рішення: Злити вузол, перевірити кабелі/risers/сидіння у слоті, прошивку, лінії живлення і розглянути заміну апаратури.

Завдання 11: Перевірити реальну частоту пам’яті GPU під навантаженням

cr0x@server:~$ nvidia-smi --query-gpu=clocks.mem,clocks.gr,temperature.gpu,power.draw --format=csv -l 1
clocks.mem [MHz], clocks.gr [MHz], temperature.gpu, power.draw [W]
1215, 1410, 78, 232.45
405,  585,  60, 115.10

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

Рішення: Полагодьте охолодження, ліміти потужності або політику application/persistence clocks. Інакше графіки пропускної здатності будуть бреши вам.

Завдання 12: Підтвердити, що контейнер бачить ті самі можливості GPU (несумісності cgroups і runtime)

cr0x@server:~$ docker exec -it ml-infer bash -lc 'nvidia-smi -L'
GPU 0: NVIDIA A100-PCIE-40GB (UUID: GPU-2c1b0f0a-1a7c-9c1a-bd73-3b0b62f4d2b2)

Що це означає: Контейнер має доступ до GPU. Якщо ні — ви отримаєте відкат до CPU і жахливу «VRAM» продуктивність (бо ви не використовуєте VRAM).

Рішення: Виправте конфігурацію runtime перед тим, як чіпати код моделі.

Завдання 13: Виміряти пропускну здатність PCIe під час копіювань (виявити домінування host-device копій)

cr0x@server:~$ nvidia-smi dmon -s t -d 1
# gpu    rxpci   txpci
# Idx   MB/s    MB/s
    0    9800    2100

Що це означає: Значний PCIe receive-трафік. Якщо час кернелу малий, копії можуть домінувати в латентності.

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

Завдання 14: Перевірити розподіл пам’яті CPU NUMA під час навантаження GPU

cr0x@server:~$ numastat -p 18422
Per-node process memory usage (in MBs) for PID 18422 (python)
Node 0          14820.5
Node 1           120.0
Total          14940.5

Що це означає: Пам’ять процесу в хості здебільшого на вузлі 0. Якщо він підгодовує GPU1 на вузлі 1, ви примушуєте міжсокетний трафік.

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

Швидкий план діагностики: знайти вузьке місце за хвилини

Коли навантаження GPU повільне, ви не маєте права вгадувати. Ви робите триаж. Мета — визначити обмежувальний рівень — обчислення, пропускна здатність VRAM, ємність VRAM, передача PCIe/NVLink, вхідний конвеєр CPU або тротлінг — перш ніж чіпати код.

Перше: встановіть, чи GPU справді завантажений

• Запустіть nvidia-smi і nvidia-smi dmon.
• Якщо використання GPU низьке: підозрюйте голодування даними, синхронізації, CPU конвеєр або накладні витрати на передачі.
• Якщо використання GPU високе: можливо, ви обмежені обчисленнями або пропускною здатністю пам’яті; продовжуйте далі.

Друге: перевірте «легкі обмани» (тротлінг і проблеми шини)

• Підтвердьте Gen і ширину PCIe: nvidia-smi -q.
• Перевірте причини тротлінгу: nvidia-smi -q -d PERFORMANCE.
• Проскануйте журнали ядра на AER/Xid: journalctl -k.

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

Третє: вирішіть, чи це тиск ємності чи пропускної здатності

• Тиск ємності: OOM, часті вибивання/перевикористання, VRAM близько до 100% з великим churn.
• Тиск пропускної здатності: VRAM вміщується, але швидкість низька; кернелі показують велику пам’ятну навантаженість і низьку арифметичну інтенсивність; частоти пам’яті й шаблони використання відповідають цьому.

Четверте: перевірте передачі і локальність

• Використайте nvidia-smi dmon -s t, щоб побачити рівні трафіку PCIe.
• Використайте nvidia-smi topo -m і numastat для перевірки NUMA-розміщення.
• Якщо сервіс контейнеризований, підтвердіть видимість GPU всередині контейнера.

П’яте: лише тоді профілюйте глибше

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

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

1) Симптом: «VRAM заповнений, але продуктивність нормальна… поки не стала ні»

Корінь: фрагментація алокатора або кешування, що поступово зменшує доступну суцільну пам’ять.

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

2) Симптом: низьке використання GPU, велика латентність і великий PCIe-трафік

Корінь: хост-девіс копії домінують; надмірні синхронізації змушують послідовне виконання.

Виправлення: пакетувати передачі, розумно використовувати pinned memory, перекривати копії й обчислення, і видалити неявні точки синхронізації в коді запитів.

3) Симптом: раптове погіршення після переходу на «швидший VRAM» GPU

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

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

4) Симптом: періодичні зависання GPU або збої завдань у різних моделях

Корінь: помилки PCIe, ненадійний riser/слот, маргінальне живлення або GPU, що починає виходити з ладу.

Виправлення: перевірте журнали ядра на AER/Xid; переосадіть апарат; оновіть прошивку; помістіть підозрілі GPU в карантин за трендами помилок.

5) Симптом: багатогпу задача повільніша за одно-GPU

Корінь: обмеження інтерконекту (топологія PCIe, відсутність NVLink) або витрати на синхронізацію градієнтів переважають.

Виправлення: перевірте топологію за допомогою nvidia-smi topo -m; закріпіть процеси; використовуйте відповідну стратегію паралелізму; уникайте пар GPU через сокети.

6) Симптом: OOM, хоча «вільна пам’ять» існує

Корінь: фрагментація, зарезервовані пули або кілька процесів з окремими алокаторами.

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

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

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

Виправлення: моніторити тренди ECC; ізолювати апарат; виконати перевірки відтворюваності; тимчасово відключити ризикові fast-math шляхи для валідації.

8) Симптом: «Ми додали ємності VRAM; продуктивність не змінилася»

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

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

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

Чекліст A: Вибір між GDDR і HBM (що робити, а не що сперечатися)

1. Класифікуйте навантаження: стрімінгове (пропускна здатність), з повторним використанням (кеш) або ємнісне (великий робочий набір).
2. Виміряйте поведінку передач: host↔device пропускна здатність і частота при реальному трафіку.
3. Вирішіть, за що платите:
   • Обирайте HBM, коли пропускна здатність є обмежувачем і ви можете виправдати преміум-пакування.
   • Обирайте GDDR, коли важливіша ємність/вартість і гнучкість постачання, а навантаження терпить нижчу пропускну здатність.
4. Бюджетуйте терміки: якщо не можете стабільно тримати частоти пам’яті, теоретична пропускна здатність — фантазія.
5. Плануйте надійність: вимагайте ECC там, де важлива коректність; встановіть пороги карантину й автоматизуйте злив вузлів.

Чекліст B: Роллаут GPU-навантаження в продакшені (уникнути класичних фейлів)

1. Перевірте ширину/покоління PCIe і топологію для кожного класу вузлів.
2. Увімкніть persistence mode, якщо ваше середовище виграє від стабільної ініціалізації і меншого джиттера.
3. Встановіть і задокументуйте ліміти потужності та політику application clocks; не лишайте це на фольклор.
4. Закріпіть CPU-потоки і пам’ять хоста в NUMA-домені GPU для чутливих до латентності сервісів.
5. Інструментуйте: завантаження GPU, використана пам’ять, частота пам’яті, PCIe RX/TX, події ECC і хвостова латентність.
6. Тестуйте навантаження з реалістичними розподілами запитів (не тільки steady-state throughput).
7. Визначте операційні відповіді: що тригерить drain, що — rollback, що — карантин апаратури.

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

1. Порівняйте вивід nvidia-smi (драйвер, сумісність CUDA) до і після.
2. Перевірте нову поведінку тротлінгу під тривалим навантаженням.
3. Підтвердьте, що переговори PCIe не змінилися (регресії Gen/width трапляються).
4. Повторно перевірте доступ GPU у runtime контейнера і монтування бібліотек.
5. Лише потім профілюйте кернелі і трафік пам’яті; не припускайте одразу, що компілятор погіршав.

Поширені питання (FAQ)

1) Чи швидкість VRAM здебільшого про MHz?

Ні. Пропускна здатність — це добуток швидкості передачі на пін і ширини шини (і архітектури). Самі MHz ігнорують метод сигналізації, ширину й ефективність контролера.

2) Чому GPU терплять вищу латентність пам’яті, ніж CPU?

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

3) Якщо моя модель вміщується у VRAM, чи можу я ігнорувати PCIe?

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

4) Чи HBM завжди кращий за GDDR?

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

5) Чому я бачу помилки out-of-memory, коли nvidia-smi показує вільний VRAM?

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

6) Чи ECC зменшує продуктивність?

Іноді трохи, залежно від архітектури і навантаження. В обмін ви отримуєте менше тихої корупції даних. Для тренувань або критичних inference цей обмін зазвичай виправданий.

7) Як визначити, чи я обмежений пропускною здатністю чи обчисленням?

Швидкі сигнали: високе використання пам’яті/трафік при помірному завантаженні SM вказує на тиск пропускної здатності; високе завантаження SM при стабільному трафіку пам’яті вказує на обмеження обчислення.
Підтвердіть профілюванням, коли перевірки здоров’я платформи пройдені.

8) У чому практична різниця між ємністю VRAM і пропускною здатністю VRAM?

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

9) Чому той самий GPU поводиться по-різному в різних серверах?

Топологія PCIe, NUMA-розміщення, охолодження, ліміти потужності і навіть налаштування BIOS можуть змінювати ефективну пропускну здатність і стабільність. Розглядайте сервери як частину системи GPU.

10) Чи слід покладатися на уніфіковану пам’ять/перевикористання як на «рішення» проблем VRAM?

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

Наступні кроки, які варто реально зробити

Якщо ви керуєте GPU у продакшені, ставтеся до VRAM як до підсистеми першого рівня: вона має планування ємності, планування пропускної здатності, моніторинг здоров’я й режими відмов.
Еволюція від GDDR до HBM — це не технічний тренд; це реакція індустрії на те саме обмеження, яке ви відлагоджуєте о 3:00 ранку: переміщення даних.

1. Базуйте кожен клас вузлів: PCIe Gen/width, топологію, терміки, ліміти потужності і режим ECC.
2. Інструментуйте правильні сигнали: використання VRAM, частоти пам’яті, PCIe RX/TX, помилки ECC, причини тротлінгу і хвостову латентність.
3. Кодифікуйте правила карантину: тренди коригованих помилок і події Xid мають автоматично зливати вузли.
4. Зробіть локальність частиною деплою: NUMA-пінінг і розміщення пам’яті мають бути налаштуваннями сервісу, а не племінним знанням.
5. Обирайте обладнання на основі виміряних вузьких місць: не купуйте ємність, щоб вирішити пропускну здатність, і не купуйте пропускну здатність, щоб вирішити ламаний PCIe лінк.

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