Cost, Billing, and Ops2026年10月13日Flatkey Team

按需、竞价与预留 GPU 定价：哪种模式适合你的工作负载？

一个以工作负载为导向的框架，帮助你在按需、竞价或预留 GPU 容量之间做出选择，而不会把标注的小时费率与完成工作负载的实际成本混淆。

在按需与竞价 GPU 容量之间做选择，不只是看费率表那么简单。较低的小时价格，如果任务会重启、检查点机制薄弱、数据需要重新加载，或者工程师要花几天时间维持可中断机器持续运行，反而可能更贵。预留 GPU 容量也可能看起来更便宜，直到模型需求发生变化，团队被锁定在利用率不足的硬件上。

本指南面向 AI 基础设施采购方、FinOps 团队和平台工程师，比较按需、竞价和预留 GPU 定价，帮助你做出实用的工作负载决策。简短答案是：按需 GPU用于首次测量和紧急工作，竞价 GPU用于容错的批处理负载，而预留 GPU 容量则应在你能够证明基线利用率之后再使用。

如果你仍在决定是否应该租用 GPU，不妨先阅读更全面的 GPU 租赁价格和GPU 云与模型 API 对比指南。本文聚焦的是：在你已经确定 GPU 容量需要纳入计划之后，如何选择定价模式。

快速答案：按需 GPU、竞价 GPU 与预留 GPU

对大多数团队来说，第一轮判断应当如下：

定价模式	最适合的场景	主要风险	关注指标
按需 GPU	基准测试、紧急实验、演示、早期生产、利用率未知	空闲时间和更高的标称小时费率	有用 GPU 活动分钟数 / 计费分钟数
竞价 GPU	批量推理、离线评估、带检查点的训练、媒体队列、可重试工作进程	驱逐、排队延迟、重启浪费、重复工作	中断后完成的任务成本
预留 GPU	稳定的生产推理、定时训练、发布窗口、专用集群	利用率不足、硬件锁定、合同不匹配	基线利用率与承诺盈亏平衡点

关于按需与竞价 GPU 决策，一个持久适用的原则很简单：比较每个已完成工作负载的有效成本，而不是宣传中的 GPU 小时单价。

每个已完成工作负载的有效成本 =
  （计算 + 存储 + 带宽 + 空闲时间 + 重启浪费 + 支持 + 工程开销）
  / 已接受任务、训练 token、推理 token、图像、短片或基准测试运行次数

这个公式之所以重要，是因为每种模式都把风险转移到了不同的地方。按需模式把风险放在空闲时间上。竞价模式把风险放在中断和编排上。预留容量把风险放在预测准确性上。

按需 GPU 定价是什么意思

按需 GPU 定价是最清晰的基准。只要实例、Pod 或服务器在运行，你就付费，没有长期承诺。AWS 将 On-Demand Instances 描述为按使用付费、没有长期承诺的容量。即使计费单位和包含的存储不同，专业 GPU 云对 Pod、实例或按小时 GPU 服务器也使用类似的表述。

当工作负载仍不明确时，优先使用按需：

用例	为什么适合按需
模型或服务栈的首次基准测试	你需要不受中断变量影响的干净计时。
驱动、CUDA、容器或框架验证	调试不应与竞价驱逐风险混在一起。
客户演示或 QA 环境	可预测性比最低费率更重要。
早期生产端点	在拥有稳定利用率数据之前，你需要先保证可用性。
短期紧急训练或微调任务	排队延迟的成本可能高于小时节省。

陷阱在于空闲时间。如果一个 notebook、Pod 或推理服务器运行了 100 个计费小时，但 GPU 只有 28 个小时真正有用，那么真实成本就不是供应商标示的小时价格。真实费率会被空闲浪费抬高。

按需有效小时费率 =
  标示的按需小时费率 / 有用利用率占比

如果利用率是 35%，那么一个 $4/hour 的 GPU，在不计存储、带宽或工程开销前，就相当于一个 $11.43/useful-hour 的资源。对于按需与竞价 GPU 的决策，应先解决空闲关停和队列打包问题，再去谈判更好的小时费率。

竞价 GPU 定价是什么意思

竞价 GPU 定价使用的是备用或可中断容量。AWS 表示，EC2 Spot Instances 使用闲置的 EC2 容量，与 On-Demand 价格相比最高可提供 90% 的折扣。Google Cloud Spot VMs 和 Azure Spot Virtual Machines 遵循同样的大方向：价格更低，但当云平台需要收回容量时，可能会被抢占或驱逐。

竞价 GPU 对 AI 工作负载很有吸引力，因为训练、评估、图像生成和批量推理通常包含大量可重试的部分。但“可重试”并不是自动成立的。你需要检查点、幂等作业、数据本地性、监控，以及能够在不破坏结果的情况下重启的调度器。

通常在以下情况下，竞价是一个强候选方案：

训练任务会频繁保存检查点，并能干净地恢复。
批量推理可以重试，而不会对用户可见地失败。
离线评估可以分布在多个 worker 上运行。
媒体生成任务位于队列之后。
单个 worker 失败不会使整个多节点任务失效。
团队已经具备处理驱逐和防重复的编排能力。

通常在以下情况下，竞价是一个较弱的候选方案：

一个为期多天的训练任务从旧检查点重新启动。
启动时间主要消耗在拉取模型、镜像或数据集上。
面向客户的延迟取决于机器持续在线。
当一个 worker 消失时，多节点训练会失败。
工程师不得不手动盯着重启过程。

对于 spot 与按需 GPU 实例的优缺点，计算时应包含中断损耗：

spot 有效每小时费率 =
  spot 每小时费率 / (1 - 中断损耗占比)

如果 spot 便宜 60%，但中断、数据重新加载、失败步骤和排队延迟造成 35% 的已用工作时间浪费，那么真实折扣会比标价小得多。如果重启损耗达到与折扣同量级的水平，按需容量通常更省心。

预留 GPU 定价的含义

预留 GPU 定价是一种承诺模型。它可能表现为预留实例、Savings Plans、承诺使用折扣、预留集群、私有容量、容量块或专用 GPU 合同。不同云厂商名称各异，但权衡是一致的：你用灵活性换取可预测的容量或更低的有效费率。

预留 GPU 容量适用于以下情况：

信号	含义
稳定的基础推理流量	你可以让 GPU 在每月大部分时间都保持忙碌。
重复性的训练日程	你知道何时需要容量以及需要多久。
上线容量需求	你不能依赖 best-effort 的 spot 可用性。
多节点拓扑需求	网络放置、fabric 和存储就近性很重要。
采购需要固定支出	已知的每月承诺比波动的使用量更容易获批。

预留容量的核心问题是利用率盈亏平衡：

预留盈亏平衡利用率 =
  预留每月承诺金额
  / (按需每小时费率 * 每月小时数)

如果预留承诺在 62% 的利用率下达到盈亏平衡，而你的真实基础负载只有 25%，那么预留容量并不是折扣，而是闲置容量订阅。对于 GPU 集群，请结合 GPU 集群 TCO 模型一起考虑，这样网络、存储、支持、远程运维和运营成本都能纳入。

按工作负载划分的决策矩阵

最佳定价模式更多取决于故障容忍度和利用率，而不只是模型大小。

工作负载	更好的起点	原因
第一个模型基准测试	按需 GPU	你需要一个干净的基线来评估吞吐、延迟、内存和故障模式。
新推理栈评估	按需 GPU	在优化价格之前，先验证 vLLM、SGLang、TensorRT-LLM、驱动、镜像和模型加载。
离线评估套件	Spot GPU	结果可以重试、拆分，并检查是否有重复工作。
批量 embedding 或批量推理	Spot GPU，配合按需回退	如果存在幂等性和重试控制，任务就可以排队处理。
面向客户的推理基线	预留加按需突发	稳定需求可以证明承诺是合理的；突发部分仍保持灵活。
一次性上线或短期活动	按需或容量块	容量保障可能比长期折扣更重要。
多节点分布式训练	预留或专用集群	放置、网络 fabric 和故障域比每小时价格更重要。
低流量 AI 产品功能	模型 API 或网关	闲置 GPU 容量的成本可能高于托管式按用量推理。

对于任意一行中的 GPU 模型选择，请将本文与 AI GPU 选型指南、LLM 推理最佳 GPU 和 vLLM 部署指南搭配参考。

按需 vs spot GPU 经济性：一个简单示例

假设某个推理批次可以在同一 GPU 型号上以按需或 spot 模式运行。

字段	按需	Spot
标价每小时费率	`$4.00`	`$1.80`
有效利用率	`70%`	`70%`
重启与驱逐损耗	`0%`	`22%`
有效每小时成本	`$5.71`	`$3.30`

在这个例子中，spot 仍然更划算，因为折扣大于损耗。现在把重启损耗改成 55%，因为任务会反复重新加载权重并丢失部分批次。

字段	按需	Spot
标价每小时费率	`$4.00`	`$1.80`
有效利用率	`70%`	`70%`
重启与驱逐损耗	`0%`	`55%`
有效每小时成本	`$5.71`	`$5.71`

到那时，表面上的现货折扣就消失了。这就是为什么在比较按需与现货 GPU 时，应该把运营浪费算进去，而不仅仅是看提供商给出的现货折扣百分比。

预留 GPU 经济性：利用率测试

预留容量需要另一种测试。假设一块按需 GPU 的价格是 $4/hour，而同等容量的月度预留承诺是 $1,900/month。

monthly on-demand cost at 100% utilization =
  $4 * 730 hours = $2,920

reserved break-even utilization =
  $1,900 / $2,920 = 65%

只有当工作负载能让 GPU 在一个月中忙碌超过大约三分之二时，这种预留才有吸引力。如果你的生产端点在工作时间会高强度使用 GPU，但在夜间和周末处于空闲状态，那么真实基线可能低于盈亏平衡点。

采购视角下，这个问题可以表述为：

实际测得的基线是多少，而不是预测峰值？
哪些工作负载可以填充空闲的预留容量？
如果模型从 H100 迁移到 H200、B200、L40S，或者迁移到托管 API，会发生什么？
存储、支持、网络和出站流量是在承诺范围内还是之外？
合同是否可以缩减、转换 GPU 类型，或迁移区域？

不要基于希望去预留。要基于已测得的利用率去预留。

提供商来源检查清单

GPU 定价页面经常变化，市场价格变化速度甚至可能快过采购周期。把下面内容当作来源检查清单，而不是固定费率卡。请在你批准支出当天重新核对。

提供商类别	要检查的官方来源	需要记录的内容
AWS	Amazon EC2 pricing, EC2 Spot Instances, EC2 Capacity Blocks for ML	区域、GPU 实例系列、按需、现货、Savings Plans 或 Reserved Instances、容量块时长、EBS、数据传输、支持。
Google Cloud	Compute Engine GPU pricing, Spot VMs, Committed use discounts	GPU 类型、机器系列、区域、Spot VM 状态、承诺期限、预留需求、持久磁盘、网络出站流量。
Microsoft Azure	Azure Spot Virtual Machines, Reserved VM Instances	GPU VM SKU、区域、驱逐策略、最高价格设置、预留期限、托管磁盘、带宽、支持。
RunPod	RunPod pricing and product docs	Secure Cloud 与 Community Cloud、pod 定价、serverless 定价、持久存储、网络卷、冷启动行为。
Vast.ai	Vast.ai pricing and Vast.ai docs	主机可靠性、数据中心/社区状态、可中断标志、磁盘、带宽、已验证主机、是否需要公网 IP。
Lambda	Lambda Cloud GPU pricing	实例类型、GPU 数量、区域、按需可用性、预留集群报价条款、存储和网络假设。

在你的电子表格中加上一行检查日期。就本文而言，来源检查清单已于 2026 年 10 月 13 日审阅。

在选择之前的采购问题

在你选择按需 vs 现货 GPU 容量，或签署预留 GPU 合同之前，请先问这些问题：

问题	为什么重要
任务能否在无需人工修复的情况下检查点保存并恢复？	决定现货中断风险是否可接受。
有用的 GPU 工作开始之前，启动需要多长时间？	较长的模型和数据加载会削弱现货节省，并损害按需效率。
实际测得的空闲率是多少？	空闲时间是按需成本泄漏的主要来源。
基线是多少，而不是峰值？	只有当基线需求真实存在时，预留定价才有效。
工作负载是否需要特定区域或网络架构？	稀缺拓扑可能让通用的现货/按需费率失去意义。
是否包含存储、快照、带宽和支持？	GPU 小时只是实际账单中的一项。
如果模型选择发生变化，退出路径是什么？	当模型架构变化时，硬件锁定的代价很高。
是否可以改用托管模型 API 来满足需求？	低利用率或多模型工作负载可能不值得自建 GPU 运维。

对于多节点和私有容量决策，可将其与 GPU cluster rental 和 private GPU cloud 进行比较。

当模型 API 胜过这三种 GPU 定价模式时

按需、现货和预留 GPU 都默认：租用并运营硬件是正确的抽象层。但事实并不总是如此。

当以下情况出现时，托管模型 API 可能是更好的经济起点：

利用率低、呈突发性，或者尚不明确。
产品需要很多模型，而不是一个自托管模型。
可靠性、升级和扩展会分散产品路线图的注意力。
团队更需要使用明细账、预算和发票，而不是硬件控制。
工作负载是生产推理，而不是模型训练或自定义服务研究。

Flatkey 正位于这一 API 侧的决策路径上。它为 AI 团队提供一个 API 密钥、一个余额、一张发票、用量可见性，以及跨不同提供商访问官方模型路由的能力。如果按需 vs 竞价 GPU 计算表显示硬件利用率还不够高，那么在购买或预留 GPU 容量之前，先比较托管 API 的每个可接受结果成本。下一步请参考 AI model pricing comparison 和 AI gateway pricing 指南。