2026 年四类负载里：何时「并联双节点」优于「单机升配」
当你在新加坡、日本、韩国、香港与美东美西之间分配开发者与 Runner 时，单机云 Mac 往往在两条轴上同时触顶：其一是 Xcode 与并行编译导致的统一内存与磁盘写入峰值；其二是制品仓、容器 registry 与无头批处理不在同一「数据面」带来的 chatty IO。第二条轴只靠扩内存并不能根治——你需要的是让第二套 Runner 落在制品就近的大陆，并把队列标签写进 orchestrator，而不是在 README 里写一句「尽量靠近」。Thunderbolt 级并联资源解决的是「两台物理机之间能以远高于千兆以太网的点对带宽搬运分层缓存」这一类问题；若你的瓶颈压根不是两台相邻 Mac 之间的搬运，而是 Runner 仍在俄勒冈而制品在新加坡，那么并联硬件只会把错误架构固定成双倍账单。
下面五条把最常见的误判写成检查顺序：当你能逐条排除这些误判后，才有资格进入「第二台机器」的预算审批；否则应回到 存储与内存选配 里的档位矩阵与回收阈值，而不是急于并联。
把 wall time 一律归咎于 CPU：队列监控只看利用率曲线却忽略 SPM/CocoaPods 解析占比；此时应先采样解析占比周曲线，再决定是否同区副节点。
把「两台 Runner」写在口头却不写标签：CI 系统里两套并发上限指向同一标签，白天交互式调试与夜间归档抢同一池；并联只会复制噪声而不能分摊 spike。
跨洋复制 DerivedData：试图用夜间 rsync 把缓存搬到另一区却不更新 DNS/registry 端点；并联带宽救不了错误的数据面。
忽视租期叠加口径：按天试水后直接口头续两台长期实例却无 owner，财务科目仍是「临时测试」，月底审计无法解释 spike。
把 Thunderbolt 当万能药：厂商菜单里的互联选项只有在两台节点确实可被调度到相邻机位且你的 workload 需要大块点对点搬运时才值得买票；否则优先完成制品同区。
认清上述误判后，可把决策收敛成一句可验收的话：并联是为「同一数据面上的并行队列」买单，不是为「更多 CPU 数字」买单；这与 Xcode Cloud 与独占池混搭 一文里的队列分层逻辑相容——Cloud 吸短 spike，独占池保主线 SLA，而并联解决的是 Pool 内部仍需横向切片时的物理亲和。
对照表：先升配、先同区副节点、还是先评估 Thunderbolt 并联资源
下表刻意不把 Thunderbolt 写成「必然勾选」，而是把它放在「两台节点已经同区且缓存分层确实需要点对点高带宽」之后的第三顺位。对跨国团队而言，第一顺位通常仍是把 Runner 与私有 registry 收敛到同一大陆；第二顺位才是单机内存或磁盘档位的变更；第三顺位才是互联与并联 SKU。
| 维度 | 优先单机升配 | 优先同区第二节点 | 再评估 Thunderbolt / 并联 SKU |
|---|---|---|---|
| 瓶颈信号 | 链接尾延迟、swap、峰值并行度逼近 CPU/GPU 上限 | 解析占比高、registry RTT 占 wall time、队列在同一标签内 collision | 两台相邻节点之间需要高频搬运分层缓存或巨型 tarball |
| 财务口径 | 一次性变更内存或 SSD 档即可对齐预算科目 | 新增一台即新增队列 owner 与账单拆分字段 | 互联多为附加 SKU，需要写明折旧周期与共享 owner |
| 风险 | 过度采购长期空闲核数 | 队列分层缺失会导致「两台仍互相抢」 | 机位不相邻时互联不可达，需回滚契约写清楚 |
| 观测指标（两周窗口） | 黄线（进入并联 POC） | 红线（冻结架构评审） |
|---|---|---|
| 同标签队列 P95 | 连续 5 个工作日大于 15 分钟 | 任意三日大于 25 分钟且运维值班工时同比上升 |
| 制品拉取占 wall time | 周均大于 28% | 周均大于 38% 且并行编译利用率低于 55% |
| 缓存回收导致的重建次数 | 夜班触发全量清理大于每周两次 | 清理后 24 小时内重复触顶两次以上 |
并联的正确 KPI 不是「机器数量」，而是「同一数据面上的并行队列是否可观测、可计费、可回滚」。
阈值需要在你自家 orchestrator 与时区定义下本土化；本节给出的比例借鉴公开 CI 观测实践与队列分层讨论，并不替代你方 SLA。把它们写进与 多地区租期决策 相容的变更模板后，财务与技术才能在同一页表格对齐。
命名与亲和：把 region 与 artifact_plane 写进 orchestrator 标签
当你在 KVMNODE 选定某一区域的独占裸金属后，建议在队列命名中同时冻结三个维度：地理 region、数据面 artifact_plane（私有 registry 与对象存储所在大陆）、以及 workload_profile（交互式调试 versus 无头归档）。忽略 artifact_plane 会导致并联两台仍在默认上游「跨区域」解析依赖；忽略 workload_profile 则会让白天 GUI 会话与夜间归档争抢同一并发令牌。
下列 YAML 片段展示语义而非绑定某一 CI 品牌——键名应替换为你方系统的等价字段，但「region + artifact_plane + queue」三位一体的约束建议直接镜像到合并请求模板。
mac_pool_sg_primary:
region: ap-southeast-1
artifact_plane: same-metro-private-registry
queues: [ios-night-archive, release-tag-build]
tb_link:
enabled: candidate
rationale: "layer tarball > 80 GB weekly"
mac_pool_sg_secondary:
region: ap-southeast-1
artifact_plane: same-metro-private-registry
queues: [spm-resolve-cache, derived-data-sticky]
pairing: mac_pool_sg_primary
提示：若互联 SKU 暂不可用，可把 pairing 退化为「同区对象存储就近前缀 + 固定 egress」，仍以 artifact_plane 一致为第一约束。
云侧 SSH 与带宽配额应与队列峰值并行度一并写入工单；不要把 SSH 仅当成工程师接入通道——自动化 pulling 与签名脚本同样需要稳定的出站路径与会话复用策略，否则并联只是在两端复制「人机排队」。这方面细则可在订购与交付沟通中与客服对齐 regions 与套餐字段。
六步落地：从按天试水到把并联字段写进预算附件
冻结观测口径：在同一仪表盘并列队列 P50/P95、解析占比与磁盘回收事件；时区与工作日高峰窗口写成文档。
单机对照实验：先用同等内存档跑一周，确认瓶颈不在可调缓存策略；记录 DerivedData 回收阈值。
同区副节点 POC：新增 Runner 仅挂载同一 artifact_plane，不改上游 DNS；对比两周 wall time 与值班工时。
并联 SKU 评估：若点对点搬运可量化节省夜班带宽成本，再评估 Thunderbolt 或等价互联账单；写入并联触发条件与回滚。
租期叠加：短期按天验证通过后转月度或更长周期时，把 owner、队列分层与财务科目一次性对齐；参见多地区租期指南。
订购留痕：通过站点默认订购入口写入区域、档位与并联意图，避免口头加机器；帮助中心留存连接与安全策略截图。
硬数据口径：把三条可引用参数写进 EEAT 与评审附件
Thunderbolt 代际带宽量级：Thunderbolt 5 官方规格指向数十 Gbps 级点对点管道；当你的分层缓存 tarball 体积稳定在数十 GB 且 nightly 窗口重复搬运，点对点带宽才有可比优势（厂商白皮书）。
独占千兆出站：典型云 Mac 租赁商会标注独立 1 Gbps 级带宽与静态 IPv4/IPv6；并联两台时需复核「每台 versus 并联链路」是否共享封顶，避免观测误判。
队列并行令牌：若 orchestrator 以并发令牌计数而非裸 CPU，两台 Runner 仍映射同一令牌桶时会虚假并行；评审附件应写明令牌拆分策略。
注意：并联并不能替代合规与密钥轮换；跨区复制密钥材料仍应禁止，数据面收敛仍是第一性原理。
自建机房或桌面主机并联往往要面对电源、雷电链路稳定性与手工接线的人力成本；虚拟机拆分则会引入嵌套虚拟化对Metal与CODE SIGN的不确定性。相较之下，可在新加坡、日本、韩国、香港与美东美西多点下单、按天到按月弹性切换租期、并把独占裸金属当作标准化合同项写入预算表的云端节点，更适合长期承载跨国团队的并行 CI 与自动化链路。对于追求构建与制品路径稳定、要把队列指标写进变更系统的交付团队，KVMNODE 的 Mac Mini 云端租赁通常是更优解：独占 Apple Silicon、可按区域与档位透明选型、并以弹性租期把试错成本压在 POC 阶段而非资本开支。