4. GPU部署环境构建与基线固化
模型在开发机上跑通，并不等于在部署环境里能跑通。GPU 部署环境是一条自底向上的依赖链：内核态驱动 → 用户态 CUDA 运行时 → 深度学习加速库（cuDNN、TensorRT 等）→ 框架（PyTorch/TensorFlow）→ 模型代码与算子。任何一层版本错配，都可能表现为“能 import 但 kernel 报错”“精度漂移”“随机崩溃”。本节的目标不是把环境装起来，而是把环境固化成一个可复现、可验证、可回滚的基线。
一、先理清版本约束链，再动手安装
GPU 环境最容易踩的坑是“版本看起来都对，组合起来不对”。正确的顺序是先确定硬件与驱动能力上限，再向下选择 CUDA，再选择 cuDNN 与框架版本。关键约束关系如下：
- 驱动版本决定 CUDA 上限：驱动向下兼容，即高版本驱动可运行低版本 CUDA 运行时，反之不行。可用
nvidia-smi右上角显示的 “CUDA Version” 作为该驱动支持的最高运行时版本。 - CUDA 运行时与框架绑定：PyTorch 官方 wheel 会绑定特定 CUDA 版本（如 cu118、cu121），不能随意替换。
- cuDNN 与 CUDA 主版本强绑定：cuDNN 8.x 对应 CUDA 11.x，cuDNN 9.x 对应 CUDA 12.x，跨主版本通常不可用。
- 算力架构（Compute Capability）：编译或选择镜像时需匹配目标卡，例如 A100 为 sm_80，H100 为 sm_90，若镜像未包含对应架构，会出现 “no kernel image is available”。
下面这张图给出本节的核心对象关系：从物理 GPU 到模型进程的依赖链，以及每一层需要锁定的版本信息与验证命令。
二、容器镜像：把环境变成不可变交付物
裸机安装的问题在于“状态会漂移”——今天 apt 升级一个包，明天 pip 装个依赖，环境就变了。容器镜像的价值是把整条依赖链冻结成一个带摘要（digest）的不可变对象。推荐做法是基于 NVIDIA 官方镜像或框架官方镜像构建，而不是从 ubuntu 裸镜像开始装驱动。
一个可复现的 Dockerfile 应遵循三条原则：基础镜像用 digest 而非 tag、依赖安装分步并锁定版本、构建产物可验证。示例：
# 用 digest 锁定基础镜像，避免 tag 被覆盖
FROM nvcr.io/nvidia/pytorch:23.10-py3@sha256:abc123... AS base
# 锁定 Python 依赖，使用 hash 校验
COPY requirements.txt .
RUN pip install --no-cache-dir --require-hashes -r requirements.txt
# 复制模型与推理代码
COPY model/ /workspace/model/
COPY serve.py /workspace/
# 构建时自检：CUDA 可用 + cuDNN 版本 + 算力匹配
RUN python -c "import torch; assert torch.cuda.is_available(); \
print('CUDA:', torch.version.cuda, 'cuDNN:', torch.backends.cudnn.version())"
ENTRYPOINT ["python", "/workspace/serve.py"]构建完成后，用 docker inspect --format='{{.RepoDigests}}' 记录镜像 digest，这个 digest 就是基线的一部分。部署时只允许使用 digest 拉取，禁止使用 :latest。
三、依赖锁定：从 requirements.txt 到完整环境快照
仅锁定顶层依赖不够，因为间接依赖（transitive dependencies）也会变。推荐三层锁定策略：
- 顶层声明：
requirements.in写直接依赖，如torch==2.1.2、transformers==4.36.0。 - 完整快照：用
pip-compile --generate-hashes生成带哈希的requirements.txt，包含所有间接依赖的精确版本。 - 系统级快照：记录
apt list --installed、CUDA 包版本、cuDNN 头文件版本，写入env-manifest.json。
对于 conda 环境，使用 conda env export --no-builds 导出，但要注意 conda 的 channel 优先级也会影响解析结果，建议同时锁定 channel 顺序。
四、可复现环境验证：四层检查清单
环境构建完成后，必须通过一组可自动化的验证，才能称为“基线”。验证应覆盖从硬件到模型输出的完整链路：
| 层级 | 检查项 | 命令 / 方法 | 通过标准 |
|---|---|---|---|
| 硬件 | GPU 可见性与算力 | nvidia-smi -L | 列出预期 GPU 数量与型号 |
| 驱动 | 驱动版本与 CUDA 上限 | nvidia-smi | 驱动版本 ≥ 基线要求，CUDA Version 匹配 |
| 运行时 | CUDA / cuDNN 版本 | python -c "import torch; print(torch.version.cuda, torch.backends.cudnn.version())" | 与基线记录完全一致 |
| 算子 | 矩阵乘 + 卷积可用 | 运行小规模 torch.matmul 与 torch.nn.Conv2d | 无报错，输出 shape 正确 |
| 模型 | 推理输出一致性 | 固定输入跑模型，比对输出张量 | 与基线输出余弦相似度 > 0.9999 |
其中“模型输出一致性”是最关键的一环。建议在基线固化时保存一份黄金输入/输出对（golden input/output），每次环境变更后重新跑一遍，用数值容差判断是否退化。例如：
import torch, numpy as np
# 固定随机种子，保证输入可复现
torch.manual_seed(42)
x = torch.randn(1, 3, 224, 224).cuda()
with torch.no_grad():
y = model(x)
# 与基线输出比对
baseline = torch.load("golden_output.pt")
cos = torch.nn.functional.cosine_similarity(y.flatten(), baseline.flatten(), dim=0)
assert cos > 0.9999, f"输出漂移: cos={cos.item():.6f}"torch.backends.cudnn.benchmark=False 与 torch.backends.cuda.matmul.allow_tf32=False，再重新比对。
五、基线固化与回滚
基线不是一次性的，而是需要版本管理的。建议为每个基线分配一个 ID，格式如 gpu-base-2024Q4-v1，并记录以下内容：镜像 digest、驱动版本、CUDA/cuDNN 版本、框架版本、依赖快照哈希、黄金输入输出哈希、验证通过时间与执行人。当新环境验证失败时，直接回滚到上一个基线镜像即可，不需要重新排查依赖。
总结来说，GPU 部署环境构建的核心不是“装上去”，而是“锁得住、验得了、回得去”。驱动、CUDA、cuDNN、镜像、依赖五层各自锁定版本，再用四层验证确认整条链路一致，最后把结果固化成带 ID 的基线。这样，模型部署才具备工程意义上的可复现性。