大模型成本看板Token、延迟和业务价值要放一起看一、只看 Token 账单不够大模型应用上线后账单很快会变成管理问题。很多团队只统计总 token 和总费用但这只能说明花了多少钱不能说明钱花得值不值。真正有用的成本看板要把成本、延迟、质量和业务结果放在一起。我见过一个团队的月报表总调用 200 万次总费用 4500 元。单看这个数字挺便宜。但拆开一看A 功能的 50 万次调用了核心模型占总费用 70%而 A 功能的日活只有 50 人人均每天开销几十块钱。B 功能日活 500 人却只花了 15% 的费用因为它用的便宜模型加缓存。如果不拆功能看团队永远不知道哪个功能在烧钱。更糟的是A 功能因为没做成本控制月初第 15 天就用光了预算后面半个月功能直接不可用——但报表上看到的是月总费用没超高层还觉得挺好的。成本治理不能只靠月报。同样是一千次调用有的用于高价值客户的合同审查每次价值几十块钱有的用于内部同事的测试重试每次价值趋近于零。只按调用量平均摊成本会掩盖浪费。成本治理的第一步是把费用归因到租户、功能、模型、场景和请求结果。不是算公司花了多少钱而是算哪个功能为谁花了多少钱效果怎么样。二、成本归因要进入链路flowchart LR A[请求入口] -- B[策略选择 — 根据租户/功能/场景] B -- C[模型调用] C -- D[用量采集 — token 延迟 结果状态] D -- E[成本看板 — 按租户/功能/模型维度聚合] E -- F[策略调整 — 模型切换/预算设置/缓存优化] F -- A每次模型调用都要记录 model_id、prompt_tokens、completion_tokens、cache_hit、latency_ms、tenant_id、feature_key 和 trace_id。没有这些字段看板只能做财务统计无法指导工程优化。还要记录结果状态——成功、超时、被拦截、用户重试、人工接管——一次失败调用不仅浪费 token还可能带来连锁反应。成本看板还要支持到底谁在用的查询。某天账单突然涨了是某个租户新增了批量任务还是某个功能被同事在群里分享了导致使用量暴涨还是某个 bug 导致了无限重试如果不能从总费用下钻到具体请求排查成本异常的效率会非常低。归因还要做价值权重。同一个 token 在不同业务场景中的价值是不一样的。付费客户的查询 token 值钱内部测试的 token 是支出。如果看板能把 token 消耗和业务收入关联就可以算出每个功能的token 投入产出比。这个指标比单纯的每千次调用多少钱更能指导功能取舍。三、预算控制要前置type Budget struct { TenantID string FeatureKey string // 按功能区分预算 DailyTokenMax int64 CostCentsMax int64 MaxOutput int Priority int // 预算耗尽时降级优先级 } func (b Budget) CheckAndDegrade(used int64, next int64) (string, error) { if usednext b.DailyTokenMax { // 超预算返回降级策略 switch b.Priority { case 1: return switch_to_cheap_model, fmt.Errorf(daily budget exceeded, trying cheap model) case 2: return shorten_and_cache, fmt.Errorf(daily budget exceeded, shortening output) default: return , fmt.Errorf(daily budget exceeded, no fallback available) } } return , nil }预算控制不要等账单出来再做。请求进入模型前根据租户、套餐和功能计算可用预算。预算不足时可以降级模型、缩短上下文、关闭重排或者返回明确提示。预算要分层全局预算保护公司成本租户预算保护商业公平单请求预算保护异常输入。预算的另一个重要作用是止损。如果某个功能因为上线了一个长 prompt 模板导致每请求 token 暴涨一倍但功能使用量没变成本会在当周月报表上才体现。预算前置可以在当天甚至当小时就触发告警和限流避免一个优化吃掉一个月的预算。四、优化要看质量损失降成本不能只看单次调用价格。换便宜模型后如果用户重试率上升、人工介入增加整体成本未必降低。看板应同时展示每次成功成本、p95 延迟、引用命中率和用户重试率。缓存也要纳入成本看板。语义缓存节省了多少 token是否影响答案新鲜度都要可见。成本告警要区分突增和慢涨——突增来自循环重试或批量任务误触发慢涨来自用户增长或提示词膨胀。看板还要提供下钻路径看到具体功能、模型和错误类型。常见优化点包括缩短系统提示、减少无效历史、调整 top_k、降低重排频次。成本优化的最终目标是花最少的钱达到业务可接受的质量。如果一味省钱导致用户不满意那不是优化是自我淘汰。关键门槛是质量不降的前提下省了多少而不是花了多少钱。成本看板还要做同比和环比。功能上线一个月后同功能的每单成本和首批用户的每单成本是否在优化方向如果每单成本持续上升而业务指标没变化说明 prompt 膨胀或模型策略在退化。没有趋势数据就看不出退化。五、总结大模型成本看板要把 token、延迟、质量和业务结果放在同一张图里。预算控制前置成本归因到租户和功能优化时同步观察质量损失。省钱不是少调用模型这么简单。真正有效的成本治理是让每一次调用都能解释它的价值——或者让它不再发生。