Чому GPU нагріваються: просте пояснення, що запам’ятовується

Коротке пояснення: маленький простір, велика потужність, жорстка математика

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

У простому вигляді:

• Електрична потужність подається. Ваш GPU може споживати 200–600 ват під навантаженням.
• Майже вся вона перетворюється на тепло. Не «трохи». Майже вся. Корисний результат — обчислення, але він не виходить з коробки як енергія; він виходить як результати. Потужність все одно перетворюється на тепло.
• Тепло має пройти через ланцюжок матеріалів. Кремній → корпус → тепловий інтерфейс (паста/подушка) → плита радіатора → ребра → повітря (або рідина) → приміщення → HVAC.
• Будь-яке слабке місце підвищує температуру на всіх етапах вище по ланцюгу. Термальні системи поводяться як черга. Якщо вихід заблоковано — все стає гарячішим.

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

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

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

Що означає «працює гарячо» (і які цифри важливі)

«Мій GPU 85°C» — цього недостатньо для діагностики. Потрібно знати, який датчик, що робить навантаження і чи відбувається тротлінг.

Важливі температури

• Температура ядра GPU: класична «температура GPU», яку показують інструменти. Корисна, але часто вже не є першим обмежувачем.
• Hotspot / junction temperature: найгарячіша виміряна точка на кристалі. Часто досягає межі першою, особливо при поганому контакті або старінні пасти.
• Температура кристалу пам’яті (особливо GDDR6X): пам’ять може нагріватися більше за ядро і викликати тротлінг. Можна мати «нормальну» температуру ядра та все одно мати проблему.
• Температури VRM / силових ступенів: елементи регулювання напруги нагріваються при великому струмі. Вони — невидимі вбивці надійності.
• Температура повітря на вході / навколишня: температура повітря, що надходить у охолоджувач GPU, а не «деінде в кімнаті». Підвищення на 5°C на вході — суттєво.

Що означає «занадто гаряче» на практиці

GPU спроектовані так, щоб працювати гаряче. Вендори знають, що кремній витримає високі температури переходу. Але «запроектовано» ≠ «добре для вашого флоту». Для споживчих карток ядра в 70–середні 80°C під тривалим навантаженням можуть бути нормою в залежності від моделі та повітряного потоку. Для датацентрових рішень поведінка залежить від конструкції охолодження (пасивні радіатори покладаються на потік повітря в шасі) і профілю потужності навантаження.

Що вам слід цікавити в експлуатації:

• Тротлінг: падіння продуктивності через досягнення температурних або енергетичних меж.
• Рівень помилок: помилки ECC пам’яті, помилки PCIe, скидання драйверів, збої додатків.
• Запас стабільності: GPU, який «в порядку» при 22°C навколишнього, може стати катастрофою при 30°C у спекотний день або з частково забраними фільтрами.
• Старіння компонентів: вищі температури прискорюють механізми зносу. Ваші надії на MTBF повільно вмирають, а потім — раптово.

Цитата, що допоможе пріоритезувати: Надія — не стратегія. — генерал Гордон Р. Салліван

Чому GPU практично гарячіші за CPU

Немає однієї причини. Це шар причин, що вишиковуються як невдалий доміно.

1) GPU орієнтовані на пропускну здатність через масивний паралелізм

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

2) Вони працюють близько до своїх енергетичних і теплових меж за дизайном

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

3) Потужність плати включає не лише ядро

У розмові про CPU часто говорять про package power. «Board power» GPU включає пам’ять, VRM та інші компоненти. Охолоджувач має справлятися з кількома джерелами тепла, а не лише з одним акуратно упакованим кристалом під сокетом.

4) Припущення про охолодження часто невірні

Server CPU живуть у світі, де повітряний потік шасі проінженерений під них. GPU часто встановлюють у «достатньо гарні» корпуси, штовхають поряд із іншим GPU і змушують дихати через стрічковий кабель та оптимізм інженера.

5) Навантаження тривалі

Ігри мають піки й варіації. Тренування та пайплайни інференсу можуть утримувати GPU на високому завантаженні годинами чи днями. Відбувається термальне насичення. Радіатор, який виглядає нормальним 10 хвилин, може провалитися на 45-й хвилині.

6) Винуватцем є щільність тепла, а не абсолютні вати

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

Цікаві факти та історія, що пояснюють сучасний перегрів

Проблеми з теплом з’явилися не тому, що інженери розслабилися. Вони з’явилися тому, що GPU перемогли, і ми почали просити їх робити все підряд.

1. Ранні 3D-прискорювачі були помірною потужності. Карти кінця 1990-х мали частку сучасного енергоспоживання; багато хто використовував маленькі радіатори й невеликі вентилятори, оскільки щільність потужності була низькою.
2. Дедиковані роз’єми живлення GPU стали мейнстримом із ростом потужності плати. Перехід за межі того, що може безпечно надати слот PCIe, вимагав нових стандартів конекторів і створив нові режими відмов (включно з, так, оплавленими роз’ємами при поганих допусках і поводженні).
3. «Shader cores» уніфікували графічні конвеєри — і створили простіший загальний обчислювальний інтерфейс. Ця архітектурна зміна допомогла перетворити GPU на обчислювальний пристрій; більше обчислень означало триваліше споживання потужності.
4. CUDA (2007) популяризувала GPGPU. Коли розробники змогли розглядати GPU як обчислювальний ресурс, навантаження перестали бути «сплесками графіки» і стали «математичною піччю 24/7».
5. HBM показав готовність галузі перемістити пам’ять ближче. High Bandwidth Memory ставить пам’ять поруч із GPU у стосах; це покращує пропускну здатність і може змінювати, де концентрується тепло і як його охолоджувати.
6. GDDR6X підвищив щільність потужності пам’яті. Швидша передача сигналів може означати гарячіші модулі пам’яті, через що температура пам’яті часто стає обмежувачем на деяких споживчих картах.
7. Датацентрові GPU сильно опиралися пасивному охолодженню. Багато серверних GPU покладаються на потік повітря шасі замість вбудованих вентиляторів; якщо сервер не розрахований під це — температури злітають.
8. Алгоритми boost ставали сміливішими з часом. Сучасні GPU підвищують частоту по можливості, поки не досягнуть обмежень, тому «він працює гаряче» часто буквально є наміром виробника.
9. Компонування багатьох GPU спричинило термічні взаємодії. Розміщення високопотужних карт поряд може зробити так, що вихід однієї карти стає входом іншої — це фактично термічний канібалізм.

Шлях тепла: від транзистора до повітря в кімнаті

Коли хтось каже «мій GPU гарячий», ваше завдання — запитати: де термічний опір?

Крок 1: Потужність генерується на кристалі

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

Крок 2: Тепло розповсюджується через упаковку

Тепло має вийти з кремнію і пройти через корпус та теплорозподільник (якщо є). Неперфекції тут не обслуговуються користувачем, але проявляються як «гаряче місце значно вище за ядро», особливо під навантаженням.

Крок 3: Тепловий інтерфейс — вирішальний шар

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

Крок 4: Радіатор має передати тепло в повітря

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

Крок 5: Корпус і приміщення мають вивести тепло

Якщо корпус рециркулює випускне повітря, ваш охолоджувач GPU змушений працювати з теплішим вхідним повітрям. Той самий радіатор, але гірший дельта-T, вищі температури. У датацентрі, якщо зона «гарячий коридор/холодний коридор» має протікання, ваш «холодний» вхід поступово стає «теплим жалем».

Короткий жарт №2: Термальна діагностика — це як детективна робота, тільки підозрюваний завжди «повітря», і воно завжди має алібі.

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

Це порядок, що заощаджує час. Мета — визначити, чи ви обмежені температурою, потужністю, повітряним потоком/навколишнім середовищем або плутаниною в сенсорах/телеметрії.

По-перше: підтвердіть, що GPU справді тротлиться (а не просто «теплий»)

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

По-друге: порівняйте ядро vs hotspot vs пам’ять

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

По-третє: перевірте реальність вхідного повітря/повітряний потік

• Поміряйте температуру повітря на вході, де GPU «дихає».
• Перевірте RPM вентиляторів і поведінку кривої вентилятора.
• Рішення: якщо вхідне повітря високе або потік заблокований — не починайте з повторного нанесення пасти. Спочатку перемістіть повітря.

По-четверте: перевірте поведінку живлення та обмеження

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

По-п’яте: перевірте платформні проблеми

• Помилки PCIe, тротлінг CPU, що викликає недовантаження GPU (і дивні термальні шаблони), скидання драйверів.
• Рішення: якщо вузол нестабільний, трактуйте «тепло» як симптом, а не корінну причину.

Практичні завдання з командами: що запускати, що означає, що вирішувати

Це реальні перевірки, які ви можете виконати на хості Linux з NVIDIA GPU. Показані виводи репрезентативні. Ваші точні поля відрізнятимуться залежно від драйвера та моделі GPU. Суть — що ви читаєте і що робите далі.

Завдання 1: Знімок термальних показників, частот і потужності в одному вигляді

cr0x@server:~$ nvidia-smi
Tue Jan 13 10:22:41 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 A10                      On  | 00000000:3B:00.0 Off   |                    0 |
| 30%   78C  P2              143W / 150W  |  10980MiB / 23028MiB   |     92%      Default |
+-----------------------------------------+------------------------+----------------------+

Що це означає: Температура 78°C при 92% завантаженні, потужність біля ліміту. Стан продуктивності P2 вказує на режим високої продуктивності. Вентилятор на 30% може бути консервативним.

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

Завдання 2: Слідкуйте в реальному часі, щоб помітити шаблони тротлінгу

cr0x@server:~$ watch -n 1 nvidia-smi --query-gpu=timestamp,temperature.gpu,utilization.gpu,clocks.sm,power.draw,pstate --format=csv
timestamp, temperature.gpu, utilization.gpu, clocks.sm, power.draw, pstate
2026/01/13 10:23:00, 79, 95, 1695, 149.22, P2
2026/01/13 10:23:01, 81, 96, 1695, 149.80, P2
2026/01/13 10:23:02, 83, 96, 1620, 149.90, P2

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

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

Завдання 3: Запитайте драйвер, чому продуктивність обмежена

cr0x@server:~$ nvidia-smi -q -d PERFORMANCE | sed -n '1,120p'
==============NVSMI LOG==============
Timestamp                                 : Tue Jan 13 10:23:10 2026
Driver Version                            : 550.54.14
CUDA Version                              : 12.4

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

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

Рішення: Якщо потрібна вища пропускна здатність — підніміть ліміт потужності (і переконайтеся в запасі охолодження/БЖ). Якщо потрібна холодніша робота — збережіть або зменшіть ліміт і налаштуйте perf/W.

Завдання 4: Логуйте температури та потужність з часом для кореляції (дешева телеметрія)

cr0x@server:~$ nvidia-smi --query-gpu=timestamp,temperature.gpu,power.draw,utilization.gpu,clocks.sm --format=csv -l 5 -f /tmp/gpu_telemetry.csv
# Monitoring GPU 00000000:3B:00.0.
# Logging to /tmp/gpu_telemetry.csv

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

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

Завдання 5: Перевірте, чи драйвер дозволяє ту поведінку вентилятора, яку ви очікуєте

cr0x@server:~$ nvidia-settings -q GPUFanControlState -q GPUTargetFanSpeed
  Attribute 'GPUFanControlState' (server:0[gpu:0]): 0.
  Attribute 'GPUTargetFanSpeed' (server:0[gpu:0]): 30.

Що це означає: Стан контролю вентилятора 0 зазвичай означає автоматичне керування. Ціль — 30% (але фактичне може відрізнятися).

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

Завдання 6: Перевірте фактичні RPM вентилятора і чи не виходить він з ладу

cr0x@server:~$ nvidia-smi --query-gpu=fan.speed,temperature.gpu --format=csv
fan.speed, temperature.gpu
30 %, 83

Що це означає: Вентилятор працює, але невідомо, чи 30% достатньо.

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

Завдання 7: Перевірте термальні показники CPU і тротлінг (бо платформа інколи бреше)

cr0x@server:~$ sudo sensors
coretemp-isa-0000
Adapter: ISA adapter
Package id 0:  92.0°C  (high = +100.0°C, crit = +105.0°C)
Core 0:        89.0°C
Core 1:        91.0°C

nvme-pci-0100
Adapter: PCI adapter
Composite:    +68.9°C  (low  = -40.1°C, high = +84.8°C, crit = +89.8°C)

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

Рішення: Виправляйте повітряний потік шасі і охолодження CPU також. Термальний інцидент GPU часто є інцидентом повітряного потоку всього вузла.

Завдання 8: Перевірте цілісність PCIe (помилки можуть маскуватися під «дивну поведінку GPU»)

cr0x@server:~$ sudo lspci -s 3b:00.0 -vv | sed -n '1,80p'
3b:00.0 VGA compatible controller: NVIDIA Corporation Device 2236 (rev a1)
	Subsystem: NVIDIA Corporation Device 147e
	LnkCap: Port #0, Speed 16GT/s, Width x16
	LnkSta: Speed 16GT/s, Width x16
	DevSta: CorrErr+ NonFatalErr- FatalErr- UnsupReq-

Що це означає: Логуються коректовані помилки. Це не негайна катастрофа, але це сигнал. Тепло може погіршувати маргінальні посилання.

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

Завдання 9: Переконайтеся, що немає простого блокування потоку повітря (класика «чому ми такі»)

cr0x@server:~$ sudo lsblk -o NAME,HCTL,SIZE,MODEL
NAME HCTL        SIZE MODEL
sda  0:0:0:0   447.1G Samsung SSD 860
nvme0n1         1.8T  SAMSUNG MZVL21T0HCLR-00B00

Що це означає: Це не команда для повітряного потоку. Це нагадування: не зациклюйтеся на GPU. NVMe при 69°C і CPU при 92°C вказують, що повітряний потік шасі недостатній або заблокований.

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

Завдання 10: Перевірте журнали ядра на термальні або драйверні події

cr0x@server:~$ sudo journalctl -k -b | egrep -i 'nvrm|pcie|thermal|throttl' | tail -n 20
Jan 13 10:20:11 server kernel: nvidia-modeset: Allocated GPU:0 (GPU-2d3a...)
Jan 13 10:22:58 server kernel: NVRM: Xid (PCI:0000:3b:00): 79, GPU has fallen off the bus.
Jan 13 10:23:00 server kernel: pcieport 0000:00:03.1: AER: Correctable error received: 0000:3b:00.0

Що це означає: «Fallen off the bus» і AER-повідомлення — серйозні індикатори стабільності. Тепло може бути фактором, але також можуть бути проблему з цілісністю живлення, роз’ємами PCIe або прошивкою.

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

Завдання 11: Виміряйте споживання GPU і застосуйте розумний ліміт потужності

cr0x@server:~$ sudo nvidia-smi -pl 130
Power limit for GPU 00000000:3B:00.0 was set to 130.00 W from 150.00 W.

Що це означає: Ви щойно зменшили максимальну потужність плати. Це зазвичай швидко знижує температури.

Рішення: Запустіть навантаження і порівняйте пропускну здатність. Якщо втрачаєте 2–5% продуктивності, але отримуєте -10°C і стабільність — це та компроміс, який у продакшні приймають без суперечок.

Завдання 12: Підтвердіть, що ліміт потужності застосовано, і спостерігайте термали після зміни

cr0x@server:~$ nvidia-smi --query-gpu=temperature.gpu,power.draw,clocks.sm,utilization.gpu --format=csv
temperature.gpu, power.draw, clocks.sm, utilization.gpu
74, 129.12, 1620, 96

Що це означає: Температура впала з низьких 80s до середини 70s при високому завантаженні. Частоти можуть стати трохи нижчими, але стабільними.

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

Завдання 13: Перевірте, чи встановлений persistence mode (зменшує фланжування, підвищує передбачуваність)

cr0x@server:~$ sudo nvidia-smi -pm 1
Enabled persistence mode for GPU 00000000:3B:00.0.
All done.

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

Рішення: На спільних продакшн-вузлах persistence mode часто покращує передбачуваність. Якщо ваша модель безпеки або мультиорендарність забороняє це — документуйте компроміс.

Завдання 14: Переконайтеся, що ваш процес не створює марного тепла (runaway utilization)

cr0x@server:~$ nvidia-smi pmon -c 1
# gpu        pid  type    sm   mem   enc   dec   command
# Idx          #   C/G     %     %     %     %   name
    0      28741     C    92    40     0     0   python

Що це означає: Один процес викликає високе завантаження SM. Це може бути очікувано. Це також означає, що тепло породжено навантаженням, а не «загадковим бекґраундом».

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

Завдання 15: Перевірте вузькі місця на стороні CPU, що спричиняють сплескову поведінку GPU (і дивні термали)

cr0x@server:~$ mpstat -P ALL 1 3
Linux 6.8.0 (server) 	01/13/2026 	_x86_64_	(64 CPU)

10:25:01 AM  CPU    %usr   %nice    %sys %iowait   %irq   %soft  %steal  %idle
10:25:02 AM  all   92.11    0.00    6.44    0.73   0.00    0.11    0.00   0.61

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

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

Завдання 16: Перевірте, чи cgroup/container-ліміти не спричиняють випадкову термальну поведінку

cr0x@server:~$ systemd-cgls --no-pager | head -n 25
Control group /:
-.slice
├─system.slice
│ ├─docker.service
│ │ ├─4121 /usr/bin/dockerd -H fd://
│ │ └─...
│ └─ssh.service
└─user.slice
  └─user-1001.slice
    └─user@1001.service
      └─app.slice

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

Рішення: Виправте обмеження планувальника (по одній важкій GPU-задачі на вузол) або застосуйте ліміти потужності для класів задач.

Три корпоративні міні-історії з термальних боїв

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

Команда отримала партію нових GPU-серверів — та сама модель шасі, що й у минулому кварталі, та сама модель GPU, та саме компонування стійки. Рунбук розгортання був «копіюй/встав». Так буває, поки щось не йде не так.

За кілька годин тренувальні задачі почали падати так, ніби це було програмне забезпечення: випадкові помилки CUDA, час від часу скидання драйвера, а іноді хост ливував помилки PCIe correctable. Нічого не кричало «перегрів», бо температури ядра не були шалено високими — середина 70s, іноді 80°C. Командир інциденту зосередився на версіях і відкатах.

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

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

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

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

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

Спочатку нічого не горіло. Насправді, температура ядра GPU виглядала лише трохи вищою. Тож зміни розгорнули масово. Потім почалися дивності: періодичні регресії продуктивності. Не повні відключення — їх помітити легко. Це були повільніші епохи, випадкові перевищення часу задач і інколи порушення SLA.

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

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

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

Стартап з інференсом на GPU мав звичку, яка виглядала надто базовою, щоб мати значення: кожен новий вузол проходив 30-хвилинний burn-in зі стандартним навантаженням, і вони записували базові показники: температура ядра, hotspot, температура пам’яті, швидкість вентилятора і потужність у стійкому стані.

Через шість місяців вони почали помічати кілька вузлів, що працювали на 8–12°C гарячіше при тій самій задачі. Нічого ще «не зламалося», але був дрейф. Оскільки мали базові показники, вони не сперечалися про те, що означає «нормально». У них були чеки.

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

Вони почистили, виправили прокладку, повторили burn-in і повернули вузли. Без інцидентів. Без аварійного технічного обслуговування у вихідні. Гламурна частина SRE — писати розумну автоматизацію. Частина, що зберігає роботу — це ловити нудне деградовання до того, як воно стане відмовою.

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

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

Корінна причина: Hotspot або junction пам’яті тротлять, а не температура ядра.

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

2) Симптом: «Температура миттєво підскакує при запуску навантаження»

Корінна причина: Поганий термоконтакт (висохла паста, нерівномірний притиск, зрушені подушки) або запізнення керування вентилятором.

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

3) Симптом: «Один GPU в багатокартковому боксі завжди гарячіший»

Корінна причина: Теплова рециркуляція або ефекти розміщення (верхня карта дихає виходом іншої, заблокований вхід).

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

4) Симптом: «Вентилятори гучні, а температури все ще високі»

Корінна причина: Ребра радіатора забиті пилом, поганий тиск у корпусі або обходження потоку повітря (повітря проходить навколо ребер).

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

5) Симптом: «Скидання драйвера / Xid-помилки під важкими задачами»

Корінна причина: Може бути термальною, нестабільністю подачі живлення, проблемами PCIe або маргінальним апаратним забезпеченням, що відмовляє лише при нагріванні.

Виправлення: Корелюйте логи з температурами/потужністю. Зменшіть ліміт потужності, покращіть охолодження, перевірте посадку PCIe і AER-повідомлення, оновіть прошивку/драйвер і ізолюйте ненадійне обладнання.

6) Симптом: «GPU гарячіший після зміни корпусу або «прибирання»»

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

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

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

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

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

8) Симптом: «Відмови трапляються лише в спекотні дні / при високій навколишній температурі»

Корінна причина: Немає запасу. Система охолодження працює на межі; невелика зміна вхідної температури переходить межу.

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

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

Покроково: стабілізація гарячого GPU-вузла (порядок безпечний для продакшну)

1. Підтвердіть тротлінг і обмежувач: використайте nvidia-smi -q для причин тротлінгу; визначте, термальний це фактор чи потужність чи щось інше.
2. Перевірте розкид сенсорів: ядро vs hotspot vs junction пам’яті (якщо доступно). Визначте провідний індикатор.
3. Перевірте умови входу: валідуйте вентилятори шасі, фільтри і температуру забору в стійці.
4. Застосуйте тимчасовий ліміт потужності: зменшіть на 10–20% і спостерігайте за впливом на пропускну здатність.
5. Підвищіть криву вентилятора, якщо дозволено: націлюйтеся на стабільні температури, а не на коливання.
6. Шукайте сигнали стабільності: журнали ядра на Xid, AER-помилки, несподівані скидання.
7. Очистіть і повторно протестуйте: фільтри, радіатори і перешкоди. Прогайте те саме навантаження для порівняння.
8. Заплануйте коригувальне обслуговування: повторне нанесення пасти/заміна подушок тільки після того, як повітряний потік і живлення будуть в порядку; робіть це у контрольоване вікно.
9. Задокументуйте базу: зафіксуйте стійкі температури, потужність і частоти, щоб виявляти дрейф раніше.

Чек-лист: що занотувати в інцидентному квитку

• Модель GPU, версія драйвера, прошивка (якщо релевантно)
• Опис навантаження (шаблон завантаження, тривалість, розмір батча)
• Температура ядра, hotspot, junction пам’яті (і який інструмент читав)
• Споживання потужності, ліміт потужності, pstate, частоти
• Причини тротлінгу з nvidia-smi -q
• Швидкість вентилятора і стан вентиляторів шасі
• Місце вимірювання температури входу
• Журнали ядра на Xid/AER/термальні події
• Результати до/після тесту з лімітом потужності

Чек-лист: рішення, що зазвичай кращі за «перенанесення пасти на все»

• Спочатку обмежте потужність, якщо потрібна негайна стабільність.
• Потім виправте повітряний потік (це допомагає всьому в вузлі).
• Тільки потім розглядайте repaste/re-pad — це інвазивно, непостійно і легко виконати неправильно.
• Попереджайте на дельтах і причинах тротлінгу, а не на одному порозі температури.

FAQ

1) Чи нормально, що GPU працює при 80–85°C?

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

2) У чому різниця між температурою GPU і hotspot/junction?

Температура GPU зазвичай — усереднений або репрезентативний сенсор ядра. Hotspot/junction — максимальне значення на кристалі. Hotspot знаходить погану пасту, поганий притиск і локальну щільність тепла.

3) Чому температура junction пам’яті вища за ядро?

Тому що пам’ять сама по собі є джерелом тепла і іноді має гірший контакт охолодження. Інтенсивний трафік пам’яті та певні типи GDDR можуть дуже нагріватися. Якщо junction пам’яті веде — це проблема охолодження пам’яті, а не ядра.

4) Чи варто знижувати напругу або обмежувати потужність GPU?

Обмеження потужності зазвичай безпечніше і повторюваніше для продакшн-руху: встановіть кап, виміряйте пропускну здатність і знайдіть оптимум perf/W. Undervolting може працювати, але це більш крихко через варіації кристалів і зміни драйверів/прошивки.

5) Мої вентилятори GPU на 100%, а температури все одно високі — що далі?

Це зазвичай означає, що повітря не проходить через ребра радіатора (засмічення, обходження, поганий кожух), вхід занадто гарячий або термоінтерфейс поганий. Чищення і перевірка потоку повітря перед повторним нанесенням пасти.

6) Чому багатокарткові системи працюють гарячіше, навіть якщо кожен GPU «в межах специфікації»?

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

7) Чи пошкоджує тротлінг GPU?

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

8) Чому продуктивність іноді погіршується після покращення охолодження?

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

9) Яка найефективніша зміна, щоб швидко знизити температуру GPU?

У багатьох реальних флотах: зменшення ліміту потужності на 10–20%. Це миттєво, відкатно, і часто коштує менше продуктивності, ніж ви очікуєте. Потім виправляйте повітряний потік, щоб повернути запас.

Висновок: кроки, що реально впливають

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

Зробіть це далі, у порядку:

1. Перестаньте гадати: перевіряйте причини тротлінгу і правильні сенсори (ядро, hotspot, junction пам’яті).
2. Купіть стабільність через ліміт потужності: протестуйте зниження на 10–20% і виміряйте вплив на пропускну здатність.
3. Зробіть повітряний потік нудним і правильним: чистіть, розблокуйте, шрадуйте і валідуйте температуру входу там, де GPU дихає.
4. Задокументуйте все: фіксуйте стійкі температури/потужність/частоти, щоб виявляти дрейф раніше, ніж вас покличуть.
5. Тільки потім виконуйте інвазивну роботу: repaste/re-pad під час техвікна з правильними матеріалами і процедурою.

Тепло — це не моральна поразка. Це облік. Ваше завдання — урівноважити: вати вхідні, тепло на вихід, продуктивність доставлена, відмови попереджені.