整个十月共744小时,持续运行一块DigitalOcean H100 GPU,按标价按需计费每GPU小时4.41美元计算,算力费用为3,281.04美元。如果承诺使用12个月,可享受每GPU小时3.26美元的包年价,算力成本降到2,425.44美元。微软零售价格API显示,美东区域的H100 Spot虚拟机每小时约1.29美元,运行744小时共959.69美元。价差相当可观,但采购条款、硬件配置以及持续服务客户的能力也各不相同。
这正是Spot GPU定价与包年容量之间的真实矛盾:小时账单更低确实能延长资金续航,但前提是应用仍能完成有效工作。训练反复重启、备用GPU无货可调、客户请求中断,这些都会把省下的钱吃回去。
DigitalOcean值得单独一提,因为它公开的H100包年价格给创业者提供了一个持续推理的明确基准。Spot则值得考虑,因为灵活的工作负载可以承受中断,并利用闲置算力。但这两种选择都不该从预设的折扣幅度或供应商整体的可靠性百分比出发。
先问自己一个问题:这项工作负载能停多久,才不会让中断造成的损失超过算力上省下的钱?答案决定了哪些价格真正重要、你需要什么样的恢复机制,以及该承诺采购多少容量。
从你能掌控的成本算起
一个月内持续运行DigitalOcean H100 GPU共744小时,按公开的按需价每GPU小时4.41美元计算,费用为3,281.04美元。12个月包年价为每GPU小时3.26美元,744小时共2,425.44美元,可省下855.60美元——这还没算存储、网络、恢复等各项费用。
更低的小时账单可以延长初创公司的资金续航,但前提是应用仍能完成有效工作。训练反复重启、备用GPU无货可调、客户请求中断,这些都会把省下的钱吃回去。
决策规则很简单:需求不确定时,用按需容量。如果有可预测的基础利用率、值得做出承诺,就为延迟敏感的推理预留容量。可中断的训练(有检查点)、批处理任务和模型评估,则用 Spot 实例。对于混合负载,可以跑一条稳定的面向客户的基础负载,再配上 Spot 工作节点来处理可中断任务。
| 工作负载 | 采购决策起点 |
|---|---|
| 需求尚不确定 | 先用按需模式,同时测量真实利用率和客户需求。 |
| 需求稳定的延迟敏感型推理 | 对照下文 73.9% 的 H100 盈亏平衡规则比较计费时长;只有当承诺条款和容量条款都合适时才选择预留。 |
| 带检查点的训练、批量推理、embedding 或评估任务 | 如果截止时间允许中断,且队列能安全重试任务,就用 Spot。 |
| H100 使用时长约占承诺周期的 74% 以上 | 在配置和计费条款相同的前提下,$3.26 的预留价格在算力成本上优于 $4.41 的按需价格。 |
| 生产任务与弹性任务混合 | 为核心基础负载预留容量或以其他方式保障稳定;可延后的任务放到 Spot 上跑。 |
关键问题是:这个工作负载能停机多久,才不至于中断损失超过节省的算力成本?
各种购买方式意味着什么
按需计费灵活,无需长期承诺(在可用容量范围内)。Spot 以可能被回收为代价换取更低价格。预留价格则是一种资金承诺;预留可以访问特定容量,或通过计划算力块来保障特定容量的访问——这些条款不能互换。
AWS Savings Plans 并不预留容量。Azure Reserved VM Instances 提供账单折扣,但同样不预留算力。Google Cloud 基于资源的 GPU 承诺通常需要附带容量预留,个别产品有例外。DigitalOcean 则通过销售渠道提供 12 个月的 GPU 预留。在把某种承诺当作容量保障之前,先核实合同中的容量保证、计费基准以及预付或周期性付款条款。
中断的成本账:提前通知有用,恢复才是真正的代价
一个没有持久化机制的批处理工作节点,一旦丢失 15 分钟的计算成果,代价可能相当高昂。而推理工作节点即使不丢任何存储数据,损失也可能更大:冷重启需要 20 分钟才能恢复算力、下载模型、预热内核并完成健康检查,这超过了 15 分钟的 GPU 算力损失,而且请求超时往往以秒计,根本等不起。
中断风险由三个因素决定:算力消失的频率、你能提前多久收到通知,以及多快能恢复到正常工作状态。DigitalOcean 公布的 Spot 政策目标是至少提前两小时通知,但紧急情况下可能缩短通知时间甚至不通知。这让运维人员有时间在收到通知后停止派发新任务、逐步排空正在运行的任务;但这并不保证每次中断都能优雅处理。
| 云服务商 | 公布的中断处理方式 | 对规划的启示 |
|---|---|---|
| DigitalOcean Spot GPU Droplets | 目标是至少提前两小时通知;紧急情况下通知时间可能缩短甚至没有通知。 | 利用通知时间停止派发新任务,对进行中的工作做检查点或排空;同时为突发中断保留恢复路径。 |
| AWS EC2 Spot | 通常在实例终止或停止前提前两分钟发出中断通知。通知投递是尽力而为。 | 定期保存检查点,并自动化停止新任务、排空活跃任务的流程。 |
| Google Cloud Spot | 默认尽力而为的关机时间最多 30 秒;文档中还提到可配置 120 秒的通知。 | 针对你的部署,验证通知配置和关机行为。 |
| Azure Spot VMs | 尽力而为的 Scheduled Events 通知可能在回收前最多 30 秒到达。 | 把检查点和持久化状态存放在工作节点之外,替换节点才能恢复处理。 |
与AWS的两分钟通知、Azure的30秒通知、Google Cloud默认的30秒(可配置到120秒)相比,DigitalOcean的两小时目标提供了充裕得多的准备时间。DigitalOcean通过邮件发送通知,因此要把通知与运维响应流程挂钩——预警期再长,没人处理也是白搭。另外,预警时间并不能决定中断频率,也不保证有替换容量可用。
AWS Spot Instance Advisor会报告近期的中断频率区间,但这些区间无法预测某个特定的H100任务能否跑完。Google提供历史抢占信息,Azure提供定价和驱逐细节,而DigitalOcean的容量页面展示的是近期可用库存,并非中断率。在试点阶段,应该实际测量这些指标:每1000实例小时的中断次数、替换等待时间、恢复耗时、重算工作量、错过的截止时间,以及故障是否集中爆发。四台Worker同时挂掉,和一个月里分散发生四次中断,是完全不同的运维问题。
DigitalOcean GPU定价:现价与承诺价对比
以下DigitalOcean Spot价格截至2026年10月15日,核对自公开的定价页面。月度费用按744小时(31天)计算,仅含计算资源。Spot价格可能随时变动,购买前请再次确认所选配置和价格。公开定价页面上没有H100和L40S的Spot价格。
| GPU | 按需 | 12个月预留 | Spot | 公开价格说明 |
|---|---|---|---|---|
| H100,每GPU | $4.41/小时 | $3.26/小时 | 未列出 | 预留价比按需价低26.1%。 |
| L40S,单GPU | $1.57/小时 | 未查到公开价格 | 未列出 | 请使用公开的按需价格,不要自行推测Spot对比。 |
| MI350X,每GPU | 未列出公开自助价格 | $4.76/小时 | $3.50/小时 | Spot价比公布的预留价低26.5%。 |
| B300,每GPU | 未列出公开自助价格 | $7.94/小时 | $6.17/小时 | Spot价比公布的预留价低$1.77/小时,即22.3%。 |
B300 目前标价中 Spot 价格低于预留价格;但此前的 Spot 并非在所有情况下都优于预留实例,具体请核对配置可用性、当前定价以及所需的承诺期限。本文的价格对比按单 GPU 计算,并不代表吞吐量相同或整机配置一致。以相同配置、每月 744 小时计算,一台 H100 按需付费为 $3,281.04,按预留时价折算为 $2,425.44。预留价格以 12 个月合同承诺为前提,因此折算月价并非按月灵活付费。
DigitalOcean 的 GPU Droplets 页面列出了支持的配置和规格;在把不同 GPU 型号或系统配置视为可互换之前,请先对比这些细节。
H100 的 74% 盈亏平衡法则
当初创公司在承诺期内大部分时间都需要稳定的算力时,预留容量在财务上才划算。关键的对比指标是计费占用时长,而非 GPU 利用率:一个必须保持在线的端点,即便几乎不处理请求,也可能照常计费。
盈亏平衡使用率 = 预留时价 ÷ 按需时价
以 DigitalOcean 的 H100 为例:$3.26 ÷ $4.41 = 0.739,即 73.9%。凭经验估算,如果你在超过约 74% 的时间里都需要占用 GPU,预留价格就更划算——前提是配置相同、价格恒定,且在回收或额外费用上没有差异。这条约 74% 的法则针对的是整个 12 个月承诺期,而不只是你最忙的那个月。另外要注意,这里衡量的是占用(付费)时长,而非实际用于计算的时长。GPU 只要保持在线,哪怕闲置,也算占用。
假设你的工作负载在 730 小时的规划月内只需要 400 小时:按需付费为 400* $4.41 = $1,764.00。而预留承诺要按全部 730 小时计费,即 730 × $3.26 = $2,379.80。由于你当月只需为占用的 400 小时付费,选择按需可省下 $615.80,而预留承诺则覆盖整月。DigitalOcean 对 GPU Droplets 关机也照常计费,只有销毁 Droplet 才能停止扣费。销毁即意味着终止该实例;之后若要再启动 GPU Droplet,需要重新开通容量并恢复工作负载。
实例演算:训练与推理的成本模型完全不同
使用检查点在 L40S 上训练
假设一次训练任务实际需要 100 个有效 L40S GPU 小时。DigitalOcean 公布的 L40S 按需价格是每小时 $1.57。仅为便于对比,我们假设另一家供应商的 Spot 价格为每小时 $0.50;这个数字并非 DigitalOcean 的 Spot 价格,也不是任何供应商的实际报价。
在不考虑检查点开销的情况下,按需计算的基线成本为 100 × $1.57 = $157.00。假设每进行 30 分钟有效计算,就要暂停一分钟来保存检查点。累计 100 小时有效计算后,这大约会增加 3.33 个计费小时,带检查点的按需基线成本因此变为 (100 + 3.33) × $1.57 = $162.23。

接下来假设发生了五次中断,每次平均损失 15 分钟的计算进度,且每次中断还需要 10 分钟用于启动和恢复。按上述示例 Spot 价格计算,成本为:(100 小时有效计算 + 3.33 小时检查点 + 1.25 小时重算 + 0.83 小时恢复) × $0.50 = $52.71。与 $162.23 的带检查点按需基线相比,在不计存储、传输和工程投入的前提下,成本大约便宜 67.5%。
需要强调,这只是一个模型,不是可承诺的节省金额——结果在很大程度上取决于假设的 $0.50 费率。它说明的是检查点和恢复成本必须纳入计算公式,而不是说初创公司就能指望拿到 67.5% 的折扣。想省 90%,需要费率折扣足够大且额外开销足够小;仅靠检查点做不到这一点。
每 30 分钟保存一次检查点,可以把中断导致的未保存有效工作损失控制在有限范围内——前提是检查点都成功完成且可以访问。但它并不能限制中断时长本身。等待容量、启动、恢复和重算都会拉长整体耗时。在别的 GPU 上干等一小时,就是实打实延误一小时。要注意区分不计费的容量等待和计费的初始化与恢复:两者都会延迟任务完成,但只有后者才会计入 GPU 运行费用。
使用 Spot 节点做 H100 推理服务
再举一例:我们将稳定的 H100 按需基线每小时 $3.26,与估算的 Spot 费率每小时 $2.60 进行对比。这 $2.60 是四舍五入后的示意数字;DigitalOcean 的公开 Spot 目录中并未列出 H100 的 Spot 价格。

按744小时计算,我们的稳定基线方案要花744 × $3.26 = $2,425.44,而假想中的Spot工作节点只需744 × $2.60 = $1,934.40,最高可省$491.04——这还没算任何隐性成本。但如果为了保护Spot工作节点,额外部署一台每小时$3.26、全天候待命的备用副本,又要多花$2,425.44,省下的钱就全搭进去了。
如果集群本身已有闲置容量,情况就不一样了。当稳定集群有足够余量接管宕掉的工作节点时,Spot就能以更低的边际成本增加吞吐量。反之,如果新启动的副本要等20分钟才能顶上,而请求几秒内就超时了,那么冷备方案根本无法保障服务目标。
对于推理场景,应该在达到目标延迟和质量的前提下,比较每次成功请求的成本——而不只是GPU每小时的单价。跟踪首token时间、p95和p99延迟、错误率,以及工作节点丢失后的恢复表现。
Spot账单里的隐性成本
- 第一项是恢复工程。工作节点需要保存进度、把未完成的任务退回队列、安全重试并对输出去重。Spot方案带来的额外开发和运维投入都要计入成本,并把一次性实现费用分摊到你声明的评估周期内,同时将工程投入与直接现金支出分开核算。
- 第二项是数据搬运。任务恢复可能需要在云端或区域之间传输数据集、checkpoint、容器镜像和结果。数据传输费用和准备每台替代工作节点所需的时间都要算进去。
- 第三项是持久化存储。即便没有GPU在干实事,checkpoint和持久化磁盘仍会持续产生费用。恢复所需的额外存储容量、请求次数或保留期限都要计入。
- 第四项是兜底容量。对延迟和可用性要求严格的应用,可能需要预留稳定资源,以便Spot工作节点消失时随时接管。这类设计所需的额外容量要计入成本,还要实测故障切换能否达到服务目标。
- 最后,考虑延迟带来的后果。通宵实验晚两小时完成也许无妨,但错过客户的截止日期就未必了。评估成本时要把这些风险一并纳入,只有业务上有证据支撑时才为其赋予具体金额。
用下面这些公式保证比较的公允:
Spot算力成本 = 示例或报价的Spot小时单价 ×(有效GPU小时 + checkpoint占用GPU小时 + 重算GPU小时 + 计费恢复GPU小时)。
净Spot节省 = 基线总成本 −(Spot算力成本 + 存储与传输费用 + 恢复工程与运维成本 + 兜底容量成本)。
两种方案要使用相同的核算口径。共享的存储与运营成本,要么两边都计入,要么两边都抵消;只统计增量的兜底成本和工程成本。
正式投入前的试点检查清单
| 评审维度 | 需要度量或保留的内容 | 为何重要 |
|---|---|---|
| 可比的工作负载 | 在各配置之间保持模型、精度、上下文长度、并发量和质量要求一致。 | 让成本与性能的对比有意义。 |
| 恢复行为 | 在接近真实的负载下移除一台工作节点;记录通知时间、等待替换的时长、启动与恢复时间、延迟、重试、重算以及未按时完成的任务。 | 反映中断对成本和服务的实际影响。 |
| 每有效结果的成本 | 记录成功吞吐量、计费运行时长、检查点开销、存储、传输、兜底成本,以及每个成功任务或请求的成本。 | 避免把小时单价低误认为单结果成本低。 |
| 定价凭证 | 保存SKU、GPU数量、区域、操作系统、购买方式、费率、报价或定价页截图及日期。区分标牌价、协商价和抵扣额度。 | 让计算可追溯、可复现。 |
| 故障与需求压力测试 | 用预期需求减半、实测恢复时间翻倍、兜底占比提高这些条件重新测算。在接近生产的并发量下测试故障切换。 | 检验商业方案在不利条件下是否依然成立。 |
| 支出控制与续约 | 设定兜底集群上限和预算告警;在续约前,或模型、需求、区域发生变化时,重新评估工作负载和定价。 | 限制恢复成本,防止过时的承诺在无人审视的情况下顺延下去。 |
DigitalOcean 真正可信的优势在哪里
需求还不明确时,先用按需实例。一旦实测计费利用率超过约 74% 的 H100 盈亏平衡点,且承诺条款合适,就可以预留可靠的基线容量。在应用架构上,把可以暂停、保存检查点并重试的工作交给Spot实例来跑。
DigitalOcean在运维层面最大的差异化优势,是它的Spot中断通知目标仅需两小时。GPU价格可以提前确定,预算也更容易规划。新建Droplet时锁定的Spot费率,在其生命周期内不会变动,价格的不确定性因此被限制住了。不过,替换实例可能适用不同费率,而且即使有两小时的通知目标,实例仍可能被突然回收。
在DigitalOcean上可以这样搭建:用预留的H100承载稳定的推理业务作为基线,再用Spot实例处理排队中的训练、嵌入生成或评估任务。在查阅的目录中,H100和L40S均未公开标注支持Spot;MI350X和B300对合适的工作负载来说也是类似选项,但并非即插即用的替代品。从NVIDIA迁移到AMD,还需要对软件栈和性能做验证。
不妨先在GPU Droplets上跑一个有代表性的工作负载,测量计费资源占用和每完成一次成功任务的成本,再执行前文的中断试点。如果稳定基线的收益超过了盈亏平衡点,就把实测的GPU数量、所在区域和12个月需求预测带给DigitalOcean销售团队。基线部分走预留,Spot只用在经过测试、确认恢复流程不影响交付期限且总体成本更低的地方。
最终胜出的GPU策略,是既能可靠完成所需工作,又能给公司留足现金和工程时间去发展的那一个。
结论
Spot GPU能大幅降低弹性训练和批量推理的成本。但如果把利用率、恢复流程和服务要求都算进去,对稳定的生产工作负载而言,预留或其他有保障的容量反而更划算。哪种模式更好,不能只看名字。
DigitalOcean提供具体的H100承诺基线;Azure在特定区域开放了折扣力度很大的H100 NVL Spot计价;Google公布的H100 Spot折扣低于其宣传的最高值;AWS Capacity Blocks则属于定时预留容量的另一种方案,不应与一年期预留混为一谈。
对需要保护现金储备的创业公司来说,务实的起点是:以实测过的基线为主,再搭配弹性容量处理可以等待的任务。预留要保守,checkpoint要持久化,中断恢复要测试,整体部署成本要算清。最终胜出的GPU策略,是既能可靠完成所需工作,又能给公司留足现金和工程时间去发展的那一个
参考资料
- DigitalOcean GPU Droplets定价。
- DigitalOcean Droplet 定价与计费。
- Azure 零售价格 API及API 文档
- AWS Spot 定价。
- Google Cloud Spot 虚拟机行为。
- AWS Savings Plans 与容量预留。
- Azure 预留虚拟机实例。
- Google 基于资源的承诺使用折扣。
- AWS 中断通知。
- Azure Spot 虚拟机行为。
- AWS Spot 实例顾问。
- DigitalOcean Spot GPU 容量。
- DigitalOcean GPU 区域可用性。
- AWS Capacity Blocks 定价。
- Google 加速器优化型定价。
- Google Spot 虚拟机定价。
- Azure NCads H100 v5 规格说明。