单机够用，为什么还要多机并联？
一台 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 侧提速来自「多台物理机同时算」，不是雷电线缆 magically 加速单核 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 独享节点上，通常是更清醒的选择。