云端 Mac mini 集群实测：Thunderbolt 5 并联的 80 Gbps 是什么体验？

单机够用时，为什么还要 TB5 集群？

很多团队的第一反应是：「M4 已经很快了，再加机器不是浪费吗？」这在单 App、单流水线场景下往往成立—— 一台 16 GB 独享内存的 Mac mini 跑全量 xcodebuild，通常比老款 MacBook Pro 快一截。 但当出现以下三类需求时，瓶颈会从 CPU 转移到机器之间的数据搬运：

• 编译农场：同一仓库要同时打 Debug / Release / 多个 Flavor，或并行跑 UI 测试与 Archive；
• 大体积 Artifact 同步：DerivedData、.xcarchive、Core ML 模型包在节点间复制，单次可达 20–80 GB；
• 分布式推理或渲染：多进程分片加载模型权重，节点间需要接近内存带宽的互联，而非走 1 Gbps 公网。

若仅用每台机器各自的 1 Gbps 公网 IPv4 互传，理论上限约 125 MB/s，传 50 GB 数据就要 6–7 分钟， 且与同机房其他流量争抢。Thunderbolt 5 的卖点正在于此：在同一数据中心节点内， 用 80 Gbps 物理通道把多台 Mac mini 拉成一台「逻辑上的高速局域网」，让多机协作时的等待从「分钟级」压到「秒级」。

测试环境：三台物理机，一条 TB5 链路

本次测试在 SpinMac 新加坡节点完成。选择该节点的原因很实际： 大陆与东南亚团队 SSH 延迟普遍在 30–80 ms，适合作为亚太区的构建中枢； 且 TB5 并联要求机器位于同一 SpinMac 节点，跨节点（例如新加坡 + 日本）无法组网。

从下单到链路就绪：开通与接线流程

TB5 并联不是默认开启的能力，需要在租用阶段或控制台为同一订单组内的多台实例勾选附加项。 我们按下面步骤完成环境搭建，全程无需自行采购线缆或交换机——SpinMac 在同节点机房完成物理连线。

1. 01
   在下单页租用多台机器并勾选 TB5

   进入配置下单页，节点选「新加坡」，数量选 3 台，周期按测试需要选择（我们使用按周 $57.3/台）。 在附加项区域勾选「Thunderbolt 5 多机并联」——按周计费为每台额外 +$4.1。 付款后约 1–5 分钟，三台机器分别交付，控制台订单详情会出现「TB5 集群」标识。

2. 02
   确认系统识别 Thunderbolt 桥接

   SSH 登录各台机器后，在「系统设置 → 网络」中应能看到 Thunderbolt Bridge 接口， 并分配 169.254.x.x 链路本地地址。用 ifconfig bridge0 可核对状态为 active。 若只有一台机器看不到 bridge，通常是并联 provisioning 尚未完成，工单联系支持即可，我们本次等待约 8 分钟。

3. 03
   固定主机名与 SSH 互信

   在 /etc/hosts 中为三台机器写入 TB5 侧 IP 与别名（如 mac-a、mac-b、mac-c）， 配置 SSH 密钥互信，后续 iperf3 与 rsync 均走 bridge 网段，避免误用公网 IP。

4. 04
   冒烟测试

   在 mac-a 上执行 ping -c 5 169.254.x.x（mac-b 的 bridge 地址）， 延迟应稳定在 0.3–0.8 ms 量级。再跑一轮短 iperf3，确认链路可用后再上生产任务。

带宽实测：80 Gbps 能跑到多少？

标称 80 Gbps 是物理层理论值，实际吞吐受帧开销、CPU 软中断、测试工具与拓扑影响。 我们使用 iperf3 单流与 8 并行流各跑 5 次取中位数，结果如下。

换算成更直观的数字：42 GB 的 DerivedData 快照，走公网 scp 要六分钟以上； 走 TB5 网段 rsync，首次全量在 20 秒内完成。第二次增量同步（仅变更的 object 文件）更是降到 3 秒以内。 对编译农场而言，这意味着 worker 节点拉取缓存的等待，从「泡一杯咖啡」变成「接杯水」。

需要诚实说明的是：TB5 解决的是节点间搬运，不会 magically 让单台机器的 xcodebuild 更快。 若你的痛点是单 target 编译慢，加机器不如先查依赖图与模块化；若痛点是多机并行 + 大缓存同步，TB5 的收益非常明显。

实战：Xcode 构建与 CI 分工

带宽数字终究要落到工作流里。我们设计了两组对照实验，模拟常见 iOS 团队场景。

实验 A：三台并行 Archive，共享同一份 DerivedData

主节点 mac-a 完成一次全量编译生成 DerivedData 后，通过 TB5 将缓存推送到 mac-b、mac-c， 三台同时执行不同 scheme 的 Archive（Debug 内测包、Release 商店包、Notification Service Extension 独立包）。

无 TB5（各机独立全量编译）：三台总墙钟时间约 47 分钟（含各自 14–16 分钟全量编译）。
有 TB5（一次编译 + 缓存分发）：首台全量 15 分 20 秒，缓存推送 22 秒，三台并行 Archive 8 分 40 秒， 总墙钟 24 分 22 秒，节省约 48% 时间。若每日打三轮包，一周能夺回数十小时。

实验 B：GitHub Actions 自托管 Runner 池

三台机器各注册为 self-hosted runner，标签分别为 macos-m4-a/b/c。 workflow 用 matrix 拆单元测试与 UI 测试。测试产物与 .xcresult 汇总到 mac-a 时， TB5 路径使 6.2 GB 结果包聚合耗时从 4 分 50 秒降到 41 秒。

更完整的 Runner 安装与签名配置，可参考 云端 Mac 跑 Xcode CI/CD 实战指南。 该文侧重单机流水线；本篇补上的拼图是多机互联层。

踩坑记录：这些问题我们真实遇到过

并联服务交付的是物理链路与 bridge 网络，上层应用仍要自行规划。以下坑踩过一次就不会再犯：

• 链式拓扑的中转延迟：三台呈 A–B–C 链式时，A 到 C 带宽略低于 A 到 B。 对延迟敏感的全同步，可把「缓存源」固定在拓扑中心节点（本次即 mac-b）。
• 磁盘仍是瓶颈：256 GB 系统盘同时塞三份 DerivedData 会吃紧。 大仓库建议至少为一台 worker 勾选 +1 TB SSD 扩容（按月 +$12.5），缓存与 Archive 分盘存放。
• 签名证书只需主节点导入：Archive 若在各机并行，每台都要在钥匙串有 Distribution 证书； 或采用「仅主节点签名 + 子节点只跑测试」的分工，减少密钥扩散面。
• TB5 不替代公网接入：你的笔记本仍通过 SSH/VNC 连各机公网 IP 操作； TB5 网段是机房内部数据平面，不会暴露到互联网，这是安全设计而非缺陷。

成本算账：什么时候值得加购 TB5？

基础租用按 SpinMac 统一定价：按日 $21.2、按周 $57.3、按月 $106.1、按季 $288.6，五节点同价。 TB5 并联附加项按台计费：按日 +$1.5、按周 +$4.1、按月 +$7.5、按季 +$20.4。 以我们本次 3 台、按周为例粗算：

机器租金：3 × $57.3 = $171.9/周
TB5 附加：3 × $4.1 = $12.3/周（约占机器租金 7%）
合计约 $184.2/周，折合约每天 $26.3 拥有三台可互联的 M4 编译节点。

对比自建方案：购置 3 台 Mac mini M4 硬件约 $1,800+，再加 TB5 线缆、机架与电费， upfront 成本高， 且闲时无法缩容。对比「三台云主机各跑各的、走公网互传」：机器费用相同，但每周若发生 10 次以上 40 GB 级同步， 浪费在传输上的工程师等待时间，通常远超 $12.3 的附加项差价。

建议加购 TB5 的信号：同节点 ≥2 台机器、且存在每日大体积 Artifact 或缓存同步； 或 CI matrix 经常并行 3 路以上 macOS job。反之，长期只有单台、或机器分布在不同城市节点做灾备， 则不必开通——跨节点无法用 TB5，应改用对象存储做构建缓存（S3 兼容层），那是另一条架构路径。

若你尚未租用任何机器，可从下单页一次性选好多台与 TB5 附加项； 已有单台的用户，在控制台追加并联即可，无需迁移数据。

结论：80 Gbps 改变的是「协作摩擦」，不是单机峰值

回到标题里的问题——Thunderbolt 5 并联的 80 Gbps 是什么体验？ 用一句话概括：它让多台 Mac mini 在数据面上像同一机架上的服务器一样说话， iperf3 实测 60–68 Gbps 量级，大文件同步从分钟压到秒；但单台 Xcode 全量编译该多久还是多久， 集群的价值在于并行与缓存复用，而非替代更快的芯片。

对 SpinMac 用户而言，TB5 附加项的意义是「在已经选了云端物理 Mac 的前提下，把多机协作的摩擦系数降到足够低」—— 无需自己买线缆、无需和机房协商布线，同节点勾选即可。若你的团队正卡在「编译农场想法有了，机房间传文件太慢」这一步， 这篇实测里的数字和流程可以直接当作 PoC checklist 使用。