GitHub Actions 的 macOS Runner 计费文档显示，标准 macOS Runner 的公开费率为每分钟 0.062 美元，Apple Silicon 的 macOS 大型 Runner 为每分钟 0.102 美元；自托管 Runner 则不会按 GitHub Actions 执行分钟直接计费，但会转化为设备、空闲容量和运维成本。GitHub Actions Runner 计费参考
因此，结论很明确：
- 低频、波动明显、不依赖固定环境：优先使用 GitHub 托管 Runner。
- 稳定高负载、依赖私有网络、固定 Xcode、持久缓存或固定签名环境：优先使用自托管远程 Mac。
- 大多数企业：采用混合方案。托管 Runner 承接弹性任务，自托管 Runner 承接受控生产任务。
这篇文章适合管理多个 iOS 项目、正在控制构建用量与排队时间的平台负责人。
如果团队还在评估购买 Mac、托管 Mac 或租赁 Mac 构建节点，也可以用下面的指标直接建立采购边界。
[ SECTION_01 ] 先用工作负载指标划定选型边界
GitHub Actions macOS Runner 选型不应从“托管还是自托管更先进”开始，而应从实际工作负载开始。建议先统计连续两周的构建记录，至少记录月度构建时长、峰值并发、平均排队时间、任务波动、私有网络访问和缓存依赖。
| 工作负载指标 | 更偏向托管 Runner | 更偏向自托管远程 Mac |
|---|---|---|
| 构建频率 | 低频或波动明显 | 每天持续运行，负载稳定 |
| 并发需求 | 短时间突发并行 | 长时间保持固定容量 |
| 环境要求 | 可由脚本重复安装 | 固定 Xcode、SDK 或系统设置 |
| 网络依赖 | 只访问公开依赖 | 需要内网、私有仓库或内部服务 |
| 缓存需求 | 缓存命中收益有限 | 依赖大型且持久的本地缓存 |
| 签名流程 | 临时验证或非生产构建 | 生产签名、发布和固定凭证 |
| 运维能力 | 不希望维护主机 | 有平台工程团队负责节点 |
托管 Runner 的主要价值是不用提前准备容量。任务到达时，平台提供执行环境；任务结束后，团队不必继续承担节点空闲成本。大型 Runner 还支持并发配置，但其虚拟机池规模较小，首次任务可能出现分配等待。大型 Runner 官方说明
自托管远程 Mac 的优势则是环境可控。节点可以长期保留工具链、缓存和内部网络访问权限，但这也意味着团队必须负责系统升级、Runner 在线状态、磁盘清理、故障恢复和凭证隔离。
[ SECTION_02 ] 成本核算要看完整 TCO，而不是单价
托管 Runner 的基础成本可以写成：
托管成本
= Σ（每个工作流的计费分钟 × 对应 Runner 每分钟费率）
+ 并发与缓存相关成本
+ 重复安装和环境初始化造成的时间成本
GitHub 会将每个任务使用的分钟数及不足一分钟的部分向上取整。当前官方费率页面列出，标准 macOS 3 核或 4 核 Runner 为每分钟 0.062 美元，macOS 12 核大型 Runner 为每分钟 0.077 美元，macOS 5 核 M2 Pro 大型 Runner 为每分钟 0.102 美元。大型 Runner 只对实际执行工作流的时间计费，未被工作流使用时不会因为创建 Runner 而产生执行费。官方费率表
自托管远程 Mac 的成本应采用另一套口径：
自托管成本
= Mac 资源周期成本
+ 空闲容量成本
+ 初始配置与镜像维护
+ macOS、Xcode 和 Runner 更新
+ 监控、告警与备份
+ 故障处理工时
+ 安全审核与凭证管理
可以把下面的模板复制到采购表中。没有企业账单或真实节点记录时，不应直接填入节省比例。
| 成本变量 | 记录方式 | 托管 Runner | 自托管远程 Mac |
|---|---|---|---|
| 构建执行时间 | 每月实际计费分钟 | 分钟 × 官方费率 | 计入节点占用与并发损耗 |
| 峰值并发 | 同时运行的最大任务数 | 记录排队与扩容需求 | 记录需要预留的节点数 |
| 初始化时间 | 每次任务安装工具和依赖的时间 | 计入构建耗时 | 计入镜像维护与缓存维护 |
| 缓存收益 | 命中率、节省时间 | 以工作流结果统计 | 以节点级缓存统计 |
| 运维工时 | 每月平台工程投入 | 账单、权限和工作流维护 | 主机、系统、Runner、故障处理 |
| 安全成本 | 凭证、隔离、审计 | 重点检查托管边界 | 重点检查节点残留与横向访问 |
如果构建任务只是偶尔执行，购买或长期保留 Mac 容量会产生空闲成本。相反，如果生产构建每天持续运行，自托管节点的固定成本可能更容易预测。最终判断应使用企业真实账单和节点记录，而不是拿公开费率直接推算年度节省。
[ SECTION_03 ] 吞吐量决定扩容方式
吞吐量不等于单次构建速度。平台负责人至少要拆开看四个指标：
- 排队时间：任务提交到 Runner 接收任务的等待时间。
- 初始化时间：安装 Xcode 工具、依赖和脚本所需时间。
- 实际构建时间：编译、测试、归档和签名的执行时间。
- 峰值恢复时间：并发突然增加后，系统恢复到可接受排队水平所需时间。
托管 Runner 适合短时间出现的并发峰值。团队不必为全天候峰值提前准备物理容量，但大型 Runner 可能需要等待虚拟机分配，且并发上限、仓库权限和预算设置都会影响实际吞吐。大型 Runner 排队与并发说明
自托管远程 Mac 更适合稳定生产负载。工具链和依赖可以保留在节点中，减少重复安装；多个项目也可以通过 labels 或 Runner Group 路由到指定节点。不过，节点数量不足时，排队问题不会自动消失，反而会转化为企业自己的容量规划问题。
基准测试必须保持变量一致：
- 使用同一个 iOS 项目和同一提交版本。
- 固定 Xcode、macOS、依赖锁定文件和构建参数。
- 分别记录冷缓存与热缓存结果。
- 记录至少一次低并发和一次峰值并发。
- 不要用不同项目的构建时长直接比较两类 Runner。
如果生产任务的构建步骤稳定、缓存收益明显，可以将这些任务固定到自托管节点；测试矩阵、临时分支和突发回归任务则交给托管 Runner。
[ SECTION_04 ] 兼容性取决于架构与环境控制
GitHub 官方文档列出的 macOS 大型 Runner 包括 Intel 12 核、30 GB 内存的规格，以及 arm64 M2、5 核并带 GPU 硬件加速的规格。对应的工作流标签包括 macos-15-large、macos-15-xlarge 等，实际可用标签应以发布时的官方 Runner 文档为准。macOS 大型 Runner 规格与标签
Apple Silicon 适合需要原生 arm64 工具链的 iOS CI/CD 场景，但不能只看到架构名称就完成兼容性判断。官方明确说明，GitHub 提供的 Action 兼容 arm64；社区 Action 则可能不兼容，部分工具需要在任务运行时手动安装。
还需要注意两个边界：
- arm64 macOS Runner 没有静态 UUID 或 UDID。
- Intel macOS Runner 具有官方文档列出的静态 UDID，固定设备标识需求可能因此影响选型。
- macOS 大型 Runner 当前不支持嵌套虚拟化。
- macOS 大型 Runner 的网络能力与静态 IP 能力存在限制，私有网络接入不能只按 Linux Runner 的经验设计。
固定 Xcode、小众 SDK、内部脚本、专用证书和持久缓存，更适合受控的自托管远程 Mac。第三方 Action 的兼容性必须通过项目级实测确认，不能把社区反馈当成平台保证。
[ SECTION_05 ] 安全边界决定哪些任务可以进入自托管节点
自托管 Runner 最大的风险，不是机器离线，而是工作流代码能够执行什么操作。官方建议自托管 Runner 主要用于私有仓库，因为公共仓库的 Fork 可能通过 Pull Request 触发危险代码，并在 Runner 主机上执行。添加自托管 Runner 的安全警告
企业至少应完成以下隔离：
- 将生产签名节点放入独立 Runner Group。
- 只允许明确的私有仓库访问该组。
- 用 labels 区分测试、预发布和生产任务。
- 限制哪些工作流可以调用生产节点。
- 不让不受信任的 Pull Request 进入含签名证书的环境。
- 对临时文件、构建产物、钥匙串和环境变量执行任务后清理。
- 定期轮换注册令牌、签名凭证和访问令牌。
- 让节点只访问必要的代码仓库、包仓库和内部服务。
Runner Group 可以作为组织级安全边界，用于限制哪些组织、仓库和工作流访问指定 Runner，也可以设置并发限制来控制容量和成本。Runner Group 官方文档
⚠️ 经验提醒：不要把“自托管”理解成“完全私有且天然安全”。只要工作流能在节点上执行脚本，节点上的凭证、缓存和网络访问权限就必须按生产资产管理。
[ SECTION_06 ] 运维责任需要纳入最终评分
托管 Runner 把大量主机责任交给平台，但企业仍然需要维护工作流、依赖锁定、权限策略、缓存策略和失败重试逻辑。自托管 Runner 则要求企业或服务提供方承担更多基础设施责任。
自托管节点注册时，需要在目标机器上下载 Runner 应用、执行配置脚本并使用有时效的注册令牌。官方文档说明，配置脚本使用的令牌有效期为 1 小时；Runner 应用必须保持活动状态，才能继续接收任务。自托管 Runner 添加步骤
| 评估维度 | 托管 Runner | 自托管远程 Mac | 混合方案 |
|---|---|---|---|
| 环境控制 | 3 / 5 | 5 / 5 | 5 / 5 |
| 突发扩容 | 5 / 5 | 2 / 5 | 5 / 5 |
| 固定缓存 | 2 / 5 | 5 / 5 | 5 / 5 |
| 私有网络 | 视网络能力而定 | 5 / 5 | 5 / 5 |
| 日常运维 | 5 / 5 | 2 / 5 | 3 / 5 |
| 生产签名控制 | 3 / 5 | 5 / 5 | 5 / 5 |
| 预算可预测性 | 3 / 5 | 4 / 5 | 4 / 5 |
| 高峰排队风险 | 3 / 5 | 3 / 5 | 4 / 5 |
评分不是普遍排名，而是帮助平台负责人确认责任归属。低频团队更看重免维护和弹性；稳定生产团队更看重环境持久性；多项目企业则更需要按任务类型拆分节点。
[ SECTION_07 ] 企业可按三档方案落地
低频或小团队
选择托管 Runner。把依赖安装、Xcode 选择、测试和归档流程写入工作流。先通过缓存和依赖锁定减少重复初始化，不要因为偶尔出现排队就立即购买固定节点。
稳定生产团队
选择自托管远程 Mac。固定生产 Xcode 和签名流程，建立独立 Runner Group，并为节点配置监控、磁盘告警、Runner 在线检查和故障切换。测试任务仍可使用托管 Runner，避免生产节点被非关键任务占满。
多项目企业
选择混合部署。生产发布、私有网络依赖和固定签名任务进入自托管节点；分支验证、临时回归、突发并行任务进入托管 Runner。通过 runs-on、labels 和 Runner Group 明确路由，避免工作流随机落到错误环境。
如果团队正在评估远程节点容量，可以先查看 NOVAKVM 的远程 Mac 方案入口，再根据实际项目确认 Apple Silicon、访问方式和租赁周期。对于需要固定 Mac 环境的团队，也可以参考 Apple Silicon 远程 Mac 配置 作为自托管节点的资源评估对象。
[ SECTION_08 ] 一页式采购决策矩阵
| 如果团队满足这些条件 | 推荐方案 | 主要原因 | 采购前必须确认 |
|---|---|---|---|
| 构建低频、任务波动明显 | 托管 Runner | 不为峰值提前保留容量 | 费率、并发、排队、缓存命中 |
| 需要私有网络和内部依赖 | 自托管远程 Mac | 网络边界和访问路径可控 | 防火墙、权限、监控、故障恢复 |
| 固定 Xcode 或小众 SDK | 自托管远程 Mac | 环境可持久化 | 镜像、升级窗口、回滚方案 |
| 生产签名任务较多 | 自托管或混合 | 便于隔离证书和工作流 | Runner Group、凭证轮换、任务清理 |
| 测试任务有明显峰值 | 托管或混合 | 可按需吸收并发 | 预算上限、并发策略、失败重试 |
| 多项目且负载差异大 | 混合部署 | 按任务类型分流 | labels、工作流规则、容量预留 |
当前方案如果是“每台开发者 Mac 兼做打包机”，常见缺点是环境漂移、设备被个人任务占用、签名材料难以集中审计；如果是长期自购 Mac 服务器，还要承担折旧、闲置容量、系统升级和硬件故障处理。对于只需要临时算力、固定构建节点或阶段性扩容的企业，租赁 NOVAKVM 的远程 Mac 可以把节点采购和维护责任转化为可规划的周期性资源，更适合先验证两周构建数据，再决定是否长期保留容量。
真正的落地顺序应是：先统计工作负载，再按成本、吞吐、安全、兼容性和运维责任评分；如果生产任务确实需要固定 Xcode、持久缓存或私有网络访问，再进入远程 Mac 构建节点部署与容量评估，而不是先购买设备。