深色模式
成本看板与预算管控
摘要：有了 Token 成本与用量监控 的指标底座，本文解决"治理"问题：如何把成本归因到租户与业务场景、如何设计一张领导看得懂、工程用得上的成本看板、如何把预算管控跑成月度流程。适用栈：LiteLLM / 自建网关 + Prometheus + Grafana + Langfuse。
成本分摊：先定口径再看板
成本看板最大的坑不是技术，是分摊口径：同一个"智能客服"场景可能同时调 GPT-4o（兜底）与轻量模型（初筛），按模型分组看会得到一堆与组织架构对不上的数字。建议三层维度体系：
| 维度 | 来源 | 用途 |
|---|---|---|
| 租户 / 业务方 | 网关虚拟 Key / API Key | 谁花钱，账单分摊 |
| 场景（scene） | 调用方传入的标签 | 成本优化落在哪个功能 |
| 模型 | 网关记录 | 单价结构分析、降本效果 |
关键工程约定：租户与场景标签必须在网关层强制——调用方不传标签就拒绝请求（或归入 untagged 并告警）。未标注流量一旦超过 5%，看板就会失去治理价值。
看板设计：四块结构
Grafana 成本看板建议按"总-分-因-控"四块组织：
- 总览（日/月粒度）：总成本、环比、预算水位条（
已用/预算）。给管理层看，数字必须与财务对账一致。 - 分解（TopN 表格）：按租户、按场景、按模型的成本 Top10 及占比——回答"钱花哪了"。
- 归因（趋势与异常）：单请求 P95 成本趋势、缓存命中率、按场景的单次对话成本——回答"为什么涨"。
- 控制（预算状态表）：各租户预算消耗进度、硬限流触发次数、
untagged流量占比——回答"管住了没有"。
promql
# 月度累计成本 vs 预算（水位）
sum(increase(llm_requests_cost_usd_total[30d])) by (tenant)
/
on(tenant) llm_budget_total_usd
# 单次对话成本（scene 维度，按会话聚合后的均值）
sum(increase(llm_requests_cost_usd_total[7d])) by (scene)
/
sum(increase(llm_sessions_total[7d])) by (scene)1
2
3
4
5
6
7
8
9
2
3
4
5
6
7
8
9
对账一致性是生命线
看板数字与财务账单（厂商发票）通常有 1%~3% 的差异（汇率、缓存计价滞后、未计费调试流量）。建立月度对账流程：网关估算成本 vs 厂商账单的差异率 > 5% 时视为计量故障，必须排查单价表或漏记流量。看板失去财务信任后就没人看了。
预算管控的月度流程
- 定预算：上月成本 × 业务增长系数 × 降本目标折扣，与业务方确认后写入网关配置（租户级
max_budget）。 - 跑水位：70% / 90% 自动告警到租户负责人（软预算）；100% 触发降级或限流（硬预算，策略由租户事先选择）。
- 复盘归因：月初用看板"归因块"复盘上月异常波动，产出优化项（prompt 精简、缓存策略、模型降档）。
- 调整单价表：厂商调价后更新单价表并在变更记录中留痕，保证对账连续性。
预算管控的指标实现与熔断细节见 Token 成本与用量监控；模型与推理侧的降本手段见 推理成本优化策略 与 GPU 成本模型与计费。
从看板到行动：三个典型优化闭环
| 看板信号 | 对应动作 |
|---|---|
| 某场景单次对话成本高于同类 3 倍 | 检查该场景 prompt 是否膨胀、上下文历史是否未裁剪 |
| 缓存命中率低于 20% | prompt 前缀结构化改造，把稳定内容前置 |
| 轻量模型占比 < 10% | 推进模型降档路由（简单请求走小模型） |