为PyTorch项目生成requirements.txt依赖列表
在深度学习项目开发中，你是否曾遇到过这样的场景：本地训练好模型后提交代码，同事拉取后却因“torch.cuda.is_available()返回 False”而无法运行？又或者 CI/CD 流水线突然报错，排查半天才发现是某台服务器上的 cuDNN 版本与 PyTorch 不兼容？
这类问题的根源，往往不在于代码本身，而在于环境的不可复现性。尤其当项目涉及 GPU 加速、CUDA 工具链和复杂 Python 依赖时，手动配置几乎等同于“踩雷游戏”。幸运的是，现代开发已经给出了成熟解法——结合容器镜像与标准化依赖管理。
以pytorch-cuda:v2.8这类预构建镜像为例，它不仅集成了特定版本的 PyTorch 和 CUDA，还自带 Python 生态常用库，真正实现了“启动即用”。但关键一步常被忽视：如何从这个“完美环境”中准确提取出属于你项目的那份requirements.txt？这并非简单执行一条pip freeze就能一劳永逸。
镜像不是终点，而是起点
很多人误以为使用了官方镜像就万事大吉，其实不然。镜像提供的是一个通用基础环境，里面可能包含了 Jupyter、testtools、sphinx 等你项目根本用不到的包。如果直接将整个环境导出为依赖文件，会导致几个严重后果：
- 部署体积膨胀：生产环境中安装大量无用依赖，浪费存储与带宽。
- 安全风险增加：引入不必要的第三方库可能带来漏洞暴露面。
- 版本冲突隐患：某些开发期工具可能与生产组件存在间接依赖冲突。
举个真实案例：某团队在镜像中使用pip freeze > requirements.txt后，发现其文件竟包含pytest==7.4.0和torchvision==0.15.2，而他们的服务仅需推理功能。结果在边缘设备部署时因空间不足失败。后来改用按需分析，依赖项从 68 个精简到 19 个，镜像大小减少 40%。
所以，正确的做法是：把基础镜像当作干净画布，从中提炼出真正属于你项目的最小依赖集。
如何精准提取你的项目依赖？
最直观的方法当然是进入容器执行命令：
docker run --gpus all -it pytorch-cuda:v2.8 bash pip freeze > requirements.txt这条命令确实能拿到所有已安装包的精确版本，但它给的是“全量快照”，而非“项目特需”。要实现精细化控制，建议采用以下策略组合。
方法一：pipreqs—— 基于代码引用的智能推断
相比pip freeze的“我装了什么就列什么”，pipreqs 更聪明：它扫描你的.py文件，只列出被import的包。
# 安装 pipreqs pip install pipreqs # 在项目根目录运行（假设代码在 ./src） pipreqs ./src --force输出示例：
numpy==1.24.3 torch==2.0.1 tqdm==4.66.1 transformers==4.35.0你会发现，像jupyter-client、notebook这类开发辅助工具不会出现在结果中。这才是真正的“业务所需”。
💡 实践建议：对于新项目，优先使用
pipreqs生成初版requirements.txt；对于已有项目，可用其验证是否存在未声明但实际使用的隐式依赖。
方法二：分层管理依赖 —— 让不同环境各取所需
大型项目应避免单一requirements.txt。更合理的做法是分层组织：
requirements/ ├── base.txt # 核心运行时依赖（PyTorch, CUDA相关） ├── dev.txt # 开发环境（Jupyter, pytest, black, mypy） ├── prod.txt # 生产环境（base + 推理优化库如 onnxruntime） └── test.txt # 测试专用（factory-boy, responses）然后通过-r引入：
# requirements/prod.txt -r base.txt onnxruntime-gpu==1.16.0 psutil>=5.0.0这样，在部署时只需pip install -r requirements/prod.txt，确保环境纯净高效。
方法三：结合 Docker 多阶段构建自动提取
如果你使用 CI 构建流程，可以利用多阶段 Dockerfile 自动化生成轻量依赖：
# 第一阶段：基于完整镜像分析依赖 FROM pytorch-cuda:v2.8 as analyzer COPY . /app WORKDIR /app RUN pip install pipreqs && \ pipreqs . --output-file requirements-auto.txt --force # 第二阶段：构建极简运行环境 FROM nvidia/cuda:12.1-runtime-ubuntu22.04 RUN apt-get update && apt-get install -y python3-pip COPY --from=analyzer /app/requirements-auto.txt . RUN pip install -r requirements-auto.txt COPY . /app CMD ["python", "/app/inference.py"]这种方式不仅能保证依赖准确性，还能实现“构建即验证”——只要镜像能成功构建，说明依赖关系就是完整的。
Jupyter 与 SSH：不只是访问方式，更是工作流选择
在pytorch-cuda镜像中，Jupyter 和 SSH 并非简单的连接选项，它们代表了两种截然不同的开发范式。
当你在做实验时，Jupyter 是最佳拍档
数据探索、模型调参、可视化输出……这些高度交互的任务，用 Jupyter 再合适不过。你可以直接在 Notebook 中导出依赖：
# 在 cell 中运行 !pip freeze > reqs_for_experiment.txt但注意：此时导出的会包含ipykernel,matplotlib,pandas等可视化相关库。如果你后续要把实验转成脚本部署，记得清理这些非必要项。
更好的做法是在完成原型后，用pipreqs扫描生成的.py脚本，得到真正可部署的依赖列表。
当你要跑训练任务时，SSH + 命令行才是正道
长时间训练任务不适合放在 Jupyter 中执行。一旦网络中断，内核断开，训练即终止。正确姿势是通过 SSH 登录后使用tmux或nohup：
ssh -p 2222 user@localhost nohup python train.py --epochs 100 > train.log 2>&1 &同时，在启动前先确认环境状态：
python -c " import torch print(f'Torch: {torch.__version__}') print(f'GPU: {torch.cuda.get_device_name(0) if torch.cuda.is_available() else \"None\"}') "这种模式下，你可以放心地关闭终端，进程仍在后台持续运行。更重要的是，它更贴近生产环境的行为模式，有助于提前发现问题。
别忘了版本锁定与安全性审查
即使你有了完美的requirements.txt，也不代表高枕无忧。以下几个细节决定成败。
锁定镜像标签，拒绝“神秘更新”
永远不要使用latest标签。假设你今天基于pytorch-cuda:v2.8开发，一切正常；两周后新人拉取时，若v2.8被重新构建并升级了 PyTorch 到 2.1，而你的代码尚未适配，就会出问题。
解决方案很简单：在文档或 README 中明确记录所用镜像版本，并在 CI 脚本中硬编码：
# .github/workflows/ci.yml - name: Start container run: | docker run --gpus all -d --name trainer pytorch-cuda:v2.8定期扫描依赖漏洞
Python 包生态庞大，但并非每个维护者都及时响应安全通告。建议集成pip-audit或safety工具进行检查：
pip install pip-audit pip-audit -r requirements.txt发现高危漏洞时立即升级或寻找替代方案。例如，曾有项目因依赖链中的urllib3<1.26.5存在 CVE-2020-26137，导致中间人攻击风险。
使用.dockerignore减少干扰
在构建过程中，避免将缓存、日志、虚拟环境打包进镜像：
# .dockerignore __pycache__ *.pyc .env .venv .git data/ logs/这不仅能加快构建速度，也能防止意外泄露敏感信息。
从实验到部署：一条清晰的路径
总结下来，一个稳健的 PyTorch 项目依赖管理流程应该是这样的：
初始化阶段
启动pytorch-cuda:v2.8容器，挂载项目目录，使用 Jupyter 快速验证想法。原型转工程
将核心逻辑拆分为.py模块，用pipreqs扫描生成初始requirements/base.txt。分层定义需求
补充dev.txt（开发）、prod.txt（生产）等，实现环境隔离。自动化验证
在 CI 中通过多阶段 Docker 构建测试依赖完整性，同时运行pip-audit检查安全。交付与协作
将requirements/*.txt提交至 Git，配合 Dockerfile 形成可复现的部署单元。
这条路径的核心思想是：利用容器解决环境一致性问题，用结构化依赖管理提升工程品质。
最终你会发现，那些曾经让人头疼的“在我机器上是好的”问题，正逐渐消失。取而代之的，是一个无论在笔记本、服务器还是 CI 环境中都能稳定运行的 AI 应用。
这种高度集成的设计思路，正引领着深度学习项目向更可靠、更高效的方向演进。
