CMP 90HX 解锁思路:从 170HX 方法论迁移
2026-07-22
加密与解密
00

目录

和 170HX 比一眼
FMA / 指令节流在 90HX 上指什么
L1:指令替换(现成)
L2:固件 ROP(推测)
L3:驱动与 VBIOS
各路径预期
从 170HX 工具能搬什么
路线
小结

CMP 90HX 是 GA102(和 3090 / 3080 Ti 同硅),和 170HX 的 GA100 不是一块 die。限制都偏固件寄存器,但指令集、显存、Falcon 描述符都不一样。下面按 170HX 那套 L1 / L2 / L3 往 90HX 上推,没实测的地方当推测看

和 170HX 比一眼

维度170HX90HX
dieGA100,sm_80GA102,sm_86
同硅A1003090 / 3080 Ti
显存HBM2e,容量常被锁GDDR6X 10GB(没有容量锁)
带宽~1,355 GB/s~760 GB/s 量级
PCIeGen1 x4 锁Gen1 x4 锁
Falcon 描述符V2V3(审视更多)
设备 ID10DE:20C2以本机 lspci -nn 为准

节流对象也不一样:

指令170HX90HX(社区微基准量级)
FP32 FMA/FFMA~1/32大约 14–15× 变慢
DP4A大约 29×
FP16 HFMA2不限不限
INT32 IMAD不限不限
Tensor Coredispatch-gated几乎废掉
FP64极低通常也受限

90HX 更针对 AI/张量路径(DP4A、Tensor);两边都留下 FP16 / INT 当逃生口,所以 L1 仍有戏。

FMA / 指令节流在 90HX 上指什么

和 170HX 一样,这里说的不是「整卡报废」,而是某几类指令跑起来特别慢

  • FMA / FFMA:还是 a*b+c 那条 FP32 融合乘加。90HX 上延迟被拉长大约 14–15×(社区微基准),所以默认 FP32 内核会肉眼变慢。
  • DP4A:INT8 点积,AI/量化里很常见,90HX 上大约慢 29×——这是它比 170HX 更「针对 AI」的地方。
  • 不受限的逃生口:FP16 的 HFMA2、INT32 的 IMAD 往往仍正常,所以 L1 才用「换成这些指令」或 -fmad=false
  • Tensor Core:几乎废掉,多半不是改几条标量指令就能救;和单纯的 FMA 闸要分开看。

会影响什么:默认 FP32 计算、依赖 DP4A 的量化内核会慢;能重编译的 llama.cpp 一类用指令替换后 decode 能明显上去;闭源 cuBLAS/渲染仍难;显存和 PCIe 在 90HX 上通常不是这条锁的问题。

层次170HX90HX 推测
L1 指令替换-fmad=false 成熟DP4A→IMAD、FP32→HFMA2,已有 fork
L2 固件 ROPSEC2 DMA(2026-07)同类洞可能有,V3 + 寄存器要重逆
驱动启用NVIDIA-patcherpatcher 已写 90HX
VBIOSAmpere 签名未破同样,仅已签名互刷

现实路径:先 L1;L2 当长期课题;驱动补丁是前提。

L1:指令替换(现成)

被限指令换成不受限等价物。beellama-cmp90hx 一类实测映射:

原指令换成位置收益量级
DP4APTX IMAD(多次 mad.lo.s32common.cuhdecode +47.6%
FP32 FFMA 反量化(Q4_K/Q5_K)HFMA2vecdotq.cuh+7.1%
FP32 FFMA 反量化(Q6_K/Q2_K)HFMA2vecdotq.cuh+4.2%
编译-fmad=falsenvcc/CMake少生成 FMA

累计有人报到 Q4_K +58%、dense Q4_K_XL +87%(例如 42→62 tok/s decode)。构建示例:

bash
cmake -B build -DGGML_CUDA=ON -DCMAKE_CUDA_ARCHITECTURES=86 \ -DGGML_CUDA_FA=ON -DGGML_CUDA_FA_ALL_QUANTS=ON \ -DCMAKE_BUILD_TYPE=Release cmake --build build -j$(nproc) --target llama-bench llama-server

参考:Rhonstin/beellama-cmp90hxRhonstin/llama-cpp-cmp90hx-patch。局限:要能改源码;Tensor / 闭源 cuBLAS 路径救不了。

L2:固件 ROP(推测)

GA102 和 GA100 同属 Ampere:SEC2、GSP-RM、MMIO 防火墙、CSB、FEAT_OVR_* 族都在。若 SEC2 booter 也有类似 DMA bounce + canary,理论上能 ROP 写 FEAT_OVR_SM_SPD 解节流。

但这些几乎都要重做:

170HX90HX
描述符V2V3,攻击面更窄
GSP 文件gsp_tu10x.bin可能同文件或 gsp_ga10x.bin,需确认
gadget0x10B9 / 0x810D(绑 580)地址会变
FEAT_OVR 偏移0x0082381C可能不同
节流位含义SS0 满速一类或许另有 DP4A/Tensor 位
buffer / canary4096、0xFACEB13D需确认
驱动锁 580.173.02要找 GA102 上 GSP-RM 能稳起的版本

若洞存在,ROP 帧大致仍是:开 PLM → 写 SS0/SS1 → 尾帧退出。170HX 把 SS0/SS1 放在 FLR 后宿主 BAR0 补写;GA102 防火墙在 FLR 后放不放,得实测。

探索顺序可以是:dump GSP → Ghidra + falcon 插件看 SEC2 → 找 DMA 读签名段路径 → 找 CSB 写 gadget 与干净返回 → 对寄存器偏移 → 定驱动版本 → ROP→FLR→原厂固件。

主要不确定性:V3 签名更强;Tensor 节流可能是熔丝;寄存器布局不能照搬 170HX;580 不一定适用。短期别指望可交付工具。

L3:驱动与 VBIOS

dartraiden/NVIDIA-patcher 已列 CMP 90HX,补丁驱动后才谈 CUDA/OpenCL。稳定版本跟 patcher 文档走。

VBIOS:Ampere 签名未破,只能已签名 ROM 互刷(改子系统 ID 一类);改未签名 ROM 容易砖。MAC 外字段另说,节流寄存器一般不在那块「随便改」的区里。

各路径预期

路径现状L1 后L2 若成
FP32 FFMA节流HFMA2 / -fmad=false寄存器级满速
INT8 DP4A重节流IMAD 绕寄存器级
FP16 / INT32不限不变不变
Tensor Core近废换不了可能仍是熔丝
显存 / PCIe10GB、常 Gen4 x16无需解无需解

90HX 的瓶颈主要在算力节流,不像 170HX 还背着 Gen1 x4 和容量锁。

从 170HX 工具能搬什么

170HX 部件90HX
bar0.py / watchdog / pipeline 框架 / ELF sh_size 补丁思路多半可复用
gadget、寄存器表、固件段名、DMA 是否真溢出必须重逆
probe_*.py换设备 ID 和寄存器表

路线

短期:NVIDIA-patcher → beellama 或自打 L1 补丁 → 自写 kernel 优先 FP16/INT,-fmad=false

中期:dump 固件、比 V2/V3、定位 FEAT_OVR、写探针读候选寄存器。

长期:找溢出与 gadget、两阶段启动、验证 Tensor 是不是熔丝。

合规同矿卡改机那套:EULA、保修、仅自有硬件;L2 有变砖面。二手价不高,L1 收益已经够吃的话,L2 要算投入产出。

小结

跑推理:优先 L1,10GB + 正常 PCIe,体感通常好过 170HX 的 8GB+Gen1。做研究:V3 更难,但若打穿也更有信息量,从 dump 和 Ghidra 起步。Tensor:别默认能救回来。

社区:dartraiden/NVIDIA-patcherRhonstin/beellama-cmp90hxRhonstin/llama-cpp-cmp90hx-patch;170th Street 主要是 170HX,方法可参考。具体设备 ID、固件文件名、寄存器偏移以本机探测为准,不要硬套 170HX 数值。

ai协作,人工编辑

本文作者:张老板

本文链接:

版权声明:本博客所有文章除特别声明外,均采用 BY-NC-SA 许可协议。转载请注明出处!