- 何が起きた: 非公式ツール「nv-uefi-unlocker」によって、Windows上でGeForceの行列演算や画像生成が高速化したとの実機報告が相次いでいる。
- なぜ重要か: Tensor演算の制限解除が実際のアプリケーションの処理時間短縮につながることが確認された一方、UEFIで解除に成功しても、Windows起動後に効果が失われる構成も報告されている。
- 次に見るべき点: GPUごとのWindows環境での再現性に加え、起動時のセキュリティ保護や電力制限を考慮した実アプリの性能、計算結果の正確性、長期的な安定性が焦点となる。
NVIDIA製GeForceのTensor演算制限をWindows起動前に解除する非公式ツール「nv-uefi-unlocker」について、Windows環境で行列演算や画像生成を高速化できたとの実機報告が相次いでいる。2026年10月28日に投稿されたGeForce RTX 4060 Tiの検証結果では、特定の条件下で画像生成にかかる時間が1枚当たり12.1秒から8.0秒に短縮された。従来は主にLinux環境で行われていた制限解除を、UEFIから実行してWindowsへ引き継ぐ仕組みだ。ただし、UEFIで解除に成功しても、Windows起動後に元の状態へ戻ってしまう外付けGPUの事例も報告されている。実用性を判断するには、UEFIでの解除成功、Windows起動後の状態維持、実際のアプリケーションでの性能向上をそれぞれ確認する必要がある。
Windows起動前にGeForceの何を書き換えるのか
nv-uefi-unlockerが解除を狙うのは、低精度の数値を入力として使い、演算結果をFP32精度で累積加算するTensor演算の命令発行速度に関する制限だ。GPU全体のFP32演算性能を引き上げるものではなく、VRAMの容量やメモリ帯域が増えるわけでもない。対象となる入力形式にはFP16とBF16が含まれるが、Turing世代のGPUはBF16に対応していない。そのため、対応するGPUであっても、世代によって利用できる演算形式は異なる。
従来の手法では、Linuxの初期RAMディスク（initramfs）からGPUの初期化前に介入していた。これに対し、開発者が公開したAda世代GPUでの検証報告によると、nv-uefi-unlockerはOSの起動前にあたるUEFIのDXE段階でGPUファームウェアを起動し、必要な改変処理を実行する。その後、Windows Boot Managerへ制御を引き渡すことで、解除した状態のままWindowsを起動させる仕組みだ。Windowsのレジストリを変更したり、GPUのVBIOSを書き換えたりする方式とは異なる。
改変処理では、署名データをコピーする際の境界検査の不備を利用している。具体的には、スタックオーバーフローと、既存のコード断片を組み合わせて処理を実行するROP（Return-Oriented Programming）を使い、GPUの保護設定を変更してホスト側からの書き込みを可能にするという。起動処理には署名済みのBooterやGSP-RMを使用しているが、これはNVIDIAが改変を承認していることを意味しない。
開発者が10月26日に公開した実機検証では、RTX 4060 Laptop GPUを搭載したASUS ROG Strix G16 G614JVが使用された。GPUは20基のSMと8GiBのVRAMを備え、ディスプレイを独立GPUへ直接接続する設定だった。Windows上で4096×4096のFP16行列積を実行し、データがL2キャッシュに収まる条件で性能を測定したところ、29.89 TFLOPSから49.02〜49.33 TFLOPSへ向上した。約1.65倍の性能改善だが、あくまでこのGPUと測定条件で得られた結果である。
RTX 20〜40シリーズへの対応とWindowsでの動作確認は別問題
開発者はGitHubの公式READMEで、RTX 20・30・40シリーズへの対応を掲げている。ただし、対応状況は、実機で動作が確認されたGPU、同系列の上流実装で検証されたGPU、処理経路は実装されているものの実機確認が済んでいないGPUに分けられている。対象となるデバイスIDを処理できる設計であっても、そのシリーズに属するすべての製品でWindows上の動作が保証されるわけではない。
世代ごとに必要な準備も異なる。RTX 20シリーズでは、事前にGSPファームウェアモードを設定する必要がある一方、RTX 30シリーズではその設定は不要とされている。また、Blackwell世代のGPUは対応対象に含まれていない。GPUが対応シリーズに属していることと、実際のPC構成で制限解除の効果を維持できることは、区別して考える必要がある。
10月28〜29日には、RTX 4070 Ti SUPER、RTX 4080、RTX 4060 Tiの利用者から、Windowsでの性能測定結果が相次いで投稿された。ただし、これらの報告では測定対象が異なる。Tensor命令の発行速度を測るマイクロベンチマーク、まとまった行列演算の処理速度、画像生成にかかる時間では、それぞれ制限解除の効果の現れ方が違う。報告された倍率をそのまま比較することはできない。
Tensor命令の発行速度は約2倍、行列演算でも大幅な改善
RTX 4070 Ti SUPERでは、Tensor命令の発行速度を測るマイクロベンチマークで、61.98 TFLOPSから125.29 TFLOPSへの性能向上が報告された。利用者s654632396が10月28日に投稿した検証結果によるもので、同じ条件と同じバイナリを使用した比較では約2.02倍となった。検証にはAD103を搭載する16GiBモデルを使用し、AMD製CPUを搭載したデスクトップPCで、NVIDIAドライバー621.01、ツールv2.1.0、Secure Boot無効という条件で測定している。ただし、このテストは特定のTensor命令をどれだけ高速に発行できるかを測るもので、アプリケーション全体の処理速度が2倍になったことを意味しない。
一方、MingShi350が10月29日に投稿したRTX 4080 16GBの検証結果では、PyTorchを使用して行列演算の性能を解除前後で比較している。検証環境は、改造していないRTX 4080にRyzen 9 9950X3Dと64GBのDDR5-6000メモリを組み合わせたPCだ。OSはWindows 11 24H2、GPUドライバーは621.01で、PyTorch 2.11.0+cu128とCUDA 12.8を使用した。
測定ではFP16とBF16のいずれも、低精度でのリダクションを無効にする設定（reduced_precision_reduction=False）を適用し、FP32で累積加算する条件を使用した。各行列サイズについて3回の測定を実施し、それぞれ30回の反復処理から最良値を採用している。以下は投稿された2組の解除前後の比較のうち、最初の組の結果であり、2組を平均した値ではない。
| RTX 4080での測定条件 | 解除前（TFLOPS） | 解除後（TFLOPS） |
|---|---|---|
| FP16入力・FP32累積、4096³ | 100.53 | 185.50 |
| FP16入力・FP32累積、8192³ | 104.49 | 164.31 |
| BF16入力・FP32累積、4096³ | 100.37 | 192.18 |
| BF16入力・FP32累積、8192³ | 104.39 | 172.31 |
| strict FP32（対照） | 34.47 | 34.42 |
FP16とBF16を入力とする行列演算では大幅な性能向上が見られたものの、4096³と8192³では改善率に差が生じている。一方、対照として測定したstrict FP32の性能はほぼ変化しておらず、GPU全体の演算性能が一様に向上したわけではないことが分かる。投稿者は8192³で改善率が低くなる理由として、340Wの電力上限に達する可能性を挙げている。ただし、電力制限が原因だと独立に検証されたわけではない。
RTX 4060 Tiでは画像生成が約1.51倍に高速化、待ち時間は約34%減少
行列演算だけでなく、実際のAIアプリケーションでも処理時間の短縮が報告されている。利用者fj80405が10月28日に公開したRTX 4060 Ti 16GBの検証結果では、GPUの電力上限を165Wに維持したまま、画像生成の高速化に成功した。使用したのはMSI製RTX 4060 Ti 16GBとRyzen 5 5600X、MSI MAG B550M MORTAR WIFIを組み合わせたPCで、Windows 11 Proのビルド26200、ドライバー610.88、独自ビルドしたnv-uefi-unlocker v2.1.4を使用している。
ComfyUIで画像生成モデル「Z-Image-Turbo」を実行し、1024×1024ピクセル、8ステップの画像を生成したところ、1枚当たりの処理時間は12.1秒から8.0秒へ短縮された。GPUやドライバー、電力上限は変更せず、モデルと乱数シード（seed）もそろえて比較している。これらの数値から計算すると、処理速度は約1.51倍、待ち時間は約34%の削減に相当する。
速度倍率は12.1÷8.0＝1.5125、待ち時間の削減率は（12.1−8.0）÷12.1×100＝約33.9%となる。速度の向上率と処理時間の削減率は基準が異なるため、約1.51倍の高速化を「待ち時間が51%減った」と表現するのは正しくない。ただし、この画像生成テストでは測定を繰り返した際の結果の分布や、複数のGPU個体で再現できるかどうかは示されていない。
同じ投稿では、8192³のFP16入力・FP32累積加算についても性能が測定されている。約4秒間の連続負荷を3回実行した結果、中央値は45.72 TFLOPSから67.30 TFLOPSへ向上した。投稿者は、短時間のベンチマークより数秒間の連続負荷で性能が低くなる理由として、165Wの電力上限と2190MHzまで低下するクロックを挙げている。この結果からも、短時間のTensor命令発行速度だけで、長時間の演算処理や実際の画像生成で得られる高速化の倍率は予測できない。
計算結果の正確性についても、一定の確認が行われている。RTX 4060 Tiの投稿者は、同じseedを使用して生成した画像が、制限解除の前後で画素単位まで一致したと報告した。また、開発者によるRTX 4060 Laptop GPUの検証でも、データの完全性を調べる自己検査で異常は見つかっていない。ただし、これらは特定の検証条件で得られた結果であり、あらゆるAIモデルで計算結果が正しくなることや、長期間の安定動作を保証するものではない。性能値や検査結果はいずれも開発者または利用者による報告であり、独立した第三者による再現検証が完了したものではない。
UEFIで解除に成功してもWindowsで効果が失われるケース
すべての環境で制限解除が成功するわけではない。GWASDW123が10月29日に投稿した報告では、Thunderbolt 3で接続したRTX 3070について、UEFIでの解除には成功したものの、Windows起動後には効果が失われていた。検証にはASUS製RTX 3070をThunderbolt 3対応の外付けGPUドックに搭載し、Core Ultra 5 125Hを備えたLenovo 83D4へ接続した構成を使用した。ディスプレイ出力には内蔵のIntel Arcを使用し、Windows 11とNVIDIAドライバー621.01で動作を確認している。
ローカルのv0.2.0分岐を使用した試験では、UEFI内で制限解除に成功し、FLR（Function Level Reset）と呼ばれるPCIeデバイスの機能単位のリセット後も、解除状態が維持されていたという。ところがWindows側で確認すると、解除状態を示す診断結果はNOT_UNLOCKEDとなり、演算性能の向上も確認できなかった。同じGitHub Issueにはv2.1.5を使用した別の失敗ログも掲載されているが、こちらはUEFIでの処理自体が失敗しており、v0.2.0の事例とは経過が異なる。
報告者は、解除状態が失われた正確なタイミングを特定できていないと明記している。GPUの完全なリセットやUSB4関連の処理、NVIDIAドライバーによる初期化などが原因として考えられるものの、いずれも確定していない。Thunderboltトンネルの再構築で状態が失われたという説明も、現時点では仮説にとどまる。この事例だけで外付けGPU全般に対応できないと判断することはできないが、UEFI側で成功と表示されたことだけでは、Windowsでも解除状態が維持されるとは限らないことが分かる。
そのため、実際の動作確認は三つの段階に分ける必要がある。まずUEFIで保護設定を変更し、書き込んだ値を正しく読み戻せるかを確認する。次にWindows起動後も解除状態が維持されているかを調べ、最後に目的のアプリケーションで性能が向上するかを測定する。RTX 3070の事例は、この三つを区別せずに「解除成功」と判断することの問題を浮き彫りにしている。
Secure Bootの無効化や電力制限解除にはリスクも
nv-uefi-unlockerを通常の手順で使用するには、UEFIのSecure Bootを無効にする必要がある。開発者は自己署名証明書をUEFIの署名データベースに登録する方法も説明しているが、いずれも起動時の信頼設定に関わる変更だ。Microsoftの技術文書によると、Secure Bootは起動時に読み込まれるブートローダーなどの署名を検証し、信頼できるコードのみを実行するための仕組みである。これを無効にすれば、OS起動前の不正なコード実行を防ぐ保護の一部が失われる。
また、nv-uefi-unlockerによる変更は永続的なものではなく、電源を完全に切ると解除状態が失われるため、冷起動のたびに再適用する必要がある。Windows側で保護設定が再び書き込み禁止になっている場合は、その場で解除処理をやり直すこともできない。開発者は、処理がSTOP状態で停止した場合、同じセッションで再実行せず、完全に電源を切って通常のWindows起動へ戻すよう求めている。VBIOSへの永続的な書き込みを行わない設計であっても、すべての不具合やハードウェアの損傷から復旧できることを保証するものではない。
さらに、ほかの制限解除ツールと併用する場合は、消費電力や発熱にも注意が必要だ。開発者のAda世代GPUでの検証報告には、別ツール「nvoc」による電力制限解除を組み合わせ、GPUチップの消費電力が約163.7W、Hot Spot温度が104.4°Cに達した事例がある。ただし、これはTensor演算の制限解除と電力制限解除を併用した結果であり、nv-uefi-unlocker単体での温度や消費電力を表すものではない。電力上限を165Wに維持したRTX 4060 Tiの検証とも条件が異なるため、両者を同じものとして扱うべきではない。
今回の報告によって、GeForceのTensor演算制限を解除することで、Windows上の行列演算だけでなく、実際の画像生成アプリケーションでも処理時間を短縮できる可能性が示された。ただし、その効果はGPUの世代や接続構成、電力制限、実行する処理によって異なり、UEFIでの解除成功がWindowsでの性能向上を保証するわけではない。今後は、起動時のセキュリティ保護への影響を踏まえたうえで、実アプリの処理時間、計算結果の正確性、長期的な安定性を検証することが重要になる。
