AI 成本测算怎么做？从用量记录倒推花费的实操流程

要给项目报价、或者想知道一个月大概烧多少，最靠谱的办法不是拍脑袋，而是从你手上已有的用量记录往回推。这篇给一套可执行的流程：把口径对齐、把用量拆到任务、把不确定的部分留成缓冲，最后落成一张能拿去报价或申请预算的表。

要给项目报价、或者想知道一个月大概烧多少，最靠谱的办法不是拍脑袋，而是从你手上已有的用量记录往回推。这篇给一套可执行的流程：把口径对齐、把用量拆到任务、把不确定的部分留成缓冲，最后落成一张能拿去报价或申请预算的表。先讲清楚一件事——成本测算不是算出一个精确数字，而是算出一个你愿意为它负责的区间。

整个流程走下来大概半天到两天，取决于你手上的用量记录有多全。如果现在连日志都没留，那第一步不是估，是先去埋点，过两周再回来做这件事。下面按顺序拆。

先别估单价：从用途决定算法

很多人一上来就打开某个价格页，盯着单价开始乘调用次数，这基本会算歪。因为单价只是公式里的一个因子，真正决定算法的是这次测算给谁用、覆盖多长周期。用途不同，同一批用量能算出完全不同的两个数。

内部预算

看总量就够，缓冲可以窄，重点是别漏项；报错了顶多下次调整。

对外报价

要看风险敞口，上限要能覆盖掉重试、峰值和口径变动，宁可报高一点也别中途加价。

一次性任务

按项目总用量算，做完就结束，不需要按月摊。

长期在线服务

按自然月算，而且要按均值加峰值两版，因为流量不是平的。

还有一件事要在开头就写下来：哪些成本不在这张表里。比如人工标注、向量库存储、日志留存、失败重跑占用的额外调用，这些如果不在测算范围内，就在表头标注清楚，避免后面和其他人对账时扯皮。

第一步：把计价口径对齐到同一个尺度

这一步是整个流程里最容易被跳过、也最容易出错的地方。你从不同渠道拿到的单价，很可能根本不是同一个东西：有的写输入价，有的写输出价，有的把两者混成一个数，还有的带倍率或者分组折扣。直接相乘，等于拿米乘以尺。

把上面这几项列成一张对照表之后，再去站内页面拿数字。官方价和中转价的口径经常不一样，建议到 /official-api 和 /price-watch 互相对照，两边都看一遍再决定用哪个作为基准。缓存命中的价格通常是单独一档，别把它当成常规单价去算，那会让整个估算偏乐观。

第二步：从哪拿到真实的用量底数

底数越接近真实计费记录，后面的推算就越省事。优先级是这样的：平台自带的用量页或账单导出最准，其次是客户端或网关的请求日志，最后才是自己凭印象估。很多人卡在「没有日志」，其实网关层加一行记录就能补上。

• 每条用量记录至少保留五个字段：时间戳、模型标识、输入量、输出量、用途标签；
• 用途标签自己定，比如按业务动作打，不要留空，否则后面没法归集；
• 没有平台导出时，从网关或代理层抓日志，比在业务代码里到处埋点省事；
• 历史数据不全就挑一段有代表性的时间窗口做样本，再按比例外推到月；
• 样本要避开促销、试用、压测、异常重试这些非典型时段，否则外推会失真。

如果只能拿到汇总数、拿不到明细，也还能做，但要接受精度下降。这种情况下建议把缓冲给宽一点，并且在结论里写明是粗估，别拿它去做对外报价的最终依据。

第三步：把用量拆到具体任务上

汇总数只能告诉你一共花了多少，没法告诉你哪块在烧钱。要能优化、要能报价，就得把用量拆到任务粒度。做法是给每个业务动作打标签，然后按标签汇总。

1. 定义任务标签比如「客服问答」「文档摘要」「批量翻译」「数据清洗」，一个标签对应一类稳定的调用形态。
2. 给历史记录打标签能按调用来源自动分的就自动分，分不了的按提示词特征粗分，再抽样人工核对比例是否合理。
3. 算两个核心数每个任务记单次平均用量（输入加输出）和每月调用次数，这两个数一乘就是该任务的基础成本。
4. 处理混合用量同一批调用里混了多个任务时，先按比例拆，拆不准的就单独列成「未分类」，别硬塞进某个任务里。
5. 标记波动大的任务活动、促销、定时批处理这类任务，按峰值和均值各算一版，报价时用峰值版。

这套拆法在任务量比较平稳时很准。但如果你的用量高度集中在少数几次大请求上，比如每天就几个超长文档要处理，那平均值会被稀释得没有意义，这时候应该直接按单次最大用量去估，而不是按次数乘均值。

第四步：把单价和用量乘起来，并留缓冲

到这里材料就齐了：每个任务的用量底数，加上对齐过口径的单价。接下来是把它们乘起来，并且强制分成三层，别混成一个数。

重试这一层最容易被漏掉。很多团队算出来的账和真实账单差一截，就是因为只算了成功请求。你可以在日志里数一下失败重发的比例，哪怕只是粗略估个系数，也比当它不存在强。至于缓冲比例，没有统一标准，原则是：确定性越高给得越窄，涉及没跑过的模型或没验证过的场景就给宽。

结论写成区间而不是单点：报价时用上限，申请预算时用中位数。

具体单价到站内核对当时的数字，不要拿几个月前的印象价去乘。价格和分组都会变，你记忆里的那个数很可能已经不准了。

第五步：用历史账单反推验证你的模型

估算表做完了不代表能用，得拿真实账单验一遍。方法是找最近一个完整计费周期的账单，和你的估算表逐项对比，看差异出在哪一层。差异本身不是问题，找不到原因才是问题。

• 差异集中在基础层：多半是单位口径或者单价来源不一致；
• 差异集中在重试层：说明失败率估低了，或者有隐藏的自动重试；
• 差异集中在缓冲层：正常，缓冲本来就是留给不确定性的；
• 差异是某一两个任务特别大：回去看是不是有调用量统计漏了，或者有批处理在跑；
• 差得离谱时，先怀疑单位换算，再怀疑单价，最后才怀疑用量。

想快速做交叉验算，可以用站内的 /tools/model-cost-calculator 和 /tools/token-price-calculator，把同一组用量丢进去算两遍，看结果是否一致。两个工具算出来对不上，通常说明你对输入输出的理解有偏差。另外缓存命中、阶梯价、按次取整这几个因素经常是差异来源，对账时优先排查它们。

上线之后：把估算变成持续跟踪

一次性的估算用完就过了，但如果你在做长期服务，这张表应该变成月度对比表。做法很简单：保留估算表的列结构，每个月只填真实数，然后看偏差。偏差超过你设的阈值，就回头查原因，是需求涨了、有人在跑飞、还是口径变了。

1. 固定对比节奏每月固定一天把真实用量填进去，和估算并排看，别等到账单出来吓一跳。
2. 设用量红线给每个任务设一个用量上限，超了就触发排查，先看是需求正常增长还是脚本异常。
3. 监控口径变化模型换代、价格调整、分组变化都会让老估算失效，站内 /price-watch 和 /resets 可以当提醒源。
4. 定期重估每季度把估算表从头走一遍，任务标签和单价都刷新一次，别一直用老表。

这套跟踪不适合调用量很小的场景。如果你一个月就用几次，花在维护对比表上的时间可能比省下的钱还多，那就退回到简单的月度总额检查就够了。

这些地方最容易把账算歪

最后列几个高频坑。它们不一定让你算错数量级，但会让你在报价或者申请预算时被打脸。逐条对照检查一遍，能省掉很多返工。

• 只算成功请求，不算失败重试和超时重发，实际账单会高出预估一截；
• 只看平均用量，不看长尾的大请求，遇到超长输入时单次成本会跳一个台阶；
• 把试用额度、赠送额度当成常态成本，正式跑起来立刻对不上；
• 忽略输出通常比输入贵，长输出的任务要单独拆开算，不能和短问答混在一个均值里；
• 拿别人的用量当自己的基准，任务形态不一样，数字没有可比性；
• 用几个月前的单价去乘，没到站内核对当时的数字，结果系统性偏差。

把这六条逐项在你的估算表里过一遍，能改的就改，改不了的就在备注里写明假设。写清假设比假装精确更有用，因为看表的人知道该在哪里打问号。