Zagitta

I got pretty good results with my 3090 on Qwen 27b. Yeah, the rack is completely unusable when you launch the llm, but i wouldn't say its slow. Btw, fellow 3090 user, some time ago i saw this: Zagitta/gpu-unlock Can't try it personally because windows, but maybe it will help you.

中古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が更新でどこまで使えるようになるかという楽しみも増えてきた。

RTX 3090のGPU Unlockを検証：速くなる処理、変わらない処理 RTX 3090で比較した処理 GPU Unlockを適用すると、RTX 3090で動かすLLMや画像生成はどの程度速くなるのか。行列演算のベンチマークだけでは、普段使う処理への効果は分からない。同じRTX 3090で27Bの量子化LLM、小型のBF16 LLM、画像生成、学習を実行し、適用前後を比較した記録を整理した。 GPU Unlockの仕組み 使用したのはZagitta/gpu-unlock 1.0.0だ。開発元によると、GeForce AmpereでFP16・BF16を入力とし、FP32で累積する演算の発行レート制限に関わる設定を変更する。Linuxの起動初期に動くカーネルモジュールで、通常のNVIDIAドライバーがGPUを使い始める前に設定を変える。 「発行レートの解除」は、アプリケーション全体の処理時間が半分になるという意味ではない。モデルの重みの読み出しや演算以外の処理、CPUへのオフロードにも時間がかかるためだ。効果は実際に使う処理で確かめる必要がある。 ここでは性能と出力を比較する。導入・解除手順はバージョンによって異なるため、測定時のREADMEと現在の開発元を分けて参照してほしい。Windows版や別世代のGPUは検証していない。 実験環境 GPU：RTX 3090、VRAM 24GB。この個体の既定電力上限は390W。ファン・クロックは自動制御。 RAM：DDR5 96GB。 Ubuntu 26.04.1、Linux 7.0.0-38-generic、NVIDIA Open Kernel Module 595.99.02。 PyTorch 2.14.0+cu132。使用ライブラリと実行バイナリは適用前後で固定。 GPU Unlock：Zagitta/gpu-unlock 1.0.0、コミット af28cbbfd3d922a659227ecfb7369adfd924cf03。 モデルとデータはIntel Optane SSD P5800X上に配置。生成・学習の主測定はモデルを読み込み終えた後に行う。 試走で画面描画による負荷を確認したため、本測定ではGNOMEとGPU描画専用プロセスを一時停止し、プロセス別のGPU使用率で干渉を監視した。 結果 実測グラフ 4,096³の行列積はBF16で69.811→119.923 TFLOPSとなり、対応する試行の速度比は約1.72倍だった。FP32は23.369→23.621 TFLOPSで、速度比は約1.005倍にとどまった。精度や処理によって効果は異なる。ただし、この比較だけでは、量子化LLMのデコード速度が変わらなかった原因をメモリ帯域など一つに絞ることはできない。 グラフの線は対応する試行の四分位範囲を示す。信頼区間ではない。速度比1倍は適用前後で同じ速度だったことを表す。画像生成は入力条件と反復を合わせた18組、学習は独立した3回の開始を対応付けた。 表の数値は中央値を示す。学習は同じ初期状態から3回開始し、各試行で20回分の重み更新を集計してから、3試行の結果を比較した。 用途・指標 適用前 適用後 変化 27B Q5_K_M・16k入力後のデコード 35.032 tokens/s 35.022 tokens/s ほぼ同じ 1.7B BF16・16k入力の処理 12,346.513 tokens/s 18,042.784 tokens/s 約1.46倍 SDXL・1枚の生成時間 7.656秒 5.477秒 約28.5%短縮 Z-Image-Turbo・1枚の生成時間 17.798秒 14.607秒 約17.9%短縮 Qwen3-0.6B・全学習 7,206.476 tokens/s 8,874.998 tokens/s 約1.23倍 Qwen3-1.7B・LoRA学習 3,244.588 tokens/s 4,254.175 tokens/s 約1.31倍 SDXL・LoRA学習 1.836画像/s 2.380画像/s 約1.30倍 速度比は対応する適用前後の試行ごとに比率を求め、その中央値を示した。表の適用前後の中央値を単純に割った値とは、丸めや集計方法による違いがある。時間短縮率は処理時間の中央値から計算した。全指標は末尾の付録と集計CSVで確認できる。 LLMの入力処理とデコード 27BのQ5量子化LLMは、16,384トークンを入力した後のデコード速度が 35.03 → 35.02 tokens/s（-0.0%）で、ほぼ変わらなかった。一方、1.7B BF16は同じ入力長で、入力処理が 12,347 → 18,043 tokens/s（+46.1%）に向上した。LLMの速度を比較するときは、入力処理とデコードを分けて見る必要がある。 画像生成と学習の変化 1枚あたりの生成時間は、SDXLが 7.66 → 5.48 秒（28.5%短縮）、Z-Imageが 17.80 → 14.61 秒（17.9%短縮）となった。学習でも、次のように処理速度が向上した。 Qwen3-0.6B 全学習：7,206.476 → 8,874.998 tokens/s、23.2%向上。 Qwen3-1.7B LoRA：3,244.588 → 4,254.175 tokens/s、31.1%向上。 SDXL LoRA：1.836 → 2.380 画像/s、29.6%向上。 今回の結果では、すべてのLLM処理が一様に速くなったわけではない。量子化方式やモデル、入力長、CPUオフロードの有無が違えば、この数値をそのまま当てはめることはできない。 電力の推移 電力・温度・クロックはベンチマーク本体とは別のsystemd監視でも約1秒ごとに記録した。取得した1,528サンプルの最大記録間隔は1.017秒で、長い欠測はなかった。元のレポートでは、記録の間隔が3秒を超えた箇所で線を切り、欠測区間を補間しないようにしている。 図は保存された測定時系列を示す。室温を一定に保った比較ではない。 今回の連続実行中に再起動は起きなかった。ただし、この結果から以前の再起動原因は特定できず、長期安定性を保証することもできない。 結果から 今回の設定では、量子化27Bモデルのトークン生成はほとんど速くならなかった。BF16の入力処理や画像生成、学習には改善を期待できる結果だったが、処理時間がどの程度短くなるかはモデルと実行条件によって変わるのだろう。 効果を判断するには、行列積の速度比だけでなく、普段使う処理の待ち時間と出力を確認する。そのうえで、1台を短時間測った今回の検証では評価できていない長期安定性や耐久性を、性能向上とは分けて考えていきたい。 ただ、電力消費や発熱のし具合がほぼ変わらずに学習性能が上がったのはすごく良いと思う。常時適用済みでもいいかなと思った。 測定条件と比較方法 LLMの推論 新規入力と、キャッシュを再利用する会話継続時の条件を分けて測定した。 条件 設定 新規入力 512・4096・16384トークン。キャッシュの再利用は無効 会話継続 4096トークンを再利用 生成 256トークンを生成する時間を測定 測定回数 各条件でウォームアップ2回、本測定7回 サーバー側で実際に評価されたトークン数も確認した。 TTFTとトークン間隔の計測範囲は、モデルによって異なる。 指標 27B 1.7B TTFT localhostのHTTPクライアントに最初のトークンが届くまでの時間 GPUに常駐させたモデルで、入力処理から最初のトークンを算出するまでの計算時間。通信やトークン化は含めない トークン間隔 クライアントへの到着間隔 CUDAイベントの経過時間 このため、それぞれのモデル内で適用前後を比較する。トークン間隔は各リクエストでP50/P95を求め、7リクエスト分の中央値を集計した。数値は添付の集計CSVに記録した。 画像生成 写真・物撮り・イラストの3プロンプトと3seedを組み合わせ、それぞれ2回繰り返した。 モデル 解像度 ステップ数 その他の設定 SDXL 1024×1024 30 CFG 5 Z-Image-Turbo 1024×1024 設定9ステップ、実際のDiT実行8回 guidance 0、モデル単位のCPUオフロード 学習 測定 モデル 設定 LLM全学習 Qwen3-0.6B BF16混合精度、系列長1024、マイクロバッチ2、勾配蓄積4 LLM LoRA Qwen3-1.7B rank 16、系列長2048、マイクロバッチ1、勾配蓄積4 画像LoRA SDXL 1024×1024、rank 16、マイクロバッチ1、勾配蓄積4 LLMの学習テキストにはWikiText-2を使った。画像LoRAにはDiffusersのdog-example実画像を使い、潜在表現とテキスト埋め込みをキャッシュした。学習速度にはforward、backward、勾配蓄積、optimizer更新を含む。 資料とデータ サムネイルの製品画像：NVIDIA GeForce RTX 3090公式ページの公式画像。Founders Editionの製品画像であり、測定個体を撮影したものではない。 GPU Unlock開発元 llama-bench Qwen3-1.7B、Qwen3-0.6B SDXL、Z-Image-Turbo WikiText：CC BY-SA 3.0 / GFDL。 Diffusers dog-example この記事に添付した集計CSVと出力照合結果、元の検証資料内のHTMLレポート・生データで数値と集計方法を確認できる。 付録：LLM・画像生成・学習・行列演算の詳細 実験 指標 適用前 適用後 単位 対応試行の速度比 試行数 前/後 27B Q5_K_M / 新規入力 512 tokens TTFT 0.545 0.526 秒 1.037倍 7/7 27B Q5_K_M / 新規入力 512 tokens 入力処理 944.057 979.584 tokens/s 1.036倍 7/7 27B Q5_K_M / 新規入力 512 tokens デコード 37.962 37.945 tokens/s 1.000倍 7/7 27B Q5_K_M / 新規入力 4,096 tokens TTFT 3.749 3.720 秒 1.008倍 7/7 27B Q5_K_M / 新規入力 4,096 tokens 入力処理 1,092.980 1,101.389 tokens/s 1.008倍 7/7 27B Q5_K_M / 新規入力 4,096 tokens デコード 37.137 37.142 tokens/s 1.000倍 7/7 27B Q5_K_M / 新規入力 16,384 tokens TTFT 15.832 15.780 秒 1.004倍 7/7 27B Q5_K_M / 新規入力 16,384 tokens 入力処理 1,035.076 1,038.498 tokens/s 1.004倍 7/7 27B Q5_K_M / 新規入力 16,384 tokens デコード 35.032 35.022 tokens/s 1.000倍 7/7 27B Q5_K_M / 文脈4,096＋追加会話64 tokens TTFT 0.199 0.188 秒 1.058倍 7/7 27B Q5_K_M / 文脈4,096＋追加会話64 tokens 入力処理 323.541 342.103 tokens/s 1.058倍 7/7 27B Q5_K_M / 文脈4,096＋追加会話64 tokens デコード 37.060 37.051 tokens/s 1.000倍 7/7 Qwen3-1.7B BF16 / 入力 512 tokens TTFT 0.039 0.026 秒 1.478倍 7/7 Qwen3-1.7B BF16 / 入力 512 tokens 入力処理 13,270.344 19,630.939 tokens/s 1.479倍 7/7 Qwen3-1.7B BF16 / 入力 512 tokens デコード 89.186 89.442 tokens/s 1.003倍 7/7 Qwen3-1.7B BF16 / 入力 4,096 tokens TTFT 0.271 0.183 秒 1.475倍 7/7 Qwen3-1.7B BF16 / 入力 4,096 tokens 入力処理 15,132.200 22,346.744 tokens/s 1.475倍 7/7 Qwen3-1.7B BF16 / 入力 4,096 tokens デコード 89.065 89.573 tokens/s 1.007倍 7/7 Qwen3-1.7B BF16 / 入力 16,384 tokens TTFT 1.327 0.908 秒 1.461倍 7/7 Qwen3-1.7B BF16 / 入力 16,384 tokens 入力処理 12,346.513 18,042.784 tokens/s 1.461倍 7/7 Qwen3-1.7B BF16 / 入力 16,384 tokens デコード 64.195 65.741 tokens/s 1.024倍 7/7 SDXL BF16 / 1024×1024 画像生成 7.656 5.477 秒/枚 1.398倍 18/18 Z-Image-Turbo BF16 / 1024×1024 画像生成 17.798 14.607 秒/枚 1.218倍 18/18 Qwen3-0.6B 全学習 / 固定データ・重み更新 学習処理 7,206.476 8,874.998 tokens/s 1.231倍 3/3 Qwen3-1.7B LoRA / 固定データ・重み更新 学習処理 3,244.588 4,254.175 tokens/s 1.311倍 3/3 SDXL LoRA / 1024×1024 画像学習 1.836 2.380 画像/s 1.296倍 3/3 行列積 / BF16 / 4,096³ 行列演算 69.811 119.923 TFLOPS 1.718倍 5/5 行列積 / FP16 / 4,096³ 行列演算 68.726 116.008 TFLOPS 1.688倍 5/5 行列積 / TF32 / 4,096³ 行列演算 34.440 58.543 TFLOPS 1.700倍 5/5 行列積 / FP32 / 4,096³ 行列演算 23.369 23.621 TFLOPS 1.005倍 5/5 行列積 / BF16 / 8,192³ 行列演算 72.115 118.457 TFLOPS 1.641倍 5/5 行列積 / FP16 / 8,192³ 行列演算 70.861 113.999 TFLOPS 1.610倍 5/5 行列積 / TF32 / 8,192³ 行列演算 38.171 64.101 TFLOPS 1.680倍 5/5 行列積 / FP32 / 8,192³ 行列演算 24.965 25.123 TFLOPS 1.005倍 5/5

A free kernel module made my RTX 3090 generate images 55% faster with 40% less energy (ComfyUI, Z-Image Turbo, bit-identical outputs)  benchmarked GPU Unlock on my 3090 in ComfyUI. It's a Linux kernel module that lifts the GeForce FP16/BF16 tensor-core throttle on RTX 30 cards. |ComfyUI|Stock|Unlock|Unlock + undervolt| |:-|:-|:-|:-| |Z-Image Turbo BF16, 1024², 8 steps|7.46 s/img|4.95 (+51%)|4.82 (+55%)| |SD 1.5 FP16, 1024², 30 steps|6.40 s/img|4.64 (+38%)|4.52 (+41%)| - Same images: every output's pixels were SHA-256 identical to stock at a fixed seed, including a 2-hour soak of 540 batches. - Energy per image down 40% (2,369 J → 1,410 J). - The weird part: my undervolt slowed the card at stock but sped it up once unlocked, because the card then hits its power limit and lower voltage buys clocks. - Don't use --fast in ComfyUI if you want the gain. It switches matmuls to FP16 accumulation, which isn't throttled to begin with. Linux only. Only a full power-off reverts it. Github repo: Esequiel378/gpu-unlock-3090-results

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

gpu-unlock: Free Tool Lets GeForce RTX Cards Run AI Up to 2x Faster #Shorts gpu-unlock is a free, open-source Linux kernel module that removes the half-rate cap on GeForce RTX tensor cores at boot, with the stock NVIDIA driver and no BIOS flash. Per the README: up to 2x FP16/BF16/TF32 tensor throughput, an RTX 3090 going from 75 to 125 BF16 TFLOPS, and user-reported +25-55% LLM prompt processing, +25-50% fine-tuning and +30-55% image generation. RTX 30 is stable, RTX 40/20 experimental, Linux only. 11K+ GitHub stars. Source: x.com Repo: Zagitta/gpu-unlock Not financial advice. Modify your system at your own risk. #AI #GPU #NVIDIA #OpenSource #LocalAI

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!

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!

Inside Zagitta/gpu-unlock: Unlocking Full-Rate FP16 & BF16 Tensor Math on NVIDIA RTX 30-Series GPUs Inside Zagitta/gpu-unlock: Unlocking Full-Rate FP16 & BF16 Tensor Math on NVIDIA RTX 30-Series GPUs !Image description For home AI builders and ML researchers, the NVIDIA GeForce RTX 3090 and RTX 3090 Ti remain legendary price-to-performance workhorses thanks to their 24 GB of GDDR6X VRAM. However, anyone who has benchmarked dense FP16 or BF16 matrix multiplication (GEMM) on consumer Ampere silicon knows about a frustrating artificial ceiling: NVIDIA throttles FP32-accumulated Tensor Core throughput on GeForce cards to half the rate of professional Ampere workstation and datacenter GPUs. The physical Tensor Cores inside the GA102 die aren't missing the transistors—the instruction issue rate is capped by firmware via internal hardware speed selector registers. Enter Zagitta/gpu-unlock, a rapidly trending open-source Linux kernel module (kmod) that removes NVIDIA's FP16/BF16 Tensor Core rate limit on RTX 30-series GPUs during early boot—without flashing a custom VBIOS or modifying the proprietary NVIDIA driver. Let's break down how NVIDIA's Ampere instruction cap works, how gpu-unlock bypasses it in initramfs, and what real-world TFLOPS gains look like across dense GEMM and local LLM workloads. --- The Hardware Bottleneck: Why Consumer Ampere Tensor Cores Run at Half Speed On NVIDIA's Ampere architecture (GA102, GA103, GA104, GA106), Tensor Cores support mixed-precision matrix multiply-accumulate (MMA) operations where inputs are FP16 or BF16 and the accumulator is either FP16 or FP32. While FP16 accumulation runs at full speed on GeForce cards, modern deep learning training, LoRA fine-tuning, and many inference kernels rely on FP32 accumulation (FP16 -> FP32 and BF16 -> FP32) and TF32 to maintain numerical stability. On consumer RTX 30-series cards, firmware locks the hardware speed selectors to half rate for these instructions: | Precision Mode (Dense GEMM) | Professional Ampere (Full Rate) | Consumer GeForce RTX 30-Series (Stock) | | :--- | :--- | :--- | | FP16 (FP16 Accumulate) | Full Issue Rate | Full Issue Rate | | FP16 (FP32 Accumulate) | Full Issue Rate | Half Rate (Throttled) | | BF16 (FP32 Accumulate) | Full Issue Rate | Half Rate (Throttled) | | TF32 (TensorFloat-32) | Full Issue Rate | Half Rate (Throttled) | --- How Zagitta/gpu-unlock Lifts the Cap Without Patching the NVIDIA Driver Previous attempts to unlock consumer NVIDIA features either required risky hardware VBIOS modifications or patching binary blobs inside nvidia.ko—an approach that breaks every time your Linux distribution updates the kernel or NVIDIA driver. Zagitta/gpu-unlock takes a much cleaner pre-driver timing approach via an initramfs kernel module: Linux Early Boot (initramfs) │ ▼ 1. gpu_unlock.ko binds to target Ampere PCIe device(s) │ ▼ 2. Executes V67 / PLM coprocessor privilege sequence │ ▼ 3. Writes internal Speed Selector registers: • SS0 = 0x88888888 (Full BF16 instruction issue rate) • SS1 = 0x8 (4-bit IMLA4 configuration) │ ▼ 4. Triggers PCIe Function Level Reset (FLR) & unbinds │ ▼ 5. Unmodified proprietary nvidia.ko driver loads normally with full-rate Tensor Core throughput preserved! 1. The V67 / PLM Unlock Sequence Derived from prior research into NVIDIA CMP (Cryptomining Processor) hardware unlockers, the module uses the V67 / PLM (Privilege Level Mask) sequence on the GPU's embedded microcontroller to temporarily gain write access to protected hardware configuration registers. 2. Reprogramming SS0 and SS1 Speed Selectors Once privilege masks are lowered, gpu_unlock writes directly to the hardware Speed Selector registers: - SS0 (0x88888888): Switches BF16 / FP16-with-FP32-accumulate Tensor Core pipelines from half-rate to full instruction issue rate. - SS1 (0x8): Configures the 4-bit IMLA4 selector value. 3. Function Level Reset (FLR) and Clean Handoff After writing the registers, the module issues a PCIe Function Level Reset (FLR) so the new speed selector latches take effect cleanly, then unbinds from the GPU. Moments later in the boot sequence, the stock, unmodified NVIDIA driver (nvidia.ko) binds to the card and inherits the unlocked Tensor Core issue rates. --- Benchmark Results: Stock vs. Unlocked (RTX 3090 Ti / RTX 3090) In dense matrix multiplication (GEMM) benchmarks, unlocking the speed selectors produces dramatic throughput increases on GA102 hardware: | Workload / Precision | Stock RTX 3090 Ti | Unlocked (gpu-unlock) | Throughput Gain | | :--- | :--- | :--- | :--- | | BF16 GEMM (FP32 Accum) | ~87.50 TFLOPS | ~157.41 TFLOPS | +79.9% | | TF32 GEMM | ~42.58 TFLOPS | ~82.61 TFLOPS | +94.0% | | FP16 GEMM (FP32 Accum) | ~87.46 TFLOPS | ~118.39 TFLOPS | +35.4% | (On standard RTX 3090 cards, community benchmarks similarly report dense BF16 GEMM climbing from ~77.5 TFLOPS to ~129.6 TFLOPS, depending on board power limits and clock speeds.) What Does This Mean for Real-World AI Workloads? It is important to separate compute-bound workloads from memory-bandwidth-bound workloads: - Prompt Processing (Prefill) & Fine-Tuning: Compute-bound operations—such as processing long context prompts in llama.cpp or vLLM, running vision encoders/diffusion models in BF16, or training/LoRA fine-tuning—benefit directly from the unlocked BF16, FP16, and TF32 matrix math throughput. - Single-Batch Token Generation (Decode): Autoregressive token generation at batch size 1 is bottlenecked by GDDR6X memory bandwidth (936 GB/s on an RTX 3090), so decode tokens/sec see only minor changes unless you are running larger batch sizes. --- Supported GPUs Zagitta/gpu-unlock targets NVIDIA Ampere consumer silicon across four die families: - GA102: RTX 3090 Ti, RTX 3090, RTX 3080 Ti, RTX 3080 (10GB / 12GB) - GA103: RTX 3080 Ti Laptop / GA103 desktop variants - GA104: RTX 3070 Ti, RTX 3070, RTX 3060 Ti - GA106: RTX 3060 (12GB) --- Installation & Kernel Parameter Configuration Because gpu-unlock integrates with DKMS and your system's initramfs (initramfs-tools or dracut), installation is straightforward on modern Linux distributions: # 1. Clone the repository git clone https://github.com/Zagitta/gpu-unlock.git cd gpu-unlock # 2. Build and install via DKMS + update initramfs sudo make install Next, enable the unlock on boot by adding the kernel command-line parameter (for example, in /etc/default/grub under GRUB_CMDLINE_LINUX_DEFAULT): gpu_unlock.targets=all (You can also target specific PCIe bus IDs instead of all in multi-GPU rigs.) To revert your GPU back to factory stock behavior at any time, simply remove gpu_unlock.targets=all from your kernel parameters or uninstall the DKMS module and reboot—since nothing is flashed to the VBIOS EEPROM, a cold reboot always restores factory defaults. --- Key Takeaways Zagitta/gpu-unlock is a masterclass in low-level Linux kernel and PCIe hardware engineering. By combining pre-driver initramfs timing with register-level speed selector configuration and Function Level Reset (FLR), it breathes huge new compute life into existing RTX 30-series GPUs without touching VBIOS flash chips or proprietary driver binaries. Explore the source code, register documentation, and benchmark scripts on GitHub: Zagitta/gpu-unlock

NVIDIA GPUs Have Hidden AI Performance?! RTX 20, 30 & 40 Series Github Project Link: RTX 2xxx nlzy/turing-unlock RTX 3xxx Zagitta/gpu-unlock RTX 4xxx JustAResearcher/gpu-unlock-ada