为 AI 应用设计一套用量与配额系统

多租户的 AI 应用，定价和配额是绕不开的两道坎。定价决定你能不能活，配额决定你的用户会不会把你用垮。这两件事要在同一个系统里想。

按 Key 隔离，而不是按用户

多租户场景下，租户维度靠 API Key 来承载最自然：一个租户一把 Key，用量、限流、并发都以 Key 为单位计算。

包月 Key 通常有个「首次调用起生效」的约定。

这在实现上要注意：未激活的 Key 在被调用时才开始计时，而不是从下单那天开始——否则用户买了却不用的那段时间会被白白消耗掉。

额度、并发、有效期是三个独立旋钮

套餐里通常至少要能独立调整这三样。一个「每天 10 美元、并发 5」和一个「每天 50 美元、并发 1」是完全不同的产品，适合完全不同的场景。

很多套餐只标了「每日额度」，但对 AI 业务来说并发数往往比额度更早成为瓶颈。

因为一个请求可能跑几十秒，几十个并发请求同时在跑，额度还没用完，服务就被并发上限卡住了。

支付与发放在同一个事务里

订单结算、额度增加、Key 发放必须原子完成，并且要有幂等约束。重复回调、回调与主动查询并发、迟到通知、目标 Key 失效——这四种情况都得覆盖。

一个常见的坑是：运营调整了套餐价格，结果已经创建但未支付的订单也跟着变了。

兑换失败通常是「码不存在 / 已使用 / 过期」；游客购卡失败可能是「支付未确认 / 凭证过期 / 目标 Key 已停用」。

让租户自己看用量

给每个租户一个只读查用量入口，用低敏感度的查询凭证而不是完整 Key。既降低风险，又减少客服工作量。

健康探测是要真实发请求的，如果这些请求记在某个 Key 名下，管理员看到的用量就会莫名其妙地偏高。

实操：按 Key 分组隔离资源的思路在配置侧是什么样。

查询凭证就是为这个场景设计的：让用户自己看用量，而不必把完整 Key 交给前端。

# 分组决定了一个 Key 能看到哪些渠道。
# 三种状态的语义完全不同：

#   未绑定分组  →  所有「启用 + 公开」分组里的渠道
#   绑定公开分组 →  仅该组渠道
#   绑定专属分组 →  仅该组渠道（组停用/为空 → 直接拒绝，不回退）

# 配置专属渠道的顺序有讲究：
#   1. 新建分组，类型设为「专属分组」，加入目标渠道
#   2. 把这些渠道从所有公开分组里移除
#      （只要还挂在任何公开分组，未绑定的 Key 就仍能用它）
#   3. 创建 Key 时选择该分组并保存
#   4. 之后要恢复，解除 Key 绑定即可回到公开池

几个容易踩的坑

• 把「今日额度」「并发上限」「账户余额」当成同一个东西。
• 日/周/月窗口用的时区没说清楚，用户看到的数字和自己的记录对不上。
• 没有 Key 级限流，一个跑飞的脚本把共享额度吃完。
• 结算重试没有幂等约束，同一笔用量被记了两次。

小结

技术上的事大多不复杂，难的是把每个异常分支都想清楚。把这份清单存下来，下次排障会快不少。

上面提到的能力基本都来自 https://aiminis.info/ 这个自建的 API 网关，支持 OpenAI 与 Anthropic 双协议接入，还有公开的模型健康看板 https://aiminis.info/model-health 可以先看看状态。