用Python估算LLM功能的人均成本
文章以客服工单摘要为例，介绍如何建立LLM功能的人均成本模型，避免仅按单次提示词Token量估价。文中价格和用量均为演示数据，实际预算需替换为当前供应商或合同费率。
原文暂未完整获取，基于公开信息的快读
给 LLM 功能估价，只算一次请求用了多少 Token，很容易低估月账单。dev.to 的这篇文章以客服工单摘要为例，展示如何用 Python 把请求频次、缓存、重试和额外开销纳入人均成本。文中的价格与用量都是演示数据，不能直接拿来做预算。
目前能确认什么
作者给出的基础关系是：单次成本由输入、输出 Token 分别计价，再乘以每位活跃用户每月的请求次数，得到月度人均成本。
输入也不只是用户发来的文字。系统提示词、少样本示例、检索上下文和对话历史，都要算进去。作者建议取 20 到 50 条脱敏且有代表性的输入，套用实际提示词模板调用 API，记录返回的用量，同时看中位数和 p90，避免平均值掩盖长工单的费用。
Python 模型进一步加入了缓存输入占比、重试率，以及评估、裁判模型和回退调用等额外开销。缓存可能降低费用，但命中比例需要实测；重试则要统计每次调用，不能只数成功结果。
文中的费用结果只用于演示计算关系，不代表任何供应商的真实报价。
我的判断
这套方法对上线前最有用的提醒，是先明确「人均」的分母。节选按月活跃用户计算，如果拿注册用户数去摊成本，就可能把预算压得过低。
另一个具体启发是，优化摘要长度之前，先检查发送了多少上下文。在文中示例里，即使输出 Token 单价更高，输入仍占较多费用；不过，这个结论不能直接套到所有功能。
我更看重把成本脚本放进代码仓库：提示词增加示例、拼入更多历史记录时，可以同步重算预算，让费用变化进入代码评审。
目前节选没说清请求频次和额外开销比例该如何采样，也未展开不同回退模型如何分别计价。缓存规则、失败请求是否收费，则需要对应供应商的官方文档或合同确认。