为什么必须按租户摊成本
只看"这个月花了多少钱"，你无法回答：是哪个功能、哪个租户、哪类请求在花钱。
结果就是涨价时只能一刀切（要么全站降价体验，要么全面提价），而这通常都是错的决策。
单位经济模型：先算三个数
- 单次调用平均成本（按功能分组：问答、抽取、生成、批量任务）；
- 单活跃用户成本（月成本 / 月活）；
- 单付费用户毛利（收入 − 变动成本）。
有了这三条，才谈得上"这个功能是否值得做"。
成本要摊到哪几维
- 功能：哪个入口最贵（常见是"让模型反复重试"的那条链路）；
- 租户：Top 5 租户占比多少（集中度高就说明有脚本或死循环）；
- 任务类型：交互式 vs 批量；
- 模型/版本：换版本后成本是否变化；
- 缓存命中：命中率低通常意味着可优化空间大。
三条常见的"看不见的浪费"
- 重试放大：失败重试把成本翻倍，却只在错误率里体现，不进成本归因；
- 上下文过长：把整份文档重复塞进每轮对话；
- 批任务不设上限：某个租户一次提交十万条，账单当天翻倍。
该看什么指标
- 单位成本趋势（周环比），比总额更能发现问题；
- 成本 Top 功能/租户占比；
- 缓存命中率与重试率；
- 每千次调用的 token 消耗（判断提示词是否在膨胀）。
落地顺序
- 先给每次调用打上"功能/租户/模型版本"标签（不改业务逻辑，只加标签）；
- 汇总出单位成本与占比；
- 找出 Top 1 的浪费点，做一次优化并记录前后对比；
- 建立成本预算与告警（按租户与全局各一条）。
关键纪律：任何成本优化都要同时记录质量指标。只看成本，迟早会把质量赔进去。