降本10%怎么算

老板丢下一句「这个季度成本降一成」，很多人第一反应是去砍模型，结果月底一算没降多少。问题不在于没动手，而在于一开始没定义「降谁的、相对哪段时间、按什么口径」。这篇给一套能落到表格里的算法：先把基准线锁死，再把十个百分点摊到几个可动分项上，每个分项算出需要减多少量或换什么档，最后用站内页面核对当期数字。

老板丢下一句「这个季度成本降一成」，很多人第一反应是去砍模型或换档位，结果月底一算没降多少。问题不在没动手，而在一开始没定义「降谁的、相对哪段时间、按什么口径算」。口径不写清楚，两个人用同一份账单能算出两个完全不同的降幅。

这篇给一套能直接落到表格里的算法：先把基准线锁死，再把目标摊到几个可动分项上，每个分项算出需要减多少量或换什么档，最后用一个完整周期回来看分项差额。所有单价、汇率、档位对照，都到站内页面核对当时的数字，不在纸面上预设。

第一步：先把「降 10%」的基准线锁死

基准没定的降本讨论基本都是空转。选一个统计周期（上一个完整月最省事），把这个周期里相关支出加总当分母。周期一变，后面所有百分比都会漂。建议把基准写成一页纸：周期、口径、分项金额、数据来源页面，团队里谁都能按同样步骤复现。

• 口径要写进表头：只算 API 按量支出，还是把订阅费、中转充值、算力租用一起算进来，两套口径得出的降幅差得很大
• 确认账单里有没有一次性支出，比如年付摊销、充值赠送、测试期集中调用，这类要先剔除或单独标注，否则基准被抬高，达标看着很容易
• 把每个分项的数据来源页面记下来，后续核对时不用重新找入口，直接对着同一页比

第二步：把十个点摊到可动分项上，别整体砍

十个百分点不等于每项都降十个点。先做一张分项表，把调用量、单价、缓存命中情况、重试与失败请求、订阅席位、闲置资源逐行列出来，写清金额和占比。占比最大的那一两项扛大头，占比很小的项动它性价比很低，甚至不值得单独排期。

按可动性排序后，每项给一个待验证的假设，比如「重试占比偏高」「长上下文任务吃掉大量输入」。假设要能用日志证伪，证不了的就先放下，别把不可控项算进目标里。

第三步：逐项算差额，凑够目标就停手

单项目标额 = 基准总额 × 目标降幅 × 该项占比权重。换算成动作就是「这项要少花多少钱」，而不是「这项要优化多少」。先在表里把每项要贡献的差额写出来，再去找对应的动作，顺序不要颠倒。

1. 算调用量差额用当期单价乘以需要减少的 token 量，倒推能砍掉哪些任务或改成批处理。单价一律到 /official-api 和 /tools/token-price-calculator 取当期数字，别用记忆里的旧值。
2. 算换档差额把低价值任务从小模型或更便宜的档位跑，用 /tools/model-cost-calculator 算同一任务换档前后的差额，再决定换哪几个任务，不要整站一刀切换。
3. 加总并贴线把每项算出的差额加总，贴着目标线即可。超出目标太多的方案往往意味着牺牲质量，容易在下个周期反弹回来。

第四步：跑一个周期后回来核对，别只看总数

下一个完整周期结束时，按同一口径重算一次，比较的是分项差额，不是总额。总额受调用量自然波动影响，会掩盖真实效果。分项对不上，说明动作没落到实处，而不是目标定得高。

给每个分项留一个观察指标，比如平均上下文长度、失败重试次数、缓存命中情况。指标没动，就说明对应的动作没生效，先回去改动作，别急着调目标。

什么情况下这套算法不适用

这套拆法成立的前提是业务量相对稳定、成本大头在调用费上。两个前提有一个不成立，硬套就会得到误导性结论。下面几种情况要换算法或干脆先别谈降幅。

• 业务量本身在快速变化时，固定基准会失真，改用单位成本对比更稳，比如每千次调用、每万 token 的成本，按同一口径跨周期比
• 成本大头是人力而非调用费时，百分比拆法会误导，应该按人力工时单独核算，调用费只作为附注
• 刚上线还没跑满一个完整周期的项目没有可靠基准，先记录用量再谈降幅，硬套只会吵口径
• 多团队共用一份账单时，先做成本归属拆分，否则谁降了谁没降说不清，测算也落不到责任人

判断标准很简单：拿一份历史账单，如果两个人按同一口径各算一遍能得到接近的数，这套算法就能用；如果算出来差很多，说明口径还有没锁死的地方，先回去补第一步。

降本不是砍得最狠，而是每一分差额都能对得上账。