雙顯卡跑大模型值不值?PCIe 頻寬與切分全解析

多卡的第一瓶頸不是頻寬總量,而是同步次數(本文推論)。 官方文件只寫 tensor 模式「受 GPU 互連速度的瓶頸嚴重得多」,並未區分頻寬總量與同步次數;本文依官方的「每層做多次跨 GPU 歸約」再乘上層數推論:兩種切分法之間的差距,不在於誰搬的資料比較多,而在於每產生一個 token 要跨卡「等」幾次。
llama.cpp 官方已經把 -sm row 標為 deprecated,並寫明新部署應避開。 舊教學仍常見「雙卡就開 row 模式」的寫法,那是這個標記出現之前的建議。
vLLM 官方在「GPU 數不整除」的邊界情況註記中補充:節點上的 GPU 之間若沒有 NVLINK 互連,改用 pipeline parallelism 取代 tensor parallelism 可得到更高吞吐與更低通訊開銷。這句話直接鬆動「雙卡就開 TP」的直覺,而沒有 NVLink 正是消費級雙卡的真實處境。

這三點會決定你買第二張卡之後拿到的是「跑得動」還是「跑得動又跑得快」,也會決定第二張卡是不是白買。

📊 三種配置路線快速比較

配置路線	VRAM 合計(以 24 GB 卡計)	最適場景	主要限制	站長推薦度
A 單卡 + CPU offload	24 GB(+系統記憶體)	模型只超一點點、預算最優先	溢出的層跑在系統記憶體,速度明顯下降	⭐⭐⭐
B 雙卡 pipeline 切分(`layer`)	48 GB	模型放不進單卡、互連只有 PCIe	官方定位在 prefill 與批次吞吐;單請求逐字生成不會明顯加速(本文推論)	⭐⭐⭐⭐⭐
C 雙卡 tensor 切分(`tensor`/TP)	48 GB	追求單請求低延遲、且有 NVLink	每層多次跨卡歸約,受互連速度嚴重拖累	⭐⭐⭐

⚠️ 表中 VRAM 合計為兩張 24 GB 卡的名目總量,實際可用量還要扣掉 KV cache 與執行時開銷;本文不列價格,理由見下方「反向淘汰指標」。

📋 重點摘要(行動版精簡版)

最推薦:B 雙卡 pipeline 切分——這是 llama.cpp 的預設值(--split-mode layer),官方定位就是「最相容的多卡選擇」,而且能容忍慢速互連。
次選:A 單卡 + CPU offload——如果只差幾 GB,先降量化位元或縮短脈絡長度,通常比買第二張卡划算。
不推:C 在沒有 NVLink 的消費級雙卡上硬開 tensor 切分——vLLM 官方在「GPU 數不整除模型」的邊界情況註記中,建議無 NVLINK 節點改以 pipeline 取代 tensor。

🔬 tensor 切分 vs pipeline 切分:差在每個 token 要跨卡幾次

這是全篇最關鍵的機制。兩種切分法搬的都是資料,但搬的次數與時機完全不同。

pipeline 切分(llama.cpp 的 layer 模式) 是把「連續的一段層」分給每張卡(以 80 層模型、兩張同容量卡為例:第 0–39 層在 GPU 0、第 40–79 層在 GPU 1;官方預設是依記憶體按比例自動分配,不必然對半),而第 *l* 層的 KV cache 就住在擁有第 *l* 層的那張卡上。token 依序穿過管線,跨卡傳輸只發生在交界處。llama.cpp 官方對這個模式的描述是:把 GPU 之間的資料傳輸降到最低,但需要夠多的 token 才能發揮擴展性。

tensor 切分(llama.cpp 的 tensor 模式、vLLM 的 tensor parallelism) 則是把每一層都橫向切開,兩張卡各算一半,再把結果合起來。官方文件寫得很清楚:這種做法「每層要做多次跨 GPU 歸約」,因此受 GPU 互連速度的瓶頸嚴重得多。

把層數代進去就知道差多少。以 Qwen2.5-72B-Instruct 的官方 config.json 為例,num_hidden_layers 是 80、hidden_size 是 8192。同樣是產生一個 token:

pipeline 切分:兩張卡只有一個交界。官方的措辭是「把 GPU 之間的資料傳輸降到最低」;依「每張卡持有連續層段」的設計本文推算,每個 token 只需 1 次跨卡傳遞。
tensor 切分:官方寫的是「每層做多次跨 GPU 歸約」,80 層相乘,本文推算量級在上百次以上。

官方在這裡只把病因指到「受 GPU 互連速度的瓶頸嚴重得多」,沒有再往下拆。以下是本文推論:問題從來不是「PCIe 一秒能搬幾 GB」,而是「一個 token 之內要停下來等對方幾次」——每一次同步都要付出啟動與往返的固定成本,乘上 80 層之後,固定成本就成了主角。這也是為什麼 llama.cpp 官方會把兩者的定位寫成:pipeline 最大化批次吞吐,tensor 最小化延遲——前者適合你要餵很多 token,後者適合你要單一回應快,而後者的前提是互連要夠快。

如果你想先弄懂量化與 VRAM 的基本盤,站內這篇可以先看:本地 LLM 模型怎麼選?7B/70B、Q4/Q8 量化與 VRAM 一次搞懂。

pipeline 類與 tensor 類切分在 llama.cpp 狀態、跨卡通訊量與互連敏感度上的官方敘述比較表

📉 PCIe 頻寬瓶頸:x16 / x8 / x4 什麼時候才真的有差

先把數字擺出來。Intel 官方對 PCIe 世代的說明是:PCIe 3.0 為 8 GT/s、4.0 為 16 GT/s、5.0 為 32 GT/s,每一代的頻寬都是前一代的兩倍(Intel 該頁未言明單位基準;依 PCIe 規格,此為每通道傳輸率)。換算到 x16 插槽,PCIe 4.0 大約是每方向 32 GB/s、PCIe 5.0 約每方向 64 GB/s(GT/s 是編碼前的理論值,實際會再打折)。

現在拿它跟卡內記憶體比。NVIDIA 官方的《RTX Blackwell GPU 架構白皮書》列出,GeForce RTX 5090 的記憶體頻寬是 1,792 GB/s(512-bit 介面、GDDR7 28 Gbps)。把 NVIDIA 這個官方數字,跟上一段由 Intel 官方 GT/s 換算出的 PCIe 值並排看:1,792 GB/s 對上約 64 GB/s——兩者出自不同來源、量測對象也不同,但落差之大足以說明整件事的物理基礎:任何需要頻繁跨卡搬資料的設計,都在拿一條慢很多的路取代快路。

由此可以得出很實務的判斷:

pipeline 切分對 PCIe 頻寬非常不敏感。 llama.cpp 官方明言這個模式「可容忍 GPU 之間較慢的互連速度」;以 Qwen2.5-72B 的 hidden_size 8192、BF16 每值 2 位元組本文換算,交界處每個 token 傳的隱藏狀態約 16 KB,因此窄插槽的影響通常有限。
tensor 切分則相反。 llama.cpp 官方的疑難排解表裡,「多 GPU 反而比單 GPU 慢」這一項的處方就是:確認有沒有用到 NCCL、改用 --split-mode layer(通訊量比 tensor 少),或透過更多 PCIe 通道、或 NVLink(若有)來提高互連速度。
模型載入時間是另一回事。 把幾十 GB 權重灌進顯卡走的就是 PCIe,插槽越窄通常載入越久;本文推論:載入是一次性成本,與後續逐字生成的速度是兩件事。

至於 NVLink,消費級的門已經關上了。NVIDIA 官方規格表上,GeForce RTX 3090 的「NVIDIA NVLink(SLI-Ready)」欄位是 Yes;而 RTX 40 系列的同一欄位全數是 No,RTX 5090 官方規格表的同一欄位也同樣標示為 No。換句話說,現在買新卡組雙卡,跨卡通訊就只剩 PCIe 一條路。這正是 vLLM 官方那句補充的適用情境——它寫在「GPU 數不整除」的邊界情況註記裡:當節點上的 GPU 之間沒有 NVLINK 互連時(官方舉的例子是 L40S),採用 pipeline parallelism 取代 tensor parallelism,可以得到更高的吞吐與更低的通訊開銷。要留意 vLLM 對單機多卡的主線建議仍是 tensor parallelism,這句是針對特定條件的例外提醒。

想再往下挖「為什麼記憶體頻寬才是本地 LLM 的真瓶頸」,站內有專文:為什麼本地 LLM 跑不快?真瓶頸是記憶體頻寬,不是顯卡算力。

🔎 三條路線逐項深入解析

A 單卡 + CPU offload:先別急著買第二張

在加卡之前,值得先確認你到底差多少。以 720 億參數的模型粗估,4-bit 量化下光是權重就約 36 GB(720 億 × 0.5 位元組,純算術推估、非實際檔案大小,實際 4-bit GGUF 檔通常更大),再加上 KV cache 與執行時開銷,24 GB 單卡確實裝不下——這種情況多卡是合理的。

但如果你要跑的是 30B 級距、只超出幾 GB,先降一階量化或縮短 --ctx-size 通常更划算。llama.cpp 的 -ngl / --n-gpu-layers 可以控制放進 VRAM 的層數上限,溢出的層跑在 CPU 上;官方也明講這時「推論會慢很多」,所以這是妥協而非解法。它的價值在於:你可以先用它量出自己到底差多少,再決定要不要花錢。

B 雙卡 pipeline 切分:預設值就是最佳解的少數情況

llama.cpp 的 --split-mode 預設就是 layer,官方定位是「預設且最相容的多卡選擇」,適合「你需要比單卡更多的記憶體、且優先要快速 prefill」,並且能容忍 GPU 之間較慢的互連速度。實務上這一行就能跑起來:

llama-cli -m model.gguf

兩張卡容量不一樣時,用 -ts 調配比例,例如 -ts 3,1 代表 GPU 0 拿 75%、GPU 1 拿 25%(比例會被正規化,-ts 75,25 等價)。官方也提醒:若省略 --tensor-split,layer 模式會依記憶體自動按比例分配。

vLLM 這一側對應的是 --pipeline-parallel-size。官方文件在「GPU 數量無法整除模型」的邊界情況下建議:啟用 pipeline parallelism,因為它沿著層切分、支援不均等的切法,此時把 tensor_parallel_size 設為 1、pipeline_parallel_size 設為 GPU 數量。

C 雙卡 tensor 切分:限制多到需要逐條核對

llama.cpp 的 tensor 模式官方明確標示為 EXPERIMENTAL,而且附帶一串條件,前兩項不滿足會直接報錯:

必須開 Flash Attention。--flash-attn off(或 auto 解析成 off)是硬錯誤。
KV cache 不得量化,只能是 f32、f16 或 bf16,用了量化 KV 會直接報錯。
--fit 自動配置在此模式不支援,官方寫的是「你可能得自己手動設定 --ctx-size 才塞得下」;此項的官方症狀是啟動或 prefill 期間 CUDA OOM,而非啟動硬錯誤。
不是所有架構都支援。官方逐一點名了會失敗的清單:MoE/混合架構有 Grok、MPT、OLMoE、DeepSeek2 等;狀態空間 / RWKV 類列的是 Mamba、Mamba2(官方另註含上列的 Mamba-attention 混合模型);另有 Gemma-3n、BitNet、T5、OLMo2 等。報錯訊息是 LLAMA_SPLIT_MODE_TENSOR not implemented for architecture '...',部署前請直接對照官方清單。

跑起來之後還有兩個效能開關要注意。NCCL 是編譯期決定的(-DGGML_CUDA_NCCL=ON 為預設),但 NCCL 並不隨 CUDA 一起發佈,可能要自己裝;沒裝到的話會看到「NCCL is unavailable, multi GPU performance will be suboptimal」的一次性警告,效能就會比較差。另一個是 CUDA P2P,它讓 GPU 直接互傳而不繞系統記憶體,但是執行期 opt-in(設 GGML_CUDA_P2P 環境變數),而且官方警告:P2P 需要驅動支援(通常限工作站/資料中心卡),在某些主機板或 BIOS 設定下(例如開啟 IOMMU)可能造成當機或輸出損毀,不穩就把變數拿掉。

vLLM 這邊的對應寫法是 --tensor-parallel-size,官方在單機多卡的建議是把它設成 GPU 數量;其 tensor parallel 實作採用 Megatron-LM 的演算法,單機預設用 Python multiprocessing、多機才用 Ray。

⚠️ 反向淘汰指標:每條路線的「不該選」情境

各路線的「請別這樣做」

A 單卡 + CPU offload — 這些情況請別買帳

❌ 致命缺點:一旦有層落到 CPU,速度下降的幅度足以毀掉互動體驗;官方對這個狀態的措辭是「推論會慢很多」,把它當長期方案是自找麻煩。
❌ 使用場景排除:需要穩定服務他人、或要跑長脈絡的,別走這條。

B 雙卡 pipeline 切分 — 這些情況請別期待

❌ 致命缺點:官方把這個模式定位在「優先要快速 prefill」,並寫「需要夠多的 token 才能良好擴展」——本文據此推論:紅利在批次吞吐,單請求的逐字輸出速度不會明顯加速(官方另表示多卡「可能」改善 token generation,視切分模式與互連速度而定,並未作絕對敘述)。
❌ 使用場景排除:如果你的動機純粹是「想讓吐字更快」,加第二張卡走 pipeline 會讓你失望。

C 雙卡 tensor 切分 — 這些情況請別碰

❌ 致命缺點:在沒有 NVLink 的消費級雙卡上,每層多次跨卡歸約會被 PCIe 拖住,實際使用很可能比單卡還慢——llama.cpp 官方疑難排解表就把「多 GPU 比單 GPU 慢」列為已知症狀,並把互連速度指為病因。
❌ 使用場景排除:官方點名的 MoE/混合架構(Grok、MPT、OLMoE、DeepSeek2 等)與 Mamba、Mamba2 直接出局;需要量化 KV cache 省記憶體的也不行。

站長刻意不推的做法

常有人問能不能「插滿四張二手卡湊 VRAM」。站在客觀立場要說清楚兩件事:電力與相容性。NVIDIA 官方規格表上,GeForce RTX 3090 的 Graphics Card Power 是 350 W,兩張就是 700 W 的顯卡功耗;而單張 RTX 5090 的 Total Graphics Power 是 575 W,官方標示的 Required System Power(所需系統電源,註記為最低值)是 1000 W——單一張新旗艦就已經把系統電源需求推到 1000 W,雙卡還要再往上加。多卡系統要同時解決電源餘裕、機殼散熱與插槽通道分配,這些成本不會出現在顯卡的標價上。

另外,本文刻意不列台灣通路價格:多卡方案的報價波動大,寫死在文章裡反而誤導。請以你查詢當下的實際報價為準。

🏆 站長推薦:不同需求怎麼選

只差幾 GB、預算優先 → 走 A。先降量化階、縮短脈絡長度,把 -ngl 調到剛好塞滿 VRAM,量出真實缺口再談加卡。
模型明確放不進單卡、手上是 RTX 40/50 系列 → 走 B。這是消費級雙卡的預設答案,原因很單純:你沒有 NVLink,而 pipeline 正是為慢互連設計的模式。
手上剛好是兩張 RTX 3090、且真的裝了 NVLink 橋接器 → 可以試 C,但請把它當實驗:先確認模型架構在支援清單內、Flash Attention 有開、KV cache 沒量化,並且和 B 模式實測比較過再決定留哪個。
要服務多人、追求總吞吐 → 走 B 或 vLLM 的 pipeline 配置,並把注意力放在批次大小而不是切分模式。

💡 總結:選購眉角與常見誤區

把「顯卡數量」當成本地 LLM 的主要旋鈕,很容易第二張卡買回來才發現速度沒變、電費先漲。真正該問的順序其實是三個:模型放不放得下 → 放不下的話用哪種切分 → 這種切分吃不吃互連。這三題答完,要不要買第二張卡的答案自己就會浮出來。

最容易被忽略的細節是官方文件的狀態標記會隨版本變動。row 模式目前標的是 deprecated、tensor 模式目前標的是 experimental;照著舊教學設參數,很可能正在踩官方已經明講要避開的路。開新專案前花五分鐘看一次 docs/multi-gpu.md,比看十篇轉載教學有用。

必須誠實說明:本文屬深度查證型內容,所有參數與規格均引自 llama.cpp、vLLM、NVIDIA 與 Intel 官方文件,並非站長第一手實測。文中沒有任何自稱實測的秒數、溫度或 token/s 數字,就是這個原因。想更完整地評估硬體路線,站內的 2026 本地端 AI (Local LLM) 硬體指南:NPU 是智商稅嗎? 可以一起看。

❓ 常見問題

Q:雙顯卡跑大模型真的有用嗎?

有用,但用途是「裝得下」而不是「跑得快」。以本文推估的 4-bit 權重約 36 GB 計,兩張 24 GB 卡合計 48 GB 有機會讓 70B 級模型全上顯卡,避免溢出到系統記憶體(本文換算:未量化的 BF16 權重約需 144 GB=720 億 × 2 位元組,48 GB 並不夠)。至於速度,官方把 pipeline 模式定位在快速 prefill 與批次吞吐,並表示多卡「可能」改善 prefill 與/或 token 生成效能(視切分模式與互連速度而定);本文據此推論:單一請求的逐字生成速度不會因為多一張卡就減半。

Q:PCIe 頻寬不足會怎樣?

要看切分模式。pipeline 模式官方明言可容忍較慢的互連,交界處每個 token 的傳輸量以 KB 計(本文換算),窄插槽影響有限;tensor 模式每層都要跨卡歸約,這時 PCIe 通道數就會直接反映在速度上——llama.cpp 官方的處方之一就是增加 PCIe 通道或改用 NVLink。另外,模型載入時間通常會受插槽寬度影響,但那是一次性的(本文推論,官方文件未著墨)。

Q:tensor 切分跟 pipeline 切分到底差在哪?

pipeline 把不同層放在不同卡、token 依序穿過,跨卡傳輸最少;tensor 把每一層橫向切開、兩卡各算一半再歸約,通訊次數多很多。官方的一句話總結是:pipeline 最大化批次吞吐,tensor 最小化延遲。

Q:兩張卡可以型號不一樣嗎?

llama.cpp 支援用 --tensor-split 手動配比例來遷就不同容量的卡,例如 -ts 3,1。vLLM 官方則在 GPU 數無法整除模型時建議改用 pipeline parallelism,因為它支援不均等切分。另外一般而言,混搭時整體速度容易被較慢那張卡拖住——這一點官方文件並未著墨,屬經驗性推論,但規劃時值得先算進去。

Q:耗電與散熱要注意什麼?

先算電。NVIDIA 官方數字是 RTX 3090 每張 350 W、RTX 5090 每張 575 W,而 RTX 5090 單卡的 Required System Power 就標到 1000 W。把兩張卡的官方功耗加總後再抓餘裕,是估電源容量最起碼的做法,別用剛好夠的瓦數去賭瞬時峰值。

再看散熱。以下這段官方文件並未著墨,屬經驗性推論、非查證事實:兩張厚卡相鄰安裝時,下方那張的進風容易被上方卡擋住,溫度多半會高於單卡狀態;插槽間距不足時,渦輪(blower)式散熱器或垂直/延長線安裝是常見的緩解方向。要留意的是,溫度壓不住時通常表現為降頻而非當機——速度變差卻不會跳任何錯誤訊息,規劃散熱時值得把這點放進考量。

Q:現在買 RTX 3090 組 NVLink 雙卡還來得及嗎?

技術上可行——NVIDIA 官方規格表確認 RTX 3090 的 NVLink(SLI-Ready)為 Yes。但要注意 30 系列距現行的 50 系列已隔兩代,且 40 系列規格表的同欄位已全數為 No、RTX 5090 亦標示為 No,代表這條路沒有後續。若你打算三年後再升級,這筆投資的延續性需要自己評估。

🔗 延伸閱讀

📎 參考資料來源

📖 第一級|官方文件與規格:

llama.cpp — Using multiple GPUs with llama.cpp(docs/multi-gpu.md) — 2026-07-26 查證
vLLM — Parallelism and Scaling — 2026-07-26 查證
NVIDIA — GeForce RTX 3090 Family 官方規格 — 2026-07-26 查證
NVIDIA — GeForce Graphics Cards 官方規格比較表 — 2026-07-26 查證
NVIDIA — RTX Blackwell GPU Architecture 白皮書(v1.1) — 2026-07-26 查證
NVIDIA — GeForce RTX 4090 官方規格頁 — 2026-07-26 查證
Intel — What Are PCIe 4.0 and 5.0? — 2026-07-26 查證
Qwen2.5-72B-Instruct config.json(模型官方 repo) — 2026-07-26 查證

📅 本文查證戳記:2026-07-26 撰寫。官方文件的功能標記(deprecated/experimental)與硬體規格會隨版本更新,部署前請再確認一次對應版本的官方說明。