6.12 AI 基础设施基础——GPU、CUDA 与模型服务

预计阅读时间：14 分钟

学习目标

学完本章后，你将能够：

• 理解 GPU 的硬件架构和 CUDA 软件栈的层次关系
• 在 Linux 上安装 NVIDIA 驱动并验证 GPU 可用性
• 使用 NVIDIA Container Toolkit 让 Docker 容器访问 GPU
• 部署 vLLM 和 Triton Inference Server 提供推理服务
• 使用 nvidia-smi 和 DCGM 监控 GPU 健康状态和性能
• 排查常见的 GPU/CUDA 错误和性能瓶颈

核心知识

• GPU（Graphics Processing Unit）——最初为图形渲染设计的并行处理器，因大量 CUDA 核心适合矩阵运算，成为 AI 加速的核心硬件
• CUDA（Compute Unified Device Architecture）——NVIDIA 的并行计算平台和编程模型，允许开发者用 C/C++ 直接调用 GPU 进行计算
• cuDNN（CUDA Deep Neural Network Library）——NVIDIA 针对深度神经网络优化的 GPU 加速库，提供卷积、归一化、激活函数等高性能实现
• NVIDIA Driver——操作系统与 GPU 硬件之间的通信层，包含内核模块（nvidia.ko）和用户空间库（libcuda.so）
• NVIDIA Container Toolkit——在容器中暴露 GPU 设备文件的工具链，核心是 nvidia-container-runtime 和 nvidia-container-cli
• vLLM——高性能 LLM 推理引擎，核心创新是 PagedAttention（分页显存管理），支持连续批处理和流式输出
• Triton Inference Server——NVIDIA 官方的多模型推理服务框架，支持 TensorRT/ONNX/PyTorch 等多种后端
• DCGM（Data Center GPU Manager）——NVIDIA 的数据中心 GPU 管理工具，提供比 nvidia-smi 更细粒度的遥测和健康检查

知识关联

• 前置知识：了解 Linux 包管理（apt/yum）、Docker 基本用法（3.1：Docker 容器入门）、命令行基础
• 后续影响：本章的 GPU 环境是运行 LLM 训练/推理、模型微调、生成式 AI 应用的硬件基础
• 配套技术：nvidia-smi/DCGM 用于监控，可配合 Prometheus/Grafana 构建 GPU 仪表盘
• 在整个体系中的位置：AI 基础设施的底层——GPU 硬件层 → 驱动/CUDA 层 → 容器运行时 → 推理框架 → 上层应用

原理讲解

1. GPU 硬件架构——从图形卡到 AI 加速器

GPU 与传统 CPU 的设计哲学截然不同：CPU 追求低延迟串行执行（几十个强大核心），GPU 追求高吞吐并行计算（数千个精简核心）。

NVIDIA GPU 内部以 SM（Streaming Multiprocessor） 为基本计算单元。每个 SM 包含一组 CUDA 核心、共享内存、寄存器文件和 warp 调度器。以 A100 为例：108 个 SM × 64 个 CUDA 核心/SM = 6912 CUDA 核心。GPU 在执行矩阵乘法（AI 推理的核心算力）时，数千个线程同时计算，做到"乘法比加法还快"的并行效果。

2. CUDA 软件栈——从驱动到框架的四层结构

在 Linux 上运行 AI 模型，涉及从硬件到应用的完整软件栈：

关键认知：驱动是唯一需要直接安装在宿主机上的组件。CUDA 工具链和加速库可以装在 Docker 容器内（通过 NVIDIA Container Toolkit 暴露驱动），这就是"驱动在宿主机、CUDA 在容器"的最佳实践。

3. nvidia-smi 指标解读——读懂 GPU 健康状态

nvidia-smi 是运维 GPU 服务器最常用的工具。理解每一列的真正含义比跑出数字更重要：

4. vLLM 推理架构——PagedAttention 与连续批处理

vLLM 是目前最流行的 LLM 推理引擎。它的两个核心创新让 GPU 显存利用率大幅提升：

PagedAttention：传统方案为每个请求的 KV Cache 预分配连续显存（类似内存碎片问题），PagedAttention 像操作系统的分页机制——将 KV Cache 分成固定大小的 block，按需分配、非连续存储，消除了内部碎片。

Continuous Batching：传统方案等一批请求全部完成后才切换下一批；Continuous Batching 在每个推理 step 后动态调度——已完成请求离开、新请求加入队列，最大化 GPU 利用。

5. 多卡并行——模型放不下单张卡时的三种切法

大模型（70B+）单卡放不下时，需要把模型或数据拆分到多张 GPU。三种主流并行方式对应三种"切法"：

vLLM 推理场景通常只涉及 张量并行（--tensor-parallel-size），因为它对显存的改善最直接。注意两个反直觉点：

• TP 不省总显存：7B 模型在 1 张 24G 卡上放不下时，切成 TP=2 每张卡各放一半模型权重（≈4GB）——但 KV Cache 也要按比例分配，总显存需求仍是"模型全部权重 + KV Cache"
• TP 越高通信开销越大：TP=8 时每层 attention 都要跨卡通信，PCIe 带宽会成为瓶颈。同节点优先用 NVLink；跨节点做 TP 性能会显著下降

# vLLM 多卡启动（2 张 A100 跑 70B 模型）
docker run --gpus '"device=0,1"' \
  -p 8000:8000 -v /models:/models \
  vllm/vllm-openai:v0.6.0 \
  --model /models/Qwen2.5-70B-Instruct \
  --tensor-parallel-size 2 \
  --gpu-memory-utilization 0.9

# 显存放不下时的降级路径（按性价比排序）：
# ① 量化：AWQ/GPTQ 4bit（显存减半，精度损失小）→ 首选
# ② 减小 max-model-len（限制 KV Cache 上限）
# ③ 减小 gpu-memory-utilization 并加 --swap-space（CPU offload，变慢）
# ④ 换更大显存卡 / 增加 TP 卡数

示例代码

NVIDIA 驱动安装与验证

# 检查 GPU 型号
lspci | grep -i nvidia
# 输出: NVIDIA Corporation GA102 [GeForce RTX 3080]

# 查看推荐驱动版本
ubuntu-drivers devices
# 输出:
# driver   : nvidia-driver-570 - third-party non-free recommended
# driver   : nvidia-driver-535 - third-party non-free

# 安装推荐驱动
apt update && apt install -y nvidia-driver-570
reboot

# 验证驱动
nvidia-smi
# 输出:
# +-----------------------------------------------------------------------------+
# | NVIDIA-SMI 550.xx    Driver Version: 550.xx    CUDA Version: 12.4          |
# |-------------------------------+----------------------+----------------------+
# | GPU  Name        Persistence-M| Bus-Id        Disp.A | Volatile Uncorr. ECC |
# | Fan  Temp  Perf  Pwr:Usage/Cap|         Memory-Usage | GPU-Util  Compute M. |
# |   0  GeForce RTX 3080    Off  | 00000000:01:00.0  On |                  N/A |
# | 30%   65°C    P0    120W / 320W|   2048MiB / 10240MiB |     45%      Default |
# +-------------------------------+----------------------+----------------------+

NVIDIA Container Toolkit 配置

# 安装 NVIDIA Container Toolkit
curl -fsSL https://nvidia.github.io/libnvidia-container/gpgkey | \
  sudo gpg --dearmor -o /usr/share/keyrings/nvidia-container-toolkit-keyring.gpg
curl -sL https://nvidia.github.io/libnvidia-container/stable/deb/nvidia-container-toolkit.list | \
  sed 's#deb https://#deb [signed-by=/usr/share/keyrings/nvidia-container-toolkit-keyring.gpg] https://#g' | \
  sudo tee /etc/apt/sources.list.d/nvidia-container-toolkit.list

apt update && apt install -y nvidia-container-toolkit
systemctl restart docker

# 验证 GPU 在容器中可访问
docker run --gpus all nvidia/cuda:12.4-runtime-ubuntu22.04 nvidia-smi

# 指定特定 GPU
docker run --gpus '"device=0"' nvidia/cuda:12.4-runtime-ubuntu22.04 nvidia-smi

# 检查 nvidia-container-cli 是否正常工作
nvidia-ctk cdi list
# 输出: nvidia.com/gpu=0  (列出可用 GPU)

vLLM 推理服务部署

# 启动 vLLM（Docker）
docker run --gpus all \
  -p 8000:8000 \
  -v /path/to/models:/models \
  vllm/vllm-openai:v0.6.0 \
  --model /models/Qwen2.5-7B-Instruct \
  --tensor-parallel-size 1 \
  --gpu-memory-utilization 0.9 \
  --max-model-len 8192

# 调用推理接口（兼容 OpenAI API）
curl http://localhost:8000/v1/chat/completions \
  -H "Content-Type: application/json" \
  -d '{
    "model": "Qwen2.5-7B-Instruct",
    "messages": [{"role": "user", "content": "用文言文写一段 Linux 的简介"}],
    "temperature": 0.7,
    "max_tokens": 512
  }'

GPU 监控——nvidia-smi 与 DCGM

# 实时监控
watch -n 1 nvidia-smi

# 详细指标（DCGM）
apt install -y datacenter-gpu-manager
dcgmi group -c all
dcgmi dmon -e 1001,1002,1003,1004
# 输出: GPU 温度、功耗、显存带宽利用率

# Prometheus GPU Exporter（容器化）
docker run -d --gpus all --restart unless-stopped \
  -p 9835:9835 \
  nvidia/dcgm-exporter:latest
# Prometheus 抓取: http://localhost:9835/metrics
# 关键指标: DCGM_FI_DEV_GPU_UTIL, DCGM_FI_DEV_MEM_COPY_UTIL, DCGM_FI_DEV_POWER_USAGE

Triton Inference Server 配置

# docker-compose.yml
services:
  triton:
    image: nvcr.io/nvidia/tritonserver:24.06-py3
    command: tritonserver --model-repository=/models --http-port=8000 --grpc-port=8001
    ports:
      - "8000:8000"
      - "8001:8001"
    volumes:
      - ./models:/models
    deploy:
      resources:
        reservations:
          devices:
            - driver: nvidia
              count: all
              capabilities: [gpu]

GPU 故障排查流程——从现象到根因

# 场景：模型推理突然报错或变慢，按以下顺序排查

# 第一步：确认 GPU 还在不在（驱动层面）
nvidia-smi
# 失败 → 驱动问题：dmesg | grep -i nvidia 查内核报错，重启或重装驱动
# 成功 → 看 Perf 列：P0（全速）/ P2-P3（降频）/ P8（空闲）

# 第二步：确认硬件健康（温度/功耗/ECC）
nvidia-smi -q -d TEMPERATURE,POWER,ECC
# 温度 > 85°C → 散热问题（清灰/机房空调/降功耗 nvidia-smi -pl 250）
# Uncorr ECC > 0 → 显存损坏，申请换卡

# 第三步：确认是"算不动"还是"等数据"（计算 vs 带宽）
nvidia-smi --query-gpu=utilization.gpu,utilization.memory --format=csv
# gpu 高 + memory 低 → 计算密集，正常（如训练）
# gpu 低 + memory 高 → 显存带宽瓶颈（如长序列推理）
# 两者都低 → 进程在等 CPU/磁盘/网络（数据加载慢、单请求串行）

# 第四步：确认进程与显存占用
nvidia-smi --query-compute-apps=pid,used_memory --format=csv
fuser -v /dev/nvidia0    # 谁占用了 GPU 0
# 显存碎片化：重启推理服务进程是最快的清理手段

# 第五步：核对日志与配置
# 推理服务日志中找 CUDA OOM / NCCL timeout / DRIVER version mismatch
# NCCL timeout → 多卡通信异常：检查 NVLink 状态（nvidia-smi nvlink -s）

常见错误

最佳实践

练习题

1. （概念）解释 GPU 和 CPU 在架构设计上的根本差异。为什么 GPU 适合 AI 推理而 CPU 不适合？
2. （概念）"驱动在宿主机、CUDA 在容器"是什么意思？这样做的好处是什么？
3. （概念）解释 vLLM 的 PagedAttention 如何提高显存利用率。
4. （实操）在 Linux 上安装 NVIDIA 驱动，运行 nvidia-smi 并记录输出的 GPU 型号、驱动版本、CUDA 版本、显存总量。
5. （实操）部署 NVIDIA Container Toolkit，运行 docker run --gpus all nvidia/cuda:12.4-runtime-ubuntu22.04 nvidia-smi 验证容器内 GPU 可用。
6. （实操）使用 Docker 部署 vLLM（任意支持的小模型如 Qwen2.5-7B），通过 curl 调用 /v1/chat/completions 接口完成一次对话。
7. （探究 🔍）查看 nvidia-smi -q -d ECC 的输出，确认你的 GPU 是否有 ECC 内存和当前错误计数。
8. （探究 🔍）在容器内外分别运行 nvidia-smi，对比输出差异。思考：为什么 nvidia-smi 命令本身在容器内也能工作？

学习检查点

学完本章后，请检验自己是否掌握以下内容：

本章总结

GPU 是 AI 时代最核心的计算硬件。在 Linux 上运行 AI 推理的完整路径：

• 硬件层——NVIDIA GPU（CUDA 核心 + HBM 显存），通过 PCIe 与主机通信
• 驱动层——NVIDIA 驱动（nvidia.ko + libcuda.so），唯一需要装在宿主机上的组件
• 容器运行时层——NVIDIA Container Toolkit，让 Docker 暴露 GPU 设备到容器
• 推理框架层——vLLM（PagedAttention + Continuous Batching）或 Triton Inference Server
• 监控层——nvidia-smi（即时）、DCGM Exporter + Prometheus（持续）

速查表

下一步：掌握本章的 GPU 基础设施后，可以继续学习模型微调（LoRA/QLoRA）、多机多卡推理部署、以及 GPU 虚拟化/分片技术。

延伸阅读