LLM API 成本预算器

账单失控之前，先建立一个可审计的模型

大模型 API 的账单往往到了月底才暴露问题：一次重试风暴、一轮缓存命中率下滑，或者新增的搜索与媒体调用，都可能让实际开销明显偏离预期。而 requests * avg_tokens 这类平均数模型，在 token 分布偏斜时会系统性失真——少数超长请求或高推理 token 的请求会把均值拉高，同时掩盖大多数请求的真实成本。

这个技能要解决的核心问题，就是把目录价格和实测账单严格分开，并且让所有假设可见。

它如何工作

核心流程可以拆成三段。

1. 先收集价格与用量口径

• 模型 ID、每百万 token 的输入与输出价格
• cached-token 定价、按请求计费的固定费用、货币单位

2. 用 P50 与 P95 替代单一平均值

当 token 分布偏斜时，只用平均值做月度估算必然出错。技能要求分别取输入与输出 token 的 P50 与 P95，再各自计算基线成本。

3. 逐项叠加，再只扣除已验证的部分

基线公式为：

requests * ((input_tokens / 1M) * input_price + (output_tokens / 1M) * output_price)

在此基础上叠加：重试放大、工具调用产生的子请求、推理 token、搜索与媒体费用、供应商加价。扣除项只认已验证的缓存节省，并且要求明确展示假设的缓存命中率——不把假设当成事实写进结论。

输出与适用边界

技能返回假设表、月度模型、低/基准/高三档预测、排名前三的成本驱动因素，以及具体的控制手段。数据可得时，还会计算单次请求、单个成功任务、单个活跃用户乃至业务结果的单位成本。告警与临界阈值设定在硬性账户限额之下，而不是贴着限额运行。

需要注意的边界：

• 价格字段缺失时会被标记为缺失，而不是按 0 处理
• 绝不输出 API key 或账单标识符
• 当估算缺少真实的 token 与重试遥测数据时，技能会建议先补齐埋点，而不是继续凭经验外推