Зниження напруги та обмеження потужності: тихіші ПК без жалю

Що саме ви змінюєте: напруга, частота та потужність

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

Обмеження потужності — інакші. Це явні обмежувачі, які лімітують, скільки електричної потужності CPU/GPU може перетворити на тепло. Обмеження потужності майже завжди знижують пікову продуктивність у важких навантаженнях, але сюрприз у тому, скільки продуктивності ви втрачаєте за ту кількість зниженого шуму. Зазвичай можна зменшити верхню потужність на 20–40% з втратою одиничних кадрів в секунду або кількох відсотків у багатоядерних бенчмарках.

Фізика, яка вам потрібна (і тільки вона)

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

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

Зниження напруги vs зниження частоти vs обмеження потужності

• Зниження напруги: зберігає цільові частоти, зменшує напругу. Кращий випадок: та сама продуктивність, менше тепла/шуму. Найгірший випадок: тонкі проблеми зі стабільністю.
• Зниження частоти: знижує цільові частоти. Зазвичай стабільно й передбачувано. Часто залишає ефективність «на столі» порівняно зі зниженням напруги.
• Обмеження потужності: лімітує ватаж. Продуктивність стає залежною від навантаження (короткі піки залишаються швидкими; тривалі завдання вирівнюються).

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

Факти та контекст, які можна використати за вечерею (або в огляді змін)

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

1. Intel ввів SpeedStep на початку 2000-х, щоб динамічно знижувати напругу й частоту — легітимний родич зниження напруги завжди був у плані.
2. AMD Cool’n’Quiet (середина 2000-х) нормалізував ідею, що настільні CPU не повинні весь день сидіти на повній напрузі просто щоб показати пошту.
3. Сучасні GPU підвищують частоти опортуністично: вони не «працюють на одній частоті», а «працюють на тому, що дозволяє тепловий/потужнісний запас».
4. Шум вентиляторів сприймається логарифмічно: невелике зниження RPM може звучати як велике покращення, особливо в діапазоні 1–3 кГц, де вентилятори найбільше дратують людей.
5. Ефективність VRM важлива: краща плата/дизайн GPU витрачає менше енергії на регулювання, тож працює холодніше при тій самій витраті енергії.
6. Intel Plundervolt (2019) призвів до обмеження зниження напруги на багатьох ноутбуках; деякі BIOS оновлення заблокували керування напругою з міркувань безпеки.
7. Пікові стрибки потужності (транзієнти) можуть бути реальним обмежувачем: GPU, що в середньому споживає 250 W, може миттєво вимагати значно більше, викликаючи поведінку PSU або захисту.
8. Багато навантажень не обмежені потужністю: офісна робота домінована латентністю/простоями; обмеження потужності її не сповільнює, але тримає вентилятори сплячими.
9. «Auto» налаштовано під заголовні бенчмарки: стокові криві часто віддають пріоритет максимальному бусту для коротких прогонів, а не вашій тривалій ігровій сесії або рендерінгу.

Чому стає тихіше: крива вентилятора — грубий інструмент

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

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

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

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

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

Перед тим як чіпати повзунки, з’ясуйте, що насправді спричиняє шум і тепло. Це тріаж, а не терапія.

По-перше: CPU, GPU чи повітрообмін у корпусі?

• Відкрийте улюблене навантаження (гру, рендер, компіляцію) і спостерігайте разом потужність пакета CPU, потужність GPU і температури.
• Якщо потужність GPU висока і температура GPU швидко зростає: почніть зі зниження напруги/обмеження потужності GPU.
• Якщо пакетна потужність CPU стрибкоподібна і температура CPU досягає меж термалу: почніть з обмежень потужності CPU (PL1/PL2 або ECO/PPT).
• Якщо жодне не високое, але вентилятори все одно верещать: можливо, крива вентиляторів або відображення датчиків неправильні, або повітрообмін у корпусі обмежений.

По-друге: чи ви обмежені потужністю, термічно чи напругою?

• Термічно обмежені: частоти падають, коли температура досягає ліміту. Виправляйте охолодження, потужність або напругу.
• Потужнісно обмежені: частоти вирівнюються навіть при безпечних температурах; з’являються прапори «Pwr» або «Power Limit». Виправляйте тюнінгом обмеження потужності, якщо вам потрібно більше продуктивності; знижуйте ліміт, якщо хочете тиші.
• Напругою обмежені: GPU показує VRel/VOp (NVIDIA) або ви досягаєте стабільної підлоги напруги. Виправляйте, налаштовуючи криву, а не тільки максимальну частоту.

По-третє: чи прихована нестабільність під виглядом «програмних проблем»?

• Випадкові падіння вкладок у браузері, WHEA-повідомлення, рідкісні падіння ігор після 30+ хвилин: поводьтесь з цим як з нестабільністю від undervolt, доки не доведено протилежне.
• Миттєвий крах при початку навантаження: зазвичай занадто агресивна точка напруги/частоти або обмеження потужності, що викликає різкий перехід стану.
• Затримки без краху: можуть бути термо/потужнісне тротлінг, помилки пам’яті або фонові завдання.

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

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

Завдання 1: Визначте CPU і поточний governor частоти

cr0x@server:~$ lscpu | egrep 'Model name|CPU\(s\)|Thread|Core|MHz'
Model name:                          AMD Ryzen 7 7700X 8-Core Processor
CPU(s):                              16
Thread(s) per core:                  2
Core(s) per socket:                  8
CPU MHz:                             4500.000

Що це означає: Ви знаєте платформу і приблизну робочу частоту.

Рішення: Виберіть правильні регулятори (Ryzen: PPT/TDC/EDC і Curve Optimizer; Intel: PL1/PL2 і undervolt, якщо дозволено).

Завдання 2: Перевірте політику масштабування частоти CPU

cr0x@server:~$ cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor
schedutil

Що це означає: Ядро використовує чутливий governor.

Рішення: Не «виправляйте шум», примусово встановлюючи performance, якщо вам не подобається витрата енергії на холостому ходу і гарячі VRM без причини.

Завдання 3: Зчитайте датчики температури пакета CPU

cr0x@server:~$ sensors
k10temp-pci-00c3
Adapter: PCI adapter
Tctl:         +83.4°C
Tdie:         +83.4°C

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

Що це означає: CPU гарячий під навантаженням; NVMe теплий, але не вмирає.

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

Завдання 4: Перевірте, чи є термальне тротлінг (вигляд ядра)

cr0x@server:~$ dmesg -T | egrep -i 'throttl|thermal' | tail -n 5
[Mon Jan 12 09:41:13 2026] amdgpu: [powerplay] SMU: thermal throttling engaged
[Mon Jan 12 09:41:15 2026] thermal thermal_zone0: throttling event: package_temp=96

Що це означає: Платформа вже захищається, знижуючи частоти.

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

Завдання 5: Перегляньте телеметрію GPU (NVIDIA)

cr0x@server:~$ nvidia-smi --query-gpu=name,temperature.gpu,power.draw,power.limit,clocks.gr,clocks.mem --format=csv
name, temperature.gpu, power.draw, power.limit, clocks.gr, clocks.mem
NVIDIA GeForce RTX 3080, 76, 287.45, 320.00, 1830, 9501

Що це означає: GPU споживає серйозну потужність; вентилятори заробляють свою зарплату.

Рішення: Почніть зі зниження ліміту потужності (наприклад, 320 W → 270 W), потім знизьте напругу, щоб відновити частоти в рамках нового ліміту.

Завдання 6: Встановити обмеження потужності NVIDIA (потребує persistence mode і прав)

cr0x@server:~$ sudo nvidia-smi -pl 270
Power limit for GPU 00000000:01:00.0 was set to 270.00 W from 320.00 W.

Що це означає: Ліміт активний одразу.

Рішення: Прогрійте навантаження 15–30 хвилин. Якщо продуктивність майже не змінилася, а вентилятори заспокоїлися — майже готово.

Завдання 7: Підтвердити, що кап фіксується, і спостерігати поведінку під навантаженням

cr0x@server:~$ nvidia-smi --query-gpu=power.draw,power.limit,temperature.gpu,clocks.gr --format=csv -l 2
power.draw, power.limit, temperature.gpu, clocks.gr
262.88, 270.00, 71, 1800
268.20, 270.00, 72, 1785
269.95, 270.00, 72, 1770

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

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

Завдання 8: Спостерігати системний рівень споживання (грубо, але корисно)

cr0x@server:~$ sudo turbostat --Summary --quiet --show PkgWatt,CorWatt,GFXWatt,PkgTemp --interval 2
PkgWatt CorWatt GFXWatt PkgTemp
88.72   72.11   0.02   86
74.30   58.54   0.01   79

Що це означає: Потужність пакета CPU корелює з температурою. (На системах не Intel доступність змінюється.)

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

Завдання 9: Перевірте на наявність апаратних помилок типу WHEA (вигляд Linux)

cr0x@server:~$ journalctl -k -b | egrep -i 'mce|whea|hardware error|edac' | tail -n 8
Jan 12 09:55:22 server kernel: mce: [Hardware Error]: CPU 7: Machine Check: 0 Bank 27: baa000000000080b
Jan 12 09:55:22 server kernel: mce: [Hardware Error]: TSC 0 ADDR 1ffffa2b0 MISC d012000100000000

Що це означає: Ймовірно, у вас маргінальна стабільність: занадто агресивне зниження напруги, нестабільна RAM або CPU, якому щось не подобається.

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

Завдання 10: Перевірка стану NVMe і температурних запасів (тихий ПК також означає прохолодне сховище)

cr0x@server:~$ sudo smartctl -a /dev/nvme0 | egrep 'Temperature:|Available Spare|Percentage Used|Media and Data Integrity Errors'
Temperature:                        55 Celsius
Available Spare:                    100%
Percentage Used:                    3%
Media and Data Integrity Errors:    0

Що це означає: Диск здоровий. Температура підходить для більшості споживчих NVMe.

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

Завдання 11: Визначте живі джерела тепла

cr0x@server:~$ sudo powertop --time=10 --html=/tmp/powertop.html
modprobe cpufreq_stats failed
Loaded 22 prior measurements
RAPL device for cpu 0
report generated: /tmp/powertop.html

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

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

Завдання 12: Спостерігайте температури і частоти CPU під вашим реальним навантаженням

cr0x@server:~$ watch -n 1 "grep -E 'cpu MHz' /proc/cpuinfo | head -n 4; sensors | egrep 'Tctl|Tdie|Package id 0' | head -n 4"
Every 1.0s: grep -E 'cpu MHz' /proc/cpuinfo | head -n 4; sensors | egrep 'Tctl|Tdie|Package id 0' | head -n 4

cpu MHz         : 5100.000
cpu MHz         : 5075.123
cpu MHz         : 5092.331
cpu MHz         : 5022.918
Tctl:         +91.8°C
Tdie:         +91.8°C

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

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

Завдання 13: Перевірте навантаження GPU і частоти за допомогою простого OpenGL тесту (саніті-чек)

cr0x@server:~$ glxgears -info | head -n 10
GL_RENDERER   = NVIDIA GeForce RTX 3080/PCIe/SSE2
GL_VERSION    = 4.6.0 NVIDIA 550.54.14
GL_VENDOR     = NVIDIA Corporation
Running synchronized to the vertical refresh.  The framerate should be approximately the same as the monitor refresh rate.

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

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

Завдання 14: Зафіксуйте базову лінію для порівняння до/після

cr0x@server:~$ mkdir -p ~/quietpc-baseline && (date; uname -a; sensors; nvidia-smi) | tee ~/quietpc-baseline/baseline.txt
Mon Jan 12 10:02:11 UTC 2026
Linux server 6.6.12 #1 SMP PREEMPT_DYNAMIC x86_64 GNU/Linux
k10temp-pci-00c3
Adapter: PCI adapter
Tctl:         +44.1°C
Tdie:         +44.1°C
NVIDIA-SMI 550.54.14    Driver Version: 550.54.14    CUDA Version: 12.4

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

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

Зниження напруги CPU і обмеження потужності CPU

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

Що робити на AMD Ryzen (десктоп): PPT/TDC/EDC і Curve Optimizer

Precision Boost у Ryzen охоче витрачає вати заради невеликих прибутків. Це добре для маркетингових графіків і жахливо для ваших вух.
Два великі важелі:

• ECO mode / reduced PPT: знижує цільову пакетну потужність. Шум швидко падає.
• Curve Optimizer (CO): по-ядрове або загальне зміщення кривої напруга/частота. Це зниження напруги з ременем безпеки.

З CO ви зазвичай застосовуєте «негативне» значення (менше напруги при даній частоті). Правильне число — те, що проходить ваше гірше навантаження, а не те, що дає кращу скріншотну цифру.

Що робити на Intel (десктоп): PL1/PL2 і зниження напруги (якщо дозволено)

Сучасна поведінка Intel залежить від PL1/PL2 (тривалі та турбо-ліміти потужності) і часових вікон. Заводські налаштування можуть сильно залежати від материнської плати; деякі плати трактують «сток» як «безлімітне, поки VRM не почнуть благати пощади».

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

1. Встановіть розумні PL1/PL2 відповідно до вашого охолодження і повітрообміну в корпусі.
2. Лише потім експериментуйте з невеликими зсувами напруги (або адаптивним налаштуванням напруги).
3. Валідуйте довгими змішаними навантаженнями і журналами помилок.

Обмеження потужності CPU: чому це виграш у бік тиші

Вентилятори не дбають про ваш Cinebench скор. Вони дбають про вати. Якщо CPU виштовхує 170 W у баштовий кулер, вентилятори відреагують.
Якщо ви обмежите до 105 W, ви не «паралізуєте» його; ви формуєте його для тривалих навантажень і людського комфорту.

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

Зниження напруги GPU і обмеження потужності: найкращий результат за хвилину

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

Робочий процес, що уникає болю

1. Встановіть ліміт потужності, який вже робить вентилятори терпимими.
2. Знизьте напругу за допомогою кривої, щоб утримувати пристойну частоту при нижчій напрузі.
3. Тестуйте реальні ігри і кілька синтетичних навантажень, бо різні навантаження навантажують різні шляхи.
4. Зупиніться раніше. Останні 25 mV, які ви зекономите, найімовірніше коштуватимуть вам вечора «чому воно впало в тому одному меню?»

Як виглядає зниження напруги на сучасних GPU

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

Типові результати:

• 10–20°C нижче для гарячої точки або ядра в тривалих навантаженнях (залежить від кулера і повітрообміну).
• Помітно нижчі RPM вентиляторів, особливо якщо ви були біля порогу їх підвищення.
• Невелика втрата продуктивності або майже паритет, інколи навіть виграш, якщо раніше був термо-тротлінг.

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

Стабільність і валідація: перестаньте довіряти «воно завантажилося»

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

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

• Тиха корупція даних (рідко на споживчих десктопах, але не фантазія): помилки при розпаковці файлів, некоректні компіляції, «мій архів пошкоджений».
• WHEA/MCE події: система виправляє помилки доти, доки не зможе. Це ваше раннє попередження, а не підказка.
• Скидання драйвера GPU: класичне «екран чорніє, потім повертається» або повний крах застосунку.
• Випадкові падіння додатків: браузери — гарні канарки, бо використовують багато JIT і пам’яті, і вони невпинні.

Принцип надійності, який варто тримати

Ось переказ ідеї від Вернера Вогельса (CTO Amazon): усе ламається; проектуйте і експлуатуйте, припускаючи це, і побудуєте стійкі системи.
Застосуйте це до тюнінгу: припускайте, що ваш вибраний undervolt в якомусь випадку зламається, і доведіть, що цього не станеться.

Стратегія валідації, що не витратить ваш уїк-енд

1. Виберіть два репрезентативні реальні навантаження: одне, що навантажує CPU (компіляція, кодування) і одне, що навантажує GPU (ваша основна гра).
2. Запустіть 30-хвилинний «smoke test» після кожної зміни. Якщо воно падає швидко — ви вчитеся швидко.
3. Запустіть 2–4-годинний «soak test» на найкращих кандидатних налаштуваннях. Якщо витримує — ви близько.
4. Перевірте логи на виправлені помилки, навіть якщо нічого не впало.

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

Інцидент через неправильне припущення: «економія енергії не може зламати коректність»

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

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

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

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

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

Інша організація мала пул GPU-робочих станцій для візуалізації даних та інколи CUDA-завдань. GPU були гучні на переході idle→load.
Хтось прочитав, що зниження ліміту потужності робить все тихіше. Вони застосували великий уріз: від дефолтного ліміту до драматичного зниження.

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

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

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

Нудна, але правильна практика, що врятувала день: «одна зміна, одна метрика, один відкат»

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

Команда обробила це як продакшн. Вони записали базові показники: температури idle і під навантаженням, RPM вентиляторів, споживання потужності і кілька таймінгів характерних завдань.
Записали версії BIOS і драйверів. Робили одну зміну за раз: спочатку обмеження потужності CPU, потім помірний ліміт GPU, потім зниження напруги.
Кожна зміна мала нотатку про відкат: куди повернути, якщо користувач повідомить про крах.

Через два місяці, після оновлення драйвера, одна машина почала чорнити екран під навантаженням GPU. Команда не сперечалася, чи це «оновлення» чи «undervolt».
Вони відкотили профіль undervolt GPU за кілька хвилин, підтвердили стабільність, а потім повторно ввели м’якший undervolt пізніше після тестування.

Це не гламурно. Проте саме так ви уникаєте перетворення проєкту «тихий ПК» в «чому причина перезапусків ПК в бухгалтерії під час виставлення рахунків».
Нудна практика — це гігієна змін: базова лінія, одна змінна, soak test, відкат.

Поширені помилки (симптом → корінна причина → виправлення)

1) «Стає тихіше, але ігри падають через 40 хвилин»

Симптом: Стабільно працює деякий час, потім крах/скидання драйвера.

Корінна причина: Undervolt стабільний коли охолоджувач холодний; нестабільний при нагріванні VRAM, GPU hotspot або ядер CPU.

Виправлення: Збільшіть напругу трохи на цільовій частоті, або зменшіть цільову частоту на 15–30 MHz; повторіть довший soak-тест.

2) «Продуктивність падає в одній грі, але не в інших»

Симптом: Один тайтл втрачає значно більше FPS після обмеження потужності.

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

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

3) «Вентилятори все одно різко підвищуються після зниження напруги»

Симптом: Температури покращилися, але шумові сплески зберігаються.

Корінна причина: Гістерезис кривої вентилятора занадто агресивний; вентилятори реагують миттєво на короткі сплески.

Виправлення: Додайте гістерезис/затримку або згладьте криву. Також перевірте, чи інший датчик не керує кривою (CPU vs GPU hotspot).

4) «Випадкові перезавантаження, без логів, наче проблема PSU»

Симптом: Раптове відключення живлення під навантаженням.

Корінна причина: Комбіновані транзієнти CPU+GPU разом з нестабільністю undervolt спричиняють різкі переходи станів; або спрацьовує захист PSU/VRM.

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

5) «Холостий хід все ще гарячий і гучний»

Симптом: Вентилятори чути на робочому столі.

Корінна причина: Фонові процеси заважають досягненню низьких енергетичних станів; неправильний governor CPU; GPU застряг у високому продуктивному стані; поганий повітрообмін корпусу.

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

6) «Після оновлення BIOS контролі undervolt зникли»

Симптом: Керування напругою відсутнє або заблоковане.

Корінна причина: Міра безпеки (поширено на ноутбуках) або зміни політики вендора.

Виправлення: Використовуйте обмеження потужності/ECO режим. Не понижуйте BIOS необдумано; розглядайте це як зміни безпеки.

7) «GPU undervolt проходить синтетичні тести, але падає в меню або при alt-tab»

Симптом: Краші під час переходів, а не під стабільним навантаженням.

Корінна причина: Нестабільність під час переходів напруга/частота; крива не стабільна на різних точках.

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

8) «Температури в нормі, але ПК все одно гучний»

Симптом: Термали виглядають контрольованими; шум зберігається.

Корінна причина: Механічний шум: підшипник вентилятора, турбулентність, резонанс корпусу; або маленький високошвидкісний вентилятор (чипсет/PSU) є джерелом.

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

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

Покроково: робочий процес «тихо без жалю»

1. Базова лінія: зафіксуйте температури, частоти, потужність і сприйняття шуму під вашим реальним навантаженням. Збережіть логи.
2. Виправте повітрообмін спочатку: очистіть пил, перевірте, що повітряні входи не заблоковані, переконайтеся, що вентилятори спрямовані правильно.
3. Застосуйте GPU power limit: зменшіть на 10–15% і протестуйте. Це найшвидший виграш для ігрових збірок.
4. Застосуйте CPU power cap/ECO режим: зменшіть тривалу пакетну потужність, щоб підійти до вашого кулера. Протестуйте тривале навантаження CPU.
5. Знизьте напругу GPU через криву: виберіть консервативну цільову точку напруга/частота; тест 30 хвилин; ітеруйте.
6. Знижуйте напругу/оптимізуйте криву CPU: маленькими кроками, слідкуйте за виправленими помилками. Віддавайте перевагу по-ядровому налаштуванню, якщо доступно.
7. Soak test: 2–4 години комбінованого навантаження CPU+GPU або вашої найдовшої реальної сесії.
8. Перегляд логів: перевірте логи ядра на виправлені помилки; перегляньте логи драйверів GPU, якщо доступно.
9. Зафіксуйте: збережіть профілі, задокументуйте налаштування і тримайте «відомо хорошу» профільну резервну копію.

Чекліст гігієни змін (те, що використовують дорослі)

• Одна зміна за раз.
• Завжди майте шлях відкату (профіль BIOS, збережений профіль GPU або письмовий «скинути назад до X»).
• Віддавайте перевагу капам і кривим перед сирими зсувами, якщо платформа підтримує.
• Слідкуйте за виправленими помилками, а не лише за крашами.
• Валідуйте при стійкій температурі, а не лише після холодного старту.

Пріоритети для тихого ПК (відсортовано)

1. Усуньте термо-тротлінг (тротл = тепло + шум + втрата продуктивності).
2. Встановіть обмеження потужності, щоб підлаштуватися під кулер і корпус.
3. Знижуйте напругу, щоб повернути продуктивність на ват.
4. Налаштуйте гістерезис вентиляторів, щоб машина не «панічно» ревіла.
5. Механічні виправлення (вентилятори, кріплення, резонанс) після розв’язання теплової історії.

FAQ

Чи анулює зниження напруги гарантію?

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

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

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

Що краще для тиші: зниження напруги чи обмеження потужності?

Спочатку обмеження потужності. Це передбачувано і легко пояснити. Зниження напруги друге — щоб покращити ефективність у межах цього ліміту.

Чому мій GPU undervolt здається стабільним у бенчмарку, але падає в конкретній грі?

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

Чи може зниження напруги спричинити корупцію даних?

Може, особливо у CPU-інтенсивних обчисленнях, де некоректні обчислення мають значення. Це рідко для звичайного використання, але не неможливо.
Якщо коректність важлива, слідкуйте за апаратними помилками і валідуйте ретельно.

Мій ноутбук не дозволяє знижувати напругу більше. Що робити?

Використовуйте обмеження потужності, вендорні «тихі» режими і покращення охолодження (перепаста за потреби, очищення вентиляційних отворів, покращення повітрообміну).
Багато систем заблокували зниження напруги через міри безпеки.

Чи варто знижувати напругу RAM або VRAM для тиші?

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

Як зрозуміти, що вузьке місце — CPU чи GPU?

Спостерігайте використання, частоти і споживання потужності під навантаженням. Якщо GPU близький до максимуму завантаження і споживання потужності близьке до ліміту — це GPU-bound.
Якщо пакетна потужність CPU і температура стрибне з високим завантаженням CPU — це CPU-bound або CPU-термічно обмежено.

Яке «безпечне» число для undervolt?

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

Чому іноді зниження ліміту потужності підвищує «статер»?

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

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

1. Виміряйте спочатку: зафіксуйте базові температури і потужність для CPU і GPU під вашим реальним навантаженням.
2. Встановіть помірний GPU power limit: зменште на 10–15%, протестуйте 30 хвилин, а потім вирішуйте, чи потрібне зниження напруги.
3. Встановіть CPU power cap/ECO режим: орієнтуйтесь на тривалі температури, з якими ви комфортно живете, а не на максимум, який виносить ваш кремній.
4. Знижуйте напругу маленькими кроками: віддавайте перевагу стабільності і плавній поведінці, а не пиковим показникам.
5. Запустіть soak test і перевірте логи: якщо бачите апаратні помилки — відкотіть негайно і повторіть тест.
6. Документуйте налаштування: ви їх забудете, і ваше майбутнє «я» буде незадоволене.

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