一句话结论：从 IOMMU（硬件地址翻译与 DMA 隔离）→ VFIO（设备直通框架）→ SR-IOV（PCIe 级切分）→ MIG（硅片级硬切分）→ vGPU（软件时间片调度）这条链路，构成了 GPU 虚拟化的完整技术栈。「IOMMU 划边界、VFIO 做移交」这条直通链路，是所有 GPU 沙盒和具身仿真基础设施绕不开的地基。

本文按「技术原理 → 两大落地场景 → 一个真实落地案例 → 决策树」四层展开，并把各技术支持的功能以表格汇总。

所有技术描述核对自 Linux 内核文档、NVIDIA 官方文档、Intel/AMD 官方文档与各项目仓库。核对中发现原稿有二十余处需要更正，其中三处是实质性错误，已在文中以 ⚠️ 标注。

一、技术原理层：从 IOMMU 到 vGPU

1.1 IOMMU：硬件级安全边界

IOMMU 是提供地址翻译与设备隔离的硬件单元：对设备发出的 DMA 做 IOVA → HPA 翻译与访问保护，并提供中断重映射；隔离以 IOMMU group 为粒度。Intel 侧叫 VT-d，AMD 侧叫 AMD-Vi。

Linux VFIO 内核文档原文：

This includes x86 hardware with AMD-Vi and Intel VT-d…
The IOMMU API therefore supports a notion of IOMMU groups. A group is a set of devices which is isolatable from all other devices in the system. Groups are therefore the unit of ownership used by VFIO.

这部分原理（IOVA 翻译、DMA Remapping、中断重映射、IOMMU group 与 GPUDirect RDMA 的关系）在 x86 体系结构基础 §8 已经讲透，这里不重复。

⚠️ 一处常见混淆：原稿写「BIOS 需开启 intel_iommu=on iommu=pt」。这两个是内核命令行参数，不是 BIOS 开关——BIOS 里开启的是 VT-d/AMD-Vi（IOMMU 硬件本身），内核参数只是让驱动去用它。而且 iommu=pt 不是 VFIO 直通的必需条件：它只是主机侧默认 DMA 行为（让未直通的设备走恒等映射以提升性能），直通给 VM 的设备由 VFIO 单独建立 IOMMU 翻译域，与它无关。kernel-parameters 原文：pt - Use passthrough mode by default (Equivalent to iommu.passthrough=1)。

1.2 VFIO：把设备安全移交给用户态

设备先从原生驱动解绑、再绑定到 vfio-pci，绑定后出现组字符设备 /dev/vfio/$GROUP（$GROUP = IOMMU 组号）；容器设备是 /dev/vfio/vfio。VMM（QEMU / Cloud Hypervisor / crosvm）通过 ioctl 完成 IOMMU 映射、寄存器区域描述、中断注册。

内核文档原文：

By unbinding the device from the host driver and binding it to a VFIO driver, a new VFIO group will appear for the group as /dev/vfio/$GROUP…
The VFIO device API includes ioctls for describing the device, the I/O regions and their read/write/mmap offsets…, as well as mechanisms for describing and registering interrupt notifications.

直通链路：

1
BIOS 开 VT-d/AMD-Vi → 设备解绑原驱动 → 绑定 vfio-pci → VMM 接管 → guest 装原生驱动

⚠️ 安全论断有前提：原稿写「guest 内核即使被攻破也无法通过 GPU 的 DMA 通道越过边界读写宿主机内存」。这个论断成立的前提是 IOMMU group 隔离完整——内核文档明确警告隔离粒度可能被削弱：

a non-PCI-ACS (Access Control Services) capable bridge allowing redirection without reaching the IOMMU

vfio-pci 绑定的是 PCI function 而非整张卡（官方示例分别绑 06:0d.0 与 06:0d.1 两个 function）；多功能卡需逐个绑定，且整个 IOMMU 组内的设备都要处理。

1.3 五种 GPU 虚拟化技术对比

技术方式 切分层级 隔离强度 每卡并发实例 性能损耗 支持热迁移 硬件要求
整卡直通 无切分，整个 PF 给一台 VM ★★★★★ 1 量级最低 ❌ 不支持 任何支持直通的卡 + IOMMU
SR-IOV PCIe function 级，硬件切 ★★★ 网卡 127/端口；GPU 视卡型 量级较低 ❌ 基本不支持 设备支持 SR-IOV + 上游 ACS
MIG 硅片级，硬件切算力/显存/带宽 ★★★★★（硬件强制隔离 + QoS） 最多 7（数据中心卡） 量级较低 ❌ 不支持 仅部分数据中心卡与 RTX PRO Blackwell
MIG-backed vGPU MIG 硬切 + vGPU 软件调度 ★★★★ 最多 12 VM/GPU（RTX PRO 6000 Blackwell） 中等 ✅ 支持（有约束） RTX PRO Blackwell Server Edition 等
vGPU 软件时间片调度 ★★（时间片轮转） 几十至数百 中等 ✅ 支持（部分型号） L40S/L4/A16/RTX PRO Blackwell 等

⚠️ 性能损耗那三个百分比我删掉了。原稿写「整卡直通 <5% / MIG <10% / vGPU 5–15%」——在 NVIDIA 官方文档与内核文档里都找不到这三个数字的一手出处。NVIDIA 官方只给相对值，例如：

at the 48 GB profile size, MIG-backed vGPU delivered 20% higher performance than time-sliced vGPU

这些百分比常见于第三方对比文章与论坛，不是官方数据。上表已改为「量级」表述，需要精确数字请自行实测。

几个关键差异点

MIG 的独有优势是故障隔离和带宽 QoS。 每个 MIG instance 拥有独立的计算引擎、显存控制器、L2 cache、DRAM 地址总线——一个 instance 的故障或吵闹邻居影响不到隔壁，性能可预测性是所有方案中最好的。

MIG 的实例上限按卡型分档（官方 Supported GPUs 表）：

卡型 架构 MIG 实例上限
A100 / H100 / H200 / B200 / GB200 / B300 / GB300 Ampere — Blackwell 7
RTX PRO 6000 Blackwell（Server / Workstation / Max-Q） GB202 4
RTX PRO 5000 Blackwell GB202 2
RTX PRO 4500 Blackwell GB203 2
Thor iGPU GB10B 2

「MIG 支持范围扩大到 RTX PRO Blackwell」属实——这是 2026 年的重要变化，官方 MIG 支持型号表已明确列出这三款 RTX PRO。但要记住它们的上限是 4/2/2，不是 7，这直接影响单卡能切几份的容量规划。

⚠️ +gfx 和 +me 要拆开说。原稿把两者都算作「GB20X 架构的新特性」——只有 +gfx 是新的：

  • +gfx 确实是 Blackwell（RTX PRO / Thor）上出现的新 profile 类型，官方原文：“No graphics APIs are supported, except on +gfx profiles of RTX PRO 6000 Blackwell (all editions), RTX PRO 5000 Blackwell, RTX PRO 4500 Blackwell, and Thor iGPU (technology preview)”，支持 OpenGL 与 Vulkan（含 EGL headless）。
  • +me 不是新特性——A100（R470 驱动起）就有 MIG 1g.5gb+me，H100 也有 1g.10gb+me。

而且官方还有一个分工要注明：「Video encode/decode is set by +me/-me, not +gfx」——编解码归 +me，图形 API 归 +gfx，两者不是一回事。

vGPU 支持多 GPU 聚合。 官方特性就叫 Multi-vGPU：

Multi-vGPU attaches several vGPU devices to one VM. Devices may be time-sliced or MIG-backed and can sit on different physical GPUs — you are not limited to slicing one physical GPU across many VMs.

SR-IOV 的设备生态严重倾斜于网卡。 一张 ConnectX 每端口最多 127 个 VF（官方原文：“NVIDIA ConnectX adapters support up to 127 VFs per port”）。

⚠️ 这条原稿写反了，而且是最严重的一处。原稿写「SR-IOV GPU 侧只在 NVIDIA 数据中心卡（A100/H100/BlueField DPU）上有限开放」——A100 和 H100 恰恰不支持 SR-IOV，它们走的是 MIG。

按 NVIDIA vGPU 的 Validated Platforms 矩阵：

架构 是否支持 SR-IOV 具体型号
Blackwell ✅ RTX PRO 系列
Ada Lovelace ✅ L4 / L20 / L40 / L40S / RTX 6000 Ada
Ampere ✅ A40 / A16 / A10 / A2 / RTX A6000 / A5500 / A5000（不含 A100）
Turing ❌ —

A100 与 H100 的 vGPU 类型页全文 0 次出现 SR-IOV。所以准确的说法是：SR-IOV 开放的是一批图形/专业卡，数据中心计算卡 A100/H100 用的是 MIG。 BlueField DPU 支持 SR-IOV 这点对，但它是网络/DPU 不是 GPU。

热迁移的分裂格局。 SR-IOV 与整卡直通基本不支持（设备 DMA 状态是硬件实态，无法软件打包搬运）。

⚠️ 但 MIG-backed vGPU 的热迁移有强约束，不能只说「支持」。官方原文：

Live migration between different MIG profiles (for example, migrating a VM from a 1g.5gb instance to a 2g.10gb instance) is not supported. The target host must have a matching MIG configuration.

vGPU 热迁移本身也有前提：源/目标主机必须是同型号物理 GPU、相同显存配置/ECC、兼容的驱动与 hypervisor 版本。

另外注意：MIG-backed vGPU 在 A30/A100/A800/H100/H200/B200/B300 上不支持 Windows guest（这些卡上只有 time-sliced vGPU）。

⚠️ ACS 的定位要精确。原稿写「主板 ACS」是 SR-IOV 的前提——ACS 不是 SR-IOV「能工作」的前提（SR-IOV 靠 PF/VF 硬件切分即可运行），而是「VF 能被安全分到独立 IOMMU group 并直通」的前提。Intel 官方把它归入 SR-IOV 与 VT-d 体系：“ACS is part of SR-IOV… part of Intel Virtualization Technology for Directed I/O”。

二、Agent 训练 Sandbox

核心矛盾：RL rollout / 代码执行 sandbox 里跑的是模型自己生成、未经人审的代码——可能被提示注入劫持去读环境变量里的 API key，或者写恶意 CUDA kernel 探测同卡其他进程的显存。传统 Docker/runc 容器共享宿主内核，对这类代码的隔离性被业界明确判定为不够用。

2.1 隔离栈架构

1
2
3
4
5
6
7
8
9
Agent 框架（LangGraph / OpenHands / 自研 harness）
        ↓ 调用 run_code() 工具
   容器层（只是打包，不承担安全边界）
        ↓
  microVM 层（真正的隔离边界）
  ├─ Firecracker：纯 CPU 场景
  └─ QEMU/KVM 或 Cloud Hypervisor + VFIO：需要 GPU 的场景
        ↓ VFIO 直通
     物理 GPU / MIG slice / vGPU

2.2 主流隔离技术对比

隔离技术 隔离原理 启动时间 性能开销 GPU 直通 典型场景
Docker/runc 命名空间 + cgroups，共享宿主内核 数十毫秒量级 量级最低 ✅ nvidia-container-toolkit 可信代码、内部开发环境
gVisor 用户态内核（Go）拦截 syscall 量级较低 I/O 密集场景明显 ✅ 通过 nvproxy（见下） CPU-bound 或轻量 CUDA
Firecracker Rust microVM，KVM 硬件隔离，每 workload 独立内核 ≤125 ms >95% 裸机性能 ❌ 无 GPU/PCI 直通 无 GPU 的 agent 代码执行
Kata Containers K8s 集成，pod 跑在 VM 内 未找到官方数字 量级中等 ✅ 通过 QEMU/CH 支持 VFIO K8s 环境下微服务 + GPU 混合负载
QEMU/KVM 完整虚拟化，VFIO 直通最成熟 未找到官方数字 未找到官方数字 ✅ 最成熟 GPU sandbox、需要完整 guest OS
Cloud Hypervisor Rust 轻量 VMM，云原生设计 <100 ms 未找到官方数字 ✅ 支持 新型 microVM + GPU 场景

⚠️ 启动时间与开销那一列，只有两条有一手来源：

数字 来源
Firecracker ≤125 ms 官方 SPECIFICATION.md：“It takes <= 125 ms to go from receiving the Firecracker InstanceStart API call to the start of the Linux guest user-space /sbin/init process.”（注意这是 VMM 启动不是完整 OS boot；VMM 进程本身 “within 8 CPU ms”）
Firecracker >95% 裸机性能 同页：CPU 性能 “> 95% of the equivalent bare-metal performance”
Cloud Hypervisor <100 ms 官网：“Boot to userspace in less than 100ms with direct kernel boot”

其余（Docker ~50ms、gVisor 50–100ms、Kata 150–300ms、QEMU/KVM 1–3s、以及那几个开销百分比）都找不到官方一手来源，属常见二手估值。上表已改为「量级」表述。

⚠️ 两处必须更正：

其一，「Firecracker 无 PCI 总线」已过时。 原稿说它「设备模型仅 virtio-over-MMIO，无 PCI 总线」。新版 Firecracker 有 virtio-PCI 传输，官方 docs/device-hotplug.md 原文：“PCI transport enabled: Firecracker must be started with the --enable-pci flag.”，并进入 PCIe 热插拔 Developer Preview（支持 virtio-block / pmem / net）。「Firecracker 无 GPU 直通」仍然成立（无 VFIO/PCI passthrough），但理由是「不支持 PCI 设备直通」而不是「没有 PCI 总线」。

其二，「gVisor 与 GPU 直通互斥」是错的。 见下节。

gVisor 的 GPU 支持：nvproxy

⚠️ 这是原稿最实质的一处错误。它写「gVisor 在用户态拦截 syscall，会阻断 PCIe 直通所需的 DMA 映射路径」，据此判定 gVisor 与 GPU 互斥。不属实。

gVisor 官方有专门的 GPU 支持文档：

gVisor supports running most CUDA applications on preselected versions of NVIDIA’s open source driver. To achieve this, gVisor implements a proxy driver inside the sandbox, henceforth referred to as nvproxy. nvproxy is a passthrough driver that forwards ioctl(2) calls made to NVIDIA devices by the containerized application directly to the host NVIDIA driver.

官方支持的 GPU：T4、A100、A10G、L4、H100（共 5 款型号、4 个微架构——Turing / Ampere / Ada Lovelace / Hopper）。支持 Docker --gpus、NVIDIA k8s-device-plugin、CDI、GKE device plugin。

所以准确的表述是：gVisor 不做 PCIe/VFIO 直通（不把物理 PCI 设备透传给 sandbox），但并非与 GPU 互斥——它靠 nvproxy 转发 NVIDIA 驱动的 ioctl 来跑 CUDA。而且 DMA 映射是宿主 NVIDIA 驱动做的，nvproxy 只转发 ioctl，所以「阻断 DMA 映射路径」这个因果也不成立。

⚠️ 另一处旧认知要修正：nvproxy 支持 Vulkan（不是「只转发计算类 ioctl」）。官方原文：“gVisor also supports Vulkan and NVENC/NVDEC workloads”，driver capability 里明确含 graphics。

真正的缺口在设备文件：nvproxy 只暴露 /dev/nvidiactl、/dev/nvidia-uvm、/dev/nvidia#，不暴露 /dev/nvidia-drm、/dev/nvidia-modeset、/dev/nvidia-caps/*。所以 Isaac Sim 这类依赖完整显示/DRM 管线的图形栈确实跑不了——但理由不是「不支持图形 API」，而是「不暴露 DRM/modeset 设备节点」。

nvproxy 的版本耦合是长期运维负担。 官方文档讲得很直白：

the lack of ABI stability guarantees in NVIDIA’s KMD, meaning ioctl definitions can change arbitrarily between releases… nvproxy must understand the ABI for each supported driver version, necessitating internal versioning logic for ioctls.

The range of officially supported driver versions directly aligns with those available within GKE. As GKE incorporates newer drivers, nvproxy will extend support accordingly. Conversely, to manage versioning complexity, nvproxy will shrink the window as drivers are removed from GKE.

查当前支持列表用 runsc nvproxy list-supported-drivers（版本清单硬编码在源码 pkg/sentry/devices/nvproxy/version.go）。runsc 是严格版本匹配，可用 --nvproxy-driver-version 强制指定但官方标注 “not officially supported”。

⚠️ 关于新卡与多卡，两处措辞要收：

新卡：官方只承诺「与上述相同微架构的其他 GPU 可能可用」（举例 RTX 3090/4090）。所以 L40S（Ada，与 L4 同架构）落在「可能可用」范围内；而 B200、RTX PRO 6000 Blackwell 属 Blackwell，不在已支持的四个微架构之列——文档对它们没有任何「可能工作」的承诺。原稿说三者都「可能工作但不被支持」，对 Blackwell 卡属无依据推断。

多卡 NCCL：原稿说「需要实测」。文档正文确实没提 NCCL，但 gVisor 的 CI 已经在跑多卡 NCCL 测试——test/gpu/nccl_test.go 覆盖 all_reduce_perf / all_gather_perf / alltoall_perf 等，且 pkg/test/dockerutil/gpu.go 用 Count: -1 请求全部 GPU。所以「需要实测」作为工程建议成立，但说「未验证」不准确。

2.3 主流 Agent Sandbox 平台

平台 底层隔离 GPU 支持 部署模式 特殊能力
E2B Firecracker microVM ❌ 托管版、OSS、BYOC 全部 CPU-only 托管云 + BYOC + 自托管 开源（Apache-2.0）运行时
Modal gVisor（另有 VM 运行时） ✅ 自有 GPU 池（T4/L4/A10/L40S/A100/RTX-PRO-6000/H100/H200/B200/B300） 托管云 GPU Sandbox 仅支持 runtime="gvisor"
Daytona 默认 Linux 容器（namespace），可选 VM sandbox ✅ NVIDIA + AMD 托管 + 自托管 持久化、快照、多语言 SDK
Northflank CPU = microVM；GPU = gVisor ✅ 有条件 托管云 K8s 原生集成
CodeSandbox Firecracker microVM 有限 托管 内存快照、fork、web preview

⚠️ 三处更正：

其一，E2B 的 GPU 情况比原稿更严格。 原稿写「托管版不支持（Firecracker 限制），OSS 版可自建」——这个说法有误导性。E2B 官方 FAQ 原文：

No. E2B sandboxes are CPU-only, sized by vCPU and RAM only, with no GPU option in the SDKs, CLI, API, or a template definition. BYOC does not change this, because BYOC sandboxes are created through the same API.

而且底层 Firecracker 本身就没有 GPU 直通，「自建」也拿不到 GPU 支持。上表已改为「托管版、OSS、BYOC 全部 CPU-only」。

其二，Daytona 底层不是 gVisor。 官方文档写的是 “Sandboxes run as Linux containers by default”，另有 VM sandbox 与 GPU sandbox；隔离页只描述三类边界（Container / VM / GPU），全文未出现 gVisor/Kata/Firecracker。

其三，「唯一开源 Apache-2.0 运行时」不成立——gVisor、Kata、Firecracker、Cloud Hypervisor 都是 Apache-2.0。

两处原稿说对了、值得保留：Northflank 官方口径确实是「Managed CPU sandboxes use microVMs, while GPU sandboxes use gVisor」（不过 CPU 侧官方没钉死在 Kata，Firecracker 也在选项内）；Modal 官方明确 “GPU Sandboxes are only supported with runtime=“gvisor””。

关键坑点：

  • Firecracker 不支持 volume_mounts 是 virtio 设备模型的限制 ✅。它的设备模型只有 virtio-block / vhost-user-block / virtio-pmem / virtio-net / virtio-vsock / virtio-rng / virtio-mem，没有 virtio-fs 也没有 9p——即不支持共享目录式挂载。官方 design.md：“Firecracker emulated block devices are backed by files on the host. To be able to mount block devices in the guest, the backing files need to be pre-formatted…”
  • VFIO 直通 VM 的内存需要 pin/mlock ✅（机制对），但不是「全部内存」——只有被映射进 IOMMU 的 guest RAM 需要 pin，用 hugepage 是标准可配置项。而且「一张 H100 起步几十 GB 锁定内存」找不到权威来源——需要 pin 的是 guest 侧 RAM，由 VM 配置的内存大小决定，与 GPU 型号无关（H100 的 80GB HBM 不占 host RAM）。
  • 普通 nvidia 容器的隔离模型 ✅：NVIDIA Container Toolkit 把宿主设备节点与驱动用户态库注入容器，容器内 CUDA 应用通过 ioctl 直接走宿主 NVIDIA KMD，driver 攻击面巨大。gVisor 需要 nvproxy 正是因为这种「直连宿主驱动」的默认模型没有隔离。

三、具身仿真场景

具身仿真同时压榨三条 GPU 负载路径，而它们对 GPU 的需求形态完全不同：

  • 物理引擎层 —— Isaac Sim 的 PhysX、Genesis 的多求解器耦合、MuJoCo 的 GPU 后端：纯计算密集，不需要 RT Core，吃算力和显存带宽；
  • 渲染管线层 —— Isaac Sim 的 RTX 渲染器、传感器仿真：强依赖硬件光追单元；
  • 并行环境层 —— Isaac Lab 的向量化环境、ManiSkill3 的 GPU 并行：决定显存占用规模。

这形成一个残酷约束：最强的训练卡恰恰渲染不了，最擅长渲染的卡计算密度又不如 H100。

3.1 仿真器对比

仿真器 物理引擎 渲染引擎 GPU 加速 RT Core 依赖 单卡 FPS / 并行环境数 典型硬件
Isaac Sim/Lab PhysX（GPU）+ Newton（新增，集成 MuJoCo Warp） RTX（硬件光追） ✅ ✅ 必需 数千 envs/GPU，基准用到 4096/8192 num_envs RTX 4080+（最低 16GB VRAM）、L40S、RTX PRO 6000
Genesis Taichi 编译多求解器（刚体/柔体/流体/MPM/IPC） Nyx 光栅化 ✅ CUDA ❌ 43M FPS（见下方口径说明） RTX 4090 等消费级
MuJoCo 自研 可选（OpenGL/EGL/OSMesa） ✅（MJX） ❌ 中等 CPU 也能跑，GPU 加速可选
ManiSkill3 SAPIEN（GPU 并行） SAPIEN 并行渲染 ✅ ❌ 30,000+ FPS，比同类省 2–3 倍显存 消费级卡即可
Habitat-Sim Bullet（CPU）+ GPU 渲染 OpenGL/EGL ✅ 渲染加速 ❌ 10,000+ FPS（多进程单 GPU） 中端 GPU
CoppeliaSim 多引擎可切换（MuJoCo/Bullet/ODE/Newton/Vortex） 内置 部分 ❌ 中等 CPU/GPU 均可

⚠️ Isaac Sim 的 RT Core 清单要收一收。原稿写「官方明确标注：没有 RT Core 的 GPU（A100、H100、H20）不受支持」。官方 Requirements 文档原文只点了两款：

GPUs without RT Cores (A100, H100) are not supported.

H20 只出现在 NVIDIA 官方开发者论坛的 NVIDIA 员工回复里，未进正式产品文档。说「官方明确标注 H20」不准确。

⚠️ Genesis 的 43M FPS：数字属实，但口径必须写清。原稿写「数千万 FPS（RTX 4090 单场景）」——「单场景」这个措辞容易误导。

官方项目页原文：“When simulating a manipulation scene (with a single plane and a Franka arm), Genesis runs at 43 million FPS, which is 430,000 times faster than in real time.”

关键限定：

  1. 这个数字依赖 GPU 并行批量环境 + 碰撞检测优化 + auto-hibernation + contact island，不是单环境串行 FPS；
  2. 第三方基准指出：开启随机动作后同场景降到约 27M FPS；单个隔离环境串行只有几千 FPS，和 MuJoCo 差不多；
  3. 该句原文未标注 GPU 型号——「RTX 4090」是二手转述；
  4. 新版 README 已不再出现该数字。

正确口径是「单场景 + 数千并行环境批量吞吐下达 43M FPS」。

另外两条口径也要注明：ManiSkill3 的 30,000+ FPS 是 RGBD + 分割数据采集口径（非纯物理）；Habitat-Sim 的 10,000+ FPS 是多进程单 GPU 渲染口径（非单进程）。

Isaac Lab 的 Newton 后端属实 ✅：官方文档描述 Newton 是 “a GPU-accelerated, extensible, differentiable physics simulation engine… built on NVIDIA Warp and integrates MuJoCo Warp”，由 Disney Research、Google DeepMind 与 NVIDIA 共同维护，可通过 SimulationManager.switch_physics_engine("newton") 切换。

3.2 具身场景 GPU 虚拟化选型矩阵

方案 物理仿真 RTX 渲染 多环境并行 典型卡型 适用度
整卡直通 ✅ 满速 ✅ 满速 1 卡 1 实例 RTX PRO 6000、L40S、GeForce ★★★★★ 单环境/高质量渲染
MIG ✅ 硬隔离 ❌ A100/H100 无 RT Core 每卡最多 7（RTX PRO 为 4/2/2） A100/H100/H200/B200 ★★★ 训练侧首选，渲染弱
MIG-backed vGPU ✅ ✅ RTX PRO Blackwell 有 RT Core + +gfx 最多 12 VM/GPU RTX PRO 6000 Blackwell Server ★★★★ 云端高密度混合负载
SR-IOV ⚠️ 数据中心卡不支持（走 MIG） ⚠️ 看卡型 — RTX PRO / Ada / A10/A16/A40 ★ 具身场景用得少
vGPU ✅ ✅ L40S/L4 有 RT Core 单卡几十实例 L40S、L4、RTX PRO ★★★★ 云端多租户仿真

⚠️ 表中 SR-IOV 那一行按 §1.3 的更正调整了——A100/H100 走 MIG 不走 SR-IOV。

2026 年的重要变化：RTX PRO 6000 Blackwell 同时支持 MIG 和硬件光追（+gfx profiles），首次打破了「MIG = 无渲染」的约束，让「训练 + 渲染统一」的单卡方案成为可能。

架构选择的分水岭：

  • 纯训练（可信代码、追求吞吐） → 单机多进程直通共享。RL 训练代码是自己写的，不需要硬件隔离，零虚拟化开销；
  • 评测 benchmark / 多用户共享 / 跑模型生成的代码 → microVM + MIG/vGPU 切分；
  • Sim2Real 部署前的最后验证 → 整卡直通，避免任何共享带来的时延抖动影响控制频率。

四、一个真实落地案例：四模板架构及其复盘

这一节是一个真实落地形态的复盘。架构本身的完整描述见 Agent 沙盒基础设施实践 的 §3.12。

4.1 四个模板

模板 后端 隔离边界 适用场景
cpu-* AgentENV + Firecracker microVM 独立内核 通用命令与工具；需要「暂停后进程还在」
gpu-light-* gVisor + nvproxy Sentry 拦截 + 宿主内核 CUDA / Ray 等轻量算子——不是渲染沙盒
vm-* Kata（独立内核） VM 独立内核 需要特定 Linux 行为、又不需要 GPU
render-* 普通 NVIDIA 容器，sandbox: false 仅 namespace / cgroup Isaac 等图形栈仿真

方案整体是可行且务实的——它准确接受了三个现实约束（Firecracker 不支持 GPU、gVisor 撑不住完整渲染栈、Isaac 没有真正的沙盒方案），并且诚实地把 render-* 标注为 sandbox: false，这比很多团队硬把 Docker 当 sandbox 用要诚实得多。

4.2 逐项对照技术现状

模板 技术现状对照 评价
cpu-* Firecracker 不支持 volume_mounts 属实（无 virtio-fs / 9p，块设备需宿主预格式化文件做后端），用 /workspace 替代是合理规避 ✅ 描述准确
gpu-light-* nvproxy 支持 5 款 GPU / 4 微架构（T4/A100/A10G/L4/H100）；支持 Vulkan 与 graphics capability，但不暴露 /dev/nvidia-drm、/dev/nvidia-modeset ✅ 「不是渲染沙盒」的判断正确，但理由要改（见下）
vm-* Kata 支持 VFIO GPU 直通（cold-plug 模式，NVIDIA reference stack），所以「无需 GPU」不是 Kata 的技术限制，而是当前方案有意简化的选择 ⚠️ 描述有简化
render-* 普通 nvidia 容器共享宿主 NVIDIA KMD，driver 攻击面巨大 ✅ 定性诚实，但边界需明确

⚠️ gpu-light-* 那一行的理由要改。原方案说它「不是渲染沙盒」是因为「gVisor 的 GPU 支持只覆盖轻量 CUDA 算子」——这个理由不准确。nvproxy 支持 Vulkan，真正的缺口是不暴露 /dev/nvidia-drm 与 /dev/nvidia-modeset，所以跑不了完整的显示/DRM 管线。结论不变，理由要换。

4.3 四个值得推敲的点

其一，render-* 的安全边界需要显式分层，不能只是一个 sandbox: false 标签。

普通 nvidia 容器的隔离模型是：应用通过 ioctl 直接调用宿主 NVIDIA kernel driver，driver 攻击面巨大。这里需要明确回答一个问题：render-* 是只跑团队自己写的评测代码，还是也会跑 agent rollout 生成的代码？

  • 如果只是前者 → 定位合理；
  • 如果是后者 → 当前方案在安全上有硬伤。至少要叠加 seccomp、user namespace、egress allowlist；更彻底的路径是给 render 任务配 Kata + VFIO 整卡直通，或者接受「每台物理机单任务」的成本。

一个务实的折中是：把 render-* 进一步切分为 render-trusted（团队代码）与 render-untrusted（模型生成代码），后者走 Kata GPU 直通或独立物理机。

其二，nvproxy 的版本锁定是长期运维负担。

如 §2.2 所述，nvproxy 的驱动版本支持窗口直接跟随 GKE 滚动。这意味着：

  • host 驱动升级必须与 gVisor 版本严格对齐，否则 sandbox 启动直接失败；
  • 集群里混用新卡（L40S、RTX PRO 6000 Blackwell、B200），Blackwell 卡完全不在支持范围内（L40S 因与 L4 同属 Ada 而落在「可能可用」区间）。

建议把版本耦合写进运维文档，锁死驱动版本 + 定期验证升级路径，避免「host 打了安全补丁 → gVisor 不认识 → 所有 gpu-light-* 模板挂掉」这种连锁故障。

其三，vm-* 用 Kata 的理由应该更精确。

Kata 和 Firecracker 都是独立内核的 VM，真正的差异是：

Firecracker Kata
启动 ≤125ms（官方数字） 官方未给数字，量级更大
K8s 集成 需自建 RuntimeClass 原生、OCI 兼容
底层 VMM 固定 可插拔（QEMU / Cloud Hypervisor / Firecracker / Dragonball）
GPU 直通 ❌ ✅ VFIO，cold-plug 模式

所以 vm-* 的选型理由应该是「需要 K8s 生态集成、需要 OCI 兼容性、需要 systemctl/dkms 这类特定内核行为」，而不是单纯的「独立内核」。如果哪天需要跑「不可信代码 + GPU」，Kata + VFIO 是现成的升级路径——这个空间应该被预留出来。

其四，沙盒等级应该量化标注，而不是只有 true/false。

四个模板的实际隔离强度差距很大，建议在 API 响应里加一个 isolation_level 字段：

模板 隔离原理 隔离等级建议
cpu-* Firecracker 硬件虚拟化，独立内核 L3（VM 级）
gpu-light-* gVisor 用户态内核 + nvproxy ioctl 白名单 L2（Sentry 拦截）
vm-* Kata VM 独立内核 L3（VM 级）
render-* 共享 host 内核，共享 NVIDIA KMD L1（仅命名空间）

上层 agent 框架拿到 isolation_level 后就能做策略路由——reward hacking 检测类任务强制 L3、内部工具调用 L2 即可、可视化评测 L1 警告但不阻断。没有量化等级，上层就只能在「是沙盒/不是沙盒」之间做二元决策，粒度太粗。

4.4 还缺什么

其一，多 GPU / 分布式 GPU 训练。 nvproxy 的多卡支持实际上 CI 已覆盖（见 §2.2），但生产规模仍需实测。另一条路是 Kata 的多 GPU 直通——官方文档逐字给出了这个能力：

If you have machines supporting multi-GPU passthrough, use a pod deployment manifest which uses 8 pgpu and 4 nvswitch resources. On the NVIDIA Hopper architecture multi-GPU passthrough uses protected PCIe (PPCIE) which claims exclusive use of the nvswitches for a single CVM… The NVIDIA Blackwell architecture uses NVLink encryption which places the switches outside of the Trusted Computing Base (TCB)…

即 8 张 GPU + 4 颗 NVSwitch 作为一个直通单元（4 颗 NVSwitch 对应 H100/Hopper 机型；HGX A100 是 6 颗）。方案里目前没有对应模板。

其二，Isaac Lab headless 训练场景。 Isaac Lab 支持纯物理仿真模式（不需要 RTX 渲染），这种任务理论上可以走 gpu-light-*（CUDA-only）。如果实测通过，可以显著降低 agent rollout 的隔离风险——只有需要传感器仿真/可视化的任务才落到 render-*。

其三，快照/暂停能力的统一定义。 cpu-* 支持暂停恢复（E2B 官方数字：暂停约 4 秒/GiB RAM、恢复约 1 秒），其他三个模板呢？gVisor/Kata/普通容器的快照能力都弱于 Firecracker，上层如果假设「所有模板都能 pause/resume」，会在 gpu-light-* 和 render-* 上翻车。

⚠️ 顺带更正一处数字：原稿写「E2B Firecracker 快照恢复 5-30ms」——这个数字错了 2–3 个数量级。E2B 官方文档给的是：

Pausing a sandbox takes approximately 4 seconds per 1 GiB of RAM. Resuming a sandbox takes approximately 1 second.

状态保留那半是对的：“both the sandbox’s filesystem and memory state will be saved.”

4.5 一个补充：CVE-2026-103916

原稿提到「Docker Sandboxes 近期还爆出 CVE-2026-103916 符号链接逃逸」。这个 CVE 真实存在（我一开始怀疑是编造的，查了 NVD 后确认不是）：

字段 值
描述 Docker Sandboxes sbx cp 未把宿主侧路径安全限制在共享工作区内，恶意沙盒可创建/替换 workspace 符号链接，使后续用户发起的拷贝读出工作区外的宿主文件、或以调用者权限写入工作区外的宿主路径
弱点 CWE-59（Link Following）
发布 2026-11-03，sourceIdentifier security@docker.com
CVSS 4.0 8.4（HIGH）
受影响版本 >= 0.28.0, < 0.51.0
修复版本 v0.51.0

⚠️ 另外，「NVIDIA Isaac OS 的 SECURITY.md 警告」出处也对不上。不存在叫「Isaac OS」的产品（NVIDIA 侧是 Isaac Sim / Isaac ROS / Isaac Lab），而且各 Isaac 仓库的 SECURITY.md 都是 NVIDIA PSIRT 标准模板，不含该警告。

那句警告语义等价但措辞不同的版本确实存在，位置在 Isaac Sim 的容器安装文档里：

Warning: Isaac Sim and the web viewer are designed for use on private/trusted networks. They do not include authentication or encryption. If you need to expose them over the Internet, add a reverse proxy with HTTPS/TLS and authentication…

引用时指向这个出处即可。

五、选型决策树

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
需要跑不可信代码吗？
├─ 否（纯自研训练代码）
│   └─ 单机多进程直通共享（Docker + nvidia-container-toolkit）
│       性能最高，零隔离开销
│
└─ 是
    ├─ 需要 GPU 吗？
    │   ├─ 否
    │   │   └─ Firecracker microVM（≤125ms 启动，硬件隔离，成本最低）
    │   │
    │   └─ 是
    │       ├─ 代码危险等级高（红队 / reward hacking 检测）
    │       │   └─ 整卡直通（QEMU/KVM + VFIO）
    │       │
    │       ├─ 大规模 RL rollout（可信度中等）
    │       │   ├─ 物理仿真为主 → A100/H100/H200/B200 MIG 切分
    │       │   ├─ 渲染 + 仿真混合 → RTX PRO 6000 Blackwell MIG-backed vGPU
    │       │   └─ 仿真器是 Genesis/ManiSkill → 消费卡集群
    │       │
    │       └─ 多用户共享教学 / 平台服务
    │           └─ L40S vGPU（有 RT Core + 云端实例充足）
    │
    └─ K8s 原生环境
        └─ Kata Containers + QEMU/Cloud Hypervisor
            RuntimeClass 集成，底层支持 VFIO

六、趋势

训练卡与渲染卡的边界开始模糊。 RTX PRO Blackwell 的 +gfx profiles 让单卡既能硬件切分（MIG）又能跑光追，B200/GB300 的 MIG profiles 也在持续扩展。未来「训练用 H100、渲染用 L40S」的双卡异构架构可能会被单卡统一方案逐步替代，但当前采购成本仍然极高。

Agent sandbox 生态在快速分化。 E2B 开源 Firecracker 运行时、Modal 用 gVisor 挂自有 GPU 池、Northflank 混合 microVM + gVisor，各家都在试探「隔离强度 × GPU 支持 × 成本」这个三角的不同顶点。NVIDIA 的 Open Agent Safety Platform 这类硬件级方案也开始入场（核心组件含 NVIDIA OpenShell 开源运行时与跑在 BlueField-4 上做 in-silicon 策略执行的 NVIDIA Sentry）。

下一代隔离层在酝酿。 Edera 这类容器原生 Type 1 hypervisor 试图消除共享内核风险而不引入 VM 开销。注意它的数字有两套口径：官方博客写「300ms container start times」，而它自己的论文（arXiv:2501.04580）给的是 “a 648 millisecond increase in startup time from Docker’s 177.4 milliseconds”（约 825ms）——引用时宜注明。

但无论上层怎么变，「IOMMU 划边界、VFIO 做移交」这条直通链路，都是所有 GPU sandbox 和具身仿真基础设施绕不开的地基。

附录：术语速查表

术语 全称 一句话定义
IOMMU Input-Output Memory Management Unit 硬件 DMA 地址翻译与隔离单元；Intel 叫 VT-d，AMD 叫 AMD-Vi
VFIO Virtual Function I/O Linux 内核把物理设备安全移交给用户态/虚拟机的框架
PF Physical Function SR-IOV 中的完整物理设备，拥有全部配置能力
VF Virtual Function SR-IOV 中由 PF 切出的轻量虚拟设备，有独立 Routing ID
MIG Multi-Instance GPU NVIDIA 的硅片级硬件切分技术
vGPU Virtual GPU NVIDIA 基于软件时间片调度的 GPU 共享方案
nvproxy — gVisor 的 NVIDIA 驱动代理，把容器内 ioctl 转发给宿主驱动
ACS Access Control Services PCIe 拓扑的 P2P DMA 隔离机制，是 VF 安全直通的前提
IOVA I/O Virtual Address 设备使用的虚拟地址，由 IOMMU 翻译为物理地址
microVM Micro Virtual Machine 轻量级虚拟机，毫秒级启动
VMM Virtual Machine Monitor 虚拟机监视器，即 hypervisor

相关阅读

核实说明：本文核对自 Linux 内核文档（VFIO、DMA-API、x86 IOMMU、kernel-parameters）、NVIDIA 官方文档（MIG User Guide 的 Supported GPUs / Profiles / Deployment Considerations、AI Enterprise 的 MIG-Backed vGPU / Multi-vGPU / Live Migration、vGPU Validated Platforms）、Intel ACS 说明、AMD ROCm IOMMU 文档、gVisor GPU 支持文档与源码、Firecracker SPECIFICATION/FAQ/device-api/device-hotplug、Kata Containers NVIDIA GPU passthrough 文档、E2B 官方文档与 FAQ、Modal/Daytona/Northflank/CodeSandbox 官方文档、各仿真器官方仓库与论文、NVD 的 CVE-2026-103916 记录。

原稿更正汇总：SR-IOV 的型号清单写反了（A100/H100 不支持 SR-IOV，走 MIG；SR-IOV 开放的是 Blackwell RTX PRO / Ada / Ampere 的 A10/A16/A40 等图形专业卡）、+me 不是 GB20X 新特性（A100 R470 起已有，只有 +gfx 是新的）、性能损耗三个百分比无官方来源、MIG-backed vGPU 热迁移有强约束（目标机 MIG 配置需匹配、跨 profile 不可迁）、ACS 是安全直通的前提而非 SR-IOV 本身的前提、intel_iommu=on iommu=pt 是内核参数不是 BIOS 开关且 pt 非必需、「gVisor 与 GPU 互斥」是错的（nvproxy 支持 GPU，且支持 Vulkan，真正缺口是不暴露 DRM/modeset 设备文件）、nvproxy 是 5 款卡 / 4 微架构（不是「四种卡」）、E2B 快照是 4s/GiB 暂停 + 1s 恢复（不是 5-30ms）、E2B 的 OSS/BYOC 同样 CPU-only、Daytona 底层不是 gVisor、Firecracker 已有 PCIe（--enable-pci，Developer Preview）、「唯一 Apache-2.0」不成立、Genesis 43M FPS 的口径是「数千并行环境批量吞吐」、Edera 的 300ms 是营销口径（论文为 648ms 增量）、「Isaac OS SECURITY.md」出处错（警告实际在 Isaac Sim 容器文档）、H20 未进 Isaac 官方 Requirements 文档、Kata 150-300ms 与若干开销百分比无一手来源。

两处核实为正确并保留：RTX PRO 6000/5000/4500 Blackwell 确实支持 MIG（上限 4/2/2）、Kata 的多 GPU 直通确实是「8 pgpu + 4 nvswitch」一个单元、CVE-2026-103916 真实存在（CWE-59，CVSS 8.4）。