Thunderbolt 5 並聯究竟是什麼？
在 ZilCloud 的設定頁選購附加項目時，有一個選項叫「Thunderbolt 5 並聯服務」，按天只要加 $1.4，按月加 $8.9。我第一次看到時的反應是：這東西到底能做什麼？
簡單說：Thunderbolt 5（以下簡稱 TB5）是 Apple 在 Mac mini M4 上導入的新介面標準，理論頻寬為 120 Gbps（PCIe 通道），用於裝置互聯時可達 80 Gbps 雙向頻寬，相當於 10 GB/s 的資料吞吐——比過去的 TB4（40 Gbps）直接翻了一倍。而 ZilCloud 的 TB5 並聯服務，就是將兩台或多台雲端 Mac mini M4 節點用實體 TB5 線纜直連，形成一個對作業系統透明的高速區域網路。
從工程角度來看，這不是單純把兩台機器用網路線接在一起。TB5 並聯走的是 PCIe 通道，延遲遠低於乙太網路，理論上可實現接近本機 NVMe 讀寫速度的跨機記憶體映射（透過 Remote Direct Memory Access 機制）。這對編譯叢集、AI 推理叢集、影片渲染池都有實質意義。
本次測試租用了 ZilCloud 新加坡節點的 2 台 Mac mini M4（各配 16 GB 統一記憶體 + 256 GB SSD，1 Gbps 獨享公網頻寬），並開啟 Thunderbolt 5 並聯服務，由 ZilCloud 完成實體接線與系統辨識確認後交付。
環境建置：開通與辨識 TB5 介面
在 ZilCloud 主控台選好 2 台節點並開啟 TB5 並聯附加項目後，約 3 分鐘內兩台機器的狀態就變為「已就緒」。透過 SSH 登入第一台機器後，執行以下指令確認 TB5 介面辨識情況：
system_profiler SPThunderboltDataType輸出中可以看到兩個 TB5 連接埠均已被系統辨識，並且在「Connected」狀態下偵測到對端裝置（即第二台 Mac mini）。接著在 macOS 網路偏好設定裡，系統自動將 TB5 連結呈現為一個「Thunderbolt Bridge」介面，分配了 169.254.x.x 的本地鏈路位址，無需手動設定。
手動設定靜態 IP（建議）
雖然自動 APIPA 位址已可使用，但為了後續編譯任務與腳本的穩定性，建議手動設定靜態 IP。在兩台機器的 Thunderbolt Bridge 介面上分別設定：
# 節點 A
sudo networksetup -setmanual "Thunderbolt Bridge" 192.168.100.1 255.255.255.0
# 節點 B
sudo networksetup -setmanual "Thunderbolt Bridge" 192.168.100.2 255.255.255.0設定完成後，用 ping -c 4 192.168.100.2 測試連通性，平均 RTT 約為 0.08 ms——這個延遲數字，比同機房的 10 Gbps 乙太網路還要低。
頻寬實測：iperf3 與 fio 數據
建置好基礎網路後，第一件事自然是跑 iperf3 測頻寬。
iperf3 TCP 測試
# 節點 B 作為伺服端
iperf3 -s
# 節點 A 作為用戶端，8 併發流
iperf3 -c 192.168.100.2 -P 8 -t 30測試結果如下：
| 測試場景 | 協定 | 併發流 | 實測吞吐 | 達到理論上限 |
|---|---|---|---|---|
| 單向 TCP | TCP | 1 流 | 38.2 Gbps | 48% |
| 多流 TCP | TCP | 8 流 | 72.4 Gbps | 90% |
| 單向 UDP | UDP | 1 流 | 79.1 Gbps | 99% |
| 雙向同時 | TCP | 4+4 流 | 61.8 + 59.3 Gbps | ~76% |
UDP 單流能跑到 79.1 Gbps，非常接近 80 Gbps 的標稱值。TCP 多流在 8 併發時達到 72.4 Gbps，對於實際工作負載來說已經是極其充裕的頻寬了。雙向併發時，兩個方向各能穩定在 60+ Gbps，合計超過 120 Gbps——這正好與 TB5 的 PCIe 通道理論值吻合。
fio 跨機檔案傳輸測試
純 iperf3 只測網路層，實際使用中更關心檔案系統層面的傳輸速度。使用 macOS 原生的 SMB 共享與 NFS 掛載分別測試：
| 協定 | 讀取速度 | 寫入速度 | 小檔案 IOPS (4K) |
|---|---|---|---|
| SMB（macOS 預設） | 4.8 GB/s | 3.9 GB/s | 42,000 |
| NFS v4.2 | 6.2 GB/s | 5.7 GB/s | 67,000 |
| rsync（壓縮關閉） | 5.1 GB/s | — | — |
NFS v4.2 在循序讀取上能達到 6.2 GB/s，已經超過單塊 NVMe SSD 的本機讀取速度——這意味著透過 TB5 網路讀取遠端機器的資料，甚至比從本機 SSD 讀取還要快（因為 M4 的記憶體頻寬更高，透過 TB5 可以直接存取對端的統一記憶體緩衝區）。
建議使用 NFS v4.2 而非 SMB 進行大檔案或高頻小檔案的跨機共享，IOPS 提升約 59%，延遲更低。如果是對延遲極敏感的場景（如 Xcode 模擬器狀態同步），可以考慮直接用 SSH + FUSE 掛載。
Xcode 分散式編譯實測
對於 iOS / macOS 開發者來說，最直接的問題是：TB5 叢集能讓 Xcode 編譯快多少？
我們使用了一個真實的 iOS 專案（一個約有 180 個模組的大型 SwiftUI 應用程式，冷編譯大約需要 14 分鐘）作為測試對象。使用 distcc 配合 pump mode 將編譯任務分發到兩台機器：
# 安裝 distcc
brew install distcc
# 節點 B 作為編譯守護程序伺服端
distccd --allow 192.168.100.0/24 --log-stderr --verbose
# 節點 A 上設定 distcc 主機清單
export DISTCC_HOSTS="192.168.100.2/8 localhost/4"
# 使用 pump 模式發起編譯
pump xcodebuild -project MyApp.xcodeproj -scheme MyApp -configuration Release build| 編譯方式 | 總耗時 | CPU 峰值利用率 | 提速比 |
|---|---|---|---|
| 單機（節點 A 本機） | 14 分 12 秒 | 87% | 基準 |
| 單機（節點 B 本機） | 14 分 08 秒 | 89% | 基準 |
| 2 機 TB5 分散式（distcc） | 8 分 47 秒 | 91% × 2 | ×1.62 |
| 2 機 TB5（增量編譯） | 1 分 38 秒 | 76% × 2 | ×2.3+ |
冷編譯從 14 分鐘縮短到 8 分 47 秒，提速約 1.62 倍。提速沒有達到理想中的 2 倍，原因在於 Swift 前端編譯（語意分析階段）目前還不支援分散式——這部分只能跑在本機，佔了整體編譯時間的約 35%。純 C/C++/Obj-C 程式碼的分散式提速效果更明顯，實測可達 1.9 倍。
增量編譯的提速效果則更為顯著：因為中間產物的跨機共享極快（TB5 傳輸速度遠超網路 I/O 等待），整體增量編譯從約 3 分 46 秒縮短到 1 分 38 秒，在日常開發循環中節省的時間非常可觀。
大模型推理：多機並聯加速 llama.cpp
除了編譯場景，TB5 叢集對於 AI 推理同樣有巨大價值。M4 的 Apple Neural Engine 有 38 TOPS 算力，單機推理已經夠用；但對於需要同時處理多個併發請求的 AI 服務端場景，兩機並聯可以有效提升吞吐。
我們使用 llama.cpp 的 RPC 後端（從 build 0.1.x 開始支援多機負載平衡）測試了 Llama 3.1 8B（Q4_K_M 量化）的推理吞吐：
# 節點 B 啟動 llama-rpc-server
./llama-rpc-server --host 192.168.100.2 --port 50052 -ngl 99
# 節點 A 作為主控，指定兩台機器
./llama-cli \
--rpc 192.168.100.2:50052 \
-m ./Llama-3.1-8B-Q4_K_M.gguf \
-ngl 99 --parallel 8 -p "Write a detailed technical analysis of..."| 場景 | tokens/s（推理） | 併發請求數 | 記憶體佔用 |
|---|---|---|---|
| 單機（節點 A） | 48.2 tok/s | 4 併發 | 12.3 GB |
| 2 機 TB5 RPC | 89.7 tok/s | 8 併發 | 11.8 GB × 2 |
| 2 機 TB5（Llama 3.1 70B Q4） | 22.4 tok/s | 2 併發 | ~30 GB 分布 |
8B 模型的推理吞吐從單機 48.2 tok/s 提升到兩機並聯的 89.7 tok/s，接近線性擴展。更重要的是，TB5 的超低延遲使得多機間的 KV-Cache 同步開銷可忽略不計——這是傳統乙太網路方案做不到的。
兩機並聯還解鎖了另一個單機無法完成的任務：執行 Llama 3.1 70B Q4 量化版本。該模型需要約 40 GB 記憶體，單台 16 GB 機器無法獨立載入；透過 TB5 RPC 將模型層分布到兩台機器，成功實現本機推理，吞吐約 22 tok/s，在無 GPU 的前提下已經相當實用。
llama.cpp 的 RPC 後端在使用 Apple Neural Engine（Metal 加速）時，跨機層分片偶爾會出現記憶體對齊問題導致推理卡住（約 2% 機率）。暫時解法是在 RPC 模式下降低 -ngl 值到 80，讓部分層回退到 CPU 計算，可消除這個問題。官方 issue 已有 PR 在合併流程中，預計下一個版本修復。
延遲與穩定性：持續 72 小時壓測結論
效能數據好看只是一方面，雲端節點的穩定性才是決定能否投入生產的關鍵。我們對兩台機器進行了 72 小時連續高負載測試，期間同時跑 Xcode 增量編譯循環（每 5 分鐘一次）+ llama.cpp 併發推理 + 跨機大檔案循環讀寫。
| 指標 | 72 小時均值 | 最差值 | 備註 |
|---|---|---|---|
| TB5 鏈路延遲 (RTT) | 0.09 ms | 0.21 ms | 峰值發生在高負載切換瞬間 |
| TB5 頻寬（持續傳輸） | 69.8 Gbps | 61.2 Gbps | 降低發生於熱節流時 |
| 節點連線中斷次數 | 0 次 | — | 72 小時零中斷 |
| 任一節點 SSH 可達性 | 100% | — | 全程無需人工介入 |
| 機器溫度（外殼頂部） | 38.2°C | 41.7°C | M4 的被動散熱表現穩定 |
72 小時內 TB5 鏈路 零中斷，兩台節點全程 SSH 可達。頻寬峰值時偶有因 M4 熱節流導致小幅下降，但均值仍維持在 69.8 Gbps，對工作負載影響可忽略。這個穩定性對於生產環境 CI/CD 節點和常駐 AI 服務都是可以接受的。
適用場景總結
根據以上測試，TB5 並聯叢集最適合以下幾類需求：
1. 分散式 iOS / macOS 編譯（Xcode + distcc）：冷編譯提速約 1.6 倍，增量編譯提速超 2 倍，CI 流水線建置時間大幅壓縮。
2. 大參數量模型本機推理（llama.cpp RPC）：突破單機記憶體限制，兩機合併 32 GB 統一記憶體，可執行 70B 級別量化模型；併發推理吞吐近線性擴展。
3. 大規模影片渲染 / 媒體處理：跨機檔案讀取速度（NFS over TB5）可達 6.2 GB/s，遠超普通區域網路；配合 Final Cut Pro 叢集渲染協定，理論上可將渲染時間減半。
4. 即時資料管道與串流處理：80 Gbps 頻寬 + 0.08 ms 延遲使得跨機記憶體映射成為可能，適合需要低延遲節點間通訊的即時資料處理場景（如量化交易回測、即時資料流聚合等）。
一個繞不開的問題：為什麼不用傳統雲端伺服器搭叢集？
看到這裡，你可能會問：同樣的叢集需求，用 AWS 或 Google Cloud 的 GPU 執行個體不也能做嗎？畢竟主流雲端平台的高效能運算執行個體動輒提供 100 Gbps 乙太網路、HPC 叢集網路，聽起來參數也不差。
這個問題值得認真回答，因為它涉及到幾個常被忽視的本質差異。
首先是 macOS 環境的不可替代性。如果你的工作負載是 Xcode 編譯、iOS 簽章、TestFlight 分發、Apple Neural Engine 推理——這些場景在 Linux 或 Windows 執行個體上根本無法執行，法律上與技術上均有限制。AWS 的 Graviton 執行個體是 ARM，但跑不了 macOS；AWS 的 Mac 執行個體是 Apple 專屬硬體，但起步價格貴得離譜，最低配置折算下來約 $1.08/小時，且最短必須租滿 24 小時（即 $25.9/天起），比 ZilCloud 的 $20.9/天還貴，且無法做 TB5 並聯。
其次是 共享與超賣問題。傳統雲端平台幾乎都建立在虛擬化超賣的基礎上：100 個 vCPU 執行個體背後可能共用 60 個實體核心，「10 Gbps 頻寬」是突發頻寬而非保證頻寬，鄰居的 noisy neighbor 問題在高負載時段會直接影響你的編譯速度與推理延遲。而 ZilCloud 是實體機獨享——你拿到的是一台實實在在的 Mac mini M4，沒有虛擬化層，沒有超賣，10 核 CPU 就是 10 核 CPU。
第三是 網路互聯的品質差異。AWS 的 Cluster Placement Group 雖然提供低延遲網路，但節點間 RTT 仍在 0.5–2 ms 範圍；即便是 AWS 的 HPC 叢集執行個體（EFA 網路），延遲也在 1 µs 量級——而 TB5 的 0.08 ms RTT 是實體層直連，中間沒有任何網路堆疊路由，這對於行程間共享大量狀態的工作負載（如 KV-Cache 分片推理）意義完全不同。
當然，傳統雲端伺服器也有其優勢：按秒計費更靈活、GPU 型號選擇更多、彈性擴縮成熟度更高。如果你的主要需求是純 Linux GPU 訓練，傳統方案仍然更合適。但如果你需要的是 macOS 原生環境 + 高效能叢集互聯 + 按天靈活租用——這個組合，目前市場上只有 ZilCloud 的 TB5 並聯服務能真正做到。以最低 $20.9/天的起步價，加上 $1.4/天的 TB5 附加項目，合計 $22.3/天，就能拿到一台進入 80 Gbps 叢集的 Mac mini M4 實體節點。如果你有一個需要兩週的專案，臨時租兩台跑完就撤，不用為閒置資源再多付一分錢。