3-11 云服务的费用 · 波仔的云计算课

📄 一句话概括

云的计费有三种买法：按量付费（基准价、随时开停）、包月/承诺（承诺 1~3 年换低价，最高约 72% 折扣）、竞价（用云商的空闲容量，便宜 60~90%，但会被回收）；100 台实例按用途分开买，比全部按量省 31.0%——诀窍不是选最便宜的那种，是给每一部分用量配对合适的买法。

📝 本节和前面几节的关系

上一节（3-10）讲的是"要学什么"。这一节转到这一章真正要会算的东西：钱。

教材把它放在这里，是因为前面 3-6、3-7 讲的"钱"是记账层面（进哪张表、怎么摊），3-9 讲的是服务方的工时（成本优化占 28%）——而这一节要回答的是最实际的问题：同样一笔用量，怎么买才最省。 这是本章唯一需要真正动手算的一节，所以难度标了三星。

一、三种买法，各自适合谁

买法	怎么算	适合什么	折扣
按量付费	按秒/小时计费	波动、短期、试验	无（基准）
包月/承诺	承诺 1~3 年换低价	稳定的基线用量	最高约 72%
竞价（Spot）	用云商的空闲容量	批处理、CI、可中断	60~90%

这三种不是在比"哪个便宜"，而是三种不同性质的交易：

按量付费：用多少付多少，随时开随时停。它的价值不是价格，是灵活性——你在为"不确定"付一点溢价。适合所有还没想清楚要不要长期跑的东西。
包月/承诺：用"承诺"换"低价"。你答应未来一年或三年每月都消费一定量，对方给你更低的单价。它的本质是一份期货——你赌自己的用量会稳定，赢了省下几十个百分点，赢了的前提是承诺的量不能超过实际用量（超出的部分白付）。
竞价：用"可被中断"换"极低价格"。用的是云商的空闲容量，所以对方随时可以收回去。它的本质是一次赌博——你赌在被回收之前能把活干完。

看清楚了这三种性质，就能理解本节的核心方法：它们不冲突，可以同时用。

二、一个月 730 小时：三种买法各花多少

以某个实例的按量价 0.100 美元/小时、每月按 730 小时计算：

买法	单价	月成本	说明
按量付费	0.100 美元/小时	73.00 美元	基准
承诺（约 −40%）	0.060 美元/小时	43.80 美元	要承诺 1 年
竞价（约 −70%）	0.030 美元/小时	21.90 美元	随时可能被收回

这三行数字要连着右边那列一起读：

承诺能省 40%，代价是"承诺期间不能停"。如果这台实例实际只跑了半年，那剩下半年的承诺费是白付的——省下的 29.20 美元月费，可能被浪费的半年承诺吃掉。
竞价能省 70%，代价是"随时可能被收回"。这个折扣不是白拿的，它对应的是"你的活可以被随时打断"这个前提。

所以这三行的正确读法不是"选最便宜的"，而是"先按用量性质分类，再分别匹配"。

三、把 100 台按用途分开买

假设一家公司有 100 台实例，可以这样分：

用途	台数	买法	月成本
稳定基线	60 台	承诺	2,628.00 美元
波动部分	30 台	按量	2,190.00 美元
可中断任务	10 台	竞价	219.00 美元
合计	100 台		5,037.00 美元
全部按量	100 台		7,300.00 美元
省下			2,263.00 美元（31.0%）

这个组合的逻辑，就是本节要带走的方法：

稳定基线（60 台）用承诺：这部分无论业务怎么变，一年四季都在跑——承诺它不会亏，因为你知道它一直都在。
波动部分（30 台）用按量：这部分随业务起伏——如果也承诺下来，业务低谷时那部分钱就白付了。
可中断任务（10 台）用竞价：这部分是批处理、定时任务这类断了可以重来的活——用最便宜的方式买最合适。

结果：不改变任何业务行为，只调整买法，费用降了 31.0%。

这个 31% 就是 3-9 里那"28% 的成本优化与治理"工时对应的钱。 它不需要新技术、不需要重构代码，只需要分对类、买对方式——这也是为什么这类工作值得专门有人做。

四、动手 Demo：100 台的三段配置

# 100 台实例，按用途分开买（按量价 0.100 美元/小时，月按 730 小时）
base_n, ond_n, spot_n = 60, 30, 10
p_cmt, p_od, p_spot = 0.06, 0.10, 0.03
m = 730
cost = base_n * p_cmt * m + ond_n * p_od * m + spot_n * p_spot * m
all_od = 100 * p_od * m
print("分开买 %.2f 美元/月" % cost)
print("全按量 %.2f 美元/月" % all_od)
print("省下 %.2f 美元（%.1f%%）" % (all_od - cost, (all_od - cost) / all_od * 100))

实跑输出：

==================================================================================================
D11 云服务的费用：按量、包月、竞价，三种买法
==================================================================================================
  【一】三种买法各自适合谁

  买法                怎么算                      适合什么                  折扣
  --------------------------------------------------------------------------------------------
  按量付费            按秒/小时计费               波动、短期、试验          无（基准）
  包月/承诺           承诺 1~3 年换低价           稳定的基线用量            最高约 72%
  竞价（Spot）        用云商的空闲容量            批处理、CI、可中断        60~90%

  【二】一个月 730 小时：三种买法各花多少（按量价 0.100 美元/小时）

  买法                  单价                  月成本          说明
  ------------------------------------------------------------------------------------
  按量付费              0.100 美元/小时       73.00 美元      基准
  承诺（约 −40%）       0.060 美元/小时       43.80 美元      要承诺 1 年
  竞价（约 −70%）       0.030 美元/小时       21.90 美元      随时可能被收回

  【三】把 100 台按用途分开买

  用途                      台数      买法              月成本
  --------------------------------------------------------------------------
  稳定基线                  60 台     承诺              2,628.00 美元
  波动部分                  30 台     按量              2,190.00 美元
  可中断任务                10 台     竞价              219.00 美元
  --------------------------------------------------------------------------
  合计                      100 台                      5,037.00 美元
  全部按量                  100 台                      7,300.00 美元
  省下                                                  2,263.00 美元（31.0%）

  【四】竞价的两分钟（2026 现状）
     AWS 提前 2 分钟通知回收，Azure 与 GCP 只有约 30 秒。
     所以竞价只能用在【断了不影响结果】的活上：有状态的数据库、
     不能中断的任务，一律不许碰。

读这个输出：第三段的三行分别对应三种用量性质——60 台一直跑、30 台忽高忽低、10 台随时可断。这个分类不是技术分类，是业务分类：你要问的不是"这台机器配置多高"，而是"它的活能不能停、会不会一直跑"。

最后一段那句限制要当成硬规矩记住：竞价不是"便宜的选择"，是"有前提的选择"——它的前提是"被收走也不影响结果"。给数据库用竞价，省下的钱不够赔一次数据损坏。

五、⚠️ 2026 现状

"竞价"这个名字要更新一下认知：现在的模型已经不是拍卖了。教材写的年代还带一点拍卖的味道（出价高者得），现在的主流做法是动态定价——你按当时的价格直接用，云商需要时提前通知回收。 所以网上老教程里"设置最高出价"的说法，多数已经过时。
回收的预警时间各家不一样，这件事是设计的前提。AWS 提前 2 分钟通知，Azure 与 Google Cloud 只有约 30 秒；Google 的 Spot 实例还取消了老式抢占实例的 24 小时强制上限。这 2 分钟与 30 秒的差别，直接决定了你能不能在被收走前把状态存下来——所以选哪家之前，先看你的程序能不能接受 30 秒。
承诺折扣的形态在往"更灵活"的方向走。过去承诺要绑定具体的机型、具体的区域；现在出现了按"每小时消费额"承诺的形式，可以跨机型、跨区域、甚至跨服务使用。这让"承诺"的风险显著降低——即使换了机型，承诺也不会浪费。
对 AI 负载来说，这套买法要再加一层。GPU 实例的供需和普通实例完全不同，除了按量、承诺、竞价，还多了"容量预留"这类提前锁定资源的形态。所以 2026 年的成本优化，第一次需要把普通负载和 AI 负载分开算。

30 秒实验

打开你的云账单（或者任意一份云服务的定价页），做一次分类：

列出你正在付费的实例或服务——大概心里有数就行，不用精确。
把每一项标一个字母：A 表示"一直跑、不能停"，B 表示"时开时关、需求有起伏"，C 表示"断了可以重来"。

标完之后，对照本节第三段那张表，看现在的买法对不对得上——A 类应该用承诺，B 类应该用按量，C 类可以考虑竞价。只要有一项对不上，那里就有可以省下来的钱。 这个动作不需要工具，一支笔就够。

常见误区

错误：竞价便宜 70%，能用的地方尽量用。——纠正：它的前提比价格重要得多。竞价的本质是"对方随时可以收回"，回收预警 AWS 只有 2 分钟、Azure 和 Google 只有 30 秒。所以只有"被中断也不影响结果"的活能用——批处理、构建任务、可重跑的数据处理。有状态的数据库、不能中断的交易系统，一律不能用。 省下的钱和一次数据损坏的损失不在一个量级。
错误：承诺折扣高，那就尽量多承诺。——纠正：承诺的性质是"不管用不用都要付"。如果承诺的用量超过了实际用量，超出的部分是纯浪费——这比不打折还糟，因为你付了钱却什么也没得到。所以正确的顺序是：先看至少一个月的历史用量，确认基线在哪里，只对确认会用的部分做承诺（这也是这一类优化的通行做法：先对齐规格、再承诺）。
错误：按量付费是最贵的，所以应该只用来做测试。——纠正：按量付费的溢价是"灵活性"的价格，它本身是一种正确的选择。Demo 里那 30 台波动部分，如果改用承诺，省下的单价会被业务低谷时白付的钱吃掉。所以按量付费不是"次优选择"，它是专门为"用量不稳定"这件事设计的买法。 判断标准是"这部分用量稳不稳"，不是"哪种价格低"。
错误：三家的竞价规则差不多，可以照着同一套方案搬。——纠正：预警时间差得很远，这直接改变了技术方案。AWS 给 2 分钟，可以在收到通知后存盘、把任务挪走；Azure 和 Google 只给约 30 秒，程序必须在运行期间就持续保存状态，而不是等通知。所以同一套"竞价上的架构"，在不同云上的可行性是不同的——换云的时候，这一条要重新验证。

自测三问（点开对答案）

1. Demo 里省下的 31%，靠的是换技术还是换买法？ —— **纯粹靠换买法**。三段的实例数量、规格、跑的业务完全没变，**唯一的变化是"哪部分用哪种计费方式"**。这也说明为什么 3-9 里"成本优化与治理"占了 28% 的工时——**这项工作不需要改代码，只需要持续地分类、调整、复核**。它省的每一分钱都是净利润。 2. 为什么"波动部分"用按量付费比用承诺更划算？ —— 因为**承诺要求你在一段时间内持续付费，而波动部分的特点是"有时候不用"**。业务低谷时那部分实例可能只跑了一半时间，**但承诺费照付**——省下的 40% 单价，被"一半时间白付"完全抵消甚至反超。**所以判断标准是"这段时间里它会不会一直跑"，而不是"它的单价是多少"。** 用量越不确定，按量的溢价越值。 3. 为什么"给数据库用竞价"这个错误特别严重？ —— 因为**竞价的回收是不可协商的**——通知只有 2 分钟（甚至 30 秒），到点就收走。数据库是**有状态的**：它上面可能正有未提交的事务、正在写的日志、内存里没落盘的数据。**被强制收走的后果不是"服务暂停一下"，而是可能的数据损坏或不一致。** 所以这里的原则是**按"最坏情况代价"来分类，而不是按"平均能省多少"**：可以重跑的东西才允许被中断。

☐ 下一节（3-12 云计算中需要长期支出的费用：总体成本、人工成本）