价格上调5%怎么算

收到供应商或中转站的调价通知，写着「上调 5%」，第一反应是打开计算器乘 1.05——但如果你的账单里混着缓存价、阶梯价、按次收费和赠送额度，乘一次 1.05 得到的数往往对不上真实扣费。这篇给一套三步换算顺序：先分清基数口径，再算单次和月度差额，最后判断这次调价值不值得换方案。全程只讲算法和核对动作，不给固定数字。

收到供应商或中转站的调价通知，写着「上调 5%」，第一反应是打开计算器乘 1.05。但如果你的账单里混着缓存价、阶梯价、按次收费和赠送额度，乘一次 1.05 得到的数往往对不上真实扣费。所以别急着算钱，先花两分钟把口径理清楚。

这篇给一套三步换算顺序：先分清基数口径，再算单次和月度差额，最后判断这次调价值不值得换方案。全程只讲算法和核对动作，具体数字请到站内页面拿当时的值。

第一步：先确认「上调 5%」的基数是什么

同样是 5%，落在不同计费项上算出来的钱能差出一截。先别管比例，先搞清楚通知针对的是哪一类单价、在哪个价的基础上调。这一步错了，后面乘得再准也是白算。

• 确认基数是原价还是折后价：走限时折扣或赠送额度抵扣的，调价通常动的是原价，折扣另算。
• 确认是否只调某一段：常见的只动输出价、不动输入价，或者只动某一阶梯档位。
• 确认是否有生效条件：比如新老用户不同价、或某档用量以下不调。
• 拿不准就去 /official-api 和 /price-watch 核对该家当前口径，别照着自己记忆里的老价算。

第二步：单次与月度差额怎么算

1. 算单次新价和差额单次新价 = 原单价 × 1.05，单次差额 = 原单价 × 0.05。按量场景下这两个数都要再乘你的用量才是钱，别把单价当成本。
2. 算月度差额粗值月度差额 ≈ 上月该项费用 × 0.05。成立的前提是调价前后用量不变、计价口径不变。
3. 用量在涨就叠趋势先用上月账单乘 5% 拿到最低增量，再把最近三个月的用量趋势套上去，得到一个区间而不是一个点。
4. 拿真实日志验证到 /usage 看同类模型的实际消耗，用真实用量当基数，别拿订阅页的宣传额度当分母。

如果业务量比较稳，月度差额粗值已经够用。用量在涨的团队，这个粗算会系统性低估，因为涨价的部分会落在更多请求上，必须按区间来估，后面做判断时才不会被打脸。

什么情况下这套算法不成立

这套算法成立的前提是账单结构单一、计价口径不变。只要碰上下面这几种情况，整体乘 1.05 就会失真，得拆开逐项算。

• 账单里混着缓存命中价、批量折扣、阶梯价：整体乘会偏高或偏低，要先按计价项拆开再逐项乘，缓存口径怎么算去看 token-cost 那篇。
• 调价同时伴随限速或额度缩减：实际成本增幅会大于 5%，要按「单位时间能跑多少活」重算，而不是按单价。
• 按次或按秒计费且带最低计费单位：短请求多的业务，取整会把涨幅放大，要单独抽样几个典型请求算。
• 订阅加超额按量的混合模式：月费和超额费要分开乘，加在一起乘一次必错。

百分比是乘在口径上的，不是乘在你印象里的单价上的。

算完之后怎么用这个数

算出差额不是终点，是用来做两个决定：留还是换，以及下次怎么更快算。先给自己定一条能接受的月度增量线，超过就去比一遍同类替代方案。

1. 跑一周实测调价生效后拿真实账单和你的预估区间对一下，偏差大说明还有计价项没算进去，回头补口径。
2. 写一条换算记录记下原单价口径、调价口径、你的用量基数、算出的区间。下次再调价直接复用，不用从头推。
3. 决定是否换方案月度增量超线就去比替代方案，顺序按上面表格来，别只看单价，要看同口径下的总支出。