gpu-unlock-ada

What does it do?

It is a Linux kernel module that applies an SM speed-select override before the stock NVIDIA driver starts on RTX 4090 and some experimental Ada GPUs. [1a][1b] On a tested RTX 4090, it changes measured FP16/BF16 tensor throughput with FP32 accumulation from about 165.6 TF/s to 331.6 TF/s. [2] It does this without a patched NVIDIA driver or UEFI application by running signed firmware and performing FLR (function-level reset) before the unmodified driver binds. [3a][3b]

Activity, over time

Daily observations from the public event archive.

Attention

Daily stars & forks

Loading attention chart

Star accumulation

Cumulative stars

Loading star accumulation chart

Pull requests

Daily opens & merges

Loading pull requests chart

Conversations

Daily issues & comments

Loading conversations chart

Community

Daily accounts & reviews

Loading community chart

Releases

Daily releases

Loading releases chart

Mentions

107posts · 30d
Nov 30 posts
  1. Zenn · · @phpmyadmin

    中古GPUでローカルLLM環境を作る価格更新 2026年11月版 前回の記事で、中古サーバ用GPUを使ったローカルLLM環境の費用を試算した。今回は価格の更新と、その後に出てきたソフトウェア側の変化をまとめる。調査日は2026年10月30日である。構成やベンチマークの詳細は前回の記事を参照してほしい。 前回から価格はどう変わったか 前回記事の採用価格と、今回確認した価格例を並べる。GPUはカード単体、DGX Sparkは本体価格である。 中古は個別の取引例であり、市場平均ではない。売却済みの商品も参考として含め、販売状況を併記した。 製品 前回の価格 今回確認した価格 状況・出典 Tesla P100 16GB 20,000円 24,500円 ファン付き、10月22日売却済み。商品ページ Tesla P40 24GB 59,000円 45,000円 10月23日出品、売却済み。商品ページ MI50 32GB 110,000円 89,800円 9月9日売却済みの参考例。商品ページ Tesla V100 PCIe 32GB 120,000円 160,000円 ファン・変換ケーブル付き、販売中。商品ページ CMP 170HX 300,000円 US $3,298.98 64GB利用をうたう海外出品、在庫3点表示。送料・輸入費用別。商品ページ RTX 3090 24GB 比較対象外 209,000円 10月29日売却済み、送料込み。商品ページ RTX 4090 24GB 比較対象外 539,980円 税込、在庫1点、本体のみ。じゃんぱら RTX 5090 32GB 774,000円 1,229,000円 価格.com掲載最安。店舗在庫は別途確認。価格一覧 DGX Spark 128GB 980,000円 1,276,000円 税込、2027年1月頃入荷予定。ELSA ONLINE RTX PRO 6000 Blackwell Workstation Edition 96GB 2,546,000円 3,300,000円 税込、即納・在庫品表示。PGダイレクト 目立つのは新品側の高さである。今回の掲載例では、RTX 5090が前回比約59%増、DGX Sparkが約30%増になった。一方、P40には4万円台、MI50には9万円前後の売却済み事例がある。ただし前回と今回で集計方法や付属品が違うため、そのまま相場の騰落率とは扱えない。 RTX PRO 6000は納期でも価格が大きく違う。同じ販売店に、2027年2月入荷予定の予約品253万円と、即納品330万円が並んでいる。「最安値」で比較すると、数か月待つ構成とすぐ組める構成が混ざる。PGダイレクトの掲載一覧 CMP 170HXも、前回の30万円をそのまま使うのは難しくなった。今回の出品はeBayの円表示で約52.1万円だった。これを仮に1枚52万円として、前回と同じホスト機18万円を加えると、3枚構成は約174万円、4枚構成は約226万円になる。送料・輸入費用はさらに加わるため、前回の108万円・138万円からはかなり遠い。eBayの掲載価格 中古GeForceも比較に入れる Tensor演算の制限解除が登場したので、中古RTX 3090・4090もサーバ用GPUと並べてみる。上の価格例を公称VRAM容量で割った。ホスト機・電源・冷却の追加費用は含まない。 GPU VRAM 今回の価格例 VRAM単価 Tesla P100 16GB 24,500円 1,531円/GB Tesla P40 24GB 45,000円 1,875円/GB MI50 32GB 89,800円 2,806円/GB Tesla V100 32GB 160,000円 5,000円/GB RTX 3090 24GB 209,000円 8,708円/GB RTX 4090 24GB 539,980円 22,499円/GB 容量あたりの安さではサーバ用GPUが強い。3090はV100より約4.9万円高く、容量は8GB少ない。4090も標準品は24GBなので、容量を買う目的では割高になる。 GeForceを選ぶ理由になるのは演算性能だ。その評価を変えそうなものが、次の制限解除である。 RTX 30・40系ではTensor演算の制限解除が登場 gpu-unlockなどで、FP16・BF16などを入力に使い、FP32で積算するTensor演算の速度制限を解除する手法が公開されている。開発者の公開値は次のとおり。 GPU 測定内容 解除前 解除後 RTX 3090 BF16行列積、FP32積算 75 TFLOPS 125 TFLOPS RTX 3090 Ti BF16行列積、FP32積算、450W 88 TFLOPS 157 TFLOPS RTX 4090 FP16→FP32積算の命令スループット 165.6 TFLOPS 331.6 TFLOPS 3090系はgpu-unlockの測定表、4090はAda版の測定報告による。行列積の実効性能と命令スループットは測定方法が異なるため、この表からGPU同士の性能順位は出せない。 Tensor演算が最大2倍でも、LLMの生成速度が2倍になるわけではない。 gpu-unlockの開発元は、対象の演算を使うLLMのプリフィルで25〜55%の改善例をまとめる一方、メモリ帯域が律速になるトークン生成は変化なしとしている。測定・対応表 Ada版の独立した追試では、実際のcuBLAS行列積の改善幅は形状に依存し、FP16で12〜34%だった。改造48GB RTX 4090では、Tensor演算の高速化を確認しながら、量子化MoEの8Kプリフィルは0.983倍で改善しなかった例もある。モデル・量子化・カーネルが、解除対象の演算を使うかどうかで効果が変わる。Ada版の追試と実アプリ測定 RTX 40系は実験的な扱いで、導入環境や安定性の確認も必要になる。それでも、手元に3090や4090があるなら、買い替える前に調べる価値のある変化だと思う。 今回の価格なら、容量と初期費用を優先する候補はP100・P40・MI50・V100で、対象のTensor演算を多用する用途では3090も比較候補になる。4090は約54万円を払う効果を、使うモデルとエンジンで確かめたい。 旧記事のV100の生成速度と、ハック後のGeForceのTFLOPSは別の指標である。同じモデル・量子化・コンテキスト長で、プリフィルと生成を分けて比べる必要がある。 Strataで古いGPUの使い道も変わってきた サーバ用GPU側では、推論エンジンのStrataが気になる。 旧世代GPU向けの資料には、P100・P40・V100の実験的な対応経路が用意されている。Pascal・VoltaではCUDA 12版のエンジンを使い、P100向けの専用カーネルや、V100のFP16 Tensor Coreを使う処理もある。Strataの旧世代GPU対応資料 公開された運用例では、P100 16GBを4枚使い、Qwen3.8-Flash-Nextで単一ユーザー48.7〜52.0 tok/sが報告されている。多トークン予測を併用した値で、主な測定はIQ3_XXS量子化によるものだ。前回記事とはモデルも条件も違うので直接比較はできないが、古いGPUを使った具体的な運用例として面白い。構成・測定記録 P100が安いままでも、動かせるソフトウェアが改善すれば使い道は増える。中古GPUは、カードの仕様表だけで評価しきれなくなってきた。 感想 新品の大容量機は高くなった。一方で、古いカードを使い切るソフトウェアも進んでいる。 容量を安く確保するなら中古サーバ用GPU、対象の演算を速く回したいなら中古GeForceも含めて考える。どちらを選ぶにしても、価格表と同じぐらい、使いたいモデルがどのエンジンでどう動くかが大事になってきた。 安いGPUを探す楽しみに加えて、手元のGPUが更新でどこまで使えるようになるかという楽しみも増えてきた。

  2. JustAResearcher/gpu-unlock-ada — RTX 4090の制限を解除し、演算性能を「2倍」に加速 ・今週スター急増中のC言語製Linuxカーネルモジュール ・ドライバ起動前にSMを上書きしFP16/BF16演算を倍増(160→320 TF/s) ・ファームウェアをローカル生成し、最新の615系ドライバにも対応 ・LLM学習や科学計算など、FP32蓄積を多用する現場に革命 #GPU #機械学習

  3. Hacker News · · 84634E1A607A

    Show HN: UEFI pre-driver Nvidia GPU unlocker for Windows UEFI pre-driver NVIDIA GPU unlocker for Windows (Rust): SEC2 scrubber -> FWSEC/WPR2 -> signed Booter -> V67 four-write payload, read-back verified. Based on Zagitta/gpu-unlock , JustAResearcher/gpu-unlock-ada , Consensus-Protocol/cmp170hx and other research work

    2 points
  4. JustAResearcher/gpu-unlock-ada — RTX 4090のTensor性能を2倍にするLinuxモジュール ・C言語製カーネルモジュールでドライバー前にSM制限を解除 ・FP16/BF16の理論スループットを165→331TF/sに倍増 ・ローカルLLM学習や独自モデルの計算時間を大幅削減 #GPU #AI開発

  5. YouTube · · YouTube description · Vibeecode RU

    Топ-10 GitHub за 3 дня · 24–26 октября 2026: rea, cleanyourtv, gpu-unlock Топ-10 GitHub за 3 дня · 24–26 октября 2026 (без повторов прошлого выпуска) Самые быстрорастущие open-source проекты GitHub за 3 дня: morluto/rea, Gathin23/cleanyourtv, Zagitta/gpu-unlock и ещё 7. 1. morluto/rea — +17 419 ★ — MCP-сервер и CLI для реверс-инжиниринга с ИИ-агентами: от поведения приложений до нативных бинарников. morluto/rea 2. Gathin23/cleanyourtv — +10 533 ★ — Убирает предустановленный мусор на Android/Google TV по Wi-Fi и ставит лаунчер в стиле Apple TV. Gathin23/cleanyourtv 3. Zagitta/gpu-unlock — +8 922 ★ — Модуль ядра Linux, снимающий ограничение скорости FP16/BF16 на RTX 3000 до уровня проф. карт Zagitta/gpu-unlock 4. cloudflare/security-audit-skill — +5 994 ★ — Скилл, который делает из ИИ-агента аудитора безопасности: аудит идёт в шесть фаз, находки независимо проверяются. cloudflare/security-audit-skill 5. elayadesign/ai-design-skills — +5 029 ★ — Набор дизайн-скиллов для ИИ-кодеров: создание лендингов и превращение статичного макета в анимацию. elayadesign/ai-design-skills 6. Nutlope/hallmark — +4 897 ★ — Дизайн-скилл для Claude Code, Codex, Cursor и OpenCode, чтобы сгенерированные страницы не выглядели сделанными ИИ Nutlope/hallmark 7. JustAResearcher/gpu-unlock-ada — +3 813 ★ — Форк gpu-unlock для RTX 4090 и экспериментально RTX 4070 Ti SUPER: удваивает скорость тензорных FP16/BF16 JustAResearcher/gpu-unlock-ada 8. pbakaus/impeccable — +3 561 ★ — Дизайн-скилл для ИИ-агентов: 24 команды и 62 детерминированных правила против шаблонного фронтенда pbakaus/impeccable 9. seedds/nxnative — +3 394 ★ — Превращает собственные NSP-файлы игр Switch в IPA, чтобы запускать их нативно на iPhone, iPad и Mac. seedds/nxnative 10. deepseek-ai/deepseek-harness — +3 033 ★ — Открытый фреймворк агентов от DeepSeek: все возможности сделаны плагинами на основе Cordis. deepseek-ai/deepseek-harness Сообщество вайбкодеров в Telegram - vibeecode.ru Запускай и дорабатывай такие проекты с ИИ в Приложении ВайбКод - vibeecode.ru Новые звёзды за 3 дня по официальной истории звёзд GitHub, сутки по UTC. #github #opensource #программирование #нейросети #вайбкодинг

    1 like · 83 views
  6. gpu-unlock-ada — 今週急上昇!RTX 4090のTensor性能を約2倍にする ・NVIDIAドライバー起動前にSM overrideを実行するC言語製モジュール ・RTX 4090のFP16/BF16演算(FP32蓄積)で最大330 TF/s超を達成 ・自作CUDA開発やローカルLLM基盤のハード限界性能を引き出せる #CUDA #Linux

  7. New unlock for RTX 2080 KohakuBlueleaf/KohakUnlock Try at your own discretion t.co

    50 likes · 4 reposts · 2,896 views
  8. Reddit · · r/StableDiffusion · u/panchovix

    GPU unlocks (FP32 accumulation): Why can it be unlocked on Turing (RTX 20), Ampere (RTX 30) and Ada (RTX 40) but no consumer Blackwell (RTX 50) and some misconceptions. Hello guys, hoping you're doing fine. Wall of text next I know, but I want to get this info out of my chest, all hand written lol. I wanted to make this post explaining some things about GPU unlocks that have been going on lately. What are these GPU unlocks doing? NVIDIA on purpose neuters tensor core performance when using FP32 accumulation (FP16, BF16, FP8 and TF32 inputs accumulating in FP32, which is what most AI/LLM/ML tasks use), for market segmentation. Normal FP32 on the CUDA cores (no tensor cores) is NOT affected. Consumer and prosumer GPUs use the exact same die (like GB202 between the 5090 and 6000 PRO, AD102 between the 4090 and 6000 Ada, or even literally 1:1 with the 3090 Ti vs A6000, both with the same core amounts and 84 SMs). How it works: the speed of each kind of tensor operation is set by fuses burned at the factory. On consumer cards, the fuse for "FP16/BF16 with FP32 accumulation" says HALF_SPEED, on the pro cards it says FULL_SPEED. These fuses don't cut any circuit, the GPU just reads them at boot and runs at that speed. The GPU also has an override register that can set them back to FULL_SPEED, but it's locked so only NVIDIA's most privileged firmware can write to it, not your PC. The unlocks open that lock and write FULL_SPEED on the override. With that, the consumer cards gain all the neutered performance imposed by NVIDIA. It doesn't give you more SMs, VRAM or anything like that, a 4090 is still a 4090, it just runs those instructions at the same rate a pro card does. Why can Turing, Ampere and Ada be unlocked? And what is unlocked on these cards? On these generations, the NVIDIA driver itself loads a small NVIDIA-signed firmware called the "Booter" onto a security microcontroller inside the GPU (SEC2, a "Falcon"), to start the GSP. The Booter runs in the highest privilege mode of the GPU (Heavy Secure, HS), which is exactly the one allowed to open the lock. In June 2026, Jon Pry published a paper ("A Canary in the Crypto Mine") showing that the Booter of the newer drivers has a buffer overflow: it copies its "signature" data using a length that you control, so you can overflow its stack (including the stack canary that is supposed to stop exactly this) and take control of the Booter while it is running in HS mode. The signature check still passes, because it is NVIDIA's own signed code running, the bug is inside it. With that, the unlock reuses instructions from NVIDIA's own Booter to open the lock, writes FULL_SPEED on the override, resets the card and lets the normal NVIDIA driver load. The unlock survives resets and driver reloads, but it's lost when you power off, which is why it runs on every boot before the NVIDIA driver loads. This was first done on mining cards (CMP 170HX: FP32 from 1/32 to full speed, and 10GB to 80GB of VRAM), and then ported to GeForce: - Turing: haohervchb/Turing-unlock (UEFI, Linux) - Ampere: Zagitta/gpu-unlock (Linux kernel module) - Ada: JustAResearcher/gpu-unlock-ada (Linux with kernel module) What gets unlocked: - FP16 with FP32 accumulation (Turing, Ampere, Ada) - BF16 with FP32 accumulation (Ampere, Ada; Turing has no BF16) - TF32 (Ampere, Ada) - FP8 with FP32 accumulation (Ada; Turing and Ampere have no FP8) Some numbers from those repos: 4090 FP16/BF16 with FP32 acc goes from 165 to 331 TFLOPS (raw instruction rate), 3090 Ti BF16 GEMM from 87 to 157 TFLOPS, 2080 Ti FP16 with FP32 acc from 47 to 94 TFLOPS. Real-world GEMMs gain less than 2x because the cards then hit their power limit (more on that below). Why can't consumer Blackwell be unlocked? The funny part is that on Blackwell the limitation is EXACTLY the same thing: same fuses, same override registers. I checked on my own cards: the 5090/5080/5070 Ti have the FP32 accumulation fuses set, and the 6000 PRO/4000 PRO don't. So it's not a hardware difference there either. What changed is the door. Starting with Hopper, and consumer Blackwell too, the root of trust of the GPU is the FSP (Foundation Security Processor), a RISC-V core that boots from its own ROM as soon as the GPU powers on, before the driver even loads. On Blackwell: - There's no Booter to abuse. The driver just sends the FSP a message with a hash + RSA-3K signature of the next firmware, and the FSP verifies and boots it. The Linux kernel docs literally say: "There is no SEC2 involvement, no Booter ucode, and no FWSEC-FRTS stage". I also checked it myself: in NVIDIA's 615 driver source the Booter only exists for Turing, Ampere and Ada (TU102, TU116, GA100, GA102, AD102), and the RTX 50 VBIOSes don't carry the Falcon firmware (FWSEC) that older cards did. - The firmware the driver ships for Blackwell is encrypted, and the debug and production images are the exact same encrypted bytes. The Ada payload was built from analysis of the decrypted debug Booter, on Blackwell there's no such shortcut. - NVIDIA has said it uses SPARK (a formally verifiable programming language) to prove its most critical RISC-V firmware free of runtime errors, and a buffer overflow like the one used on the older cards is exactly that kind of error. So, with what is known today, it can't be done. It isn't "impossible forever", but someone would need a brand new vulnerability in a way harder target. And if someone ever gets there, the unlock itself would very likely be the same couple of register writes. FP4 is not affected, but all the rest is (FP16/BF16/FP8/TF32 with FP32 accumulation). In which tasks is the unlock has most of the effect? I will put some examples on my 6000 PRO vs 5090s, former using 400W and latter 600W, at how much is the impact in performance because the NVIDIA neutering. - Training: Like LoRAs, finetuning, etc. - Example: Using the same batch size for 25GB VRAM to train a diffusion LoRA, my 6000 PRO is 70-90% faster than my 5090. - Diffusion: Models that do txt2img, txt2vid, img2img, img2vid, txt2aud, etc. - Example: My 6000 PRO not using fp16 accumulation is about 30-40% faster than my 5090. If using fp16 accumulation, it is 15% faster. - Prefill on LLMs: Heavily affected as well, since even when a model is marked as "int8" or "mixed precision" etc, the inference parts that the GPU uses include FP32 accumulation parts, except if explicitly set to not use them. - Example: My 6000 PRO on vLLM on a model that fits on a 5090 as well, it's 50-70% faster. On llamacpp, instead is about 30-40% faster. - TG with big batching: TG with a single batch is mostly bandwidth bound, and it uses FP32 acc instructions, but since it is so little in comparison with the need of bandwidth, it isn't a limitation. On the other hand, when you use batches with batch size 2, 4, 8, etc, compute again starts to being a bottleneck and then you have a performance impact. - Example: Same results as previous point. In which tasks the unlocks makes no difference: - TG with batch size 1: almost entirely bandwidth bound. - CUDA compute without tensor cores (normal FP32). - INT4/INT8 tensor operations. - FP4 on Blackwell (not neutered to begin with). - GEMM operations with FP16 accumulation instead, but those aren't very used. - Gaming. Is there a risk by unlocking the cards, like burning the card, crashes, etc? Short answer: NO. And again, NO. For the love of god guys, stop repeating this nonsense. The cards are still limited by their max power limit. They won't magically use 200% of your power budget with an unlock, they will just use the cores more efficiently. Let me explain: if you have a 3090 power limited at 300W, and without the unlock you were seeing only 250W in use, but after the unlock it uses 300W, it's not because the unlock did malicious things to your card. It's because the card can NOW stretch its legs and use the power to do more work. Real example from the Ada repo: an unlocked 4090 doing the same GEMMs peaked at 346W vs 313W stock, still under its 450W limit. If you were getting X performance at Y < max TDP, and now you get more than X performance at max TDP, obviously the card will be hotter, but that's still inside the POWER LIMIT YOU SET, not above it. Power spikes: those are normal on every card, and if you're using it to the full extent of its capabilities they can be more common. Are they risky? No, assuming you have a PSU with the wattage NVIDIA recommends per GPU. So what ARE the actual risks then? They're about the unlock process, not your card: - It runs an exploit on NVIDIA's firmware before the driver loads. If something fails mid-way, the tools stop and you need a full power off before trying again (a reboot isn't enough). Read the repo instructions, especially on laptops and multi-GPU setups. - NVIDIA could patch it in future drivers, or even burn anti-rollback fuses so the old Booter stops being accepted. That wouldn't damage your card, it would just close the door for good. "But, NVIDIA bins the dies to make these work 24/7 on the prosumer side but not on consumer, that's why they're locked!!!11" Also incorrect. NVIDIA uses the EXACT SAME dies for their consumer GPUs and their prosumer GPUs, and the FP32 accumulation speed has nothing to do with binning: the 3090 Ti and the A6000 have the exact same specs. The half speed is just a value written in a fuse that the firmware reads. Unlocking a card will not make it die sooner, nor will it crack the die or something. Sorry I have to repeat this again and again, but the amount of pure fury I get from reading comments like these made me do this. Does affect gaming performance? None known at the moment, except if somehow NVIDIA uses FP32 accumulation for DLSS or FG, which I doubt. I'm almost sure they use FP16 accumulation (or lower precisions) there, because if they used FP32 accumulation the perf hit would be insane on consumer cards. The model I run says it is Q8, or FP6, or 4bit, or INT4, or anything that doesn't mention FP32, am I affected? It depends on how the GPU actually does the math, not on the name of the quant: - If the kernel dequantizes the weights to FP16/BF16 and multiplies on the tensor cores with FP32 accumulation, you're affected. That's the case for FP16/BF16 models and most vLLM paths, including AWQ/GPTQ with Marlin kernels (the weights are INT4, but the math is FP16 with FP32 accumulation). - FP8 (W8A8) also accumulates in FP32, so it's affected too (Ada and Blackwell). - If the kernel uses integer tensor math (INT8 x INT8), it isn't affected. A lot of llama.cpp's quantized matmuls work like this, which is one reason llama.cpp sees a smaller gap than vLLM. - Attention (like FlashAttention) almost always uses FP16/BF16 with FP32 accumulation, so long contexts get hit even on quantized models. - FP4 (NVFP4/MXFP4) on Blackwell: not affected. Example: on a modded 48GB 4090, a quantized MoE model on an inference server got no gain at all after the unlock (0.98x on 8K prefill), while the FP16/BF16 matmuls doubled. That's what I have for now, if you guys have any more questions, let me know!

    395 points · 113 comments
  9. Reddit · · r/nvidia · u/panchovix

    GPU unlocks (FP32 accumulation): Why can it be unlocked on Turing (RTX 20), Ampere (RTX 30) and Ada (RTX 40) but no consumer Blackwell (RTX 50) and some misconceptions. Hello guys, hoping you're doing fine. Wall of text next I know, but I want to get this info out of my chest, all hand written lol. I wanted to make this post explaining some things about GPU unlocks that have been going on lately. First of all, does affect gaming performance? None known at the moment, except if somehow NVIDIA uses FP32 accumulation for DLSS or FG, which I doubt. I'm almost sure they use FP16 accumulation (or lower precisions) there, because if they used FP32 accumulation the perf hit would be insane on consumer cards. What are these GPU unlocks doing? NVIDIA on purpose neuters tensor core performance when using FP32 accumulation (FP16, BF16, FP8 and TF32 inputs accumulating in FP32, which is what most AI/LLM/ML tasks use), for market segmentation. Normal FP32 on the CUDA cores (no tensor cores) is NOT affected. Consumer and prosumer GPUs use the exact same die (like GB202 between the 5090 and 6000 PRO, AD102 between the 4090 and 6000 Ada, or even literally 1:1 with the 3090 Ti vs A6000, both with the same core amounts and 84 SMs). How it works: the speed of each kind of tensor operation is set by fuses burned at the factory. On consumer cards, the fuse for "FP16/BF16 with FP32 accumulation" says HALF_SPEED, on the pro cards it says FULL_SPEED. These fuses don't cut any circuit, the GPU just reads them at boot and runs at that speed. The GPU also has an override register that can set them back to FULL_SPEED, but it's locked so only NVIDIA's most privileged firmware can write to it, not your PC. The unlocks open that lock and write FULL_SPEED on the override. With that, the consumer cards gain all the neutered performance imposed by NVIDIA. It doesn't give you more SMs, VRAM or anything like that, a 4090 is still a 4090, it just runs those instructions at the same rate a pro card does. Why can Turing, Ampere and Ada be unlocked? And what is unlocked on these cards? On these generations, the NVIDIA driver itself loads a small NVIDIA-signed firmware called the "Booter" onto a security microcontroller inside the GPU (SEC2, a "Falcon"), to start the GSP. The Booter runs in the highest privilege mode of the GPU (Heavy Secure, HS), which is exactly the one allowed to open the lock. In June 2026, Jon Pry published a paper ("A Canary in the Crypto Mine") showing that the Booter of the newer drivers has a buffer overflow: it copies its "signature" data using a length that you control, so you can overflow its stack (including the stack canary that is supposed to stop exactly this) and take control of the Booter while it is running in HS mode. The signature check still passes, because it is NVIDIA's own signed code running, the bug is inside it. With that, the unlock reuses instructions from NVIDIA's own Booter to open the lock, writes FULL_SPEED on the override, resets the card and lets the normal NVIDIA driver load. The unlock survives resets and driver reloads, but it's lost when you power off, which is why it runs on every boot before the NVIDIA driver loads. This was first done on mining cards (CMP 170HX: FP32 from 1/32 to full speed, and 10GB to 80GB of VRAM), and then ported to GeForce: - Turing: haohervchb/Turing-unlock (UEFI, Linux) - Ampere: Zagitta/gpu-unlock (Linux kernel module) - Ada: JustAResearcher/gpu-unlock-ada (Linux with kernel module) What gets unlocked: - FP16 with FP32 accumulation (Turing, Ampere, Ada) - BF16 with FP32 accumulation (Ampere, Ada; Turing has no BF16) - TF32 (Ampere, Ada) - FP8 with FP32 accumulation (Ada; Turing and Ampere have no FP8) Some numbers from those repos: 4090 FP16/BF16 with FP32 acc goes from 165 to 331 TFLOPS (raw instruction rate), 3090 Ti BF16 GEMM from 87 to 157 TFLOPS, 2080 Ti FP16 with FP32 acc from 47 to 94 TFLOPS. Real-world GEMMs gain less than 2x because the cards then hit their power limit (more on that below). Why can't consumer Blackwell be unlocked? The funny part is that on Blackwell the limitation is EXACTLY the same thing: same fuses, same override registers. I checked on my own cards: the 5090/5080/5070 Ti have the FP32 accumulation fuses set, and the 6000 PRO/4000 PRO don't. So it's not a hardware difference there either. What changed is the door. Starting with Hopper, and consumer Blackwell too, the root of trust of the GPU is the FSP (Foundation Security Processor), a RISC-V core that boots from its own ROM as soon as the GPU powers on, before the driver even loads. On Blackwell: - There's no Booter to abuse. The driver just sends the FSP a message with a hash + RSA-3K signature of the next firmware, and the FSP verifies and boots it. The Linux kernel docs literally say: "There is no SEC2 involvement, no Booter ucode, and no FWSEC-FRTS stage". I also checked it myself: in NVIDIA's 615 driver source the Booter only exists for Turing, Ampere and Ada (TU102, TU116, GA100, GA102, AD102), and the RTX 50 VBIOSes don't carry the Falcon firmware (FWSEC) that older cards did. - The firmware the driver ships for Blackwell is encrypted, and the debug and production images are the exact same encrypted bytes. The Ada payload was built from analysis of the decrypted debug Booter, on Blackwell there's no such shortcut. - NVIDIA has said it uses SPARK (a formally verifiable programming language) to prove its most critical RISC-V firmware free of runtime errors, and a buffer overflow like the one used on the older cards is exactly that kind of error. So, with what is known today, it can't be done. It isn't "impossible forever", but someone would need a brand new vulnerability in a way harder target. And if someone ever gets there, the unlock itself would very likely be the same couple of register writes. FP4 is not affected, but all the rest is (FP16/BF16/FP8/TF32 with FP32 accumulation). In which tasks is the unlock has most of the effect? I will put some examples on my 6000 PRO vs 5090s, former using 400W and latter 600W, at how much is the impact in performance because the NVIDIA neutering. - Training: Like LoRAs, finetuning, etc. - Example: Using the same batch size for 25GB VRAM to train a diffusion LoRA, my 6000 PRO is 70-90% faster than my 5090. - Diffusion: Models that do txt2img, txt2vid, img2img, img2vid, txt2aud, etc. - Example: My 6000 PRO not using fp16 accumulation is about 30-40% faster than my 5090. If using fp16 accumulation, it is 15% faster. - Prefill on LLMs: Heavily affected as well, since even when a model is marked as "int8" or "mixed precision" etc, the inference parts that the GPU uses include FP32 accumulation parts, except if explicitly set to not use them. - Example: My 6000 PRO on vLLM on a model that fits on a 5090 as well, it's 50-70% faster. On llamacpp, instead is about 30-40% faster. - TG with big batching: TG with a single batch is mostly bandwidth bound, and it uses FP32 acc instructions, but since it is so little in comparison with the need of bandwidth, it isn't a limitation. On the other hand, when you use batches with batch size 2, 4, 8, etc, compute again starts to being a bottleneck and then you have a performance impact. - Example: Same results as previous point. In which tasks the unlocks makes no difference: - TG with batch size 1: almost entirely bandwidth bound. - CUDA compute without tensor cores (normal FP32). - INT4/INT8 tensor operations. - FP4 on Blackwell (not neutered to begin with). - GEMM operations with FP16 accumulation instead, but those aren't very used. - Gaming. Is there a risk by unlocking the cards, like burning the card, crashes, etc? Short answer: NO. And again, NO. For the love of god guys, stop repeating this nonsense. The cards are still limited by their max power limit. They won't magically use 200% of your power budget with an unlock, they will just use the cores more efficiently. Let me explain: if you have a 3090 power limited at 300W, and without the unlock you were seeing only 250W in use, but after the unlock it uses 300W, it's not because the unlock did malicious things to your card. It's because the card can NOW stretch its legs and use the power to do more work. Real example from the Ada repo: an unlocked 4090 doing the same GEMMs peaked at 346W vs 313W stock, still under its 450W limit. If you were getting X performance at Y < max TDP, and now you get more than X performance at max TDP, obviously the card will be hotter, but that's still inside the POWER LIMIT YOU SET, not above it. Power spikes: those are normal on every card, and if you're using it to the full extent of its capabilities they can be more common. Are they risky? No, assuming you have a PSU with the wattage NVIDIA recommends per GPU. So what ARE the actual risks then? They're about the unlock process, not your card: - It runs an exploit on NVIDIA's firmware before the driver loads. If something fails mid-way, the tools stop and you need a full power off before trying again (a reboot isn't enough). Read the repo instructions, especially on laptops and multi-GPU setups. - NVIDIA could patch it in future drivers, or even burn anti-rollback fuses so the old Booter stops being accepted. That wouldn't damage your card, it would just close the door for good. "But, NVIDIA bins the dies to make these work 24/7 on the prosumer side but not on consumer, that's why they're locked!!!11" Also incorrect. NVIDIA uses the EXACT SAME dies for their consumer GPUs and their prosumer GPUs, and the FP32 accumulation speed has nothing to do with binning: the 3090 Ti and the A6000 have the exact same specs. The half speed is just a value written in a fuse that the firmware reads. Unlocking a card will not make it die sooner, nor will it crack the die or something. Sorry I have to repeat this again and again, but the amount of pure fury I get from reading comments like these made me do this. The model I run says it is Q8, or FP6, or 4bit, or INT4, or anything that doesn't mention FP32, am I affected? It depends on how the GPU actually does the math, not on the name of the quant: - If the kernel dequantizes the weights to FP16/BF16 and multiplies on the tensor cores with FP32 accumulation, you're affected. That's the case for FP16/BF16 models and most vLLM paths, including AWQ/GPTQ with Marlin kernels (the weights are INT4, but the math is FP16 with FP32 accumulation). - FP8 (W8A8) also accumulates in FP32, so it's affected too (Ada and Blackwell). - If the kernel uses integer tensor math (INT8 x INT8), it isn't affected. A lot of llama.cpp's quantized matmuls work like this, which is one reason llama.cpp sees a smaller gap than vLLM. - Attention (like FlashAttention) almost always uses FP16/BF16 with FP32 accumulation, so long contexts get hit even on quantized models. - FP4 (NVFP4/MXFP4) on Blackwell: not affected. Example: on a modded 48GB 4090, a quantized MoE model on an inference server got no gain at all after the unlock (0.98x on 8K prefill), while the FP16/BF16 matmuls doubled. That's what I have for now, if you guys have any more questions, let me know!

    312 points · 60 comments
  10. Reddit · · r/LocalLLaMA · u/panchovix

    GPU unlocks (FP32 accumulation): Why can it be unlocked on Turing (RTX 20), Ampere (RTX 30) and Ada (RTX 40) but no consumer Blackwell (RTX 50) and some misconceptions. Hello guys, hoping you're doing fine. Wall of text next I know, but I want to get this info out of my chest, all hand written lol. I wanted to make this post explaining some things about GPU unlocks that have been going on lately. What are these GPU unlocks doing? NVIDIA on purpose neuters tensor core performance when using FP32 accumulation (FP16, BF16, FP8 and TF32 inputs accumulating in FP32, which is what most AI/LLM/ML tasks use), for market segmentation. Normal FP32 on the CUDA cores (no tensor cores) is NOT affected. Consumer and prosumer GPUs use the exact same die (like GB202 between the 5090 and 6000 PRO, AD102 between the 4090 and 6000 Ada, or even literally 1:1 with the 3090 Ti vs A6000, both with the same core amounts and 84 SMs). How it works: the speed of each kind of tensor operation is set by fuses burned at the factory. On consumer cards, the fuse for "FP16/BF16 with FP32 accumulation" says HALF_SPEED, on the pro cards it says FULL_SPEED. These fuses don't cut any circuit, the GPU just reads them at boot and runs at that speed. The GPU also has an override register that can set them back to FULL_SPEED, but it's locked so only NVIDIA's most privileged firmware can write to it, not your PC. The unlocks open that lock and write FULL_SPEED on the override. With that, the consumer cards gain all the neutered performance imposed by NVIDIA. It doesn't give you more SMs, VRAM or anything like that, a 4090 is still a 4090, it just runs those instructions at the same rate a pro card does. Why can Turing, Ampere and Ada be unlocked? And what is unlocked on these cards? On these generations, the NVIDIA driver itself loads a small NVIDIA-signed firmware called the "Booter" onto a security microcontroller inside the GPU (SEC2, a "Falcon"), to start the GSP. The Booter runs in the highest privilege mode of the GPU (Heavy Secure, HS), which is exactly the one allowed to open the lock. In June 2026, Jon Pry published a paper ("A Canary in the Crypto Mine") showing that the Booter of the newer drivers has a buffer overflow: it copies its "signature" data using a length that you control, so you can overflow its stack (including the stack canary that is supposed to stop exactly this) and take control of the Booter while it is running in HS mode. The signature check still passes, because it is NVIDIA's own signed code running, the bug is inside it. With that, the unlock reuses instructions from NVIDIA's own Booter to open the lock, writes FULL_SPEED on the override, resets the card and lets the normal NVIDIA driver load. The unlock survives resets and driver reloads, but it's lost when you power off, which is why it runs on every boot before the NVIDIA driver loads. This was first done on mining cards (CMP 170HX: FP32 from 1/32 to full speed, and 10GB to 80GB of VRAM), and then ported to GeForce: - Turing: haohervchb/Turing-unlock (UEFI, Linux) - Ampere: Zagitta/gpu-unlock (Linux kernel module) - Ada: JustAResearcher/gpu-unlock-ada (Linux with kernel module) What gets unlocked: - FP16 with FP32 accumulation (Turing, Ampere, Ada) - BF16 with FP32 accumulation (Ampere, Ada; Turing has no BF16) - TF32 (Ampere, Ada) - FP8 with FP32 accumulation (Ada; Turing and Ampere have no FP8) Some numbers from those repos: 4090 FP16/BF16 with FP32 acc goes from 165 to 331 TFLOPS (raw instruction rate), 3090 Ti BF16 GEMM from 87 to 157 TFLOPS, 2080 Ti FP16 with FP32 acc from 47 to 94 TFLOPS. Real-world GEMMs gain less than 2x because the cards then hit their power limit (more on that below). Why can't consumer Blackwell be unlocked? The funny part is that on Blackwell the limitation is EXACTLY the same thing: same fuses, same override registers. I checked on my own cards: the 5090/5080/5070 Ti have the FP32 accumulation fuses set, and the 6000 PRO/4000 PRO don't. So it's not a hardware difference there either. What changed is the door. Starting with Hopper, and consumer Blackwell too, the root of trust of the GPU is the FSP (Foundation Security Processor), a RISC-V core that boots from its own ROM as soon as the GPU powers on, before the driver even loads. On Blackwell: - There's no Booter to abuse. The driver just sends the FSP a message with a hash + RSA-3K signature of the next firmware, and the FSP verifies and boots it. The Linux kernel docs literally say: "There is no SEC2 involvement, no Booter ucode, and no FWSEC-FRTS stage". I also checked it myself: in NVIDIA's 615 driver source the Booter only exists for Turing, Ampere and Ada (TU102, TU116, GA100, GA102, AD102), and the RTX 50 VBIOSes don't carry the Falcon firmware (FWSEC) that older cards did. - The firmware the driver ships for Blackwell is encrypted, and the debug and production images are the exact same encrypted bytes. The Ada payload was built from analysis of the decrypted debug Booter, on Blackwell there's no such shortcut. - NVIDIA has said it uses SPARK (a formally verifiable programming language) to prove its most critical RISC-V firmware free of runtime errors, and a buffer overflow like the one used on the older cards is exactly that kind of error. So, with what is known today, it can't be done. It isn't "impossible forever", but someone would need a brand new vulnerability in a way harder target. And if someone ever gets there, the unlock itself would very likely be the same couple of register writes. FP4 is not affected, but all the rest is (FP16/BF16/FP8/TF32 with FP32 accumulation). In which tasks is the unlock has most of the effect? I will put some examples on my 6000 PRO vs 5090s, former using 400W and latter 600W, at how much is the impact in performance because the NVIDIA neutering. - Training: Like LoRAs, finetuning, etc. - Example: Using the same batch size for 25GB VRAM to train a diffusion LoRA, my 6000 PRO is 70-90% faster than my 5090. - Diffusion: Models that do txt2img, txt2vid, img2img, img2vid, txt2aud, etc. - Example: My 6000 PRO not using fp16 accumulation is about 30-40% faster than my 5090. If using fp16 accumulation, it is 15% faster. - Prefill on LLMs: Heavily affected as well, since even when a model is marked as "int8" or "mixed precision" etc, the inference parts that the GPU uses include FP32 accumulation parts, except if explicitly set to not use them. - Example: My 6000 PRO on vLLM on a model that fits on a 5090 as well, it's 50-70% faster. On llamacpp, instead is about 30-40% faster. - TG with big batching: TG with a single batch is mostly bandwidth bound, and it uses FP32 acc instructions, but since it is so little in comparison with the need of bandwidth, it isn't a limitation. On the other hand, when you use batches with batch size 2, 4, 8, etc, compute again starts to being a bottleneck and then you have a performance impact. - Example: Same results as previous point. In which tasks the unlocks makes no difference: - TG with batch size 1: almost entirely bandwidth bound. - CUDA compute without tensor cores (normal FP32). - INT4/INT8 tensor operations. - FP4 on Blackwell (not neutered to begin with). - GEMM operations with FP16 accumulation instead, but those aren't very used. - Gaming. Is there a risk by unlocking the cards, like burning the card, crashes, etc? Short answer: NO. And again, NO. For the love of god guys, stop repeating this nonsense. The cards are still limited by their max power limit. They won't magically use 200% of your power budget with an unlock, they will just use the cores more efficiently. Let me explain: if you have a 3090 power limited at 300W, and without the unlock you were seeing only 250W in use, but after the unlock it uses 300W, it's not because the unlock did malicious things to your card. It's because the card can NOW stretch its legs and use the power to do more work. Real example from the Ada repo: an unlocked 4090 doing the same GEMMs peaked at 346W vs 313W stock, still under its 450W limit. If you were getting X performance at Y < max TDP, and now you get more than X performance at max TDP, obviously the card will be hotter, but that's still inside the POWER LIMIT YOU SET, not above it. Power spikes: those are normal on every card, and if you're using it to the full extent of its capabilities they can be more common. Are they risky? No, assuming you have a PSU with the wattage NVIDIA recommends per GPU. So what ARE the actual risks then? They're about the unlock process, not your card: - It runs an exploit on NVIDIA's firmware before the driver loads. If something fails mid-way, the tools stop and you need a full power off before trying again (a reboot isn't enough). Read the repo instructions, especially on laptops and multi-GPU setups. - NVIDIA could patch it in future drivers, or even burn anti-rollback fuses so the old Booter stops being accepted. That wouldn't damage your card, it would just close the door for good. "But, NVIDIA bins the dies to make these work 24/7 on the prosumer side but not on consumer, that's why they're locked!!!11" Also incorrect. NVIDIA uses the EXACT SAME dies for their consumer GPUs and their prosumer GPUs, and the FP32 accumulation speed has nothing to do with binning: the 3090 Ti and the A6000 have the exact same specs. The half speed is just a value written in a fuse that the firmware reads. Unlocking a card will not make it die sooner, nor will it crack the die or something. Sorry I have to repeat this again and again, but the amount of pure fury I get from reading comments like these made me do this. Does affect gaming performance? None known at the moment, except if somehow NVIDIA uses FP32 accumulation for DLSS or FG, which I doubt. I'm almost sure they use FP16 accumulation (or lower precisions) there, because if they used FP32 accumulation the perf hit would be insane on consumer cards. The model I run says it is Q8, or FP6, or 4bit, or INT4, or anything that doesn't mention FP32, am I affected? It depends on how the GPU actually does the math, not on the name of the quant: - If the kernel dequantizes the weights to FP16/BF16 and multiplies on the tensor cores with FP32 accumulation, you're affected. That's the case for FP16/BF16 models and most vLLM paths, including AWQ/GPTQ with Marlin kernels (the weights are INT4, but the math is FP16 with FP32 accumulation). - FP8 (W8A8) also accumulates in FP32, so it's affected too (Ada and Blackwell). - If the kernel uses integer tensor math (INT8 x INT8), it isn't affected. A lot of llama.cpp's quantized matmuls work like this, which is one reason llama.cpp sees a smaller gap than vLLM. - Attention (like FlashAttention) almost always uses FP16/BF16 with FP32 accumulation, so long contexts get hit even on quantized models. - FP4 (NVFP4/MXFP4) on Blackwell: not affected. Example: on a modded 48GB 4090, a quantized MoE model on an inference server got no gain at all after the unlock (0.98x on 8K prefill), while the FP16/BF16 matmuls doubled. That's what I have for now, if you guys have any more questions, let me know!

    235 points · 71 comments

Latest stargazers

The last 10 distinct accounts we observed this year.

Most active participants

PR, issue, comment & review events in the past year.

Packages

No packages found.

README badges

Embed a badge in your README or website.

  • JustAResearcher/gpu-unlock-ada reached #2 in daily mentions on gitwal · Oct 25, 2026
Live mentions · last 30 days
JustAResearcher/gpu-unlock-ada mentions in the last 30 days