AI 平台租户配额隔离：同时约束请求、token、并发与 GPU 时间

在普通 API 中，每个请求成本差异有限，按租户限制每秒请求数通常够用。AI 推理不是这样：一个请求可能只生成十几个 token，也可能携带超长上下文、持续流式输出数分钟并触发多次工具调用。若平台只限制 QPS，大客户的一小批长请求就能占满 GPU 解码槽位，其他租户即使没有超额也会排队。这就是典型的噪声邻居问题。

租户隔离需要从身份、记账、排队、执行到观测形成闭环。租户 ID 必须由可信认证上下文得出，不能接受请求体自报；项目、环境和用户可以作为次级维度，但最终都归属一个可计费、可审计的根租户。内部服务代用户调用时要传播原始租户和委托身份，不能全部落在一个“平台服务账号”下绕过限制。

配额是一组资源向量

至少同时管理五类额度：请求速率防止控制面被打爆，输入与输出 token 预算约束推理成本，并发请求或活跃序列保护实时槽位，排队长度限制内存和等待时间，GPU 秒或任务总成本控制长期消耗。对于 Agent，还需限制单次 run 的模型调用次数、工具轮数和累计 token，避免循环在每个局部限额内却耗尽全局资源。

配额分为长期保障与短期突发。令牌桶允许可信租户在平时积累少量 burst，但桶容量必须有限，不能把整月未用额度在一分钟内释放到共享集群。并发额度通常不应积累。不同模型资源成本不同，可使用经过基准测试的“推理单位”计价，但对外仍展示用户可理解的 token、并发和金额，避免黑盒扣费。

LLM 限流与配额 适合定义产品层额度，API 限流策略 提供令牌桶等算法基础。平台层还必须把额度映射到真实队列与 GPU 池，否则网关返回“允许”后，调度器仍可能让某租户无限占用资源。

预留、结算和补偿必须原子化

流式生成开始前无法知道准确输出 token。可先根据输入 token 与请求的最大输出上限预留额度；生成过程中周期结算实际使用，结束时释放未使用部分。若客户端取消，停止信号必须传到推理后端，并按已经消耗的资源记账。仅在响应完成时扣费会让断线和超时请求免费消耗 GPU。

分布式网关需要共享且一致的配额状态。检查与扣减应是原子操作，并携带全局唯一请求 ID。重试同一个 ID 返回原来的预留结果，不能重复扣减；超时状态进入待对账而不是默认撤销。记账服务不可用时的策略按风险区分：免费沙箱可拒绝新请求，关键付费租户可使用小额本地应急额度，但绝不能无限 fail-open。

reserve(tenant, requestId, inputTokens, maxOutputTokens, modelClass)
  -> reservationId, admittedUnits, expiresAt
settle(reservationId, actualInput, actualOutput, gpuMillis)
cancel(reservationId, consumedSoFar)

预留记录应有 TTL，但后台清理前要查询执行状态，防止长请求仍运行时额度被错误释放。每日对账比较网关预留、模型服务实际 token、GPU 计量与账单事件；差异超过阈值时冻结自动结算并告警，而不是悄悄修改用户余额。

公平排队不能只靠先进先出

全局 FIFO 会让一个租户提交的大批任务挡住所有人。更合理的是按租户分队列，再使用加权公平调度或 deficit round robin，从每个活跃租户轮流取任务。权重代表购买的保障份额，而不是无限优先级；单租户仍受并发与总预算限制。交互、批处理和评估任务要分优先级池，批任务可以利用闲置容量，但在交互流量恢复时让出资源。

优先级与抢占需谨慎。已经开始的长生成被抢占会浪费 GPU 时间并破坏用户体验，优先在排队阶段调度，或使用支持保存状态的执行方式。高优先级只能来自服务端策略，不能让客户端传一个 header 就升级。Kubernetes ResourceQuota 可以隔离命名空间层面的 CPU、内存和对象数量，但无法单独理解每个推理请求的 token 与 KV Cache，因此应用配额和集群资源配额必须同时存在。

隔离所有共享状态

配额并不能代替数据隔离。缓存键、批处理聚合、观测标签、日志采样、模型适配器和对象存储路径都要包含经过验证的租户范围。MCP 多租户隔离 中的上下文传播原则同样适用于推理平台：后端每一跳都接收可信租户上下文，缺失时拒绝，而不是回落到公共租户。

尤其要检查语义缓存和动态批处理。不同租户请求可以在 GPU 层共同批处理，但响应映射、取消信号和指标必须按请求隔离；含私有数据的缓存不能跨租户命中。平台指标中租户标签应使用稳定内部 ID 或哈希，并控制标签基数，原始用户标识不进入公共监控系统。

在容量紧张时按承诺降级

集群饱和时先暂停没有保障的批任务，再限制 burst，最后按租户保障份额公平排队。返回 429 或明确的资源耗尽状态时，附带合理的重试时间和请求 ID；不要让 SDK 立即无抖动重试形成第二波流量。对于关键任务，可以切换到经过批准的备用池，但仍沿用同一份租户配额，不能通过换模型重置额度。

仪表盘同时展示每租户准入、拒绝、排队时间、活跃序列、输入输出 token、GPU 秒、预留与结算差异以及共享池 SLO。平台运营者需要查看聚合热点，租户只能看到自己的数据。容量和成本归属可结合 云成本优化，让保障份额与真实预留资源匹配。

验收时模拟单租户突发、超长输出、客户端取消、网关重试、记账服务中断、队列 worker 重启和共享池降容。确认其他租户延迟仍在目标内、同一请求不重复扣减、失效预留最终收敛、批任务确实让出资源，并且任何路径都不能伪造租户。真正的租户隔离不是给 API 加一个限流中间件，而是让身份、额度、调度、状态和账本在故障中仍保持同一个边界。

延伸阅读

• LLM 限流与配额设计
• API 限流策略
• MCP 多租户隔离
• 云成本优化