一句话结论：具身智能公司的仿真主力沙盒应当是「裸金属容器 + K8s GPU 调度」，而不是 DSec / AgentENV 那套 Firecracker microVM 层。只有轻量 Agent 工具调用和不可信代码执行才下沉到 microVM。这不是对多级运行时架构的否定，而是该框架在具身场景下的正确映射——仿真吃的是 NVIDIA 专有计算栈，而虚拟化层的 GPU 转发方案恰恰覆盖不到这里。

这篇是 Agent 沙盒基础设施实践：从 DSec 与 AgentENV 看调度层的选型与落地 的延伸。那篇里有一节（§3.5）讲具身仿真的 GPU 路线，结论是「虚拟化不是默认选项」；本文把那个结论展开成一份完整的选型依据——为什么 microVM 接不住仿真、虚拟化 GPU 的四条路径各自能到哪、以及三层负载该怎么分别匹配。

一、为什么这不是一个「通用沙盒」问题

讨论的对象是一类典型的具身智能公司：自研端到端具身大模型，部署轮式双臂仿人机器人与高自由度灵巧手，自建数据工厂沉淀了数万小时多模态具身数据集，机器人已规模化进入真实家庭。

这个形态决定了基础设施要同时承载三类性质完全不同的负载：

负载 形态 隔离需求 资源画像 生命周期
大规模 RL 仿真训练 数千并行环境跑 Isaac Lab / MuJoCo Warp / Genesis 低（跑的是自己的代码） GPU 密集，单进程吃整卡 小时到天
数据工厂流水线 真机数采 → 标注 → 仿真回放 → 模型训练 低 高吞吐 I/O + GPU 持续
真机部署与数据回流 家庭场景机器人持续回传数据、迭代模型 中（设备接入） 异构边缘资源 长期

三类负载的隔离强度、资源形态、生命周期没有一处是重合的。这就是为什么「找一个统一沙盒承载一切」从一开始就是错的问题设定——后面第五节会回到这一点。

仿真层的硬约束

仿真这一层的要求最明确，也最容易被误判：

Isaac Sim 官方要求 GPU 必须带 RT Core，明确声明无 RT Core 的卡（A100、H100）不被支持，最低配置是 RTX 4080 16GB。这不是「推荐配置」，是硬性门槛。

Isaac Lab 3.0 虽然增加了 kit-less 的 Newton 物理路径以摆脱 Isaac Sim 依赖，但官方尚未为这条路径发布独立硬件清单——在数据中心卡上跑之前需要自行实测，不能默认它能绕开 RT Core 要求。

其余两个主流选择同样压在 NVIDIA 栈上：

  • MuJoCo Warp 把整个仿真内循环写成 GPU 常驻计算，依赖 CUDA kernel；
  • Genesis（CMU / Stanford 系）用 Taichi + CUDA 后端，设计目标就是从单机笔记本内核扩展到数据中心 GPU。

这些栈全部压在 NVIDIA 专有计算上——CUDA、PhysX、RT Core、Taichi CUDA kernel。而虚拟化层的 GPU 转发方案，恰恰覆盖不到这里。

二、虚拟化层 GPU 转发的真实边界

这是选型最容易踩的坑，需要先把四条路径的边界说清楚。

2.1 virtio-gpu 只是图形 API 翻译，不是 CUDA 直通

virtio-gpu 的两种模式——Venus 和 VirGL——都是图形 API 翻译层：

  • Venus 是 Vulkan 命令序列化协议；
  • VirGL 翻译 OpenGL；
  • 宿主侧由 virglrenderer 把命令转到宿主 GPU 的图形 API。

问题在于宿主驱动的要求。Venus 要求宿主驱动提供 Vulkan 1.1 加一堆扩展，而 Mesa 官方文档明确指出「不保证在所有满足要求的驱动上都能工作」，且只测试过 ANV（Intel）和 RADV（AMD）——NVIDIA 专有驱动根本不在列。社区实测反馈是「复杂应用会崩溃」，作为日常训练基础设施的稳定性完全不够。

所以：Isaac Lab 的 OptiX 渲染、PhysX GPU 加速、MuJoCo Warp 的 CUDA 内核，在 virtio-gpu 下一律走不通。 这不是性能打折的问题，是根本跑不起来。

2.2 vGPU 时间片没有隔离保证

一个常见的误解是把「时间片提利用率」和「时间片做隔离」当成同一件事。NVIDIA 官方文档写得很直白：

Unlike Multi-Instance GPU (MIG), there is no memory or fault-isolation between replicas.

时间片只是把多个负载交织调度，一个负载 OOM 或 crash 会波及其他副本。对 RL 仿真而言，rollout 崩溃重试的代价可以接受，所以时间片在仿真层提利用率是可用选项；但做隔离不可用——这个区分必须在选型时说清楚。

2.3 MIG-backed vGPU 才是真正的硬件隔离

每个 vGPU 跑在 MIG 实例上，计算核、显存、编解码引擎独占。代价有三个：

  • MIG 划分是静态的，创建后不能动态调整；
  • 粒度粗（A100 最多 7 份）；
  • 切分后的实例不一定能跑 Isaac Sim 类渲染负载——RT Core 的可用性取决于切分方式。

所以这是「强隔离 + 想保留 VM 形态」时的唯一 GPU 选项，但代价要先算清楚。

2.4 VFIO 整卡直通：保留 VM 形态的另一半选项

每 VM 独占一张物理 GPU，通过 VFIO 直通进 QEMU / Kata。收益是接近裸金属的性能和完整的 NVIDIA 栈支持；成本是 GPU 密度骤降——一张卡只服务一个 guest。

只对多租户、强隔离、且必须保留 VM 形态的场景考虑。

三、方案对比

把五条路径摆在一起：

方案 GPU 密度 启动/恢复 隔离强度 适合的负载 具身仿真适配度
裸金属容器（K8s + DRA / 设备插件） 最高（可整卡可切片） 秒级 容器级（namespaces / cgroups / SELinux） Isaac Lab / MuJoCo / Genesis 仿真、RL 训练、数据流水线 ⭐⭐⭐⭐⭐ 首选
vGPU 时间片 + 容器 高（一卡多副本） 秒级 弱（无内存/故障隔离） 多个轻量 rollout 共享一卡 ⭐⭐⭐ 提利用率可用，不能当隔离
MIG-backed vGPU + VM 低—中（静态划分） 分钟级 强（硬件隔离） 多租户不可信负载、需 VM 形态 ⭐⭐ 仅必须 VM 隔离时
VFIO 整卡直通（Kata / QEMU） 最低（一卡一 guest） 分钟级 强 带图形界面的仿真回放、多租户强隔离 ⭐⭐ 密度太低，非首选
Firecracker / AgentENV microVM N/A（无 GPU 支持） 毫秒级启动 / 百毫秒级快照 强 CPU 密集 Agent rollout、FnCall、代码执行 ⭐⭐⭐⭐ Agent 决策环专用，非仿真层

为什么 Firecracker 从架构上就出局

Firecracker 的设备模型只有 virtio-net / block / vsock / balloon / 串口等固定几样——不支持 GPU / PCIe 直通、没有 PCI 总线、无 VFIO。这从架构上就把 GPU 仿真排除在 microVM 之外，不是配置问题。

AgentENV 基于 Firecracker 构建，继承同样的限制；它的 PVM 模式解决的是嵌套虚拟化不可用时的部署问题，不改变 GPU 边界。

⚠️ AgentENV 的性能数字（boot/resume < 50ms、增量快照 < 100ms、9.6× 内存超卖）均为其项目 README 的宣称值，仓库中未给出测量方法与复现脚本，引用时当量级参考。该对照表的原始出处见前文 §2.1。

四、推荐架构：按负载分层

结合具身公司的实际形态，基础设施应该拆成三层，分别匹配不同的沙盒技术。

第一层：仿真训练主力 —— 裸金属容器 + K8s

Isaac Lab / MuJoCo / Genesis 的 rollout 和训练以 Pod 形态直接调度到带 GPU 的节点上，GPU 通过 NVIDIA Device Plugin 或 DRA 分配。

DRA 版本口径：DRA（Dynamic Resource Allocation）在 K8s 1.34 起 GA，1.35 默认启用，可按属性而非整数张数请求 GPU 切片。

⚠️ 这一条值得单独核一下：本站另一篇 DRA 拓扑感知调度 里把 GA 标在 1.35、beta 标在 1.34，与本文口径不一致。以你实际使用的 K8s 版本的 release note 为准，我暂时按 1.34 GA 写。

要提利用率，可以在其上叠 HAMi（支持按显存 MiB 和算力百分比切分）或 vGPU 时间片——但要清楚这层共享不提供故障隔离（见 §2.2）。训练批次队列交给 Kueue。

这里有一条最本质的差别：rollout 的断点续跑，正路是仿真器自身的 save_state 机制（Isaac Lab、MuJoCo、Genesis 均支持），而不是指望虚拟化层的快照。

GPU 状态无法被 hypervisor 快照——这是仿真和其他负载最本质的差别。microVM 那套「毫秒级快照 + fork 多轨迹」的能力，在 GPU 负载上直接失效。

第二层：Agent 决策环 —— microVM 或容器

具身模型的训练里，Agent 需要频繁调用工具：代码执行、文件操作、API 调用、仿真环境复位。这类负载是 CPU 密集、无 GPU、短生命周期、高并发——正是 Firecracker microVM 的甜点区。

AgentENV 的 boot/resume < 50ms、增量快照 < 100ms、内存超卖能力（均见上方 caveat），能承载大规模 Agent rollout 的生命周期管理。如果对隔离要求没那么高，kubernetes-sigs/agent-sandbox 的 Sandbox CRD + RuntimeClass 委托给 Kata / gVisor 也是一条正路。

但必须强调：快照/恢复只对 CPU + 内存状态有效。当 Agent rollout 涉及 GPU 状态时，断点恢复必须回到仿真器的 save_state——microVM 的快照帮不上忙。

第三层：数据工厂与真机接入 —— K8s + Device Plugin / DRA + SR-IOV

数万小时多模态数据集和真机部署（机器人进家庭）意味着基础设施要同时接住数据回流和真机调度。

真机硬件（机械臂、摄像头、遥操作设备）通过自定义 Device Plugin 注册为 K8s 可调度资源——这正是 RLinf 论文的做法，也是 K8s DRA 设计要解决的场景（硬件拓扑感知、按属性调度）。

数采 → 仿真回放 → 训练的数据流水线需要高吞吐网络，SR-IOV 能把虚拟功能直通到 Pod，绕过软件交换，拿到微秒级延迟和线速吞吐。

五、几条配套决策

5.1 网络隔离要按风险分层

仿真 rollout 的主要风险是泄漏权重、非授权访问外网——用 NetworkPolicy + 出口白名单就能覆盖，不必上重型方案。

真正需要域名级 egress 策略、深度审计的是不可信代码执行沙盒（Agent 工具调用层），那才是 agent-sandbox / gVisor / microVM 的战场。

如果把仿真层的网络隔离做得跟工具沙盒一样重，吞吐和延迟会先撑不住。

5.2 镜像加速是所有层共用的公共底座

Nydus + RAFS v6 + EROFS over FSCache 是公共底座，对仿真镜像（Isaac Sim / Genesis 的资产动辄数十 GB）的冷启动加速效果显著。

⚠️ 有资料指出，EROFS over FSCache 的按需读特性已在较新的内核中被标记 deprecated，社区方向转向 fanotify 的 pre-content hooks，预计会在未来几个内核版本内移除旧路径。规划时要看自己内核版本的窗口。

具体数字请用自己环境的镜像集实测——第三方评测（尤其出自 Nydus 系的）只能当量级参考。

5.3 「仿真沙盒」这个概念本身要拆开

这是全文我认为最容易被忽略、但影响最大的一条。

一件事是「仿真环境的隔离与复用」——那是仿真器和 K8s 调度的事；
另一件事是「跑仿真的那个进程放在什么隔离级别里跑」——那才是沙盒选型的事。

前者靠仿真器 API + 集群调度解决，后者按第四节的三层走。把这两件事混在一起，就会掉进「用一个统一沙盒承载一切」的陷阱。

DSec 论文最大的贡献恰恰是证明了单一抽象做不到，必须多级运行时——但它的价值在于这个「多级」的判断本身，而不是它的某一级。

六、总结

一句话回答：具身智能公司的仿真层，沙盒选型是「裸金属容器 + K8s DRA / HAMi + 仿真器自身快照」为主，Firecracker / AgentENV microVM 只做 CPU 密集的 Agent 工具调用层，GPU 虚拟化（MIG vGPU 或 VFIO 直通）仅在强隔离多租户场景兜底，virtio-gpu 直接排除。

配套的：真机接入靠 Device Plugin / DRA，高吞吐网络靠 SR-IOV，镜像加速靠 Nydus 按需加载。

选型的核心不是找一个最强的沙盒，而是认清每一层负载的隔离需求、资源形态、生命周期差异，然后用不同的技术分别匹配。

三条硬边界值得记牢：

  1. virtio-gpu 只翻译图形 API，对 CUDA / PhysX / RT Core 无能为力——主流仿真器套 VM 不是性能打折，是跑不起来；
  2. vGPU 时间片不提供隔离，提利用率和做隔离是两件事；
  3. GPU 状态无法被 hypervisor 快照，仿真断点续跑只能靠仿真器自己的 save_state。

相关阅读

核实说明：本文的技术论断基于公开文档（NVIDIA 官方文档、Mesa 文档、Firecracker 设计文档、Kubernetes release notes）与项目 README。文中已标注三处需要按自己环境复核的地方：DRA 的 GA 版本、EROFS over FSCache 的弃用内核版本、AgentENV 的性能宣称值。仿真器硬件要求（尤其 Isaac Lab 3.0 Newton 路径）在数据中心卡上落地前请自行实测。