PR 构建频繁触发，月底却说不清 macOS CI 花在哪？ 先按工作流类别统计真实运行次数、作业时长、重试和存储，再按仓库可见性与 Runner 类型核对当日官方规则；持续调试需求另行预算，不要只拿 CI 分钟推算。
适合需要为 macOS 构建、测试或签名任务编列预算的高校科研软件开发者。 也适合预测私有仓库自动化支出的课题组负责人，以及要区分短时 CI 和长期 macOS 环境的实验室技术支持人员。
GitHub Actions macOS Runner 科研 CI 成本的核算边界
账单先分为三类：Runner 执行用量、构建产物存储、缓存存储。公开仓库使用标准托管 Runner 与私有仓库使用标准 Runner 的计费条件不同；larger runner 即使运行在公开仓库，也不能直接套用标准 Runner 的免费规则。私有仓库的免费额度依账户套餐而异，超额后才按适用规则计费。详见 GitHub Actions 官方计费说明。
核算时别把“月总分钟”当作唯一输入。建议先为每种工作流建一行记录，再分别计算：
月度 Runner 用量 = Σ（该类作业月运行次数 × 单次实际作业时长）
随后按当前账单规则处理分钟取整、仓库及套餐额度、Runner 类型和存储。若要估算超额金额，再将适用的 Runner 费率与计费分钟对应；不要将某个账户的免费额度或高校优惠资格视为所有课题组都适用。GitHub 的官方价格和套餐规则可能更新，核价应以预算审批当日的账单页面与价格计算器为准，具体取整和单价可核对官方 Runner 价格与计费规则。
| 工作流场景 | 需要记录的实际输入 | 核算时重点 | 场景适配评分 |
|---|---|---|---|
| PR 快速构建与冒烟测试 | 触发次数、每次执行时长、失败重跑、并发 | 将可在其他平台完成的检查与必须用 macOS 的作业分开 | 托管 Runner：高 |
| Xcode 与 macOS 版本回归 | Runner 标签、系统与架构、矩阵作业数、每项时长 | 按矩阵展开实际作业；预览环境要单独标记 | 托管 Runner：中至高 |
| 签名验证与发布检查 | 签名步骤、证书配置、验证次数、人工介入 | 分清自动检查与必须由人员完成的验收 | 托管 Runner：中 |
| 定时分析或持续调试 | 调度频率、作业运行时间、重跑、是否需保留状态 | 短时批处理按作业核算；长时间交互另做环境预算 | 前者高，后者低 |
PR 快速构建的真实用量
PR 任务看似轻量，但频率高、失败重跑多时，月度用量可能被它主导。不要用“每个 PR 一次”替代记录：同一 PR 可能因提交更新、手动重跑或并发策略触发多次；而排队时间与作业实际执行时间也要分开看，估算时应从作业记录和账单指标复核。
在最近一个完整项目周期中，按工作流名称导出作业记录，至少标出触发来源、实际执行时间、失败后消耗时间和重跑次数。组织或仓库的 Actions 使用指标可用于定位分钟主要消耗在哪些工作流；如果团队有相应权限，也可导出指标供课题组预算复核，操作方法见官方 Actions 使用指标说明。
随后把不依赖 Apple 平台工具链的静态检查、文档检查或通用单元测试留在其他可用平台；仅将必须验证 macOS 行为的任务送入 macOS Runner。这样做不是把 macOS 测试删掉，而是避免让每次提交都重复承担本可在别的平台完成的步骤。若设置并发取消规则，要检查它是否会中断正在执行且必须保留结果的验证任务；并发组的行为由工作流语法中的并发规则决定。
Xcode 27 回归任务的标签与矩阵
Xcode 27 作业不宜只记“跑了 iOS 测试”。先核实 runs-on 标签对应的系统、架构和预览状态，再确认任务矩阵实际扩展出的作业数量：不同 macOS 版本、架构或模拟器组合，都会增加独立的执行项。标签列表及镜像内容会更新，不能把上次运行使用的环境默认当作本月仍然可用。
截至 2026 年 9 月 27 日，GitHub 的 Runner 镜像公告将 xcode-27 标记为公开预览，并说明预览环境可能存在软件不稳定或排队问题；公告在 2026 年 9 月 16 日更新了其基础系统信息。把它用于课题关键路径前，应复核官方 Xcode 27 预览公告和当前 Runner 镜像列表，先做可回退的验证，再纳入正式预算。
单次构建、多个系统版本回归和签名验证要拆成不同类别。单次构建只统计真实执行的作业；矩阵测试按每个实际展开的作业记账，而不是按一次工作流触发计数；签名任务则要确认是否每次 PR 都必须运行，还是只在合并、发布或验收阶段执行。对 Xcode 27 测试，按项目实测时长和失败重跑记录估算，不预设一个对所有项目都适用的“适合 Runner”时长门槛。
定时批处理与持续环境
定时分析、周期回归适合按实际调度频率和单次执行时长核算。若调度触发后任务无需人工介入、完成后可结束，就将它归入托管作业；若任务中断会导致昂贵的准备过程重来，还要从运行记录中分离重跑耗时。
持续运行、需要交互调试或保留状态的任务，不能简单按“每次构建分钟数”衡量。你还要计入环境维护、团队访问方式、状态保留和人工操作需求；它们与一次性托管作业不是同一类成本。若只有短时自动构建，继续按 Runner 作业核算；若同一台 macOS 环境需要反复供研究人员连接使用，则把长期环境作为独立方案比较，而不是把 Runner 的分钟预算无限外推。
失败重跑、构建产物与缓存
失败作业已经执行的部分仍可能形成 Runner 用量，修复后重新运行也会再次消耗执行时间。GitHub 的计费说明区分了失败前已用分钟与之后重跑的分钟，因此预算表应记录失败作业已运行时长，而不只是最终成功那次。
构建产物与依赖缓存也不要混成一个“存储”字段：产物可能包含安装包、测试报告和调试文件，需核对占用量与保留时间；缓存用于复用依赖或构建输入，有独立的空间规则和淘汰行为。缓存即使能减少重复下载、缩短后续任务，也不能假定它永远命中或不会产生管理负担；规则可查阅官方依赖缓存文档。
产物删除后，当前占用可能下降，但计费周期内已经累计的存储用量不一定随之消失；仓库和套餐的存储额度也需单独确认。为避免旧构建文件长期占用，检查保留策略，并确认缩短保留周期不会影响课题复现、审计或发布留档。组织管理员可按官方产物与日志保留期说明核对设置。
课题组核算表与执行步骤
按下面的步骤完成一次可复核的预算，不用臆造项目频率或单次时长：
- 定核算对象。 记录仓库所有者、公开或私有、套餐、Runner 类型，并确认账单归属账户。
- 按工作流分类。 至少拆分 PR 快速检查、macOS/Xcode 回归、签名验证、定时分析；不要把不同用途的作业合并成一项平均时长。
- 导出实际运行记录。 选取代表性的项目周期，记录每类工作流的运行次数、作业执行时长、失败耗时和重跑情况。不要用队列等待时间替代作业执行时间。
- 核对标签和矩阵。 确认 Runner 的系统、架构、预览状态，以及矩阵展开后的实际作业数；Xcode 27 相关标签在预算审批前重新查看官方公告。
- 核算存储与保留。 分开填写产物、缓存和需要保留的镜像数据；记录平均占用与保留策略，不把删除后的当前占用误当作整个周期的累计占用。
- 套用当日规则并复核账单。 对照适用套餐额度、标准 Runner 或 larger runner 的计费边界和官方单价，再与组织使用指标或账单页面交叉检查。GitHub 官方费率页面当前列出标准 macOS Runner 为每分钟 $0.062，并列出不同规格 larger runner 的费率；这些数字仅代表核算日页面所列规则，预算锁定前需再次确认。
| 预算字段 | 你要填写的内容 |
|---|---|
| 仓库与套餐 | 仓库可见性、账单所有者、套餐与免费额度 |
| Runner 选择 | 标准或 larger、标签、系统、架构、预览状态 |
| 工作流类别 | PR、Xcode 回归、签名、定时分析或其他 |
| 实际用量 | 月运行次数、单次实测时长、失败耗时、重跑次数 |
| 存储用量 | 产物体积与保留期、缓存峰值、镜像占用（如适用） |
| 核价依据 | 官方费率页面、核价日期、账单或使用指标复核结果 |
最后更新于 2026 年 9 月 27 日；Runner 标签、Xcode 27 预览状态、费率与存储规则核实自 GitHub Runner 镜像公告、Actions 计费文档及官方 Runner 价格表。项目运行次数和时长应以你自己的工作流记录为准。
常见核算问题
私有仓库估算要先确认账单账户的套餐额度和 Runner 类型，再结合实际作业记录计算；Xcode 27 任务要核实标签与预览状态；失败重跑和构建产物要分别计入；持续调试需求则另行评估长期 macOS 环境。具体问题与独立答案见文末 FAQ。
如果核算结果显示你的团队只需要偶发的自动构建，继续用托管 Runner，通常比为短任务常驻一台主机更容易按作业追踪；如果研究人员需要频繁交互调试、手工验收或保留 macOS 状态，单看 Runner 分钟就会漏掉真实需求。你可以先查看 MACGPU 的远程 Mac 环境入口，再核对可选 Mac 环境信息，确认访问方式与任务适配后再比较租赁方案。若涉及长期、稳定的重负载或必须连接本地物理设备，则先评估自购设备或实验室现有主机；远程 Mac 并不自动适合所有工作流。