RunPod 计费机制拆解：Pod 与 Serverless 分别按什么扣钱

见过最典型的一笔糊涂账是这样的：团队上个月跑完实验，把几台 Pod 都”停掉”了，以为算力费就断了，月底一看余额还在往下掉。再翻一遍控制台，发现停机的机器上挂着几块不小的持久盘，而且停机状态下那块盘的计费档位并不比运行时便宜。更糟的一次是余额真的见了底，没挂网络卷的那台机器直接被回收，里面装了两天的环境和中间产物一起没了。

这两件事都不是平台坑人，是计费模型没读明白。RunPod 的账单不是”一台机器多少钱”这么一维的东西，它至少有三层：算力按什么单位在计时、存储在哪几种状态下还在计、余额归零的时候平台对你的资源做什么。本文只讲这三层的机制。具体单价、档位阈值、消费上限这类数字一律不抄——这些值随时会调，写进文章过两个月就是错误信息，以控制台部署页和官方定价页当时显示的为准。平台形态本身如果还不熟，先看RunPod 是什么那篇，这里假设你已经知道 Pod 和 Serverless 是两种东西。

一、先看账户层：预付余额 + 实时扣减

RunPod 用的是预付信用额度（credits）模型，不是月末出账。你先往账户里充钱，运行中的 Pod、Serverless 端点和存储实时从余额里扣。数据进出流量（ingress / egress）不收费——这一条官方文档多处口径一致，可以放心按它做预算，别把”流量费”这一项习惯性地列进预算表。

但计时粒度这件事，官方文档自己给了两个说法，这里得把话说清楚：

• Pods 概览页写的是 Pods are billed by the minute with no fees for ingress/egress.（按分钟）
• Pod 定价页写的是 Pods are billed by the second for compute and storage, with no fees for data ingress or egress.（算力与存储按秒）

两处都是 RunPod 官方文档，粒度不一致。我没有账号去核实实际账单究竟按哪个粒度结算，所以这里不替它选一个——要精确到粒度的场景，以控制台和实际账单为准。 两处一致的部分只有”入口出口流量不收费”。

粒度这件事对大多数人其实不是决定性的（秒和分钟的差别通常被别的东西盖过去，下面几节讲的就是那些”别的东西”），但它有一个附带含义值得记住：连官方文档在同一件事上都能出现两个口径，任何二手文章里的计费细节都不该当权威用，包括本文。

结算节奏是后台按一个很短的固定周期跑一次（账单文档给的是分钟级，具体周期以官方说明为准），扣减是持续发生的。这意味着你没有”月末对账再发现超支”的缓冲期，超支这件事是一边跑一边发生的。

余额归零的后果会分叉，这是全篇最该先记住的一条。 按文档口径，余额到零时平台会自动停掉你所有运行中的 Pod，然后按有没有挂网络卷分成两种命运：

• 挂了网络卷的 Pod——停机，数据留在卷上，还能救。
• 没挂网络卷的 Pod——直接终止，数据不可恢复。

而且还有第二级连锁：Pod 停了以后网络卷上的存储费用仍然在累积，如果余额一直是零、这部分费用也补不上，文档说网络卷本身最终也可能被删除，数据同样不可恢复。也就是说”欠费”在这套体系里不是服务暂停，是一个带倒计时的数据销毁流程。

账户层还有几条会实际拦住你的机制：

• 最低余额门槛：部署一台新 Pod，账户余额必须至少能覆盖所选配置运行一小时的量（这个阈值以官方文档当时的说明为准）。达不到就只能加钱或者换更便宜的机型——它是个前置检查，不是跑一半才告诉你。
• 低余额通知：在账单页的通知里开”低余额提醒”，自己设一个阈值，掉到阈值以下发邮件。这是纯提醒，不动钱。
• 自动续费（auto-pay）：设一个触发阈值和一个补充额度，余额接近阈值时自动刷默认卡。文档提到为了防止重复扣款，自动续费的触发有频次限制（每小时最多一次）。它和低余额提醒是两套机制，可以只开一个也可以都开。
• 消费上限：账户默认有一个按小时计的总消费上限，覆盖所有资源，作用是防止配置错误或跑飞的进程把账户刷穿。文档说这个上限会随账户使用历史自动提高，急需更高上限要联系支持说明用途。
• 充值不可退：credits 一旦充进来不可退款、不能提现，只能消费在平台服务上。所以”先充一大笔拿个折扣”这种动作在这里是单向的。

付款方式这块只说机制：支持信用卡（走 Stripe 支持的卡种）、加密货币（首次付款前要完成 KYC）、以及达到一定金额门槛后可以走企业对公开票（支持 ACH、电汇、信用卡），具体门槛和预付卡的单笔最低额度见官方账单文档。国内团队真正的卡点通常不在这里，而在付款通道本身能不能走通。

二、Pod：计时的是”机器归你”，不是”你在用它”

Pod 侧只有两种定价形态，机制差别比价差重要：

按需（on-demand）：用多少算多少，资源是专属于你这台 Pod 的，文档特别强调不会被其他用户挤掉（displaced）。适合开发、测试、忽高忽低的负载。

节省计划（savings plan）：预付一个固定期限的承诺换折扣，期限按月分档（文档当前给了两个档位，具体月数以定价页为准）。适合长期跑的生产负载。

savings plan 有四个机制细节，不看清楚很容易买了之后发现没省到预期：

1. 只覆盖 GPU 算力成本。存储部分照标准费率单独计，不在折扣范围里。
2. 停机后计划会自动套到下一次部署，前提是同一种 GPU 型号。换型号就用不上了——这条决定了你在买承诺之前必须先把机型定死。
3. 停机的 Pod 上存储费用继续累积，节省计划不管这一段。
4. 不可退款，而且有固定到期日。不是”用不完顺延”，是到点作废。

接下来是 Pod 侧最容易算错的一段：停机（stop）和终止（terminate）在账单上是完全不同的两件事。

停机做的事是释放 GPU、清空 container disk、保留 /workspace 里的数据。算力那一段确实停了，但文档在停机说明里挂了一条明确警告：停机期间你仍然要为 volume disk 的存储付费，如果不需要保留这套环境就应该直接终止。

更反直觉的是方向：按文档现在给出的定价表，volume disk 在停机状态下的计费档位甚至高于运行状态（方向以官方定价页为准）。为什么这么设计文档没解释，但它对操作习惯的含义很清楚——“先停机放着，回头再接着用”不是省钱动作，是换了一种花钱方式。 如果那台机器你两周内不会再碰，停机放着的累计支出可能比你想的难看。

真正让计费彻底归零的只有终止。而终止会永久删掉所有不在网络卷上的数据。把这两条叠在一起，就得到 Pod 侧唯一一条自洽的省钱路径：

想要”彻底停止计费 + 数据还留着”，数据必须在网络卷上。

而网络卷有个硬约束：必须在创建 Pod 的时候挂，事后既不能挂也不能卸。 换句话说，你能不能干净地停下来这件事，在第一天填部署表单的时候就已经定死了。三种存储各自的持久化边界和挂载位置值得单独看一遍，见RunPod 存储怎么选。

还有两条往你这边倒的机制，别忘了用：

• 计划内维护窗口不计费。宿主机要做计划维护时官方会提前发邮件通知，维护期间 Pod 不可用的那段时间不向你收费。
• 宿主机不可用时存储也不计费。定价页和账单页都写了这一条。

至于修改配置：改 container / volume disk 容量走 Pods 页面的三点菜单进 Edit Pod，volume disk 只能增不能减。但文档有一条加粗警告——编辑一个运行中的 Pod 会把它完全重置，抹掉所有不在 /workspace 或网络卷里的数据。这不是账单问题，但它会让你为”重新装一遍环境”的时间再付一次算力费。

三、Serverless：计的是 worker 存在的时间，不是请求数

这里最容易形成的误解是”Serverless 按调用次数收费”。不是。文档的口径是按秒计费，从一个 worker 开始启动，到它完全停止为止，向上取整到秒。请求数只是间接变量，直接变量是 worker 的存在时长。

文档把计费明确拆成了三段，这三段都在计钱：

1. 启动段：拉起容器、把模型权重加载进显存、初始化运行时。模型越大这一段越长——而它是在计费的。这就是为什么”权重从哪来”是个成本问题而不只是工程问题：文档给的缓解方向是开 FlashBoot（保留 worker 停机后的状态，让”复活”比全新启动快）和使用模型缓存（把 worker 调度到已经预载了模型文件的机器上）。
2. 执行段：真正处理请求的时间。这一段是你唯一想付的钱。
3. 空闲超时段：请求处理完之后，worker 还会保持活跃一段时间等下一个请求，然后才缩掉。文档写得很直接——空闲期间你是在被计费的，换来的是这段时间内来的请求不用再冷启动。

第三段是 Serverless 账单里最值得单独想一想的地方。空闲超时这个参数的本质不是”性能开关”，是用一笔确定的空闲费去买掉一次不确定的冷启动。它划不划算取决于你的请求到达间隔分布：请求密集、间隔远小于空闲超时，那这笔钱几乎全都换成了命中；请求稀疏、每次都等到 worker 缩完才来下一个，那你就是在为每一个请求付”空闲 + 启动”两段冤枉钱。默认值文档给的是一个很短的秒级数值（默认值以控制台当前显示为准），调它之前先去看你自己的流量间隔。

worker 类型的差别也是纯计费机制：

• flex worker：空闲时缩到零，按标准的按秒费率计。
• active worker：常驻不停，包括空闲时也持续计费。它的作用是把冷启动彻底消掉，代价是那部分算力你一直在养。文档提到 active worker 的折扣需要走销售咨询，这里不展开。

另外几个直接影响账单形状的配置项：

• 执行超时：单个任务的最长时长，超了任务失败、worker 停止。它的第一身份其实是账单闸门——防止一个卡死的任务一直占着 GPU 计费。可以在端点的高级设置里配，也可以按请求覆盖。
• max workers：并发上限，同时也是成本上限。文档建议设得比预期峰值并发略高一点以吸收突发，但它封住的就是你单位时间最坏情况下的开销。
• 任务 TTL：任务在系统里的总生命周期，从提交开始算而不是从执行开始算。排队排掉的时间会吃掉执行的余量，过期的任务数据会被直接删掉、状态查询返回 404。这条和钱关系不大，但会让你以为”任务白跑了”。
• 长期无请求自动缩容：文档说一个端点长时间没有任何请求，平台会自动把它的 max workers 降下来并发邮件通知，再继续没有请求会降到零。这既是替你止血的省钱机制，也是”我的端点怎么突然不工作了”的常见原因——降下来之后不会自己涨回去，得你自己进控制台把 max workers 调上去。

Serverless 侧的存储计费口径和 Pod 不同，要单独记：container disk 的成本算在 worker 的运行成本里面（数据在 worker 停止或缩容时丢失）；网络卷是单独计费的持久存储，可以挂给多个 worker，所以在多 worker 场景下它能把”每个 worker 各存一份模型”的存储开销摊掉；而 S3 兼容的外部对象存储走的是你自己服务商的账单，根本不进 RunPod 这边的账。网络卷还有个副作用要提前知道：它会把端点约束在卷所在的数据中心，可能影响能抢到的 GPU 供给。

四、存储：唯一一条穿透所有形态的常驻支出

把前面几节的存储信息集中起来看，形状就很清楚了。三种存储在”什么状态下还在计费”这件事上各不相同（下表的结算颗粒度一列取自 Pod 定价页的口径，前面说过 Pod 整体粒度在概览页还有另一个说法）：

存储	运行中	停机后	结算颗粒度	备注
Container disk	计费	不计费	按秒	停机即清空，所以也没什么可计的
Volume disk	计费	仍然计费，且档位高于运行状态	按秒	保留到 Pod 被终止为止
Network volume	计费	计费	按小时	独立于 Pod 存在，按容量分档，超过某个容量阈值后单价降档

三条要点：

第一，颗粒度不统一。 按定价页的口径，container disk 和 volume disk 按秒结算，网络卷按小时结算。做短生命周期的自动化调度时这个差别会体现出来——不过既然 Pod 的计时粒度本身在官方文档里就有两个说法，真要靠”卡着颗粒度省钱”的方案，先拿一天的真实账单验一遍再上。

第二，网络卷是最容易变成”僵尸支出”的一项。 它的优点就是它的风险：独立于任何 Pod 存在。你把 Pod 删干净了，卷还在，还在按小时计费，而且控制台上它不在 Pods 列表里，你不会每天看见它。我见过的成本泄漏里，这一类占比不低。

第三，官方自己说了它不是做长期存储的。 定价页、账单页、存储页三处都挂了同一句免责：RunPod 不是为长期云存储设计的，关键数据请备份到本地或专门的存储服务；账户没钱了存储可能被删且不可恢复。把它当对象存储用，是拿最贵的介质做最便宜的事。

顺带一句，宿主机不可用期间存储不计费——这条在定价页和账单页都写了，属于对你有利但不需要你做任何事的机制。

五、cost center：把账分到项目和团队上

单人用不着，多项目并行或者要跟客户对账的时候这套东西是刚需。机制很简单：cost center 是挂在资源上的账单标签，把资源分组之后，费用可以归到具体团队、项目或部门。

能归集的资源类型和口径：

资源	归集方式
Pod	GPU 算力和存储合并成单条 Pod 费用
Serverless 端点	该端点的全部用量归到所属 cost center
网络卷	存储费用和算力资源分开追踪
Instant Cluster	集群算力费用归到所属 cost center

几条会影响对账准确性的规则：

• 一个资源同一时间只能属于一个 cost center。 没分配的进”未分类（uncategorized）“清单——它们照样花钱，但这些钱在发票上不归属任何 cost center。
• 发票按月结束时的归属为准。 月结之后再改资源的 cost center，只影响后续发票，历史发票不会重算。当月发票是预览状态、没有可下载的 PDF，要等账期结束才有；而且数据有延迟（文档说新产生的消费反映到发票上可能要等一段时间）。
• 重命名只改显示名。 改名后控制台和后续发票用新名字，历史发票保留原名。
• 删除 cost center 会把它下面所有资源打回未分类。 想保住归属就先把资源迁到别的 cost center 再删。

实践上文档给的建议其实就两句有用的：资源一创建就打标（别让费用先在未分类里堆着），以及月末关账前扫一遍未分类清单。这两件事做不到的话，这套标签体系产出的报表只能看个趋势，没法真的用来分摊。

六、上量前必须先搞清的几笔账

这是我认为在把量放上去之前必须逐条有答案的清单，每一条对应上面某个机制。答不出来就先别加机器。

1. 停机的机器上还有哪几块盘在滴钱？ 而且要意识到停机档的单价方向可能不利于你。
2. 有没有和任何 Pod 都不关联的网络卷？ 定期扫一遍卷列表，不要只看 Pods 页面。
3. Serverless 的空闲超时和你真实的请求到达间隔匹配吗？ 不匹配的话你是在为每个请求付”空闲 + 启动”两段。
4. active worker 数是几？ 这个数字大于零意味着有一份算力在 7×24 常驻计费，它是把冷启动换成了固定开销。
5. 模型权重从哪来、启动段有多长？ 启动段是计费的，所以”权重打进镜像还是走网络卷”是一个成本决策，不只是部署方式偏好。
6. 余额真的到零那一刻，你的数据在哪？ 在网络卷上是停机，不在就是终止加不可恢复。这个问题没有想清楚之前，低余额提醒和自动续费至少开一个。
7. 买了 savings plan 的话，它覆盖不到的那部分是多少比例？ 存储不在折扣里，而且换 GPU 型号就用不上。
8. 未分类资源清单是空的吗？ 不空就说明你的成本报表是不完整的。
9. 执行超时和 max workers 设了吗？ 这两个是账单的硬闸门，不是性能参数。

把这些答案填进一张表里，再去做自建和调 API 的对比才有意义——那部分的算法见自建平衡点和成本模型。

七、诚实判断：这套机制里最贵的不是单价

本文一个数字都没有，这是故意的，但也确实有代价——你没法拿这篇文章直接算出一个数来。想要数就只能去控制台看当时的定价页，那才是唯一权威的地方。

要我说的话，大多数团队在 GPU 云上花的冤枉钱，几乎都不是因为选了单价更高的机型。是因为：停机放着以为不花钱的机器、删了 Pod 忘了删的卷、为了压冷启动常驻着但流量其实很稀疏的 active worker、以及一个卡死之后没有执行超时兜底的任务。这几项的共同点是它们都不在你每天看的那个页面上。单价是你决策时会认真比较的东西，所以它通常不会错得太离谱；而这些常驻支出是默认发生的，没人提醒你。

什么情况下这篇东西对你没什么用：如果你只是开一台机器跑几个小时的实验，跑完就终止、不留卷、不碰 Serverless，那上面一多半机制都轮不到你，认真读一遍存储的持久化表格就够了，建治理的成本比省下来的钱高。反过来，如果你已经到了”多个项目共用一个账号、有常驻推理端点、有人会忘记关机”的阶段，那 cost center、消费上限、执行超时、低余额通知这四样应该在加机器之前先配好，而不是出了账单再补。

最后是本文事实来源的边界：以上全部来自 RunPod 官方文档（Pod 与 Serverless 定价页、账单总览、cost center、存储类型页、Pod 概览页），我没有用账号逐项核对过控制台和真实账单的行为。有几件事官方文档没有明确说明，只能以控制台实际显示和你的账单为准：停机后存储费用的确切结算与出账周期、容量档位切换的具体生效方式、当前的消费上限与最低余额阈值实际是多少、以及各数据中心之间是否存在计费差异。

还有一件事比”没写”更麻烦——官方文档在 Pod 计时粒度上写了两个互相矛盾的口径（概览页按分钟、定价页按秒），我在第一节把两处原文都列了出来，没有替它挑一个。这件事本身就是读计费文档时最该带走的态度：一手文档都可能自相矛盾，二手文章（包括这篇）只能帮你把要问的问题列清楚，不能替你定数。

所以真正靠得住的做法只有一个：开一台最小配置的机器，把完整生命周期走一遍——开机、跑一会儿、停机放一天、再终止——然后拿账单页把每一段对一遍。这一遍花的钱，会比你读任何文章（包括这篇）都更准确地告诉你自己的账单长什么样。要不要走到自建这一步，前置判断在自建推理还是直接调 API。