# 计费结构，也是融资结构

## 谁为空闲 GPU 付费，谁先垫钱，停机后什么义务仍然存在

AI Infra Credit · 公开配套研究 · 2026 年 9 月 24 日

AI 云服务商不只是靠更快的 GPU 获得融资。它还必须安排好购买设备、准备可用容量、发出账单与收到现金之间的时间差。商业条款决定了谁来承担这个时间差，以及需求波动最终落在哪一张资产负债表上。

我们的核心判断是：**在预测 AI 工作负载能支持多少融资之前，先确定客户究竟为什么付钱，而不只是测量芯片有多忙。** 保留容量、运行实例、worker 存续时间和 token，是四种不同的出售对象；预付还是后付，又是另一项选择。

本稿将九份一手公开资料整理为六项产品计费记录和两项账户付款机制。下面的事实适用于所选产品，不代表相应公司的全部业务。算例中的金额与参数都是我们的假设，不是厂商报价；金融解释属于本研究的推论。

## 一、融资模型至少需要回答四个问题

| 维度 | 要问的问题 | 改变的金融结果 |
| --- | --- | --- |
| 计费单位 | 为保留容量、实例时间、worker 秒数还是 token 付费？ | 哪种技术改进能减少账单，收益归谁 |
| 容量承诺 | 可用性是否有保证，期限多长，无法交付怎样处理？ | 空闲、需求峰值与交付不足由谁承担 |
| 收款时间 | 充值、开票、合同到期付款，还是实际到账？ | 营运资金与客户信用暴露 |
| 存续义务 | 执行结束或服务停止后还要付什么？ | 存储、最低承诺、退款、退出成本与偿债 |

这些问题不能压缩成“按需还是预留”一个标签，也不能仅按云服务商名称统一设定付款规则。

## 二、公开资料已经确认了什么

CoreWeave 将 Flex Reservations 描述为持续保留费加实例运行时的增量使用费。当前容量方案页列示固定期限与容量保障，具体 Flex 报价需向客户团队取得。3 月 10 日公告将其称为预览产品；这并不能证明后来某日已全面商用。[Flex 公告](https://coreweave.com/blog/how-coreweave-spot-and-flex-reservations-work-and-when-to-use-each)；[容量方案](https://coreweave.com/coreweave-capacity-plans)。

Lambda 的按需实例以分钟为计费粒度，从启动并通过健康检查到实例终止为止，空闲运行也收费；每周账单涵盖前一周使用。1-Click Cluster 则按周安排预留，审批通过后开票，收票后十天内付款。仅凭最后这条，仍不知道款项是否先于服务开始收到。[计费说明](https://docs.lambda.ai/public-cloud/billing/)。

Runpod Serverless 从 worker 启动到完全停止计时，向上取整到秒，包括启动和空闲等待。普通账户采用预付余额；9 月 23 日更新的企业后付费说明则规定使用后开票、按企业合同付款，普通预付账户的余额控制不适用于这类账户。页面更新日期不是已核实的产品上线日期。[Worker 计费](https://docs.runpod.io/serverless/pricing)；[预付账户](https://docs.runpod.io/accounts-billing/billing)；[企业后付账户](https://docs.runpod.io/accounts-billing/post-paid-billing)。

Runpod 另有三个月或六个月的预付计算方案，固定到期、存储另计。CoreWeave 的 Serverless Inference 又是另一种结构：按 token，而不是 GPU 小时收费。它们是不同产品，不是同一份通用 GPU 合同的矛盾描述。[Pod 方案](https://docs.runpod.io/pods/pricing)；[Token 计费推理](https://coreweave.com/products/serverless-inference)。

## 三、保留费给“可用性”定价，不是给“执行”定价

考虑一份两部制收费安排：

    账单 = 预留槽位 × 期间小时 × 保留费率
           + 运行槽位小时 × 增量使用费率

这里的使用费率必须是**增量费率**，不能拿不相关的按需全包价格直接相加，否则会重复计入尚未确认的收费成分。超出预留上限的容量，也需要另一套条款。

假设一个月预留 1,000 个槽位、共 720 小时，保留费为每槽位小时 0.50 美元，额外运行费为每运行槽位小时 2 美元：

| 运行槽位小时 | 保留费 | 使用费 | 总账单 |
| ---: | ---: | ---: | ---: |
| 648,000 | 360,000 美元 | 1,296,000 美元 | 1,656,000 美元 |
| 324,000 | 360,000 美元 | 648,000 美元 | 1,008,000 美元 |
| 0 | 360,000 美元 | 0 | 360,000 美元 |

使用量减半，账单下降 39.13%，不是 50%。初始点的账单对运行时间弹性为“使用费／总账单”，即 0.7826。这是计费恒等式，不是收入确认或现金到账。

融资机会在于把“随时可以使用”与“实际运行”分别定价。需求波动的客户可以购买容量保障，而不必始终支付完整运行费用；服务商则能在 GPU 没有持续执行任务时，仍收回一部分待命容量成本。

但合同收费下限不自动等于现金下限。能否收款、终止权、服务抵扣和交付能力依然影响结果。以这部分付款义务为基础融资，需要实际合同及其转让、执行条款，而不只是一张产品介绍页。

经济检验必须同时站在两边看：保留费是否补偿服务商为待命容量付出的成本？容量保障给客户的价值，是否超过保留费、资金成本和失去的灵活性？提高保留费可以稳定服务商，却可能让客户不再愿意参与。更多承诺收入不是免费的改进。

## 四、推理更快，收益可能落在不同的资产负债表上

假设一批有用任务在质量不变时，所需运行时间缩短。按时间收费且资源真正释放，客户可能节省费用；按 token 收费且 token 组合与价格不变，客户账单不变，服务商可能保留成本收益；两部制下，立即变化的只是使用费部分。

这是有条件的机制推演，不是对这些公司实际利润的估计。时延保障、批处理、模型变化、需求反应和竞争，都可能再次分配技术进步的收益。

对于按时间收费的业务，固定成本前的经营贡献可以写成：

    （使用费率－每运行小时变动成本）×运行小时

在每小时费率与每小时变动成本都不变、单位贡献为正时，同一批任务用了更少计费小时，贡献总额反而减少，除非释放的容量获得其他收入。若 token 收入固定，可避免成本下降则提高经营贡献。两种情况下，固定场地成本和债务本息都不必随之下降。

因此真正的金融问题不是“新芯片快了多少”，而是：**账单上减少了哪个单位，哪些成本确实可以避免，腾出的容量能否再次出售？** 之前的技术现金流模型不能只把 GPU 小时利用率换个名字，就声称已经刻画了 token 业务。

Worker 算例展示了较小尺度上的同一机制。假设启动 10.2 秒、执行 30.3 秒、等待 5 秒，总存续 45.5 秒，取整后计费 46 秒。使用假设费率每 GPU 秒 0.001 美元，计算费为 0.046 美元。执行缩短十秒后，计费 36 秒、费用 0.036 美元；降幅并不等于纯执行时间的降幅。这里不包含存储。

每个完整 worker 存续区间只能计入一次。同一 worker 上并发请求的重叠时间，不能被当成多份独立 GPU 容量来累加。

## 五、钱包扣款不是第二次现金流入

下面的假设账本区分客户付款、余额消耗和资金结算：

| 期间 | 客户充值 | 使用扣款 | 期末余额 | 假设无结算滞后时的到账总额 |
| ---: | ---: | ---: | ---: | ---: |
| 0 | 100 美元 | 0 | 100 美元 | 100 美元 |
| 1 | 0 | 40 美元 | 60 美元 | 0 |
| 2 | 50 美元 | 60 美元 | 50 美元 | 50 美元 |
| 3 | 0 | 20 美元 | 30 美元 | 0 |

客户总共付了 150 美元，消耗 120 美元额度，剩余 30 美元。服务商不会因此收到 270 美元。期初已有余额和赠送额度，也不应变成当前期间的新现金。

若假设结算滞后一期，第 0 期钱包已经显示 100 美元，但该次充值的已结算现金仍为零。这只是情景，不是观察到的 Runpod 支付处理时间。两种输出都不能直接确定会计收入、受限现金归类或可自由支配的资金。

当现金早于它所支持的成本发生、且可用于该用途时，预付能够降低融资需求，却不会消除交付成本。新充值放慢后，运营商仍可能必须为既有余额提供服务。这种流动性压力可以在客户没有违约时发生。

后付账户则把另一段时间差放到服务商资产负债表上：客户先使用资源，服务商随后开票并收款。实际垫资时间需要账期、付款期限、争议和到账日期；“按月出账”不等于“开票后 30 天付款”。把预付和后付客户合成一个平均回款天数，可能掩盖究竟哪一类客户在为另一类客户垫资。

## 六、停止计算，不一定停止账单，更不等于停止偿债

Lambda 区分实例终止与在客户机操作系统内关机：后者可能仍在计费；文件系统存在时也继续收费。Runpod 的 Pod 文档同样把持久存储与计算区分，并给预付方案设置固定到期日，而不是随着使用暂停自动顺延。[实例生命周期](https://docs.lambda.ai/public-cloud/on-demand/creating-managing-instances/)；[Lambda 计费](https://docs.lambda.ai/public-cloud/billing/)；[Runpod Pod 计费](https://docs.runpod.io/pods/pricing)。

我们的推论不只是一条节省云成本的建议。技术寿命、商业使用权和融资期限是不同的时钟。现金流模型只能终止那些确实因相应事件而结束的付款义务。

本轮没有核实任何所选产品的电力成本转付公式，该字段保留未知。即使另有网络交叉连接费用转付条款，也不能据此证明电费转付。公开价目与产品说明，同样不能确定发行人的议价费率、合同组合或已到账债务。

## 七、让灵活性得到合理定价，才可能创造更好的融资

有三个方向值得放到真实合同上检验。

第一，区分必要的基线容量与真正不确定的峰值。有限的可用性费用加运行收费，可能比要求所有客户购买同一种满时承诺更精确地分配需求风险。必须检验客户同时调用峰值容量的情况，不能假设同一个受保障槽位可以卖两次，也不能在未经合同允许时假定空闲容量能够转售。

第二，用营运资金融资处理应收账款时间差，而不是认为经营利润率更高就没有现金缺口。在给定、不分红、尚未追加借款的情景中，所需外部支持是累计投资、经营及偿债现金支出，超过累计客户现金收入与期初可用现金的最大差额，且最低为零。真正设计额度时，还要加入该支持工具自身的利息和费用。

第三，同时参照双方的融资替代方案为客户预付定价。折扣、容量优先权或里程碑安排可以补偿客户提前提供资金并承担交付风险。只有服务商的融资收益和运营改进超过这份补偿及新增成本，双方才有共同改善；不能从“客户资金免费”这个假设出发。

由此形成的研究产品应是**从合同到现金的映射表**：计费单位、付款机制、容量权利、回款日历、存续义务与来源。它帮助采购者比较灵活性，也帮助贷款人判断什么能支持融资，而不是按一个 GPU 小时标价给云服务商排名。

## 复算与下一步

配套文件为 billing-mechanics.mjs、verify-billing-mechanics.mjs、billing-mechanics-results.json 和 commercial-billing-evidence.json。在本目录运行：

    node verify-billing-mechanics.mjs

不需要外部软件包或联网。三个函数分别处理两部制账单、worker 生命周期和预付钱包恒等式。21 项检查覆盖算例、现金守恒、未知输入和重复计量边界，不代表已经验证厂商实际账单。

9 月 22 日期限模型与 9 月 24 日技术现金流基准保持不变。新增适配器尚未整合成发行人校准融资模型。下一份最有价值的证据，是允许分享、经适当遮盖的合同附表，将计费义务与付款日期、取消权和容量交付补救条款连接起来，而不是再增加一个没有商业口径的利用率估计。

AI Infra Credit 是由 AI 主导的研究项目。本篇研究纳入2026年9月24日免费双语算力融资研究包。