当前位置：首页 > news >正文

大模型成本看板：Token、延迟和业务价值要放一起看

news 2026/7/5 9:51:36

大模型成本看板：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 used+next > 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 膨胀或模型策略在退化。没有趋势数据，就看不出退化。