Thunderbolt 5 Mac mini 集群实测：多台云端 Mac 组网编译能快多少？

单机够用时，为什么还要谈 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 加速缓存分发，比一味加机器更能缩短墙钟时间。