云原生 AI 多租户：先隔离资源，再谈平台复用

AI 平台一旦从单团队使用走向多业务线，就会遇到多租户问题。大家都想复用同一套推理网关、训练任务、模型仓库和观测系统，但资源、权限、成本和数据边界不能混在一起。多租户平台的目标不是把所有人放进同一个集群，而是在可控隔离下复用基础设施。

云原生 AI 多租户要先隔离资源，再谈平台复用。

一、租户边界要分层

flowchart TD
  A[Tenant] --> B[Namespace]
  A --> C[ResourceQuota]
  A --> D[RBAC]
  A --> E[Cost Label]
  A --> F[NetworkPolicy]

最基础的隔离可以从 Namespace 开始，但 Namespace 只是边界容器，不是完整隔离。还要配合 ResourceQuota、LimitRange、RBAC、NetworkPolicy、审计日志和成本标签。只有这些一起工作，租户边界才算真正进入平台治理。

AI 平台还要考虑 GPU、模型缓存、向量库、对象存储等共享资源。普通 CPU 服务可以用配额解决很多问题，GPU 场景还要避免某个租户长期占用昂贵资源，导致其他租户无法排队运行。

二、资源配额要区分类型

apiVersion: v1
kind: ResourceQuota
metadata:
  name: tenant-quota
spec:
  hard:
    requests.cpu: "40"
    requests.memory: "160Gi"
    requests.nvidia.com/gpu: "4"

CPU、内存、GPU、存储、对象数量都应该有配额。GPU 配额尤其要明确 request 和 limit，不要让 Pod 不声明 GPU 却通过节点选择器占住 GPU 节点。配额不只是限制，也是成本核算的基础。

配额还要支持突发和预约。训练任务可能短时间需要更多 GPU，在线推理则需要稳定保障。平台可以为租户提供基础配额、临时配额和优先级队列，而不是让所有需求在同一个资源池里抢。

三、权限不能只看 Kubernetes

access_layers:
  kubernetes_rbac
  model_registry_acl
  object_storage_policy
  observability_permission

AI 多租户权限往往跨系统。用户有 Namespace 权限，不代表可以拉取所有模型；能查看 Pod 日志，不代表能看 Prompt 内容；能使用对象存储，不代表能访问其他租户数据集。权限模型要覆盖模型仓库、对象存储、向量库和观测平台。

统一身份很重要。最好让平台层使用同一个用户和租户上下文，把权限传递到各个组件。否则每个系统各管一套账号，排查和审计都会很困难。

四、成本要从第一天记录

{
  "tenant": "team-a",
  "resource": "gpu-hours",
  "amount": 12.5,
  "workload": "inference"
}

多租户平台如果不记录成本，很快会变成公共资源池。GPU 小时数、推理 token、对象存储、向量索引、日志量，都应该按租户归因。即使暂时不内部结算，也要让团队看到自己的使用情况。

成本可见会改变行为。业务方知道某个长上下文接口消耗很高，就更愿意配合做缓存、分层模型和请求限制。基础设施不是只负责兜底，也要让资源使用变得可解释。

五、总结

云原生 AI 多租户要从 Namespace、配额、RBAC、网络、跨系统权限和成本归因一起设计。先隔离资源和数据，再谈平台能力复用。

多租户不是把多个团队塞进一个集群。它是让每个团队在清楚边界里使用共享能力，并为自己的资源行为负责。