Обмеження потужності та Boost: чому ваша GPU поводиться, наче має свою голову

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

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

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

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

Справжній контракт: «до» робить багато роботи

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

Обмеження потужності (W): бюджет, який картка дозволена витрачати.
Обмеження напруги (V): що силікон і VRM витримують у конкретний момент.
Термальне обмеження (°C): що охолодження може відвести і наскільки агресивною є прошивка в захисті.
Обмеження струму/VRM: електрична реальність плати, часто невидима без інструментів вендора.
Характеристики навантаження: різні кернели навантажують різні частини кристала; «100% завантаження» — не однакова річ.

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

Цікаві факти та історичний контекст (коротко й конкретно)

Boost-частоти стали мейнстримом, бо фіксовані частоти втрачали енергоефективність. Силікон варіюється; потужність і терміка варіюються; динамічне керування дає вищу «типову» продуктивність.
NVIDIA GPU Boost (ера Kepler) зробила частоти оппортуністичними. Замість «однієї частоти» ви отримали діапазон частот, змінюваний залежно від запасу.
Датацентрові GPU не оминули boost; вони просто загорнули його в політику. Обмеження потужності, режим постійності та application clocks з’явилися, бо оператори захотіли передбачуваності.
Power viruses існують. Деякі мікс-команди інструкцій можуть тягнути непропорційно багато потужності; постачальники налаштовують регулятори частково, щоб пережити гірші випадки навантаження.
Слот PCIe і 8‑пінові конектори — це фізичні контракти живлення. Партнери по платі не можуть просто «дати газу», не зважаючи на те, що конектори й траси безпечно можуть передавати.
«TDP» — не універсальна одиниця істини. Це цільовий проєкт і маркетингове скорочення; у практиці важлива фактична споживана потужність плати і поведінка у тривалій роботі.
Температура пам’яті стала першочерговою проблемою з GDDR6X і щільними HBM-стеками. Ядро може бути «щасливим», поки пам’ять тихо смажиться й викликає тротлінг.
Криві вентиляторів змістилися від акустики до надійності. Багато «тихих» профілів дозволяють розвиватися гарячим плямам; датацентри віддають перевагу нудному потоку повітря понад приємним звуком.

Boost — не магія; це керуючий контур

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

Що оптимізує boost

Алгоритм boost зазвичай намагається максимізувати продуктивність, дотримуючись:

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

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

Одна цитата, щоб не дурити себе

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

Два види «вона сповільнилася»

Є два загальні режими відмов, які плутають:

Зниження частоти (throttling): GPU навмисно знижує частоту через обмеження потужності/терміки/напруги.
Голод конвеєра (pipeline starvation): GPU міг би працювати швидше, але чекає на пам’ять, передачі PCIe, планування CPU, диск або мережу. Це часто виглядає як «низьке завантаження» і змушує людей ганятися за неправильною проблемою.

Ось сухо-жартівливе правило: GPU із 99% завантаження може бути все одно нудьгуючим; просто дуже послідовно.

Стос обмежень: потужність, напруга, температура та «реальність плати»

Обмеження потужності: великий очевидний регулятор, що ховає гострі кути

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

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

Терміка: не лише «температура GPU», але й гарячі плями та пам’ять

Більшість людей перевіряють «температуру GPU» і рухаються далі. Це як подивитися на термостат у вестибюлі і оголосити всю будівлю в порядку. Сучасні карти мають гарячі плями (junction temp), температури пам’яті, VRM та іноді окремі сенсори для різних частин пакету. Ядро може показувати 70°C, поки якась гаряча пляма досягне порогу тротлінгу.

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

Напруга і якість силікону: чому дві «ідентичні» GPU поводяться по-різному

Навіть у межах одного SKU чипи різняться. Один GPU досягає певної частоти при меншій напрузі; іншому потрібно більше. Більша напруга — більше потужності. Більше потужності — більше тепла. Тож дві картки з однаковим обмеженням потужності можуть опинитися на різних усталених частотах. Це не «дефект». Це реальність бінінгу, що проривається у ваші графіки.

Обмеження плати: VRM, конектори та прошивкові запобіжники

Кремній — лише частина історії. Регулятори напруги плати (VRM) і шлях живлення мають обмеження. Коли VRM перегріваються, деякі карти знижують потужність чи частоту, щоб захистити себе. Ви можете не отримати гарного попередження. Ви отримаєте «таємниче» падіння продуктивності через 10–20 хвилин.

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

Чому частоти й продуктивність флуктуюють (навіть якщо ви клянетесь, що нічого не змінилося)

1) Фазові зміни навантаження

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

2) Температура навколишнього середовища й зміни повітря на вході

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

3) Політика кривої вентиляторів (акустика vs продуктивність)

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

4) Виконання обмеження потужності усереднюється, а не миттєво

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

5) Спільні домени живлення та конкуренція між GPU

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

6) Оновлення драйверів і прошивок

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

Короткий жарт #1: Оновлення драйвера — як безкоштовне підвищення продуктивності — поки це не безкоштовне зниження продуктивності з кращими нотатками випуску.

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

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

По-перше: визначте, чи ви пов’язані з обчисленням, потужністю чи очікуванням

Перевірте завантаження, частоти й потужність в період повільної роботи. Якщо завантаження високе й потужність близька до ліміту — ви обмежені потужністю. Якщо завантаження високе й температура близька до мети — ви термально обмежені. Якщо завантаження низьке — імовірно, ви чекаєте на щось інше.
Порівняйте телеметрію «хорошого» vs «поганого» запуску на тому самому хості, якщо можливо. Ви шукаєте, що змінилося: споживання потужності, температури, лічильники помилок, ширина PCIe, час відбору CPU, пропускна здатність диска.
Виявте причину ліміту (потужність vs терміка vs надійність). На NVIDIA це часто відображається як «PerfCap Reason». На AMD ви зробите висновки з SMI сенсорів і поведінки частот.

По-друге: швидко перевірте фізичний шар

Чи правильна подача повітря у шасі? Об/хв вентиляторів, температура на вході, пил, кожухи, заглушки. Проблеми з охолодженням маскуються під «випадкову продуктивність».
Чи стабільне живлення PSU/фід? Серверне обмеження потужності може притиснути GPU, не попередивши ввічливо.
Чи здоровий PCIe лінк? Зниження до x8 або Gen3 може нашкодити навантаженням, що залежать від передач даних, і спричинити дивні затримки.

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

Налаштування управління живленням (persistence, application clocks, power cap). Помилкова конфігурація — часте явище, особливо після образування або змін оркестрації.
Обмеження контейнерів/VM (MIG-партіції, cgroups, device plugin ліміти). Іноді ви «втратили продуктивність», бо отримали інший шматок обладнання.
Термальні/потужні взаємодії з іншими користувачами на тому самому хості. Шумні сусіди існують і в фізиці.

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

Це реальні завдання, які ви можете запустити сьогодні на Linux-хостах. Кожне включає (1) команду, (2) приклад виводу та (3) рішення на її підставі. Мета — операційна: ізолювати обмежувача, а потім обрати найменш ризикове виправлення.

Завдання 1: Знімок потужності GPU, частот, завантаження (NVIDIA)

cr0x@server:~$ nvidia-smi --query-gpu=name,uuid,pstate,clocks.sm,clocks.mem,temperature.gpu,power.draw,power.limit,utilization.gpu --format=csv
name, uuid, pstate, clocks.sm [MHz], clocks.mem [MHz], temperature.gpu, power.draw [W], power.limit [W], utilization.gpu [%]
NVIDIA A10, GPU-6b7..., P0, 1680, 6251, 74, 142.31, 150.00, 98

Значення: Ви близькі до обмеження потужності (142/150 W) при високому завантаженні в P0. Якщо продуктивність низька, ймовірно, ви обмежені потужністю, а не «драйвер зламався».

Рішення: Якщо терміка в нормі і бюджет PSU дозволяє, трохи підвищте ліміт потужності (або перестаньте очікувати пікових частот при жорсткому ліміті). Якщо ліміт накладено політикою, зосередьтеся на налаштуванні perf-per-watt (undervolt, планування навантажень або ф’южн кернелів).

Завдання 2: Визначити, чому GPU обмежує продуктивність (PerfCap reason)

cr0x@server:~$ nvidia-smi -q -d PERFORMANCE | sed -n '1,120p'
==============NVSMI LOG==============

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

Значення: Жодна причина тротлінгу зараз не активна. Якщо ви все ще бачите низьку продуктивність, вузьке місце ймовірно не жорсткий тротлінг; можливо, ви обмежені пам’яттю, CPU або ввід/вивід.

Рішення: Припиніть «чинити частоти». Перейдіть до профілювання (розподіл завантаження, трафік PCIe, насичення CPU) і перевірте конвеєр даних.

Завдання 3: Спостерігати за джиттером потужності/частот у часі (швидко і просто)

cr0x@server:~$ nvidia-smi --query-gpu=timestamp,power.draw,clocks.sm,temperature.gpu,utilization.gpu --format=csv -l 1 | head -n 8
timestamp, power.draw [W], clocks.sm [MHz], temperature.gpu, utilization.gpu [%]
2026/01/13 09:21:01, 148.22, 1710, 78, 99
2026/01/13 09:21:02, 149.87, 1695, 79, 99
2026/01/13 09:21:03, 150.02, 1665, 80, 99
2026/01/13 09:21:04, 149.95, 1635, 81, 99
2026/01/13 09:21:05, 149.90, 1605, 82, 99
2026/01/13 09:21:06, 149.88, 1590, 83, 99

Значення: Потужність на піку, поки температура зростає; частоти сходинками знижуються. Класична поведінка «ліміт потужності + зростаюча терміка».

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

Завдання 4: Перевірити налаштований ліміт потужності vs мін/макс підтримувані (NVIDIA)

cr0x@server:~$ nvidia-smi -q -d POWER | sed -n '1,120p'
Power Readings
    Power Management                    : Supported
    Power Draw                          : 142.31 W
    Power Limit                         : 150.00 W
    Default Power Limit                 : 150.00 W
    Enforced Power Limit                : 150.00 W
    Min Power Limit                     : 60.00 W
    Max Power Limit                     : 180.00 W

Значення: Картка може піти до 180 W, але ви обмежені на 150 W (за замовчуванням). Якщо ви очікували більше пропускної здатності, ваше очікування не узгоджується з налаштованою політикою.

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

Завдання 5: Встановити ліміт потужності (NVIDIA) і підтвердити, що він застосований

cr0x@server:~$ sudo nvidia-smi -pl 170
Power limit for GPU 00000000:65:00.0 was set to 170.00 W from 150.00 W.

cr0x@server:~$ nvidia-smi --query-gpu=power.limit,power.draw --format=csv
power.limit [W], power.draw [W]
170.00, 156.04

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

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

Завдання 6: Перевірити ширину/швидкість PCIe (NVIDIA через nvidia-smi)

cr0x@server:~$ nvidia-smi -q -d PCI | sed -n '1,140p'
PCI
    Bus                               : 00000000:65:00.0
    PCIe Generation
        Max                           : 4
        Current                       : 3
    Link Width
        Max                           : 16x
        Current                       : 8x

Значення: Ви очікували Gen4 x16, але працюєте в Gen3 x8. Це може вбити пропускно-дані навантаження й спричинити «недовантаження GPU», що виглядає як тротлінг.

Рішення: Перевірте налаштування BIOS, посадку riser, біпфуркацію ліній і чи не вкрала інша карта лінії. Виправляйте PCIe перш ніж чіпати частоти.

Завдання 7: Підтвердити драйвер ядра та persistence mode (NVIDIA)

cr0x@server:~$ nvidia-smi --query-gpu=driver_version,persistence_mode --format=csv
driver_version, persistence_mode
550.54.14, Disabled

Значення: Режим persistence вимкнений. Це може додавати латентності й викликати стрибки частот/pstate між завданнями, особливо для короткоживучих задач.

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

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

Завдання 8: Примусово встановити application clocks (де підтримується) для передбачуваності

cr0x@server:~$ nvidia-smi -q -d SUPPORTED_CLOCKS | sed -n '1,80p'
Supported Clocks
    Memory                             : 6251 MHz
        Graphics                       : 1710 MHz
        Graphics                       : 1680 MHz
        Graphics                       : 1650 MHz

cr0x@server:~$ sudo nvidia-smi -ac 6251,1680
Applications clocks set to "(MEM 6251, SM 1680)" for GPU 00000000:65:00.0

Значення: Ви обміняли оппортуністичний boost на стабільні частоти (в межах потужності/терміки). Це зменшує коливання між прогоном у багатьох пакетних навантаженнях.

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

Завдання 9: Перевірити ECC-помилки, що корелюють із тротлінгом або повторними запитами

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

Значення: Ви бачили скориговані помилки історично. Не обов’язково фатально, але може корелювати з маргінальною термікою, старінням заліза або занадто агресивним тюнінгом.

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

Завдання 10: Перевірити тактові частоти/потужність/температури AMD GPU (інструменти ROCm)

cr0x@server:~$ rocm-smi --showtemp --showpower --showclocks --showuse
===================== ROCm System Management Interface =====================
GPU  Temp   AvgPwr  SCLK     MCLK     GPU%  
0    79.0c  262.0W  1720Mhz  1200Mhz  97%

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

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

Завдання 11: Підтвердити навантаження CPU і планування (не звинувачуйте GPU за проблеми CPU)

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

09:24:01     CPU    %usr   %nice    %sys %iowait   %irq   %soft  %steal  %idle
09:24:02     all   62.10    0.00   12.55    8.31   0.00    1.22    0.00  15.82
09:24:02      7   98.00    0.00    1.00    0.00   0.00    0.00    0.00   1.00
09:24:02     19   97.00    0.00    2.00    0.00   0.00    0.00    0.00   1.00

Значення: Деякі CPU практично на 100%. Якщо ваш пайплайн CPU-важкий (підготовка даних, стиснення, аугментація), GPU може голодувати й показувати періодичні провали завантаження.

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

Завдання 12: Виявити вузькі місця вводу/виводу (зберігання або мережа), що виглядають як «GPU не піднімається»

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

avg-cpu:  %user   %nice %system %iowait  %steal   %idle
          41.12    0.00   10.44   18.90    0.00   29.54

Device            r/s     rkB/s   rrqm/s  %rrqm r_await rareq-sz     w/s     wkB/s   w_await aqu-sz  %util
nvme0n1         220.0  35200.0     0.0    0.0    8.90   160.0     40.0   5120.0    3.20   2.10  92.0

Значення: Високий iowait та ~92% завантаження пристрою. Ваш загрузчик даних може голодувати GPU, викликаючи провали завантаження й нижчі середні частоти.

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

Завдання 13: Вловити термальні проблеми через системні сенсори (вентилятори й шасі)

cr0x@server:~$ sensors | sed -n '1,120p'
coretemp-isa-0000
Adapter: ISA adapter
Package id 0:  +86.0°C  (high = +90.0°C, crit = +100.0°C)

nvme-pci-0100
Adapter: PCI adapter
Composite:    +79.9°C  (low  =  -0.1°C, high = +84.8°C)

ipmi_si-isa-0000
Adapter: ISA adapter
System Fan1:  9800 RPM
System Fan2:  9600 RPM

Значення: Системні температури та NVMe вищі; вентилятори вже визвихають. Якщо GPU тротлить, можливо, причина — охолодження шасі або температура на впуску, а не «GPU».

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

Завдання 14: Перевірити обмеження потужності на рівні сервера (IPMI)

cr0x@server:~$ sudo ipmitool dcmi power reading
    Instantaneous power reading:                   980 Watts
    Minimum during sampling period:                740 Watts
    Maximum during sampling period:               1080 Watts
    Average power reading over sampling period:    945 Watts

Значення: Споживання сервера близьке до того, що багато БЖ/фідів шафи можуть витримати. Деякі платформи застосовують обмеження або «power brake» при наближенні до ліміту.

Рішення: Підтвердіть політики BIOS/прошивки щодо потужності. Якщо платформа застосовує «power-braking» під навантаженням, зміни на рівні GPU не стабілізують продуктивність, поки ви не вирішите бюджет платформи.

Завдання 15: Переконатися, що ніхто випадково не поставив прихований низький ліміт потужності (пersistence та boot-скрипти)

cr0x@server:~$ grep -R --line-number "nvidia-smi -pl" /etc /usr/local 2>/dev/null | head
/etc/systemd/system/gpu-tune.service:9:ExecStart=/usr/bin/nvidia-smi -pl 120

Значення: Є systemd-юніт, що форсує ліміт 120 W. Це пояснює «раптову» регресію продуктивності після провізії.

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

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

Міні-історія №1: Інцидент через хибне припущення

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

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

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

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

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

Команда продуктивності хотіла кращий perf-per-watt. Вони протестували undervolting на невеликому наборі GPU, побачили гарні результати і впровадили у золоту збірку. Середня пропускна здатність стала трохи кращою, а графіки по витраті електроенергії — приємнішими. Всі відчули себе розумними.

Потім з’явилися рідкі відмови. Не відразу. Через кілька тижнів деякі роботи почали падати з помилками CUDA «illegal memory access». Не у всіх задачах, не на всіх вузлах. Найгірший тип багу: переривчастий, залежний від навантаження і не відтворюваний у робочий час.

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

Виправлення полягало в тому, щоб ставитися до undervolting як до будь-якої зміни з потенційним blast radius: профілі per‑SKU, довші soak-тести і введення за певні робочі навантаження. Вони зберегли undervolting, але перестали вдавати, що це безкоштовний подарунок. Ви можете обміняти ватти на надійність; просто треба це чітко озвучити.

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

Команда, яка запускає inference на GPU, мала стару практику: на кожному вузлі перед допуском у пул виконували базову «термальну та потужну характеристику» у CI. Це не було гламурно. Це був довготривалий тест, що випускав кілька графіків і мітку пройшов/не пройшов.

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

Оскільки вони це виявили до продукції, вони підкоригували розміщення у шафі (холодніші зони для тих вузлів), оновили політику ліміту потужності і уникнули перевантаження флоту inference. Жодного інциденту. Жодного пейджера. Просто внутрішня замітка: «Нова ревізія поводиться інакше; планувати відповідним чином.»

Тяжко святкувати інциденти, яких не сталося, але це саме робота. Нудні практики часто є єдиними, що масштабуются.

Короткий жарт #2: Найкращий тип аутейджу — той, якого ви запобігли. Другий кращий — той, що стався під час вашої відпустки.

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

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

1) Симптом: «Boost-частота ніколи не досягає рекламованого числа»

Корінь: Рекламований boost оппортуністичний і залежить від запасу; ви обмежені потужністю або термікою, або ваше навантаження важке й викликає нижчі усталені біни.
Виправлення: Заміряйте усталені частоти під реальним навантаженням; встановіть реалістичні очікування. Покращте охолодження, підвищте ліміт потужності (якщо безпечно) або використайте application clocks для передбачуваності.

2) Симптом: «Продуктивність чудова 60 секунд, а потім падає»

Корінь: Термальна прогрівка. РАДІАТОР, пам’ять, VRM досягають усталеного стану й вмикають термальні цілі або захист VRM.
Виправлення: Проганяйте 20–30 хв тест; виправте повітряний потік, криві вентиляторів, замініть термопасту/прокладки, якщо треба, або трохи зменшіть ліміт потужності, щоб уникнути перегрівання.

3) Симптом: «Завантаження GPU низьке; частоти низькі; має бути тротлінг»

Корінь: GPU чекає — CPU препроцесинг, I/O вузьке місце, передача PCIe, синхронізація або малі batch-розміри.
Виправлення: Перевірте iowait, насичення CPU, лінк PCIe і перекриття пайплайну. Оптимізуйте вхід даних, збільшіть batch розмір, якщо можливо, і префетчте.

4) Симптом: «Та сама задача, різні вузли, 15–25% варіація»

Корінь: Різні зони охолодження, різна якість силікону, різні ліміти потужності, різні стани PCIe, або різні фонові користувачі.
Виправлення: Стандартизувати: впровадити ліміти потужності через CM, перевірити PCIe, охарактеризувати вузли й ізолювати шумних сусідів.

5) Симптом: «Після оновлення драйвера споживання потужності змінилося й частоти виглядають дивно»

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

6) Симптом: «Підвищення ліміту потужності не збільшило продуктивність»

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

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

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

8) Симптом: «GPU помилки або падіння задач після undervolting/overclocking»

Корінь: Зменшена маржа стабільності; boost іноді вибирає нестабільні V/F точки; зміни температури змінюють стабільність.
Виправлення: Відкотіть до стоку, потім поетапно вводьте тюнінг з soak-тестами й моніторингом помилок. У продакшені віддавайте пріоритет коректності над «показниками».

Контрольні списки / покроковий план (цілеспрямована стабільність)

Контрольний список A: Встановіть надійну базу

Виберіть одне репрезентативне сталеве навантаження (не 30‑секундний бенч). Проганяйте 20–30 хвилин.
Зберіть телеметрію: споживання потужності, ліміт потужності, частоти, температура, завантаження і будь-які причини тротлінгу.
Запишіть середовище: температура на вході, політика вентиляторів, модель шасі, версія драйвера, версія прошивки.
Задокументуйте очікувані усталені діапазони: «Потужність 145–155 W, темп 70–78°C, частоти 1600–1700 MHz.»

Контрольний список B: Визначте, чого ви справді хочете (пік vs передбачуваність)

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

Контрольний список C: Послідовність безпечного тюнінгу (робіть це, а не крутити ручки без плану)

Виправте потік повітря спершу. Стабільне термальне середовище робить кожну іншу зміну простішою для пояснення.
Встановіть/перевірте політику ліміту потужності (і забезпечте її збереження після перезавантажень).
Тестуйте application clocks, якщо платформа їх підтримує і ваше навантаження виграє від стабільності.
Лише потім розгляньте undervolting, з soak‑тестами й моніторингом помилок.
Повторіть базове навантаження і порівняйте усталені метрики, а не першу хвилину.

Контрольний список D: На що ставити оповіщення (сюрпризи — ворог)

Стійке споживання потужності, прижатий до ліміту з падаючими частотами: ви обмежені потужністю; планування потужностей має передбачати цей стан.
Температура наближається до мети при зростаючих об/хв вентиляторів: ви близько до термальної межі; один гарячий день може знизити продуктивність.
PCIe лінк знижено (Gen/ширина): означає проблеми з посадкою/BIOS або конкуренцію ресурсів платформи.
Правильно скориговані ECC-помилки в тренді вгору: можуть бути раннім попередженням маргінальності апаратного забезпечення або занадто агресивного тюнінгу.

ЧаПи

1) Чому моя GPU змінює частоту навіть при 100% завантаженні?

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

2) Чи «обмеження потужності» те саме, що TDP?

Ні. TDP — термін проєктної цілі, який різні вендори використовують по-різному. Обмеження потужності — це політика, що застосовується (часто в ватах) і яка безпосередньо обмежує алгоритм boost. Операційно контролювати й вимірювати можна саме обмеження потужності.

3) Якщо я підніму ліміт потужності, чи завжди покращиться продуктивність?

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

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

Перевірте, чи power.draw сидить близько до power.limit, поки завантаження високе і частоти нижчі за максимально підтримувані. На NVIDIA «PerfCap reason» або причини тротлінгу можуть це підтвердити.

5) Чому дві ідентичні GPU мають різні усталені частоти?

Варіація силікону (різна напруга для однієї й тієї ж частоти), невеликі різниці в охолодженні, відмінності плати/VRM і навіть натиск монтажу можуть давати помітні розбіжності. У флоті сприймайте продуктивність як розподіл, а не одне число.

6) Чи слід блокувати application clocks у продакшені?

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

7) Чи знижує undervolting продуктивність?

Може, але часто ні, якщо ви обмежені потужністю. Undervolt може дозволити утримувати вищі частоти в тому самому ліміті потужності. Підступ — стабільність: треба soak‑тести під реальним набором кернелів і стежити за помилками.

8) Чому моя GPU «холодна», але все одно повільна?

Бо можливо вона чекає на CPU, зберігання, мережу або передачі PCIe. Холодна GPU з низьким завантаженням зазвичай недоодержує дані, а не тротлить. Виправляйте конвеєр, а не криву вентилятора.

9) Чи може контейнеризація впливати на boost і поведінку потужності?

Так. Контейнери можуть змінювати доступність CPU, I/O поведінку і конкуренцію завдань, що змінює duty cycle GPU. Також device plugins і партиціювання (наприклад MIG) можуть змінити ту частку обладнання, яку ви отримуєте.

10) Що стандартизувати по GPU-флоту?

Версії драйверів/прошивки, політику ліміту потужності, persistence mode, політику вентиляторів/повітряного потоку і базовий тест характеристик усталеного стану. Стандартизація — це те, як ви перетворюєте «мистецтво» на операції.

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

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

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

Виміряйте усталену поведінку під реальними навантаженнями (20–30 хв), а не імпульсні бенчмарки.
Визначте обмежувач: потужність, терміка або «чекання на щось інше».
Виправте фізичний шар: потік повітря, температура на вході, здоров’я PCIe, політика живлення сервера.
Виберіть політику: передбачувані частоти (application clocks) або оппортуністичний boost (з термальним запасом).
Точно налаштовуйте: ліміти потужності спочатку, undervolt наприкінці, і тільки з soak‑тестами та моніторингом помилок.

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

Схожі статті

TGP у ноутбуках: число, яке бренди люблять приховувати Плавлення роз’ємів: коли «стандарт» перетворюється на скандал Чому GPU нагріваються: просте пояснення, що запам’ятовується