先说结论
一句话：云账单虚高，常常不是单价贵，而是按峰值买了资源，大部分时间在为空转付钱。Modal 官方博客最近讲了 Sandbox 的突发式资源计费：默认按实际用量结算，官方口径是比固定预留省约 58%。
我的判断有两条。一条：58% 不是优惠力度，而是浪费比例的镜像，之前为闲置资源付的钱大约就是这么多，省下来的只是把没用的部分退掉，不是平台让利。另一条：突发式不是新魔法，它只是把「买大份」改成「吃多少付多少」，负载形状对了才省钱，形状不对反而更贵。
划重点：省钱的本质不是砍单价，是让账单匹配真实的资源曲线。曲线对不上，单价再低也救不了账单，这是所有云成本优化的第一性问题。
按峰值买资源亏在哪
传统预留模式的流程：先估峰值，按峰值或 95 分位锁定固定资源，跑多跑少都付一样的钱。这个逻辑在十几年前是合理的，那时机器不开机也要折旧，容量就是硬成本；可到了按秒计费的云上，容量早就变成了可以被计量、被切分的东西，还按峰值买，就等于把可切分的东西整块买断。
Modal 给了个扎心的数字：典型 Sandbox 超过一半时间，CPU 用量不足峰值的 6%。说白了，你按满配交钱，一半以上的时间只用零头，剩下九成多的容量常年躺在账单里，连折旧都算不上，纯粹是给空气付费。
预留模式本身没错，错在拿峰值当日常。固定资源买的是「上限保障」，负载真正需要的是「平均用量」，两者之间的差价，就是账单虚高的那部分。峰值越偶尔、越尖，这个差价越大；也正因如此，闲置率才是账单里最该被盯住的那根线。
突发式怎么算这笔账
突发式走的是另一条路：平时给一个基础额度，要用时短时跑满，跑多少算多少，账单按实际用量结算。定价的锚点从「容量」换成「用量」，这是它和预留模式最大的分野，也是为什么同样的活，账单能差出这么多。
划重点：突发式省下的是「没发生过的峰值」那笔钱，代价是极端尖峰可能被限。资源池被占满时，抢不到的人只能排队或降速，任务完成时间不再有硬保证，便宜是用确定性换来的。
所以突发式省钱有个隐含前提：负载得有弹性。尖峰可以等、可以慢、可以重试，省下的钱才拿得稳；尖峰一步都不能等，省下的钱会以另一种形式还回去，可能是超时重跑，也可能是一次线上事故。
适合谁不适合谁
适合突发式的负载画像很统一：大部分时间闲着，偶尔冲一下。批处理任务、AI 训练、CI 构建都算，它们不要求固定响应时间，慢几分钟无所谓，算完就行，弹性对它们来说不是妥协而是常态。
不适合的也明确：需要恒定低延迟的在线服务。用户点一下就要有回应的接口，不能赌突发额度，该预留还是预留，省钱不能省在用户体验上。这类负载的形状本来就是平的，突发式那套省法在它身上无从发力，硬切只会两头不讨好。
判断方法很简单，问一句：我的资源曲线长什么样？平缓就预留，锯齿状就突发。负载形状决定计费模式，这个顺序反了，省钱的愿望就得落空，还会连带把稳定性搭进去。
小团队先看闲置率
对普通开发者和小团队，这篇博客最该记住的不是 58%，是那个 6%。先看自家账单背后的闲置率，比研究任何计费名词都实在，因为闲置率是你自己就能算出来的东西，不需要谁背书。
怎么看：把云平台监控里的 CPU 曲线拉出来，如果大部分时间在低位打转，只有零星尖峰，你的负载和 Modal 描述的情况高度重合，按用量计费大概率更便宜，这笔对照不需要付任何学费。
选模式别听厂商单方面宣传，拿真实负载跑一周对比：同一批任务，固定预留和按用量各跑一遍，账单差多少，数字自己会说话。省没省、省多少，一周的样本胜过任何一张宣传图。
整个检查用不了十分钟：登录控制台，导出最近一个月的用量报表，看 CPU 平均利用率和尖峰出现的频率。利用率常年是个位数，你大概率在为空转付钱，切换前先算清这笔账，别急着换。
但这里有个前提
再泼一盆冷水：58% 来自官方博客的典型场景，不是对所有人的承诺。突发式对「闲多忙少」的负载划算，对忙碌又均匀的负载可能不省钱，甚至更贵；把别人的典型当成自己的均值，是最常见的误读。
说白了，对错取决于你的负载形状，不取决于厂商的宣传口径。计费模式没有好坏，只有匹配不匹配，先看清自己的曲线再站队，别让一句省 58% 替你做决定。
读这篇博客的正确姿势：先看懂机制，再用自己的数据验证，最后决定切不切换。省 58% 的前提，是你的负载大部分时间真的闲着，而这个前提，只有你自己的监控能回答。
