Thunderbolt 5 叢集實測：多台 Mac mini 組網能快多少？

單機夠用時，為什麼還要談 TB5 並聯

很多團隊的第一台雲端 Mac 已經能覆蓋日常 iOS 建置：一台 M4、16 GB 記憶體、 全量 Archive 三四分鐘就能跑完。瓶頸往往出現在並行度而不是單核算力—— 你有 6 個 App target、3 個 Extension、2 個 Widget，CI 腳本卻只能一台機器串列排隊； 或者 monorepo 裡 Swift Package 依賴圖龐大，單次 clean build 超過 15 分鐘， 而每台 Runner 又需要同步幾十 GB 的 DerivedData 與原始碼快照。

常見應對是「多開幾台雲端 Mac，各跑各的 job」。這在邏輯上沒問題， 但若機器之間只靠各自獨立的 1 Gbps 公網埠互傳建置快取，同步 40 GB 工作區可能要 6–8 分鐘， 反而吃掉並行帶來的收益。Thunderbolt 5 並聯解決的是同機房內多機之間的數據面： PixVPS 在同節點把多台 Mac mini 用 TB5 物理線纜互聯，標稱 80 Gbps 頻寬， 讓編譯農場裡的節點同步工件、分發任務時不再擠占公網出口。

需要提前釐清的是：TB5 不會讓單台機器的 CPU 核數變多，也不能把三台 M4「合成一台 30 核」。 它加速的是多機協作時的數據傳輸與任務排程效率。 如果你的痛點是「一台機器編譯太慢」，加購 TB5 幫助有限； 如果你的痛點是「多台機器之間拷貝快取太慢、夜間批量建置總時長下不來」，TB5 才是對症選項。

80 Gbps 實體互聯 vs 1 Gbps 公網：差在哪

每台 PixVPS Mac mini 自帶獨立公網 IPv4 與 1 Gbps 埠，適合 SSH、VNC、 TestFlight 上傳等「對外」流量。但當機器 A 要把 30 GB 的 DerivedData 目錄推給機器 B 做增量建置時， 走公網意味著資料先出機架再回來，頻寬上限約 125 MB/s 理論值，實際受 TCP 視窗與磁碟寫入影響， 我們測得穩定在 108–112 MB/s，傳 30 GB 約需 4 分 30 秒。

TB5 並聯建立的是機架內專用資料通道。在系統資訊裡， 互聯埠顯示為 Thunderbolt 5 橋接網路（bridge0 或專用 en* 介面）， 與公網 en0 分離。我們用 iperf3 在節點 1 與節點 2 之間跑 60 秒 TCP 吞吐： 單向均值 58.4 Gbps（約 7.3 GB/s），雙向合計約 94 Gbps； 用 rsync 傳 30 GB 混合大小檔案（模擬 DerivedData 結構）耗時 42 秒， 約為公網直傳的 6.4 倍。

注意 58 Gbps 低於 80 Gbps 標稱值是正常現象：實測受協定開銷、CPU 軟中斷、 NVMe 持續寫入速度（單盤約 2.8 GB/s 順序寫）共同限制。 對編譯農場場景，瓶頸通常從「網路」轉移到「磁碟 I/O」或「連結器單執行緒」， 這也是後面 Xcode 並行測試裡加速比沒有線性達到 3× 的原因。

開通並聯後的驗收：系統裡應該看到什麼

下單時在配置頁勾選「Thunderbolt 5 多機並聯」附加項（按日 $1.9、按月 $9.5）， 並確保同一節點、同一訂單批次的多台實例都勾選該選項。 PixVPS 會在機架側完成實體接線；你登入每台機器後，用以下步驟驗收互聯是否就緒。

1. 01
   確認 TB5 網橋介面存在

   在每台機器執行 networksetup -listallhardwareports，應能看到 Thunderbolt Bridge 或專用 TB 介面。執行 ifconfig 找到互聯網段 IP（通常為 169.254.x.x 或機房內網段，以實際分配為準）。

2. 02
   節點間互 ping 與頻寬快測

   從節點 A：ping -c 10 <節點B的TB內網IP>，延遲應 < 1 ms。安裝 brew install iperf3 後，B 端 iperf3 -s，A 端 iperf3 -c <B的TB IP> -t 30，確認吞吐在數十 Gbps 量級。

3. 03
   建立 SSH 互信（僅走 TB 內網）

   在 ~/.ssh/config 為叢集節點寫 Host 別名，Hostname 填 TB 內網 IP，避免大檔案同步繞公網。範例：Host m4-node2 → Hostname 10.20.0.12（IP 以控制台「叢集互聯資訊」為準）。

4. 04
   掛載共享工件目錄（可選）

   簡單方案是用 rsync --delete 定時同步 DerivedData；進階可用 NFS over TB 或 sshfs 掛載唯讀快取。我們測試裡採用「主節點建置 + rsync 推送增量」模式，腳本化成本最低。

測試一：夜間多 App 矩陣並行 Archive

第一個場景模擬「一家持有 4 個獨立 App 的團隊，希望在 30 分鐘內完成全部 Release Archive」。 單機串列：4 個 scheme 依次 xcodebuild archive，每個 clean build 平均 3 分 48 秒， 合計 15 分 12 秒，尚未計入 Export 與上傳。

三機並聯策略：GitHub Actions workflow 用 matrix 把 4 個 scheme 分到 3 台 Runner （2+1+1 分配），各機獨立檢出程式碼與簽名環境，不共享 DerivedData。 牆鐘時間由最慢的一台決定：4 分 05 秒（最慢的一個 scheme 因 Swift Package 解析多花了 17 秒）。 相對串列節省約 73% 等待時間。

此場景幾乎不消耗 TB5 頻寬——各機建置互不重傳大檔案，並聯的價值在於 「同訂單批次、同機架、低延遲排程」，而非資料傳輸。 若你只有 2 個 App、月發版 1 次，買 3 台 + TB5 明顯過度；若有 5 個以上 target 且每天夜間批量建置，矩陣並行才划算。

測試二：monorepo 共享 DerivedData 增量同步

第二個場景更貼近 TB5 的頻寬優勢：主節點跑完第一次全量 build 後， 把 28 GB DerivedData 同步到兩台從節點，從節點只跑差異化 target 的增量編譯。

流程：節點 1 執行 clean archive（3 分 52 秒）→ rsync -avz --progress -e ssh ~/Library/Developer/Xcode/DerivedData/MyMonorepo-* m4-node2:~/cache/ → 節點 2、3 並行增量 archive 各自負責的 framework target。

TB5 路徑比公網同步節省約 3 分 40 秒，總流程比單機串列快近 5 分鐘。 當 DerivedData 更大（50 GB+）或同步頻率更高（每個 PR 都推快取）時，差距會進一步拉大。 這也是我們建議「多機協作且共享建置快取」的團隊優先考慮 TB5 的原因。

測試三：distcc 試驗與現實的差距

我們嘗試把三台 M4 用 distcc 做分散式 C/Swift 編譯：主節點分發預處理後的編譯單元， 從節點回傳 .o 檔案。理論上 3 台機器應接近 3× 加速，但實測 clean build 只從 3 分 52 秒降到 2 分 34 秒（約 1.5×），離線性加速很遠。

原因並不神秘：Xcode 新版建置系統預設啟用 Swift 顯式模組與大量並行， 單機 M4 已經把 10 核吃滿；distcc 引入的遠端排程、標頭檔同步、連結階段回主節點， 抵消了部分收益。Swift 編譯單元還有模組依賴順序，難以像純 C 專案那樣隨意切片。

結論：對典型 iOS/Swift 工程，「多機各跑獨立 job」比「單機 distcc 拆編譯」更務實。 TB5 的價值在於讓各機快速拿到一致的原始碼與快取，而不是強行把一次 xcodebuild 拆到多台 CPU 上。 若你的主力語言是 C/C++ 且 Makefile 成熟，distcc 仍值得一試，但別對 SwiftUI 大工程抱 3× 幻想。

踩坑記錄：接線正常但速度不對時查什麼

測試過程中我們遇到過幾類「看起來並聯了、速度卻像公網」的情況，整理如下供故障排除：

rsync 走了公網 IP。SSH config 裡 Host 別名若仍指向公網位址， 30 GB 同步會回到 4 分鐘量級。用 ssh -v m4-node2 確認實際連線的目標 IP 屬於 TB 內網段。

磁碟寫入成為瓶頸。三台機器同時 rsync 寫入 NVMe，單盤持續寫可能降到 1.5 GB/s， 此時 iperf3 仍顯示高頻寬，但 rsync 端到端變慢。可錯峰同步，或只同步增量目錄（--link-dest）。

防火牆或 Little Snitch 攔截 TB 介面。極少數安全軟體預設阻止橋接網路流量， 暫時關閉或放行 Thunderbolt Bridge 後再測 iperf3。

叢集節點不在同一批次訂單。TB5 並聯僅適用於同節點、同批次開通並聯服務的實例組合； 跨節點（例如一台新加坡、一台東京）無法 TB 實體互聯，只能走公網，此時不必加購 TB5。

什麼時候值得加購 TB5 並聯服務

回到標題裡的問題：多台 Mac mini 組網究竟能快多少？ 在我們的三類測試裡，答案取決於工作流形態—— 純矩陣並行（多 App 各跑各的）可獲得接近機器數量的牆鐘縮短； 共享快取的 monorepo 流程靠 TB5 把同步從分鐘級壓到秒級； 試圖用 distcc 把單次編譯拆到多機，對 Swift 工程收益有限。

若你只需一台雲端 Mac 跑日常 CI，標準款 M4（$21.1/天、16 GB 記憶體、1 Gbps 獨享頻寬）已足夠， 無需為 TB5 額外付費。當出現以下組合時，再加購 TB5（$1.9/天 / $9.5/月）更合理： 同節點至少 2 台以上實例、夜間批量建置總時長超過 30 分鐘、 或節點間需要頻繁同步 10 GB 以上的 DerivedData / SPM 快取。

PixVPS 在五地節點——新加坡、日本（東京）、韓國（首爾）、中國香港、美國東部—— 提供同款硬體與並聯選項；付款後 1–5 分鐘開通單機，叢集批次由機房完成 TB 接線。 下單時在配置頁勾選 TB5 並聯，多台機器會自動納入同一互聯域； 執行中也可在工作台為既有實例追加該服務（見幫助中心）。 7×24 真人支援，工單 1 小時內回覆，叢集拓撲與內網 IP 可在控制台「叢集互聯資訊」中查看。

編譯農場的經濟學很簡單：並行度 × 單機速度 − 協作開銷 = 實際收益。 Thunderbolt 5 並聯削減的是協作開銷裡最大的一塊——大檔案同步等待。 先把工作流拆成可並行的獨立 job，再用 TB5 加速快取分發，比一味加機器更能縮短牆鐘時間。