gpu-unlock：把 30 系显卡被限速的 BF16 吞吐找回来（一个 Linux 内核模块，+80% 实测背后有几个坑）

一句话看懂：NVIDIA 把 30 系消费卡的 FP/BF16 发射速率锁在了专业卡的一半，理由是产品线切割。这个 Linux 内核模块在驱动接管显卡之前把锁顶开，3090 Ti 实测 BF16 稠密 GEMM 从 87.50 涨到 157.41 TFLOPS。代价是一整套早期启动流程、必须冷启动，以及一批发行版打包的坑。

项目地址：https://github.com/Zagitta/gpu-unlock

先说结论：这玩意儿改的不是驱动，是启动顺序

看到「gpu-unlock」这个名字，我的第一反应是又一个 vBIOS 刷写工具，和过去几年那些魔改显存颗粒、魔改供电限制的脚本没什么本质区别。读完 README 和仓库里那份 docs/How Ampere was unlocked.md 之后，我改主意了——它做的事情比刷 BIOS 要精细得多，而且思路值得单独聊一聊。

先摆事实。NVIDIA 在 GA102/GA103/GA104/GA106 这四颗芯上，把 FP/BF16 指令发射速率限制在了专业卡的一半。专业卡（A100、RTX A 系列）跑同样的活儿是全速。差出来的那一半，是纯粹的厂商产品线切割：不让两万元的专业卡显得像个笑话。

这个项目做的事情，就是把这道闸门顶开。做法是 Linux 内核模块，在 NVIDIA 驱动绑定显卡之前完成一整套流程，写完速率选择寄存器后触发一次 FLR 复位，等驱动接管时，卡已经处于放开限制的状态。3090 Ti 实测 BF16 稠密 GEMM 从 87.50 涨到 157.41 TFLOPS，接近翻倍。

值得留意的是它的形态选择：不是 UEFI 程序，也不是改过的 NVIDIA 驱动。这个选择解决了一个很实际的痛点——UEFI 方案每次 NVIDIA 发新驱动都得重新打一遍补丁，UEFI 固件本身也是各家主板千奇百怪，兼容性是场灾难。换成内核模块塞进 initramfs，跟着内核版本走，驱动升级不再影响你。仓库里那句「it does not require manual patching each time nvidia releases a new driver version」写得挺实在。

不到两周，star 快到两千，fork 也过两百，issue 区里排着二十几条。这个项目的热度不是凭空来的。

它是怎么做到的：漏洞找得漂亮，但别把它当教程看

仓库里那份技术文档写得相当认真，我把它翻译成人话讲一遍，因为这里的思路比结果本身更有意思。

Ampere 的启动流程大致是：PCI 枚举 → 加载 VBIOS/固件 → DEVINIT 初始化硬件和显存 → GSP 上的 FWSEC 在 heavy-secure 模式建立受保护的显存区（WPR2）→ SEC2 安全处理器用硬件 DMA 加载一个签名的 Booter 固件 → Booter 解密验签，把 GSP-RM 拉起来。看起来是一条挺严密的信任链。

问题出在 Booter 上。它有个栈溢出，攻击者可以用返回导向编程（ROP）控制返回地址。ROP 这套东西在 PC 上早就是常识，但搬到 GPU 的 Falcon 协处理器上做，是个挺有意思的活儿。

那怎么才能看到一个加密固件的内部结构？文档里这段我读了两遍。NVIDIA 那阵子同时发布 debug 和 production 两个版本的 Booter，本身不是问题——都是加密的。但 debug 版用的是公开的测试密钥方案（key index 37）加密的。有人用这个已知密钥把固件解开，反汇编，挖出一堆 gadget，才摸清了 debug 与 production 版本的相似程度，最终把 ROP 链拼出来，在 heavy-secure 上下文里拿到了代码执行能力。

拿到执行权之后，反倒没什么戏剧性了。速率选择寄存器 SS0/SS1 主机侧写不了，因为被 PLM（权限层级掩码）管着。默认只有 L3 层级能写，而 L3 正好对应 heavy-secure 上下文。于是先写一次 FEAT_OVR_PLM = 0xFFFFFFFF 把写权限放开，再由驱动写 SS0 = 0x88888888（全 BF16 速率）和 SS1 = 0x8（IMLA4），完事。

文档最后那句「As Borat would say. Great success.」我笑了半天。整个过程里最反直觉、也最值得记下来的一句，其实是那句「NVIDIA fucked up more than once」——真正的问题不是加密算法被破了，而是加密流程管得太松：同一个密钥管着两种用途不同的固件发布，一旦有一侧管不住，整条链子就塌了。这事儿的教训放在任何密钥管理体系里都成立。

不过要提醒一句：别把这份文档当教程看。里面的 V67 常量是从 WildFlash1st/cmp90hx-unlock 拿来的，而 firmware/NOTICE.md 写得很清楚，NVIDIA 驱动许可的 1.1(d) 条只覆盖「二进制文件不变」的分发场景，官方措辞是「Personal local packaging is the initial delivery target」，并且明确说了再分发授权「is not claimed」。仓库自己也把这点写在了显眼位置，这点态度我挺欣赏——技术上该说的说清楚了，法律上不该越的线也没含糊。

数字要打折看，实际能省多少时间

这是我想多说两句的地方，因为宣传口径和实际体感之间有落差。

先看收益分布。仓库收集的用户实测里，BF16 GEMM 提升在 +25% 到 +80% 之间浮动，中位数大致 +60% 到 +70%。但真正落地到场景上就不一样了：

• 受益明显：矩阵密集型任务。LLM 的 prefill 阶段 +14% 到 +36%，扩散模型，FlashAttention。
• 基本没变化：LLM 的 decode 阶段（受显存带宽限制，不是算力瓶颈），INT8 相关工作。

这就引出一个很实际的判断题。跑对话机器人、跑推理服务、跑批量 API 的朋友，提速带来的体感提升远小于那 80%——因为你大部分时间花在 decode 上，那部分一点没变。做训练、做长上下文预填充、跑图像生成的，才是真的吃到红利。

还有一个容易被忽略的变量：功耗墙。仓库里最低的 +25% 来自一张限在 225W 的卡。也就是说，你这台机器散热和供电撑得住，才能吃到接近 +80%；如果电源配得紧，收益会被砍掉一大半。这跟很多硬件评测的老问题一样——跑分是给一块没有约束的卡跑的。

另外几张卡的情况差异挺大，README 那张表值得逐行看：

• GA102（3090 Ti、3090、3080 系列）：主要收益来源，报告区间 +25% 到 +80%，差距主要来自功耗设置。
• GA104（3070、3070 Ti）：+73% 到 +81%，3070 Ti 用这个模块没测过，但同样的同样的开关在 Windows 上走 UEFI 移植是通的。
• GA106（3060 12G）：约 +80%，但 issue #21 里 3060 LHR 在 stock 模块上会报 -110 超时，需要放宽两处检查才能走通 FWSEC，后面 SEC2 又会失联——这条路还在磕。
• GA102-250（3080 Ti 20GB OEM 魔改卡，issue #28）：最尴尬的一种情况。提速流程跑完了，运行态也确认 SS0 稳稳停在 0x88888888，可 BF16 就是纹丝不动，实测 BF16/FP16 比值 1.004。作者怀疑这个 SKU 的半速分频是烧在硅片里的，寄存器改不动。我倒觉得这个案例最有意思——它说明「寄存器写成功」和「性能真的变了」是两件事，中间还隔着一层硬件的脾气。

作者那句提醒也得记住：各家的实测数字来自各自不同的 benchmark，不能直接横向比。选卡之前还是得自己跑一遍。

门槛比 README 标题给人的感觉要高

如果你打算动手，有几件事 README 里藏着，issue 区里翻出来的，官方 README 没写清楚或写得太轻描淡写：

必须是冷启动。热重启的场景下模块会失败。issue #23 里描述得挺具体：失败之后 GPU 直接没法被 nvidia 驱动接管，rmmod 也说 in use，得整机断电才恢复。官方在 README 里的说法稍微温和一点，但也承认失败后卡会留在原状。

不是所有发行版的包装都是好的。issue #54 是个典型例子：Ubuntu 25.10 之后改用 dracut 构建 initramfs，而 deb 包只带了 initramfs-tools 的 drop-in，dracut 直接无视。结果是 DKMS 编好了、模块装上了、initramfs 也重建了，唯独 gpu_unlock.ko 不在里面——全程零报错，静默失效。装完记得自己 lsinitramfs 查一遍。

内核被 taint 了。模块是 out-of-tree 的，没签名，日志里那句 module verification failed: signature and/or required key missing - tainting kernel 是必然出现的。对日常使用没影响，但有些工具会检测到 taint 就报警或拒绝加载。

固件版本是钉死的。构建时会下载 NVIDIA 610.43.03 的开源内核模块源码包和 CachyOS 的 nvidia-utils 包，逐个校验 SHA-256，然后从中提取 GSP 与 booter 镜像生成 payload。以后 NVIDIA 换驱动版本，这个提取流程大概率得跟着改——它是跟着固件走的一次性提取，不是一劳永逸的东西。

休眠会把它打回原形。suspend to RAM 会给显卡断电，速度选择器随之复位。模块的 suspend notifier 会在 nvidia 之前把提速流程重跑一遍，大概多花一秒，可以关。不覆盖休眠到磁盘（hibernate）。

Windows 没有。issue #36 和 #46 都被关掉了，只有 Linux 这条路。想在 Windows 上折腾，只能自己找 UEFI 移植的版本。

还有件小事，但我觉得挺重要：这东西只对自己的卡有效，纯粹是单机行为，不涉及任何绕过 NVIDIA 账号或授权机制的成分。用户报告里明确提到，跑 vfio-pci 直通给虚拟机、带核显的主机、接雷电的 eGPU 都有人验证过可用。这些都是合规的自用场景，别拿它去干别的事。

我的看法

我觉得这个项目有意思的地方不在性能数字，在于它揭示了一个趋势：硬件厂商在消费卡上做产品线切割的手法越来越「软件化」了。

过去 NVIDIA 卡上的那些限制——显存位宽、FP64 单元数量、PCIE 带宽——多少是硬件层面的，想改就得动电路板。改到 Ampere 这一代，核心频率、SM 数量、FP16 单元这些真正决定性能的东西都开放了，反而是「指令发射速率」这种可以靠一个寄存器开关控制的东西被锁死了。这个限制从出厂固件里的一个 4 bit 字段，变成了一个纯软件问题。既然是软件问题，就有人会去逆向；有人逆向出来，就有了今天的项目。

顺带说，仓库的演进路径也很有意思。这套思路源自 CMP 170Hx 那个 8G/10G 变 64G/40G 的项目（cmpunlocker，被 LTT 报道过），同一个 ROP 链、同一套 PLM 技巧，这回用在了完全不同的目标上——从「把矿卡改装成 AI 卡」变成「把 AI 卡改成 AI 卡的完全体」。同一批人、同一套方法论，一年内做了两件性质完全不同的事。这在我看來是比性能数字更有意思的行业信号。

当然，我要泼点冷水。

第一，这东西的适用窗口在收窄。仓库的 issue 里有加 Turing 支持的请求（#30）、有加 AD103/4080 支持的请求（#24、#41，#41 已关闭）。随着新架构上市，给旧架构打补丁会变成一种固定形态的维护工作，而新卡的限制只会藏得更深。NVIDIA 也完全有能力在后续固件里堵掉这个漏洞——事实上，一次 NVIDIA 固件更新可能就得重新逆向一次。

第二，那个「debug 固件用公开测试密钥加密」的历史漏洞，是一次性的运气。不会每个新架构都再送一次这样的机会。技术路线越走越窄。

第三，也是最实际的：+80% 的 BF16 吞吐，对你到底意味着什么，取决于你的负载是不是矩阵密集、你的机器是不是真能给到那个功耗、你的模型是不是瓶颈在算力而不是显存带宽。很多人折腾完发现体感提升只有个位数百分比，然后得出「这玩意儿没用」的结论——那多半是负载选错了，而不是项目不行。

所以我的建议很明确：先算清楚自己的瓶颈在哪儿。如果是本地跑一个 7B 模型的对话，重心应该放在量化、批处理和 KV cache 上，提速帮不了多少。如果是做训练、做长上下文预填充、或者跑扩散模型，那这 60% 到 80% 是实打实的，值得折腾。

折腾之前记得三件事：冷启动，装完用 lsinitramfs 确认模块真的进 initramfs 了，以及失败了就断电，别硬来。

下载

仓库主页：github.com/Zagitta/gpu-unlock（内核模块与打包 GPL-2.0-only，固件 payload 沿用 NVIDIA 各自条款）
技术文档：How Ampere was unlocked（讲清了整条漏洞链与寄存器细节）
相关项目：cmpunlocker（同源思路，把 CMP 170Hx 的显存改大）