机器学习项目的实验结果往往依赖大量环境因素：Python 版本、深度学习框架版本、CUDA 驱动、第三方库甚至操作系统底层组件。仅仅记录模型的超参数和训练日志，远远不足以保证结果可以复现。Docker 提供了一种把整个运行环境固化为镜像的方式，配合实验跟踪工具，可以让每一次训练都附带一份完整的环境快照。本文从实际落地出发，讨论 Docker 在实验跟踪中的核心做法、常见坑点以及团队协作时的管理策略。
为什么实验跟踪离不开容器化
很多团队早期做实验跟踪，只是用表格记录学习率、batch size、数据集版本这些显式参数。这种方式在单人小项目里勉强够用，但一旦出现依赖冲突问题就会暴露短板。比如同一个项目里，A 实验用的是 PyTorch 1.13，B 实验升级到了 2.1，某天发现 A 的结果在当前环境怎么都跑不出来，问题到底出在代码改动还是依赖变更，完全无法判断。环境本身就是实验变量的一部分，不把它记录下来，跟踪就只做了一半。
容器化的价值在于把环境变量从不确定性变成确定性。Docker 镜像包含操作系统库、Python 解释器、所有依赖包的完整状态，只要镜像还在，理论上任何时候都能还原出当时跑实验的精确环境。把镜像的摘要哈希（digest）作为元数据写入实验记录，环境信息就跟指标、参数一样变成了可查询、可对比的跟踪维度。
除了复现性，容器还带来隔离性收益。数据科学家经常需要在同一台机器上跑不同框架版本的实验，直接装在宿主机上迟早会互相污染。每个实验一个容器，环境互不干扰，卸载清理也只需要删掉镜像和容器，不留残余。
如何编写适合实验场景的 Dockerfile
实验用的镜像和线上服务镜像的诉求不太一样。线上镜像追求体积小、启动快，实验镜像更看重构建速度和灵活性。一个实用的做法是采用多阶段或分层缓存策略：把变动频率低的依赖安装放在前几层，把频繁修改的代码放在最后几层，这样改代码重新构建时可以复用缓存，几秒钟就能出新镜像。
FROM pytorch/pytorch:2.1.0-cuda12.1-cudnn8-runtime # 依赖层：改动少，放在前面利用缓存 COPY requirements.txt /tmp/requirements.txt RUN pip install --no-cache-dir -r /tmp/requirements.txt # 代码层：经常变动，放在最后 WORKDIR /workspace COPY . . # 记录环境快照，便于事后追溯 RUN pip freeze > /workspace/requirements.lock.txt ENTRYPOINT ["python", "train.py"]
几个细节值得注意。基础镜像尽量选择官方维护的 CUDA 版本镜像，省去自己配驱动的麻烦，但要确保版本与宿主机驱动兼容。训练代码里不要把数据集打包进镜像，通过 volume 挂载的方式引入数据，否则镜像会膨胀到难以管理。另外建议在构建时把 pip freeze 的输出固化到镜像内部，即使后来 requirements.txt 被改动了，镜像里仍保留着真实的依赖清单。
还有一个常被忽略的点：代码是走 COPY 进镜像，还是通过挂载注入？严格复现场景下推荐 COPY，因为镜像内容不可变，代码即快照。调试迭代阶段则可以挂载代码目录，改完立刻重跑，效率更高。实践中可以给同一个镜像打两个用途标签，调试用挂载，正式实验用内置代码，各取所长。
把镜像信息接入实验跟踪工具
容器本身只是环境快照，要形成完整的实验跟踪体系，还需要把镜像标识和训练元数据绑定在一起。主流工具如 MLflow、Weights & Biases 都支持记录任意自定义元数据，只需在启动训练前把镜像信息注入环境变量即可。
IMAGE_DIGEST=$(docker inspect --format='{{index .RepoDigests 0}}' my-experiment:latest)
GIT_COMMIT=$(git rev-parse HEAD)
docker run --rm \
-e IMAGE_DIGEST=$IMAGE_DIGEST \
-e GIT_COMMIT=$GIT_COMMIT \
-e MLFLOW_TRACKING_URI=http://192.168.0.1:5000 \
my-experiment:latest在训练脚本内部，用 mlflow.log_param 之类的接口把这些环境变量一并上报。这样在实验平台的界面上，每条实验记录都能看到对应的镜像摘要、代码提交号、参数和最终指标，复现时一条 docker run 命令加上对应的 Git checkout 就能还原整个实验。MLflow 还提供了 MLproject 文件机制，可以直接声明实验的执行环境和入口命令，配合 mlflow run 实现"一条命令跑实验"，环境声明和执行进一步解耦。
GPU 场景下要注意，宿主机需要安装 nvidia-container-toolkit，并在 docker run 时加上 --gpus all 参数。CUDA 的兼容性矩阵要提前确认清楚，容器内的 CUDA 版本不能高于宿主机驱动支持的版本，否则会报驱动不匹配错误。这些信息同样建议记入实验元数据，因为 GPU 型号和驱动版本对训练结果（尤其是数值精度相关实验）可能有实际影响。
团队协作中的镜像管理与常见坑点
单人实验用本地镜像就够了，团队场景则需要一个统一的镜像仓库。可以搭建 Harbor 或使用云厂商的镜像服务，约定统一的命名规范，比如 registry.ippipp.com/ml/experiment-{项目名}:{git短哈希}，让镜像名天然关联代码版本。CI 流水线中自动构建并推送镜像，再触发实验任务，整个流程就闭环了。
存储成本是团队必须面对的问题。深度学习镜像动辄十几 GB，每次改依赖都推新镜像，仓库很快就会失控。缓解手段有几个：一是保持基础镜像稳定，所有实验镜像从同一个基础镜像派生，Docker 的分层共享机制能让实际存储远小于镜像标称大小；二是定期清理无人引用的实验镜像，只保留重要实验对应版本；三是把大型依赖（如预训练模型权重）通过挂载或对象存储分发，不塞进镜像。
几个高频踩坑点也值得列出来。第一，用 latest 标签跟踪实验是大忌，latest 指向的内容随时会变，必须用不可变的 digest 或唯一 tag 定位镜像。第二，容器内写文件要注意权限问题，容器内用户 UID 与宿主机不一致时，挂载目录可能写不进去或产生 root 属主文件，建议在 Dockerfile 中显式创建普通用户运行训练。第三，随机种子、数据切分这些非环境因素同样要纳入跟踪，否则即使环境完全一致，结果仍可能对不上。容器解决的是环境维度的可复现，完整的实验跟踪还需要代码、数据、配置三个维度共同配合。
总的来说，Docker 把实验环境从"口口相传的配置说明"变成了"可分发、可校验的制品"，与实验跟踪工具结合后，每次训练都自带完整上下文。前期搭建流水线虽然要多花一些功夫，但当实验数量上到几十上百个、或者需要跨机器迁移训练任务时，这套体系的回报会非常明显。