5卡Local LLM推理機組裝與調整

最初本來只是在主力機只有一張4080在玩ComfyUI，後來看到一張便宜的3080 12G後就收下來用想說其中一張卡跑一個較小的LLM，但入手後隨著想想玩的東西越來越多東西也越買越多，最後就乾脆獨立一台。

而這台最終的組合是 X99 平台配五張 RTX 3060，合計 60 GB VRAM。以下大致照組裝的順序記錄選料、踩到的坑與實際數據。

▲ 完成後的樣子，開放式礦機架

【主機板與 CPU】

主機板、CPU 與散熱器是二手整組買的，2500 元。CPU 是 i7-5960X，主機板是

ASUS X99 Deluxe。

選這組的理由是 PCIe 通道配置。這張板子的 所有PCIe x16 插槽由 CPU 直出，不需要額外的拆分卡就可以有5組 PCIe 3.0 x8插五張 GPU 。網路卡則插在 PCH 提供的 PCIe 2.0 x4 上。

【記憶體】

記憶體用 2 條 REG ECC 16 GB DDR4-2666。主機板與 CPU 的規格表只寫原生支援到2133，但實際插上去會自動跑到 2666。

後來跟朋友借了 4 條 8 GB DDR4-3200 來試，四通道 DDR4-3200 也上得去，不過效能似乎卡在 CPU IMC 本身的限制，跟雙通道 DDR4-2666 差距不大，所以最後就維持原本那兩條 ECC。反正模型權重全部在 VRAM，主機記憶體只在載入時走一次。

【系統碟與模型儲存】

只配了一顆 256 GB 的 Kingston SKC600 SATA SSD 當系統開機碟。模型權重檔全部放在 NAS 上，透過 SMB Direct 存取，本機不留副本。

【電源供應器】

電供是技嘉 P1000GM 1000W，RMA 回來未開封的，2000 元收到。它本身就有 6 個PCIe 8pin 可以直接用，另外再自己做了幾條 SATA 轉 PCIe 6pin 的線，供電給

PCIe 轉接板。

【網路卡】

網路卡用 HPE 544FLR-QSFP+ 40G，很久以前買的，加轉接板一張幾百元。

因為 NAS 端目前是 25G/10G 的網路卡，所以必須加轉接頭降速成 10G 來用。不過NAS 實際讀取上限大約 2 GB/s，網路卡只有10Gbps還算可以接受。

▲ HPE 544FLR-QSFP+ 加轉接板

【PCIe 延長方案】

延長走的是純被動方案：PCIe x8 轉 SFF-8654 x1，再用 SFF-8654 x1 轉回 PCIe x16。找閒魚上的委託代購，一組含線大約 500 元台幣。

▲ 轉接板與 SFF-8654 線材

市面上容易找到的 PCIe x8 轉 SFF-8654 轉接板有兩種，線路看起來比較簡單的那一種，要把板子上 R5 的電阻位置短路，否則插在主機板第一條 PCIe x16 以外的插槽會偵測不到卡。

原因是這個電阻位置的兩端分別是 PRSNT1# 與 PCIe x8 的 PRSNT2#，主機板就是靠這兩個接點有沒有導通，去判斷插槽上到底有沒有插介面卡。第一條插槽會過是因為它本來就預期有卡，其他插槽就得靠這組訊號自己表態。

▲ R5 位置補一點錫短路就正常了

【電力配置】

這台跟主力機共用一組 220V 的電源回路。兩台閒置時合計約 200~250W，LLM 跑起來大概再加 650W；如果主力機的雙卡（4080 + 3080）同時在生圖或跑影片，總功耗會衝到 1600W 以上。

▲ 只有 LLM 在跑的時候

▲ LLM 加上主力機生圖，220V 那一路來到 1651W

先前兩台加 NAS 都掛在同一組 110V/15A 回路上，不小心讓 LLM 跟生圖一起跑就會直接跳電，後來乾脆自己拉了一路 220V/15A 專門給主力機和 LLM 用。NAS 因為接110V 的 UPS，就繼續留在 110V。

【顯示卡】

五張 3060 是前兩個月陸續收的，單張 5500~6000 元。廠牌沒有統一，ASUS 的 ROG Strix、TUF、Dual 各一張，再加兩張 MSI──二手市場有什麼就收什麼，反正 VRAM一樣大、跑起來也差不多。以目前新品的售價來看，現在大概很難再用這個價格收到了。

▲ 五張 3060，廠牌與散熱器都不一樣

【軟體與效能】

OS 是 Ubuntu 26，跑 llama.cpp。原本載入跟切換模型都靠 script 檔，後來覺得太麻煩，就叫 Opus 寫了一個網頁控制介面。

▲ llama.cpp 控制台，起停模型跟改參數都在這裡

目前主要跑 Qwen3.6 27B Q8，開多模態與 MTP，模型與 KV 全部放在 VRAM，

context 可以開到 256K。在 32K context 長度下，TTFT 48 秒、prefill 677 t/s、decode 42 t/s。

補一下 Q4 與 Q8 在沒有 MTP 情況下的測試結果：

▲ llama-bench，Q4_K_M 對 Q8_0

【花費總結】

RAM、SSD、網路卡、礦機架都是本來就有的，這次額外買的只有主機板加 CPU 加散熱器、電源供應器，以及 PCIe 延長板。

‧ 主機板 + CPU + 散熱器（二手整組）：2,500

‧ 電源供應器 P1000GM 1000W（二手未拆）：2,000

‧ PCIe 延長板：一組含線約 500，五組約 2,500

‧ RTX 3060 x5：單張 5,500~6,000，合計約 2.8~3 萬

顯示卡以外的部分加起來大約 7,000 元。以 60 GB VRAM、能把 27B Q8 連同 256K context 整個放進 VRAM 來說還算划算吧

弄下來的一點感想是要搞多 GPU 門檻我覺得並不高。

AM5 平台大多支援把 PCIe x16 拆成 x8+x8、x8+x4+x4 或 x4+x4+x4+x4，再加上

CPU 直出的兩個 x4 M.2，配上 PCIe x16 轉 4x OcuLink 以及 M.2 轉 OcuLink 的轉接板，就可以生出 6 組 PCIe 4.0 x4 給 6 張 GPU 用。AM4 也可以有 5 組。

我之前就是在 AM5 主力機上跑 PCIe 4.0 x8+x8+x4+x4。用 HWiNFO 看會發現 GPU的 PCIe Error 計數器有一些數字，但實際運作沒遇到什麼問題；而如果降到 PCIe 3.0，這些錯誤計數就不會出現了。如果改用那種板上有 PCIe Redriver/Retimer 的延長方案，應該就可以在 PCIe 4.0 下完全沒有錯誤，只是價格貴很多。

至於PCIe頻寬夠不夠，目前 3060 跑 --sm tensor 模式，在 PCIe 3.0 x8（跟 4.0 x4 差不多）下還是有明顯增益的。

接下來說一些建置過程中的測試調整，也包含進常常看到有人在討論的PCIe頻寬與TP議題軟體設定修改與測試方面主要是由Codex與ClaudeCode處理的

下面的內容也是叫Codex/ClaudeCcde撈出來整理的

要先補充的是另一台機器：主力工作站是 Ryzen 7 9800X3D 配約 64 GB DDR5-6000，平常跑 ComfyUI 生圖，目前掛 RTX 4080 加 RTX 3080 兩張卡。多卡實驗最早就

是在它身上做的，後來卡片才陸續搬到專用伺服器。

卡片在這兩台之間流動過好幾次，這是下文所有測試的背景。順序大致是：主力工作站先從兩張卡擴到四張，成為多卡實驗的第一個場地；接著才另外組了專用伺服器，起初只有兩張 3060，中途曾把其中一張換成 3080 用來測異質組合，之後才逐步補到四張、再到五張同型號的 3060。所以下文提到「這台」時，指的是當時正在測的那一台，兩者的卡數與拓樸都不同。

最一開始是搞清楚單張 4080 跑得動什麼、能開多大 context。用的是官方 QAT 量化的 Gemma 4 12B（gemma-4-12b-it-qat-q4_0.gguf，6.50 GiB，另加約 0.16 GiB的 mmproj），RTX 3080 完全保留不用，正式 profile 設 262,144 context 配 Q8 K/V cache 與 Flash Attention。

▲ 單卡 Gemma 12B：context 上限 32K vs 256K

這組數字給出了一個貫穿後續所有 context 決策的結論：把可用 context 上限從32K 拉到 256K，短序列的解碼速度幾乎沒有變化（73.60 對 73.51）。換句話說，增加 context 上限本身不必然拖慢生成，真正的成本在 KV cache 佔掉的容量，以及長 prompt 的 prefill 時間。這條結論後來讓幾乎每個 profile 都敢把 context開大，只在 VRAM 真的不夠時才往回收。

再往後上線的是 Gemma 4 26B A4B Uncensored HauhauCS Balanced Q4_K_M（15.64 GiB，約 26B 總參數配約 4B active），跑在 4080 加 CPU/RAM 上、排除 3080，同樣是 131,072 context 與 Q8 KV。長時間日誌完成過一次 65,536-token 的連續生成，平均 43.99 tok/s，另有約 49-50 tok/s 的一般生成紀錄──這證明它不只能

載入，還能長時間穩定輸出。

值得先記一筆的是：這顆 MoE 在「部分權重留在 RAM」的配置下仍有 44 tok/s。同尺寸的 dense 模型在同樣情況下會慢得多，因為 MoE 每個 token 只啟用少數專家，實際需要讀取的權重量少了一個量級。

再來是Gemma4-31B Opus Distill 的兩個量化──它們跑在同一組三張卡（3080 加

兩張 3060）上，唯一的關鍵差異是 KV cache 放在 GPU 還是 CPU：

▲ Gemma4-31B Opus Distill：KV 放 CPU vs 放 GPU

Q5 這邊還有更細的量測：載入後三張卡的剩餘量分別是約 2.3 GB、3080 只剩約

436 MB、約 1.05 GB；跑完一次 21K token 的 prefill 之後 3080 仍有約 418 MB，確認了「idle 時的餘裕約等於穩態餘裕」──因為 KV 是在載入時就整塊預先配

置好的，不會隨著實際用量慢慢長大。生成速度約 11 到 12 tok/s，而且隨深度幾乎平坦（0 深度 10.9、21K 深度 12.2），代表它是被層鏈中最慢的那張卡綁住，而不是被 KV 綁住；prefill 在 21K prompt 時約 757 tok/s，首字約 28 秒。

兩相對照，把 KV 留在 CPU 的代價極高──Q6_K 的長生成只剩 4.16 tok/s，是 Q5（KV 在 GPU）的四成不到，因為每個 token 的跨 PCIe 與 RAM 路徑成了熱點。但Q6_K 換到的是 128K context（Q5 只有 96K），所以這是一筆刻意的交易而不是設定失誤：需要長 context 就付速度，需要速度就收 context。

另外 Q5 的 3080 只剩不到 0.5 GB，這個量化已經不能再往上加 context。這也是整段歷程反覆出現的一個規律：真正卡住的永遠是「最滿的那一張卡」，不是幾張卡加起來的總量。三張 12 GB 看起來有 36 GB，但只要有一張先滿，整個配置就到頂了。

主力工作站常常要跑ComfyUI，覺得要切換使用很麻煩，於是要搞了套X99，接下來的多卡測試換到了另一台X99機器上。這台起初只有兩張 3060──兩張卡都是 Gen3

x16 直連 CPU root port下面幾組測試都是在這台上做的。

換到這台機器最大的一筆效能提升來自切換張量切分方式，而原本的預測完全相反：這台沒有 P2P、卡間只有 5.57 GB/s 而且要繞主機記憶體，照直覺推斷 tensor

parallel 應該不划算。

實測推翻了這個預測（Qwen3.6-27B Q4_K_M @ ctx32K，同一個 prompt、temp 0）：

▲ Qwen3.6-27B：-sm layer vs -sm tensor（MTP 開／關）

TP 與 MTP 是乘法疊加的：18.3 經 TP 變成 30.9（1.7 倍），再經 MTP 變成 46（又 1.5 倍），總共 2.5 倍。

原因在於 batch=1 的生成是記憶體頻寬瓶頸而不是通訊瓶頸：每一層的 all-reduce只有大約 10 KB，幾微秒就傳完；而 -sm layer 的問題是同一時間只有一張卡在動，-sm tensor 則讓兩張卡同時計算每一層，等效頻寬因此翻倍。GPU 使用率的觀察

印證了這點──layer 模式下有一張卡閒著，tensor 模式下兩張都在 89% 與 92%。得到的教訓是：不要用「PCIe 慢、沒有 NVLink、沒有 P2P」來推論 TP 不划算，那個直覺只適用於大 batch 的 prefill。附帶好處是 tensor 模式的 VRAM 分配很平均（10361/10353），不像 layer 模式那樣偏斜（9747/10949）。生成越長還越快：114 token 是 34.6，300 token 45.4，800 token 45.8，8.6K prompt 則到 48.5 tok/s。

【把 PCIe 頻寬砍半來測 TP 的敏感度】

既然 TP 的收益這麼大，下一個問題就是它對頻寬有多敏感──如果換到頻寬更窄的插槽還划算嗎？做法是用 setpci 把 root port 的 LNKCTL2 target speed 從 Gen3降到 Gen2 再 retrain（這個改動不持久，重開機自動回復）。Gen2 x16 的 8.0

GB/s 約等於 PCIe 3.0 x8 的 7.88 GB/s，是很好的代理，因為軟體改不了 lane 數只能改速度。

▲ PCIe 由 Gen3 x16 降到 Gen2 對 TP 的影響

頻寬砍半只讓 prefill 掉 9%、decode 掉 5%，所以即使只有 x8 也該用 tensor

（44.4 對 29.6，還是 1.5 倍）。對照組只掉 1% 與 0.4%，這證明量到的確實是PCIe 的影響而不是雜訊。

更重要的是從這裡導出的洞察：痛不痛不是看頻寬，而是看「通訊佔計算時間的比例」。主力工作站的 3080 掛在 PCH 後面的 PCIe 4.0 x4（7.88 GB/s，跟這裡的

Gen2 差不多），但那邊的 tensor prefill 卻直接腰斬（2123 掉到 1011）。差別有兩個：一是 4080 與 3080 的算力約為 3060 的三倍，計算時間短，同樣的通訊量佔比就大增；二是 PCH 多了一跳而且有 DMI 爭用，延遲遠高於直連 root complex。所以單純從 x16 降到 x8 不痛，PCH 加上快卡才痛。

【P2P 解鎖：技術上成功，實用上幾乎沒有意義】

TP 既然靠卡間通訊，那把被鎖住的通道打開應該還能再快一點──這是很自然的下

一步。消費卡的 P2P DMA 被 NVIDIA 鎖住，但社群有開源分支可以解開，原本估計「通訊約 5ms 一個 token，P2P 省一半就有 +10%」。

實際做法是把 BIOS 改成 OS Type=Other OS（Secure Boot 關閉）並開啟 Above 4G Decoding，驅動換成 .run 安裝的 610.43.03 userspace 加上

aikitoria/open-gpu-kernel-modules 的 610.43.03-p2p 自編未簽名模組（taint 12288），並補上 nouveau 黑名單與 update-initramfs -u、把三個 kernel 套件apt-mark hold 住、開 NVreg_EnableResizableBar=1 加 grub 的 pci=realloc，以及把 NCCL 的 P2P 層級設成 SYS。

▲ P2P 解鎖前後：卡間頻寬 vs llama.cpp 實際效能

原本估的 +10% 是錯的。CUDA 層確實開通了，但 llama.cpp 幾乎沒有受益──因為llama.cpp 早就把通訊與計算重疊了，通訊根本不在關鍵路徑上，加速它省不到時間。頻寬分析只在大 batch 的 prefill 才成立，而那正好就是唯一有改善的地方。這也和前一節的結論互相呼應：既然頻寬砍半只掉 5%，把頻寬加倍自然也換不回多少。

另外三點值得記：NCCL_P2P_LEVEL=SYS 不設就等於整套白裝（NCCL 看到 PHB 拓撲會預設走繞主機的路徑）；ReBAR 生效的關鍵是 pci=realloc 而不是驅動版本

（GPU0 是 boot_vga，BAR 卡在 4G 以下，沒有 realloc 搬不上去），BAR1 因此從256 MB 變成 16 GB；而把 patch 移植到舊驅動是死路──上游 fork 最新只到 570，套到 595 有六個 hunk 失敗、全都在建立 peer PTE 的那段程式碼，手工補會靜

默地寫錯實體位址，比不能用還糟。

【-ts 有效，但 3080 的 12 GB 是個死結】

這台專用機中途曾把一張 3060 換成 3080，於是有了一組乾淨的異質卡環境可以驗證 -ts（手動指定各卡分配比例）到底有沒有用──兩張卡都是 Gen3 x16 直連、沒有 PCH 汙染。單卡的 tg128 是 3080 89.5、3060 42.1，所以理論最佳比例是

0.68/0.32。

▲ 異質卡 -ts 比例掃描（3080 + 3060）

從均分調到正確比例是 +38%，而且是單調上升直到理論最佳點才 OOM──如果不設

-ts，快卡會完全被慢卡拖住。

但把整個組合背對背比較之後，結論卻很掃興：

▲ 3080+3060 與 2x3060 的 decode 背對背比較

-ts 調校與 MTP 只能二選一，而 MTP 比較划算。要讓 3080 真正出力就得給它 68%的層數，也就是 10.8 GB，再加上 MTP 的 context（458 MB）與 compute buffer就爆掉 12 GB──ctx 試到 32k、16k、8k 全部 OOM，連 8192 都不行。核心問題是3080 快 2.13 倍但 VRAM 跟 3060 一樣是 12 GB，速度配不上容量，要換 24 GB 的卡才解得開。

換句話說，換上一張更快的卡並沒有換到更快的推論。這台機器最後的選擇是回頭走同型號路線──與其湊一張快卡加一張慢卡，不如多放幾張一樣的卡，讓分配變簡單、也讓每張卡的負擔平均。

【四卡一次到位】

四張 3060 到位之後，嘗試一次拿到「Q8 精度加 128K context 加多模態加 MTP」全開。腳本用四卡 -sm tensor（同型號同速所以不需要 -ts，正好省掉上一節那個兩難）、ctx 131072、Q8 KV、Flash Attention 打開、MTP 開啟，並為視覺任務加上 --image-min-tokens 1024。

結果是一次就成功、零 OOM：VRAM 用掉 39,900 / 49,152 MiB（81%），每張卡還剩1.5 到 2.6 GB，載入 56 秒。短文字生成 39.3 tok/s；8.6K prompt 的 prefill是 836 tok/s、生成 48.2 tok/s；圖片 prefill 436 tok/s。最有說服力的是深層驗證：52,551 token 的 prompt 以 760 tok/s 處理完，而埋在最開頭的密語被一字不差地複述出來──這證明它不只是「能載入」，而是真的記得住。

那麼加卡到底買到了什麼？

▲ 2x3060 vs 4x3060：加卡的邊際效益

擴展是次線性的，效率大約 0.33，因為 4-way all-reduce 的通訊成本吃掉了大半算力紅利。但加卡的真正價值不是速度而是容量──四卡跑 Q8（836 / 48.2）全面

勝過雙卡跑 Q4（664 / 45.7），等於精度翻倍、context 翻倍、圖片快十倍，而速度不減。

其中「圖片快十倍」值得單獨說明：四卡最大的好處是 mmproj 可以放上 GPU。雙卡時 VRAM 不夠，必須讓視覺編碼器跑在 CPU 上，圖片 prefill 只有 46 tok/s；四卡放上 GPU 之後（GPU0 多吃 1.1 GB）跳到 436 tok/s。

--