企业 iOS CI Mac 节点要租几台？2026 容量估算

症状： PR 一集中合并，Mac Runner 队列就拉长；平时又看不出究竟该添多少节点。

最快解法： 企业 iOS CI Mac 节点容量估算，不要从开发者人数推台数；本周先导出队列与运行记录，按任务类型、并发和工具链约束分池，再用试点结果决定扩容或租赁。

企业 IT 负责人：为 iOS CI 规划 Mac 资源，并准备采购或租赁申请。
平台工程师：治理 GitHub Actions 自托管 Mac Runner 的任务路由与排队。
FinOps 负责人：需要用真实负载建立可复算的容量与预算模型。

PR 检查与常规构建：先拆 Mac 任务，再看峰值并发

先从流水线记录中分清提交检查、PR 检查和主分支构建。每类任务分别采集触发时间、开始运行时间、结束时间、排队时间、失败或重试情况，并标记同时在跑的任务数。开发者人数只能帮助你解释团队活动，不能说明构建任务是否同时到达，也不能说明它们占用节点多久。

再检查工作流步骤：代码格式检查、静态分析或不依赖 macOS 的脚本，若兼容且能安全路由，可以交给非 Mac Runner；只有必须运行 macOS、Xcode 或 Apple 工具链的步骤才计入 Mac 池。否则，你会把整条工作流的时长都算到 Mac 上，导致需求虚高。

GitHub 会根据 runs-on 标签与 Runner Group 寻找匹配节点；只有匹配且在线空闲的自托管 Runner 才能接收任务，没有符合条件的 Runner 时任务会继续排队。自托管 Runner 的匹配与排队规则 因此，队列变长不一定说明总节点数不足，也可能是标签、组权限或工具链路由让已有节点无法接这类任务。

GitHub Actions 自托管 Mac Runner 排队时间能直接换算成节点数吗？
不能。队列记录能揭示等待发生在哪类任务上，但要同时核对匹配标签、Runner Group、Runner 在线状态和任务运行时长；否则，增加节点也可能没有分流效果。工作流使用标签与组进行路由，组合条件必须同时匹配。自托管 Runner 工作流路由说明

模拟器回归与矩阵任务：并发空间不等于空闲节点

把模拟器测试、设备矩阵和回归任务独立标记。记录每个 job 实际占用节点的时段，以及它是否能与普通构建共存。矩阵扩大时，工作流可能一下子提交多个 job；但若任务需要特定模拟器运行环境、工具链或独占资源，不能简单把“任务数”当成“可并行数”。

检查是否存在环境冲突：并行任务会不会争用同一份派生数据、测试账户、模拟器状态或共享缓存？若清理和隔离不充分，表面上增加了并发，实际可能带来失败重试，反而占用更多构建时段。用日志验证并行后的通过率和运行时间，不要先假定并行一定缩短队列。

PR 构建和模拟器回归要分开配置 Mac 吗？
如果它们需要不同的 macOS、Xcode 或模拟器环境，或者回归任务会持续挤压 PR 检查，就用标签和路由拆成不同容量池；如果环境一致、可以并行且队列记录显示互不干扰，可以先共用，再以试点数据决定是否分池。自定义标签可用于按节点特征路由，但标签必须和实际环境保持一致。GitHub 自托管 Runner 标签说明

签名归档与发布：安全约束先于并发推算

归档、签名和发布要作为独立工作负载盘点。除运行时间外，还要记录哪些凭证能被任务读取、哪些仓库可以进入发布节点、发布任务是否只能在受保护环境获批后启动，以及发布时段是否集中。构建耗时相同，不代表它们适合同时执行。

若多个普通构建节点都能访问发布凭证，扩容可能扩大敏感资产的暴露面。先确认发布任务的权限边界和可路由范围，再决定它是否需要独立 Runner Group 或专用标签；组访问策略也会影响任务能否进入预期节点。Runner Group 的访问控制与组织方式

签名发布池需要几台节点？
先从流水线记录确认同一发布窗口里有多少任务必须并行，再核对批准流程、凭证范围和节点可用时间。若发布任务必须顺序执行，或审批本身限制了启动节奏，增加 Mac 节点未必能减少等待。

集中合并与发布突发：用等待目标识别短队列还是容量缺口

把版本发布、集中合并和批量回归等突发事件单独标记。对照任务进入队列与开始执行的时间，观察高峰是否只在短时集中出现，还是在一段持续窗口内反复出现。前者可评估是否接受短暂排队，后者才更可能需要增加常驻或弹性容量。

为不同优先级设定团队自己的等待目标：PR 检查可以有明确的交付时限，夜间回归则可能接受较长等待。目标是企业内部的服务决策，不是 GitHub 的容量指标。GitHub 官方文档说明，任务若超过 24 小时仍在队列中会失败；这个平台边界不应被误当成团队可接受的等待标准。自托管 Runner 的排队规则

提醒：GitHub-hosted Runner 的并发额度和企业自托管 Mac 节点池是两件事。不要把托管 Runner 的计划额度直接当成自托管节点建议；先确认工作流实际发往哪种 Runner，再分析对应队列。GitHub Actions 并发限制说明

负载波动时，Mac 节点应该怎样扩容？
先验证高峰是否反复触发等待目标，再区分可路由任务与受标签、工具链或权限限制的任务。若队列只在偶发突发时上升，可先试租弹性容量；若高峰外也持续排队，就要复核基线池。无论哪种情形，都用试点前后的队列和运行记录验证假设。

专用工具链与遗留任务：单独标记不兼容的负载

为必须使用特定 macOS、Xcode、CPU 架构或其他专用环境的任务建立独立统计。通过工作流的 runs-on 条件、Runner Group、节点标签和实际运行记录，确认任务被送到哪里、是否存在等待，以及哪些节点确实有资格承接。Runner 组和标签可共同限定任务目标；若其中一个条件不匹配，增加其他池的节点不会帮它消化队列。按 Runner Group 与标签选择节点

此类负载通常不适合直接与常规构建合并估算。若专用环境使用频率低但不可替代，可把它作为弹性租用候选；若必须长期在线、任务持续且环境变更受严格控制，再对比自购设备和固定租期。每项判断都要能回到任务记录和路由证据，而不是只凭“可能会用到”留出节点。

试点里程碑与容量模型：从记录得到基线、峰值和备用量

先建立一份按任务类别拆分的变量表。对每类任务 (i)，记录观测窗口内任务到达量 (\lambda_i)、典型运行时长 (t_i)、允许利用率 (u_i)、节点可用时间 (A_i)，并标记隔离限制、可并行性和等待目标。作为企业估算模型，可用：

该类任务的基线估算值 = 向上取整（(\lambda_i × t_i ÷（u_i × A_i）)）

所有时间单位要统一；(\lambda_i) 应表示单位时间的任务到达量，而不是开发者人数。这个式子只给出基线工作量折算，不能自动处理突发分布、节点故障、任务不可并行或特定标签限制，因此不能把计算结果包装成 GitHub 官方指标或性能承诺。

按里程碑推进，避免一次性采购：

• 盘点： 导出队列时间、开始与结束时间、失败重试、工作流标签、Runner Group 和任务类别。
• 分流： 将非 Mac 步骤移出 Mac 容量模型；标记模拟器、签名发布和专用工具链任务。
• 建模： 用真实到达量和运行时长算基线；根据队列记录与内部等待目标，另列峰值和备用容量假设。
• 试点： 只调整一个容量池或一种路由策略，比较调整前后的排队、运行时长、重试和节点空闲情况。
• 复核： 若目标等待仍未达到，检查限制因素后再扩容；若队列改善但空闲时间明显增加，重新校准利用率假设。

Runner 扩缩容文档提供的是配置和运维方式，不是企业应配置多少 Mac 的结论。GitHub 对 Runner Scale Sets 的说明是：它们可与自动扩缩容方案配合；相关配置文档示例通过最小与最大 Runner 数量控制扩缩范围。Runner Scale Sets 概念说明；扩缩 Runner Scale Sets 的配置说明 对自托管节点的实际容量，仍须按企业自己的日志校准。

容量估算需要采集哪些队列事件？
至少要能区分 job 何时排队、何时开始、何时完成，并将事件关联到工作流、任务类别和目标 Runner 池。GitHub 的 workflow_job Webhook 提供任务状态事件，可作为采集设计的核对依据；仍要结合企业自己的运行日志补齐分析所需字段。workflow_job Webhook 事件说明

Mac CI 租赁还是企业自购？
先用试点算出持续基线和临时峰值，再比较设备利用率、采购周期、维护责任和租用周期。若负载持续、稳定且需要物理接口或固定的本地管理，自购可能更适合；若需求随发布周期变化、需要尽快验证容量或不想为短期峰值购置闲置设备，可评估按需租赁。不要在没有真实队列、租期和报价数据时，宣称某种方案必然更省钱。

完成盘点后，下一步应把模型中的容量假设与可核验的环境、租赁周期及交付信息逐项对照。固定自购方案的缺点是采购和维护责任集中、峰值扩容不够灵活；其他云端执行方案也未必能满足必须使用真实 macOS 与 Xcode 环境的任务。对于尚未摸清高峰、只想验证队列改善效果的团队，VMSPIN 的远程 Mac 可作为试点候选；如果你需要长期稳定满载或依赖物理接口，则先评估自购是否更合适。

你可以先查看 VMSPIN 的 Mac 租赁方案 与 租赁价格信息，核对页面列出的配置、租期和交付条件；只有与工作流要求匹配，再申请小规模容量试点。