团队预算管控：从「月底才发现超支」到实时限额

典型症状

「API 这个月花了多少？」

• 「不知道，等月底看账单。」
• 「某个同事的 Key 用超了，其他人的活全停了。」
• 「上个月账单突然翻了三倍，查不出是哪来的。」

这三个症状的根因是同一个：没有把用量拆到「谁、做什么」这一层。

而所有管控手段——限额、告警、优化——都建立在这个拆分之上。没有拆分，后面都做不了。

第一步：Key 拆分

一个用途一个 Key。 维度按你的组织结构选，常见两种：

按人拆：适合「每个人独立工作」的团队。

key-alice / key-bob / key-carol / key-ci     ← CI 单独一个

按项目拆：适合「多人协作同一个产品」的团队。

key-prod-api / key-staging / key-batch-job / key-internal-tool

两种都做的情形：按项目拆一级，再在项目内按人拆二级（如果站方支持二级 Key）。

为什么 CI / 定时任务必须单独一个 Key：它们的用量模式与人工调用完全不同（可能一次跑几千个请求）。混在同一个 Key 里，会让你的用量曲线无法解读。

第二步：明确计量口径

在动手做统计前，先回答三个问题：

1. 按什么计量？ 请求次数、token 数、还是金额？

→ 建议以金额为准，因为这才是你要管的东西。token 数只是中间量。

1. 输入与输出是否分开统计？

→ 必须分开。输出的单价通常是输入的 3–5 倍。只统计总 token 数会让你误判成本结构。

1. 缓存命中的部分是否单独计？

→ 如果开启缓存，命中部分的成本可能只有 10%。不分开统计的话，你会高估成本。

落库的字段建议：时间 / key 标识 / 用途 / 模型 / 输入 token / 输出 token / 缓存读 token / 折算金额。

有了这七个字段，任何维度的分析都能做出来。

第三步：告警与限额

告警（软限制）

三个阈值就够：

第二条最有价值：70% 时通知，你有时间干预；100% 时才通知，已经晚了。

硬限额

如果站方支持按 Key 设置额度上限，一定要设。它是唯一能真正兜住失控的手段。

限额设置原则：设在「月度预期用量 × 1.5」。太紧会误伤正常业务，太松失去意义。

如果站方不支持硬限额，你有两个选择：

1. 在你自己的代码层加计数与拦截（所有请求走一个统一入口，累计计数超限即拒绝）；
2. 换一家支持限额的站。

第二种更省事，但如果你的业务已经在用，第一种是唯一解。第 1 项的实现在自建网关的场景下最容易做（见本站《自建中转的隐性成本》）。

第四步：纳入例行回顾

管控的目的不是限制使用，是让投入产出可见。所以需要一次定期的回顾，建议按周（不是按月——月度太滞后）。

每周看三个数：

1. 总量与上周的对比（±20% 以内算正常波动）；
2. Top 3 消耗者（如果某个 Key 突然进榜，查一下是什么）；
3. 单位产出成本：如果某个业务有产出指标（比如生成了多少条内容、处理了多少文档），算一下每单位的成本。

第三项是最有价值的一项，因为它能回答一个业务问题：这笔钱花得值不值？ 前两项只回答「花了多少」。

最常见的三个失控场景

一、循环调用

Agent 或自动重试逻辑写错，导致同一个请求被反复发送。

特征：用量在几分钟内出现一个陡峭的尖峰，且集中在同一个 Key。

预防：所有自动重试都要有最大次数 + 指数退避。默认的「失败就重试」是最常见的失控源头。

二、上下文累积

Agent 每轮都把完整历史发一遍。轮数一多，输入 token 呈平方级增长。

特征：单个请求的输入 token 持续增长。

预防：对历史做滑动窗口裁剪，或用缓存（见本站缓存计费一篇）。

三、调试期的全量重跑

开发阶段为了验证，把整个批处理重新跑一遍。如果测试环境用的是生产 Key，就会直接计费。

预防：测试环境用独立 Key，并给它设一个小额度。用完了就说明测试该收敛了。

一个低成本起步方案

如果你现在什么都没有，按顺序做这三件：

1. 拆 Key（半小时）—— 立刻让用量可分辨；
2. 每天记录一次用量（写个脚本，5 分钟能跑的）—— 三天后你就有基线，能看出异常；
3. 设一个「超过近 7 日均值 2 倍就通知」的告警 —— 这一条能拦住绝大部分失控。

这三件事加起来不到一天的工作量，但能解决「月底才发现」这个根本问题。剩下的优化可以后面慢慢做。

顺序很重要：先可见，再优化。看不见的时候做优化，等于闭着眼睛调参数。