1.2 隔离式沙箱究竟在隔离什么：容器、虚拟化与 GPU 透传的边界
文档摘要
1.2 隔离式沙箱究竟在隔离什么：容器、虚拟化与 GPU 透传的边界 上一节我们论证了"venv 管不了大模型最麻烦的那层"。这一节我们要正面回答本教程最核心的概念问题：隔离式开发沙箱，到底在隔离什么？ 注意，这里说的"隔离"不是泛泛而谈的安全沙箱，而是特指在大模型开发语境下，把"代码 + 依赖 + 运行时 + 硬件视图"这四件事，按使用者（人 / 任务 / 团队）切割开来的能力。要讲清它，必须先厘清三对常被混用的概念：容器与虚拟机、隔离与虚拟化、GPU 透传与 GPU 直通。 一、容器（Container）与虚拟机（VM）的本质区别 很多人把 Docker 容器当成"轻量虚拟机"，这是个容易误导的比喻。
1.2 隔离式沙箱究竟在隔离什么：容器、虚拟化与 GPU 透传的边界
上一节我们论证了"venv 管不了大模型最麻烦的那层"。这一节我们要正面回答本教程最核心的概念问题：隔离式开发沙箱，到底在隔离什么？
注意，这里说的"隔离"不是泛泛而谈的安全沙箱，而是特指在大模型开发语境下，把"代码 + 依赖 + 运行时 + 硬件视图"这四件事，按使用者（人 / 任务 / 团队）切割开来的能力。要讲清它，必须先厘清三对常被混用的概念：容器与虚拟机、隔离与虚拟化、GPU 透传与 GPU 直通。
一、容器（Container）与虚拟机（VM）的本质区别
很多人把 Docker 容器当成"轻量虚拟机"，这是个容易误导的比喻。
| 维度 | 虚拟机（VM） | 容器（Container） |
|---|---|---|
| 隔离层级 | 硬件 + 完整 Guest OS 内核 | 共享宿主内核，隔离用户态 |
| 启动速度 | 秒~分钟级（要起一个 OS） | 毫秒~秒级（只是进程） |
| 资源开销 | 高（每 VM 一套内核与内存） | 低（仅进程级开销） |
| 隔离强度 | 强（内核都分开） | 较弱（共享内核，靠 namespace/cgroup） |
| 适用场景 | 需要不同内核/强安全边界 | 同内核下的环境封装与分发 |
关键理解：容器不是模拟一台机器，而是给一个进程套上一套"障眼法"。Linux 的 namespace 让容器里的进程以为自己独占了一个文件系统、网络、进程树（PID 1 是它自己）；cgroups 给它限定能用的 CPU、内存上限。但容器和宿主机跑的是同一个 Linux 内核。
这对大模型沙箱意味着两件事：
- 好处：容器启动极快、分发极小，一份镜像几 GB 就能把"完整的 torch + CUDA 运行时 + 你的代码"带走，非常适合"环境即代码"；
- 代价：因为共享内核，容器默认拿不到 GPU——GPU 设备（
/dev/nvidia*）和内核驱动是宿主机的，容器里看不见。要让容器用上 GPU，必须显式"透传"设备并注入驱动库。这就引出了下一对概念。
二、隔离（Isolation）不等于虚拟化（Virtualization）
这是第二个常被混淆的点。
- 虚拟化关心的是"把一份硬件虚拟成多份"，重点在"资源怎么分"。比如把一张物理 GPU 通过 MIG（Multi-Instance GPU）切成 7 个逻辑实例，或把一台服务器虚拟成 10 台 VM；
- 隔离关心的是"不同的工作负载不要互相污染"，重点在"边界怎么画"。比如两个训练任务各自有独立的文件系统、依赖、显存视图，互不可见。
大模型开发沙箱，核心诉求是隔离（环境不互踩、可复现），而不是一定要虚拟化（把硬件拆碎）。因此容器是性价比最高的选择：它用很低的成本提供了"文件系统隔离 + 依赖隔离 + 进程边界"，再通过 GPU 透传补齐硬件访问。
只有当团队需要"把一张卡按算力切给多个人独立用"时，才需要叠加虚拟化手段（如 MIG、或 vGPU）。本书第四章会提到 MIG 这类进阶用法，但在基础篇，请先建立这个判断：我们先要的是隔离，虚拟化是可选的增强。
三、GPU 透传（Passthrough）与 GPU 直通的区别
第三个概念对后续实操至关重要。
- GPU 直通（PCIe Passthrough / VFIO）：把整张物理 GPU 从宿主机"夺走"，独占式分配给一个虚拟机。宿主机自己都不能用这张卡。常用于 VM 场景，隔离极强但浪费——一张卡只能给一个 VM；
- GPU 透传（Device Passthrough into Container）：宿主机仍正常用 GPU，只是把 GPU 设备文件（
/dev/nvidia0等）和必要的驱动库"映射"进某个容器，让这个容器的进程能直接调用。多个容器可以各自看到不同的卡（靠CUDA_VISIBLE_DEVICES与 runtime 配合），但底层共享同一个驱动。
我们教程讲的是第二种——容器级 GPU 透传。它的精髓在于：
- 容器里不装驱动，驱动只在宿主机。容器启动时由 NVIDIA Container Runtime 把宿主机的驱动库（如
libcuda.so、libnvidia-ml.so）挂载进容器； - 容器里只带 CUDA toolkit 的"用户态运行时"部分（其实就是那些
.so），真正发号施令的内核驱动是宿主机的； - 可见性由 runtime 裁剪：你给容器
--gpus '"device=0"'，runtime 就会把CUDA_VISIBLE_DEVICES=0注入容器，并只把/dev/nvidia0暴露给它，容器"以为"自己独占 0 号卡，实际上底层是运行时在过滤设备视图。
这套机制既避免了"每容器装一份驱动"的臃肿与冲突，又实现了"每个沙箱只看到自己那张卡"的隔离感。第三章会拆开它的内部调用链。
四、一个沙箱到底装了什么、没装什么
为了把概念落到可执行的地基上，我们给"隔离式大模型沙箱"画一张"内容物清单"：
| 组件 | 在宿主机 | 在沙箱（容器）内 | 说明 |
|---|---|---|---|
| Linux 内核 | 是 | 否（共享） | 容器不自带内核 |
| NVIDIA 驱动 | 是 | 否（运行时挂载） | 容器内只看到 .so 影子 |
| CUDA 用户态运行时 | 否 | 是（来自基础镜像） | 如 libcudart |
| Python 与 torch | 否 | 是 | 随镜像打包 |
| 你的代码与数据 | 否（用 volume 挂载） | 是（挂载视图） | 数据常通过卷共享 |
| GPU 设备 | 是 | 部分（按 device 透传） | 只看到被授权的卡 |
这张表回答了"隔离"的精确含义：内核、驱动、硬件是共享的事实基础；文件系统、依赖栈、GPU 设备视图是被切割的边界。沙箱"隔离"了容易冲突、需要一致的那层（依赖与设备视图），"共享"了没必要重复、反而容易出问题的那层（内核与驱动）。这就是它比 VM 轻、比 venv 强的原因。
五、为什么要"隔离式"而不是"裸机式"
把前面所有概念收束成一句话：隔离式沙箱 = 容器（提供文件系统/依赖/进程边界）+ GPU 透传（提供受控的硬件访问）+ 镜像固化（提供跨机复刻）。
它解决的是第一章开头那个 5 人团队的死循环：
- 每个人在自己的容器里拥有完整且独立的依赖栈，升级自己的库不会动到别人；
- 每个人只看到被分配给自己的 GPU（哪怕物理上是同一台 8 卡机），不会互相抢；
- 镜像是不可变的，新人拉同一个镜像，得到和老人完全相同的环境，无需口口相传。
到这里，你应当能区分"容器 vs 虚拟机""隔离 vs 虚拟化""透传 vs 直通"这三组概念，并说清"沙箱里到底装了什么"。下一节我们讨论技术选型：为什么是 Docker + CUDA，而不是其他组合。