多租户的隔离是怎么做的？互不干扰

用 AI 智能体对外提供服务时，成千上万的请求会同时涌向同一个推理集群，多租户的隔离就是保证这些请求互不踩踏的机制。它做得好不好，直接决定你敢不敢把业务放到平台上。

可以把它想成一栋写字楼：每家公司共用同一栋楼的水电和电梯，但办公室有独立的门锁和电表。这个类比失效之处在于，办公室的墙是固定的，推理系统里的租户边界更多是逻辑上的，靠标签、队列和配额实时划界，极端高峰时彼此仍可能有轻微影响。带走一个判断：隔离不是砌墙，而是给每条请求发一张通行证。

隔离的三个层次：从请求到显存

第一层是请求隔离：每个请求都带着租户标签，排队、计数、限流都按标签分开算，谁也看不见谁的等待队列。

第二层是数据隔离：对话历史、上传的资料、缓存的提示词都按租户分账本，A 租户的上下文不会被 B 租户读到，上下文里引用来源的挂接方式同样按会话隔离，见上下文里的引用标记是怎么加的？来源标注。第三层是资源隔离：显存和算力按配额切分，防止某一家把整块显卡占满。三层各管一段，缺一层都会出乱子。三层也是层层递进的：请求隔离决定谁先被处理，数据隔离决定谁能看到什么，资源隔离决定谁最多能用多少。设计时通常自下而上补齐，资源层最直观，数据层最关键。评估一个平台时，三层说明是否清楚，本身就是成熟度的信号。

三层各管一段，逐层摊开是这样。

一条请求的租户标签是怎么走的

请求从网关进来时被贴上标签，之后每经过一个环节——鉴权、限流、缓存查找、排队、计算——标签都跟着走。鉴权环节确认身份，限流环节按标签查配额，缓存环节按标签隔离前缀条目，思考型模型的预算也按租户单独计量，见思考预算是怎么在推理时执行的？，最后用量记录同样按标签归档，供后面对账。标签一旦贴错，轻则串了配额，重则串了数据，所以网关层的校验做得最严。

隔离做不好会出什么乱子

常见的乱子有两种。一种是速度上的：某租户突发大流量，把共享队列塞满，其他租户的请求跟着变慢，这要靠每租户的独立配额来兜住；另一种是内容上的：前缀缓存若不按租户区分，A 的系统提示词可能被 B 复用，既浪费算力也可能泄露信息，缓存归属的细节见提示缓存的失效是怎么发生的？关键步骤一次讲清。讯飞星火、智谱清言这类多租户产品在文档里都会强调提示词与数据的租户归属，道理就在这里。

普通使用者能感知到隔离吗

大多数时候感知不到，隔离做得越好越隐形。能间接观察到的迹象有两处：一是限流提示按你的账户单独计算，不随别人用量波动；二是用量明细只包含自己的记录。当服务偶尔出现整体变慢，那是资源共享层面的正常波动，与隔离无关。输出环节的顺序保障是另一套机制，见流式输出的顺序是怎么保证的？分片组装。

租户隔离自查清单：

• 调用时是否使用了独立的密钥或项目标识
• 限流计数是否只统计自己的请求
• 上传的资料是否只能被自己的会话引用

三问都答得上，说明隔离按预期工作。

关于多租户的隔离，问得最多的三个

• 共用一个模型会互相看到对话吗？：不会。对话历史按租户分账本存储，计算过程也不携带其他租户的内容。
• 别人用量暴涨会影响我吗？：配额独立时影响很小，极端高峰可能在共享资源层面带来轻微波动。
• 一个账号算一个租户吗？：多数平台按项目或应用划分，粒度比账号更细，方便分摊配额。

隔离的价值在于让人敢把业务放上来，边界清楚，合作才没有顾虑。