半年后必须回答的问题

在企业内部推动 AI 应用时，最棘手的往往不是把产品做出来，而是半年后说明：这套系统究竟创造了多少收益，又是否值得继续投入。

技术团队容易盯着「跑通了、好用」，决策层关注的却是投入产出，包括 API 费用花了多少、覆盖多少人、替代多少人工工时。连接这两套语言的，正是平台侧看似普通的用量统计、调用日志和多密钥归因。它们既是运维工具，也是让提效从「感觉不错」变为「能写进汇报」的数据来源。本文以jiekou.vip为例深入探讨。

一、钱花到哪里：用量统计

用量统计呈现的是最基础也最关键的事实，包括累计消耗、按时间变化的调用趋势，以及不同模型的用量分布，而这些数字各有用途。

通过调用趋势判断采纳度。内部工具上线后，调用量持续增长，表明确实有人使用；如果一周后回落到个位数，问题不在成本，而在于产品没有解决真实需求。

模型用量分布决定可优化空间。企业最常见的浪费，是「所有任务都走最贵的模型」。分类、抽取和格式化等任务，小模型已经完全够用。统计会直接显示哪个模型占据成本大头，这通常是降本最快见效的切入点。

把累计消耗与人工成本对比，才能得出提效结论。以合同摘要为例，月 API 支出只相当于一个人几天的工时，处理量原本却需要两个人忙完整月，这样就能把账算清楚。

二、为何这么贵：调用日志

每次请求的时间、模型、状态和消耗都会被日志记录，使排查具备依据。不过从提效角度看，日志还有一种常被低估的用途：它是识别无效消耗的唯一途径。

生产环境中的几种隐性浪费，只有查看日志才能发现：

• 重试风暴。上游偶发超时会触发客户端重试；策略过于激进时，一次失败可能扩展成三四次计费调用。日志中同一时间窗口出现大量相同请求，就是明显信号。
• 超长上下文。检索阶段配置了过多召回条数，导致每次请求塞入大量无关片段，输入 token 随之徒增。发现单次消耗明显超过设计预期，问题通常就在这里。
• 失败后仍然计费的调用。部分错误发生时，模型已经开始生成，因此仍会计费。这些费用属于纯损耗，只有先算出占比，才能判断是否值得投入修复。

建议每月例行检查这三项。多数团队完成第一轮后，就能在不影响任何功能的前提下削减部分开销，因为被砍掉的都是原本没有创造价值的调用。

三、钱由谁花：多密钥归因

前两部分分别回答「多少」与「为什么」，这一部分解决「归给谁」。企业尤其需要把成本落到具体业务线，否则某笔支出无人负责，任何优化措施都难以推进。

具体做法是为不同项目、环境和团队分配独立密钥：

• 项目隔离：每个项目使用一把，用量和成本独立统计，责任归属明确。
• 环境区分：测试与生产分别使用，防止压测流量混入生产账单。几乎每个团队都会踩一次这个坑，因为一晚压测产生的账单可能超过正常一周。
• 安全收敛：某把密钥泄露或对应项目下线时，可单独吊销而不影响其他项目。
• 额度分配：试验性项目使用单独密钥并设置额度上限，即使实验失控，也不会影响主业务。

关键在于尽早实施：接入第一天就按项目拆分，成本几乎为零；等十几个服务共用一把密钥后再拆，则要逐个修改配置、重新发布并协调停机窗口。

三项能力组成的闭环

单独看都很普通，组合起来才形成完整链路：

多密钥先按项目拆分流量 → 用量统计据此展示分项成本 → 出现异常时由日志提供逐条排查依据 → 完成优化后再回到统计验证效果。

有了这个闭环，「AI 提效」就不再只是口号，而成为能够逐月追踪的指标：各业务线支出多少，其中有多少无效消耗，优化后又下降几个百分点。相比模型选型争论，这些数字更能推动企业持续投入 AI。

小结

企业评估 AI 提效，需要三层数据共同支撑：用量统计呈现成本总量与结构，调用日志揭示无效消耗，多密钥管理则把成本归到业务线。模型能力决定 AI 可以做什么，可观测性决定它能在企业中持续多久。