API 中转站多租户隔离怎么落地：Key 级归属、集中限流与故障不扩散的边界设计

多租户隔离的真正难点不在“隔开”，而在“隔到什么粒度才既不脆弱又不昂贵”。一个中转站如果只有账号级余额，任何一次 Key 泄露都可能让陌生调用吃掉另一个团队的预算；可隔离做得过细，运维成本和链路延迟又会反噬稳定性。这个话题在 API 中转选型里的权重，往往比“支持多少模型”更能决定长期体验。

先说租户粒度。实践中至少要区分四层：账号是付费主体，子账号或项目对应团队，Key 是调用凭证，终端用户则是 App 背后的匿名访客。只做账号级隔离的系统，在多人协作场景里会出现“谁都看得见谁的调用记录”；做到 Key 级，才能把配额、审计与吊销收敛到最小可控单元。

控制面隔离是第一道边界。租户的余额、套餐、Key 归属与调用记录必须落在独立的逻辑账本里，所有写操作要幂等，避免重试导致重复扣费。快米兔 API 采用按量计费，注册即送 5 元测试金，这种“先试用后放量”的模式对账本准确性要求更高：测试金与充值余额要分账记录，消耗顺序、有效期与退款边界都得在控制面写清楚，缺项以官方说明为准。

第二道是数据面隔离。请求链路里的会话上下文、缓存、向量数据与中间结果，只要存在跨租户复用的可能，就是隐患。缓存键应带租户前缀与 Key 指纹，而不是只取 prompt 哈希；流式响应要绑定单一请求上下文，避免连接池复用造成串包；日志中的提示词与返回内容按租户隔离存放并做脱敏采样。

第三道是配额与限流。限流计数器如果只放在单机内存，多实例扩容后实际配额会被瞬间放大。更稳的做法是令牌桶集中存储，按租户加模型两个维度计数，再给每个租户一个突发池，允许短时冲高但不长期占用共享容量。这样单个租户的爬虫式调用，不至于演变成全站排队。

第四道是上游路由与故障隔离。中转站背后通常挂着多个上游通道，路由要按租户分组、按模型能力匹配，并对每个上游独立熔断。关键点是熔断计数不能全局共享：某一租户触发的上游异常若上升到全局熔断，会让所有租户一起降级。把熔断、重试与超时预算按租户维度收敛，才能做到故障不扩散。

计费隔离是最容易埋雷的部分。推荐预扣、结算、回滚三段式：请求进入时按最大可能消耗预扣，返回后按实际用量结算，异常中断则回滚差额。余额不足要有明确降级策略，是拒绝新请求还是切到更便宜的模型，决策应写在网关侧而不是客户端，否则容易出现“先调用后欠费”的超卖。

可观测性决定隔离是否可运维。租户维度的 QPS、错误率、延迟分位、Token 消耗与上游命中率应各自成面板；告警阈值按租户历史基线动态调整，而不是全站一个数。审计日志要能回答“这个 Key 在几点调了哪个模型、消耗多少、命中哪个上游”，这既是排障所需，也是账目有异议时的凭据。

几个常见坑值得单独点出。共享连接池没有做租户标记，长连接可能把 A 租户的流式响应写进 B 租户的 socket；限流与配额分别记在缓存和数据库，两边对不上，会出现“明明没超却被拒”；Key 吊销之后旧请求仍在飞行，需要配合短时宽限与幂等失效机制。

从选型角度看，隔离能力是隐性但高权重的指标。快米兔 API 走 OpenAI 兼容协议，接入时基本沿用现有 SDK 与调用习惯，多模型路由与 Key 管理收在同一套控制面里，配合按量计费与测试金，团队可以在不带预算压力的情况下，先把隔离策略压测一轮再放量。对中小团队来说，这种“先验证再扩容”的节奏更省事。

落地顺序建议是：先做 Key 级归属与账本幂等，再做缓存与日志隔离，随后上集中式限流，最后补上游熔断与租户级可观测。顺序反了，往往会先做出一套好看的面板，却在真实流量下发现钱和配额都对不上，返工成本远高于一开始就把边界划清。

多租户隔离不是一次性工程，而是随租户结构变化持续调参的过程。把边界定在 Key 级、把配额与计费收敛到控制面、把故障限制在单个租户内部，基本就覆盖了中转站八成的隔离风险，剩下的就是按业务节奏逐步加固。