【中阶·融合】如何隔离多租户 AI 推理平台的 GPU 资源：从 Namespace 到 MIG/Kata 的五层纵深防御

【中阶·融合】如何隔离多租户 AI 推理平台的 GPU 资源从 Namespace 到 MIG/Kata 的五层纵深防御专栏《AI 工程与安全深度实战》· 第11轮·第3篇核心痛点多个团队共享同一组昂贵的 GPU 集群为什么一个租户的 OOM 崩溃能拖垮另一个租户的生产推理服务Namespace 隔离真的能保护 GPU 显存中的模型权重吗适配人群AI 平台工程师、Kubernetes 运维工程师、安全架构师以及正在规划或运营多租户 GPU 推理平台的技术团队收获能力掌握从 K8s Namespace/RBAC 到 NVIDIA MIG 硬件分区、再到 Kata Containers VM 级隔离的五层纵深防御架构具备在生产环境落地多租户 GPU 隔离方案的完整能力技术背景与演进逻辑企业 AI 基础设施正从一个团队独占一组 GPU向多团队共享 GPU 池演进驱动力1GPU 硬件成本极高H100 节点云端每小时超 30 美元独占模式导致利用率普遍低于 40%驱动力2AI 推理负载具有突发性独占分配意味着大量算力在低谷期闲置驱动力3企业内部多团队算法、产品、业务线需要共享统一的 GPU 平台以降低运维复杂度但共享带来了严峻的隔离挑战性能干扰一个租户的训练任务占满显存导致另一个租户的推理 Pod 被 OOM Kill安全风险GPU 驱动运行在宿主内核 Ring 0容器边界对 ioctl 调用无任何拦截数据泄露GPU 显存在 CUDA context 销毁后不会清零下一个租户可读取上一个租户的模型权重和 KV-Cache技术演进必然性从逻辑隔离到硬件隔离多层防御缺一不可演进时间线text 树表达多租户 GPU 隔离技术演进 ├── 2016 - NVIDIA Docker 发布: GPU 设备直接挂载到容器无隔离 ├── 2020 - NVIDIA MIG 随 A100 发布: 首次实现 GPU 硬件级分区隔离 ├── 2021 - Kata Containers 支持 VFIO GPU 直通: VM 级内核隔离 ├── 2023 - CVE-2023-0184 披露: NVKM 堆溢出可从容器提权到宿主 root ├── 2024 - Kueue GA DRA Beta: K8s 原生 GPU 调度与资源分配框架成熟 └── 2026 - vCluster/HAMi v2.9: 控制面隔离 异构 GPU 虚拟化成为生产标配核心原理深度解析多租户 GPU 隔离的本质是一个五层纵深防御问题五层隔离模型隔离层级分解text 树多租户 GPU 五层隔离模型 ├── 第1层 逻辑隔离层 │ ├── 机制: Namespace RBAC ResourceQuota │ ├── 隔离粒度: API 层面的资源可见性与配额控制 │ └── 局限: 不保护 GPU 显存、不拦截 ioctl 调用 ├── 第2层 调度隔离层 │ ├── 机制: PriorityClass Kueue ClusterQueue 拓扑感知调度 │ ├── 隔离粒度: GPU 资源分配公平性与抢占策略 │ └── 局限: 不阻止已分配 GPU 上的跨租户干扰 ├── 第3层 GPU 虚拟化隔离层 │ ├── 机制: NVIDIA MIG 硬件分区 / MPS 时间切片 / HAMi vGPU │ ├── 隔离粒度: GPU 显存与算力的物理或逻辑分区 │ └── 局限: MIG 仅限 A100/H100/H200MPS 无故障隔离 ├── 第4层 运行时隔离层 │ ├── 机制: Kata Containers VFIO 直通 / gVisor 用户态内核 │ ├── 隔离粒度: 每个租户独立内核ioctl 攻击面被 VM 边界阻断 │ └── 局限: Kata 增加冷启动延迟500-1500msgVisor 不支持 GPU └── 第5层 可观测性与策略执行层 ├── 机制: DCGM Exporter Prometheus Falco OPA/Gatekeeper ├── 隔离粒度: 实时监控 GPU 指标 异常访问检测 准入策略强制 └── 局限: 检测而非预防需配合前四层形成闭环逻辑推导每一层解决一类特定的隔离失败模式任何单一层被绕过都不会导致全面失守设计思想纵深防御的核心不是加更多墙而是每一层解决不同的失败模式GPU 共享内核攻击面分析GPU 驱动的共享内核问题攻击面分解text 树GPU 共享内核攻击面 ├── 宿主内核模块Ring 0 │ ├── nvidia (NVKM): 核心设备驱动处理所有 ioctl 调用 │ ├── nvidia-uvm: 统一虚拟内存子系统 │ ├── nvidia-modeset: 显示与模式设置 │ └── nvidia-peermem: GPUDirect RDMA 对等内存访问 ├── 容器内挂载的设备文件 │ ├── /dev/nvidia0 ~ /dev/nvidiaX: 每块 GPU 一个字符设备 │ ├── /dev/nvidiactl: 控制设备 │ └── /dev/nvidia-uvm: 统一虚拟内存设备 ├── 关键漏洞模式 │ ├── CVE-2023-0184: NVKM 堆溢出NV_ESC_RM_ALLOC ioctl │ ├── CVE-2021-1076: NVKM 释放后重用NV_ESC_REGISTER_FD │ ├── CVE-2022-28181: nvidia-vgpu-mgr 越界写入 │ └── CVE-2024-0074: nvidia-uvm 空指针解引用导致内核恐慌 └── GPU 显存残留问题 ├── CUDA context 销毁后显存不清零性能权衡 ├── torch.cuda.empty_cache() 仅释放到 PyTorch 缓存分配器 └── 下一个租户可读取上一个租户的模型权重与 KV-Cache逻辑推导nvidia-device-plugin 将 /dev/nvidia0 直接挂载到 Pod容器运行时不拦截 ioctl - 所有容器共享同一个 NVKM 内核模块 - 任何 NVKM 漏洞都可从容器提权到宿主 root设计思想容器边界提供的是文件系统和 PID 命名空间隔离对 GPU ioctl 攻击面提供零保护核心模块详解第1层Namespace RBAC ResourceQuota 逻辑隔离机制Kubernetes Namespace 将集群划分为独立的虚拟空间RBAC 控制每个租户的 API 访问范围ResourceQuota 限制 GPU 资源消耗上限配置流程text 树 箭头逻辑隔离部署流程 ├── 创建 Namespace - 配置 RBAC Role RoleBinding ├── 配置 RBAC - 设置 ResourceQuotaGPU 上限 ├── 设置 ResourceQuota - 配置 LimitRange默认请求值 └── 配置 LimitRange - 验证租户只能看到自己的资源核心配置apiVersion:v1kind:ResourceQuotametadata:name:gpu-quota-team-anamespace:team-aspec:hard:requests.nvidia.com/gpu:4limits.nvidia.com/gpu:4pods:20---apiVersion:v1kind:LimitRangemetadata:name:gpu-limit-rangenamespace:team-aspec:limits:-default:nvidia.com/gpu:1defaultRequest:nvidia.com/gpu:1type:Container关键局限Namespace 隔离不保护 GPU 显存。/dev/nvidia0 是宿主文件系统上的字符设备nvidia-device-plugin 基于资源请求将其挂载到 Pod。两个不同 Namespace 的 Pod 在同一节点上都请求 nvidia.com/gpu: “1”它们可能共享同一块物理 GPU通过 MPS 或时间切片。Namespace 边界不阻止任何一个 Pod 的代码读取另一个 Pod 的 GPU DRAM第2层PriorityClass Kueue 调度隔离机制PriorityClass 定义工作负载优先级高优先级 Pod 可抢占低优先级 Pod 的 GPU 资源Kueue 提供租户级 ClusterQueue 配额管理与公平调度核心配置apiVersion:scheduling.k8s.io/v1kind:PriorityClassmetadata:name:gpu-productionvalue:1000000globalDefault:falsedescription:生产推理服务优先级---apiVersion:scheduling.k8s.io/v1kind:PriorityClassmetadata:name:gpu-dev-testvalue:100globalDefault:falsedescription:开发测试工作负载优先级Kueue ClusterQueue 配置为每个租户设置独立的 GPU 配额apiVersion:kueue.x-k8s.io/v1beta1kind:ClusterQueuemetadata:name:team-a-gpu-queuespec:resourceGroups:-coveredResources:[cpu,memory,nvidia.com/gpu]flavors:-name:gpu-h100resources:-name:nvidia.com/gpunominalQuota:8borrowingLimit:2namespaceSelector:matchLabels:team:team-a调度策略优化默认调度器倾向于 Spread分散调度导致多节点部分利用。配置 MostAllocated 策略实现 Bin-Pack将 GPU 工作负载集中到最少节点空闲节点可通过 Cluster Autoscaler 缩容profiles:-schedulerName:default-schedulerpluginConfig:-name:NodeResourcesFitargs:scoringStrategy:type:MostAllocated第3层NVIDIA MIG 硬件级 GPU 分区隔离机制MIGMulti-Instance GPU在硬件层面将单块物理 GPU 划分为最多 7 个独立实例每个实例拥有独立的 DRAM 分区、L2 缓存切片和流式多处理器MIG 隔离特性矩阵text 树MIG vs MPS vs 时间切片对比 ├── MIG硬件分区 │ ├── 显存隔离: 硬件强制跨实例不可读 │ ├── 计算隔离: 独立 SM 分配互不影响 │ ├── 故障隔离: 一个实例崩溃不影响其他实例 │ ├── 适用硬件: A100 / H100 / H200 / L40S │ └── 最大实例数: A100-80GB 可分 7 个 1g.10gb ├── MPS多进程服务 │ ├── 显存隔离: 无所有客户端共享同一地址空间 │ ├── 计算隔离: SM 资源并发共享 │ ├── 故障隔离: 无一个客户端 CUDA 错误杀死所有客户端 │ ├── 适用硬件: 所有支持 CUDA 的 GPU │ └── 安全警告: 仅适用于互相信任的 HPC 工作负载 └── 时间切片Time-Slicing ├── 显存隔离: 无所有进程共享同一显存空间 ├── 计算隔离: 上下文切换延迟不可预测 ├── 故障隔离: 无 ├── 适用硬件: 所有 NVIDIA GPU含 T4/V100 └── 适用场景: 开发测试环境非生产多租户MIG 部署配置# 在 A100 节点启用 MIG 模式sudonvidia-smi-mig1# 创建 7 个 1g.10gb 实例sudonvidia-smi mig-cgi1g.10gb,1g.10gb,1g.10gb,1g.10gb,1g.10gb,1g.10gb,1g.10gb-C# 通过 gpu-operator 的 MIG 策略配置helminstallnvdp nvdp/nvidia-device-plugin\n--version0.17.0\n--namespacenvidia-device-plugin\n --create-namespace\n--setmigStrategymixedPod 请求 MIG 资源apiVersion:v1kind:Podmetadata:name:inference-tenant-aspec:containers:-name:vllm-serverimage:vllm/vllm-openai:v0.8.5resources:limits:nvidia.com/mig-1g.10gb:1关键安全价值MIG 分区后租户 A 的 Pod 无法寻址租户 B 的 DRAM无论任何 CUDA API 调用或驱动漏洞。GPU 显存残留问题在 MIG 实例之间被硬件彻底消除第4层Kata Containers VFIO GPU 直通运行时隔离机制Kata Containers 为每个 Pod 提供轻量级 VM 内核GPU 通过 VFIO/IOMMU 直通到 VM 内部。NVKM ioctl 攻击面被限制在 VM 内核中即使触发 CVE-2023-0184 级别的漏洞也只能获得 VM root 而非宿主 root隔离架构text 树 箭头Kata VFIO GPU 隔离架构 ├── 宿主节点 │ ├── 宿主内核: nvidia 驱动 unbind - vfio-pci 绑定 │ ├── Kata Runtime: 创建轻量级 QEMU VM │ └── VFIO IOMMU: GPU 设备直通到 VMDMA 边界由硬件强制 ├── VM 内部每个租户独立 │ ├── Guest 内核: 独立的 nvidia 驱动实例 │ ├── /dev/nvidia0: 挂载在 VM 内部不暴露到宿主 │ └── NVKM ioctl: 在 Guest 内核中处理攻击面被 VM 边界阻断 └── 安全边界 ├── CVE-2023-0184 利用: 获得 VM root非宿主 root ├── GPU 显存: 每个 VM 有独立的 IOMMU DMA 映射 └── 冷启动延迟: 500-1500msVM 启动时间Kata RuntimeClass 配置apiVersion:node.k8s.io/v1kind:RuntimeClassmetadata:name:kata-vfio-gpuhandler:katascheduling:nodeSelector:katacontainers.io/kata-runtime:truePod 使用 Kata 运行时apiVersion:v1kind:Podmetadata:name:isolated-inference-podspec:runtimeClassName:kata-vfio-gpucontainers:-name:inferenceimage:vllm/vllm-openai:v0.8.5resources:limits:nvidia.com/gpu:1securityContext:allowPrivilegeEscalation:falsereadOnlyRootFilesystem:truerunAsNonRoot:true适用场景运行不受信任的推理代码如用户提供模型制品、合规敏感环境金融/医疗、需要最强隔离保障的生产租户第5层DCGM Falco OPA/Gatekeeper 可观测性与策略执行机制DCGM Exporter 采集每块 GPU 的详细指标利用率、显存、温度、PCIe 带宽Falco 检测异常 GPU 设备访问OPA/Gatekeeper 在准入阶段强制执行安全策略Falco GPU 异常访问检测规则-rule:Unexpected GPU device accessdesc:非已知 ML 运行时的进程访问 NVIDIA GPU 设备节点 可能是容器逃逸或配置错误condition:(open_read or open_write) and fd.name startswith /dev/nvidia and not proc.name in (python3, vllm, tritonserver, nvidia-smi, dcgm-exporter) and container.id ! hostoutput:异常 GPU 设备访问 (proc%proc.name container%container.name pod%k8s.pod.name ns%k8s.ns.name)priority:WARNINGOPA/Gatekeeper 准入策略强制 GPU Pod 设置安全上下文apiVersion:constraints.gatekeeper.sh/v1beta1kind:K8sPSPAllowedUsersmetadata:name:gpu-pod-security-contextspec:match:kinds:-apiGroups:[]kinds:[Pod]scope:Namespacesparameters:runAsUser:rule:MustRunAsNonRootrunAsNonRoot:trueDCGM Prometheus Grafana 监控栈采集 GPU 利用率、显存使用、温度、PCIe 带宽等指标按租户 Namespace 聚合展示设置显存 85% 告警阈值预防 OOM 级联故障技术优缺点与适用场景对比总览text 树表达五层隔离方案对比 ├── 逻辑隔离Namespace/RBAC/Quota │ ├── 优势: 零额外开销所有 K8s 集群原生支持 │ ├── 局限: 不保护 GPU 显存不拦截 ioctl │ ├── 性能影响: 无 │ └── 适用规模: 任何规模的基础隔离 ├── 调度隔离Kueue/PriorityClass │ ├── 优势: 公平配额管理生产工作负载优先保障 │ ├── 局限: 不阻止已分配 GPU 上的跨租户干扰 │ ├── 性能影响: 无 │ └── 适用规模: 多团队共享 GPU 池的中大型集群 ├── MIG 硬件分区 │ ├── 优势: 硬件强制显存隔离消除跨实例数据泄露 │ ├── 局限: 仅 A100/H100/H200 支持分区粒度固定 │ ├── 性能影响: 每个实例算力按比例缩减 │ └── 适用规模: A100 硬件的生产推理集群 ├── Kata VFIO 运行时隔离 │ ├── 优势: VM 级内核隔离NVKM 漏洞影响限制在 VM 内 │ ├── 局限: 冷启动延迟 500-1500ms运维复杂度高 │ ├── 性能影响: CUDA context 创建增加 1-3ms │ └── 适用规模: 不受信任代码 / 合规敏感环境 └── 可观测性与策略执行 ├── 优势: 实时检测异常准入阶段拦截违规配置 ├── 局限: 检测而非预防需配合前四层 ├── 性能影响: DCGM 采集约 1% 开销 └── 适用规模: 所有生产 GPU 集群必选适用场景中小团队内部共享3-5 个团队Namespace RBAC ResourceQuota MIG如有 A100即可满足企业级多租户平台10 租户五层全部启用Kata 仅对不受信任租户启用AI 云服务提供商五层 vCluster 控制面隔离 GPU 驱动版本钉死 CVE 72 小时 P1 补丁 SLA禁忌场景MPS 用于多租户生产环境所有 MPS 客户端共享同一地址空间一个租户的 CUDA 错误杀死所有租户仅依赖 Namespace 隔离保护 GPU 显存中的模型权重Namespace 不拦截 ioctl不保护 GPU DRAM时间切片用于对延迟敏感的生产推理上下文切换引入不可预测的延迟抖动实战落地完整部署流程部署链路text 树 箭头多租户 GPU 隔离部署链路 ├── 阶段1: 基础隔离 │ ├── 创建租户 Namespace - 配置 RBAC │ ├── 配置 RBAC - 设置 ResourceQuota LimitRange │ └── 验证: kubectl auth can-i --asteam-a-sa list pods -n team-b应拒绝 ├── 阶段2: GPU 驱动安全加固 │ ├── 钉死 GPU 驱动版本 - 在 gpu-operator ClusterPolicy 中设置 version │ ├── 禁用 MPS - 在 nvidia-device-plugin ConfigMap 中清空 mps.resources │ └── 验证: nvidia-smi --query-gpudriver_version 确认版本一致 ├── 阶段3: MIG 分区A100 节点 │ ├── 启用 MIG 模式 - 创建 MIG 实例 - 配置 mixed 策略 │ ├── 节点标记 nvidia.com/mig.config - 重启 Device Plugin │ └── 验证: Pod 请求 mig-1g.10gb确认 nvidia-smi 只显示自己的实例 ├── 阶段4: 调度策略 │ ├── 部署 Kueue - 为每个租户创建 ClusterQueue │ ├── 配置 PriorityClass - 生产 测试 开发 │ └── 配置 Bin-Pack - MostAllocated 调度策略 ├── 阶段5: 运行时隔离按需 │ ├── 部署 Kata Containers - 配置 VFIO GPU 直通 │ ├── 创建 kata-vfio-gpu RuntimeClass │ └── 验证: 不受信任租户的 Pod 使用 kata 运行时 └── 阶段6: 可观测性与策略 ├── 部署 DCGM Exporter Prometheus Grafana ├── 部署 Falco GPU 异常访问检测规则 ├── 部署 OPA/Gatekeeper 准入策略 └── 验证: 模拟异常 GPU 访问确认 Falco 告警触发GPU 驱动版本钉死与 CVE 追踪驱动版本钉死配置apiVersion:nvidia.com/v1kind:ClusterPolicymetadata:name:gpu-cluster-policyspec:driver:enabled:truerepository:nvcr.io/nvidiaimage:driverversion:560.35.03operator:upgradeCRD:truedaemonsets:updateStrategy:RollingUpdateCVE 追踪要点订阅 NVIDIA PSIRT RSS 和 NVD CPE cpe:2.3️nvidia:gpu_driver 提要CVSS 7.0 的内核模块漏洞视为 P172 小时内打补丁受影响节点立即 cordon drain避坑经验MPS 用于多租户是最常见的致命错误NVIDIA 文档明确说明 MPS 仅适用于互相信任的 HPC 工作负载。在多租户环境中启用 MPS 消除了故障隔离一个租户的 CUDA 断言错误可杀死所有共置租户的推理进程Namespace 隔离不等于 GPU 隔离Kubernetes Namespace 是控制面概念控制 Pod 通信、RBAC 和 NetworkPolicy。它不保护 GPU 显存。/dev/nvidia0 是宿主文件系统上的字符设备Namespace 边界不阻止一个 Pod 的代码读取另一个 Pod 的 GPU DRAMGPU 驱动 CVE 不在 Linux 发行版安全公告中NVIDIA 驱动是闭源二进制不通过发行版仓库分发。依赖 OS 厂商安全公告的团队会完全错过 NVIDIA 驱动 CVE。需要独立追踪 NVIDIA 安全公告页面和 NVDMIG 分区变更需要 drain 节点MIG 分区配置变更需要终止节点上所有 GPU 工作负载不能热切换。规划分区方案时应预留足够余量显存残留是真实威胁CUDA context 销毁后 GPU DRAM 不会清零。在非 MIG 环境中下一个租户可通过 torch.empty() 读取上一个租户的模型权重和 KV-Cache。MIG 通过硬件分区消除此问题非 MIG 环境需在应用层显式清零tensor.zero_() torch.cuda.synchronize()全文总结核心原理多租户 GPU 隔离不是单一技术能解决的问题必须在逻辑隔离、调度隔离、GPU 虚拟化隔离、运行时隔离、可观测性五个层面构建纵深防御关键结论Namespace 隔离是必要基础但远不充分MIG 是 A100 硬件上性价比最高的隔离手段Kata VFIO 是运行不受信任代码时的唯一可靠选择落地重点先建立 Namespace/RBAC/Quota 基础再启用 MIG 硬件分区最后按需叠加 Kata 运行时隔离和 Falco 异常检测技术本质GPU 驱动运行在宿主内核 Ring 0容器边界对 GPU ioctl 攻击面提供零保护。真正的多租户安全必须在硬件层面MIG/IOMMU和运行时层面VM 隔离建立不可绕过的边界免责声明本文所有技术内容仅供安全研究与教学目的使用。文中涉及的攻击面分析基于公开的 CVE 和学术研究所有安全加固配置均在可控的隔离环境中验证。严禁将文中技术用于非法用途。实际部署安全方案前请结合自身业务场景进行充分测试。本期专栏更新说明本文为《AI 工程与安全深度实战》订阅专栏持续迭代内容专栏按初/中/高阶递进规划长期更新 AI 云原生架构、GPU 算力工程、LLMOps 运维智能化、模型安全攻防、供应链安全、安全治理与合规实践一次订阅永久持续更新。专栏推荐AI 工程与安全深度实战TypeScript 从入门到精通LangChain/LangGraph 从入门到精通Rust 从入门到精通参考资料Designing multitenant GPU infrastructure: Isolation across virtualization and Kubernetes platforms - Red Hat (2026)GPU Tenant Isolation in Kubernetes: Strategies for AI Cloud Operators - vCluster (2025)GPU Shared-Kernel Attacks: Isolation Failures in Multi-Tenant AI Inference Clusters - System Hardening (2025)NVIDIA Multi-Instance GPU (MIG) 技术文档Kata Containers: Kubernetes workload isolation for secure AIHAMi v2.9: Kubernetes as the GPU Control PlaneImprove GPU utilization with Kueue in OpenShift AI - Red Hat Developer (2025)CVE-2023-0184: NVIDIA GPU Driver Vulnerability - NVD