自托管runner私有库每分钟$0.002、消耗免费额度，2026年3月这刀落下后自托管还比托管便宜吗？

目录

一、导语：一次计费口径变化，为什么值得写一篇长文

CI/CD 的成本问题长期被“免费额度”掩盖。对多数团队而言，托管 Runner 的账单在总云支出中占比不高，于是“自托管更便宜”几乎成了一种默认共识：机器是自己的、分钟不要钱、还能装任意依赖。但这个共识有一个隐含前提——自托管的成本被记在了“别人看不见的地方”：平台工程师的时间、闲置机器的折旧、缓存与出口流量、失败重跑带来的额外机时。一旦托管侧把“私有库按分钟计价、并消耗免费额度”的口径明确下来，这个隐含前提就被摆到了台面上。

本文的分析主线只有一条：把托管与自托管都折算成“每有效构建分钟成本”，再求盈亏平衡点。所有章节都服务于这条主线——背景章节解释口径为什么变，原理章节给出折算公式，数据章节做三组可复算的测算，对比章节讨论边界条件，操作章节给出迁移路径。笔者认为，讨论“自托管还便宜吗”如果不先定义“便宜”的计量单位，就会退化为立场之争；而一旦统一到“有效构建分钟”，答案会变得可计算、可验证、也可被证伪。

提示：本文涉及的价格与额度均为公开计费页面的口径整理，具体以各平台当期计费文档为准；涉及自建集群的机时、折旧与人力数据，除注明来源外均为模拟测算，用于演示方法而非给出绝对结论。

二、背景与问题定义：从“免费分钟”到“按分钟计价”的口径迁移

2.1 计费对象的迁移：从“仓库可见性”到“执行时长”

托管 CI 的计费模型大体经历了两代。第一代以“仓库可见性”为分界：公开仓库免费、私有仓库给一定免费额度，超出后按分钟计价。第二代则更强调“执行资源”的差异化：不同规格的 Runner（CPU、内存、GPU、ARM）对应不同单价，分钟数按规格加权。GitHub 的计费文档长期采用“按作业运行分钟计费、不同操作系统倍率不同”的口径，并对私有仓库账户给予月度免费分钟与存储额度（来源：GitHub Docs, “About billing for GitHub Actions”，持续更新）。本文评述：这一代模型的关键变化不是“涨价”，而是把计费锚点从“仓库属性”移到了“资源消耗”，这为后续把自托管也纳入同一坐标系提供了可能。

所谓“私有库每分钟 $0.002、消耗免费额度”，在工程上应理解为两层含义：其一，私有仓库的构建分钟不再被默认为“零边际成本”，而是有明确单价；其二，账户级免费额度是“先扣后计费”的池子，额度耗尽后每一分钟都产生现金支出。本文评述：这两层含义叠加，使得“构建分钟”从技术指标变成了财务指标，CI 优化第一次有了直接的 ROI 口径。

2.2 问题定义：三个必须同时回答的子问题

要回答“自托管还比托管便宜吗”，必须同时回答三个子问题，缺一不可：（1）单位成本怎么算——托管是“分钟单价×计费分钟”，自托管是“机时折旧+运维人力+网络与存储+失败重跑”；（2）有效产出怎么度量——不是“跑了多少分钟”，而是“多少分钟产出了可合并的构建结果”；（3）边界条件是什么——构建量、缓存命中率、并发峰值、合规要求、团队规模，都会改变结论。

本文把“有效构建分钟”定义为：作业从开始执行到产出可用制品（或明确失败）的墙钟分钟，扣除排队与人为等待，再乘以“一次通过率”的修正。这个定义的好处是，它同时惩罚“慢”和“不稳”：失败重跑会拉低一次通过率，从而抬高每有效构建分钟成本。笔者认为，很多“自托管更便宜”的结论，恰恰是因为只算了机时、没算重跑。

三、原理与技术路线：把 CI 成本还原为“有效构建分钟”

3.1 统一成本模型：托管侧与自托管侧的同构表达

设某账户月度私有库构建的“计费分钟”为 M，托管分钟单价为 p，免费额度为 F，则托管侧月度现金成本可写为：

C_hosted = p × max(0, M − F) + C_storage + C_egress

自托管侧则要把“机时”拆成可折旧的资本支出与可计量的运营支出。设集群月度可用机时为 H，机时综合成本（含折旧、电费、机房或云主机租金）为 c，运维人力月成本为 L，则：

C_self = c × H_used + L + C_net + C_store + C_rerun

两边再除以“有效构建分钟” E，就得到可比的单位成本 u = C / E。本文评述：这个同构表达的价值在于，它把“自托管不要钱”的直觉拆成了四项可观测变量；只要其中任意一项被低估，结论就会系统性偏向自托管。

3.2 盈亏平衡点的推导与敏感性

令 C_hosted = C_self，在忽略存储与出口的简化情形下，可解出临界计费分钟：

M* = F + (c × H_used + L) / p

这个式子说明三件事：第一，免费额度 F 直接抬高临界点，额度越大，自托管越难“回本”；第二，运维人力 L 是分子里最刚性的部分，一个 0.5 FTE 的平台工程师成本，往往需要数十万分钟才能摊平；第三，单价 p 越低，临界点越高，自托管越不划算。笔者认为，很多团队在估算时只看了 c × H_used，却漏掉了 L，这是结论失真的主要来源。

3.3 技术路线：自托管 Runner 的三种部署形态

自托管并非只有一种形态。工程上常见三类：（a）单机常驻型，一台虚拟机跑 actions-runner，适合小团队但隔离性弱；（b）容器编排型，用 Kubernetes + Actions Runner Controller（ARC）按需伸缩，隔离性好但引入集群运维成本；（c）弹性云主机型，用云厂商的竞价实例或自动伸缩组，兼顾弹性与成本。GitHub 官方文档对 self-hosted runners 的说明明确指出：自托管 Runner 由用户自行维护、需自行承担安全与更新责任（来源：GitHub Docs, “About self-hosted runners”）。本文评述：这三种形态的 L 差异极大，选型时若把 (a) 的人力成本套到 (b) 上，会严重低估运维负担。

四、关键数据与案例：三组可复算的测算

4.1 测算一：小团队、低构建量（模拟数据）

假设某 8 人团队，私有库月度计费分钟 6,000 分钟，免费额度 2,000 分钟，单价按题设 $0.002/分钟。托管侧现金成本约为 0.002 × (6000 − 2000) = $8。自托管侧若用一台月租 $40 的云主机，加上每月约 4 小时的运维（按 $60/小时计），仅人力就 $240。显然，这一量级下自托管不划算。本文评述：这个测算的意义不是“证明托管便宜”，而是说明在低构建量区间，人力成本是压倒性变量，任何忽略人力的比较都不成立。

4.2 测算二：中型团队、高构建量（模拟数据）

假设某 60 人团队，月度计费分钟 180,000 分钟，免费额度 3,000 分钟。托管侧现金成本约 0.002 × 177,000 ≈ $354。自托管侧若用 4 台 8C16G 竞价实例（月均 $70/台）加 0.5 FTE 运维（$2,400/月），合计约 $2,680。仍高于托管。本文评述：这说明即便构建量上升一个数量级，只要单价处于 $0.002 量级，自托管的成本优势需要更极端的条件——要么单价显著更高，要么构建量再上一个数量级，要么自托管硬件已沉没。

4.3 测算三：大型团队、硬件已沉没（模拟数据）

假设某 300 人团队，月度计费分钟 1,200,000 分钟，且已有闲置的 IDC 机柜与平台工程团队（人力视为既有编制，不新增现金支出）。托管侧现金成本约 0.002 × 1,197,000 ≈ $2,394；自托管侧增量现金成本主要是电费与网络，假设 $800/月。此时自托管占优。本文评述：这个案例的关键不是“量大就自托管”，而是“增量现金成本”与“全成本”是两个口径；用增量口径做决策，容易在硬件更新周期到来时被反噬。

五、对比与局限：自托管不是“更便宜”，而是“另一种成本结构”

5.1 成本结构的差异：可变成本 vs 固定成本

托管侧的成本是可变成本：构建量下降，账单下降；构建量上升，账单线性上升。自托管侧的成本是固定成本为主：机器买了就在折旧，人招了就在发薪，构建量下降并不会让成本下降。本文评述：这意味着两者的风险敞口不同——托管把“需求波动风险”留给了平台，自托管把“产能利用率风险”留给了自己。对于构建量波动大的团队，托管的期权价值被低估了。

5.2 局限与边界条件

本文的测算有三处明确局限。第一，未计入安全与合规成本：自托管 Runner 需要自行打补丁、做网络隔离、管理凭据，GitHub 文档也提示自托管 Runner 的安全责任在用户侧（来源：GitHub Docs, “Security hardening for self-hosted runners”）。第二，未计入缓存与制品存储的长期成本，而这类成本随构建量超线性增长。第三，未计入“平台工程能力”的机会成本——同样的工程师做自托管，就无法做别的平台能力建设。笔者认为，这三项在多数组织里都是真实存在的，只是不在 CI 账单上。

5.3 一个容易被忽略的变量：一次通过率

设一次通过率为 r，则每有效构建分钟成本会被放大 1/r 倍。若 r = 0.8，成本放大 25%。本文评述：自托管环境若缺乏标准化镜像与依赖缓存，r 往往低于托管，这会抵消掉机时上的节省。因此，“自托管更便宜”的成立条件里，必须包含“一次通过率不低于托管”。

六、操作路径：从托管到自托管的分阶段迁移与治理清单

6.1 第一步：先度量，再决策

迁移前必须先建立度量基线。建议采集四项指标：月度计费分钟、一次通过率、缓存命中率、平均排队时长。采集周期至少 4 周，覆盖一次完整的发布周期。本文评述：没有基线的迁移都是赌博；而基线一旦建立，M* 公式就可以直接代入，决策从“感觉”变成“算术”。可参考 GitHub Actions 使用文档（docs.github.com/en/actions）与 Actions Runner Controller 文档（ARC 文档）了解可采集的指标口径。

6.2 第二步：分阶段迁移

建议按“非关键路径 → 关键路径 → 全量”三阶段推进。第一阶段把文档构建、静态检查等低风险作业迁到自托管，验证镜像、缓存与网络；第二阶段迁移测试作业，重点观察一次通过率；第三阶段再迁移发布作业，并配套回滚预案。本文评述：分阶段的价值在于把“一次性大迁移”的风险拆成可观测的小步，每一阶段都用 u = C / E 复核，不达标就停在上一阶段。

6.3 第三步：治理清单

延伸阅读可参考持续交付领域的经典著作《Continuous Delivery》（Humble & Farley）中关于构建流水线度量的章节，以及《Accelerate》中关于部署频率与变更失败率的研究（Forsgren 等，2018）。本文评述：这些研究提供的不是价格数字，而是“用什么指标衡量流水线健康”的方法论，恰好可以迁移到成本治理上。

七、结论与展望：2026 年之后，CI 成本治理的三种走向

回到最初的问题：2026 年 3 月计费口径变化之后，自托管还比托管便宜吗？本文的答案是条件性的“是”——在构建量大、硬件已沉没、平台工程能力成熟、一次通过率不低于托管的场景下，自托管的单位成本仍可能更低；但在中小构建量、缺乏运维能力、构建波动大的场景下，托管依然是更优解。计费口径变化真正改变的，不是“谁更便宜”，而是“便宜必须被证明”。

展望未来，笔者认为 CI 成本治理会走向三个方向：其一，成本可观测性内生化，流水线平台会原生提供每作业的成本标签；其二，混合调度常态化，托管与自托管按作业特征动态分流；其三，单位成本成为工程指标，与部署频率、变更失败率并列进入团队仪表盘。无论走向哪一条，本文的 u = C / E 模型都可以作为起点——它不预测价格，但它让讨论有了共同的计量单位。

主要参考文献与资料