为每个功能建一条成本基线
功能上线时除了看质量指标，还应当留下一条成本基线：每千次请求的成本折算值、每请求的输入与输出 token 分布、缓存命中率、重试与结构化输出重试次数。基线的作用不是记账，而是回归监控——后续版本、提示词改动、依赖升级或模型切换造成成本偏移时，能立刻看到并与具体变更对齐。
基本信息
| 核心指标 | 每千次请求成本、每请求 token 分布、缓存命中率、重试率 |
|---|---|
| 辅助指标 | 平均输出长度、结构化输出解析失败率、超时率 |
| 基线口径 | 固定输入分布下测量，写明模型版本与提示词版本 |
| 监控频率 | 按日采集、按周对比、变更后立即复核 |
| 阈值设定 | 以历史波动幅度为参考，避免用拍定的固定比例 |
| 归属划分 | 按功能或按业务线分开，便于定位成本增长来源 |
典型使用场景
- 新功能上线：建立第一条基线并作为后续对照的起点
- 提示词改版：确认输出变长或检索变多是否带来成本上升
- 依赖升级：SDK 默认参数或重试策略变化后的成本核对
- 模型切换：替代版本的单位用量与输出风格变化需要重算
- 容量与预算：按实测基线外推增长曲线，替代凭感觉估算
- 异常排查：账单增长与请求量不一致时，用基线定位偏移环节
指标与偏离原因
| 指标 | 基线怎么定 | 偏离的常见原因 |
|---|---|---|
| 每千次请求成本 | 固定样本集折算并记录公式 | 模型切换、提示词变长、重试增加 |
| 输入 token 分布 | 按场景记录中位数与 p95 | 检索片段数增加、上下文模板改动 |
| 输出 token 分布 | 按输出形态分档统计 | 结构变化、格式约束放宽、未设输出上限 |
| 缓存命中率 | 按前缀稳定性分组测量 | 提示词前缀被频繁修改导致缓存失效 |
| 重试率 | 按错误类型统计 | 限流与超时上升，默认重试策略变化 |
| 解析失败率 | 结构化输出单独统计 | 格式约束与模型行为不匹配，反复重试 |
| 人工修正率 | 抽样统计后折算成本 | 质量下降导致人力投入增加，隐性成本上升 |
回归告警思路
回归告警思路
# 目标：把成本偏移转成可自动判定的信号
alert_rules:
- name: per_request_cost_drift
window: 7d
compare: 与功能基线对比
trigger: 偏离超过历史波动幅度上界
actions: [标记变更时间轴, 通知功能负责人]
- name: output_length_drift
window: 7d
compare: 输出 token 中位数
trigger: 连续三个采集周期上移
actions: [核对提示词与输出上限]
- name: retry_rate_spike
window: 1d
trigger: 重试率显著上升
actions: [排查限流、超时与默认重试策略]
- name: cache_hit_drop
window: 7d
trigger: 命中率下降导致单位成本回升
actions: [检查提示词前缀稳定性]
context:
log_fields: [model_version, prompt_ver, usage, retry_count]成本回归的难点在归因而不是检测：指标偏移通常能自动发现，但要说清原因需要把版本信息一起记录。把模型版本、提示词版本与用量字段写进同一条链路日志，排查时间会从数天降到数小时。
阈值不要拍脑袋。先观察基线在正常运行期的波动幅度，取波动上界加一点余量作为触发线；阈值过紧会持续误报，最终没人看，监控等于没有。
不要只盯账单总额。总量增长可能来自业务增长而非效率退化，只有单位成本与分布指标才能反映真实变化；同时成本下降也可能来自质量降低或缓存命中被误算，需与质量指标一起看。