【中阶·融合】如何隔离多租户 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 池"演进
* 驱动力1：GPU 硬件成本极高（H100 节点云端每小时超 30 美元），独占模式导致利用率普遍低于 40%
* 驱动力2：AI 推理负载具有突发性，独占分配意味着大量算力在低谷期闲置
* 驱动力3：企业内部多团队（算法、产品、业务线）需要共享统一的 GPU 平台以降低运维复杂度
* 但共享带来了严峻的隔离挑战
* 性能干扰：一个租户的训练任务占满显存，导致另一个租户的推理 Pod 被 OOM Kill
* 安全风险：GPU 驱动运行在宿主内核 Ring 0，容器边界对 ioctl 调用无任何拦截
* 数据泄露：GPU 显存在 CUDA context 销毁后不会清零，下一个租户可读取上一个租户的模型权重和 KV-Cache
* 技术演进必然性：从逻辑隔离到硬件隔离，多层防御缺一不可
* 演进时间线（text 树表达）：
```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 树）：
```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/H200；MPS 无故障隔离
├── 第4层 运行时隔离层
│ ├── 机制: Kata Containers + VFIO 直通 / gVisor 用户态内核
│ ├── 隔离粒度: 每个租户独立内核，ioctl 攻击面被 VM 边界阻断
│ └── 局限: Kata 增加冷启动延迟（500-1500ms）；gVisor 不支持 GPU
└── 第5层 可观测性与策略执行层
├── 机制: DCGM Exporter + Prometheus + Falco + OPA/Gatekeeper
├── 隔离粒度: 实时监控 GPU 指标 + 异常访问检测 + 准入策略强制
└── 局限: 检测而非预防，需配合前四层形成闭环
```
* 逻辑推导：每一层解决一类特定的隔离失败模式，任何单一层被绕过都不会导致全面失守
* 设计思想：纵深防御的核心不是"加更多墙"，而是"每一层解决不同的失败模式"
* GPU 共享内核攻击面分析
*
#### GPU 驱动的共享内核问题
* 攻击面分解（text 树）：
```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 树 + 箭头）：
```text
逻辑隔离部署流程
├── 创建 Namespace -> 配置 RBAC Role + RoleBinding
├── 配置 RBAC -> 设置 ResourceQuota（GPU 上限）
├── 设置 ResourceQuota -> 配置 LimitRange（默认请求值）
└── 配置 LimitRange -> 验证租户只能看到自己的资源
```
* 核心配置：
```yaml
apiVersion: v1
kind: ResourceQuota
metadata:
name: gpu-quota-team-a
namespace: team-a
spec:
hard:
requests.nvidia.com/gpu: "4"
limits.nvidia.com/gpu: "4"
pods: "20"
---
apiVersion: v1
kind: LimitRange
metadata:
name: gpu-limit-range
namespace: team-a
spec:
limits:
- default:
nvidia.com/gpu: "1"
defaultRequest:
nvidia.com/gpu: "1"
type: 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 配额管理与公平调度
* 核心配置：
```yaml
apiVersion: scheduling.k8s.io/v1
kind: PriorityClass
metadata:
name: gpu-production
value: 1000000
globalDefault: false
description: "生产推理服务优先级"
---
apiVersion: scheduling.k8s.io/v1
kind: PriorityClass
metadata:
name: gpu-dev-test
value: 100
globalDefault: false
description: "开发测试工作负载优先级"
```
* Kueue ClusterQueue 配置（为每个租户设置独立的 GPU 配额）：
```yaml
apiVersion: kueue.x-k8s.io/v1beta1
kind: ClusterQueue
metadata:
name: team-a-gpu-queue
spec:
resourceGroups:
- coveredResources: ["cpu", "memory", "nvidia.com/gpu"]
flavors:
- name: gpu-h100
resources:
- name: nvidia.com/gpu
nominalQuota: "8"
borrowingLimit: "2"
namespaceSelector:
matchLabels:
team: team-a
```
* 调度策略优化：默认调度器倾向于 Spread（分散）调度，导致多节点部分利用。配置 MostAllocated 策略实现 Bin-Pack，将 GPU 工作负载集中到最少节点，空闲节点可通过 Cluster Autoscaler 缩容
```yaml
profiles:
- schedulerName: default-scheduler
pluginConfig:
- name: NodeResourcesFit
args:
scoringStrategy:
type: MostAllocated
```
*
#### 第3层：NVIDIA MIG 硬件级 GPU 分区隔离
* 机制：MIG（Multi-Instance GPU）在硬件层面将单块物理 GPU 划分为最多 7 个独立实例，每个实例拥有独立的 DRAM 分区、L2 缓存切片和流式多处理器
* MIG 隔离特性矩阵（text 树）：
```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 部署配置：
```bash
# 在 A100 节点启用 MIG 模式
sudo nvidia-smi -mig 1
# 创建 7 个 1g.10gb 实例
sudo nvidia-smi mig -cgi 1g.10gb,1g.10gb,1g.10gb,1g.10gb,1g.10gb,1g.10gb,1g.10gb -C
# 通过 gpu-operator 的 MIG 策略配置
helm install nvdp nvdp/nvidia-device-plugin \n --version=0.17.0 \n --namespace nvidia-device-plugin \n --create-namespace \n --set migStrategy=mixed
```
* Pod 请求 MIG 资源：
```yaml
apiVersion: v1
kind: Pod
metadata:
name: inference-tenant-a
spec:
containers:
- name: vllm-server
image: vllm/vllm-openai:v0.8.5
resources:
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 树 + 箭头）：
```text
Kata + VFIO GPU 隔离架构
├── 宿主节点
│ ├── 宿主内核: nvidia 驱动 unbind -> vfio-pci 绑定
│ ├── Kata Runtime: 创建轻量级 QEMU VM
│ └── VFIO IOMMU: GPU 设备直通到 VM，DMA 边界由硬件强制
├── VM 内部（每个租户独立）
│ ├── Guest 内核: 独立的 nvidia 驱动实例
│ ├── /dev/nvidia0: 挂载在 VM 内部，不暴露到宿主
│ └── NVKM ioctl: 在 Guest 内核中处理，攻击面被 VM 边界阻断
└── 安全边界
├── CVE-2023-0184 利用: 获得 VM root，非宿主 root
├── GPU 显存: 每个 VM 有独立的 IOMMU DMA 映射
└── 冷启动延迟: 500-1500ms（VM 启动时间）
```
* Kata RuntimeClass 配置：
```yaml
apiVersion: node.k8s.io/v1
kind: RuntimeClass
metadata:
name: kata-vfio-gpu
handler: kata
scheduling:
nodeSelector:
katacontainers.io/kata-runtime: "true"
```
* Pod 使用 Kata 运行时：
```yaml
apiVersion: v1
kind: Pod
metadata:
name: isolated-inference-pod
spec:
runtimeClassName: kata-vfio-gpu
containers:
- name: inference
image: vllm/vllm-openai:v0.8.5
resources:
limits:
nvidia.com/gpu: "1"
securityContext:
allowPrivilegeEscalation: false
readOnlyRootFilesystem: true
runAsNonRoot: true
```
* 适用场景：运行不受信任的推理代码（如用户提供模型制品）、合规敏感环境（金融/医疗）、需要最强隔离保障的生产租户
*
#### 第5层：DCGM + Falco + OPA/Gatekeeper 可观测性与策略执行
* 机制：DCGM Exporter 采集每块 GPU 的详细指标（利用率、显存、温度、PCIe 带宽），Falco 检测异常 GPU 设备访问，OPA/Gatekeeper 在准入阶段强制执行安全策略
* Falco GPU 异常访问检测规则：
```yaml
- rule: Unexpected GPU device access
desc: >
非已知 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 != host
output: >
异常 GPU 设备访问
(proc=%proc.name container=%container.name
pod=%k8s.pod.name ns=%k8s.ns.name)
priority: WARNING
```
* OPA/Gatekeeper 准入策略（强制 GPU Pod 设置安全上下文）：
```yaml
apiVersion: constraints.gatekeeper.sh/v1beta1
kind: K8sPSPAllowedUsers
metadata:
name: gpu-pod-security-context
spec:
match:
kinds:
- apiGroups: [""]
kinds: ["Pod"]
scope: Namespaces
parameters:
runAsUser:
rule: MustRunAsNonRoot
runAsNonRoot: true
```
* DCGM + Prometheus + Grafana 监控栈：采集 GPU 利用率、显存使用、温度、PCIe 带宽等指标，按租户 Namespace 聚合展示，设置显存 85% 告警阈值预防 OOM 级联故障
### 技术优缺点与适用场景
* 对比总览（text 树表达）：
```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 树 + 箭头）：
```text
多租户 GPU 隔离部署链路
├── 阶段1: 基础隔离
│ ├── 创建租户 Namespace -> 配置 RBAC
│ ├── 配置 RBAC -> 设置 ResourceQuota + LimitRange
│ └── 验证: kubectl auth can-i --as=team-a-sa list pods -n team-b（应拒绝）
├── 阶段2: GPU 驱动安全加固
│ ├── 钉死 GPU 驱动版本 -> 在 gpu-operator ClusterPolicy 中设置 version
│ ├── 禁用 MPS -> 在 nvidia-device-plugin ConfigMap 中清空 mps.resources
│ └── 验证: nvidia-smi --query-gpu=driver_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 追踪
* 驱动版本钉死配置：
```yaml
apiVersion: nvidia.com/v1
kind: ClusterPolicy
metadata:
name: gpu-cluster-policy
spec:
driver:
enabled: true
repository: nvcr.io/nvidia
image: driver
version: "560.35.03"
operator:
upgradeCRD: true
daemonsets:
updateStrategy: RollingUpdate
```
* CVE 追踪要点：订阅 NVIDIA PSIRT RSS 和 NVD CPE cpe:2.3🅰️nvidia:gpu_driver 提要；CVSS \>= 7.0 的内核模块漏洞视为 P1，72 小时内打补丁，受影响节点立即 cordon + drain
*
#### 避坑经验
* MPS 用于多租户是最常见的致命错误：NVIDIA 文档明确说明 MPS 仅适用于互相信任的 HPC 工作负载。在多租户环境中启用 MPS 消除了故障隔离，一个租户的 CUDA 断言错误可杀死所有共置租户的推理进程
* Namespace 隔离不等于 GPU 隔离：Kubernetes Namespace 是控制面概念，控制 Pod 通信、RBAC 和 NetworkPolicy。它不保护 GPU 显存。/dev/nvidia0 是宿主文件系统上的字符设备，Namespace 边界不阻止一个 Pod 的代码读取另一个 Pod 的 GPU DRAM
* GPU 驱动 CVE 不在 Linux 发行版安全公告中：NVIDIA 驱动是闭源二进制，不通过发行版仓库分发。依赖 OS 厂商安全公告的团队会完全错过 NVIDIA 驱动 CVE。需要独立追踪 NVIDIA 安全公告页面和 NVD
* MIG 分区变更需要 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 工程与安全深度实战](https://blog.csdn.net/a13662080711/category_13180596.html)
* [TypeScript 从入门到精通](https://blog.csdn.net/a13662080711/category_13177147.html)
* [LangChain/LangGraph 从入门到精通](https://blog.csdn.net/a13662080711/category_12977087.html)
* [Rust 从入门到精通](https://blog.csdn.net/a13662080711/category_13177144.html)
### 参考资料
* [Designing multitenant GPU infrastructure: Isolation across virtualization and Kubernetes platforms - Red Hat (2026)](https://www.redhat.com/en/blog/designing-multitenant-gpu-infrastructure-isolation-across-virtualization-and-kubernetes-platforms)
* [GPU Tenant Isolation in Kubernetes: Strategies for AI Cloud Operators - vCluster (2025)](https://www.vcluster.com/blog/gpu-multitenancy-kubernetes-strategies)
* [GPU Shared-Kernel Attacks: Isolation Failures in Multi-Tenant AI Inference Clusters - System Hardening (2025)](https://www.systemshardening.com/articles/ai-landscape/gpu-shared-kernel-ai-isolation/)
* [NVIDIA Multi-Instance GPU (MIG) 技术文档](https://docs.nvidia.com/datacenter/tesla/mig-user-guide/)
* [Kata Containers: Kubernetes workload isolation for secure AI](https://www.thestack.technology/kata-containers-kubernetes-isolation-ai/)
* [HAMi v2.9: Kubernetes as the GPU Control Plane](https://jimmysong.io/blog/kubernetes-gpu-control-plane-hami-v29-ai-infra/)
* [Improve GPU utilization with Kueue in OpenShift AI - Red Hat Developer (2025)](https://developers.redhat.com/articles/2025/05/22/improve-gpu-utilization-kueue-openshift-ai)
* [CVE-2023-0184: NVIDIA GPU Driver Vulnerability - NVD](https://nvd.nist.gov/vuln/detail/CVE-2023-0184)