第二章 · 核心模块：搭建可复用的沙箱骨架

第二章 · 核心模块：搭建可复用的沙箱骨架

第一章我们统一了认知：GPU 开发必须隔离，且隔离要连 Cuda 运行时一起打包。本章进入动手环节，目标是搭出一套「换台机器也能一行命令拉起」的标准骨架。

我们不会堆砌命令，而是把沙箱拆成几个可独立替换的模块：基础镜像怎么选、Dockerfile 怎么写才兼顾体积与可用性、docker-compose 如何编排多容器、以及最关键也最容易被忽略的——GPU 设备如何在容器内可见可用。

本章你将带走什么

读完本章，你手头应该有一份经过验证的「沙箱模板」：一条命令启动即获得带 GPU 的 Python 环境，且环境定义全部落在版本化的文件里，团队任何人 clone 下来都能复现。

2.1 节预告：基础镜像选型与 Dockerfile 模板

从 nvidia/cuda 官方镜像家族讲起——base/runtime/devel 三类的区别，什么时候该用哪个；如何选 Cuda 与 Python 版本组合避免踩雷；一份可复用的 Dockerfile 模板，含 apt 源加速、非 root 用户、工作目录与数据卷约定。

2.2 节预告：docker-compose 编排多容器沙箱

单容器够用吗？当你的开发需要「训练容器 + 推理服务容器 + 向量库容器」协同，compose 就能把拓扑固化下来。本节给出推理服务 + 模型下载容器的 compose 范例，讲清网络、卷、资源限制三段怎么写。

2.3 节预告：让 GPU 在容器内「活」起来

这是整章的核心难点。我们会实装 nvidia-container-toolkit，验证 docker run --gpus all 之后容器内 nvidia-smi 与 torch.cuda.is_available() 双双为真；并排错清单化——工具包没装、驱动版本过低、容器运行时配置缺失时各自的报错长什么样。

第三章我们将深入这些机制背后的原理，解释为什么它能工作。