隔离要做在事前，扩容救不回被挤垮的邻居。
一个用户拖垮所有人
多租户系统里最常见的线上事故：某个租户写了脚本猛刷接口，把模型配额、连接数或带宽吃光，
所有租户一起变慢或失败。这类事故靠"事后扩容"救不回来，必须事前隔离。
四层防护
一、配额（Quota）
按租户限定"一段时间内可用多少"（调用次数、token 数、并发数、存储量）。
要点：
· 配额维度要匹配成本来源（对话类按 token，批量任务按条数或并发）；
· 超额行为要明确：拒绝、降级到小模型、还是排队等；
· 配额用量对租户可见（避免"莫名其妙失败"）。
二、限流（Rate limit）
控制速率（每秒/每分钟），与配额互补：配额防"总量超标"，限流防"瞬时打爆"。
· 用令牌桶/漏桶；给突发留一点余量（例如允许 2 倍瞬时）；
· 限流键要分层：租户级 + 全局级（全局兜底，防止"每个租户都不超但总量爆"）；
· 被限流时返回明确状态与建议等待时间。
三、并发隔离
· 每个租户的并发请求数设上限；
· 关键路径与批量任务分池（批量任务不能占满交互请求的池子）；
· 队列要有优先级：交互优先、批量让路。
四、降级与熔断
· 上游变慢时，先降级（小模型/缓存/规则兜底），再考虑拒绝；
· 熔断要有恢复探测（半开状态），不要"断了就一直断"；
· 每个降级动作都要记录，便于事后归因。
观测什么
· 按租户的用量分布（找出 Top 5 是不是异常增长）；
· 拒绝率/限流触发率（被限流的租户是否知道原因）；
· 排队时长的 P95（排队比拒绝更容易被忽略）；
· 全局与单租户的成本曲线（成本突然抬升往往是脚本或死循环）。
一个可执行的上线清单
1. 列出每个接口的成本来源，定配额与限流值（宁可先紧，后放开）；
2. 加租户级 + 全局级限流；
3. 批量与交互分池，队列设优先级；
4. 降级链写清楚，熔断加半开探测；
5. 把"按租户用量/拒绝率/排队时长"做进看板，并做一次单租户压测验隔离是否真的生效。
本文由云枢 AI导航整理，内容以官方来源为准。
相关文章
顺序阅读
← 上一篇：把长任务做成可恢复：断点、幂等与进度可见
下一篇：检索结果怎么排序：相似度不是唯一信号 →
第 21 / 171 篇