文章目錄
36GB VRAM 的幻覺：我讓三家 AI 預測 RTX 3060 ×3 的推論效能，結果全部被數據打臉
Mr. τ／風雲網通系統 · 2026-06-10 · 地端 AI 基礎設施
一、心動的開始
前幾天，社群裡流傳一篇文章。
有人用 RTX 5090 在本地跑 Gemma 4 12B，透過一個參數調整，TPS 從 27 直接飆到 103。將近四倍。
看完之後，我盯著螢幕想了很久。
「我手上有三張 RTX 3060 12GB，加起來 36GB VRAM。應該也能跑得很猛吧？」
其實買第三張卡的初衷很務實。不是為了炫耀規格，而是有實際需求：
- 兩張卡跑大一點的模型，偶爾會 OOM（顯存不足），動不動就崩
- 想測試 26B、27B 等級的模型，需要更寬裕的 VRAM 緩衝
- 不希望因為顯存限制，就把好不容易找到的優質模型放棄
帶著這個期待，我做了一件很多人都會做的事：先去問 AI。
💡 小科普：什麼是 TPS？
TPS = Tokens Per Second，每秒能生成多少個文字單位。數字越高，模型回應越快。一般對話體感流暢大約需要 15 TPS 以上；Agent 自動化任務則越高越好。
二、三家 AI 都這樣說
我把硬體規格丟給 Gemini、Grok、ChatGPT，問它們怎麼配置最好。
三家的答案大同小異，方向都很樂觀：
三張卡全上，tensor split 平均分配，context 可以拉到 128K 以上，非常適合 Agent 長對話場景。
Grok 最樂觀，直接說：「三張卡比單張 5090 還靈活！」
聽起來很美。
沒有任何一家特別提醒我：插槽本身的差異，可能才是決定勝負的地方。
我當時也沒有多想。於是開始動手。
💡 小科普：什麼是 tensor split？
多張顯卡同時跑推論時，需要把模型的不同「層」分配給不同的卡，這個分配方式叫做 tensor split。分配比例決定了每張卡承擔多少運算量。聽起來很合理——多張卡分工，理應更快。但前提是，卡與卡之間的溝通速度要夠快。
三、動手實測
測試環境如下：
| 項目 | 規格 |
|---|---|
| 顯示卡 | RTX 3060 12GB × 3（共 36GB VRAM） |
| 插槽配置 | CUDA0：PCIe x4／CUDA1、CUDA2：PCIe x16 |
| 模型 | Gemma 4 12B Q4_K_XL（6.86GB） |
| 推論引擎 | llama.cpp llama-server（最新版） |
| 測試工具 | 自製 matrix_runner.py，系統性跑完所有 GPU 組合 |
我把三張卡拆成三種組合，逐一測試，記錄每種配置的實際 TPS。
然後靜靜等待數據出來。
四、數據出來了
| GPU 配置 | Context 範圍 | 平均 TPS | 結果 |
|---|---|---|---|
| 單卡 CUDA1（x16） | 2K ~ 16K | 37.1 ~ 37.5 | ✅ 穩定，全程幾乎不掉速 |
| 雙卡 CUDA1+2（x16+x16） | 32K ~ 98K | 37.2 ~ 37.3 | ✅ 速度幾乎不變，免費擴 context |
| 三卡含 CUDA0（x4） | 8K ~ 32K | 10 ~ 15 | ❌ 比單卡慢 71% |
三張卡全上，是最慢的配置。
36GB VRAM 的幻覺，就這樣破了。
💡 小科普：PCIe x4 vs x16 差在哪？
PCIe 是顯示卡與主機板之間的資料通道。x16 有 16 條資料線，x4 只有 4 條，帶寬差了四倍。單卡使用時幾乎感覺不到差異，但多卡需要頻繁交換資料時，x4 插槽就會成為整條鏈路的瓶頸——所有卡都必須等它。
五、我真正學到的三件事
① GPU 數量不等於推論效能，PCIe 拓撲才是關鍵
很多人以為 VRAM 總量夠大就夠了。但這次實測清楚證明：多卡協作的系統效能，取決於「最慢的那條路」。
36GB VRAM 聽起來很漂亮，但它不是一個統一的記憶體池，而是三個各自獨立的 12GB 島嶼。卡與卡之間要交換資料，這個溝通成本才是真正決定速度的地方。
x4 那張卡拖慢了整個系統，這是結構性問題，不是調參能救的。
② 雙卡變成「免費的 context 擴充」
半年前的測試記錄顯示，雙卡比單卡慢 15%，要 context 超過 96K 才值得用雙卡。
這次重測：雙卡 37.2 TPS，單卡 37.5 TPS，幾乎一樣。
llama.cpp 持續在演進。同一套硬體、不同版本的推論引擎，結論可以完全翻轉。測一次就寫死結論，會害到自己。
💡 小提示：定期重測很重要
llama.cpp 的更新速度非常快，每隔幾個月就可能有重大改善。建議在升級推論引擎後，用固定的測試腳本重跑一次基準測試，確認結論是否還成立。
③ n_parallel 是最容易被忽略的 VRAM 黑洞
llama-server 啟動時，不指定 --parallel 的話，預設會自動設為 4。
很多人以為：--ctx-size 8192 = KV Cache 佔用 8192 token。
實際上：8192 × 4 個 slot = 32,768 token 的 KV Cache。VRAM 瞬間膨脹四倍。
很多人以為是模型太大、顯卡不夠、量化有問題——其實只是這個預設值在默默吃掉記憶體。
💡 小提示：單人使用加這個參數
--parallel 1：告訴 llama-server 只需要服務一個對話，KV Cache 回到正常大小，VRAM 壓力大幅降低。多人同時使用再考慮調高。
六、那麼，人家 5090 為什麼能破百 TPS？
看到這裡，很多朋友一定會冒出這個問題：
「你 37 TPS，人家 103 TPS，差了將近三倍。原因到底是什麼？」
這不是輸，而是兩條完全不同的賽道。
原文用的推論引擎是 vLLM，我用的是 llama.cpp。兩者的設計目標根本不同：
| vLLM | llama.cpp | |
|---|---|---|
| 設計目標 | 榨乾高端單卡極限 | 讓普通硬體也能跑 |
| 跨平台 | ❌ CUDA 專用 | ✅ CPU / CUDA / Metal 皆可 |
| 多卡擴展 | 需要 NVLink 才能完整發揮 | PCIe tensor split 即可 |
| 硬體門檻 | 高（單卡高階 GPU） | 低（消費級多卡皆可） |
原文那個「拔掉一個參數 TPS 從 27 飆到 103」的關鍵，是一個叫做 CUDA graph 的機制。vLLM 深度實作了它，llama.cpp 為了跨平台彈性選擇了不同路線。
📖 延伸閱讀：CUDA graph 是什麼？為什麼能讓 TPS 暴增四倍？
正常推論每生成一個 token，CPU 都要跟 GPU 溝通一次。CUDA graph 把整個推論流程「錄製」成劇本，之後 GPU 直接重播，省掉大量溝通成本。LLM 每個 token 的運算結構高度重複，特別適合這個機制。詳細原理與適用顯卡，請見下一篇文章。
七、給決策者的建議
如果你是正在評估地端 AI 基礎設施的企業主或 IT 主管，這次實測有幾個實際結論可以參考：
買卡前先問插槽：主機板上每個 PCIe 插槽的通道數是 x16 還是 x4？這比卡的型號更重要。
兩張 x16 勝過三張混搭：寧可投資兩張滿速 PCIe x16 的卡，也不要為了湊 VRAM 數字加第三張受限插槽的卡。
顯存夠用 ≠ 推論更快：區分「載入模型需要的安全餘裕」和「實際推論速度」，是兩個不同的目標。
定期重測，不要信舊結論：llama.cpp 持續演進，半年前的測試數據今天可能已經過時。
八、結語
買第三張卡的初衷，是不想讓顯存限制卡住探索的腳步。這個目的達到了。
至於那張 PCIe x4 的卡，目前在推論速度上確實是弱點。但我相信早晚會找到它的位置——模型在精進，工具在演進，搭配方式也會跟著出現。
工程的樂趣從來不是找到完美的配置，而是在現有條件下，合理榨乾效能、保持餘裕、讓系統穩定地活著，然後繼續往前走。
我們相信模型會精進，硬體會便宜，我們只是在過程中，盡量找到存活與推進的路徑。
📖 本系列延伸閱讀
→ 【即將推出】CUDA graph 是什麼？為什麼同樣是 RTX 3060，在 vLLM 和 llama.cpp 上表現差這麼多？
→ 【即將推出】從 GPU Bin Packing 到 Runtime Scheduler：地端 AI 的系統架構設計
💬 你的配置跑出多少 TPS？
歡迎在下方留言分享你的硬體配置與實測數據，一起打破對多卡的迷思。
作者：Mr. τ／風雲網通系統有限公司
標籤：#Gemma4 #llama_cpp #LocalLLM #RTX3060 #多卡推論 #地端AI #PCPiLOT
Comments