我覺得以後只要有一個技術可以令蘋果設備加強就已經夠打,人家多機連接只需一條線

https://lcz.me/topic/1607/13

我也做了,我把記錄加到我自己的貼子了

RTX 3080 20GB 解鎖全紀錄：FP16 +85%、BF16 +68%，然後我拿它去跑了 125B MoE

TL;DR — gpu-unlock 在 Ampere 上確實有效，我的 3080 20GB 魔改卡 FP16 從 57.31 → 105~106 TFLOPS（+85%）、BF16 64.37 → 106.63~109.41（+68%）、TF32 +70%，FP32 完全不變（這正是它有效的證據）。但對大型 MoE 的推理速度一點幫助都沒有 —— 記憶體頻寬才是瓶頸。真正有用的是算力密集、不吃頻寬的工作。

---

一、為什麼要解鎖

手上有一張 RTX 3080 20GB 魔改卡（GA102、68 SM、compute capability 8.6、320W power limit），跑在 KVM 虛擬機裡、PCI passthrough 直通給 guest。

20GB 在 2026 年仍然是很好用的容量 —— 夠放 27B Q4、夠放 Qwen3-Coder-Next 的量化版、夠跑 FLUX。但 GA102 的 FP16/BF16 吞吐是被硬體保險絲鎖住的：消費級 GeForce 的 FP16/BF16 FMA issue rate 只有專業卡的一半。

gpu-unlock 這個專案（github.com/Zagitta/gpu-unlock，C 語言，約 300 星）做的事就是繞過那道鎖。

二、原理（看懂這段才知道為什麼 FP32 不會變快）

這個專案源自 CMP 礦卡的解鎖器（CMP-unlocker V67 / PLM），用的是 UEFI pre-boot 時序：在 nvidia 驅動綁定顯卡之前，搶先寫入 GPU 的 fuse shadow 暫存器：

• SS0 ← 0x88888888：把 FP16/BF16 的 issue rate 拉回 full-speed BF16
• SS1 ← 0x8：打開 IMLA4 指令

關鍵在於它只改 FP16/BF16 的 FMA 吞吐，不動 FP32 的 CUDA core 數量。所以：

• FP16 / BF16 / TF32 → 大幅提升（它們走 tensor core 路徑）
• FP32 → 完全沒變（走一般 FP32 管線，本來就沒被鎖）

如果你的 FP32 數字也變快了，那才是可疑的 —— 那代表你量到的不是真實增益，而是時脈或散熱狀態的變化。我特別把 FP32 當作對照組。

三、環境

項目	值
GPU	RTX 3080 20GB（GA102、68 SM、CC 8.6、320W）
驅動	595.99.02
系統	Ubuntu（Linux 7.0.0-38-generic）
虛擬化	KVM guest，PCI passthrough
Secure Boot	開啟
initramfs	dracut（不是 initramfs-tools）

注意最後兩項 —— 這是後面兩個坑的來源。

四、正確的安裝方式

專案 README 的做法：

git clone https://github.com/Zagitta/gpu-unlock
cd gpu-unlock
make
sudo make install        # 或 make install-deb

然後必須加 kernel cmdline 指定要解鎖的 PCI 位址：

gpu_unlock.targets=0000:02:00.0

（lspci -nn | grep NVIDIA 找到你的位址，格式是 DDDD:BB:DD.F）

接著重建 initramfs、重開機。

️ 網路上常見的錯誤做法

sudo insmod gpu_unlock.ko     # ← 沒用

專案 README 明講：對已經被 nvidia 驅動綁定的卡手動載入模組沒有作用。解鎖必須發生在驅動綁定之前，也就是 initramfs 階段。

另外，編出來的產物名字是 gpu_unlock，不是 gpu-unlock.ko。用 insmod 找錯檔名的人會卡很久。

五、三個實戰坑

坑 1：dracut vs initramfs-tools（最容易漏）

make install-deb 只會裝這一個檔案：

/usr/share/initramfs-tools/modules.d/gpu-unlock.conf

但 Ubuntu 現在預設用 dracut。 如果你 ls /etc/initramfs-tools/ 發現根本沒在用，那這個 conf 永遠不會被讀到，模組不會進 initramfs，重開機後什麼都不會發生（也不報錯，最陰險）。

要自己補一個：

sudo tee /usr/lib/dracut/dracut.conf.d/gpu-unlock.conf <<'EOF'
force_drivers+=" gpu_unlock "
EOF

然後重建。怎麼確認真的進去了：

lsinitramfs /boot/initrd.img-$(uname -r) | grep gpu_unlock
# 應該看到：
# usr/lib/modules/7.0.0-38-generic/updates/dkms/gpu_unlock.ko.zst
# usr/lib/firmware/... (nvidia firmware)

我的 initrd 從 38 MB 長到 110,239,486 bytes，這就是模組和 firmware 真的被打包進去的證據。

坑 2：Secure Boot 擋下未登記的金鑰

重開機後 dmesg 出現：

Kernel is locked down from EFI Secure Boot mode
Loading of module with unavailable key is rejected

nvidia 模組有 Canonical 簽章，所以沒問題；gpu_unlock 是 DKMS 現場編譯的，用的是你機器自己的 MOK 金鑰 —— 而它還沒被登記。

解法：

sudo mokutil --import /var/lib/shim-signed/mok/MOK.der
sudo reboot

重開機會進 MOK 管理畫面（藍底），選 Enroll MOK → Continue → 輸入密碼。這個畫面只停留約 10 秒，錯過就要重來一次。

坑 3：驅動版本與 firmware 不符

專案附的 firmware 是給 610.43.03 的，我的是 595.99.02。屬於「未支援組合」。

實測結果：能跑，而且數字完全正常。專案做的是改 fuse shadow，與驅動版本相關性不高。但這是你自己要承擔的風險 —— 如果哪天驅動更新到 610 之後反而出現異常，記得回來懷疑這個組合。

六、成功長什麼樣

開機 dmesg 會有一長串 ROM 解析日誌，最後一行是關鍵：

gpu_unlock: loading out-of-tree module taints kernel.
ROM chain: pos=0x0 data=0x52494350 bytes=65024 type=0x0
...
FWSEC geometry: image_off=0x4239c size=0xde00 imem=0xd600 dmem=0x800 ...
FWSEC signature selection: versions=0x7 fuse_version=2 sig_bytes=384
pci 0000:02:00.0: gpu_unlock: unlocked          ← 這一行才是成功

注意：沒有這一行就代表沒解鎖，即使模組載入成功也一樣。很多人 lsmod | grep gpu_unlock 看到模組在就以為成功了 —— 那不代表 fuse 被改到。

（順帶一提：解鎖是 per-boot 的，每次重開機都要重新跑一次這個流程，這也是為什麼它必須在 initramfs 裡。）

七、實測數據

方法：PyTorch torch.matmul，8192³ 方陣，每個 dtype 跑 5 次取中位數，解鎖前後各測一輪（解鎖後跑兩次確認可重現）。

dtype	解鎖前	解鎖後（兩次）	增益
FP16	57.31	105.25 / 106.11	+85%
BF16	64.37	106.63 / 109.41	+68%
TF32	31.61	53.90 / 53.42	+70%
FP32	21.47	21.43 / 21.24	±0% ← 對照組，正確

兩次獨立測量誤差 < 2.5%，所以這不是雜訊。

對照作者在 3090 Ti 上的數據

dtype	3090 Ti 前	3090 Ti 後	我的 3080 前	我的 3080 後
FP16	87.46	118.39	57.31	105~106
BF16	87.50	157.41	64.37	106~109
TF32	42.58	82.61	31.61	53.90

兩點觀察：

1. 我的 3080 解鎖後 BF16 只有 106~109，作者的 3090 Ti 到 157。差距來自 SM 數（68 vs 84）與功耗上限（320W vs 450W），完全符合預期。
2. 相對增益我也是略低（BF16 +68% vs +80%）。沒有黑魔法 —— 這張卡該有的表現就是這樣。

八、證明這不是時脈幻覺

最容易被質疑的一點：「你是不是只是 GPU 跑到更高頻？」

測試期間用背景 nvidia-smi 每 0.5 秒採樣：

指標	實測最高	上限
功耗	251 W	320 W
核心時脈	1950 MHz	—
溫度	52 °C	—

251W / 320W —— 沒撞功耗牆。 52°C 也遠遠不到降頻溫度。

所以增益全部來自 instruction issue rate 加倍，不是頻率或散熱。

九、然後我拿它去跑 125B MoE —— 幻滅

解鎖之後第一件事，當然是把手上最大的模型丟上去：Qwen3.8-Flash-Next 125B MoE（IQ2_XS 量化）。

結果：

指標	RTX 3080 20GB（解鎖後）	R9700 32GB
解碼速度	50~62 tok/s	70~88 tok/s
專家槽數量	7,941	16,862
VRAM	19,896 / 20,480 MiB（滿）	31.5 / 31.9 GiB
prefill（27k tokens）	1,090 tok/s	1,363 tok/s
系統可用 RAM	8.8 GiB（危險）	正常

解鎖後仍然輸。 原因很簡單：

大型 MoE 的 decode 是 記憶體頻寬 + VRAM 容量 的競賽，不是算力的競賽。

3080 的 320-bit GDDR6X 頻寬約 760 GB/s，而 125B MoE 每一顆 token 都要把大量專家權重搬一次。你把 FMA 吞吐加倍，只是讓「計算」變快 —— 但計算本來就不是瓶頸，等資料才是。

而且 20GB VRAM 只放得下 7,941 個專家槽（R9700 有 16,862），命中率 95.5% vs 98.5%，其餘全部要走系統 RAM，把 42GB 主機記憶體吃到只剩 8.8GB —— 這是隨時會 OOM 的狀態。

結論：解鎖不能讓一張 20GB 卡變成 32GB 卡。容量和頻寬是買不到的（至少這個專案買不到）。

十、它真正有用的地方

於是我改變策略：大模型留在 R9700，3080 專門做「算力密集但不吃頻寬」的工作。

這才是解鎖的甜蜜點 —— 這些工作全是矩陣乘法，而且模型小、資料在 VRAM 裡跑得動。

我實際做的：把多模態模型的 vision encoder 移到 3080。

編碼一張 960×1280 的照片:
  CPU（6 執行緒）  1.50 s
  RTX 3080（CUDA） 0.07 s     ← 21 倍

️ 誠實說明：這 21 倍是 CPU → GPU 的差距，不是解鎖的功勞。我沒有單獨量測「解鎖前 vs 解鎖後」的 vision 編碼速度，所以不能把這個數字算在解鎖頭上。解鎖在理論上應該有幫助（vision encoder 是純 FP16 矩陣運算），但我沒有證據。

其他明顯受益的方向（同樣是算力密集、模型小）：

• Embedding / rerank（bge-m3、Qwen3-Embedding-8B）—— 批次吞吐直接翻倍
• Whisper 語音轉錄
• FLUX / SDXL 影像生成 —— 這是最大的受益者，diffusion 每一步都是大矩陣乘法，而且完全不吃頻寬
• 小型 dense 模型（8B~14B）的 prefill

反過來，不要在這張卡上跑：

• 30B-A3B 以上的 MoE（會拉爆系統 RAM，我就因此當機過一次）
• 任何需要 >40K context 的工作（20GB 扣掉權重後 KV cache 不夠）

十一、回滾

完全移除：

sudo apt-get remove -y gpu-unlock-dkms

# 移除 kernel cmdline
sudo sed -i 's|gpu_unlock.targets=[^ ]* ||' /etc/default/grub
sudo update-grub

sudo dracut -f
sudo reboot

回滾後 FP16/BF16 會回到原本的一半吞吐，其他一切正常。

十二、風險提醒

1. 這是修改 GPU firmware 行為的工具，不是官方支援的功能。理論上有變磚風險（雖然社群回報中極少）。
2. Secure Boot 需要登記自簽 MOK —— 等於在開機鏈上開了一個口子。安全性要求高的機器請三思。
3. 驅動更新後行為未知 —— 特別是你的驅動版本與專案 firmware 不符時。
4. 每次開機都會重新套用，任何 initramfs 相關的變更（核心更新、dracut 重建）都可能讓它靜默失效。建議在 dmesg 裡留一行檢查，或寫個開機腳本檢查 gpu_unlock: unlocked 是否存在。

結語

gpu-unlock 是真的有效 —— 數據乾淨、FP32 對照組不動、功耗溫度都正常，不是玄學。

但它不會把你的消費級卡變成專業卡。它只是把被鎖住的 issue rate 還給你，而這個世界大部分的 AI 推理瓶頸是記憶體，不是算力。

在我的機器上，它的價值是：讓一張 20GB 的 3080 從「跑不動大模型、跑小模型也慢」變成「專門處理算力密集的小模型工作」，而且做得非常好。

如果你的工作負載是 diffusion、embedding、vision —— 值得一試。
如果你期待它讓你的 70B 模型變快 —— 省下來吧。

---

硬體：RTX 3080 20GB（GA102/68SM/320W）、驅動 595.99.02、Ubuntu 7.0.0-38-generic、KVM PCI passthrough
測試工具：PyTorch cuBLAS，8192³ GEMM，5 次中位數

大家存放資料的需求不一樣

你怎知道它抓?會出什麼提示,我現在的問題是很容易跳GAME

我玩helldivers2 經常跳GAME 不知道是否這個原因

一直在看版主的影片，為自己公司開發了一套POS+處方。想在自己的伺服器做一些數據庫的長期工作，所以組了這台PC。
升級了 AM5 平台的電腦（Ryzen 9 7900X + 64GB DDR5 + RTX 3080）後，一直希望能達成「一套硬體，同時搞定 3D 遊戲、舊 NAS 磁碟整合與本地 AI 推理」的終極目標。

最終我選擇了 Proxmox VE (PVE) 虛擬化平台。經過一番折騰，成功實現了 Win11 VM 獨佔 RTX 3080 爽玩 3D 大作，同時掛載 飛牛OS (fnOS) 直通 4 顆大容量 HDD 整合舊 NAS，背景還能跑 Ubuntu VM 進行QWEN 3.8 27b 大模型推理！

這篇文章將完整紀錄這套架構的組態、AI 排錯心得，以及最關鍵的「PCIe 顯卡直通與硬碟整合指南」。
一、 硬體配置與虛擬化架構

CPU：AMD Ryzen 9 7900X (AM5 平台)

RAM：64GB DDR5 (32gX2 )

GPU：NVIDIA GeForce RTX 3080 20GB 京東魔改卡! 
Storage：系統 NVMe SSD + 4 顆大容量 3.5 吋 HDD（來自舊 NAS 汰換與整合）

Host OS：Proxmox VE 8.x

虛擬機架構劃分：

VM 101 (Windows 11)：直通 RTX 3080，專門用於玩《絕地潛兵 2 (Helldivers 2)》等 3D 遊戲與日常娛樂。

VM 102 (飛牛OS / fnOS)：直通 4 顆 HDD，作為全家人的多媒體影音中心與資料儲存庫，完美接管並集中管理舊 NAS 的所有硬碟。

VM 100 (Ubuntu)：作為 AI 與自動化服務節點，部署 Qwen2.5-27B 大語言模型 (搭配 SGLang + HiCache)。

二、 AI 助攻！PVE 架構與複雜設定的「神隊友」

在搭建這套系統的過程中，遇到了無數傳統 論壇/Google 搜尋很難一眼找到答案的邊角料問題（例如 PCIe Reset Bug、ZFS ARC 記憶體爭搶、虛擬化中斷號衝突等）。

這次最大的不同，是全程導入 AI 進行協同排錯與指令生成：

精準撰寫自動化指令：不管是複雜的 /etc/fstab 掛載、ZFS 記憶體上限計算，還是 PVE 的 Shell 指令，直接請 AI 根據目前的硬體狀態寫出客製化指令，完全不用怕打錯參數。

即時診斷系統死鎖：當遇到 VM 卡死 lock-101.conf 或是 SSH 斷連時，把 PVE 日誌（journalctl）貼給 AI，能立刻精準定位出是 NVIDIA 驅動 PCIe 重置失敗還是 ASPM 電源管理在作怪。

架構優化建議：包含記憶體分流、直通硬碟的 /dev/disk/by-id/ 綁定邏輯等，AI 都能提供最直接的解答，節省了 80% 漫無目的爬文的時間。

三、 飛牛OS (fnOS) 整合 4 顆舊 NAS 硬碟

為了把舊 NAS 的資料與 4 顆 3.5 吋硬碟完全合併進這台 AM5 神機，我選擇了近期口碑極佳的 飛牛OS (fnOS)。
硬碟直通 (Disk Passthrough) 技巧

在 PVE 中，為了讓 fnOS 能夠直接讀取硬碟的 S.M.A.R.T. 狀態並發揮最佳休眠與 I/O 效能，建議使用 by-id 方式將 4 顆硬碟逐一直通給 fnOS VM：

查詢硬碟序列號：
在 PVE Shell 執行：
Bash

ls /dev/disk/by-id/

將硬碟綁定至 fnOS (VM 102)：
Bash

qm set 102 -scsi1 /dev/disk/by-id/ata-STxxxxxxx_XXXXX1
qm set 102 -scsi2 /dev/disk/by-id/ata-STxxxxxxx_XXXXX2
qm set 102 -scsi3 /dev/disk/by-id/ata-STxxxxxxx_XXXXX3
qm set 102 -scsi4 /dev/disk/by-id/ata-STxxxxxxx_XXXXX4

直通完成後，開機進入 fnOS 即可直接建立 RAID 陣列或獨立儲存空間，舊 NAS 的檔案也能透過網路備份或直接掛載搬移，成功達成「淘汰舊機器，縮減設備體積」的目的。
四、 Win11 VM 顯卡直通（Passthrough）與地獄級避坑指南

將 RTX 3080 直通給 Win11 VM 是這套系統最香、但也最容易踩坑的部分。以下是無痛直通與解決卡死的關鍵技巧：

1. PVE 顯卡直通最佳設定

   BIOS / PCIe：開啟 ROM-bar 與 PCIe 標記。

   主顯卡關閉：在 PVE VM 的 Hardware 設定中，取消勾選 Primary GPU (x-vga=1)。這個設定如果開啟，常會引發 NV 驅動重置失敗。

   顯示器：預設介面設定為 none 或 VirtIO-GPU（搭配 Looking Glass 或 Sunshine/Moonlight 串流）。

2. 解決關機卡死與 lock-101.conf 逾時問題

直通環境下，Windows 關機時常因為 RTX 3080 的 PCIe Bus Reset 失敗，導致 VM 卡在背景，PVE 拋出 can't lock file /var/lock/qemu-server/lock-101.conf - got timeout。

根本解法（必做設定）：

關閉 Win11 快速啟動 (Fast Startup)：
Windows 的快速啟動底層是休眠機制，會導致 PCIe 顯卡狀態無法乾淨釋放。在 PowerShell 以管理員執行：
PowerShell

powercfg /h off

關閉 PCIe 電源管理 (ASPM)：
在 Windows 電源計劃的進階設定中，將 PCI Express ➔ 連結狀態電源管理 設定為 「關閉」；USB 選擇性暫停 設定為 「已停用」。防止顯卡在閒置或關機時進入低功耗休眠，徹底擺脫死鎖。

緊急解鎖指令：
若不幸遭遇鎖定卡死，可透過 PVE SSH 執行以下命令強制解鎖（不會影響其他運行中的 VM）：
Bash

fuser -k /var/lock/qemu-server/lock-101.conf
rm -f /var/lock/qemu-server/lock-101.conf
sed -i '/^lock:/d' /etc/pve/qemu-server/101.conf
systemctl restart pvedaemon pveproxy

五、 PVE 宿主機記憶體與 ZFS 輕量化調優

由於配置了 64GB DDR5 記憶體，且同時運行 Win11、fnOS 與 Ubuntu VM，為了避免 PVE 預設的 ZFS ARC 快取吃掉太多 RAM 導致分配給虛擬機的記憶體不足，需要對 ZFS ARC 進行限制：

在 /etc/modprobe.d/zfs.conf 中限制 ARC 最大使用量（例如限制在 8GB）：
Plaintext

options zfs zfs_arc_max=8589934592

修改後執行 update-initramfs -u 並重啟 PVE，即可讓系統記憶體調配達到極佳的平衡，確保 64GB 記憶體能精準分給各個核心服務。
結語

經過這一套完整的優化，這台 AM5 主機實現了真正意義上的「一機多用」：

遊戲娛樂：開啟 Win11 VM，RTX 3080 原生效能全開，順暢運行各類 3D 遊戲。

資料中心：飛牛OS 接管 4 顆 3.5 吋 HDD，提供超順暢的影音串流與檔案備份，完美淘汰舊 NAS。

智能後台：Ubuntu VM 穩定提供 AI 模型推理解算環境，搭配 AI 助手輔助維運，省心又高效。

如果你手邊也有高效能主機與舊硬碟，不妨也嘗試看看這套 Proxmox VE 雙系統直通 + fnOS 的全能組合！