Зниження напруги GPU: тихий трюк продуктивності, про який не кажуть

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

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

Чим воно не є:

• Не зниження частоти: ви можете знижувати напругу і зберігати високі тактові частоти. Пониження частоти зменшує частоту; зниження напруги зменшує напругу. Можна робити обидва, але не плутайте.
• Не «безкоштовний розгін»: ви оптимізуєте робочу точку. Якщо вам потрібні пікові бенчмарк-числа для скріншотів — це інше хобі.
• Не гарантія безпеку гарантії: деякі постачальники розглядають правки кривих як «тюнінг». У дата-центрі обмеження потужності зазвичай безпечніше, ніж редагування кривих напруги.
• Не універсальна налаштування: дві однакові моделі GPU можуть мати різну якість кремнію. Ви не копіюєте числове значення напруги, як Kubernetes-манифест.

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

Чому це працює: поведінка boost, ліміти потужності та теплові реалії

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

Потужність — тихий обмежувач продуктивності

Споживання GPU приблизно пропорційне V² × f (напруга у квадраті, помножена на частоту), плюс витік.
Саме квадратична залежність робить зниження напруги таким ефективним. Зменшіть трохи напругу — і ви часто скоротите помітну частину споживання,
що знижує температуру, що зменшує витік, що знову знижує потужність. Це позитивний зворотний зв’язок — у хорошому напрямку.

Чому “менше напруги” може означати “швидше”

Коли ви обмежені потужністю або температурою, GPU розганяється до межі, а потім відступає.
Якщо знизити напругу, ті самі частоти споживатимуть менше ват. Отже GPU може підтримувати вищі частоти довше, перш ніж
досягне стелі. Середня частота підвищується. Час виконання задачі зменшується.

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

Троттлінг — це не провал; це симптом

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

Одна цитата, яку люди в операціях розуміють не з першого разу:
перефразована думка: Все ламається постійно; ваше завдання — проектувати для цього. — Werner Vogels

Зниження напруги — частина проєктування під реальність: потужність і охолодження обмежені, а ваші робочі навантаження не зупиняються о 17:00.

Факти та історія: як ми дійшли до цього

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

8 конкретних фактів, які роблять зниження напруги логічним

1. Динамічне масштабування напруги і частоти (DVFS) існує вже десятиліттями; CPU і GPU давно підбирають «достатню напругу» для продуктивності.
2. Бірування існує через різницю чіпів: два кристали з тієї ж пластини можуть потребувати різної напруги для тієї самої частоти. Стандартні значення мають покривати слабший кінець розподілу.
3. Алгоритми на кшталт GPU Boost зробили частоти можливими для змін, а не фіксованими, тож потужність і температура стали справжніми регуляторами.
4. Доставка живлення ускладнилася: сучасні GPU мають багато ліній живлення і агресивну перехідну поведінку; виробники закладають запас для переживання сплесків.
5. Норми техпроцесу зменшилися, витік зріс: на менших техпроцесах витік і гарячі точки стали важливою частиною історії потужності, а не лише комутаційна потужність.
6. Дата-центри почали рахувати вати як гроші: бо це гроші—капітальні витрати, експлуатаційні витрати і можливість розмістити більше обчислень у наявному приміщенні.
7. Мобільний кремній навчив культурі ефективності: GPU для ноутбуків і SoC нормалізували ідею, що управління енергією — це управління продуктивністю.
8. Теплова щільність стала новою частотою: ви не можете «просто ще краще охолодити» нескінченно; тепловий потік і акустичні обмеження перетворюються на жорсткі рамки.

Жарт 1/2: Зниження напруги схоже на нарешті привести дієту до ладу замість купівлі більшого ременя. Менш ефектно, але ваше майбутнє «я» вам подякує.

Де зниження напруги допомагає (і де ні)

Де воно найбільше сяє

• Тривале обчислення: тренування, інференс, рендеринг, транскодування, наукове моделювання. Усе, що працює довше й дає теплове насичення.
• Акустика та теплові бюджети: робочі станції в офісах, edge-розгортання, стійки з обмеженим повітряним потоком.
• Висока щільність мультикарт: коли кілька карт ділять повітряний потік шасі і «середня карта» живе в найсуворіших умовах.
• Середовища з обмеженням потужності: колокація, лабораторні ланцюги, спільні UPS або жорсткі обмеження на рівні стійки.
• Передбачуваність: зменшення троттлінгу знижує варіативність запусків, що важливо в продукційних пайплайнах.

Де це марна трата часу

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

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

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

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

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

• Перевірте завантаження GPU та частоти під час навантаження.
• Якщо завантаження низьке, інспектуйте CPU, I/O, завантажувач даних, мережу або розклад завдань.

Друге: перевірте на троттлінг (потужність, тепло, надійність)

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

Третє: перевірте «дратівливі» центрові речі

• Правильно чи узгоджено швидкість/ширина лінії PCIe.
• MIG/vGPU-партитини, що обмежують ресурси.
• ECC-помилки або Xid-події, що спричиняють повтори або скидання контексту.
• Криві вентиляторів або проблеми з повітряним потоком шасі, які змушують одну GPU частіше троттлити.

Четверте: налаштовуйте для ефективності, а не для хизування

• Почніть з обмеження потужності (просто, відкатно, зручно для аудиту).
• Якщо потрібно більше — налаштовуйте частоту та криву напруга/частота (ризиковіше, більш варіативно).
• Тестуйте стабільність з вашим реальним шаблоном навантаження, а не лише синтетичним burn-тестом.

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

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

Завдання 1: Ідентифікувати GPU та базову інформацію драйвера

cr0x@server:~$ nvidia-smi
Tue Jan 13 10:12:04 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 RTX A5000              Off   | 00000000:3B:00.0  Off |                  N/A |
| 30%   67C    P2               188W / 230W|   8120MiB / 24576MiB |     92%      Default |
+-----------------------------------------+----------------------+----------------------+

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

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

Завдання 2: Перевірити, чи режим persistence допомагає або шкодить

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

Значення: Режим persistence тримає контекст драйвера «теплим»; це може знизити затримку першого завдання і запобігти дивностям зі станами тактів/потужності.

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

Завдання 3: Логувати потужність, частоти, температуру з часом («перестаньте гадати»)

cr0x@server:~$ nvidia-smi --query-gpu=timestamp,pstate,clocks.sm,clocks.mem,temperature.gpu,power.draw,power.limit,utilization.gpu --format=csv -l 2
timestamp, pstate, clocks.sm [MHz], clocks.mem [MHz], temperature.gpu, power.draw [W], power.limit [W], utilization.gpu [%]
2026/01/13 10:14:00, P2, 1785, 7001, 69, 192.34, 230.00, 94
2026/01/13 10:14:02, P2, 1740, 7001, 72, 201.11, 230.00, 95
2026/01/13 10:14:04, P2, 1650, 7001, 78, 229.85, 230.00, 96

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

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

Завдання 4: Перевірити причини троттлінгу (курок)

cr0x@server:~$ nvidia-smi -q -d PERFORMANCE
==============NVSMI LOG==============

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
    Sync Boost                              : Not Active
    SW Thermal Slowdown                     : Not Active
    Display Clock Setting                   : Not Active

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

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

Завдання 5: Подивитися доступні ліміти потужності та стандартний кап

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

Power Readings
    Power Management                  : Supported
    Power Draw                        : 201.11 W
    Power Limit                       : 230.00 W
    Default Power Limit               : 230.00 W
    Enforced Power Limit              : 230.00 W
    Min Power Limit                   : 120.00 W
    Max Power Limit                   : 230.00 W

Значення: Можна встановити від 120W до 230W. Цей діапазон — ваш безпечний важіль «обмеження потужності».

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

Завдання 6: Застосувати power cap (найдружніший до продакшну проксі-метод)

cr0x@server:~$ sudo nvidia-smi -i 0 -pl 200
Power limit for GPU 00000000:3B:00.0 was set to 200.00 W from 230.00 W.

Значення: Ви обмежили максимальну потужність GPU. Це часто зменшує напругу і автоматично підвищує ефективність.

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

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

cr0x@server:~$ nvidia-smi --query-gpu=clocks.sm,power.draw,temperature.gpu,utilization.gpu --format=csv -l 2
clocks.sm [MHz], power.draw [W], temperature.gpu, utilization.gpu [%]
1800, 198.22, 70, 95
1800, 199.01, 71, 96
1800, 199.44, 71, 96

Значення: Стабільні частоти при нижчому споживанні — це вся суть. Якщо раніше GPU коливався між 1650–1800 MHz, а тепер стабільно сидить на 1800 MHz, ви щойно купили реальну пропускну здатність.

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

Завдання 8: Перевірити ширину й швидкість PCIe (щоб не звинувачувати потужність за проблему шини)

cr0x@server:~$ nvidia-smi -q | sed -n '/PCI/,/GPU Link/p'
    PCI
        Bus                               : 0x3B
        Device                            : 0x00
        Domain                            : 0x0000
        Bus Id                            : 00000000:3B:00.0
        GPU Link Info
            PCIe Generation
                Max                       : 4
                Current                   : 1
            Link Width
                Max                       : 16x
                Current                   : 1x

Значення: Якщо ви бачите Gen1 x1, коли очікували Gen4 x16, ваше навантаження може бути звужене PCIe, а не напругою GPU.

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

Завдання 9: Підтвердити, що навантаження прив’язане до GPU (швидко і грубо)

cr0x@server:~$ nvidia-smi dmon -s pucvmt -d 2 -c 5
# gpu   pwr gtemp mtemp  sm   mem   enc   dec   mclk   pclk
# Idx     W     C     C   %     %     %     %   MHz    MHz
    0   199    71     -  96    42     0     0  7001   1800
    0   199    71     -  97    41     0     0  7001   1800
    0   198    71     -  96    41     0     0  7001   1800
    0   199    71     -  97    42     0     0  7001   1800
    0   199    72     -  96    42     0     0  7001   1800

Значення: «sm» близько 100% вказує на те, що обчислення завантажує GPU. Якщо «sm» низький, а CPU завантажений або I/O насичений, зниження напруги практично нічого не змінить.

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

Завдання 10: Перевірити CPU, пам’ять та вузькі місця I/O (щоб не ганятися за привидами)

cr0x@server:~$ vmstat 2 5
procs -----------memory---------- ---swap-- -----io---- -system-- ------cpu-----
 r  b   swpd   free   buff  cache   si   so    bi    bo   in   cs us sy id wa st
 8  0      0 421032  52224 812340    0    0    12    34  812 1490 62 11 26  1  0
 9  0      0 418900  52224 811998    0    0    10    22  790 1522 64 10 25  1  0
12  1      0 120044  52180 812100    0    0  9020  1100  920 1801 55 12 16 17  0
10  2      0  98020  52000 812220    0    0 12010  2300  980 2102 48 10 12 30  0

Значення: Зростання «wa» (I/O wait) і великі «bi/bo» означають, що CPU чекає на диск. Ваш GPU може бути голодним за даними.

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

Завдання 11: Шукати помилки GPU і скидання (стабільність перед хитрощами)

cr0x@server:~$ sudo dmesg -T | egrep -i "NVRM|Xid|gpu" | tail -n 8
[Tue Jan 13 10:20:11 2026] NVRM: Xid (PCI:0000:3b:00): 31, Ch 0000007e, intr 00000000. MMU Fault
[Tue Jan 13 10:20:11 2026] NVRM: Xid (PCI:0000:3b:00): 13, Graphics Engine Exception
[Tue Jan 13 10:20:12 2026] NVRM: GPU 0000:3b:00.0: GPU has fallen off the bus.

Значення: Xid-помилки можуть вказувати на баги драйвера, нестабільні частоти/напругу, поганий сигнал PCIe або проблеми з живленням. «Fallen off the bus» — не привід для налаштувань; це інцидент.

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

Завдання 12: Підтвердити лічильники ECC і помилок пам’яті, де доступно

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

ECC Mode
    Current                            : Enabled
    Pending                            : Enabled
ECC Errors
    Volatile
        Single Bit
            Device Memory              : 0
        Double Bit
            Device Memory              : 0
    Aggregate
        Single Bit
            Device Memory              : 2
        Double Bit
            Device Memory              : 0

Значення: Агреговані одно-бітні корекції можуть бути нормою за тривале життя; сплески або двобітні помилки — проблема. Нестабільні undervolt-настроювання іноді проявляються як помилки пам’яті, залежно від архітектури і умов.

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

Завдання 13: Перевірити, чи ваш power cap дійсно зберігається (або навмисно ні)

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

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

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

Завдання 14: Створити невеликий systemd-юнит для застосування ліміту потужності при завантаженні

cr0x@server:~$ cat /etc/systemd/system/gpu-powercap.service
[Unit]
Description=Set NVIDIA GPU power limit
After=multi-user.target

[Service]
Type=oneshot
ExecStart=/usr/bin/nvidia-smi -i 0 -pl 200

[Install]
WantedBy=multi-user.target

cr0x@server:~$ sudo systemctl daemon-reload
cr0x@server:~$ sudo systemctl enable --now gpu-powercap.service
Created symlink /etc/systemd/system/multi-user.target.wants/gpu-powercap.service → /etc/systemd/system/gpu-powercap.service.

Значення: Ви операціоналізували налаштування. Нікому не потрібно пам’ятати ручний крок о 2:00 ночі.

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

Завдання 15: Порівняти продуктивність на ват (потрібен метрика, яку розуміє керівництво)

cr0x@server:~$ python3 - <<'PY'
import time, subprocess, statistics
def sample(n=10, interval=1):
    p=[]
    for _ in range(n):
        out=subprocess.check_output(["nvidia-smi","--query-gpu=power.draw","--format=csv,noheader,nounits"]).decode().strip()
        p.append(float(out.splitlines()[0]))
        time.sleep(interval)
    return statistics.mean(p), statistics.pstdev(p)
mean, sd = sample()
print(f"avg_power_w={mean:.2f} stdev_w={sd:.2f}")
PY
avg_power_w=199.12 stdev_w=0.63

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

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

Методи: обмеження потужності, криві напруга/частота та «не міняйте прошивку»

Метод A: обмеження потужності спочатку (рекомендовано для продакшну)

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

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

Практичний підхід:

• Зменшуйте кроками (наприклад, 10–15% за раз).
• Запускайте реальне навантаження досить довго, щоб досягти теплового насичення (мінімум 10–30 хвилин).
• Логуйте частоти/потужність/температуру; фіксуйте пропускну здатність.
• Зупиняйтесь, коли продуктивність помітно падає або коли порушуються SLO щодо затримки.

Метод B: фіксація частот (іноді корисно, іноді пастка)

Блокування тактових частот GPU може зробити продуктивність передбачуваною, що корисно для інференсу з вимогами до латентності.
Але блокування частот також може змусити картку тримати вищу напругу, ніж потрібно, або боротися з алгоритмом boost у невигідний спосіб.

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

Метод C: редагування кривої напруга/частота (потужний, висококонтактний)

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

У кластерах редагування кривих має дві проблеми:

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

Метод D: опція «не чіпайте», яка все одно допомагає

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

Жарт 2/2: Найпростіший undervolt — протерти пиловий фільтр. Це найменш модний тюнінг продуктивності, і саме тому він працює.

Тестування стабільності, яке не витратить ваш тиждень

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

Що означає «стабільно» в продакшні

• Немає скидань драйвера: жодних Xid-штормів, жодних «fallen off the bus».
• Немає регресій правильності: розподіли вихідних даних лишаються консистентними; немає нез’ясованих NaN.
• Немає довгого зниження частот: продуктивність не деградує повільно, коли шасі нагрівається.
• Передбачувані хвостові затримки: p95/p99 не повинні погіршуватися через періодичний троттлінг або повтори.

Дизайн тестів, що поважає реальність

Використовуйте принаймні два шаблони:

• Стійкий стан: постійне навантаження 30–60 хвилин. Це знаходить проблеми теплової рівноваги.
• Цикли піку + простою: робоче навантаження, яке ви реально маєте в продакшні. Це виявляє баги переходів DVFS і транзієнтні проблеми з потужністю/напругою.

Що логувати під час тестів

• clocks.sm, clocks.mem
• power.draw, power.limit
• temperature.gpu (і hotspot, якщо доступно через інструменти)
• utilization.gpu, використання пам’яті
• dmesg на предмет Xid, логи додатків на предмет NaN або повторів

Критерії прийнятності, які можна захистити

• Пропускна здатність у межах ±1–2% від бази (або покращена) у стійкому навантаженні.
• Немає зростання лічильників помилок; немає нових помилок ядра/драйвера.
• Нижче середнє споживання або нижча температура при рівній пропускній здатності.
• Зменшена варіативність: менше падінь частот, щільніший розподіл затримок.

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

Історія 1: Інцидент через неправильне припущення («заводські налаштування — безпечні»)

Команда розгорнула нові GPU-вузли для тренування моделей. Той самий постачальник, те саме шасі, той самий «затверджений» образ.
Єдина різниця — розташування: тепліший ряд, трохи гірший повітряний потік і PDU, що працював ближче до свого ліміту.
Усе пройшло швидкі smoke-тести.

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

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

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

Історія 2: Оптимізація, що відкотилася («ми можемо йти нижче — все ок»)

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

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

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

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

Історія 3: Нудна, але правильна практика, що врятувала день («спочатку вимірюй, зміни один раз»)

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

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

Через місяць оновлення драйвера трохи змінило поведінку boost. На неналаштованих вузлах варіативність продуктивності зросла — деякі завдання уповільнювалися в години пікового навантаження.
На налаштованих вузлах кап потужності працював як запобіжник: температури і частоти лишалися в передбачуваних межах.
Налаштовані вузли стали «відомим добрим» базисом під час огляду інцидентів.

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

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

1) Продуктивність погіршала одразу після зниження напруги

Симптом: Пропускна здатність падає, частоти GPU нижчі, ніж раніше, завантаження все ще високе.

Корінь проблеми: Обмеження потужності занадто агресивне; ви опустилися нижче коліна кривої і GPU не може підтримувати цільову частоту.

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

2) Випадкові падіння завдань після годин «нормальної» роботи

Симптом: Довгі тренування падають; dmesg показує Xid-помилки або скидання GPU.

Корінь проблеми: Крива напруга/частота занадто оптимістична для конкретної карти при нагріванні; або PSU/PCIe нестабільність виявилася під транзієнтами.

Виправлення: Відкотіть до стандартних налаштувань або використовуйте консервативний power cap, протестуйте при гірших умовах; перевірте посадку PCIe і кабелі живлення; уникайте налаштування кривих на рівні карти у флоті.

3) Менше потужності, але ніякого покращення продуктивності

Симптом: Вати впали, але Wall-clock час незмінний і завантаження GPU не пропікає.

Корінь проблеми: Вузьке місце в CPU, I/O або мережі; GPU не є обмежувачем.

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

4) Одна карта в багатокартковій системі троттлить, інші ні

Симптом: GPU 2 завжди гарячіший, нижчі частоти, більше прапорців троттлінгу.

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

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

5) Налаштування «не виживають» після перезавантаження

Симптом: Після перезавантаження ліміт потужності повертається до стандарту.

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

Виправлення: Використайте systemd-юнит (як показано) або інструмент конфігураційного менеджменту, щоб встановлювати відомі добрі ліміти при завантаженні.

6) Хвости латентності погіршилися, поки середнє виглядає добре

Симптом: p99 латентність стрибкообразно росте під навантаженням; середня пропускна здатність ок.

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

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

7) Вентилятори стали тихішими, але GPU все ще гарячий

Симптом: Менше шуму, але температури близькі до ліміту, частоти хиткі.

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

Виправлення: Залишайте зниження напруги/обмеження потужності, але виправте повітряний потік. Тиша приємна; стабільність — обов’язкова.

Контрольні списки / покроковий план

Покроково: безпечне для продакшну зниження напруги через power cap

1. База: зафіксуйте модель, версію драйвера, стандартний ліміт потужності і пропускну здатність навантаження.
2. Спостереження: логування частот, потужності, температури і причин троттлінгу під репрезентативним запуском.
3. Підтвердіть вузьке місце: переконайтеся, що завантаження GPU високе й присутній троттлінг (потужність/тепло).
4. Застосуйте помірний кап: зменшіть ліміт потужності приблизно на 10–15%.
5. Тест теплового насичення: запустіть навантаження 30–60 хвилин; логуйтесь.
6. Оцініть: порівняйте пропускну здатність, варіативність, помилки й температури.
7. Ітерація: зменшуйте далі поки не впаде продуктивність або не погіршиться хвостова латентність.
8. Кодифікуйте: реалізуйте механізм застосування при завантаженні (systemd/CM).
9. Канарка: розгорніть на невеликій підмножині; моніторте тиждень реального навантаження.
10. Рол-аут: розширюйте поступово; зберігайте простий відкат.

Покроково: стиль робочої станції з правкою кривих (високий контакт)

1. Почніть з power cap у будь-якому разі; він дає безпечну базу.
2. Виберіть цільову стійку частоту, яку ви вже спостерігаєте під навантаженням.
3. Поступово знижуйте напругу, тримаючи цю частоту; тестуйте на теплові умови.
4. Зупиніться при першій ознаці нестабільності (помилки, скидання, NaN) і відійдіть назад.
5. Документуйте налаштування для кожної карти, а не лише для моделі. Так, це дратує. Це реальність.

Операційний чекліст: що моніторити постійно

• Споживання потужності GPU і застосований ліміт
• Причини троттлінгу
• Температура і поведінка вентиляторів (включно з hotspot, якщо збирається)
• Xid-помилки / скидання драйвера
• Розподіл пропускної здатності задач та хвостова латентність
• Лічильники ECC, де застосовно

Часті питання

1) Чи безпечно знижувати напругу для GPU?

Нижча напруга загалом менш електрично напружує компоненти, ніж вища, але «безпечно» в операційному сенсі означає «стабільно і правильно».
Нестабільний undervolt може спричинити падіння задач або пошкодження результатів. Використовуйте консервативні power cap спочатку, а потім валідуйте стабільність.

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

Бо ви зменшуєте потужність і тепло, що знижує троттлінг. GPU може підтримувати вищі boost-частоти довше в тих же межах.
Середні частоти важливіші за пікові.

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

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

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

Подивіться на причини троттлінгу і корелюйте частоти з потужністю і температурою. Якщо потужність упирається в ліміт і «SW Power Cap» активний — це обмеження по потужності.
Якщо температура досягає ліміту і «HW Thermal Slowdown» активний — це теплове обмеження.

5) Яке розумне перше зниження power cap?

Приблизно 10–15% нижче від стандарту — практичний старт. Далі вимірюйте. Єдиний неправильний крок — зробити великий стрибок і назвати це «налаштуванням».

6) Чи зниження напруги зменшить термін служби GPU?

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

7) Чи допомагає зниження напруги для навантажень, обмежених пам’яттю?

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

8) Чи можна застосувати ті самі налаштування для всіх GPU однієї моделі?

Для power cap зазвичай так, у межах розумного. Для редагування кривих по напрузі — ні, через варіативність кремнію це ризиковано.
Навіть power cap варто вводити через канарку, бо повітряний потік і умови по стійках різні.

9) Як зниження напруги взаємодіє з мультиарендним плануванням?

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

10) Який найшвидший «тест», що зниження напруги допомагає?

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

Наступні кроки

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

1. Зафіксуйте базу вашого навантаження: пропускну здатність, частоти, потужність, температуру, причини троттлінгу.
2. Застосуйте помірний power cap і перевиміряйте в умовах теплового насичення.
3. Зупиніться, коли продуктивність падає, хвостова латентність погіршується або з’являються помилки.
4. Кодифікуйте налаштування через systemd/CM і розгортайте через канарки.

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