第三章 · 进阶原理：GPU透传与隔离的本质

第三章 · 进阶原理：GPU 透传与隔离的本质

第二章我们做到了「容器里能看到卡、能跑模型」。但一个负责任的作者不会让你停在「能用就行」——本章要回答两件更值钱的事：它为什么能用？以及，当多人多任务共用一台八卡机器时，怎么保证彼此不抢、不崩？

这一章是整本教程的「原理脊梁」。把机制讲透，你才能在出问题时快速定位，而不是对着报错盲猜；也才能在资源紧张时，做出有依据的资源切分决策，而不是拍脑袋。

本章你将带走什么

读完本章，你应能回答三个工程问题：

1. 链路问题：容器本身没有安装 GPU 驱动，为什么 import torch; torch.cuda.is_available() 仍然返回 True？驱动、CUDA 工具链、用户态库分别住在宿主还是容器里？
2. 调用链问题：你敲下 docker run --gpus all 的那一刻，从 docker 客户端到 runc 创建容器，NVIDIA 的组件在哪一步、以什么方式把 /dev/nvidia* 设备和用户态库注入容器？
3. 隔离问题：一张卡被五个人同时用，怎么让彼此的显存、算力、设备视图互不踩？进程级（MPS）、硬件级（MIG）、容器级（cgroup / 设备视图）三种粒度各管什么？

这三个问题串起来，就是「隔离式沙箱」从「能跑」到「可管、可分工」的跃迁。

为什么这一章值得你慢读

很多教程把 GPU 容器当成黑盒：装好 NVIDIA Container Toolkit、加个 --gpus all、能跑就万事大吉。但工程现场里，真正让人失眠的从来不是「能不能跑」，而是：

• 换了一台驱动版本略低的机器，镜像突然报 CUDA driver version is insufficient——为什么昨天还好好的？
• 同事的训练任务把整张卡显存吃满，你的推理服务直接 OOM 被杀死——你们明明「各跑各的容器」啊？
• 想给实习生分配「半张 A100」的算力配额，发现 docker run 没有这种参数——到底该从哪一层切？

这些问题，答案都在本章。它们不靠背命令解决，而靠理解「设备怎样进容器」「资源怎样被切分」这两条主线。

本章路线图

• 3.1 NVIDIA Container Runtime 的调用链剖析：顺着一次 docker run --gpus all，把 dockerd → containerd → runc → nvidia-container-runtime 的协作拆开，讲清设备与驱动库注入的完整链路，以及「驱动在宿主、库在容器」的分工为何决定了版本天花板。
• 3.2 显存、算力与设备视图的隔离边界：从共享八卡机的真实困境出发，对比 MPS（进程级）、MIG（硬件级）、cgroup / 设备视图（容器级）三种隔离粒度的适用场景与配置要点，并给出「小团队共用训练机」的推荐组合。

原理讲完，下一章（第四章）我们把它落到真实案例上：训练任务怎么沙箱化、推理服务怎么对外暴露。

一点阅读约定

本章涉及少量 NVIDIA 官方组件的版本与行为差异（例如 CDI 与传统 NVIDIA_VISIBLE_DEVICES 注入路径的演进）。文中凡涉及具体版本号、默认开关、命令路径之处，我都标注「建议结合官方文档核实」，绝不替你编造运行结果。读的时候，把机制主干记牢即可，落地的精确命令以你所用版本的官方说明为准。