第一步不要按开发者人数购买 Mac mini M4。先收集 峰值任务到达量、各类任务的 P95 构建时长、目标排队时间、允许的中断范围 这 4 项数据，再计算 Mac mini M4 构建机容量规划。非关键试点可以从单节点开始；生产流水线应采用基线节点加独立冗余，或在峰值时接入弹性远程 Mac。
这篇文章适合 3 类人：正在为新增 iOS 团队编制 Mac 构建资源预算的 IT 负责人；已经因为构建队列影响合并与发布的研发效能负责人；需要在固定采购、远程租赁和混合容量之间做选择的 CTO 或技术总监。
[ SECTION_01 ] 容量输入：先判断是不是缺机器
“要几台”不是硬件问题的第一问。很多队列增长，根因其实是依赖关系、重复构建、脚本串行或缓存失效。没有下面 4 项输入，直接给出节点数量只能是猜测。
| 容量输入 | 建议取值方式 | 对计算的作用 | 常见证据缺口 |
|---|---|---|---|
| 峰值任务到达量 | 从 CI 日志按 5 分钟或 15 分钟窗口统计 | 决定峰值工作量 | 只看日均任务数，忽略发布窗口 |
| 各类任务 P95 时长 | 分别统计检查、测试、Archive、签名发布 | 反映真实服务时间 | 用平均构建时长代替长尾 |
| 目标排队时间 | 按合并验证、夜间构建、发布任务分别定义 | 决定需要多少余量 | 只看 CPU 利用率 |
| 允许中断范围 | 明确主机失联、维护、升级时的容忍度 | 决定冗余节点数量 | 把备用机当成日常产能 |
任务类型必须拆开。代码检查和增量构建通常更短，但 UI 测试、冷构建、Archive 和签名发布可能占用更长时间。若定时任务、合并请求和发布任务在同一时段重叠，就要把它们放进同一个峰值窗口，而不是分别计算后再取平均值。
建议先查看流水线配置中的重复工作。例如同一个提交是否重复执行依赖安装，是否每个任务都清理缓存，是否多个目标因错误依赖被强制串行。官方文档说明，Xcode 会尽可能并行执行任务，但存在依赖关系时必须串行；手动顺序还可能使多核资源无法充分利用。查看 Xcode 目标依赖与并行构建说明
⚠️ 如果排队只在某个脚本阶段突然增加，先修复流水线，不要立刻采购更多主机。新增节点无法消除每个任务内部的串行瓶颈。
[ SECTION_02 ] 工作量模型：按任务强度换算
容量计算的基本变量可以写成：
峰值工作量 W = Σ（某类任务在窗口内的数量 × 该类任务 P95 时长）
基础节点数 N₀ = 向上取整（W ÷ 单节点有效产能）
这里的“窗口”必须与业务目标一致。夜间批量构建可以使用较宽松的时间窗口；合并验证需要关注短时间内的任务堆积；发布窗口则要单独计算 Archive、签名和上传相关任务。
单节点有效产能不是“CPU 核心数 × 某个倍率”。它应通过相同代码版本、相同 Xcode、相同依赖源和相同缓存状态测量。Apple 的 Mac mini M4 官方规格可用于确认候选硬件边界，例如 M4 配置包含 10 核 CPU、10 核 GPU 和 120GB/s 内存带宽，M4 Pro 配置则可达到 12 核 CPU、16 核 GPU 和 273GB/s 内存带宽。查看 Mac mini 官方技术规格
这些参数不能直接转换成“每小时完成多少次构建”。不同项目的 Swift 编译、链接、脚本、测试设备和依赖图差异很大。更高规格只能说明潜在资源边界，不能替代企业自己的基准任务。
| 任务类型 | 必须记录的指标 | 适合的容量判断 |
|---|---|---|
| 增量构建 | 代码变更范围、缓存命中、P95 时长 | 合并验证的主输入 |
| 冷构建 | 清理 DerivedData 后的完整构建时长 | 新节点交付与发布风险 |
| 单元测试 | 测试数量、并发方式、失败重试 | 日常验证容量 |
| UI 测试 | 模拟器数量、设备镜像、测试时长 | 并发隔离与内存压力 |
| Archive 与签名 | Archive、导出、签名和上传分段时长 | 发布窗口容量 |
Xcode 提供 Build With Timing Summary，也可以通过 xcodebuild -showBuildTimingSummary 输出构建计时摘要。该摘要适合定位编译、链接、脚本和准备阶段的耗时，不应只记录总时长。查看 Xcode 构建计时摘要方法
[ SECTION_03 ] 单节点产能：基准任务与有效并发
基准任务至少要覆盖冷构建、增量构建、测试和归档。每项任务建议连续运行多轮，并记录 P50、P95、失败率、缓存状态和依赖下载时间。这里不需要追求一个漂亮的平均数字，而要确认高峰时最慢的一批任务会占用多少时间。
具体操作可以按以下步骤执行：
- 固定代码版本：选取近期真实提交，锁定依赖文件、子模块和资源版本。
- 固定 Xcode 环境：记录 macOS、Xcode、SDK、命令行工具和签名配置。
- 分离缓存状态：分别执行冷构建与增量构建，不能把两者混在一个平均值里。
- 打开计时摘要：保存
xcodebuild原始命令、日志和构建报告。 - 拆分工作负载：分别测试检查、单元测试、UI 测试、Archive 和签名发布。
- 逐步增加并发：从单任务开始，再增加第二个任务，观察 P95 时长、内存压力和失败率。
- 记录有效上限：当吞吐不再增加，或任务互相污染、失败率明显上升时停止增加并发。
- 保存原始证据：保留连续多轮记录，方便升级 Xcode 或更换节点后复算。
Xcode 的目标依赖越复杂，可并行的任务越少。官方建议通过准确声明依赖、减少不必要的模块重建和拆分过大的目标来改善增量构建速度。查看 Xcode 增量构建优化建议
同时，Run Script、资源复制、链接和签名步骤也可能成为瓶颈。它们往往不会因为增加 CPU 并发槽位而同比缩短。查看 Xcode Build Phases 的任务构成
- [ ] 已固定代码、依赖、Xcode 和 SDK 版本
- [ ] 已分别记录冷构建与增量构建
- [ ] 已保存每类任务的 P95 时长
- [ ] 已记录缓存命中与依赖下载时间
- [ ] 已用计时摘要定位串行脚本和依赖瓶颈
- [ ] 已逐步压测并发，而不是直接使用理论并发数
- [ ] 已记录任务失败、重试和环境污染情况
- [ ] 已为发布任务单独建立容量基线
[ SECTION_04 ] 排队门槛：利用率只是预警信号
基础节点数算出来后，还要加入服务目标。可以使用下面的扩展模型：
最终节点数 N = 向上取整（N₀ × 容量缓冲 + 冗余节点）
其中，容量缓冲用于应对任务到达量波动；冗余节点用于计划维护、Xcode 升级、主机失联和发布高峰。两者不能混为日常满载容量，否则系统看似“有很多机器”，实际没有故障空间。
三类场景的决策重点不同：
- 夜间构建：排队目标较宽松，可以使用较少的固定节点，但要避免清晨任务全部拥堵。
- 日常合并验证：重点看高峰窗口内的 P95 排队时间。只要连续多个窗口超标，就应扩容或拆分任务池。
- 发布窗口：Archive、签名和上传通常属于关键路径，应保留独立节点或弹性容量，避免被普通合并任务占满。
不建议把“利用率达到某个百分比”作为唯一扩容规则。更可靠的门槛是：连续多个高峰窗口超过排队 SLA，且已经排除依赖、缓存、脚本和网络问题。CPU 峰值只能说明某个阶段忙，不代表整个节点池的有效产能不足。
如果采用自托管 Runner，应使用标签或分组把不同硬件、Xcode 版本和任务类型隔离。官方文档说明，任务只有在 Runner 同时满足所需标签和分组条件时才会被调度。查看 Runner 标签与分组调度规则
[ SECTION_05 ] 并发隔离：纸面槽位不等于有效产能
单台 Mac 同时运行多个 Xcode 构建任务，常见问题不只在 CPU。
第一是 DerivedData 竞争。多个任务复用同一目录，可能造成缓存覆盖、锁等待或结果污染。第二是 模拟器资源冲突。UI 测试同时启动多个模拟器时，内存、磁盘 I/O 和系统服务都会增加压力。第三是 Keychain 与签名凭证隔离。发布任务不应与普通测试任务共享不受控的凭证环境。
还要考虑工作区、临时目录、依赖缓存和日志写入。如果一个任务失败后没有清理现场，后续任务可能继承错误状态。多任务并发带来的运维成本，也包括环境重置、失败重试和问题复现。
因此，单台 Mac mini M4 的 Xcode 并行槽位不能用一个通用数字回答。企业应当以压力测试中的有效吞吐为准：当增加并发后，单位时间完成任务数不再上升，或 P95 时长、失败率和资源争用明显恶化，就应把并发槽位视为已到上限。
单机多任务与多节点单任务的选择，可以这样判断：
- ✅ 任务彼此独立、无签名操作、失败可重试：可以测试有限并发。
- ✅ 发布任务、UI 测试、敏感凭证：优先使用独立节点。
- ❌ 多个任务共用 DerivedData、模拟器和 Keychain：不要直接提高并发。
- ❌ 依赖本地物理接口或固定设备：远程弹性节点可能不适合全部任务。
经验上，增加并发槽位前必须先确认任务隔离方式。否则得到的不是更高吞吐，而是更多随机失败和更难复现的构建结果。
[ SECTION_06 ] 节点方案：固定、弹性与混合
最终采购方案应同时比较固定节点成本、弹性容量成本和等待造成的研发工时损失。不能预设租赁一定更便宜，也不能只看设备采购价。
| 方案 | 适用条件 | 优点 | 风险评分 |
|---|---|---|---|
| 单节点 | 非关键试点、低峰任务、允许中断 | 配置简单，便于验证基准 | 稳定性：★☆☆☆☆ |
| 固定节点池 | 日常合并任务稳定，峰值可预测 | 延迟可控，环境固定 | 吞吐：★★★★☆ |
| 固定节点 + 弹性远程 Mac | 日常负载稳定，发布或活动峰值明显 | 避免为短时峰值长期买满设备 | 综合：★★★★★ |
| 全弹性远程 Mac | 任务低频、地域分散、试验性项目 | 初始投入较低，扩容灵活 | 环境控制：★★★☆☆ |
企业 Mac 基础设施 TCO 分析不能只计算硬件折旧，还应加入机房空间、网络、电力、备件、系统升级、远程运维、故障替换和闲置容量。若自购节点长期稳定满载，固定节点池通常更容易控制延迟；若只有发布日或阶段性项目出现峰值，弹性容量更有价值。
NOVAKVM 的远程 Mac 可以作为基准测试节点或峰值补充。更稳妥的做法是先在 远程 Mac 环境 中运行同一组代码、同一版本 Xcode 和同一套缓存策略，再把实测 P95 时长代入公式，而不是先购买一组无法验证的固定数量。
如果团队需要比较不同区域的交付条件，可以结合 M4 远程 Mac 配置说明 核对访问方式、节点可用性和实际任务限制。具体地域、交付周期和环境能力应以当前页面与采购确认结果为准，不应从芯片名称推导服务能力。
[ SECTION_07 ] FAQ：容量规划中的关键判断
上面的模型适合建立第一版容量基线，但企业决策还需要保留几个边界。尤其是节点数量、并发槽位和高配机选择，都必须回到真实 CI 日志与压力测试。
生产流水线不应把备用节点计入日常满载。若主节点一旦失联就无法发布，表面上的“刚好够用”实际上没有满足可用性要求。相反，非关键试点也没有必要一开始就采购完整冗余池。
[ SECTION_08 ] 结论：把真实产能接入预算模型
Mac mini M4 构建机容量规划的正确起点不是开发者人数，也不是 CPU 核心数，而是峰值任务量、任务类型的 P95 时长、单节点有效产能、排队目标和冗余要求。先用一台节点完成基准任务，再决定是增加高配主机、增加节点，还是接入弹性远程 Mac。
如果当前方案依赖少量自购 Mac mini，常见缺点是峰值时容量不足、备用设备长期闲置、故障与 Xcode 升级需要团队自行处理。若全部放在单一共享主机上，还会叠加凭证隔离、缓存污染和发布任务互相争用的问题。对只在发布窗口或项目高峰期需要额外产能的团队，直接扩充固定设备并不一定合理；先使用 NOVAKVM 的远程 Mac 跑完同一组基准任务，再决定固定基线加弹性容量，通常更容易把预算和 SLA 放在同一张表里。