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

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

本章导读

第一章我们论证了一件事：大模型开发必须用隔离式沙箱，而且 Docker + CUDA 是当前工程上最划算的底座。但"该用"和"能用起来"之间隔着一层很厚的工程细节。

这一章要做的，是把一个"能跑 demo 的 Dockerfile"升级成"可以反复使用、可以交给同事、可以半年后还能跑起来"的沙箱骨架。我把这套骨架拆成三个必须搞懂的模块：

• 2.1 镜像分层设计——决定你每次改一行依赖要不要重新下载 8 GB。分层不对，CI 永远慢、缓存永远失效。
• 2.2 环境编排与可复现依赖——决定"在我机器上能跑"能不能变成"在任何人机器上能跑"。这是隔离式沙箱真正的价值兑现点。
• 2.3 挂载、端口与数据卷策略——决定你的模型权重、数据集、训练日志会不会在容器一关就人间蒸发。

读完这三节，你将拥有一份可以当作团队标准的沙箱模板，而不是一堆一次性命令。

一个核心判断

我建议你把沙箱骨架理解为"一次设计、长期复用"的资产，而不是"跑通今天的任务就行"的脚本。区别在哪？一次性脚本追求的是立刻跑通；可复用骨架追求的是变更成本最低——新加一个依赖、换一张卡、换一个模型，最好只动几行配置，而不是推倒重来。

下面三节每节都会回到这个判断：这个设计，是在降低未来的变更成本，还是在埋雷？

骨架设计的三个反直觉事实

在动手前，先记住三个新人常踩、但老手习以为常的事实，它们会贯穿整章：

1. 镜像越大 ≠ 越慢：分层合理时，基础镜像层几乎只下载一次，真正每次变动的只是最上面几层。怕的不是镜像大，而是"每次构建都从头拉"。
2. 锁定版本 ≠ 锁死一切：FROM nvidia/cuda:12.1.1-runtime 锁的是 CUDA 运行时，但 pip install torch 不锁版本仍会漂移。可复现要求"每层各管各的版本"。
3. 数据千万别进镜像：权重、数据集几十上百 GB，塞进镜像既臃肿又危险；正确做法是用 volume 挂载，让镜像保持"只装软件、不装数据"。

本章与前后章的关系

• 第一章解决"为什么"：隔离、GPU 透传、Docker 路线的取舍。
• 本章解决"怎么做骨架"：把抽象目标落成可维护的工程结构。
• 第三章会深入 GPU 透传与隔离的底层原理，解释为什么这样挂 --gpus 是安全的。
• 第四章用真实模型把本章骨架真正跑起来。

如果你只想抄一份能用的模板，直接看 2.1 的 Dockerfile 与 2.3 的 compose 片段即可；但建议你至少把 2.2 读完，因为"可复现"是沙箱区别于"裸机装环境"的唯一理由。