RunPod 自建推理 vs 直接调 API：成本平衡点怎么算

这种会我开过不止一次：API 账单连续几个月往上走，有人把某个 GPU 云的机型价目表截图贴到群里，再把它跟 API 的每百万 token 价格摆在一起，得出”自己跑能省一半”的结论，然后项目就立项了。三个月后复盘，账单没降多少，但多了一个没人愿意接手的推理服务。

问题不在那张截图错了，而在于那两个数字根本不能放在一起看——一边是”租一台机器一小时多少钱”，另一边是”生成多少文字多少钱”。单位不一样，分母不一样，谁贵谁便宜这个结论在你把分母统一之前是不存在的。

所以这篇不打算给你任何单价，也不会给出”超过多少量就该自建”这种数字结论。这类数字一个月一变，我给了你也不能用。这篇给的是一套算法和一份清单：该把哪些项列进来、每一项按什么口径折算、哪个变量真正决定结论。数你自己填，填完那个结论才是你们团队的结论。

底下涉及 RunPod 的部分全部按官方文档的口径写，我没有拿账号去逐项核对控制台和账单的实际行为，凡是文档没写清的地方我会直说。

一、先把两边的分母统一，再谈贵不贵

调 API 的计费形状是按产出量：你发出去多少、拿回来多少，按量结算。它的好处是成本和业务量天然对齐——没人用就不花钱，用得多就多花，中间没有你需要操心的东西。

自建的计费形状是按占用时间。按 RunPod 文档的说法，Pod 的计费单位是时间，机器开着就在计，跟你有没有在跑推理无关；入口和出口流量不收费。Serverless 那一侧是按实际计算时间计，文档的措辞是从 worker 启动那一刻算到它完全停止，向上取整到秒。

这里有个容易看漏的细节：文档自己的口径就不完全一致。Pod 的定价页写的是按秒计费（compute 与 storage 都是），而产品总览和 Pods 概览页写的是按分钟计费。这两种粒度对短任务的账单差别是实打实的。我倾向于以定价页为准，但更稳的做法是在控制台上跑一个短任务，拿账单反推你实际被计的粒度——这件事只需要做一次，之后所有估算都能用。

统一分母的办法只有一个：把自建侧的”时间成本”折算成”每单位产出的成本”。也就是

自建单位成本 = 一段时间内的全部支出 ÷ 这段时间内实际完成的产出量

右边的分子是账单，好查；分母是你的服务在这段时间里真正干了多少活，难查也最容易被乐观估计。这个分母就是全文的主角。关于计费机制本身的逐条拆解，另有一篇专门写了：RunPod 计费机制拆解。

二、自建侧的成本清单：算力只是第一项

大部分人的估算只列了第一项。下面这几项每一项我都见过被漏掉，漏掉任何一项都会让结论偏向”自建更便宜”。

算力时间。 这是唯一会被列进去的那项。注意要算的是”机器开着的时间”，不是”处理请求的时间”。开发期、调试期、忘了关的那两天，都在这一项里。

存储，而且停机不等于停止计费。 这是最常被忽略的一笔。按文档的说明，Pod 的三种存储计费行为不同：container disk 只在运行中计费、停机即被擦除；volume disk 是持久盘，文档对运行中和停机两种状态分别列了费率，也就是说 Pod 停着盘还在计；network volume 独立于 Pod 存在，按容量单独计。粒度也不同——文档说 container disk 和 volume disk 按秒计，network volume 按小时计。一句话：“把 Pod 停掉省钱”这个动作只省掉了算力那一段，盘还在收钱。 别在估算表里假设停机就自动归零——它是一个独立的、会持续发生的成本项，而且是唯一一笔”你以为已经关掉了”的钱。

冷启动与空闲里不产出的时间。 Serverless 的定价页把计费拆成了三段：start time（起容器、把模型权重加载进显存）、execution time（真正处理请求）、idle timeout duration（处理完之后保持活跃、等后续请求的那段时间）。三段都计费，但只有中间那段在产出。这意味着请求越稀疏、越是一个一个孤零零地来，你付出去的钱里不产出的比例就越高。

镜像与环境的维护。 自己打镜像、跟框架版本、跟驱动和 CUDA 兼容性、模型换代重新验证。这一项不出现在任何账单上，但它每个月都在发生。

失败与重试的重复计算。 任务跑飞、OOM、结果不对重跑一遍，算力照付。文档专门提到可以设 execution timeout 来防止跑飞的任务无限烧——这个配置本身就说明这类支出是真实存在的。文档也写了一条对你有利的：如果宿主机不可用，那段时间不计费。但你的任务因此失败带来的返工，账得自己算。

资金占用与承诺风险。 文档里的 savings plan 是预付制，按固定期限承诺（文档列的是三个月和六个月两档），换来算力部分的折扣。三条机制必须写进你的估算：它只覆盖 GPU 算力，存储按标准费率另算；它不可退款、有固定到期日；停掉 Pod 之后，这个计划会自动应用到你下一次同一 GPU 型号的部署。最后那条是隐性约束——预付相当于把自己锁在一个机型上，而你半年内换卡的概率有多大，只有你自己知道。

账户层面的运营风险。 这一项不是钱，但会变成钱。文档写得很清楚：余额归零时 Pod 会被自动停掉，挂了 network volume 的会被保留并保住数据，没挂的会被终止、数据不可恢复。另外部署按需实例前，账户里至少要有所选配置一小时用量的余额；账户还有一个跨全部资源的每小时消费上限，默认值是有限的，要提额得联系官方支持。这几条合起来的意思是：自建多了一类 API 侧完全不存在的运维职责——看着余额和额度。

人力。 单独一节讲，因为它是另一个主角。

三、利用率为什么是决定性变量

把上面这些填进第一节那个公式，你会发现一件事：分子的大头是按时间收的，分母是按产出算的，连接这两者的桥就是利用率。

设你的机器在一个月里开着的时间是 T，其中真正在处理请求的时间是 U。那么

单位产出的算力成本 ≈ 单位时间算力费 × T ÷ 产出总量，而产出总量 ≈ 单位时间产能 × U

约一下就能看出来：单位成本和 U/T 成反比。 利用率折半，你的单位成本就翻倍。这不是一个”优化项”，它是量级级别的杠杆。而 API 那一侧的利用率恒等于百分之百——你不调用，它不收钱。这是两种形态最本质的成本差异，比任何单价对比都重要。

于是你真正该问的不是”单价谁低”，而是这三个问题：

1. 你的流量在一天里的形状是什么样的？ 白天集中、夜里空着的负载，按时间租一整月，等于为夜里那些小时付了全额。
2. 你能不能把闲着的时间填上？ 同一台机器夜里跑离线批处理、跑评测、跑微调，利用率就上去了，单位成本跟着下来。填不满就填不满，别在估算里假设自己填得满。
3. 峰值要不要靠这台机器扛？ 按峰值配容量，平峰期的利用率必然低；按平峰配容量，峰值就得有别的兜底——通常是回落到 API。混合形态比纯自建更常见，这也是文档自己建议的思路：几种产品可以组合用，Pod 做开发实验、Serverless 跑生产推理。

更一般的成本建模口径，我写在成本模型那篇里，这里只落 RunPod 这一侧。

四、Serverless 没有消灭利用率问题，只是把它换了个形状

看到”空闲不计费”，很多人以为利用率这道题被绕过去了。按文档暴露的机制看，它是被转移了，转移成了下面这几个新问题。

转移成了每次唤醒的固定开销。 冷启动那段时间是计费的，而它不产出。请求越零散，这笔固定开销摊到每个请求上就越重。缓解手段文档给了方向：用缓存好的模型、开 FlashBoot。这些手段降低的是每次唤醒的开销，不是把它消成零。

转移成了尾部等待的选择。 处理完请求后 worker 会保持活跃一段时间等后续请求，这段时间也计费。这个空闲超时是可配的：设短了，下一个请求大概率要重新冷启动；设长了，你在为等待付钱。这个参数的最优值直接由你的请求到达间隔决定——间隔明显短于超时，你就在吃缓存的好处；间隔明显长于超时，你就在反复付冷启动的钱。 这道题本质上还是利用率，只是尺度从”月”缩到了”秒”。

转移成了要不要养常驻 worker。 文档把 worker 分成两类：flex worker 空闲时缩到零，active worker 持续运行。想让端点永不冷启动，就得让 active 数大于零——而那部分算力是一直占着、一直计费的。也就是说，一旦你为了延迟去养常驻 worker，你就把第三节那个利用率问题原封不动地搬回来了，只是换了个名字。文档提到 active worker 的折扣要走销售咨询，这本身也是个信号：这条路是给流量稳定的场景准备的。

转移成了存储结构的选择。 文档建议高量且存储需求大的负载用 network volume 在多个 worker 之间共享数据，以降低每个 worker 各自的存储开销。worker 数一多，“每 worker 一份权重”和”共享一份”的差别就出来了。

Serverless 的形态细节和伸缩机制在RunPod Serverless 部署那篇里写得更细。就成本而言，我的判断是：Serverless 真正适合的是”平均量不大但必须随时可用”的负载——它把你从”为空闲时间付钱”换到了”为可用性的固定开销付钱”，哪种更划算取决于你的请求密度，而不取决于哪家单价低。

五、人力这一项怎么折，为什么它最常被漏掉

漏掉人力有个很简单的原因：它不在账单上，而估算表通常是照着账单列的。

折算口径其实不复杂，难的是诚实：

人力月成本 ≈ 工程师的全成本时薪 × 这套东西每月真实占用的小时数

右边第二项要拆成三块，别只算稳态那块：

• 一次性投入：打镜像、选型验证、压测、把服务接进现有链路、写监控和告警。这块通常被算成”反正是内部人力、不额外花钱”，但它会推迟你其他事情。
• 稳态运维：版本升级、依赖跟进、容量调整、看账单和余额。上一节说的余额归零会终止 Pod、没挂 network volume 就丢数据，这类事一旦发生，成本不是那几个小时。
• 故障期的尖峰：出问题的那几天投入会是稳态的好几倍，而且往往落在最忙的人身上。估算里给这块留空间的团队很少。

有一条经验我认为值得写进任何一份这类估算：如果这套服务只有一个人懂，那它的真实人力成本要按”两个人”算——因为迟早要么招人要么交接，而交接本身就是成本。这条文档不会告诉你。

另外别忘了观测能力也是有成本的。文档提到，如果你认为被错误计费了，提工单时需要提供 endpoint ID、request ID 和大致的发生时间。反过来说，你得先有一套能把这些信息留下来的东西。没有它，你连申诉都申诉不了。

六、拿去填的对照清单

下面这张表不填数字，格子留给你。用同一个统计周期（建议一整个自然月）、同一个产出口径（比如”完成的请求数”或”生成的 token 数”），两边各填一遍，最后各自除以产出量得到单位成本，再比。

成本项	自建（Pod / Serverless）	直接调 API
统计周期与产出总量
算力：机器开着的总时间 × 单位时间价		不适用
算力：其中真正在处理请求的时间（U/T 利用率）		恒为满
冷启动 / 启动阶段计费时间		不适用
空闲超时计费时间		不适用
常驻 worker 或常开 Pod 的持续占用		不适用
存储：运行中		不适用
存储：停机状态（别填零）		不适用
存储：独立于实例的那一层（network volume）		不适用
失败重试与返工消耗的算力		失败请求的计费口径按各家文档
预付承诺占用的资金与到期未用完的部分		通常无
机型锁定带来的灵活性损失（定性打分即可）		无
一次性人力（小时）		接入的一次性人力
稳态人力（小时/月）		通常接近零
故障期人力（小时/月，取近三个月最差值）		供应商侧故障你只能等
观测与账单核对的投入		看账单即可
单位产出成本 = 合计 ÷ 产出总量

填这张表的时候有两条纪律：利用率那一行必须用真实观测值，不许用规划值；存储那三行必须分开填，不许合成一笔”存储费”——因为它们的持久化边界和计费触发条件完全不同，合起来填你就看不出哪一笔是可以砍掉的。

还有一条不在表里但要记着：RunPod 自己也提供托管好的模型端点这种形态（按生成量付费，不用自己部署）。也就是说”自建”和”调 API”不是同一家公司内外的对立，你完全可能在同一个平台上同时用这两种形状——文档明确说几种产品可以组合。把选项想成二选一，本身就是个建模错误。想把”该不该自建”这个问题从更前一步看，可以对照自建推理还是直接调 API和自建平衡点这两篇。

七、什么情况下这笔账根本不用算

有几种情况下，上面这一套都不用做，因为结论由别的东西决定：

• 合规把数据锁死在境内。 数据能不能出境是前置条件，不是成本项。卡在这儿，海外 GPU 云的单价多低都不用看。
• 你需要的能力只有闭源模型有。 那就不存在自建的等价物，比较的对象都不存在。
• 量小且不稳定。 自建的固定开销（人力、镜像维护、常驻资源）在小量下摊不开，怎么算都不划算。这种时候花时间做这张表本身就是成本。
• 你真正想解决的是别的问题。 想要数据不出自己的环境、想要能改推理逻辑、想要不被限流——这些是能力需求，该按能力需求立项，别包装成省钱项目。包装成省钱，半年后一定会被拿账单来问。

八、算错的不是单价，是利用率和人力

如果这篇只能留一句话，那就是这句：我见过的所有”自建更便宜”的估算里，出错的地方几乎从来不是单价，而是利用率被高估、人力被算成零。

单价是明码标的，谁都能查，也很难查错。利用率是自己拍的，拍的时候永远偏乐观——因为拍数的那个人想象的是满负荷跑起来的样子，而不是上线后三个月里那些空转的夜晚。人力更隐蔽，它不在账单上，于是在估算表里就等于不存在，直到某个月你发现有个人一半时间在伺候这套东西。

所以这套算法的价值不在于算得多准，而在于它逼你把利用率和人力这两个空格填上。填完之后，即使数字很粗，方向通常也就清楚了。反过来说，如果你填不出利用率那一行——不知道自己的服务一个月里到底有多少时间在真正干活——那这个阶段的答案大概就是先别自建，先把观测做起来。

最后是本文的边界。以上全部事实来自 RunPod 官方文档，凡是涉及具体价格、费率、折扣幅度的都不在本文里，也不该在任何一篇会过期的文章里；这些以你部署当时控制台显示的为准。文档没有明确说明的部分我也标出来了：计费粒度在定价页和概览页的口径不一致、停机后存储费用的确切结算周期、失败任务的计费细节——这几处以你自己账单上看到的为准。真要落地，最省事的顺序是拿最小配置跑一个真实负载一到两周，用真账单去校准这张表，再决定要不要上量。用别人的数字算自己的账，算出来的从来不是自己的结论。