📚 课程目录第3章多租户隔离概述

3、多租户隔离概述：多租户定义、隔离需求、隔离维度（计算、存储、网络、数据）及挑战

随着大模型从实验室走向生产环境，单一模型实例服务多个业务方已成为常态。无论是企业内部多个团队共享一套GPU集群，还是云服务商以API形式对外提供模型推理能力，都面临一个核心问题：如何让多个“租户”安全、稳定、高效地共享同一套底层资源，同时互不干扰。多租户隔离正是解决这一问题的关键架构设计。本章将系统阐述多租户的定义与本质、隔离需求的来源、四大隔离维度的技术内涵，以及实施过程中必须正视的工程挑战。

3.1 多租户定义与隔离需求本质

多租户（Multi-Tenancy）并非新概念，在SaaS领域已有数十年实践。但在大模型部署场景下，其内涵发生了显著变化。传统多租户通常指多个客户共享一套软件实例，通过逻辑配置实现数据与功能隔离。而大模型部署的多租户，则是在共享GPU算力、模型权重、推理服务的基础上，为不同业务方提供独立的资源配额、数据边界和策略控制。

从本质上看，大模型多租户隔离需要回答三个核心问题：谁在用（租户身份与权限）、能用多少（资源配额与限制）、能看什么（数据与模型访问边界）。这三个问题分别对应身份认证、资源调度和权限控制，构成了隔离架构的基石。

隔离需求的来源可以归纳为四类：

安全合规需求：不同租户的Prompt可能包含敏感商业数据或个人隐私，法律合规要求（如GDPR、等保）强制要求数据不可跨租户泄露。
稳定性需求：一个租户的突发流量或恶意请求不应导致其他租户的服务质量下降，即“爆炸半径”控制。
计费与配额需求：多租户场景下需要精确计量每个租户的算力消耗，以便进行成本分摊或按量计费。
个性化配置需求：不同租户可能需要不同的模型版本、超参数、知识库或后处理逻辑，隔离是配置独立性的前提。

  核心理解：多租户隔离不是“物理隔离”的代名词，而是“逻辑隔离为主、物理隔离为辅”的混合策略。物理隔离（如独立GPU）安全性最高但成本极高，逻辑隔离（如容器、虚拟化）成本可控但需要精细设计。实际部署中通常采用分层隔离策略：关键数据物理隔离，一般计算逻辑隔离。

3.2 四大隔离维度详解

大模型部署的隔离体系可以从计算、存储、网络、数据四个维度展开。每个维度都有其独特的技术手段和适用场景，且四个维度之间相互关联、相互制约。

3.2.1 计算隔离

计算隔离关注的是算力资源的分配与保护，包括GPU显存、CUDA核心、CPU资源、内存带宽等。大模型推理是计算密集型任务，计算隔离直接决定了租户间的性能干扰程度。

当前主流的计算隔离技术包括：

技术方案	隔离粒度	优点	局限	适用场景
NVIDIA MIG	GPU实例级（A100/H100）	硬件级隔离，显存与算力独立，安全性强	仅支持部分高端GPU，实例数量有限	对安全要求高的多租户生产环境
vGPU（虚拟GPU）	时间片+显存分区	灵活配置，支持更多并发租户	性能损耗约5%-15%，存在侧信道风险	中低并发、成本敏感场景
容器资源限制	进程级（cgroup/namespace）	轻量级，部署简单，CPU/内存隔离有效	显存隔离能力弱，需配合其他技术	CPU推理、混合负载场景
多进程/多副本	独立进程/独立模型实例	隔离最彻底，故障互不影响	显存占用成倍增加，成本高	高价值租户、严格SLA场景

在实际工程中，计算隔离还需要考虑并发调度策略。例如，当多个租户同时发起推理请求时，需要设计排队机制和优先级策略。常见的做法是采用加权公平队列（WFQ），为高优先级租户分配更多权重，同时保证低优先级租户不被饿死。

3.2.2 存储隔离

大模型部署涉及的存储对象包括：模型权重文件（通常数GB至数百GB）、推理缓存（KV Cache）、临时文件、日志、配置文件等。存储隔离的目标是确保租户A无法读取或篡改租户B的数据，同时避免单个租户的存储占用影响全局。

存储隔离的关键实践：

模型权重只读共享：基础模型权重对所有租户只读共享，通过文件系统权限控制，防止任何租户修改。若租户需要微调版本，则使用独立的权重副本。
缓存目录按租户分桶：KV Cache或前缀缓存按租户ID分目录存储，并设置容量上限。例如，租户A的缓存目录为 /cache/tenant_a/，配额20GB；租户B为 /cache/tenant_b/，配额50GB。
临时文件生命周期管理：推理过程中产生的临时文件（如中间结果、上传的附件）需要设置TTL（生存时间），到期自动清理，防止残留数据被其他租户访问。
存储配额与告警：使用quota机制限制每个租户的存储上限，当使用量超过80%时触发告警，超过100%时拒绝写入。

风险提示：存储隔离中最容易被忽视的是“共享缓存”问题。如果多个租户共用同一个KV Cache池，且未做键前缀隔离，可能出现数据串扰——租户A的Prompt片段被错误地用于租户B的上下文生成。务必在缓存键设计中加入租户ID维度。

3.2.3 网络隔离

网络隔离涉及两个层面：一是租户访问模型服务的网络通道隔离，二是模型服务内部组件之间的网络通信隔离。前者关注外部安全，后者关注内部防横向移动。

网络隔离的工程实现要点：

接入层隔离：每个租户分配独立的API Key或Token，API网关根据Key识别租户身份，并应用对应的限流策略、IP白名单和TLS证书。
带宽与QoS控制：在网关或负载均衡层设置带宽上限。例如，租户A的峰值带宽限制为100Mbps，租户B为500Mbps。使用令牌桶算法实现流量整形，防止突发流量打满网络。
安全组与防火墙：在Kubernetes或虚拟机环境中，为不同租户的Pod/VM分配不同的安全组，默认拒绝跨租户的Pod间通信。若需跨租户通信（如共享知识库），需显式配置NetworkPolicy。
加密通道：所有租户请求必须通过TLS 1.2+加密传输。对于高安全租户，可提供专属VPN或专线接入。

3.2.4 数据隔离

数据隔离是多租户隔离中最敏感、最复杂的维度。它不仅涉及静态数据的存储隔离，还涉及动态数据（推理过程中的输入输出）的隔离，以及模型本身可能“记住”训练数据带来的隐私风险。

数据隔离的完整策略框架：

数据类别	隔离要求	技术手段
Prompt输入	租户A的Prompt不可被租户B获取	请求级隔离、内存清理、日志脱敏
模型输出	输出结果仅返回给发起请求的租户	连接级绑定、响应通道隔离
知识库/向量库	租户只能检索自己的知识库	向量库按租户分Collection，查询时注入租户过滤条件
API密钥与凭据	密钥不可跨租户使用	密钥管理系统（KMS）+ 租户维度密钥轮换
审计日志	日志可追溯但敏感信息脱敏	日志中租户ID保留，Prompt内容哈希化或截断

特别需要关注的是模型记忆泄露风险。大模型在训练时可能记住训练数据中的敏感信息，当租户A通过精心构造的Prompt诱导模型输出时，可能间接获取租户B的训练数据。这种跨租户数据泄露极难防范，目前可行的缓解措施包括：对输出进行敏感信息过滤、限制模型对特定实体的知识访问、以及使用差分隐私训练技术。

3.3 隔离实施案例：金融行业多租户推理平台

为更具体地说明隔离维度的落地方式，我们以一个金融科技公司的实际案例进行拆解。该公司需要为三家银行客户（租户A、B、C）提供基于大模型的智能客服和风控分析服务，部署环境为4台NVIDIA A100 GPU服务器。

背景与约束：

租户A（大型银行）：日均请求量50万，峰值QPS 800，要求P99延迟小于500ms，数据合规等级最高。
租户B（中型银行）：日均请求量20万，峰值QPS 300，P99延迟小于1s。
租户C（小型金融公司）：日均请求量5万，峰值QPS 80，对延迟不敏感，成本敏感。
硬件资源：4×A100 80GB GPU，总计320GB显存；每张GPU支持MIG切分为7个实例。

初始现象与目标：最初采用“一租户一GPU”的物理隔离方案，但发现GPU利用率仅35%，资源浪费严重。目标是在保证安全隔离的前提下，将GPU利用率提升至70%以上。

分析判断过程：

租户A对延迟和合规要求最高，不能与其他租户共享GPU实例，需独占至少2张GPU（160GB显存），并使用MIG切分为2个实例（各80GB），一个用于在线推理，一个用于批量任务。
租户B和租户C可以共享剩余2张GPU。每张GPU通过MIG切分为4个实例（每实例20GB显存），租户B分配3个实例，租户C分配1个实例。但租户C的模型较小（7B参数），20GB显存足够。
网络层面：租户A使用独立VIP和TLS证书，租户B/C共用网关但通过API Key区分，设置不同的限流阈值。
存储层面：模型权重文件放在共享只读卷，但每个租户的微调版本和缓存目录完全隔离。

实际操作步骤：

# 1. GPU MIG配置（以租户B/C共享的GPU为例）
nvidia-smi mig -cgi 1,1,1,1 -C 4G.20GB  # 创建4个20GB实例

# 2. Kubernetes中为租户B分配3个MIG实例
kubectl create namespace tenant-b
kubectl label node gpu-node-01 nvidia.com/mig.config=4G.20GB
# 在Deployment中指定MIG实例
# resources:
#   limits:
#     nvidia.com/mig-4g.20gb: 3

# 3. 存储隔离配置
mkdir -p /data/models/tenant-b /data/models/tenant-c
chmod 700 /data/models/tenant-b /data/models/tenant-c
# 缓存目录
mkdir -p /cache/tenant-b /cache/tenant-c
# 设置配额
setquota -u tenant-b 50G 60G /cache
setquota -u tenant-c 20G 25G /cache

# 4. 网络策略（NetworkPolicy）
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: deny-cross-tenant
  namespace: tenant-b
spec:
  podSelector: {}
  policyTypes: ["Ingress"]
  ingress:
  - from:
    - namespaceSelector:
        matchLabels:
          name: tenant-b

结果对比：实施后GPU利用率从35%提升至68%，租户A的P99延迟稳定在450ms，租户B的P99延迟为850ms，租户C的P99延迟为1.2s（在可接受范围内）。未发生跨租户数据泄露事件。

风险与代价：MIG配置后无法动态调整，需提前规划好各租户的容量；租户C的延迟偶尔波动，因为与租户B共享GPU时，租户B的突发流量会抢占算力。后续通过为租户C设置更严格的cgroup CPU限制缓解了该问题。

复盘经验：隔离方案设计必须从租户的SLA要求出发，而不是从技术便利性出发。对于高价值租户，物理隔离或MIG隔离是值得的成本投入；对于长尾租户，逻辑隔离配合完善的监控告警即可满足需求。

3.4 常见误区与总结复盘

在多租户隔离的工程实践中，以下误区值得特别警惕：

误区一：认为“容器隔离=安全隔离”。容器默认共享内核，存在逃逸风险。在大模型场景中，如果租户可以执行任意代码（如通过模型加载路径注入），可能突破容器边界。必须配合安全上下文（SecurityContext）、只读根文件系统、以及Seccomp/AppArmor策略。

误区二：忽略显存隔离的“软性”特征。即使通过MIG或vGPU实现了显存分区，GPU的L2缓存和内存带宽仍然是共享的。一个租户的高并发请求可能造成L2缓存颠簸，影响其他租户的推理延迟。需要监控GPU的缓存命中率和内存带宽利用率，而不仅仅是显存占用。

误区三：数据隔离只关注存储，忽略内存中的残留。推理结束后，GPU显存和CPU内存中可能残留Prompt数据。如果下一个租户的请求复用了同一块显存，理论上可能通过侧信道恢复部分数据。建议在推理结束后对显存缓冲区进行清零操作，或使用支持安全擦除的推理框架。

总结复盘：多租户隔离是一个系统工程，需要从计算、存储、网络、数据四个维度协同设计。隔离粒度越细，安全性和灵活性越高，但性能损耗和运维复杂度也越大。建议采用“分级隔离”策略：根据租户的SLA、安全等级和付费能力，将租户划分为不同等级，匹配不同的隔离方案。同时，建立完善的监控体系，实时追踪每个租户的资源使用、延迟指标和异常行为，为隔离策略的动态调整提供数据支撑。

实践建议：在项目初期，不要追求一步到位的完美隔离。先以“最小可行隔离”上线（如容器+命名空间+存储分桶），运行1-2周收集真实负载数据，再根据瓶颈逐步升级隔离方案。隔离是手段，不是目的——最终目标是让每个租户获得与其需求匹配的服务质量。