LoRA 是目前大模型微调领域最流行的方案之一，它通过在原模型旁路插入低秩矩阵来训练少量参数，显存占用小、训练成本低。但 LoRA 微调本身对运行环境的要求并不低：需要匹配的 CUDA 驱动、正确版本的 PyTorch、bitsandbytes、peft、transformers 等一整套依赖，任何一处版本冲突都可能导致训练脚本报错。Docker 提供了一条干净的路——把整个训练环境打包成镜像，在任何一台装有 NVIDIA 驱动的机器上都能直接运行，无需重复折腾环境。
为什么 LoRA 微调适合用 Docker
LoRA 微调的依赖链条非常长。以一个典型的场景为例，你需要 PyTorch 2.x 对应特定 CUDA 版本的构建、bitsandbytes 用于 4bit 量化加载、peft 提供 LoRA 实现、transformers 与模型版本匹配，再加上 datasets、accelerate 等辅助库。这些库之间任意两者版本不兼容，都可能出现"训练时 loss 为 NaN"、"量化加载报错"这类难以定位的问题。直接在宿主机装环境，往往装好一次、重启失效，或者换了台机器又得重来。
Docker 的价值在于把环境固化。写好 Dockerfile 之后，镜像里包含了所有依赖的精确版本，团队成员拿到镜像就能复现完全一致的训练环境。即使宿主机的 CUDA Toolkit 和容器内的版本不同也没关系，只要 NVIDIA 驱动满足要求，容器内可以自带独立的 CUDA 运行时。另外，镜像可以推送到私有仓库，训练机和开发机共用一份，避免了"我这里能跑你那里不能跑"的沟通成本。
选择基础镜像与编写 Dockerfile
搭建环境的第一步是选对基础镜像。常用的有两类：NVIDIA NGC 的 PyTorch 镜像（如 nvcr.io/nvidia/pytorch）和 PyTorch 官方镜像（如 pytorch/pytorch）。NGC 镜像集成了针对 NVIDIA 硬件优化过的库，训练性能更好，但体积大；官方镜像更轻量，适合自己控制依赖。下面以官方镜像为例，写一个用于 LoRA 微调的 Dockerfile：
FROM pytorch/pytorch:2.3.1-cuda12.1-cudnn8-runtime # 设置工作目录 WORKDIR /workspace # 先复制依赖清单，利用镜像层缓存加速构建 COPY requirements.txt . RUN pip install --no-cache-dir -r requirements.txt # 复制训练脚本 COPY train_lora.py . # 用非交互模式避免某些库构建时卡住 ENV PYTHONUNBUFFERED=1 CMD ["python", "train_lora.py"]
对应的 requirements.txt 需要锁定版本，这是保证可复现的关键：
torch==2.3.1 transformers==4.41.2 peft==0.11.1 bitsandbytes==0.43.1 datasets==2.19.1 accelerate==0.30.1
这里有一个实践建议：不要在镜像里放数据和模型权重，用挂载的方式在运行时注入。模型动辄几个 GB，打进镜像既拖慢构建，也浪费磁盘。只把代码和依赖固化进镜像，数据、权重、输出目录都通过 volume 挂载，这样同一个镜像可以服务不同的训练任务。
GPU 支持配置与容器启动
Docker 使用 GPU 需要 NVIDIA Container Toolkit 的支持。宿主机上先确认驱动已安装，然后安装 nvidia-container-toolkit 并重启 Docker 服务。验证方式很简单，运行一个查询 GPU 的容器：
# 安装 NVIDIA Container Toolkit sudo apt-get install -y nvidia-container-toolkit sudo systemctl restart docker # 验证容器内能否看到 GPU docker run --rm --gpus all nvidia/cuda:12.1.1-base-ubuntu22.04 nvidia-smi
如果这条命令正常输出了显卡信息，说明 GPU 透传已经打通。启动 LoRA 训练容器时，常用的完整命令如下：
docker run --gpus all \ --shm-size=16g \ -v /data/models:/workspace/models \ -v /data/dataset:/workspace/dataset \ -v /data/output:/workspace/output \ --name lora-train \ my-lora-image
几个参数值得注意。--shm-size 很容易被忽略，DataLoader 的多进程加载依赖共享内存，默认的 64MB 在训练时会直接报 "bus error"，一般给到 8G 到 16G 比较稳妥。-v 挂载把宿主机目录映射进容器，训练产出的 checkpoint 会直接写到宿主机的输出目录，容器删了数据也不丢。
多卡训练时，可以用 --gpus '"device=0,1"' 指定具体显卡，再配合 accelerate 的分布式启动方式。要注意容器内看到的卡号和宿主机是一致的，方便和 nvidia-smi 的输出对照排查显存占用。
LoRA 微调中的显存优化与常见问题
容器本身不会增加额外显存开销，但把量化加载用起来才能在小显存卡上跑 LoRA。典型做法是用 bitsandbytes 做 4bit 量化加载，配合 LoRA 只训练旁路参数，一张 24G 的卡可以微调 7B 到 13B 级别的模型。示例代码：
import torch
from transformers import AutoModelForCausalLM, BitsAndBytesConfig
from peft import LoraConfig, get_peft_model
# 4bit 量化配置
bnb_config = BitsAndBytesConfig(
load_in_4bit=True,
bnb_4bit_quant_type="nf4",
bnb_4bit_compute_dtype=torch.bfloat16,
)
model = AutoModelForCausalLM.from_pretrained(
"/workspace/models/qwen2-7b",
quantization_config=bnb_config,
device_map="auto",
)
# LoRA 配置
lora_config = LoraConfig(
r=16,
lora_alpha=32,
target_modules=["q_proj", "k_proj", "v_proj", "o_proj"],
lora_dropout=0.05,
)
model = get_peft_model(model, lora_config)
model.print_trainable_parameters()容器环境下有几个高频报错需要知道怎么排查。一是容器内运行 nvidia-smi 报 "could not select driver"，基本是 NVIDIA Container Toolkit 没装好或 Docker 没重启；二是 bitsandbytes 报 CUDA 版本不匹配，检查镜像内的 CUDA 运行时版本是否和库的编译版本一致；三是训练中途被 kill，通常是容器内存限制或共享内存不足，前者调整 --memory 参数，后者加大 --shm-size。
另外建议把训练日志和 checkpoint 输出统一挂载到宿主机，配合 --restart=unless-stopped 可以在意外断电后自动恢复容器。如果训练任务需要长期迭代，还可以进一步用 docker compose 管理启动配置，把挂载路径、GPU 分配、环境变量写成 yaml 文件，团队协作时直接共享这份配置即可，这也是容器化工作流的自然延伸。