У вас в компьютере может стоять видеокарта, которая считает вдвое медленнее, чем могла бы — просто потому, что производитель так решил в прошивке. Проект gpu-unlock от разработчика с ником Zagitta снимает этот лимит программно, на уровне ядра Linux, без патченого драйвера и без перепрошивки VBIOS.

Дисклеймер сразу: сам я этот модуль не тестировал (в отличие от предыдущей статьи про Qwen3.8 на 1070, где все цифры — мои собственные замеры). Всё ниже — разбор репозитория и README проекта, с указанием, где цифры — заявления автора и коммьюнити, а не независимо проверенный бенчмарк.

В чём суть ограничения

NVIDIA разделяет линейку на гейминговые GeForce RTX и профессиональные/дата-центровые карты (Tesla, A100, H100 и т.д.) не только по цене, но и по пропускной способности тензорных ядер на FP16/BF16/TF32 с накоплением в FP32. Железо физически одно и то же (или очень близкое), но на потребительских картах эта математика искусственно урезана — чаще всего вдвое от паспортной пиковой скорости тензорных ядер.

Для игр это не имеет значения — там этот режим почти не используется. А вот для локальных LLM, файнтюнинга, генерации изображений и видео — это именно то, что считает большую часть времени при обучении и на этапе prefill (обработка входного промпта).

Что делает gpu-unlock технически

Это модуль ядра Linux, который:

1. Встраивается в initramfs (mkinitcpio/initramfs-tools/dracut) и загружается до того, как в систему привяжется штатный драйвер nvidia.

2. Записывает в карту регистры-селекторы скорости: SS0 = 0x88888888 (полная скорость BF16) и 4-битный SS1 = 0x8 (режим IMLA4).

3. Выполняет FLR (Function-Level Reset) карты, после чего отпускает её — и уже немодифицированный оригинальный драйвер NVIDIA цепляется к карте как ни в чём не бывало.

Подход комбинирует технику из более старого проекта cmpunlocker (работа с V67/PLM-регистрами) с идеей перехвата на этапе до загрузки драйвера через UEFI. Драйвер NVIDIA модуль не патчит и не подменяет — архив драйвера скачивается только для того, чтобы вытащить из него прошивку, от которой зависит разблокировка. По заявлению автора, привязки к конкретной версии драйвера нет.

Важно: это не хак и не читерство с точностью вычислений — автор заявляет, что результаты вычислений побитово идентичны до и после, меняется только скорость.

Какие карты поддерживаются

Точные PCI device ID — в файле kernel/gpu_unlock/recipes.c репозитория.

Как видно, Pascal (10-серия, та самая GTX 1070 из моей предыдущей статьи) в списке нет вообще — у этих карт изначально нет отдельного урезанного режима tensor-core BF16, который можно было бы разблокировать (у Pascal просто нет тензорных ядер в нужном для этого виде). Так что для 1070 этот проект не актуален, а вот владельцам 20/30/40 серий — самое то.

Цифры производительности (по данным README)

Чистый BF16 matmul на стоковых лимитах мощности:

Для RTX 4090 автор отдельно отмечает: карта раньше упирается в лимит мощности, чем в потолок тензорных ядер, поэтому на больших GEMM прирост будет меньше, чем пиковая цифра в таблице.

Реальные нагрузки (типичные приросты, по отчётам сообщества, не независимый бенчмарк):

• Prefill LLM (FP16/BF16, AWQ/GPTQ): +25–55%, время до первого токена ниже на 25–30%

• LoRA и full-finetuning (BF16): +25–50%

• Генерация изображений (FP16/BF16): +30–55%

• Генерация видео (Wan 2.2, BF16): +15–20%

• FlashAttention/SDPA: +50–60%

• llama.cpp/Ollama с GGUF: 0–15%, заметнее на длинном контексте

• Без изменений: decode LLM (упирается в память, а не в вычисления), INT8/FP8/INT4-модели, игры, FP32 CUDA

Обратите внимание на последний пункт — это ключевое ограничение для локальных LLM. Если вы гоняете модель в INT8/INT4-квантах (как большинство локальных setup’ов на домашнем железе) и вас интересует скорость генерации (decode), а не только prefill — буст может быть нулевым. Выигрыш максимален именно на BF16/FP16 весах и именно на этапе обработки промпта или на обучении.

Установка

git clone https://github.com/zagitta/gpu-unlock
cd gpu-unlock
make install

Скрипт сам определяет дистрибутив и ставит зависимости. Есть отдельные таргеты под конкретные пакетные менеджеры: make install-arch, make install-deb (Debian/Ubuntu), make install-rpm (Fedora/RHEL, нужен DNF).

Дальше нужно добавить параметр ядра (не затирая существующие опции):

gpu_unlock.targets=all

Способ прописать это зависит от загрузчика: GRUB, grubby на Fedora, systemd-boot, либо /etc/kernel/cmdline для UKI-сборок. Можно указать и конкретные карты по PCI-адресу вместо all:

gpu_unlock.targets=0000:21:00.0,0000:22:00.0

Карты, уже привязанные к драйверу или выключенные, при загрузке пропускаются без ошибок.

Проверить, что разблокировка сработала:

journalctl -k -b | grep gpu_unlock
lspci -nnk -s 0000:XX:00.0

Откатить — убрать gpu_unlock.targets= из параметров ядра или удалить пакет.

Риски и нюансы

• Ноутбуки. Разблокировка теряется при полном отключении питания дискретной GPU. Частично помогает отключение runtime power management (NVreg_DynamicPowerManagement=0x00), но результат непостоянный.

• Suspend/resume. Сон в ОЗУ сбрасывает регистры-селекторы скорости, модуль разблокирует карту повторно при пробуждении (~1 секунда задержки). Отключается параметром gpu_unlock.resume=0. Гибернация не поддерживается.

• Если прошивка “зависла”. Модуль логирует это и держит DMA-буферы выделенными до полного обесточивания карты — перед повтором нужно именно выключить питание, не просто перезагрузиться.

• Нагрев. Карта будет работать теплее из-за возросшей вычислительной нагрузки, но штатный троттлинг и управление питанием продолжают работать как обычно.

• Windows. Автором не поддерживается. Существует сторонний порт, но в FAQ отдельное предупреждение: к любым “установщикам под Windows”, гуляющим по сети, относиться с крайней осторожностью — это не официальный продукт проекта.

• Скам. В FAQ отдельно написано: проект не имеет никакой официальной криптовалюты, сайтов или установщиков, кроме самого GitHub-репозитория.

Лицензия

Сам модуль ядра и локальная упаковка — GPL-2.0-only. Сгенерированный буфер прошивки собран на основе референса CMP; прошивка NVIDIA внутри остаётся под её собственной лицензией (подробности — firmware/NOTICE.md и licenses/ в репозитории).

Итого

Если у вас RTX 20/30/40-серии и вы гоняете локальные LLM, файнтюните модели или генерируете картинки/видео в FP16/BF16 — это бесплатный и, судя по описанию, довольно безопасный способ получить +25-90% на самых дорогих по вычислениям этапах, без доплаты за новую карту. Главное — честно сверить профиль своей нагрузки со списком “где не работает”: decode локальных LLM в кванте INT8/INT4 прироста не даст вообще, и это как раз самый частый домашний сценарий. Прежде чем тащить это в прод или на единственную рабочую машину — почитайте репозиторий сами и проверьте на тестовом стенде, цифры в статье — это пересказ README проекта, а не мой собственный замер.

Ссылка на репозиторий: github.com/zagitta/gpu-unlock

UPD: рабочий GUI-анлок под Windows

В комментариях подсказали: пользователь MindAllik собрал кроссплатформенный инструмент с GUI на основе наработок Zagitta, JustARearcher, TOTORONG и KohakuBlueleaf — GPU-Tensor-Unlock-Universal. Поддерживает Windows 10/11 (через загрузочную UEFI-флешку, с пробным прогоном патча в ОЗУ перед реальным применением — защита от чёрного экрана) и Linux (DKMS), карты RTX 20/30/40.

Его собственные замеры на RTX 4070 Ti (Windows 11, лимит мощности уравнен через NVML на 300 Вт) прямо подтверждают цифры из README Zagitta: FP16→FP32 87.36→175.43 TFLOP/s (2.01x), BF16→FP32 и TF32→FP32 — та же картина, INT8→INT32 без изменений (1.00x), как и ожидалось для этого типа лимита.