RTX 4090の制限解除はどうする？gpu-unlockの導入条件・戻し方とTensor演算の効果、RTX 5090との違い

RTX 4090の「制限解除」は、電力上限を上げるオーバークロックとは別の処理です。gpu-unlock-adaは、GPUの起動時にTensorコアの演算速度を決める設定を変更します。

公開されたRTX 4090の測定では、FP16・BF16入力とFP32累積を組み合わせた命令の処理速度が約2倍になりました。ただし、行列計算やAIアプリ全体が一律2倍になるわけではなく、RTX 5090相当のゲーム性能を得られる根拠にもなりません。

導入を検討できるのは、Linuxの起動設定を復旧でき、使っているAI処理で前後比較できる人です。ゲームのFPS向上だけが目的なら、この解除のために起動環境を変更する判断は勧められません。

制限解除で速くなる演算とゲーム性能の違い

Tensorコアは行列の掛け算などを高速に処理する演算器です。「FP16・BF16入力／FP32累積」は、入力の数値形式と、途中の計算結果を足し合わせる精度の組み合わせを表します。今回の約2倍は、この特定の演算経路で測った命令スループットです。

公開プロジェクト内の所有者による独立検証では、同じRTX 4090・Linux 7.2.11-arch1-1・NVIDIA 615.78.08・CUDA 13.4.92・450Wの電力上限を使っています。実行したモジュールはリビジョン8855e7bで、GNOMEデスクトップが動作した状態の通常／解除後の1組の比較です。

命令測定は5回の計時のうち最良値、cuBLASの正方行列積（GEMM）は5回の計時の中央値です。別の指標なので、速いほうの数字だけをアプリの改善率として使うことはできません。数値整合性のテストは通過していますが、任意のAIモデルの正確さや長期安定性まで保証する結果ではありません。

AIアプリの効果は実際の処理で判定する

行列サイズ・数値形式・使われるカーネルが変わると改善幅も変わります。上記のFP16の3条件では約12～34%向上した一方、BF16の4096³ではほぼ横ばいでした。生成AIの画像1枚の所要時間やLLMの応答速度は、読み込みやメモリ転送なども含むため別に測る必要があります。

改造48GB版RTX 4090での別の公開試験では、量子化MoEモデルの8K prefillは0.983倍で、改善していません。これは1枚・1回のコールドブート・1ワークロードの結果です。通常の24GB版や、別のモデル・画像生成へそのまま一般化せず、使うモデル・精度・バッチサイズを固定して比較してください。

RTX 5090相当と判断できない理由

RTX 4090はAda Lovelace世代で24GB GDDR6X、RTX 5090はBlackwell世代で32GB GDDR7です。Tensor演算の設定変更で、物理的なメモリ容量や世代そのものがRTX 5090へ変わるわけではありません。

同じ解除検証でスカラーFP32は76.4→76.3 TF/s、INT8は641.1→640.3 TOP/sと、ほぼ同じでした。Tensor命令の約2倍から、ゲームの描画FPSやレイトレーシング性能の向上率を計算することはできません。買い替えと比べるときは、遊ぶゲームの実測FPS、必要なVRAM、使うAIアプリの所要時間をそれぞれ判断材料にしてください。

導入前に確認するGPU・Linux・復旧条件

• 対象GPU：デスクトップ版RTX 4090のPCI IDは10de:2684です。4090 Dや4090 Laptop GPUは別の実験対象で、この手順をそのまま当てはめません。
• 環境：Linux用カーネルモジュールを使います。Git、実行中カーネルのヘッダー、Cビルド環境、DKMS、Python 3、zstdが必要です。
• 起動順：NVIDIAドライバーがGPUを使用する前に、initramfsからgpu_unlockを読み込みます。通常起動後に手動でモジュールを読み込むだけでは解除できません。
• 復旧手段：gpu_unlockの引数を含まない通常のブートエントリーを残します。GPUが1枚で表示も担う場合は、画面が戻らないときの復旧操作まで確認してください。

WindowsのNVIDIAコントロールパネルやAfterburnerへ同じ設定を入れる手順ではありません。別GPU向けのWindows実験もありますが、下記のLinux用コマンドをWindowsで実行するものではありません。

RTX 4090の制限解除手順

以下のコマンドは所有するLinux機で実行する例です。管理者権限でインストールする前に、取得したソースと現在のQuick Startを読み、利用中のディストリビューション・ブートローダーで復旧できることを確かめてください。

1. 変更前の環境とGPUのPCIアドレスを記録する

lspci -Dnn | grep -i nvidia
uname -r
cat /proc/cmdline

GPUの行にある10de:2684と、先頭の完全なPCIアドレスを確認します。0000:01:00.0は例なので自分の値へ置き換えます。複数GPUでも最初は対象1枚だけを明示し、targets=allは使いません。通常状態で使うアプリの処理時間・出力・GPU温度・消費電力も保存しておきます。

2. ソースからパッケージをビルドする

git clone https://github.com/JustAResearcher/gpu-unlock-ada.git
cd gpu-unlock-ada
make install
python3 tools/print_boot_option.py

make installはArch、Debian/Ubuntu、Fedora/RHEL系のパッケージ経路を選びます。ビルド中にはSHA-256で固定されたNVIDIA 610.43.03の入力ファイルをダウンロードし、ファームウェアを手元で生成します。この番号は生成素材の版であり、使用中ドライバーを610.43.03へ変更する指示ではありません。インストール時にはsudoが求められます。

3. 対象1枚の起動引数を追加する

gpu_unlock.targets=0000:01:00.0

print_boot_option.pyが表示した自分のGPUの行を使います。デスクトップ版RTX 4090の2684経路はこのtargets指定が基本で、別GPU用のexperimentalフラグは加えません。

1. GRUBの初回テストは、起動メニューで使うカーネルの項目を選び、eキーで一時編集します。linuxまたはlinuxefiで始まる行の末尾へ対象引数を追加し、Ctrl+Xで起動します。この編集はその回だけで、通常の設定ファイルは変更しません。
2. systemd-bootの初回テストではbootctl statusで使用中のエントリーを調べ、複製したテスト用エントリーのoptionsへ追記します。initrdがgpu_unlock入りの新しいinitramfsを指していることも確かめます。既定の通常エントリーは変更せず、メニューからテスト用を1回だけ選びます。

GRUBでも、選択するカーネルのinitramfsへgpu_unlockが統合されていることが前提です。一時編集だけでモジュールの組み込みを代替できるわけではありません。

通常の起動エントリーは残したまま、最初はテスト用を1回だけ選んで起動してください。Secure Bootなどでモジュールが拒否される環境では、ディストリビューションの署名・モジュール読み込み方針を確認し、原因を特定せず保護設定を変更して進めないでください。

4. 完全に電源を切って起動する

OSを正常終了し、AC電源を切って約30秒待ってから電源を戻します。初回にはGPUのファームウェア状態を新しくするための完全電源断が指定されています。稼働中の処理がある共有機では実施せず、使用者と停止時間を調整してください。

5. ログ・GPUの健全性・実アプリを確認する

journalctl -k -b --no-pager | grep -E 'gpu_unlock: unlocked|gpu_unlock: already unlocked|gpu_unlock: unlock failed|post-FLR SEC2'
nvidia-smi
uname -r
cat /proc/cmdline

選んだGPUのgpu_unlock: unlocked、正常なnvidia-smi、実際に使う処理の動作を確認します。モジュールがロードされたことだけを成功判定にしません。単一GPU機ではnvidia-smi –query-gpu=uuid –format=csv,noheaderでUUIDを取得し、python3 tools/read_sm_rates.py –expect-uuidに実際のUUIDを渡す読み取り確認も用意されています。

速度比較は同じカーネル・ドライバー・実行バイナリ・電力上限・モデル条件で行います。速度だけでなく出力の整合性とカーネルログのXidエラーも点検してください。成功後に通常の再起動でも一時編集で同じ引数を付けて同じ確認を1回行い、安定して動く構成を確かめてから永続設定を検討します。カーネル更新後はinitramfsと対象エントリーを再確認します。

永続化する場合、Ubuntu/DebianのGRUBでは/etc/default/grubのGRUB_CMDLINE_LINUX_DEFAULTの既存の引用符内へ引数を追記し、sudo update-grubを実行します。ArchのGRUBでは追記後にsudo grub-mkconfig -o /boot/grub/grub.cfgを使います。永続化後も、ブートメニューのeキー編集でgpu_unlock.*を削除して起動できることを確認し、引数のない通常エントリーも確保してください。

元に戻す方法と起動できない場合の対応

1. ブートメニューで保存しておいた通常エントリーを選ぶか、その回の起動引数からgpu_unlock.*を取り除きます。
2. 永続設定したGRUBなどの引数からもgpu_unlock.*を削除し、使用したブートローダーの設定を再生成します。systemd-bootで既定を変更した場合は、通常エントリーへ既定を戻し、bootctl statusで確認します。
3. ファームウェアの停止失敗やDMAバッファー保持のログが出た場合は、モジュールを強制アンロードせず、完全に電源を切ってからやり直します。
4. 不要なら生成されたパッケージをパッケージ管理機能でアンインストールし、initramfsの統合も除去します。引数の削除は次回以降の解除適用を止める操作です。正常に動作していた場合も、解除前のハードウェア状態へ戻すときはOSを正常終了し、AC電源を切って約30秒待ち、通常エントリーで起動します。その後にGPUの認識とアプリの動作を確認し、通常状態との速度比較もこの電源断後に行います。

エラー時に起動済みのNVIDIAドライバーを無理に外して再実行する方法は避けてください。復旧手段がない表示用GPU1枚の構成なら、導入を始める前に通常起動の選択・設定編集ができる環境を用意するのが先です。

消費電力・温度・故障リスクはどう判断する？

同じ450W上限の独立検証では、GPU使用率50%以上のサンプルに限った温度範囲は通常50～68℃、解除後54～73℃、最大の観測電力は307.67W→308.59Wでした。約100ms間隔の短い測定なので、真のピーク電力・長時間の温度・電気的な安全性の証明ではありません。

電力上限が同じでも発熱や動作クロックまで一定になるとは限りません。実アプリを同じ条件で走らせ、温度、消費電力、エラー、出力の変化を比較し、異常が出たら通常構成へ戻してください。電力上限の引き上げや別のオーバークロックを同時に加えると原因を分けにくくなります。

この公開測定から故障確率や寿命の変化を数値化することはできません。長時間の安定性試験ではなく、画面表示の引き継ぎや複数GPUもRTX 4090の元の検証範囲に含まれません。保証の扱いも販売元・メーカーの規定を確認し、仕事で停止できないPCや復旧できない環境では通常構成を維持する判断が適しています。

よくある質問

まとめ｜対象のAI処理と復旧手段がある人向け

RTX 4090のgpu-unlockは、Linuxの起動初期に適用するTensor演算の非公式な制限解除です。導入前に対象PCI ID・正確なGPUアドレス・通常起動へ戻せるエントリーを確認し、変更後はログだけでなく自分のアプリの出力と処理時間を比べてください。ゲームFPS向上やRTX 5090への置き換えを目的に導入する根拠にはなりません。

あわせて読みたい

GPU

RTX 30・40のgpu-unlock対応GPUと導入判断

GPU

RTX 5090とRTX 4090の性能差・乗り換え判断