文章目錄
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