單機夠用，為什麼還要多機並聯？
一台 Mac mini M4（10 核、16 GB 統一記憶體）跑中型 SwiftUI 工程，全量 Archive 往往落在四分鐘左右—— 對獨立開發者或「每天幾次 push」的小團隊，通常已經夠用。真正感到「機器不夠」的，多半是這三類工作流：
第一，多 scheme / 多 App 矩陣：同一 monorepo 要同時打主 App、Watch、Widget 與 Debug/Release 變體， 單機只能串行排隊，實際總耗時隨 target 數量線性拉長。 第二，共享編譯快取：希望把一台機上的 DerivedData 或 SPM 快取推給其他 Runner， 走公網 1 Gbps 獨享頻寬時，幾 GB 快取同步本身就要一分鐘級。 第三，分散式推理或渲染分片：多台機器要頻繁交換中間產物，乙太網延遲與頻寬會先於 CPU 成為上限。
這篇文章不討論「要不要買雲端 Mac」（那是定價與下單頁的問題），只回答一件事： 同節點多台 Mac mini 經 Thunderbolt 5 並聯後，機器間資料通路能快到什麼程度，對並行建置總耗時又意味著什麼？
硬體：3 × Mac mini M4 · 10 核 CPU · 16 GB 統一記憶體 · 256 GB NVMe（ZovCloud 日本節點，同機櫃）。
互聯：Thunderbolt 5 並聯服務（標稱 80 Gbps 物理通道）；對照鏈路為各機自帶 1 Gbps 獨享公網口互訪。
系統：macOS 15 Sequoia；工具：iperf3 3.17、dd + SMB、xcodebuild 16.4。
樣例工程：SwiftUI monorepo（約 14.2 萬行，含主 App + 2 個 Extension + 1 個 Watch target）。
Thunderbolt 5 並聯實際連的是什麼
先澄清一個常見誤解：TB5 並聯不是把三臺機器的 CPU 融合成一台「超級 Mac」， 也不是自動開啟某種透明的分散式編譯器。它提供的是同節點內機器之間的高速物理互聯通道—— 標稱頻寬 80 Gbps，遠高於每台機對外的 1 Gbps 獨享公網口。
在 ZovCloud 上，並聯服務僅限同一資料中心節點內的實例： 你不能把新加坡節點的機器和東京節點的機器用 TB5 串起來。 開通後，機房側完成 Thunderbolt 線纜與橋接配置，你在系統裡會看到額外的 Thunderbolt Bridge / 高速網橋介面， 隨後可在其上跑 TCP、掛載 SMB/NFS、或自建物件快取。
因此，TB5 的價值模型很清晰： CPU 仍按臺獨立排程，機間搬運資料的成本大幅下降。 若你的流水線本就不需要機器互相同步大體積產物，單機串行或「各跑各的、結果只上傳到公網」往往就夠——不必為並聯買單。
拓撲與就緒檢查：先確認鏈路真的起來
我們按「主控 + 兩台 Worker」三角拓撲開通：node-a 作排程與製品匯總，node-b / node-c 作並行建置節點。 付款開通 TB5 附加項後（工作台實例詳情也可追加），大約數分鐘內三臺機器的系統資訊裡出現 Thunderbolt 相關橋接介面。 就緒檢查建議固定做三步，避免後面測吞吐時才發現只是普通乙太網在跑。
-
01
確認橋接介面存在
在每台機執行
ifconfig或「系統設定 → 網路」，應能看到 Thunderbolt Bridge（或機房側命名的高速橋介面），並拿到同網段私有 IP。 -
02
雙向 ping 與 MTU 核對
三臺兩兩
ping -c 20，RTT 應穩定在亞毫秒到約 1 ms 內；若 RTT 落到數毫秒且抖動大，多半仍走了公網路徑，需核對路由表。 -
03
固定測試用 IP，禁用錯誤預設路由
把建置腳本裡的同步位址寫成 TB 網段 IP，而不是公網 IPv4，防止
rsync/ SMB 悄悄繞回 1 Gbps 出口。
若只看到 USB4 / Thunderbolt 裝置樹而無可用 IP，先在工作台確認並聯狀態為「已生效」，再重啟網路堆疊或按幫助中心工單回饋。 並聯僅同節點有效——跨區域實例請繼續用公網或物件儲存同步。
吞吐實測：TB5 對比 1 Gbps 公網互訪
第一組測試用 iperf3 測 TCP 單向吞吐。對照路徑是三臺機器各自的公網 IPv4 互訪（仍走機房內交換，但受 1 Gbps 獨享口上限約束）； 實驗路徑走 Thunderbolt Bridge 私有網段。每組跑 60 秒、重複三次取中位數。
| 路徑 | TCP 吞吐（中位） | RTT（中位） | 備註 |
|---|---|---|---|
| 公網 IPv4 互訪 | 0.94 Gbps | 0.6–1.2 ms | 受 1 Gbps 獨享口封頂 |
| Thunderbolt Bridge | 58.4 Gbps | < 0.3 ms | iperf3 單流，CPU 未打滿 |
| TB5 雙向同時 | 上行 51.2 / 下行 49.8 Gbps | < 0.4 ms | 雙流時略降，仍遠高於 GbE |
使用者態 TCP 很難吃滿理論 80 Gbps，這與協定開銷、單流排程和磁碟側無關——我們當時測的是記憶體到記憶體。 對工程實踐而言，「比 1 Gbps 快一到兩個數量級」已經足夠改變同步策略： 過去需要「只傳增量、壓縮再傳」的幾 GB 快取，現在可以直接整包推，腳本反而更簡單。
大檔案與共享快取：總耗時差在哪裡
吞吐數字好看，不代表建置流水線一定變快——還要看你是否真的在搬大塊資料。
我們用一份 8.4 GB 的 DerivedData 快照（含 Module Cache 與若干中間產物）做 SMB 同步，
以及一份 2.1 GB 的 .xcarchive 回傳到主控機。
| 任務 | 經 1 Gbps 互訪 | 經 TB5 橋 | 總耗時縮短 |
|---|---|---|---|
| 8.4 GB DerivedData → Worker | 72 s | 1.5 s | 約 48× |
| 2.1 GB xcarchive → 主控 | 19 s | 0.4 s | 約 47× |
| SPM 快取目錄 1.6 GB 雙向對齊 | 28 s | 0.6 s | 約 46× |
結論直白：凡是「多機之間要搬 GB 級產物」的步驟，TB5 幾乎把同步時間壓到可忽略。
若流水線每台機器各自 git clone、各自下載依賴、各自上傳到物件儲存，中間幾乎不互訪——
那你看到的提速會接近零，錢花在並聯上就虧了。
並行 Archive：三臺機器能把總耗時壓到多少
第二組測試更貼近 CI：同一 commit，三個 scheme（主 App Release、Widget Release、Watch Release）分別在三臺 Worker 上並行
xcodebuild archive；對照是同一台機器上串行打完三個 Archive。
主控負責分發原始碼快照（經 TB5）、收集產物並做簡單校驗。每組重複三次取中位。
並行總耗時 4 分 18 秒，接近「最慢那個 scheme」的單機耗時（主 App Archive 約 4 分 05 秒）， 外加約 9 秒的原始碼/快取分發與產物回傳——若改走 1 Gbps，僅同步階段就會多出一分鐘以上， 三機並行的優勢會被網路吃掉大半。
需要強調：加速比不是線性的「三臺就三倍」。 scheme 耗時不均、憑證解鎖、SPM 解析競態，都會讓總耗時停在最慢那條腿上。 TB5 的貢獻是把「分發與匯總」從分鐘級壓到秒級，讓並行排程本身值得做； CPU 側提速來自「多台實體機同時算」，不是雷電線纜憑空加速單核 Swift 編譯。
把同一個 target 強行拆到多機做「分散式單次編譯」在 Xcode 工具鏈上幾乎不現實，也不是 TB5 並聯的設計目標。 正確用法是按 scheme / App / 平台矩陣切任務，每台機器完整跑一條獨立建置，用高速互聯降低排程與製品搬運成本。
踩坑備忘：我們實際卡住的四件事
1. 同步腳本寫錯網卡。
第一輪 iperf「只有 900 Mbps」時，排除發現腳本用了公網 IP。改成 Bridge 網段後立刻跳到 50 Gbps+。
建議在 CI 環境變數裡顯式宣告 CLUSTER_IFACE 與 PEER_TB_IP。
2. SMB 預設簽章拖吞吐。
macOS 預設 SMB 在高速鏈路上會先打滿 CPU 再碰到頻寬牆。短時壓測可調簽章策略；生產環境權衡安全與速度，
或改用 rsync over SSH（同樣綁 TB IP）做快取目錄同步。
3. 鑰匙串與簽名環境要每台獨立準備。 並聯不解憑證問題。三臺 Worker 都需匯入 Distribution 憑證並配置 unlock； 我們用同一套自動化腳本，但金鑰仍分機存放，避免「共享鑰匙串目錄」帶來的並行損壞。
4. 磁碟比網路先到瓶頸。 256 GB 系統碟在三臺同時寫 DerivedData 時，偶發 I/O wait 抬升。 若 monorepo 很大、夜間批次又多，優先考慮 SSD +1TB / +2TB 擴容，再談加更多並聯節點—— 否則 TB5 再快，本地碟寫不動也白搭。
什麼時候值得加購 TB5，什麼時候不用
把實測收成一張決策表，避免「看到 80 Gbps 就想開通」：
| 你的現狀 | 建議 | TB5 是否關鍵 |
|---|---|---|
| 單 App，每天幾次建置 | 單臺獨享節點即可 | 通常不需要 |
| 多 scheme / 多 App 夜間矩陣 | 2–3 臺並行 + 主控匯總 | 強烈建議（同步開銷敏感） |
| 共享 DerivedData / SPM 快取農場 | 一台快取源 + 多 Worker 拉取 | 建議（GB 級同步） |
| 各機獨立建置，只上傳物件儲存 | 多台各自掛 Runner | 可選，收益有限 |
| 跨節點（如東京 + 新加坡）協作 | 物件儲存 / git，不靠 TB5 | 不可用（僅同節點） |
價格層面：ZovCloud 基礎節點按天 $19.8、按週 $53.5、按月 $99.1、按季 $269.6； Thunderbolt 5 並聯附加項按天 $1.8、按週 $4.9、按月 $9.1、按季 $24.8。 三臺按月常駐再加並聯，適合「建置佇列已經明確被同步與串行拖住」的團隊； 發版週臨時加機，也可以按天開並聯，測完再關掉——無需買機房裡的銅纜與交換機。
從「測得快」到「日常能用」：雲端獨享叢集怎麼落地
辦公室自建三臺 Mac mini 並聯，理論上也能跑出相近吞吐，但你要自己處理上架、線纜、斷電、 固定公網 IP、憑證輪換與夜間無人值守。對多數行動團隊，這些運維成本才是真正的門檻—— 不是「會不會敲 iperf3」。
公有雲 Linux 虛擬機組網再快，也過不了 Apple 工具鏈這一關：沒有完整 macOS，就沒有合法的
xcodebuild / codesign / TestFlight 鏈路。
共享 macOS 雲主機若存在超售，並行建置時記憶體與磁碟抖動會把「理論並行」打回原形。
ZovCloud 的路徑是：每台仍是獨享物理 Mac mini M4（10 核、16 GB、1 Gbps 獨享頻寬、完整管理員權限）， 需要機間高速通路時，在同節點勾選 Thunderbolt 5 並聯，走 80 Gbps 物理通道； 付款後 1–5 分鐘開通，節點可選新加坡、日本、韓國、中國香港、美國東部。 瀏覽器 VNC、SSH 與第三方 VNC 用戶端均可連線；建置腳本與自託管 Runner 的掛法， 與單機場景相同，只是多了一組 Bridge IP 用於同步。
-
01
先定並行切分策略
按 App / scheme / 平台切開任務，確認每台機器有獨立可跑的 Archive 目標，再決定開幾台。
- 02
-
03
綁 Bridge IP，再掛 Runner
就緒檢查通過後，把快取同步與產物回傳改走 TB 網段；公網口只負責 git、物件儲存與對外發布。
Thunderbolt 5 並聯解決的是「多台真實 Mac 之間，資料怎麼搬得夠快」， 不是「一台機器假裝成三臺」。當你的總耗時已經被矩陣建置和快取同步拖住， 同節點獨享叢集 + 80 Gbps 互聯，往往比繼續加長單機排隊更划算； 若你還在單 App、低頻發版階段，把預算留在一台穩定的 M4 獨享節點上，通常是更清醒的選擇。