數位天堂

雙 2080 Ti 張量平行跑 27B：NVLink 到底差多少？

前兩篇我們用 Strata 在同一台機器上跑 125B 的 MoE 模型，這次換一個方向：用 vLLM 把 27B 的稠密模型「拆」到兩張 2080 Ti 上（張量平行，TP=2），接上我們自己的語音助理實際使用。

兩張卡之間沒有 NVLink，連 PCIe P2P 都不支援，原本擔心跑不起來或慢到不能用。結果不只跑得動，語音助理的首聲時間還接近雲端服務。這篇整理 NVFP4 與 FP8 的比較、MTP 該不該開，以及量測過程中意外抓到的一個 bug。後來 NVLink 橋接器到貨，我們也用同樣的設定補上了有／無 NVLink 的實測對照（◆07）。



■ 先講結論

沒有 NVLink、沒有 P2P 也能做張量平行：兩卡之間的資料改走系統記憶體中轉。NVFP4 開 MTP 時生成約 48 tok/s，讀約 2,000 token 的提示詞不到 2 秒。

4-bit（NVFP4）生成比 8-bit（FP8）快約 25%，但讀長提示詞反而慢約 10%：2080 Ti 沒有原生 FP4 運算，4-bit 權重要先解壓縮，一次讀大量文字時這個成本就浮現。

MTP 讓生成快約 30%，但語音助理我們選擇關掉：這個模型是混合架構，開 MTP 後前綴快取只能命中一半，首字時間從 0.85 秒拖到 2.28 秒。回答短的應用吃不到 MTP 的好處。

量測時抓到一個 bug，修正後多台同時使用快了 56%：不開 MTP 時，啟動器只為「1 個請求」建立 CUDA Graph；2、3 個請求同時進來就退回未優化模式。加一個啟動參數就修好了。

工具呼叫的那一輪，改一行程式快了 3.7 秒：工具清單只要少一項，提示詞開頭就不同，3,000 多 token 的快取全部失效。

NVLink 實測：讀長提示詞快約 35%，逐字生成只快 7–14%：裝上橋接器後兩卡之間約 47 GB/s。開 MTP 多人同時使用快 21–24%，但語音助理的首字只快 70 毫秒（0.46 → 0.39 秒）。以語音助理的用法，沒有 NVLink 也夠用。

網路上「開 MTP 單人 120 tok/s」很可能是合成測試的數字：vLLM 分支內建的參考基準會把輸出限定成重複的同一個字，MTP 每次都猜中；我們用它在同機量到 115.5，換成真實中文只剩約 65。另外在 2080 Ti 上 INT4 比 NVFP4 快約 19%，但工具呼叫測驗較差，我們沒有換（見文末補充）。

---

◆ 01　測試平台

項目	規格
主機板	MSI X470 GAMING PLUS MAX
CPU	AMD Ryzen 5 3500X（6C/6T）
RAM	32 GB DDR4
顯卡	RTX 2080 Ti 22G（改裝）× 2，◆02–◆06、◆08 為無 NVLink、PCIe P2P 不支援時的結果；◆07 加裝 NVLink 橋接器對照
PCIe 實際連結	3.0 x8 / x8（兩張都直連 CPU）
電源	1000 W 80 Plus 白金
系統	Ubuntu 26.04、驅動 595、CUDA 13
推論引擎	vLLM 的 2080 Ti 專用分支（weicj/vLLM-2080Ti-Definitive v0.2.2），TP=2
模型	Qwen3.8-27B：NVFP4（unsloth，23.4 GB）／FP8（官方，30.9 GB）

這個分支是社群針對 Turing（sm_75）改的 vLLM，作者的平台有 NVLink，文件寫「PCIe P2P 是基本需求」。我們的兩張卡 nvidia-smi topo -p2p 顯示 CNS（不支援），等於這次也順便量出「沒有 NVLink／P2P」的代價（橋接器到貨後的對照見 ◆07）。

Qwen3.8-27B 是混合架構（部分層是線性注意力），這點後面講前綴快取時會用到。

---

◆ 02　生成速度：NVFP4 vs FP8，MTP 開或關

組合	生成速度	4 個請求同時（總速度）
NVFP4＋MTP	47.9 tok/s	136 tok/s
NVFP4	35.9 tok/s	82 tok/s
FP8＋MTP	37.9 tok/s	108 tok/s
FP8	29.1 tok/s	80 tok/s

測試條件：顯存使用 90%、16K 上下文、最多 4 路；生成中文長文 512 token、溫度 0、關思考，三次結果一致。

「不開 MTP」那兩列的 4 路總速度是修正 bug 之前量的（見 ◆05），實際應該更高；開 MTP 的兩列不受影響。

MTP（多 token 預測）是讓模型一次預猜 4 個 token 再驗證。猜中率會隨內容變化，換一個題目我們測過 59 tok/s，所以 MTP 的數字請當成「大約」。

4-bit 比 8-bit 快，是因為逐字生成時瓶頸在讀權重，權重小一半就快。

---

◆ 03　讀長提示詞：8-bit 反而比較快



讀約 2,000 token 的中文提示詞（刻意不讓快取命中），FP8 要 1.76 秒、NVFP4 要 1.94 秒。

2080 Ti（Turing）沒有原生 FP4 運算，NVFP4 的權重要先解壓縮成可以算的格式。

逐字生成時，省下一半的權重讀取量勝過解壓縮成本；但一次處理幾千個 token 時，運算量變大，解壓縮的成本就浮現了。

結論：如果你的用途是「讀很長的文件、回答很短」，FP8 不一定比較慢；以生成為主的聊天，NVFP4 比較划算，而且省 7 GB 顯存。

---

◆ 04　語音助理為什麼不開 MTP



我們的語音助理每一輪要送約 3,800 token 給模型，其中約 3,600 是固定的系統提示詞和工具定義。這部分如果能命中前綴快取，每輪只需要讀新加的一兩百個字。

Qwen3.8-27B 是混合架構，線性注意力層沒辦法逐 token 存快取，只能每隔一段（約 1,600 token）存一份狀態快照，所以快取是「一格一格」命中的。

不開 MTP：命中 3,136 token（兩格），首字 0.85 秒。

開 MTP：只命中 1,616 token（一格），首字 2.28 秒。原因我們還沒查清楚，即使固定前綴已經超過兩格的長度，開 MTP 還是只命中一格。

語音助理的回答通常很短，而且第一句話生成完就開始念，所以影響首聲的是「首字時間＋第一句」。開 MTP 第一句大約省 0.2 秒，首字卻多 1.4 秒，淨虧。

MTP 適合的是長回答：寫文章、寫程式時，生成速度快 30% 的好處才顯現。

---

◆ 05　量測時抓到的 bug：多台同時使用慢了 36%



在正式設定（不開 MTP、32K × 3 路）下量多台同時使用時，發現一個奇怪的現象：2 台同時生成和 3 台同時生成，花的時間一模一樣（都是 12.2 秒）。

查啟動紀錄，CUDA Graph 只預先建立了「1 個請求」的版本（cudagraph_capture_sizes: [1]）。開 MTP 時則是 [5, 10, 15, 20]。

原因在啟動腳本：開 MTP 時會依並行數自動算出批次清單，不開 MTP 時則直接寫死成 [1]。2、3 個請求同時進來時，就退回沒有 CUDA Graph 的慢速模式。

修法：啟動時多帶一個參數，把批次清單補上 2、3（這個分支支援用 COMPILATION_CONFIG_JSON 覆寫）：

--set COMPILATION_CONFIG_JSON={"cudagraph_mode":"FULL_AND_PIECEWISE","cudagraph_capture_sizes":[1,2,3],"max_cudagraph_capture_size":3}

結果：單台不變（36 tok/s），2 台同時 42 → 67 tok/s、3 台同時 63 → 98 tok/s，顯存用量也沒變。

如果你也用這個分支、不開 MTP、又會有多個請求同時進來，建議檢查一下啟動紀錄裡的 capture sizes。批次清單要跟著你設定的最大並行數。

---

◆ 06　工具呼叫的那一輪：改一行程式快了 3.7 秒



另一個前綴快取的坑，出在語音助理的伺服器程式。

模型要呼叫工具（例如查天氣、設提醒）時，一輪對話會送兩次請求：第一次決定呼叫哪個工具，工具回傳後再送一次產生回答。

伺服器程式在第二次請求時，會從工具清單拿掉一個「直接回答」用的虛擬工具（避免模型重複呼叫）。

問題是 Qwen 的對話模板把工具定義放在提示詞最前面。工具清單只要少一項，從第 522 個 token 開始就不一樣，後面 3,000 多 token 的系統提示詞全部要重讀。

我們把這一行改成每次都帶同一份工具清單（檢查過不會造成重複呼叫的迴圈），第二次請求的快取命中從 522 變成 3,609 token，這一輪的首聲從 6.7 秒降到 3.0 秒。

心得：想讓前綴快取發揮作用，提示詞的前半段要「完全一樣」。日期時間這類每次會變的內容放最後面，工具清單不要依情況增減。

---

◆ 07　NVLink 實測：讀提示詞快 35%，生成只快 7–14%

NVLink 橋接器（2080 Ti 用、3 槽寬）到貨後，我們用和前面完全相同的設定與題目，把全部基準重跑一次。

nvidia-smi topo -m：兩卡之間由 PHB（經過 CPU）變成 NV2（兩條 NVLink），topo -p2p 讀寫都從 CNS 變成 OK。

實際量兩張卡互相複製資料：約 47 GB/s（雙向都是），接近兩條 NVLink 的理論值 51.6 GB/s；原本走 PCIe 3.0 x8，理論上限只有約 7.9 GB/s。

vLLM 的啟動紀錄也不一樣了：裝之前是「Custom allreduce is disabled because your platform lacks GPU P2P capability」，只能用 NCCL 經系統記憶體同步；裝之後改用 custom all-reduce，兩張卡直接透過 NVLink 交換資料。

項目	無 NVLink	有 NVLink	差距
讀提示詞（NVFP4）	1,027 tok/s（1.94 秒）	1,377 tok/s（1.45 秒）	+34%
讀提示詞（FP8）	1,135 tok/s（1.76 秒）	1,546 tok/s（1.29 秒）	+36%
生成（NVFP4）	35.9 tok/s	38.8 tok/s	+8%
生成（FP8）	29.1 tok/s	31.0 tok/s	+7%
生成＋MTP（NVFP4）	47.9 tok/s	54.5 tok/s	+14%
4 路同時＋MTP（NVFP4）	136 tok/s	170 tok/s	+24%
語音助理正式組態，3 台同時	98 tok/s	109 tok/s	+12%
語音助理首字時間	0.46 秒	0.39 秒	快 70 毫秒
生成時兩卡功耗	約 500 W	約 505 W	幾乎不變

讀長提示詞差最多：一次處理幾千個 token，兩卡之間要傳大量資料，瓶頸在頻寬，正是 NVLink 的強項。

逐字生成差得少：每產生一個 token 都要同步，但每次資料量很小，瓶頸在延遲，頻寬再大也幫不上太多。開 MTP 或多人同時使用時，一次要處理的 token 變多，差距才拉開到 14–24%。

語音助理幾乎感覺不出來：我們的語音助理每輪約 6,400 token 的提示詞裡，有 6,272 token 命中前綴快取，實際只需要新讀約 200 token，所以首字只快了 70 毫秒。

先前用作者公布的數據推估「生成差約 13%、讀長文差約 45%」，實測是 7–8% 和 34–36%，方向正確、幅度略小。裝上 NVLink 後，FP8 讀提示詞 1,546 tok/s，已經接近作者的 1,643 tok/s（作者用的是 4K 提示詞，不完全同條件）。

為了確認差距真的來自 NVLink，我們另外在同一台機器上關掉 P2P（NCCL_P2P_DISABLE＋停用 custom all-reduce）再量一次，結果和裝橋接器之前的實測幾乎一樣（3 台同時 98.1 對 97.8 tok/s），可見差距確實是 NVLink 造成的。

值不值得買？以語音助理、一般聊天這種「提示詞大多命中快取、回答短」的用法，沒有 NVLink 也完全夠用；如果常丟長文件給模型讀、或多人同時使用，NVLink 帶來的 20–35% 就很有感。要注意橋接器有槽距規格（我們用的是 3 槽寬），買之前先量兩張卡的間距。

---

◆ 08　功耗



生成期間兩張卡合計約 480–500 W，兩卡的功耗上限分別是 250／260 W，幾乎頂滿。整機牆插峰值（智慧插座量測）：前面的基準測試約 640 W；加裝 NVLink 後那一輪（含 16 人同時、開 MTP 等較重的負載）最高 658 W。兩卡生成時的功耗在裝 NVLink 前後幾乎一樣，多出來的十幾瓦主要來自負載不同。1000 W 白金電源還有不少餘裕。

---

◆ 09　架設時踩到的坑

建置腳本會自動改用第三方鏡像：這個分支的 build.sh 會依測速結果，自動把下載來源切到第三方鏡像站。我們改成只走官方 PyPI／GitHub，以免下載到來路不明的套件。

單一大檔的模型要開 overcommit：載入時出現記憶體配置失敗，要先 sudo sysctl -w vm.overcommit_memory=1（要開機自動生效請寫進 /etc/sysctl.d/）。

用一般使用者身分跑 systemd 服務，記得開 linger：vLLM 會用 /dev/shm 共享記憶體，Ubuntu 預設在使用者最後一個 SSH 連線登出時清掉它，結果 vLLM 在啟動途中崩潰。要 loginctl enable-linger <使用者>，而且開機自動啟動一定要實際重開機驗證一次。

Open WebUI 預設會讓模型先思考：寫一篇文章時，模型先思考了好幾千個 token 才開始寫。要關思考，在對話的控制選項把「推理程度」設成 none（vLLM 實測有效；在提示詞加 /no_think 對這個模型沒用）。

---

◆ 10　心得總結

和前兩篇的 125B MoE 相比，27B 稠密模型在同一台機器上的定位很不一樣：125B 生成快（約 70 tok/s）但讀長提示詞慢、RAM 吃緊；27B 用張量平行拆到兩張卡，提示詞讀取快、配合前綴快取，語音助理的首聲約 2.5–3 秒，接近雲端服務。

這次最大的收穫其實不是跑分，而是量測本身找到了問題：一個讓多台同時使用慢 36% 的 bug、一行讓快取失效的程式。沒有實際量測，這兩個問題可能一直都不會被發現。

至於 NVLink：它確實讓讀長提示詞快了三成多，但對「提示詞大多命中快取、回答很短」的語音助理幾乎沒有差別。要不要買，先看自己的用法卡在頻寬還是延遲。

◆ 補充　網路上「開 MTP 單人 120 tok/s」是怎麼來的？

文章寫完後，我們看到網路上一支同樣是「雙 2080 Ti＋NVLink」的實測影片：int4 模型開 MTP，單人生成 120 tok/s、FP8 也有 94.5 tok/s，是我們實測的兩倍。我們用同一台機器追查了一輪，原因有兩個。

1. 4-bit 格式不同：INT4 在 2080 Ti 上確實比 NVFP4 快
對方用的是 GPTQ 類的 int4（W4A16），我們原本用 NVFP4。我們下載了這個分支官方支援的 RedHatAI/Qwen3.8-27B-INT4 來比：

不開 MTP、單人生成：INT4 46.3 tok/s，NVFP4 38.6、FP8 30.9（對方 int4 49.4、FP8 32.7，差距只有 5–6%，屬於功耗上限、時脈的正常差異）。

讀提示詞：INT4 1,676 tok/s，NVFP4 1,366。

2080 Ti 沒有 FP4 硬體，NVFP4 要先轉換才能算；INT4 有成熟的核心可以直接用，所以在 Turing 上 INT4 生成快約 19%、讀提示詞快約 23%。

2. 開 MTP 的 120 tok/s，很可能是「合成測試」的數字
這個分支內建一套參考基準，條件正好是「4K 輸入／128 輸出」：輸入是 4,096 個重複的英文單字 " the"，輸出用參數強制限定只能是 " the"。程式說明自己也寫著「for synthetic throughput, not correctness」。這種輸出 MTP 每次都猜得中，速度自然被放大好幾倍。

開 MTP（K=3）單人	合成基準（只輸出 " the"）	真實中文內容	網路影片
INT4	115.5 tok/s	65.5 tok/s	120.0 tok/s
NVFP4	113.5 tok/s	61.2 tok/s	—
FP8	90.4 tok/s	52.4 tok/s	94.5 tok/s

影片沒有說明測試方法，以下是我們的推測：影片標示的條件同樣是「4K 輸入／128 輸出」，而用這套合成基準我們量到 INT4 115.5、FP8 90.4，和影片的 120、94.5 只差 4%；不開 MTP 時兩邊也只差 5–6%。所以很可能用的是同一套方法，但也不排除對方用了其他重複性高的題目。

換成真實中文內容（約 4K 中文段落、請模型寫中文文章），只剩 52–66 tok/s。MTP 依然有幫助（比不開快 40–70%；這裡輸出只有 128 token、K=3，和 ◆02 寫長文量到的約 30% 條件不同），但沒有合成數字那麼誇張。

不開 MTP 時，合成和真實內容的速度幾乎一樣（INT4 46.3 對 45.9）——生成速度本身和內容無關，被內容影響的是 MTP 的猜中率。

其他對得上的地方

影片裡「FP8 開 MTP、16 人同時」顯示停擺，我們也遇到：FP8 權重最大，加上 MTP 層後 KV 快取只剩約 51,000 token，16 路 × 4K 放不下，vLLM 直接拒絕啟動。

影片的「總吞吐」是把每人生成速度加總。16 個人各送 4K 提示詞時，大部分時間其實花在讀提示詞，用實際經過的時間算，總輸出只有約 35–48 tok/s。這種加總數字很依賴量法，看的時候要小心。

那我們的語音助理要不要換 INT4？我們決定不換。速度確實比較快，但用我們語音助理的正式提示詞做工具呼叫測驗（關思考，每題 20 次），INT4 的安全關鍵項合規率 73.8%，NVFP4 是 86.2%；最重要的「確認跌倒時要呼叫通報工具」，INT4 只有 11/20，NVFP4 是 18/20。同樣是 4-bit，不同的量化方式會讓模型行為不一樣，換之前一定要用自己的題目測過。

心得：看到別人的跑分比自己快很多時，先確認是不是同一種測法；尤其 MTP、推測解碼這類「靠猜」的加速，數字非常吃內容。

---

■ 參考連結

vLLM 2080 Ti 專用分支（本文使用的推論引擎）：https://github.com/weicj/vLLM-2080Ti-Definitive

vLLM 官方專案：https://github.com/vllm-project/vllm

模型 Qwen3.8-27B NVFP4（unsloth）：https://huggingface.co/unsloth/Qwen3.8-27B-NVFP4

模型 Qwen3.8-27B FP8（Qwen 官方）：https://huggingface.co/Qwen/Qwen3.8-27B-FP8

模型 Qwen3.8-27B INT4（RedHatAI，補充段落的對照）：https://huggingface.co/RedHatAI/Qwen3.8-27B-INT4

Open WebUI（文中的聊天介面）：https://github.com/open-webui/open-webui

nvtop（文中的顯卡監看工具）：https://github.com/Syllo/nvtop

Strata（前兩篇使用的推論引擎）：https://github.com/Niko1221/Strata

■ 同系列文章

Strata 實測：家用 2080 Ti 22G 跑 125B 的 Qwen3.8-Flash-Next：https://www.digiland.tw/viewtopic.php?id=3512

續篇：32 GB 記憶體＋雙 2080 Ti 22G 跑 Strata IQ3_S：https://www.digiland.tw/viewtopic.php?id=3516

（圖表與原始數據都是我們自行量測整理，歡迎討論或指正。）