📚 课程目录第3章部署环境准备

3、部署环境准备：本地硬件选型（GPU/内存/存储）、操作系统与驱动配置、Python环境与CUDA/cuDNN安装、Docker基础

大模型部署并非单纯的软件工程问题，其底层依赖的硬件资源、操作系统、驱动栈与容器化环境，直接决定了推理延迟、吞吐量以及后续运维的复杂度。本章将围绕“本地硬件选型→系统与驱动→Python与CUDA/cuDNN→Docker封装”这条主线，构建一套可复现、可扩展的部署环境基线。无论你是在单卡工作站上进行原型验证，还是在多卡服务器上承载生产流量，理解每一层的选型逻辑与配置陷阱，都是避免“模型能跑但跑不快、能部署但难维护”的关键前提。

上图展示了部署环境的四层依赖关系。硬件层是物理底座，决定了性能上限；系统与驱动层负责让操作系统“看见”并高效调度GPU；运行时层为深度学习框架提供数学库与执行环境；容器化层则解决环境迁移与依赖隔离问题。下面我们逐层深入。

3.1 本地硬件选型：GPU/内存/存储的工程权衡

核心原理：大模型部署的硬件瓶颈通常不在CPU，而在GPU显存容量、内存带宽和存储IOPS。显存决定了能否装下模型权重及KV Cache；内存带宽影响批量推理时的数据搬运效率；存储则决定了模型加载时间和checkpoint读写速度。选型时必须从“模型规模×并发请求数”出发，而不是单纯追求旗舰卡。

判断方法：首先估算显存需求。以7B参数模型为例，FP16权重占用约14GB，推理时KV Cache按序列长度和batch size动态增长，通常预留20-30%冗余。若采用INT8量化，显存需求可降至约7GB，但需额外考虑反量化开销。其次，内存容量建议为显存的2-4倍，用于承载CPU offload和预处理数据。存储方面，NVMe SSD是底线，模型加载速度可从HDD的分钟级提升至秒级。

硬件维度	入门级（原型验证）	进阶级（单机生产）	专家级（多卡集群）
GPU	RTX 4060 Ti 16GB	RTX 4090 24GB / A6000 48GB	A100 80GB × 4 / H100
内存	32GB DDR5	64GB DDR5 ECC	256GB DDR5 ECC
存储	1TB NVMe	2TB NVMe + 4TB HDD	4TB NVMe RAID + 对象存储
网络	千兆以太网	万兆以太网	InfiniBand 200Gbps
适用场景	7B模型单卡推理	13B模型高并发	70B模型张量并行

风险提示：消费级GPU（如RTX系列）的驱动与CUDA支持通常滞后于数据中心卡，且缺乏ECC内存和更大的显存带宽。若计划长期承载生产流量，建议至少使用RTX 4090或专业级A系列，避免因显存溢出导致服务中断。

案例拆解：某团队需部署13B Chat模型，目标并发32路请求，单请求输出长度512 。经计算，模型FP16权重占26GB，KV Cache在batch=32时约需8GB，加上激活值等开销，单卡需40GB以上显存。最终选择A6000 48GB，内存配128GB，存储采用2TB NVMe。实测模型加载时间从HDD的4分钟降至25秒，首延迟从1.2秒降至0.4秒。

常见误区：只看GPU显存而忽略内存带宽。例如，RTX 4060 Ti虽有16GB显存，但带宽仅288GB/s，远低于A6000的768GB/s，导致高并发时数据搬运成为瓶颈。此外，存储仅考虑容量而忽略IOPS，导致checkpoint频繁写入时卡顿。

3.2 操作系统与驱动配置：稳定优先

核心原理：操作系统是驱动与运行时的载体。Ubuntu Server LTS版本因其稳定的内核、广泛的硬件兼容性和NVIDIA官方支持，成为大模型部署的事实标准。驱动层负责将CUDA调用翻译为GPU指令，其版本必须与CUDA Toolkit及GPU架构匹配。

操作流程：推荐使用Ubuntu 22.04 LTS，安装时选择“最小安装”并开启SSH。驱动安装有两种路径：一是通过apt安装NVIDIA官方仓库的驱动，二是使用runfile手动安装。前者便于维护，后者更可控。安装后需验证：

# 检查GPU是否被识别
lspci | grep -i nvidia
# 安装驱动（以535版本为例）
sudo apt install nvidia-driver-535
# 重启后验证
nvidia-smi
# 设置持久化模式（避免驱动休眠）
sudo nvidia-smi -pm 1
# 锁定驱动版本，防止自动更新
sudo apt-mark hold nvidia-driver-535

案例拆解：某团队在DELL R750服务器上安装Ubuntu 20.04，使用apt安装驱动后，nvidia-smi报错“No devices were found”。排查发现是内核模块与GPU的PCIe Resizable BAR不兼容。解决方案：在BIOS中开启“Above 4G Decoding”和“Resizable BAR”，并更新内核至5.15+。此案例说明，驱动问题往往需要结合BIOS设置和内核版本综合排查。

经验提醒：生产服务器建议关闭图形界面（systemctl set-default multi-user.target），并禁用NVIDIA的电源管理（nvidia-smi -pm 1），避免GPU进入低功耗状态导致推理延迟抖动。

常见误区：盲目追求最新驱动版本。新驱动可能引入回归问题，且与已安装的CUDA版本不兼容。建议遵循“驱动版本 ≥ CUDA最低要求”的原则，并查阅NVIDIA官方兼容矩阵。

3.3 Python环境与CUDA/cuDNN安装：精确匹配

核心原理：Python环境是深度学习框架的载体，CUDA Toolkit提供GPU编程API，cuDNN则针对卷积和循环神经网络进行深度优化。三者版本必须精确匹配，否则会出现“CUDA error: no kernel image is available”等难排查的错误。

判断方法：首先确定框架版本（如PyTorch 2.1），然后根据其官方文档选择对应的CUDA版本（如CUDA 12.1），再匹配cuDNN版本（如8.9.2）。使用虚拟环境（如conda或venv）隔离不同项目的依赖，避免系统级Python被污染。

# 创建虚拟环境
conda create -n llm_deploy python=3.10
conda activate llm_deploy
# 安装CUDA Toolkit（仅运行时，不覆盖系统驱动）
conda install cudatoolkit=12.1
# 安装cuDNN
conda install cudnn=8.9.2
# 安装PyTorch（匹配CUDA 12.1）
pip install torch==2.1.0 --index-url https://download.pytorch.org/whl/cu121
# 验证CUDA可用性
python -c "import torch; print(torch.cuda.is_available()); print(torch.cuda.get_device_name(0))"

案例拆解：某团队在部署vLLM时，发现torch.cuda.is_available()返回True，但运行推理时立即崩溃。日志显示“CUDA error: invalid device ordinal”。排查发现，系统中有多张GPU，但CUDA_VISIBLE_DEVICES环境变量未设置，导致PyTorch尝试访问不存在的设备。解决：在启动脚本中显式指定export CUDA_VISIBLE_DEVICES=0,1。此案例说明，环境变量管理是部署中易被忽视的环节。

组件	版本选择原则	验证命令	常见错误
Python	3.10或3.11（框架兼容性最好）	python --version	语法不兼容
CUDA Toolkit	与框架官方文档一致	nvcc --version	驱动版本过旧
cuDNN	与CUDA版本配套	python -c "import cudnn"	libcudnn.so缺失
PyTorch	优先使用官方预编译包	torch.version.cuda	CUDA runtime不匹配

风险提示：不要混用conda的cudatoolkit和系统级CUDA。conda的CUDA是用户态库，不依赖系统驱动，但若同时安装系统级CUDA，可能导致LD_LIBRARY_PATH冲突。建议在虚拟环境中统一使用conda包，并避免设置全局LD_LIBRARY_PATH。

常见误区：认为CUDA版本越高越好。实际上，某些框架（如TensorRT）对CUDA版本有严格上限，过高版本可能导致兼容性错误。此外，忽略cuDNN的版本匹配，导致推理性能下降30%以上。

3.4 Docker基础：环境隔离与GPU直通

核心原理：Docker通过容器化技术将应用及其依赖打包为镜像，实现“一次构建，到处运行”。在大模型部署中，Docker的核心价值在于：隔离不同项目的CUDA/Python依赖，避免“环境地狱”；通过NVIDIA Container Toolkit实现GPU直通，使容器内可直接访问GPU资源。

操作流程：首先安装Docker Engine，然后安装NVIDIA Container Toolkit，最后运行带GPU支持的容器。

# 安装Docker Engine（以Ubuntu为例）
curl -fsSL https://get.docker.com | sh
sudo systemctl enable --now docker
# 安装NVIDIA Container Toolkit
distribution=$(. /etc/os-release;echo $ID$VERSION_ID)
curl -s -L https://nvidia.github.io/nvidia-docker/gpgkey | sudo apt-key add -
curl -s -L https://nvidia.github.io/nvidia-docker/$distribution/nvidia-docker.list | sudo tee /etc/apt/sources.list.d/nvidia-docker.list
sudo apt-get update && sudo apt-get install -y nvidia-container-toolkit
sudo systemctl restart docker
# 运行GPU容器测试
docker run --rm --gpus all nvidia/cuda:12.1.0-base-ubuntu22.04 nvidia-smi

案例拆解：某团队需要同时部署PyTorch 1.13（CUDA 11.7）和PyTorch 2.1（CUDA 12.1）两个服务。若直接安装在宿主机上，依赖冲突不可避免。通过Docker，分别构建两个镜像，并映射不同端口，实现完全隔离。关键配置如下：

# docker-compose.yml 片段
services:
  llm_v1:
    image: llm_service:v1
    ports: ["8001:8000"]
    deploy:
      resources:
        reservations:
          devices:
            - driver: nvidia
              count: 1
              capabilities: [gpu]
  llm_v2:
    image: llm_service:v2
    ports: ["8002:8000"]
    deploy:
      resources:
        reservations:
          devices:
            - driver: nvidia
              count: 1
              capabilities: [gpu]

常见误区：在容器内重新安装NVIDIA驱动。容器共享宿主机的内核驱动，只需安装CUDA Toolkit的用户态库。此外，忽略镜像体积控制，导致每次拉取耗时数分钟。建议使用python:3.10-slim作为基础镜像，并利用Docker层缓存优化构建。

部署环境自检清单：
GPU是否被系统识别（lspci + nvidia-smi）
驱动版本是否满足CUDA要求（nvidia-smi右上角）
Python虚拟环境是否激活（which python）
PyTorch能否调用GPU（torch.cuda.is_available()）
Docker能否直通GPU（docker run --gpus all）
存储IOPS是否满足模型加载需求（dd if=/dev/zero of=test bs=1M count=1024）

总结复盘：部署环境准备的核心是“版本匹配”与“资源量化”。硬件选型需从模型规模和并发需求反推，操作系统与驱动需保持稳定优先，Python与CUDA/cuDNN需精确对齐框架要求，Docker则提供了最终的隔离与可移植性保障。建议在正式部署前，使用本章的自检清单逐项验证，避免在后续调优阶段才暴露环境问题，导致排查成本成倍增加。