魔改卡与解锁工具叠加使用，那些没人提前告诉你的坑

【免费下载链接】gpu-unlock-adaGPU tensor unlock source for RTX 4090 and experimental RTX 4070 Ti SUPER; firmware generated locally项目地址: https://gitcode.com/gh_mirrors/gp/gpu-unlock-ada

把 RTX 4090 焊成 48GB、刷一个改过的 VBIOS、再叠一个 SM 张量速率解锁——这套组合在二手市场和租赁机房里已经不算新鲜。但真正把这些东西叠在一起跑过的人会发现，问题很少出在"解锁有没有生效"这个最显眼的地方，而是出在一堆没人提前说明的边界条件上：日志说加载成功但其实什么都没做、地址格式差一个域号就静默跳过、热重启之后卡已经被判定为"不冷"、把 FP16 累加模式当成 FP32 累加模式来测然后得出"没效果"的结论。

这篇文章基于本仓库 gpu-unlock-ada 的真实代码路径与两份硬件报告，把这类叠加场景里最容易踩的坑按"改了什么 → 顺序怎么排 → 怎么误判 → 哪些卡不该碰"的顺序拆开。

一、先厘清"解锁"改了什么，否则后面全是误判

仓库在 RTX 4090（10de:2684，AD102，128 SM）上测得的数据是：

在 RTX 4070 Ti SUPER（10de:2705，AD103 实验路径，240W 功耗墙）上，同一份 cubin、同一张卡的对照是 FP16/FP32 95.0 → 189.9 TF/s、BF16/FP32 95.0 → 189.7 TF/s、TF32/FP32 47.49 → 94.51 TF/s，而 INT8、dp4a、标量 FP32、无符号 INT4 全部 1.00×；一次匹配的 E4M3 FP8 / FP32 CUTLASS GEMM 甚至只有 0.3% 差异（59.326 → 59.495 TF/s）。

这三组数字指向同一个事实：这套工具改的是寄存器层面"半速率/全速率"的特性覆盖位，收益集中在"输入是 FP16/BF16/TF32、累加器是 FP32"的 Tensor Core 指令发射率上。它不改显存带宽、不改显存容量、不改时钟、不改功耗墙，也不碰 INT8/INT4 路径。

代码里的机制非常明确。解锁模块在 FLR 之前写入两个选择器，并用一次速率回读做闭环校验，见 unlock_610.c：

#define GU_SS0_UNLOCK 0x88888888u #define GU_SS1_UNLOCK 0x8u ... ret = write_selector(work, "SS0", GU_FEAT_SS0_OFFSET, GU_SS0_UNLOCK); if (!ret) ret = write_selector(work, "SS1", GU_FEAT_SS1_OFFSET, GU_SS1_UNLOCK); if (!ret && is_ad102(work)) ret = ad102_readout(work, "selectors-applied", true);

ad102_readout()把0x00823818按 9 个 3 bit 字段解码，require_full为真时只要有任一字段非零就返回-EIO。写出之后仍然读得回来，才算这一环过了。

而 rtx4090-register-report.md 明确记录：OTP fuse 里的FMLA32、IMLA2、IMLA4在解锁后仍然是1——这不是熔断改写，是特性覆盖。README 也写了 "Power-off persistence of the override is not claimed"，即断电后不保证保留，每次开机都要重跑一遍。

这就是第一个大坑的根源：很多人理解的"解锁 = 算力翻倍"，和工具实际做的"FP32 累加路径的发射率翻倍"，中间隔着一整条应用栈。48GB 魔改卡最常见的负载恰恰是 LLM 推理，而单 token 解码是带宽受限的，token/s 大致取决于显存带宽除以模型大小。给这种负载叠一个 Tensor 发射率解锁，token/s 不动是正常结果，不是工具坏了。

二、坑一：魔改卡已经偏离官方固件基线，而工具的第一道门就是读 VBIOS

这是整条链路里最容易被忽略的前提。模块不是"直接往寄存器写一个值"，它在动手之前要先从板载 ROM 里把 FWSEC 固件挖出来、打补丁、再交给 GSP Falcon 执行。这段逻辑在 unlock_610.c 的unlock_transaction_fwsec()里：

/* kgspExtractVbiosFromRom_TU102 reads NV_PROM_DATA, up to 1 MiB. * pci_map_rom stops at the PCI last-image flag and hides the VN extension. */ if (work->bar_len < 0x300000 + 0x1a) return GU_RESULT(-ENODEV); mapped = min_t(size_t, 1024 * 1024, work->bar_len - 0x300000); memcpy_fromio(rom, work->bar + 0x300000, mapped); ret = gpu_unlock_vbios_fwsec(rom, mapped, &fw); if (ret) { dev_err(&work->pdev->dev, "FWSEC-FRTS not found in board ROM (%d)\n", ret); goto out; } if (fw.engine_mask != 0x400) { ... -EOPNOTSUPP ... }

它绕开了pci_map_rom()，直接按BAR0 + 0x300000拷最多 1 MiB 的 ROM 镜像，因为 PCI 的 last-image 标志会截断 VN 扩展区。然后交给 vbios_610.c 里的独立解析器——注释写得很直白："Independent byte parser; no firmware-owned pointer is trusted as a host pointer."

这个解析器对 ROM 结构的要求相当硬：

• 起始必须命中0xAA55/0x4E56/0xBB77三种镜像签名之一；
• 链上每个镜像必须能找到PCIR/NPDS/RGIS数据签名；
• BIT 表要能过字节和校验（sum & 0xff），token 必须是0x70 0x02形式；
• ucode 表头要求 version 为1、header 与 stride 不小于 6；
• FWSEC 描述符的vDesc必须是第 3 版、长度不小于 44，且sig_bytes == sig_count * 384、sig_count == popcount(sig_versions)；
• GSP 引擎掩码必须正好是0x400；
• interface 必须是1/4/8布局，mapper 必须是第 3 版。

再往后还有一道熔断版本门。unlock_transaction_fwsec()会从0x008241c0 + (ucode_id - 1) * 4读熔断位，交给gpu_unlock_fwsec_sig_offset()做位图检查：

if (!(versions & (1u << fuse_version))) return GU_DIAG(-ERANGE);

也就是说，如果这张卡的 ROM 被改过、ucode 表被移动过、签名区被裁剪过，或者熔断版本不在sig_versions的位图里，解锁会在"读固件"这一步就返回-EINVAL/-EOPNOTSUPP/-ERANGE，根本走不到写选择器。

而 48GB 这类魔改卡，动的地方恰恰是 ROM 和显存子系统：改 strap 让显存容量被正确识别、改功耗/风扇表、有的还会为了绕开限制重刷 VBIOS。这些改动中任何一项破坏了解析器假设的结构，结果就是上面那串 errno。这是结构性拒绝，不是兼容性毛病——工具是有意设计成"看不懂就停"的。

即使解析全过，还有一层几何校验。unlock_transaction_layout()会读0x001183a4（可用 FB 大小）、0x00625f04（VGA base）、0x001fa7c8/0x001fa82c/0x001fa830（MMU 锁区间），然后按FB 顶部 - 1MiB反推 WPR 预留，并要求：

in->usable_fb = (u64)mb << 20; if (in->usable_fb < 256ull << 20) { dev_err(&work->pdev->dev, "layout rejected: usable FB below 256 MiB\n"); return GU_RESULT(-ERANGE); } ... if (work->layout.nonwpr_start < in->usable_fb - (256ull << 20)) { dev_err(&work->pdev->dev, "layout rejected: reservations below pre-scrubbed top 256 MiB\n"); return GU_RESULT(-ERANGE); }

全部预留（1 MiB non-WPR + 88 MiB heap + GSP image + boot + 1 MiB FRTS）必须挤在 FB 顶部的 256 MiB 以内，并且 MMU 锁区间的高地址要正好落在 FB 顶部，否则mmu_lock_valid会被判定为无效。换焊显存之后，FB 容量、strap、VGA base、MMU 锁能不能同时落在这个模型里，仓库并没有证据——它只在两块原厂状态的卡上验证过。这不是"魔改卡一定失败"，而是"魔改卡的成功与否取决于一堆你未必知道的 ROM 内部状态，而且失败时工具会直接停下"。

结论很实际：拿到一张魔改卡，先别急着叠解锁。先确认它能正常跑长稳、nvidia-smi -q的显存容量和标称一致、没有 Xid、能完整断电重启。ROM 改过的卡，务必备份原 VBIOS 并确认可以刷回，否则你连"回到基线"这个选项都没有。

三、坑二：冷卡是一次性资源，时序排错就全盘作废

整套机制建立在"这张卡本次上电以来还没被任何驱动碰过"这个前提上。README 用的是很重的措辞："The module needs a card whose firmware state is fresh before NVIDIA loads."

代码把这个前提做成了两道硬门。第一道在 main.c：

pci_dev_lock(pdev); ret = pdev->driver ? -EBUSY : gpu_unlock_610_unlock(pdev, &shared);

只要设备上挂了驱动，直接-EBUSY，日志是gpu_unlock: unlock failed (-16)。

第二道在unlock_transaction_gfw()，看 WPR2 的高位：

if (wpr_hi >> 4) { dev_err(&work->pdev->dev, "card already initialised since power on (WPR2 enabled); power off first\n"); return GU_RESULT(-EBUSY); }

WPR2 从上电到 FWSEC-FRTS 跑起来之前是关闭的。一旦它被拉起来，就说明本次上电已经有驱动用过这张卡了，重启固件序列属于未验证行为，模块选择拒绝。另一个分支是plm_entry == ~0u，返回-EALREADY——权限已开，卡要么已经解锁过，要么根本不冷。

这三条分支在叠加场景里最容易同时踩中：

• 显式modprobe黑名单无效。README 专门点出：nvidia-smi、CUDA、NVML、nvidia-modprobe都会按名字加载 NVIDIA 驱动，普通黑名单拦不住显式命名加载。想让 48GB 卡先跑个nvidia-smi看看显存，就已经把这张卡的冷状态用掉了。
• 热重启不等于新卡。断电重启是必须的第一步。测试过的 2705 在普通热重启后wpr2_hi回到了 0，能再解锁一次；但 README 同时写明"Other boards may retain WPR2"，魔改卡属于没有证据的那一类。别把一次热重启成功当成通用规律。
• 失败后不要force-unload。如果日志说固件没停下来、DMA 缓冲区被保留，正确动作是断电，不是卸载模块。代码里retained这个状态位就是为这条路准备的。

还有一道更隐蔽的门槛：FLR。unlock_transaction_claim()要求这张卡是 PCIe 设备、DEVCAP里有 FLR 能力、且没有被标记PCI_DEV_FLAGS_NO_FLR_RESET：

if ((work->pdev->dev_flags & PCI_DEV_FLAGS_NO_FLR_RESET) || !pci_is_pcie(work->pdev) || diag_pci_dword(work, true, PCI_EXP_DEVCAP, &cap) || !(cap & PCI_EXP_DEVCAP_FLR)) return GU_RESULT(-EOPNOTSUPP);

整个事务的最后一步是pcie_flr()，之后还要逐条比对 BAR 值、检查 pending transaction、确认 WPR2 归零、SEC2 停在 halt。魔改卡常见的两类环境天然不友好：一类是通过转接板、延长线、矿卡支架接出来的，链路本身可能不稳；另一类是服务器/虚拟化平台上 FLR 被固件屏蔽。这类情况下你不是"解锁失败"，而是连第一道 claim 都过不去，日志里会是-EOPNOTSUPP。

顺带一个体验层面的坑：FLR 会复位显示引擎，所以代码在 FLR 之前会先把 firmware framebuffer（simpledrm、efifb）摘掉，屏幕会一路黑到nvidia-drm接管。原厂卡上这是预期行为，改了输出接口或者用非公 PCB 的魔改卡上，这一段黑屏时间足以让人误以为卡挂了。

四、坑三：叠加多个工具时，它们抢的是同一批独占资源

把 NVENC 并发解锁、功耗墙修改、vGPU 解锁、帧生成解锁这些和 SM 解锁叠在一起，冲突点往往不在"功能是否互斥"，而在资源独占和加载时序。

最直接的一条是 BAR0。unlock_transaction_claim()里：

ret = pci_request_region(work->pdev, 0, "gpu_unlock"); if (ret) return GU_RESULT(ret);

BAR0 是独占申请的。仓库自己提供的只读采样器 diagnostics/peek/gpu_peek.c 也要pci_iomap(pdev, 0, 0)，README 因此写死了一条规则："Never load a second BAR0 sampler whilegpu_unlockis performing its firmware transaction." 现实中，魔改卡用户往往同时装了监控模块、自定义风扇控制、或者自己写的寄存器探测工具——这些如果也在 initramfs 早期加载并 map 了 BAR0，解锁会在 claim 阶段拿到一个负数直接退出。

第二条是驱动绑定。前面说过pdev->driver ? -EBUSY，而"驱动级"的解锁/调优工具（改功耗表读取、改 NVENC 会话数、注入驱动参数）通常需要在 NVIDIA 驱动之后生效。顺序只能是：gpu_unlock（initramfs，先于 nvidia）→ FLR → nvidia 加载 → 其它驱动级工具。反过来做，冷状态就没了。

第三条是驱动版本被钉死。仓库只在两个具体组合上测过：4090 配615.78.08，2705 配580.178.04，而生成的固件资产来自 NVIDIA610.43.03。如果你为了另一个解锁把驱动钉在别的版本上，这个组合在本仓库里没有任何证据支持。工程上正确的做法是变量隔离：先用一个干净的 stock 驱动版本确认解锁本身能过，再引入第二个改动；两者一起上，出问题时你无法区分是固件事务失败、驱动握手失败、还是另一个 patch 改了不该改的东西。

第四条在多卡机器上格外危险：main.c用async_schedule_domain()对每张卡并发 unlock，共享一份 GSP 固件。targets=all会选中所有被接受的卡，包括 legacy 的 GA102/GA104 目标。一台混插了 4090、3090、3060 的矿机，写targets=all等于对所有卡同时做固件事务，而报告的验证范围只有一张 4090 和一张 2705。多卡场景请一律用lspci -D出来的精确地址，一张一张来。

五、坑四：gpu_unlock加载成功，什么都证明不了

这是我在读代码时觉得最值得单独讲的一条，因为它是纯粹的"日志陷阱"。

看main.c的初始化路径：

if (!shared.gsp) { ret = gpu_unlock_610_load_shared(pdev, &shared); if (ret) { pci_err(pdev, "gpu_unlock: firmware load failed (%d)\n", ret); pci_dev_put(pdev); return 0; /* ← 注意这里 */ } }

固件加载失败，模块初始化返回 0。内核眼里模块加载成功，lsmod里能看到gpu_unlock，modprobe返回码是 0，然后什么都不会发生。

单卡解锁失败也一样：unlock_one()里只打一行pci_err(pdev, "gpu_unlock: unlock failed (%d)\n", ret)，gpu_unlock_init()仍然返回 0。这是有意为之——一张卡失败不该阻止其它卡或整个启动流程——但它把"加载成功"和"解锁成功"彻底解耦了。

第二个陷阱是地址格式。listed()用strcasecmp把targets=里的每一项和pci_name(pdev)整体比较：

if (strlen(name) == end - entry && !strncasecmp(name, entry, end - entry)) return true;

pci_name()给出的是带域号的完整名（0000:01:00.0）。如果你从lspci不带-D的输出里抄了01:00.0，长度不等，永远不匹配。而report_unmatched()只会打一行：

pr_err("gpu_unlock: no supported card at \"%.*s\"\n", (int)(end - entry), entry);

然后继续往下跑、安静地什么都不做。这类"少一个域号导致整晚白干"的事故，在叠加场景里出现频率高得离谱。

第三个陷阱是实验路径的额外条件。2705 必须同时满足gpu_unlock.ad103_experimental=1和单个精确地址，targets=all永远选不中它：

if (pdev->device == GU_AD103_RTX_4070_TI_SUPER && (all || strcasecmp(targets, pci_name(pdev)))) { pci_err(pdev, "gpu_unlock: experimental AD103 requires a single exact PCI target\n"); continue; }

那么什么才算真的成功？三个条件缺一不可：

1. 内核日志里出现这张卡的gpu_unlock: unlocked（main.c只在gpu_unlock_610_unlock()返回 0 时打印）；
2. AD102 ... readout1=0x0 fields=0 0 0 0 0 0 0 0 0 valid=1 full=1这种速率回读全零；
3. 一个匹配基线的速率对比，或者独立工具（如 NVIDIA RM getter）读到FMLA32/IMLA2/IMLA4从 1 变 0。

失败时怎么看日志？unlock_transaction_result()会把最后一笔 MMIO 和最后一次 PCI 采样一起打出来：

dev_err(&work->pdev->dev, "failure unlock_610.c:%u %s error=%d last_mmio=%#x value=%#x valid=%u " "mapped=%u master=%u firmware_started=%u quiesced=%u pages=%u/%u\n", ...); dev_err(&work->pdev->dev, "last PCI sample: capability=%u offset=%#x value=%#x result=%d\n", ...);

firmware_started=1且quiesced=0，说明固件事务已经启动但没收干净——这时断电，别再试。pages=0/x说明 DMA 都没分配出去，问题在更前面的 claim。error=-16是驱动已绑定，-95（EOPNOTSUPP）优先怀疑 FLR 能力或 ROM 结构，-34（ERANGE）优先怀疑 layout 或熔断版本。

六、坑五：把显存问题当算力不足，两个工具都帮不了你

这是标题里最像"玄学"、实际上最工程化的一条。

仓库里有两个不同的诊断工具，它们的盲区恰好互补，而很多人只用了其中一个就下结论：

mma_bench的报告里写得很清楚："The accumulator results are only kept live to inhibit compiler elimination; the program does not compare numerical results to a reference." 所以它给出的 331.6 TF/s 只证明"指令发得出去"，不证明"算得对"。一张显存有隐患的 48GB 魔改卡，完全可能在mma_bench里跑出漂亮数字，然后在下游应用里输出错误结果，或者过一会儿掉卡。

正确的排障顺序因此不是"先怀疑解锁"，而是：

1. 确认解锁结论：gpu_unlock: unlocked+readout1九个字段全零。这一层过了，SM 侧的 override 就跟你的问题无关了。
2. 确认指令模式匹配：你的 kernel 到底用的是HMMA.16816.F16还是HMMA.16816.F32？前者在 4090 上解锁前就有 325.7 TF/s，解锁后 331.6 TF/s，只有 1.02×。如果你拿一个 FP16 累加的 kernel 去测，得出的"解锁无效"是真实的、正常的、可预期的。
3. 确认是不是带宽受限：48GB 只增加了容量，带宽一点没变。LLM 单 token 解码、低 batch 的 attention、大量小张量搬运，这些场景的瓶颈从头到尾不在 Tensor Core。
4. 确认功耗与时钟策略：2705 的整组对比是在 240W 功耗墙下做的，4090 是 450W。叠加了改过功耗表的 VBIOS 之后，同一个 unlock 结果在不同墙下的表现不可直接比较。
5. 最后才怀疑显存：Xid、掉卡、计算结果不一致、nvidia-smi的 remap/ECC 计数——这些才是显存侧信号。报告里对每次确认后的检查都写的是"scan found no NVRM Xid, GPU-fallen-off, or GSP/SEC2 timeout"，反过来说，出现了这些就说明问题在这一层，不在解锁。

诊断工具本身也内置了防呆。tensor_modes_driver_runner.py要求同时给出--sha256、--expect-uuid、--expect-power-limit：

python3 diagnostics/bench/tensor_modes_driver_runner.py \ tensor_modes_issue_sm89.cubin \ --sha256 PASTE-THE-CUBIN-SHA256 \ --expect-uuid GPU-PASTE-YOUR-EXACT-UUID \ --expect-power-limit 240

三样对不上就不跑。这条设计针对的正是"拿 A 卡的基线去比 B 卡的解锁结果"这种最常见的错误对比——在混插魔改卡的机器上，这几乎是必然会发生的事。

七、什么样的卡不建议碰解锁

把上面几条收敛成一份判断清单：

• 设备 ID 不在白名单里。supported_ids[]只列了0x2684与一批 GA10x ID，0x2705走额外开关。其它 Ada ID 在supported()里直接返回 false，连report_unmatched()的"找不到卡"都不会专门提示你——它只会说这个地址没有受支持的卡。给 4080、4070、4090D 之类刷这套工具，得到的不是失败日志，而是沉默。
• 平台不提供 FLR。转接板、延长线、部分虚拟化/服务器固件屏蔽了 FLR，-EOPNOTSUPP在 claim 阶段就返回。这类环境没有任何绕过手段，因为 FLR 是这套事务的收尾步骤，不是可选项。
• 无法真正切断 AC 电源。笔记本、云主机、PCIe 热插拔背板、共用电源的整机柜，都做不到"断电等 30 秒再上电"。而没有新鲜的上电状态，模块会以-EBUSY/-EALREADY拒绝，你只能反复重启碰运气。
• 显存被重焊、但没有做过长时间稳定性验证的卡。解锁事务本身要在 FB 顶部建立 WPR 预留、在 SEC2 上跑签名 booter、做一次 FLR。任何一步出错，你都无法区分是工具的问题还是显存的问题。先在 stock 状态跑满负载、跑长时间、记录 Xid，是最低成本的隔离手段。
• VBIOS 被改过且没有备份的卡。工具的第一道门就是解析 ROM 里的 FWSEC 描述符、ucode 表和熔断版本位图。改过的 ROM 可能直接-EINVAL，更麻烦的是"结构对了但语义变了"这种没法靠返回值发现的情况。没有备份就没有回滚路径。
• 生产/出租中的机器。事务会做 FLR，会摘掉 framebuffer，会中断卡上的一切负载。仓库在 2705 的测试里是专门暂停又恢复了 owner miner 的——这不是一个可以"顺手跑一下"的操作。
• 多卡混插且想用targets=all的机器。all会选中所有被接受的卡并发执行，而验证范围只有两张具体型号的卡，其中一张还是单卡单次冷启。

最后必须说清楚这套东西的证据强度，因为社区里流传的"2× 算力"往往被讲成了确定结论。RTX 4090 的结果是一张卡、一次成功的冷启动，基线是在那次成功上电之前采集的，独立冷启动复现和代表性数值负载验证在报告里都标为 pending。2705 是一张卡、两次冷启动、两次普通热重启，最后一次从持久化 EFI 默认项启动，但那两次热重启没有重复跑吞吐测试。targets=all至今没有作为任何 Ada 卡的验证路径。

这些限制不是自我否定，而是使用说明书的一部分：当你把一张魔改卡和这套工具叠在一起时，你已经同时离开了"原厂固件基线"和"已验证硬件清单"两个安全区。剩下的判断只能靠你自己手里的日志、回读和对照实验——而这三样东西，恰好是上面所有"坑"最终都指向的同一个答案。

【免费下载链接】gpu-unlock-adaGPU tensor unlock source for RTX 4090 and experimental RTX 4070 Ti SUPER; firmware generated locally项目地址: https://gitcode.com/gh_mirrors/gp/gpu-unlock-ada