macOS-14 Runner 退役后，企业 CI 预算应该从哪里重新算？

先从组织账单和工作流运行记录取数，按工作流拆出运行次数、实际计费分钟、使用的 Runner 类型、配额抵扣和存储成本，再分别估算替换承载。GitHub 对计费分钟的取整和适用规则要以核算当日官方文档及账户账单为准；不要把公告中的排队提示当成已发生的支出。

iOS CI 里哪些任务必须留在 Mac Runner 上？

凡是依赖 Xcode、Apple SDK、iOS 模拟器、Apple 平台签名或归档发布的环节，通常需要在兼容的 macOS 环境执行；通用脚本、静态检查、部分依赖准备和与 Apple 工具链无关的测试，可以先验证后分流到 Linux 或其他环境。是否可分流由实际依赖和测试结果决定，不能只按工作流名称推断。

比较托管 macOS Runner、自建 Mac 和远程 Mac 时要算哪些成本？

托管 Runner 看计费分钟、配额、存储和并发；自建 Mac 还要计入采购、折旧、机房或办公网络、维护工时、备机与故障恢复；远程 Mac 则核对所选机型、租赁周期、公开价格、接入方式和服务条款。三种方案都应单列凭证管理、环境隔离和产物留存的控制成本。

Mac CI 预算需要把空闲时间和运维工时算进去吗？

需要，但要区分方案：托管 Runner 通常按任务执行的计费时长核算，不应把未运行的机器时间直接当成同类费用；自建设备的空闲容量仍占用已购资源，也会带来折旧和维护责任；远程租赁则按实际套餐周期核对费用。运维工时、故障恢复和安全控制应另列，不能混进 Runner 分钟单价。

GitHub Actions macOS-14 退役前，企业 CI 预算怎么算？2026

这篇文章面向需要在 macOS-14 Runner 退役前重新规划 CI 承载与预算的企业 IT、平台、FinOps 和采购负责人。核心建议是先按真实运行记录识别必须使用 Mac 的任务，再比较托管、自建与远程 Mac 的计费、闲置、维护和安全责任，并用条件式决策确定试点范围。

GitHub Actions macOS-14 退役企业 CI 预算，别从 Runner 分钟单价直接推导替代方案：先拆出必须运行在 macOS 的任务，再按真实用量、组织配额、存储、运维投入和交付周期核算。对多数团队，本周先把可分流工作负载与必须留在 Mac 上的工作负载分开，优先评估任务分流或混合承载；只有数据验证适配后，才扩大自建或远程 Mac 规模。

企业 IT 或平台负责人：需要在 2026 年 11 月 2 日前确定替代承载和预算边界。
FinOps 或采购负责人：需要把 Runner 账单、设备占用、运维与扩缩容放进同一套模型。
CI/CD 负责人：需要区分必须依赖 Apple 工具链的任务，以及经过验证后能够分流的任务。

最后更新于 2026 年 10 月 27 日；退役日期、标签与队列提示核实自 GitHub 官方退役公告。

GitHub Actions macOS-14 退役企业 CI 预算，先划清核算边界

GitHub 已确认，macos-14、macos-14-large 和 macos-14-xlarge 镜像计划于 2026 年 11 月 2 日退役；公告还提示，退役前可能减少相关 Runner 容量，导致队列时间增加。这个提示说明的是潜在排队风险，不代表你的团队已经发生了成本增长，也不能据此估算新增费用。替代标签和计费口径应按你核算时的官方文档重新确认。(GitHub 官方退役公告)

预算问题也不同于迁移排障：这里要比较的是任务改由何种环境承载、需要谁维护，以及支出怎么随实际用量变化。比如，把工作流切到其他 macOS 标签，可能改变镜像、工具链或计费情况；先确认任务依赖和候选环境，再谈成本，避免把“标签改了”误当成“预算不变”。

在拿到运行记录前，至少有几项隐性成本不能忽略：Runner 配额可能影响账单；计费时间的取整和倍率会影响估算；自建机器的闲置容量不会因没有任务而消失；远程接入还需核验网络与凭证控制；故障恢复、Runner 更新和产物保存也会占用团队工时。GitHub 的计费文档说明，私有仓库的托管 Runner 分钟与存储按账户配额及使用情况核算，具体规则需对照当前账户账单。(GitHub Actions 计费说明)

CI 平台负责人：按流水线证据拆分必须用 Mac 的任务

不要用“iOS 工作流”这个名称直接推断整条流水线都必须跑在 Mac Runner 上。把工作流拆成执行阶段，结合日志、runs-on 标签、运行时长、任务成功率和发布关键性分类：Xcode 构建、Apple SDK 编译、模拟器测试、签名与归档发布通常需要兼容的 macOS 环境；通用脚本、部分依赖准备、静态检查或不依赖 Apple 工具链的测试，则可逐项验证是否能在其他环境运行。

每个候选分流任务都要有验证证据：目标环境安装的工具是否兼容、测试结果是否一致、产物是否可供后续 Mac 阶段使用，以及失败时能否回退。对于 macos-14 到其他标签的变更，也要检查实际镜像和工具版本，而不是仅凭标签名称判断等价。GitHub 的 Runner 选择文档列出可用环境及选择方式；组织的工作流记录则用于确认你自己的任务究竟跑在哪类 Runner 上。

⚠️ 公告中的队列时间提示不是团队的成本数据。预算表应填入你自己的运行次数、计费分钟和账单金额，不要把尚未测得的排队影响写成确定支出。

FinOps 负责人：用账单和运行记录建立可复算模型

先以一个账期为单位整理数据，再把实际发生额与预测值分开。对托管 Runner，可将每类工作流的执行次数乘以该类任务的计费时长与适用费率，合计后再按账户实际配额、倍率、存储和其他收费项复核：

托管 Runner 月度估算 = 各类任务的运行次数 × 单次计费时长 × 对应计费规则 + 可计费存储及其他适用费用 − 可用抵扣

月度预测确认后，年度估算应采用已知账期数据和工作负载计划，并单独注明峰值发布月、季节性变化或尚未确认的假设；不要简单用某一周的用量外推全年。GitHub 的 Runner 定价文档说明了各类 Runner 的费率与计费规则，并指出作业分钟会向上取整；而计费规则还涉及账户配额和存储。作业页显示的 billable time 不含适用的分钟倍率，因此不能只把某个显示时长乘以单价就当作最终账单。

预算输入	从哪里取数	需要避免的误差
运行次数、实际时长、标签	工作流运行记录与账单周期	不用平均值掩盖发布峰值；不把公告队列提示当作已发生的计费时长
计费规则与组织配额	核算当日官方定价文档、账户计划和账单	核实 Runner 类型、取整、适用倍率及配额范围
产物、缓存与镜像存储	组织用量与存储设置	不把删除后的当前占用误认为当期已经累积的存储费用
自建或远程 Mac 费用	采购记录、公开报价、服务条款	单列闲置容量、备机、接入、安全控制和维护工时

这张表的关键不是给出统一费率，而是让每个数字都能追溯到记录或当前规则。敏感性分析至少改变三类输入：运行次数、单次执行时长、并发峰值。若结论只在某个未经证实的任务比例或时长假设下成立，就把它标作待验证情景，不要作为采购承诺。

平台运维负责人：比较承载方式与团队责任

下表是责任侧的定性评分，不是性能排名：✅ 表示相关责任较少，△ 表示仍需承担部分配置或维护，⚠️ 表示需要团队明确安排专人或流程。实际支出必须用你的账单、报价与工时记录填充。

评估维度	托管 macOS Runner	自建 Mac Runner	远程 Mac 租赁
弹性与突发并发	✅ 按使用托管资源；仍受计划、配额和并发规则影响	⚠️ 扩容依赖设备采购或现有容量	△ 按实际可选配置与租期核验，不能假定自动扩缩容
机器维护与更新	✅ 主机由托管方管理；工作流依赖仍需你维护	⚠️ 主机、系统、Runner 版本与故障均要安排责任人	△ 需核对服务边界，并自行管理工作流、凭证和环境
空闲资源与资产	✅ 不把未执行任务时长自动当成任务计费	⚠️ 设备闲置仍占用已采购资产	△ 租期内未运行时是否仍计费，按套餐周期核对
恢复与隔离	△ 检查 Runner、网络和仓库访问控制	⚠️ 自行设计备份、清理、隔离与恢复	△ 不能仅凭“远程”或“独立机器”推断任务隔离，需验证控制与条款

自托管 Mac Runner 的账面 Runner 分钟可能不收费，但这不等于零成本：硬件采购、折旧、监控、系统更新、故障替换和平台工程工时，都应进入 TCO。GitHub 的自托管 Runner 参考文档还建议使用临时 Runner 做自动扩缩容；单任务后注销并清理环境有助于降低任务间敏感资源残留的暴露，但日志转存和清理自动化也需要维护。

安全约束可能直接排除某个承载选项。先列出私有网络访问、签名凭证使用边界、主机访问权限、仓库范围与任务隔离要求，再确认候选方式能否满足。尤其是 GitHub 文档指出 macOS 大型 Runner 不提供静态 IP 和 Azure 私有网络能力；如果你的访问策略依赖这类能力，就不能把 Linux、Windows Runner 的功能直接套用到 macOS。托管标签、远程访问方式或机器独占描述，都不能替代你自己的安全验收。(GitHub 大型 Runner 文档)

采购与 FinOps：远程 Mac 预算输入和试点条件

VPSMAC 当前公开页面列出日租、周租、月租与季租，也列有不同 Mac mini 配置及对应的公开日租价格；例如页面显示的机型包括 Mac mini M4 和 Mac mini M4 Pro。这些标价只能作为核算时的公开报价输入，不是你的最终租赁成本：下单前还要核对所选配置、租期价格、交付方式、访问方式及适用服务条款。可从VPSMAC 当前租赁方案核对配置与价格；未在页面核实的 SLA、隔离或恢复承诺不要写入预算假设。

成本比较时，将租金或设备采购等直接支出，与团队投入的维护、安全、签名凭证管理和故障恢复工时分开记录。这样才能看出“Runner 分钟更便宜”是否被空闲资源和运维责任抵消，也能发现某个安全硬条件使候选方案根本不适用。

决策条件

若任务主要依赖 Apple 工具链，且托管 Runner 的实际账单与队列表现满足发布要求，先切换到经验证的可用标签，并保留托管承载。
若记录显示大量可分流的通用任务，且目标环境验证通过，先把这些任务迁出 Mac；Mac 留给构建、模拟器、签名和发布环节。
若负载稳定、设备利用充分，并且团队已经具备更新、隔离、监控与恢复能力，再把自建 Mac Runner 纳入试点；若这些责任没有明确负责人，则回退到托管或混合方案。
若需要短期增加真实 Mac 容量、又不希望先采购设备，可评估企业远程 Mac CI；只有在租期、配置、访问权限、交付和安全条款核实后，才将对应报价纳入预算。
若任何方案无法满足签名凭证、私网访问或任务隔离的硬性要求，先排除该方案，不用低单价抵消安全缺口。

试点范围限定为一组代表性工作流，记录运行时长、成功率、队列表现、维护投入、凭证控制和恢复过程；复核周期按你们的预算和发布节奏设定，不预填虚构天数或工时。若账单无法对平、关键发布任务失败，或安全验收未通过，就停止扩容并回退到已验证的承载方式。

预算 FAQ：把四个关键问题落到记录上

macOS-14 退役后，CI 成本从哪里重新估算？

从组织账单、作业运行记录和存储用量开始，按 Runner 类型分别汇总运行次数与计费时长，并核对当前配额、计费规则和倍率。把已发生支出与队列风险等预测情景分开，才能避免把公告提示误记为实际账单。

哪些 iOS CI 任务要留在 Mac Runner？

逐个检查是否调用 Xcode、Apple SDK、模拟器、签名或归档发布流程；这些依赖通常意味着需要 macOS 环境。通用脚本或独立测试只有在目标环境跑过验证、产物衔接正确且回退可行后，才纳入分流范围。

三种 Mac CI 承载方案应如何对比？

托管 Runner 用实际账单与配额衡量；自建 Mac 加入购置、折旧、空闲、维护和恢复成本；远程 Mac 则加入当前租期报价、配置、交付与服务边界。所有方案都另外列出安全控制工时，避免用硬件价格或单价代替完整 TCO。

空闲时间与运维工时是否属于预算？

都应纳入，但不能混成一种费用。托管 Runner 以实际计费任务为主，自建 Mac 要承担设备闲置与维护责任，远程租赁需按整个租期核对未运行时的费用；计费依据用账单或租赁条款，运维工时用团队记录。

做完这套核算后，如果当前方案仍以托管分钟为主，你要留意配额、计费规则与退役前队列变化；如果改为自建，则要承担设备采购、空闲折旧、持续维护和故障恢复。临时增容或试点真实 Mac 工作负载时，远程 Mac 可作为另一个候选，但只有在公开配置、租期价格和服务条件符合团队要求后才纳入比较。你可以先核对 VPSMAC 当前 Mac 方案的公开配置与租赁周期，再用同一套变量模型与托管、自建方案对账；不需要临时容量或必须持有物理接口的团队，则未必适合租赁。