GPU 是租还是买：按秒、按小时与买断的成本账怎么算
有人拿着三张报价单来问我哪个便宜：一张写「$0.001525/秒」，一张写「每小时多少钱起」，一张是整机采购报价加机房托管的年费。这三个数字放在一起是没法比的——它们连计价单位都不一样，更别说分母（你实际用掉多少）压根不同。直接比价签，结论必然是错的，而且错的方向通常是「看起来最便宜的那个最后最贵」。
同一张卡有三种买法：按秒买、按小时（或包月）买、直接买断。这篇把三种形态换算到同一口径，然后回答一个大多数人算不明白的问题——在多高的使用率下，哪种形态才是划算的。文章最后还会讲一个反直觉但很实在的结论：在按秒计费下，更贵的卡常常总账更便宜。
一、先把三种付费形态的「分母」摆清楚
价格永远是分子除以分母。三种形态的分子长得像，分母完全不同：
| 形态 | 分子（你付的钱） | 分母（你得到的东西） | 空转要不要付钱 |
|---|---|---|---|
| 按秒计费 | 秒价 × 实际运行秒数 | 实际计算时间 | 不付 |
| 按小时 / 包月 | 小时价 × 持有小时数 | 持有时间（不是计算时间） | 要付 |
| 买断自有 | 采购摊销 + 电力 + 场地 + 运维 | 你拥有它的全部时间 | 要付，而且是全时段付 |
关键差别就在最后一列。按秒计费的分母是你真的在算的秒数；另外两种的分母是日历时间。一台卡如果一天只跑两小时，按秒计费你只掏两小时的钱，按小时租你掏二十四小时的钱，自有卡你还要额外掏它闲着时的电费和机柜费。
所以「哪种便宜」这个问题，在没给出使用率之前是无解的。任何一篇不带使用率就断言「租比买便宜」或「买比租便宜」的文章，都可以直接关掉。
二、按秒计费：把秒价换算成小时价
先看一组真实的按秒标价。Replicate 官方定价页（replicate.com/pricing）列出的 GPU 按秒价格如下，本文按 1 小时 = 3600 秒做换算，换算结果是本文的算术演示，不是官方原文表述：
| GPU 型号 | 官方秒价 | 折算小时价（秒价 × 3600） |
|---|---|---|
| Nvidia L40S | $0.000975/sec | $3.51 |
| Nvidia A100 (80GB) | $0.001400/sec | $5.04 |
| Nvidia H100 | $0.001525/sec | $5.49 |
| 2× Nvidia A100 (80GB) | $0.002800/sec | $10.08 |
价格来源：Replicate 官方定价页，核对日期 2026-08-07。价格随时可能调整，下单前以官方定价页为准。 本文其余章节涉及的卡价、电价、机柜托管费、其他平台报价一律作为变量处理，不给具体数字——那些我没有核实过的数，写出来就是害人。
再往前推一步，看看「如果按秒价一直不停地跑一整月（按 30 天 = 720 小时）」的上限：
| GPU 型号 | 小时价 | 满月不停（720 小时） |
|---|---|---|
| L40S | $3.51 | $2527.20 |
| A100 (80GB) | $5.04 | $3628.80 |
| H100 | $5.49 | $3952.80 |
| 2× A100 (80GB) | $10.08 | $7257.60 |
这一列数字的用处不是让你去照着付——按秒计费的场景里，几乎没有人会让一张卡满月不停地跑，那种负载本来就该换形态。它的用处是给你一个天花板：这是按秒计费在最糟糕情况下的花费上限。你手上任何一份按小时或包月的报价，如果高于这个天花板，那份报价就不用看了；如果低于它，接下来才轮到使用率登场。
顺带说一个容易被忽略的细节：2× A100 的秒价 $0.002800 恰好是单张 A100 $0.001400 的整两倍，一分钱折扣都没有。这意味着多卡在计费上是纯线性的，你不会因为「批量」而变便宜。后面第五节会讲这个事实带来的选型后果。
三、按小时 / 包月：使用率是唯一重要的变量
按小时租用有两个按秒计费没有的东西：最小计费粒度和空转计费。
最小粒度的意思是，哪怕你只用了几十秒，也按一个完整的计费单元结算；有些平台还有起租时长。这个粒度各家不同，我不知道你要用的那家是多少，去看它的计费说明——这是开机前必须确认的第一件事，因为它直接决定了「短任务频繁开关机」这种用法是不是可行。
空转计费的杀伤力更大，而且是复利式的。假设你租了一张卡，标价记作 P（美元/小时），一个月按 720 小时算：
- 你实际跑任务的时间只有 20%，即 144 小时；
- 但账单是按持有时间算的：720 × P；
- 折算到每个有效计算小时：720P ÷ 144 = 5P。
也就是说，20% 使用率下，你的真实单位成本是标价的 5 倍。这个倍数就是使用率的倒数，规律很干脆：
| 使用率 | 有效小时/月 | 真实单位成本 |
|---|---|---|
| 10% | 72 | 10P |
| 20% | 144 | 5P |
| 33% | 约 238 | 约 3P |
| 50% | 360 | 2P |
| 80% | 576 | 1.25P |
| 100% | 720 | 1P |
我见过不少团队在这里栽跟头：比价的时候拿标价 P 去跟别家比，赢了三成，很得意；上线三个月后一看账单，因为使用率只有一两成，实际单位成本比对手高了好几倍。比价必须比「每有效小时」或「每次任务」，不能比标价。
对照一下按秒计费。同样是 20% 使用率、L40S 这张卡，按秒付的月账单是 144 × $3.51 = $505.44，而按秒计费的「每有效小时成本」永远等于标价本身，不会被使用率放大。这就是按秒计费的全部价值——它把使用率这个变量从你的成本公式里删掉了。
反过来说，一旦使用率上去了，按秒计费的这个优势就消失了。使用率 100% 的时候，按秒和按小时的口径是一样的，这时候拼的就是纯粹的单价，而按秒计费平台通常要为「随时可调度」这件事收溢价。关于云 GPU 平台之间的形态差异和选择维度，可以看 云 GPU 平台盘点。
四、买断自有卡：把成本公式写出来，而不是拍脑袋
自购的账最容易算错，因为大部分人只算了卡钱。完整的月度成本至少包含这几块，我全部用变量表示：
月总成本 = C / N # 硬件采购摊销：整机（含卡、CPU、内存、电源、网络）总价 C，折旧月数 N
+ W × 24 × 30 × PUE × E # 电费：整机功耗 W(kW)、机房能效比 PUE、电价 E
+ H # 机柜 / 托管 / 带宽月费
+ O # 运维人力分摊（不是零，别装作是零）
每有效小时成本 = 月总成本 ÷ (720 × 使用率)
这几个变量的实际数值，取决于你买什么卡、放在哪个城市的哪个机房、用不用自建，差异极大。我没有核实过当下的卡价、电价和托管报价，所以这篇一个数字都不写，你把自己的四个数填进去就行——填进去的过程本身，比看别人的算例有价值得多。
有三个坑要提前说：
第一，折旧月数 N 不是财务上的折旧年限。 它应该是「这张卡对你还有生产价值的月数」。硬件本身能撑很久，但新一代卡出来之后，同样的任务在新卡上可能快出一大截，你那张老卡在按秒口径下就已经不划算了。把 N 拍得太长，等于把成本算低了。
第二，运维人力 O 是自购方案里最容易被隐藏的成本。 驱动版本、CUDA 环境、散热、掉卡、机房断电、故障换件、值班响应——这些工作在租用方案里是别人的活，在自购方案里是你的活。哪怕只是每周半天，折算成人力成本也不是小数。
第三，分母还是使用率。 自购最大的迷思是「反正买了就是我的，随便用」。可是公式里的分母写得清清楚楚：使用率 20% 的自有卡，每有效小时成本是满负荷时的 5 倍——和按小时租用被使用率惩罚的方式完全一样。买断并不能让你逃开使用率，它只是把付费时点提前了。
买断和租用的盈亏平衡点怎么定量地找，自建推理服务的盈亏平衡点 那篇讲得更细，这里不重复。
五、本篇的核心：按秒计费改变了「哪张卡便宜」
这一节是我最想让你带走的东西。
按小时或按月租用的时候，「哪张卡便宜」的答案很直觉：小时价低的那张便宜。但按秒计费下，你付的是「秒数 × 秒价」，而秒数取决于卡有多快。这时候更贵的卡完全可能总账更便宜。
用一个假设的任务演示。下面所有的耗时都是假设值，不是我实测的，你必须用自己的任务去测：
假设某个推理任务，在两张卡上的平均单次耗时分别是：
| 卡 | 秒价 | 假设的单次耗时 | 单次成本 | 每万次成本 |
|---|---|---|---|---|
| L40S | $0.000975 | 8 秒（假设） | $0.0078 | $78.00 |
| H100 | $0.001525 | 4.5 秒（假设） | $0.0068625 | $68.63 |
H100 的秒价比 L40S 高出约 56%，但在这组假设耗时下，每万次任务反而便宜了约 12%。
关键是这个临界点在哪。两张卡的成本相等意味着：
L40S 耗时 × 0.000975 = H100 耗时 × 0.001525
=> 秒价比 = 0.001525 ÷ 0.000975 ≈ 1.5641
也就是说，H100 必须比 L40S 快 1.57 倍以上，才在按秒口径下更便宜。换算成刚才那个 8 秒的例子：H100 的耗时必须低于 8 ÷ 1.5641 ≈ 5.11 秒。验算一下，5.11 × 0.001525 ≈ 0.0078，正好等于 L40S 的单次成本，对得上。
反例同样重要。如果 H100 上的实际耗时只降到 6 秒（假设值），那么：
6 × 0.001525 = $0.00915/次 → 每万次 $91.50
这就比 L40S 的 $78.00 贵了近 17%。同一张卡、同一份价目表，只因为你的任务在上面提速不够，结论就完全翻转。
再看 A100 和 H100 这一对，差距更微妙：
0.001525 ÷ 0.001400 ≈ 1.0893
H100 的秒价只比 A100 高约 8.93%，只要它把耗时压低 8.93% 以上，总账就更便宜。假设某任务在 A100 上是 6 秒（假设值），单次 $0.0084、每万次 $84.00；H100 只要耗时低于 6 ÷ 1.0893 ≈ 5.51 秒就赢。验算：5.51 × 0.001525 ≈ 0.0084，一致。8.93% 这个门槛相当低——低到大部分显存不紧张的推理负载都能轻松跨过去。这也是为什么在按秒平台上，「默认选便宜的卡」往往是个亏钱的默认值。
最后是多卡。前面提过 2× A100 的秒价 $0.002800 = 单卡 $0.001400 × 2，完全线性。这意味着：
- 如果模型单卡放得下，双卡只有在「耗时不到单卡的一半」时才更省。而多卡并行几乎不可能达到理想线性加速，通信开销永远存在，所以这个条件通常不成立。
- 如果模型单卡放不下，那就不是成本问题而是可行性问题，没什么好比的——你只能上多卡，或者先把模型压下来。
显存够不够、该选哪一档卡，属于选型的前置问题，GPU 选型指南 那篇有更系统的判断路径。
六、三种形态各自的主场
把前面几节的结论收成三条使用建议：
突发、低频、任务式负载 → 按秒计费。 典型特征是：请求来得没规律，白天几波、夜里几乎没有；每次任务是有明确起止的（生成一批图、跑一次批处理、转一段音视频）；你没法预测下个月的量。这类负载在按小时租用下的使用率通常在两成以下，被 5 倍惩罚，按秒计费直接把这个惩罚清零。Replicate 这类平台默认异步提交、结果回调的调用范式，也正好贴合任务式负载——它本来就是为这种形态设计的。同类的无服务器推理形态可以参考 Serverless 推理。
稳定但有波动的负载 → 按小时 / 包月，且按平均值而不是峰值配。 这里最常见的错误是「按峰值买断资源，让它一直在那待命」。峰值只出现在一天中的很短一段，你却为全天付了峰值的钱。正确做法是按平均负载配基础容量，峰值溢出的部分丢给弹性资源（按秒或按需实例）去接。这样基础容量的使用率能顶到七八成，单位成本才接近标价。
高且稳定的负载 + 有运维能力 → 才谈买断。 「高且稳定」的操作性定义是：你能拿出连续几个月的监控数据，证明使用率长期在高位而不是靠预测。「有运维能力」是指有人真的会去处理掉卡和换件，而不是出了事全组一起懵。两个条件缺一个，买断的账都算不平——第一个条件缺了，分母塌了；第二个条件缺了，公式里的 O 会失控。
还有一个组合形态值得一提：基础容量买断或包月，溢出部分走按秒。这个组合的好处是让自有卡跑在高使用率区间（成本公式里最舒服的位置），同时不必为峰值超配。代价是你要维护两条链路和一套调度逻辑，工程复杂度是真实存在的，规模不够时不值得。
七、选卡的正确方法：先测耗时，再算钱
第五节的所有结论都建立在一个东西上——你的任务在候选卡上的平均耗时。这个数没人能替你给出来，因为它取决于你的模型、批大小、序列长度、量化方式、框架版本、并发策略。别人的基准测试只能告诉你一个大致方向，不能替代你自己的那一组数。
方法很朴素，就三步：
- 准备一批真实请求。 不是构造的玩具输入，是从线上日志里捞出来的、长度分布真实的一批。用玩具输入测出来的耗时会系统性偏低，而且偏低的幅度不可预测。
- 在每张候选卡上把这批请求跑完，记录平均耗时。 记平均值，不是最好那一次；同时看一眼分布，如果长尾特别重，说明你的批处理或并发策略有问题，那个问题得先解决，否则测出来的成本是被污染的。
- 把平均耗时乘以秒价，得到每次任务的实际成本，再乘以你的月请求量。 这时候你手里才有一个能拿去做决策的数。
这个测试的成本非常低——按秒计费下，跑几百上千次任务花掉的钱以美分计。但它能避免的是一个数量级的误判：选错卡、选错形态、按峰值买断，任何一个错误的后期代价都是这次测试成本的成百上千倍。我见过太多团队愿意花两周开会争论选哪张卡，却不愿意花半天把三张卡都跑一遍。
顺便说，测出来的耗时还有第二个用处：它是你后续做批处理优化、量化、调度改造时的基线。没有基线，你做完优化也说不清到底省了多少。
八、几个反复出现的算账错误
只比标价，不比每次任务成本。 这是最常见的错，前面已经说透了，但值得再强调一遍：报价单上的数字不是你的成本，它只是你的成本公式里的一个因子。
把使用率当成常量。 使用率会随业务变，也会随你的架构变。开机前的估计和上线三个月后的实测经常差一倍以上。所以任何形态的选择都应该带一个复盘时点——上线一个月后，拿真实账单和真实请求量算一遍单位成本，跟当初的假设对一下。
忽略非计算时间。 模型加载、镜像拉取、数据传输这些环节在不同形态下的计费方式不一样，而且不一定包含在你以为的「运行时间」里。具体怎么算，各家计费说明不同，我不知道你那家的规则，去看它的计费文档——这句话不是搪塞，是这类细节唯一可靠的来源。
用别人的耗时做决策。 上一节讲过了。别人的数只能定方向。
买断时把运维当成零。 公式里那个 O 是真的要填数的。
自查清单
开算之前，把这几条逐条过一遍：
- 三份报价单都换算到同一口径了吗？按秒的换成小时价（秒价 × 3600），按月的换成小时价（月价 ÷ 720），然后再比。
- 你的使用率估计值是多少？是拍的还是有监控数据支撑的？按小时和买断的真实单位成本要除以这个数。
- 按小时租用那家的最小计费粒度和起租时长查了吗？短任务频繁开关机的用法在那个粒度下成立吗？
- 你的任务在候选卡上的平均耗时测过吗？用的是真实请求还是玩具输入？
- 算过临界加速比吗？贵的那张卡贵多少倍，就必须快多少倍才划算——秒价比就是门槛。
- 买断方案的成本公式里，电力、场地、运维人力这三项填了实数还是当成零了？折旧月数是按「财务年限」还是按「对你还有生产价值的月数」填的？
- 多卡方案的加速比，真的超过卡数了吗？如果只是因为单卡放不下，那是可行性问题不是成本问题，别混在一起算。
- 定了一个复盘时点吗？上线一个月后拿真实账单除以真实请求量，跟当初的假设对账。
最后重申一次口径：本文引用的四行 GPU 秒价来自 Replicate 官方定价页（核对日期 2026-08-07），所有小时价、月账单和任务成本都是本文按这四个标价做的算术演示；文中的耗时、使用率和其他成本项全部是假设值或变量，下单前请以各平台官方定价页与计费说明为准。