大模型应用多租户隔离：别让一个客户吃光整条推理链路

企业级大模型应用很快会遇到多租户问题。不同客户共享推理网关、向量库、对象存储和任务队列。如果没有隔离，一个大客户批量导入文档，就可能让其他客户的问答延迟飙升。多租户隔离不是 SaaS 后期才做的高级功能，而是后端底座的基本设计。

资源共享可以提高利用率，但没有边界的共享就是互相伤害。

一、隔离维度要分层

flowchart TD
  A[Tenant Request] --> B[API Rate Limit]
  B --> C[Queue Partition]
  C --> D[Model Quota]
  C --> E[Vector Store Namespace]
  E --> F[Audit And Billing]

多租户隔离至少包括接口限流、任务队列、模型配额、数据命名空间、审计和计费。只在 API 层限流是不够的。

二、队列要按租户或等级隔离

如果所有任务进同一个队列，大客户任务会挤占小客户任务。可以按租户、套餐等级或任务类型拆队列。

queues:
  premium_interactive:
    concurrency: 20
  standard_interactive:
    concurrency: 10
  batch_import:
    concurrency: 5

交互请求和批量导入尤其要分开。用户等待问答结果时，不应该被后台导入任务拖慢。

三、数据隔离不能只靠前端参数

向量库、对象存储、数据库都要带 tenant_id，并在服务端强制过滤。

SELECT *
FROM documents
WHERE tenant_id = ?
  AND doc_id = ?;

不要相信前端传来的租户信息。租户上下文应该来自认证后的服务端会话或 token。

四、配额要能解释

客户被限流时，要告诉他是 QPS、并发、Token、存储还是批任务配额触发。

{
  "error": "quota_exceeded",
  "quota": "monthly_model_tokens",
  "reset_at": "2026-08-01T00:00:00Z"
}

不透明的限流会变成客服压力。配额是产品能力，也是后端契约。

还要给内部运营留观察面板。多租户系统出问题时，需要快速知道是哪个租户、哪个功能、哪类任务占用了资源。

SELECT tenant_id, feature, SUM(tokens), COUNT(*)
FROM model_usage
WHERE created_at >= now() - interval '1 hour'
GROUP BY tenant_id, feature
ORDER BY SUM(tokens) DESC;

如果只有总量指标，就只能看到系统很忙，却不知道是谁让系统忙。

五、总结

大模型应用多租户隔离要覆盖 API、队列、模型配额、数据命名空间、审计和计费。交互任务和批处理任务要分开治理。

别让一个客户吃光整条推理链路。多租户系统的高可用，首先来自资源边界清楚。

隔离不等于每个租户都独占资源。合理做法是共享基础设施，但在队列、配额、数据和审计层面建立边界。这样既能控制成本，也能保护体验。

还要给关键租户保留突发余量。比如企业客户做月末批处理时，流量可能短时间升高。系统可以允许 burst，但必须有上限和时间窗口。

tenant_burst:
  max_multiplier: 2
  duration_minutes: 10
  require_quota_available: true

这比简单拒绝更友好，也比无限放开更安全。多租户的难点就在这里：既要共享，又不能互相拖累。