成本计算器案例

第一次打开成本计算器，多数人卡在两处：不知道该填哪些项，以及算出来的数字到底能不能拿去报预算。这篇不讲公式推导，只走一遍从拆项到出结论的完整动作：先列出这活儿的变量，再决定哪些项必须实测、哪些项可以取区间，最后看结论该保守还是该收紧。适合要给别人报数、又不想报错的人。

第一次打开成本计算器，多数人卡在两处：不知道该填哪些项，以及算出来的数字到底能不能拿去报预算。这篇不讲公式推导，只走一遍从拆项到出结论的完整动作，拆成两个通用场景演示。

核心思路是：先列出这活儿的变量，再决定哪些项必须实测、哪些项可以取区间，最后看结论该保守还是该收紧。适合要给别人报数、又不想报错的人。注意，计算器算的是量级不是承诺，具体单价一律到站内页面现取。

先拆项，再打开计算器

打开计算器之前先在纸上列变量，这一步花十分钟，能省掉后面反复重算。变量漏一项，结果就整类偏掉，而且偏的方向很难事后发现。

• 用量规模：一个月多少请求，或者多少 token 总量；
• 单次长度：平均输入多长、平均输出多长，两者分开记；
• 损耗比例：缓存命中率、重试或重发比例，早期只能给区间；
• 单价口径：按量、按次还是套餐内折算，输入价与输出价分开看。

这四类里，前两类通常能从日志捞到实测值，后两类早期只能估。不要把估算值当确定值填进去，否则预算结论会假装很精确。单价不要凭记忆填。

案例一：客服问答机器人的月度预算

场景设成一家 5 人小团队做内部知识问答。先按日均问题数乘工作日数得到月请求量，再用平均提问长度和平均回答长度分别算输入、输出 token，两笔分开计。

1. 算月请求量日均问题数乘当月工作日数。验证办法：拿一周真实日志统计日均，和估计值对一下，差得多就以日志为准。
2. 算单次 token输入长度取提问加检索片段的合计，输出长度取回答。抽样几十条真实记录取平均，别用最长值。
3. 代入三档乐观、基准、保守各算一遍。三档差异主要来自重试比例和缓存命中率，不是单价本身。
4. 读结论结论写成区间加前提，例如按当前用量节奏月度落在某区间，日均问题数翻倍就重算。数字本身去 /tools/model-cost-calculator 现算。

保守档建议把重试率按经验上限填，再单独留一段缓冲，不要把它混进模型单价里，否则后面调参时看不出来钱花在哪。

案例二：批量文档处理的单批成本

场景设成一批长文档做摘要。关键项是文档总字数、切分粒度和每段是否重复带上文。切分粒度一变，输入 token 就可能明显放大，这是最容易算漏的一项。

长文档还要单独处理缓存与重试：重复段落能不能命中缓存、失败重发会不会重复计费，都会明显改变结果，换算项到 /tools/token-price-calculator 核对口径。

批量任务的结论必须带上时间成本。单价便宜但排队久，整体是否划算取决于交付窗口；如果交付时间不可挪动，这条成本口径就不适用。

结论怎么写才不被打回

算完不等于能报。把结果整理成三栏，评审的人一眼能看出哪些是硬数、哪些是猜的，返工概率会低很多。

• 已确定项：来自日志或现有账单的实测数；
• 假设项：缓存命中率、重试率这类估计值，写清取值来源；
• 待验证项：写清用什么办法验证、大概多久能验证；
• 敏感度：点名一两个影响最大的变量，通常是用量规模和缓存命中率。

适用范围也要标出来。新业务、用量样本不足、计费口径刚调整这三类情况下，计算结果只能当量级参考，不能当承诺数，直接写进结论里比事后解释更省事。

算完之后按这个顺序复核

复核顺序错了容易白忙，建议按下面四步走，前一步没过就不要进下一步。

1. 核单价口径到 /official-api 或 /models 核对当前计费方式，确认输入、输出、缓存是否分开计，口径不对后面全错。
2. 核用量来源检查日志字段是否齐全，缺字段就先补记录再算，别用拍脑袋的日均值。
3. 核假设项把缓存命中率和重试率换成实测值重算一遍，两次差值就是当前估算误差，这个差距要一并写进结论。
4. 留复核点约定下次复核的触发条件，比如用量增长、换模型、计费规则变动，避免一份预算用过一年。

计算器给的是量级和敏感度，不是承诺数；没写前提的预算，迟早要重算。