一个客户没有增加使用量，响应却突然变慢，原因可能来自另一个客户正在批量处理文档。企业 AI 从单团队试点扩展为共享服务后，采购与运营需要回答的不再只是总吞吐量，而是谁在什么条件下仍能获得可用服务。本文讨论资源治理，不把权限隔离或独立账号等同于性能隔离。
从总容量，转向每个租户能得到什么
企业大模型服务容量验收已经强调任务组合与交付期限。多租户场景还要增加一个维度：在其他租户负载变化时，当前租户的承诺是否仍然成立。租户可以是外部客户，也可以是内部部门；它应是平台明确识别、授权并计量的服务主体，而非用户随意填写的字符串。
Microsoft 的架构文档把共享资源中一个租户影响另一个租户性能的情况称为 noisy neighbor，并指出多个正常租户同时达到高峰也会产生争用。[1] 因此不能只把问题归为恶意滥用。月底报表、集中上传或模型重试都可能是合法工作，却超过共享系统当时可交付的容量。
这带来一项经营取舍：共享资源有利于提高利用率，独占资源有利于缩小相互影响范围，但会增加闲置、部署和维护成本。本文建议先明确需要保护的任务，再决定隔离程度，不把每租户一套完整集群作为默认方案，也不把共享部署的低成本当作无条件承诺。
请求次数、在途并发与计算消耗不能互相替代
每分钟十次短问答与十次长文档分析，入口次数一样，实际负载可能很不同。一个业务任务还可能触发多次模型调用、检索和数据库查询。因此请求速率适合限制进入节奏，却不能单独约束已经进入系统的长任务，也不能准确表达全部计算成本。
建议按可观察的瓶颈组合控制：入口请求速率限制突发进入；在途任务上限限制占用者数量；输入长度、输出上限与工具调用预算限制单任务规模；共享数据库或解析器再设置对应资源边界。输出 token 数在完成前并不确定，预留额度与实际结算应分开；估算偏差要可核对，不能靠模型自行声明费用。
AWS 的多租户智能体指导建议在共享计算、内存、模型与工具等接触点设置保护，而不只在最外层入口限流。[2] 应把经过认证的租户上下文传到这些执行点，并关联父任务及子调用。用户新增 API key 或任务拆分，不应自然获得一份全新的租户预算。
多个网关各自持有本地计数时，配置上的租户上限可能被重复放大。应明确额度的作用域、共享计量或分片分配规则，以及计量服务不可用时是拒绝、排队还是使用有界本地余量。不存在适用于所有业务的默认策略；关键在于不会悄悄退化为无限放行。
配额是上限，不是保底容量
以下为构造算例，全部请求假设为等价任务。某共享服务在约定质量与延迟目标下可持续交付每分钟 100 次，十个租户各被允许每分钟最多 20 次。单个租户没有超额，不代表系统可以同时兑现 200 次需求；如果十个租户一起达到上限，仍然需要拒绝、延后或增加真实容量。
如果商务承诺每租户至少每分钟 8 次，则十个租户的基础承诺合计为 80 次，余下 20 次可以考虑作为弹性空间。但这个算术只是规划起点，不证明调度器确实保留了容量，也没有涵盖任务长度变化、共享依赖和实例故障。故障后只剩每分钟 60 次时，原承诺仍会失效，除非另有资源或事先约定降级。
合同与界面应区分最大使用上限、拥塞时最低服务、允许排队时间和超额处理。额度尚未用完，不必然意味着立即可运行；付费更高的优先级，也不应让普通租户无限等待。可以借用闲置份额提高利用率，但借用工作如何让出资源、已经运行的长任务是否可中断，都需要明确。
Kubernetes 的 ResourceQuota 对命名空间中的资源总量和对象数量施加限制；文档同时说明，配额变更不会影响已创建资源，配额总量超过集群容量时仍可能争用。[3] 它不能自动识别同一服务进程里的业务租户，更不能仅凭命名空间额度证明每个客户的模型响应时延。基础设施上限与应用服务承诺需要分别验收。
用三档方案比较隔离成本与收益
第一档是共享执行资源，按租户设置有界队列、并发与调度份额。适合负载较小、任务差异可控且允许短时等待的服务。优点是资源复用充分；局限是共享缓存、推理运行时和下游依赖仍可能产生干扰，入口公平并不保证完成时间公平。
第二档是按工作负载或服务等级划分资源池，例如交互问答与可延后批处理分开，超长输入进入独立池。它针对已经观察到的干扰源，往往比完全独占更容易控制成本。但跨池共享的数据库、模型供应商账户或存储仍需单独保护，否则只是把争用移到下一层。
第三档是为确有必要的租户提供专用执行资源或更完整的独立部署。需要把备用容量、升级窗口、监控和维护成本纳入报价。专用推理实例若仍共用受限外部接口，也不是端到端独占。是否值得投入，应比较受保护业务的价值与完整增量成本，不能由某一次峰值投诉直接推导。
服务等级的选择还要考虑可退路：非紧急工作能否延后，复杂分析能否明确转为异步，关键任务是否有受控替代路径。改变模型、裁剪资料或降低输出质量不应成为隐藏的限流措施；如果采用这些降级方式，必须单独验证结果质量并说明服务条件。
验收要让一个租户加压，再观察另一个租户
建议先测租户 B 的基线：固定代表性任务、到达节奏、模型与依赖版本，记录按期成功比例、排队时间及失败类型。随后保持 B 不变，只增加租户 A 的短请求、长输入、批处理和工具调用。比较的是 B 在干扰下的变化，而非系统总吞吐是否仍很高。这是本文提出的验收方法，不是已完成的生产试验。
测试还应覆盖多个租户同步突发、长任务先占满执行槽、某个共享工具变慢，以及部分实例退出。分别记录受理、排队、开始、完成、拒绝与取消，按租户统计。只看已受理请求的延迟会漏掉被拒绝的用户；只看全局平均值会掩盖小租户受损。
为每类业务预先约定可接受退化、最长等待和拒绝行为，并控制测试窗口与样本量。观察到干扰后，沿入口队列、推理服务、数据库和外部接口逐层定位，再调整对应控制点。不能把所有超时都归因于邻居负载；版本变更、缓存冷热和采集遗漏也应排查。
验收包应包含租户与任务范围、实际负载轨迹、配额作用域、调度规则、故障条件和原始结果。商业承诺来自这些证据，而不是配置页上的一个限流数字。若在可承受成本下仍不能保护关键任务，应缩小共享范围、调整交付期限或选择更强隔离；先把边界说清，才能扩大服务而不透支交付能力。