80 Вт из 175: как RTX 5080 Laptop под Ubuntu отдавала половину мощности
Я считал, что 21 токен в секунду — это всё, на что способен мой ноутбук с RTX 5080 при запуске Qwen3.8-27B. Оказалось, карта работала на 80 ваттах из паспортных 175.
Заметил случайно, когда взялся замерять, почему локальная модель считает медленнее, чем следует из пропускной способности памяти. Под полной нагрузкой карта показывала ровно 79.9 Вт и не шла выше ни при каких условиях. А nvidia-smi при этом честно сообщал: текущий лимит 80, максимальный 175.
Поднять не давал даже root:
$ sudo nvidia-smi -pl 175
Changing power management limit is not supported in current scope
Двое суток тупиков
Собрал llama.cpp с CUDA вместо Vulkan — ноль разницы в генерации. Попробовал мультитокенное предсказание — на длинном контексте стало хуже. Перезапускал nvidia-powerd, менял профили питания, лез в BIOS. Ничего.
Причина оказалась не в Linux
Дело в одной недостающей команде. Утилита OMEN Gaming Hub под Windows отправляет прошивке две WMI-команды: тепловой профиль и разблокировку лимита. Драйвер hp-wmi в ядре отправляет только первую. Вторую для моей платы — нет.
Как искали
Дальше работал Claude Code, и работал он не гаданием. Снял дамп таблиц ACPI моего же ноутбука, дизассемблировал их и прочитал, что именно прошивка делает в ответ на эти команды. Нашёл точный формат пакета, нашёл, что два имени полей в чужих реализациях перепутаны, и нашёл, что ещё один метод, который другие проекты вызывают, адресован вообще встроенной графике AMD, а не NVIDIA.
Но самое интересное — четыре попытки провалились. Флаги разблокировки прошивка принимала, подтверждала при перечитывании, и мощность не менялась ни на ватт. Не хватало третьей команды, которую мы оба считали необязательной: чтения числа вентиляторов. Обычный запрос данных, что он может менять?
В штатном драйвере ядра эта функция называется hp_wmi_get_fan_count_userdefine_trigger. Слово «trigger» в имени и было ответом: чтение имеет побочный эффект в контроллере. Добавили вызов первым в последовательность — и лимит снялся.
Что получилось
| Было | Стало | |
|---|---|---|
| Мощность | 79.4 Вт | 169.7 Вт |
| Частота GPU | 1426 МГц | 2141 МГц |
| Генерация | 20.8 tok/s | 31.2 tok/s |
| Префилл | 697 tok/s | 1020 tok/s |
Плюс 50% к скорости генерации на той же карте и том же кванте модели.
Но это бенчмарк, а бенчмарк короткий. На настоящей работе — агент, который пишет код, промпт от 55 тысяч токенов — медиана генерации выросла с 17.2 до 24.4 tok/s, то есть на 42%. Причём на самых длинных запросах прибавки нет совсем: там упор уже не в ватты, а в пропускную способность памяти, и лишним ваттам просто некуда деваться. Чем короче запрос, тем больше выигрыш.
Про температуру
Проверил на длительной нагрузке: температура выходит на плато 87 °C и там остаётся. Это ровно целевая температура карты — она сама к ней стремится и дальше плавно отдаёт мощность, удерживая. Аппаратное тепловое замедление не срабатывало ни разу. То есть это не разгон на грани, а штатный режим, который прошивка ноутбука просто не давала включить.
Ирония
В ядре 7.1 всё это уже сделано, причём именно для моей платы — коммит от 10 апреля. Достаточно выставить platform_profile в performance, и драйвер сам выполнит всю последовательность. Но в Ubuntu 26.04 ядро 7.0, и 7.1 туда не завезут никогда: следующее HWE-ядро придёт из промежуточного релиза, то есть будет уже 7.2, и не раньше февраля. У Fedora, к слову, 7.1.8 стоит с 11 августа — и в текущем выпуске, и в прошлом.
Пока ждём — работает свой модуль ядра со сторожевым таймером: если надзиратель за температурой умрёт по любой причине, ядро снимает разгон само в течение пяти секунд. Проверено самым грубым способом, kill -9.