速评：gpu-unlock 冲到 13.8k 星，我第一眼看的不是那些 TFLOPS，是提交数——37 次。
37 次提交，1.4k 个 fork。这比例不正常。我印象里同类内核模块项目，fork 一般在 star 的十分之一上下，提交数和 star 大致同向——代码堆得越久，看的人越多。gpu-unlock 是反着来的：几乎没人往里写代码，一大片人 fork 完就挂到自己 3090 上开机自检。这不是一个开源项目该有的生长曲线，这是一份请愿书的签名页。
事情本身一句话：同一块硅片，消费卡把 FP16/BF16/TF32 的张量速率砍到一半，专业卡跑满。作者自己给这事定性叫市场分层。NVIDIA 从来没在纸面上认过，但硬件里留了痕迹——RTX 3060 12GB 在 FP32 累加、默认功耗的稠密矩阵乘法下 BF16 从 27 TFLOPS 干到 51，3090 从 75 到 125，4090 峰值 165 到 329。砍一半这事儿不是你猜的，是被量出来的。
但先别急着高兴。这波流量里最该被拎出来的一条，是 llama.cpp 和 Ollama 那批量化 GGUF 用户拿到的提升：0–15%，还主要集中在长上下文。
也就是说，13.8k 个 star 里绝大多数人，收益基本等于零。解码阶段卡在显存带宽上，你把张量核心放开十倍也没用。真正吃到肉的是预填充、微调、图像和视频生成、FlashAttention/SDPA 那类内核——首 token 降 25%–30%，内核提 50%–60%，BF16 视频生成 15%–20%。这批人恰恰不是给这个仓库点星的人。
这类项目的传播曲线和它的收益分布，经常是反的。喊得最大声的是“我本地跑 7B”，涨得最多的是“我在跑 BF16 微调”。图一乐归图一乐，别把自己那点场景算进去。
还有个细节，比所有性能数字都值得看。项目自己提醒：4090 在默认功耗下会先撞功耗上限，大矩阵乘法的实际收益低于峰值比例。3090 Ti 那个 157 TFLOPS 是挂在 450W 设置下的——不解锁功耗，你连 88 都留不住。
这句话在通稿里通常第一个被删。它留着，反倒让我愿意信 3060 那 87%。能主动说自家峰值跑不满的项目，比只贴最大值的有底线。
能解锁的是吞吐，不是那块卡的定位。
实现方式才是这个项目跟过去那些短命脚本的根本区别。它不刷 VBIOS，不绑驱动版本，在 initramfs 阶段抢在官方 nvidia 模块绑定显卡之前动手，把速度选择器写成 SS0=0x88888888、4 位 SS1=0x8 IMLA4，先做一次 FLR 再交还给驱动。仓库里那个 610.43.03 只是拿来提取解锁所需固件，不是支持列表。
这一步的意义在于，战场被从驱动层挪到了启动层。以前的同类做法死得快，是因为绑死某个驱动版本，NVIDIA 一更新全废；而这个东西不在驱动里跑，你没法用一次驱动更新去堵它。它只有显式开启才生效，多卡并行处理通常一秒完事，从挂起恢复会多花一秒再解锁一遍，休眠场景没覆盖。
当然，NVIDIA 真要堵，从固件侧有的是办法，不需要发公告。这里我打个问号，不替它算命。
再说清楚不涨的部分，免得有人看完上面就开始做白日梦：INT8、FP8、INT4 模型不在范围内，游戏不在范围内，FP32 CUDA 负载也不在。项目说解锁前后输出按位一致，只快，不变。这句话挺重要——它意味着这不是超频式的赌博，功耗和温度节流机制原封不动，作者才敢说不太可能损坏显卡。
另外一句提醒也值钱：Windows 版是第三方移植，作者不维护，来历不明的安装器谨慎对待。13.8k 星之后肯定有人拿这个做流量生意——这点我几乎不怀疑。
这里立个 flag。往后几个月，我猜会看到两件事：一是某个驱动或固件版本里悄悄多出一道检查，不发公告那种；二是 GitHub 上冒出三五个基于这仓库改的“一键解锁”打包脚本，里面至少有一个夹了东西。第二件比第一件脏得多，而且到那时候被骂的会是这个项目本身。
37 次提交撑起来的仓库，扛不住一万四千个人的期待。