第一章 · 基础：为什么需要隔离式开发沙箱
第一章 · 基础：为什么需要隔离式开发沙箱
导读：从一句"在我机器上能跑"说起
每一位做过机器学习工程的开发者，几乎都被同一句话卡住过——代码在你本地跑得好好的，一旦交给同事、丢到服务器、或者上线到另一台带显卡的机器，就莫名其妙地报错、崩溃、或者干脆"跑出来的结果不一样"。
这句"在我机器上能跑"（It works on my machine），是大模型开发里最经典、也最令人头疼的甩锅台词。它背后暴露的，不是某段代码的 bug，而是开发环境与运行环境的不一致：
- 你的 CUDA 是 12.1，服务器是 11.8；
- 你的 PyTorch 是编译给 cu121 的，对方是 cu118；
- 你的显存是 24GB 的 4090，训练集群是 80GB 的 A100；
- 甚至同一个
requirements.txt，在不同时间点装出来的依赖树都不一样。
当模型从"单机玩具"走向"多人协作、多卡训练、持续迭代"的真实工程，这种不一致就会被放大成系统性风险：实验结果无法复现、故障无法定位、GPU 资源被无序争抢、新人配环境要花上整整一周。
本章不急着写命令、不急着拉镜像。我们要先把"为什么"讲透——只有理解了大模型开发到底卡在哪几个痛点上，以及"隔离式沙箱"到底在隔离什么，你才会真正明白后面每一行 Dockerfile、每一条 docker run 参数的意义。
复现，是大模型工程的命门
在大模型项目里，"能跑一次"和"能稳定复现"是两回事。一个微调实验，从数据预处理、tokenizer 版本、随机种子，到 CUDA 内核本身的非确定性，任何一个环节的环境漂移，都可能让"效果提升两个点"变成无法向老板交代的幻觉。
更麻烦的是，当结果对不上时，你往往分不清是"模型/数据的问题"还是"环境的问题"——这两种排查路径完全不同。隔离式沙箱把环境钉死，等于把"环境"这个变量从实验里剔除，让你每一次对比，真正比的是模型与数据，而不是玄学。
环境不一致的三类典型故障画像
为了让"不一致"这件事不再抽象，我们把它拆成三种最容易在大模型现场撞见的故障：
- 依赖漂移型：同一份
requirements.txt，今天装和三个月后装，transitive 依赖的版本可能已经被上游悄悄改了，导致同一个 commit 在不同时间跑出不同行为。 - 硬件视图型：本机是 4090（计算能力 8.9），服务器是 A100（计算能力 9.0），某个量化算子只在计算能力 ≥ 8.0 可用，于是本地正常、上线即崩。
- 驱动错配型：本地用 CUDA 12.1 编译的 torch，丢到 CUDA 11.8 的机器，直接
CUDA error: no kernel image is available，连报错都让人摸不着头脑。
本章路线图
本章作为整本教程的"基础篇"，目标只有一个：建立正确的心智模型。我们会依次回答三个问题：
- 大模型开发的真实痛点是什么？ 为什么传统
venv+pip的方式撑不起大模型工程（1.1 节）。 - 隔离式开发沙箱到底是什么？ 容器、虚拟化、GPU 透传这些概念之间的边界在哪里（1.2 节）。
- 为什么偏偏选 Docker + CUDA 这条技术路线？ 和其他方案比，它的取舍在哪里（1.3 节）。
读完这三节，你不需要会写任何配置，但你应该能在一张白纸上画出自家团队的"环境隔离架构草图"，并且能向同事解释：为什么我们要花时间把模型塞进容器，而不是继续在裸机上 pip install。
一个贯穿全书的真实场景
为了让后面的讨论不悬空，先约定一个贯穿全教程的虚构但典型的小团队场景：
一个 5 人算法团队，共用一台 8 卡 A100 服务器。有人在做 7B 模型的微调，有人在做 RAG 推理服务，还有人在复现一篇论文。他们共用同一个系统 Python、同一个 CUDA 目录。某天，做微调的同学升级了 CUDA 驱动以适配新框架，结果做推理的同学当晚服务全部
CUDA error: invalid device，排查到凌晨。
这个场景里的每一个角色、每一次踩坑，都会在后续章节变成可落地的配置与命令。而这一切的起点，就是"把环境关进各自的沙箱里"。
在第二章，我们会动手搭建可复用的沙箱骨架；第三章深入 GPU 透传与隔离的本质；第四章把真实模型真正塞进去跑；第五章收束为标准化工程实践。现在，让我们先回到最朴素的问题——我们到底在解决什么麻烦。