怎么给API密钥设消费上限，才能既卡住失控调用又不影响正常业务？

给API密钥设消费上限的核心做法是三层治理：按密钥设独立预算、在调用链路上做实时拦截、按阈值分级预警，三者缺一层都会出现“钱花了才知道”的情况。它适用于自建网关或平台支持密钥级配额、且计费方式为按量付费的账号；如果账户是包年包月、或所有业务共用一个密钥，密钥级上限就无法生效，只能退回到账户级预算。 密钥级拦截解决的是“谁能花、能花多少”的权限问题。传统做法是把预算设在账户维度，一个人超支全公司停摆，团队之间互相挤占；把上限下沉到每个密钥后，每个密钥就是一条独立的成本边界，某个爬虫脚本或测试环境跑飞了，只冻结它自己，不影响其他业务。实作上要在密钥属性里挂三个字段：额度周期（日/周/月）、额度数值、超限动作（拒绝、降级到低价模型、只读）。 用量预算要按“业务单元”而不是“开发者个人”来切。同一个开发者可能同时用密钥跑线上推荐和线下离线评测，两者的成本容忍度完全不同；按个人设上限会导致线上被离线任务拖爆。更稳的做法是让一个业务线对应一个或一组密钥，预算按业务线的历史峰值加 30% 到 50% 预留空间设定，并每月复核一次。 实时扣减必须在请求入口完成，不能等账单出来再对账。按量计费的模型API通常是按输入输出 token 计费，如果只在每小时同步一次用量，突发的大批量调用会在同步间隔内把钱烧穿。可行的做法是在网关层维护每个密钥的已用额度计数，每次请求前先检查余额，请求返回后按实际 token 数回写；对无法预估 token 的流式请求，则按最大上下文长度做预扣，结束后多退少补。 超限动作要分级，不要只有“全停”一种。第一级是软限：达到预算的 80% 时只告警不拦截，给业务留出调整窗口；第二级是降级：达到 100% 时把请求路由到更便宜或更小的模型，保住可用性；第三级才是硬停：连续超限或触发异常模式时直接拒绝。很多事故不是超支本身，而是超支瞬间业务全挂，分级能把损失控制在成本层面。 成本预警要按层级推给不同的人，而不是所有人都收全量告警。运维关心的是“有没有密钥在异常速率下调用”，财务关心的是“本月总额会不会突破预算”，业务负责人关心的是“我的那条线还剩多少额度”。建议设三档阈值：50% 提醒、80% 预警、100% 处置，分别推送不同的接收人，并在告警里带上密钥标识、当前用量、预估耗尽时间和建议动作。 预算耗尽的预估时间比绝对用量更有行动价值。只告诉团队“已经用了 600 元”没有意义，告诉他们“按当前速率还有 4 小时耗尽”才能触发限流或扩容决策。实作上可以用滑动窗口计算最近一小时的平均消耗速率，再用剩余额度除以速率得到预估耗尽时间；当这个时间低于 24 小时就提前预警，高于 24 小时则只记录不打扰。 异常检测要和预算分开做，预算是上限，异常检测是发现“还没到上限但行为不对劲”。典型异常包括：单一密钥在短时间内并发数激增、调用集中在深夜、输入长度远高于历史均值、失败重试次数异常升高。这些模式往往意味着密钥泄露或被脚本盗用，仅靠预算告警可能要等到烧掉大半额度才会发现。把并发数、请求频率、平均输入长度也纳入监控，能把发现时间从小时级压到分钟级。 密钥的配额要跟密钥的生命周期绑定，避免人走额度还在。人员离职、项目下线、临时测试结束后，对应密钥如果没被回收，就成了一条无人看管的成本通道。建议给每个密钥设到期时间，临时用途的密钥最长 7 天，到期自动失效；长期密钥每季度强制轮换一次，轮换时顺带复核预算是否还合理。 不要把上限设成固定值，要留出申请和调整的通道。业务增长、模型换代、促销活动都会让合理用量发生变化，如果上调预算要经过层层审批、耗时几天，团队就会绕过管控去申请新密钥，反而让治理失效。更现实的做法是设一个自动上调区间，比如预算的 120% 以内可以自助调整，超出部分才需要审批，同时记录每次调整的原因供事后审计。 对多模型、多供应商的账号，预算要按供应商分别核算，不能只做一个总池子。不同供应商的计费单位、免费额度、阶梯价格都不一样，混在一起算会导致某一家已经严重超支、另一家还有大量结余却看不出来。按供应商加密钥两个维度做交叉报表，才能看清成本到底花在哪里。 最后要接受一个边界：密钥级上限能控制成本，但控制不了业务价值。它只能保证“花不超”，不能保证“花得值”。因此预算治理要和用量分析配套，定期回看哪些密钥的调用真正产生了业务结果，把预算从低效用途转移到高效用途，否则就只是把浪费变得更规范而已。 落地顺序建议从最痛的一条线开始：先给调用量最大或最不可控的那个密钥加上日预算和硬拦截，跑一周看误伤情况，再逐步铺到其他密钥。一次性给所有密钥设上限，容易出现正常业务被卡住、团队集体要求放宽的局面，最后管控形同虚设。分阶段推进，留出观察和调参的时间，治理机制才站得住。