3. 部署环境准备：硬件要求（CPU/GPU）、操作系统、网络配置、依赖软件安装

推理服务部署的第一步不是拉取镜像或编写代码，而是确认目标环境是否具备承载模型推理的能力。与训练阶段追求高吞吐不同，推理阶段更关注延迟、并发响应和持续稳定性。环境准备不充分，后续的压测、扩容、故障排查都会失去可靠基础。本节从硬件选型、操作系统、网络规划、依赖软件四个维度展开，并给出可执行的检查清单。

3.1 硬件要求：CPU 与 GPU 的选型逻辑

推理服务的硬件选型取决于模型类型、输入数据规模和实时性要求。对于 Transformer 架构的大语言模型，GPU 显存容量是第一约束；对于树模型或传统机器学习模型，CPU 多核并行能力则更为关键。

硬件维度 CPU 推理场景 GPU 推理场景
典型模型 XGBoost、LightGBM、中小规模 CNN LLaMA、Qwen、GPT 系列、Stable Diffusion
核心指标 主频 ≥ 3.0GHz，核心数 ≥ 16 显存 ≥ 模型权重 + KV Cache + 激活值
推荐配置 Intel Xeon 或 AMD EPYC，支持 AVX-512 NVIDIA A10/A100/H100，或 RTX 4090（开发测试）
内存要求 ≥ 32GB，建议 64GB 系统内存 ≥ 2 倍显存，用于加载和预处理
注意事项 避免使用低主频云主机（如 burstable 实例） 确认 GPU 驱动支持 CUDA 版本，显存不足时需量化或切分

显存估算公式（以 7B 模型为例）：FP16 权重约 14GB，KV Cache 按序列长度 2048、batch size 8 计算约 4GB，加上 CUDA context 和激活值，单卡 24GB 是安全起点。若使用 INT8 量化，权重降至 7GB，可适配 16GB 显存设备。

实操建议：在采购或申请资源前，先用 nvidia-smi 查看实际可用显存，并运行一次小 batch 的推理测试，观察显存峰值占用，再决定是否需要调整 batch size 或启用显存优化策略。
推理服务硬件选型决策流程 模型类型与规模 参数量 / 输入维度 是否 Transformer? 是 GPU 推理 显存 = 权重 + KV Cache ≥ 24GB: 7B FP16 ≥ 48GB: 13B / 量化 否 CPU 推理 树模型 / 传统 ML ≥ 16 核 / AVX-512 内存 ≥ 32GB 延迟与并发评估 P95 < 500ms? 满足 → 部署 不满足 → 扩容/优化 关键检查命令 nvidia-smi | lscpu | free -h | df -h /models

3.2 操作系统与基础环境配置

推理服务对操作系统的要求集中在内核版本、GPU 驱动兼容性和文件系统支持三个方面。生产环境推荐使用 Ubuntu 20.04 LTS 或 22.04 LTS，这两者拥有最完整的 CUDA 生态支持。CentOS 7 已停止维护，不建议新项目使用。

# 操作系统版本确认（Ubuntu/Debian）
cat /etc/os-release
uname -r

# 内核参数优化（追加到 /etc/sysctl.conf）
net.core.somaxconn = 65535
net.ipv4.ip_local_port_range = 1024 65535
vm.max_map_count = 262144
fs.file-max = 1048576

# 生效
sysctl -p

GPU 驱动安装是操作系统准备中最容易出错的环节。务必遵循“驱动 → CUDA → cuDNN → 推理框架”的顺序。驱动版本必须高于 CUDA 要求的最低版本，否则会出现 CUDA driver version is insufficient 错误。

常见陷阱：不要使用系统包管理器（如 apt install nvidia-driver）自动安装最新驱动，这可能导致与已安装的 CUDA 工具链不兼容。建议从 NVIDIA 官网下载对应型号的 runfile 驱动，或使用 nvidia-driver-535 等固定版本。

3.3 网络配置：端口、防火墙与内网通信

推理服务的网络配置需要同时考虑外部访问入口和内部组件通信。外部访问通常通过 API 网关暴露 80/443 端口，内部推理服务监听 8000-9000 范围内的随机端口。若使用 Kubernetes 部署，还需配置 NodePort 或 LoadBalancer。

通信方向 协议 端口范围 用途
客户端 → 网关 HTTPS 443 外部 API 请求入口
网关 → 推理服务 HTTP/gRPC 8000-8500 内部请求转发
推理服务 → 模型存储 NFS/S3 2049/443 加载模型权重
推理服务 → 数据库 TCP 3306/5432 记录调用日志与结果 
# 防火墙配置示例（UFW）
sudo ufw allow 443/tcp        # 外部 HTTPS
sudo ufw allow 8000:8500/tcp  # 内部推理端口段
sudo ufw allow from 10.0.0.0/8 to any port 2049  # NFS 内网白名单
sudo ufw enable

网络延迟对推理性能的影响常被低估。若模型存储与推理节点跨机房，每次冷启动加载 7B 模型（约 14GB）在 1Gbps 网络下需要约 2 分钟，而 10Gbps 内网仅需 12 秒。因此模型文件应尽量与推理节点同机房或使用高速内网。

3.4 依赖软件安装：Python、CUDA 与推理框架

依赖软件安装的核心原则是版本锁定与隔离。推理服务通常使用 Python 3.9-3.11，配合虚拟环境或 Docker 容器避免系统级依赖冲突。CUDA 版本需与 PyTorch/TensorRT 的预编译包严格对应。

# 1. 安装 Python 虚拟环境
python3 -m venv /opt/inference-env
source /opt/inference-env/bin/activate

# 2. 安装 PyTorch（以 CUDA 12.1 为例）
pip install torch==2.1.0 torchvision==0.16.0 \
  --index-url https://download.pytorch.org/whl/cu121

# 3. 验证 GPU 可用性
python -c "import torch; print(torch.cuda.is_available())"
# 输出应为 True

# 4. 安装推理服务框架（以 vLLM 为例）
pip install vllm==0.4.0

# 5. 验证 CUDA 与 cuDNN
python -c "import torch; print(torch.backends.cudnn.version())"
推荐依赖清单（生产环境）：
  • Python 3.10 + pip 23.x
  • CUDA 12.1 + cuDNN 8.9
  • PyTorch 2.1.x 或 TensorRT 8.6
  • 推理框架：vLLM / Triton / FastAPI + Uvicorn
  • 监控：Prometheus + Grafana（可选）

3.5 案例复盘：一次因环境不一致导致的部署事故

某团队在开发环境完成推理服务调试后，直接部署到生产服务器。开发机使用 RTX 4090（驱动版本 545，CUDA 12.3），生产机为 A10（驱动版本 470，CUDA 11.4）。服务启动时报错：

RuntimeError: CUDA error: no kernel image is available for execution on the device
  CUDA kernel errors might be asynchronously reported at some other API call

根因是 PyTorch 2.1 的 cu121 预编译包需要 CUDA 12.1+ 驱动，而生产机驱动仅支持 CUDA 11.4。排查过程耗时 3 小时，最终通过升级生产机驱动至 535 版本解决。

复盘要点：

  • 环境准备阶段必须使用 nvidia-smi 核对驱动版本与 CUDA 版本的对应关系
  • 建立环境基线文档，记录操作系统、驱动、CUDA、Python、框架的精确版本
  • 部署前执行 python -c "import torch; print(torch.cuda.get_device_name(0))" 验证设备可见性
  • 使用 Docker 镜像固化环境，避免开发与生产环境漂移
环境检查清单（部署前逐项确认）：
  1. GPU 显存 ≥ 模型预估需求 × 1.5 倍余量
  2. CPU 核心数 ≥ 8，主频 ≥ 2.5GHz
  3. 系统内存 ≥ 显存 × 2
  4. 磁盘剩余空间 ≥ 模型大小 × 3（含临时文件）
  5. 操作系统为 Ubuntu 20.04/22.04 LTS
  6. NVIDIA 驱动 ≥ 535，CUDA ≥ 12.1
  7. 防火墙放行所需端口，内网互通测试通过
  8. Python 虚拟环境已创建，依赖版本锁定

环境准备是推理服务部署中最“枯燥”却最关键的环节。硬件不达标导致推理延迟超标，操作系统不兼容导致驱动安装失败，网络配置错误导致模型加载超时，依赖版本冲突导致运行时崩溃——这些问题一旦进入生产阶段，排查成本将成倍增加。建议将上述检查清单固化为自动化脚本，在每次部署前执行，确保环境基线一致。

← 上一章 📖 返回目录 下一章 →