主题
第一部分 GPU 与 AI 算力基础（第 1~4 章）
本部分是整本教材的起点。即使你对 GPU 一无所知也没有关系——我们会从"GPU 是什么、AI 为什么离不开它"讲起，逐步认识 NVIDIA GPU 硬件、CUDA 软件生态，以及训练、推理等 AI 工作负载的特征。学完后，你将具备学习后续驱动安装、K8s 调度、监控排障所需的全部背景知识。
第 1 章 为什么 AI 需要 GPU
本章目标
- 理解 CPU 与 GPU 在设计哲学上的本质区别
- 了解 GPU 并行计算的基本原理（SIMT、海量核心、高显存带宽）
- 理解 AI 大模型对算力需求的量级，掌握 FLOPs 这一基本概念
- 明确 GPU 集群运维工程师的角色定位与职业价值
1.1 CPU 与 GPU 的本质区别
一个类比：一位教授 vs 一万名小学生
想象你要完成一项任务：计算一万道加减乘除算术题。
- 方案 A（CPU 的思路）：请一位数学教授来做。教授做题极快，还能处理复杂的证明题，但他一次只能做一道题，做完一道再做下一道。一万道题要花不少时间。
- 方案 B（GPU 的思路）：请一万名小学生，每人分一道题，老师一声令下同时开始。虽然每个小学生做题比教授慢得多，但一万道题几乎在同一瞬间就完成了。
这就是 CPU 与 GPU 的本质区别：
| 对比维度 | CPU（中央处理器） | GPU（图形处理器） |
|---|---|---|
| 核心数量 | 几个到上百个（服务器级） | 数千到上万个 |
| 单个核心能力 | 强，擅长复杂逻辑、分支判断 | 弱，只做简单运算 |
| 擅长任务 | 串行、逻辑复杂的任务 | 并行、结构单一的重复计算 |
| 设计目标 | 低延迟，快速响应各种指令 | 高吞吐，同时完成海量计算 |
CPU 的设计目标是把一件复杂的事情尽快做完（低延迟）；GPU 的设计目标是把海量简单的事情同时做完（高吞吐）。
为什么 AI 计算恰好适合 GPU
深度学习的核心运算是矩阵乘法：神经网络的每一层，本质上都是输入向量与权重矩阵相乘，再加激活函数。矩阵乘法有一个美妙的特点——结果矩阵中每个元素的计算互相独立，天然可以被拆分成成千上万份同时计算。
而且神经网络计算量大但逻辑简单：没有复杂的 if-else 分支，就是一遍遍做"乘加、乘加"。这正是"一万名小学生"最擅长的场景。
一句话总结：AI 计算 = 海量、简单、可并行的矩阵运算；GPU = 为海量并行简单计算而生的芯片。两者是天作之合。
1.2 GPU 并行计算原理简述
作为运维工程师，你不需要会写 CUDA 程序，但需要理解 GPU 的几个基本概念，否则后面看不懂硬件规格表。
海量核心：SM 与 CUDA Core
NVIDIA GPU 内部由许多个 SM（Streaming Multiprocessor，流式多处理器） 组成，每个 SM 里又包含几十个到一百多个 CUDA Core（最基本的浮点运算单元）。一块数据中心 GPU 的 CUDA Core 总数通常在数千到上万个量级——这就是"一万名小学生"。
SIMT：单指令多线程
GPU 采用 SIMT（Single Instruction, Multiple Threads，单指令多线程） 的执行模式：一批线程（称为一个 warp，通常 32 个线程）同时执行同一条指令，只是各自处理不同的数据。
类比：老师（指令发射器）喊"所有人算自己面前那道题的加法"，全班同学（线程）同时动笔，但每人纸上的数字（数据）不同。
这解释了为什么 GPU 适合"结构单一的重复计算"：如果大家要做的"动作"各不相同，SIMT 的效率就会大打折扣。
高显存带宽：喂饱一万名小学生
光有一万名小学生还不够，还得有人飞速地把题目（数据）发到他们手上，否则大家只能干等。GPU 使用专门的高带宽显存（HBM，后面章节详述），显存带宽可达每秒数 TB 的量级，是 CPU 内存带宽的十倍以上。
运维视角：很多 GPU 任务跑不快，不是算力不够，而是"数据喂不上来"（带宽瓶颈、IO 瓶颈）。这个认知在后续性能调优章节会反复用到。
1.3 AI 大模型时代：训练与推理对算力的需求
FLOPs：衡量算力的"尺子"
FLOPs（Floating Point Operations） 指浮点运算次数，是衡量计算量和算力的基本单位：
- FLOPs（大写复数）：表示一次计算任务需要的总计算量（如"训练某模型需要 10²³ FLOPs"）
- FLOPS（大写 S 结尾）/ FLOP/s：表示每秒能完成多少次浮点运算，即算力速度
常用量级单位：
| 单位 | 含义 | 典型场景 |
|---|---|---|
| TFLOPS | 每秒 10¹² 次（万亿次） | 单块 GPU 的算力常用单位 |
| PFLOPS | 每秒 10¹⁵ 次（千万亿次） | 多台服务器合计算力 |
| EFLOPS | 每秒 10¹⁸ 次（百亿亿次） | 超算中心、大型智算中心 |
大模型训练需要多少算力
以 GPT-3 这个级别的模型（1750 亿参数）为例，业界论文估算其完整训练一次的总计算量约为 3×10²³ FLOPs 量级。
这个数字有多夸张？做一个粗略的体感计算：
- 假设一块高端数据中心 GPU 的实际有效算力约为每秒数百 TFLOPS（10¹⁴ 量级）
- 用一块卡训练一次，需要的时间以数十年计
- 因此实际训练使用数千块 GPU 组成的集群，把数十年压缩到几个月
以上仅为帮助理解量级的估算，实际数字与模型结构、并行效率、精度格式等密切相关，具体请以官方数据为准。
这就是为什么"GPU 集群"成为一个行业：单个 GPU 再强也远远不够，必须把成百上千、乃至上万块 GPU 通过网络连接起来协同工作。而让这些昂贵设备稳定高效地运转，正是运维工程师的职责。
训练 vs 推理：两种算力需求
- 训练（Training）：用海量数据反复调整模型参数，计算量极大，持续时间长（数周到数月），需要多卡多机协同。
- 推理（Inference）：模型训练好后对外提供服务（如聊天机器人回答问题），单次计算量小，但要求低延迟、高并发，且 7×24 小时在线。
两者对硬件、网络、调度方式的要求差异很大，第 4 章会详细展开。
1.4 GPU 集群运维工程师的角色与价值
你将要维护的是什么
一个 GPU 算力集群通常包含：
┌─────────────────────────────────────────────────┐
│ GPU 算力集群的组成 │
├─────────────────────────────────────────────────┤
│ GPU 服务器：每台 4~8 块 GPU，功耗数千瓦 │
│ 高速网络：InfiniBand / RoCE，200~800 Gb/s │
│ 存储系统：并行文件系统，存放训练数据和模型 │
│ 软件栈：驱动 → CUDA → 容器 → K8s → 训练框架 │
│ 平台层：任务调度、多租户、监控、计量计费 │
└─────────────────────────────────────────────────┘为什么这个角色值钱
- 资源极其昂贵：一块数据中心级 GPU 价值数万到数十万元，一个千卡集群的硬件投入以亿元计。设备闲置或故障一小时，损失的都是真金白银。
- 故障模式特殊：GPU 有 XID 错误、掉卡、ECC 显存错误、NVLink 故障等特有故障模式，传统运维经验覆盖不到。
- 技术栈深且新：从硬件、驱动到容器、K8s、RDMA 网络、AI 框架，任何一层出问题都会表现为"训练任务失败了"，定位问题需要全栈视角。
- 供不应求：AI 行业高速发展，懂 GPU 集群运维的工程师非常稀缺。
本章小结
- CPU 像"一位教授"，擅长复杂串行逻辑；GPU 像"一万名小学生"，擅长海量并行简单计算。AI 的矩阵运算恰好是后者。
- GPU 通过海量 CUDA Core + SIMT 执行模式 + 高带宽显存实现强大的并行计算能力。
- 算力用 FLOPS 衡量，大模型训练的计算量可达 10²³ FLOPs 量级，必须依靠 GPU 集群完成。
- GPU 集群运维工程师的核心价值：让昂贵的算力资源稳定、高效地运转。
动手实验与练习
- 思考题：以下任务更适合 CPU 还是 GPU？为什么？
- （a）数据库事务处理 （b）图片批量缩放 （c）操作系统调度 （d）神经网络矩阵乘法
- 概念自测：用自己的话向一位完全不懂技术的朋友解释"为什么 AI 需要 GPU"，要求用到"教授与小学生"的类比。
- 估算练习：某模型训练需要 10²³ FLOPs，单卡有效算力按 200 TFLOPS（2×10¹⁴）估算，用 1000 张卡大约需要多少秒？折算成多少天？（假设理想线性加速，实际会有折扣）
- 调研练习：打开云厂商（如阿里云、腾讯云）官网，查看 GPU 云服务器的产品页，记录 T4、A10、A100 实例的按小时价格，感受"算力的成本"。
第 2 章 NVIDIA GPU 硬件基础
本章目标
- 了解 NVIDIA GPU 架构的演进脉络及各代代表产品
- 熟悉数据中心 GPU 产品线，能说出主流型号的定位与典型场景
- 读懂 GPU 硬件规格表中的关键指标
- 理解 FP32/FP16/BF16/FP8/INT8 等精度格式的区别及使用场景
- 对国产 GPU 与 AI 芯片有基本认识
2.1 NVIDIA GPU 架构演进
NVIDIA 的 GPU 架构以科学家命名，每一代在制程、核心数量、显存技术、AI 专用单元上都有提升。作为运维工程师，了解架构演进的意义在于：看懂不同年代服务器的代际差异，理解为什么老卡跑不了新框架。
| 架构 | 发布年份 | 代表产品 | 关键特性 |
|---|---|---|---|
| Kepler | 2012 | K80、GTX 780 | 早期通用计算 GPU，已淘汰 |
| Maxwell | 2014 | M40、GTX 980 | 能效比大幅提升 |
| Pascal | 2016 | P100、P4、GTX 1080 | 首次引入 NVLink（P100）、半精度计算 |
| Volta | 2017 | V100、Titan V | 首次引入 Tensor Core（AI 专用计算单元） |
| Turing | 2018 | T4、RTX 2080 | Tensor Core 支持 INT8/INT4，推理性价比高 |
| Ampere | 2020 | A100、A10、RTX 3090 | 第三代 Tensor Core、TF32 格式、MIG 切分 |
| Ada Lovelace | 2022 | L40/L40S、RTX 4090 | 推理与图形渲染强化，FP8 支持 |
| Hopper | 2022 | H100、H200 | Transformer 引擎（FP8）、NVLink 4.0 |
| Blackwell | 2024 | B200、GB200 | 双芯封装、第二代 Transformer 引擎、NVLink 5.0 |
架构与产品的对应关系以 NVIDIA 官方发布为准。老架构（Kepler/Maxwell/Pascal）的卡在新版 CUDA 中已逐步停止支持，这是运维中"老服务器装不上新驱动"的常见原因。
记忆要点：Volta 引入 Tensor Core 是 GPU 从"图形/通用计算"转向"AI 加速"的分水岭；此后每一代的竞争焦点都围绕 AI 算力（更低精度、更高带宽、更强互联）。
2.2 数据中心 GPU 产品线
主流数据中心 GPU 一览
| 型号 | 架构 | 显存 | 功耗（TDP） | 定位与典型场景 |
|---|---|---|---|---|
| T4 | Turing | 16GB GDDR6 | 约 70W | 入门级推理卡，低功耗，云上常见 |
| V100 | Volta | 16/32GB HBM2 | 250~300W | 上一代训练主力，存量大 |
| A10 | Ampere | 24GB GDDR6 | 约 150W | 推理、轻量训练、虚拟化场景 |
| A100 | Ampere | 40/80GB HBM2e | 250~400W | 上代训练旗舰，支持 MIG 切分 |
| L40S | Ada | 48GB GDDR6 | 约 350W | 推理、AI 视觉、图形渲染 |
| H100 | Hopper | 80GB HBM3 | 350~700W | 大模型训练旗舰 |
| H200 | Hopper | 141GB HBM3e | 约 700W | 大显存推理与训练 |
| B200 | Blackwell | 约 180GB HBM3e | 1000W 级 | 新一代训练/推理旗舰 |
上表数据为大致范围，不同形态（PCIe/SXM）功耗与算力不同，具体规格以 NVIDIA 官方数据表为准。
消费级 vs 数据中心级
很多初学者会问：RTX 4090 玩游戏很强，能不能拿去训练大模型？技术上可以跑，但两者定位差异明显：
| 对比项 | 消费级（如 RTX 4090） | 数据中心级（如 A100/H100） |
|---|---|---|
| 显存类型 | GDDR（无 ECC 或有限支持） | HBM，支持 ECC 纠错 |
| 显存容量 | 24GB 左右 | 40~180GB |
| 多卡互联 | 通常无 NVLink 或受限 | 完整 NVLink/NVSwitch 支持 |
| 虚拟化/MIG | 不支持 | 支持 vGPU、MIG |
| 稳定性设计 | 间歇性高负载 | 7×24 小时满负载设计 |
| 被动散热 | 自带风扇 | 被动散热，依赖服务器风道 |
| 驱动授权 | 不允许用于数据中心（许可限制） | 正式支持 |
运维视角：数据中心级 GPU 为长期满载设计，支持 ECC 显存纠错和带外管理，这些是生产环境稳定性的基石。
2.3 GPU 关键硬件指标解读
拿到一台 GPU 服务器，你需要看懂这些指标：
CUDA Core 与 Tensor Core
- CUDA Core：通用计算单元，负责常规浮点/整数运算，数量越多通用算力越强。
- Tensor Core：AI 专用矩阵运算单元，一次完成一小块矩阵的乘加运算，AI 吞吐是 CUDA Core 的数倍到十几倍。训练/推理性能主要取决于 Tensor Core。
显存容量与带宽（HBM vs GDDR）
显存是 GPU 的"工作台"，模型参数、中间计算结果都放在显存里。
| 对比项 | GDDR（GDDR6 等） | HBM（HBM2e/HBM3/HBM3e） |
|---|---|---|
| 形态 | 分立颗粒，围绕 GPU 四周 | 多层堆叠，与 GPU 封装在同一基板上 |
| 带宽 | 数百 GB/s | 数 TB/s（高出一个数量级） |
| 成本 | 低 | 高（是数据中心卡贵的重要原因） |
| 应用 | 消费卡、推理卡（T4/A10/L40S） | 训练旗舰（V100/A100/H100/B200） |
为什么大模型训练必须大显存：训练时显存要同时装下模型参数、梯度和优化器状态。一个百亿参数级别的模型，仅这些状态就需要数百 GB 显存，必须多卡分摊。显存不够，模型根本"装不进去"，再强的算力也无用武之地。
NVLink / NVSwitch：GPU 之间的"高速公路"
- NVLink：GPU 与 GPU 之间的点对点高速直连通道，带宽远高于 PCIe（H100 的 NVLink 总带宽达 900 GB/s 量级，而 PCIe 5.0 x16 约 128 GB/s）。
- NVSwitch：NVLink 交换芯片，让一台服务器内的 8 块 GPU 实现任意两两全速互联，是 8 卡训练服务器（如 DGX/HGX）的核心部件。
类比：PCIe 是普通公路，GPU 之间通信要绕道 CPU 这个"收费站"；NVLink 是 GPU 之间的直达高铁；NVSwitch 则是让所有高铁线路互联互通的枢纽站。
TDP 功耗
TDP（热设计功耗）直接决定数据中心的供电与散热设计：一块 H100 SXM 约 700W，一台 8 卡服务器仅 GPU 就近 6kW，整机功耗可达 10kW 量级。这也是 GPU 集群机房需要专门供电、液冷改造的原因。
互联拓扑：PCIe vs SXM
| 形态 | 特点 | 典型场景 |
|---|---|---|
| PCIe 卡 | 标准插槽，通用性好，卡间通信走 PCIe 总线 | 推理服务器、轻量训练 |
| SXM 模组 | 专用插座，更高功耗上限，搭配 NVSwitch 实现全互联 | 大模型训练服务器（HGX 架构） |
用命令查看本机 GPU 拓扑（后续章节会深入学习）：
bash
# 查看 GPU 之间的互联方式（NVLink 还是 PCIe）
nvidia-smi topo -m输出中 NV# 表示 GPU 之间通过几条 NVLink 连接，PIX/PXB 表示通过 PCIe 连接。拓扑直接影响多卡训练性能。
2.4 算力单位：精度格式的区别
常见精度格式
"精度"指每个数字用多少二进制位表示。位数越少，单次计算越快、占用显存越少，但数值精度越低。
| 格式 | 位宽 | 说明 | 典型用途 |
|---|---|---|---|
| FP64 | 64 位 | 双精度，科学计算 | 超算、仿真（AI 很少用） |
| FP32 | 32 位 | 单精度，传统默认 | 早期训练、通用计算 |
| TF32 | 19 位（内部） | Ampere 引入，FP32 的加速模式 | 训练的折中方案 |
| FP16 | 16 位 | 半精度 | 训练主流（混合精度） |
| BF16 | 16 位 | 指数位与 FP32 相同，范围大不易溢出 | 大模型训练主流 |
| FP8 | 8 位 | Hopper/Ada 起支持 | 大模型训练与推理（新趋势） |
| INT8 | 8 位整数 | 量化推理 | 推理部署，吞吐翻倍 |
FP16 与 BF16 的区别（面试常考）：两者都是 16 位，但 FP16 用更多位数表示小数（精度高、范围小），BF16 用更多位数表示指数（范围大、精度略低）。大模型训练中数值范围波动大，BF16 不容易溢出，因此成为大模型训练的主流格式。
稠密算力 vs 稀疏算力
看 GPU 规格表时会发现同一格式有两个算力数字，稀疏（Sparsity）算力通常是稠密（Dense）的两倍：
- 稠密算力：老老实实计算所有数据的算力，任何任务都能达到，是"真实水平"。
- 稀疏算力：利用神经网络中大量权重为零的特点（结构化稀疏），跳过一半计算得到的理论峰值，需要特定优化才能达到。
运维与采购提示：比较不同 GPU 算力时，务必统一用稠密算力对比，并注明精度格式，否则容易被宣传数字误导。
为什么训练用 FP16/BF16、推理用 INT8/FP8
- 训练：需要反向传播更新参数，数值稳定性要求高，FP16/BF16 是速度与精度的平衡点（配合"混合精度训练"技术）。
- 推理：模型参数已固定，对精度容忍度更高，用 INT8/FP8 量化后，显存占用减半甚至更少、吞吐显著提升、成本大幅下降——这对 7×24 在线的推理服务至关重要。
2.5 国产 GPU 与 AI 芯片简介
受供应链与合规因素影响，国产 AI 芯片在国内算力中心建设中的占比持续提升，作为运维工程师很可能会接触到：
| 厂商/产品 | 软件生态 | 特点 |
|---|---|---|
| 华为昇腾（Ascend 910 系列） | CANN + MindSpore，兼容 PyTorch（torch_npu） | 生态最成熟，国产训练主力 |
| 寒武纪（MLU 系列） | Cambricon Neuware | 训练推理均有布局 |
| 海光（DCU 系列） | DTK，类 CUDA 的 HIP 路线 | 对 CUDA 代码迁移较友好 |
| 摩尔线程（MTT 系列） | MUSA | 图形+AI 双线，兼容 CUDA 生态为卖点 |
| 燧原、壁仞、天数智芯等 | 各自软件栈 | 各有侧重 |
运维上的主要差异：
- 管理工具不同：NVIDIA 用
nvidia-smi，昇腾用npu-smi，寒武纪用cnmon，海光用hy-smi - K8s 调度需要各厂商自己的 Device Plugin
- 故障码、监控指标、容器工具链各不相同，但运维方法论是相通的：驱动管理、设备发现、资源调度、监控告警、故障诊断的思路完全一致
本教材以 NVIDIA 生态为主线（市场占有率最高、资料最全），掌握后迁移到国产芯片会很快。
本章小结
- NVIDIA 架构演进：Kepler → … → Volta（首引入 Tensor Core）→ Ampere（MIG、TF32）→ Hopper（FP8、Transformer 引擎）→ Blackwell。
- 数据中心 GPU 与消费级 GPU 的核心差异：HBM 显存 + ECC、NVLink 互联、MIG/vGPU、7×24 满载设计。
- 关键指标：Tensor Core 决定 AI 算力；显存容量决定"模型装不装得下"；显存带宽和 NVLink 决定"数据喂得快不快"；TDP 决定机房供电散热。
- 精度格式：训练主流 FP16/BF16，推理主流 INT8/FP8；对比算力要看稠密算力并注明精度。
- 国产芯片生态各异，但运维方法论相通。
动手实验与练习
- 有 GPU 环境：执行以下命令，记录自己 GPU 的型号、显存、功耗：
bash
# 查看 GPU 基本信息
nvidia-smi
# 查看详细信息（架构、显存类型、功耗上限等）
nvidia-smi -q | less
# 查看 GPU 名称与显存
nvidia-smi --query-gpu=name,memory.total,power.limit --format=csv- 无 GPU 环境：执行
lspci | grep -i -E "nvidia|vga"查看本机是否有显卡；在 NVIDIA 官网查阅 H100 与 A100 的数据表（Datasheet），对比两者的显存容量、带宽和 FP16 稠密算力。 - 思考题：为什么大模型训练服务器普遍采用 SXM 形态而不是 PCIe 形态？从功耗和互联两个角度回答。
- 面试题自测：FP16 和 BF16 有什么区别？为什么大模型训练更常用 BF16？
第 3 章 CUDA 软件生态
本章目标
- 理解 CUDA 是什么，理清驱动、CUDA Toolkit、cuDNN 的层次关系
- 理解驱动版本、CUDA 版本、框架版本的兼容性概念
- 了解主流 AI 框架与 CUDA 的关系
- 理解容器时代"镜像自带 CUDA、宿主机只装驱动"的原理
3.1 CUDA 是什么
CUDA（Compute Unified Device Architecture） 是 NVIDIA 推出的并行计算平台和编程模型，是让开发者能用 GPU 做通用计算（而不只是画图）的软件基础。没有 CUDA，就没有今天的 AI 大爆发。
作为运维工程师，你需要理清 GPU 软件栈的层次关系：
┌──────────────────────────────────────────────┐
│ AI 应用与框架层 │
│ PyTorch / TensorFlow / vLLM / TensorRT-LLM │
├──────────────────────────────────────────────┤
│ 深度学习加速库 │
│ cuDNN（神经网络算子）/ NCCL（多卡通信） │
│ TensorRT（推理优化）/ cuBLAS（矩阵运算） │
├──────────────────────────────────────────────┤
│ CUDA Toolkit（开发层） │
│ CUDA Runtime API、编译器 nvcc、工具链 │
├──────────────────────────────────────────────┤
│ NVIDIA 驱动（内核层，装在宿主机上） │
│ 内核模块 nvidia.ko + 用户态库 libcuda.so │
├──────────────────────────────────────────────┤
│ GPU 硬件 │
└──────────────────────────────────────────────┘各层职责：
- NVIDIA 驱动：唯一直接与硬件打交道的软件，以内核模块形式安装在操作系统上。
nvidia-smi看到的就是驱动层信息。一台宿主机只需装一次驱动。 - CUDA Toolkit：面向开发者的工具包，包含运行时库（CUDA Runtime）、编译器（nvcc）、调试分析工具（nsight、nvprof 的继任者）等。
- cuDNN：基于 CUDA 实现的深度学习基础算子库（卷积、归一化等），框架调用它来获得极致性能。
- NCCL：多卡/多机通信库，分布式训练的"神经中枢"（第五部分会专门讲）。
3.2 版本兼容性：运维的"版本地狱"
GPU 运维的日常痛苦之一，就是处理版本兼容问题。兼容性有三条主线：
主线一：驱动版本 ≥ CUDA 版本要求
每个 CUDA 版本都要求最低驱动版本。CUDA 具有向后兼容性：新驱动可以运行旧 CUDA 编译的程序，反之不行。
bash
# 查看当前驱动支持的最高 CUDA 版本（右上角 "CUDA Version"）
nvidia-smi注意：
nvidia-smi显示的 "CUDA Version" 是驱动所支持的最高 CUDA 版本，不代表系统里实际安装了该版本的 CUDA Toolkit——这是初学者最容易误解的地方。
主线二：框架版本 ↔ CUDA 版本
PyTorch 等框架发布时会针对特定 CUDA 版本编译，例如 PyTorch 2.x 有 cu118、cu121、cu124 等多个变体。装错组合轻则性能下降，重则直接报错 CUDA error: no kernel image is available for execution on the device。
主线三：CUDA 版本 ↔ GPU 架构
每个 GPU 架构有对应的**计算能力（Compute Capability）**编号（如 A100 是 8.0，H100 是 9.0）。新版 CUDA 会放弃对过老架构的支持；新架构的卡则要求足够新的 CUDA。
运维应对策略
- 驱动适当装新：驱动向后兼容，装较新的稳定版（如生产常用 LTS 分支驱动）可以覆盖大多数 CUDA 需求。
- 用容器隔离 CUDA：不同任务用不同镜像，各自携带匹配的 CUDA（见 3.4 节）。
- 查官方兼容性矩阵：遇到版本问题，先查 NVIDIA 官方"CUDA Compatibility"文档和框架官方安装页，以官方文档为准。
3.3 常见 AI 框架与 CUDA 的关系
| 框架 | 定位 | 与 CUDA 的关系 |
|---|---|---|
| PyTorch | 训练与研究的事实标准 | 预编译包自带匹配的 CUDA Runtime，pip 安装即用 |
| TensorFlow | 老牌框架，工业界仍有存量 | 同上，版本与 CUDA/cuDNN 绑定严格 |
| vLLM | 大模型推理服务框架 | 基于 PyTorch + 自定义 CUDA 算子（如 PagedAttention） |
| TensorRT-LLM | NVIDIA 官方推理优化框架 | 深度绑定 TensorRT，编译期针对具体 GPU 架构优化 |
| DeepSpeed / Megatron-LM | 分布式训练框架 | 基于 PyTorch，依赖 NCCL 做分布式通信 |
关键点：框架本身不带驱动，它们通过用户态库 libcuda.so（由驱动提供）与 GPU 通信。这就是为什么"容器里装 CUDA 也能用宿主机的 GPU"（下一节展开）。
3.4 容器时代的 CUDA
传统痛点
在裸机时代，部署 AI 环境要依次安装：驱动 → CUDA Toolkit → cuDNN → Python 框架，任何一步版本不匹配都要重来。两个项目需要不同 CUDA 版本时，一台机器上很难共存。
容器方案：镜像自带 CUDA，宿主机只装驱动
现代 GPU 平台的标准做法是：
- 宿主机：只安装 NVIDIA 驱动 + NVIDIA Container Toolkit（容器运行时插件）
- 容器镜像：自带完整 CUDA Runtime + cuDNN + 框架（如官方镜像
nvcr.io/nvidia/pytorch:24.xx-py3）
宿主机： [ GPU ] ← [ NVIDIA 驱动 ] ← [ NVIDIA Container Toolkit ]
│
容器内： [ PyTorch + cuDNN + CUDA Runtime ] ←─ 通过挂载的驱动库访问 GPU原理解析：容器启动时，NVIDIA Container Toolkit 会把宿主机的驱动用户态库（libcuda.so 等）和 GPU 设备文件（/dev/nvidia*）挂载进容器。容器内的 CUDA Runtime 通过这些库与驱动对话，从而使用 GPU。因为驱动是向后兼容的，只要驱动版本 ≥ 容器内 CUDA 的要求即可。
bash
# 验证：启动一个自带 CUDA 的容器，测试能否看到 GPU
docker run --rm --gpus all nvidia/cuda:12.4.0-base-ubuntu22.04 nvidia-smi这种方式带来三大好处：
- 环境隔离：不同任务用不同镜像，CUDA 版本互不干扰
- 快速交付：镜像即环境，拉下来就能跑
- 宿主机极简：只需维护驱动，升级驱动即可支撑所有容器
这也是 Kubernetes 调度 GPU 的基础——K8s 上跑的所有 GPU 任务都是容器，第二部分会详细讲解工具链安装。
本章小结
- CUDA 是 NVIDIA GPU 通用计算的软件基石，软件栈层次为：驱动 → CUDA Toolkit → cuDNN/NCCL 等加速库 → AI 框架。
- 版本兼容三主线：驱动 ≥ CUDA 要求；框架匹配 CUDA；CUDA 支持对应 GPU 架构。遇版本问题查官方矩阵。
nvidia-smi显示的 CUDA Version 是驱动支持的最高版本，不等于实际安装的 Toolkit 版本。- 容器时代：宿主机只装驱动，CUDA 随镜像走，通过 NVIDIA Container Toolkit 挂载驱动库实现容器内访问 GPU。
动手实验与练习
- 概念辨析：向同学解释"为什么
nvidia-smi里显示的 CUDA Version 和我pip list里 PyTorch 的 CUDA 版本可以不一样"。 - 有 GPU 环境：
bash
# 查看驱动版本与支持的最高 CUDA 版本
nvidia-smi
# 查看 GPU 设备文件（容器挂载的就是这些）
ls -l /dev/nvidia*
# 查看驱动内核模块
lsmod | grep nvidia- 有 Docker 环境：执行 3.4 节的
docker run --gpus all实验，对比容器内外nvidia-smi输出。 - 调研练习：访问 PyTorch 官网安装页（pytorch.org），查看当前版本提供了哪几个 CUDA 变体；访问 NVIDIA 官方 CUDA Compatibility 文档，查 CUDA 12.4 要求的最低驱动版本。
第 4 章 AI 工作负载特征与算力平台
本章目标
- 掌握训练、推理、开发调试三类负载的特征差异
- 理解 KV Cache、checkpoint 等运维必须懂的概念
- 了解算力平台的整体架构：资源池化、多租户、调度、计量
- 理解 GPU 利用率低的常见原因，建立后续学习的整体地图
4.1 训练负载特征
训练任务是 GPU 集群的"重工业"，特征鲜明：
特征一：长时间运行
大模型训练动辄数周到数月不间断运行。这意味着：
- 任何一次硬件故障都可能中断训练，造成数小时甚至数天的进度损失
- 对集群稳定性要求极高，运维的每一项操作（升级、重启）都要避开训练任务
特征二：多卡多机协同
大模型单机 8 卡放不下，需要几十到几千台服务器协同。所有 GPU 像"一个人"一样步调一致地工作，每个训练步骤（step）结束时要通过网络同步梯度——任何一台机器、一条链路慢了，整个集群都在等它（俗称"短板效应"或"掉队者效应"）。
特征三：对网络与存储敏感
- 网络：梯度同步产生巨大的东西向流量，依赖 InfiniBand/RoCE 高速网络。网络抖动直接表现为训练变慢。
- 存储：训练需要持续高速读取数据集，存储跟不上，GPU 就会空转等待数据。
特征四：Checkpoint（断点续训）是生命线
训练过程中会定期把模型当前状态保存到存储上，这个快照叫 checkpoint：
- 训练中断后可以从最近的 checkpoint 恢复，而不是从头再来
- checkpoint 文件巨大（大模型可达数百 GB 到 TB 级），写 checkpoint 时对存储冲击明显
- 运维视角：checkpoint 的保存频率、存储可靠性、恢复演练，都是训练保障的重点
4.2 推理负载特征
推理是模型"上班干活"的阶段，特征与训练截然不同：
特征一：低延迟要求
用户问一句话，期望秒级响应。推理服务有严格的延迟指标（如首 token 延迟 TTFT、每秒输出 token 数），容量规划要按峰值并发设计。
特征二：高并发、7×24 在线
推理服务面向用户，通常需要多副本 + 负载均衡 + 弹性伸缩，业务高峰低谷明显（如白天高、凌晨低）。
特征三：显存占用与 KV Cache
大模型推理生成文本是逐字（token）生成的：每生成一个字，都要"回看"之前所有内容。为避免重复计算，框架会把历史中间结果缓存在显存中，这就是 KV Cache。
- KV Cache 占用与并发数 × 对话长度成正比，长对话、高并发时 KV Cache 可占掉大半显存
- 显存装不下更多 KV Cache，就无法接纳更多并发请求——这是推理容量的核心约束
- vLLM 等推理框架的核心创新（PagedAttention）就是对 KV Cache 的精细化管理
运维视角：推理服务的 GPU 显存监控要重点关注 KV Cache 占用率，它是"还能接多少请求"的直接信号。
特征四：弹性伸缩
推理负载随业务波动，平台需要按负载自动扩缩容推理实例，这是 K8s 大显身手的场景（HPA、KPA 等，后续章节展开）。
4.3 开发调试负载
第三类负载容易被忽视，但在真实集群中占比往往不小：算法工程师用 Jupyter Notebook / SSH 交互式环境开发和调试代码。
资源碎片问题
开发负载的痛点在于：
- 占用不规律：工程师白天调试几小时，卡挂上任务后可能人去吃饭，GPU 空占着
- 长期独占：一个 notebook 可能挂着几天不关，整块 GPU 被"占着茅坑不拉屎"
- 粒度粗：调试代码往往用不满一张卡，却独占整卡
这就是典型的资源碎片：集群账面上"卡都分完了"，实际利用率却很低。后续的 GPU 共享技术（MIG、vGPU、HAMi 显存切分）和调度策略（抢占、超售）主要就是为解决这类问题而生。
4.4 什么是算力平台
当集群规模到了几十台、服务几十个团队时，靠人工"SSH 上去占卡"就完全不可行了，需要建设算力平台（智算平台）。其核心思想：
- 资源池化：把所有 GPU 汇成一个大池子，用户按需申请，而不是把卡固定分给某人
- 多租户：不同团队/项目隔离使用，互不干扰，有配额限制
- 任务调度：自动把任务放到有空闲资源的节点上，排队、优先级、抢占
- 计量计费：记录谁用了多少卡时，支撑成本核算
整体架构（简化版）：
┌───────────────────────────────────────────────────────┐
│ 用户层：算法工程师 / 训练任务 / 推理服务 │
├───────────────────────────────────────────────────────┤
│ 平台层：Web 控制台 / API / 计量计费 / 用户与配额管理 │
├───────────────────────────────────────────────────────┤
│ 调度层：Kubernetes + GPU 调度器（Device Plugin、 │
│ Volcano 批调度、GPU 共享方案） │
├───────────────────────────────────────────────────────┤
│ 运行时层：容器运行时 + NVIDIA Container Toolkit + 驱动 │
├───────────────────────────────────────────────────────┤
│ 资源层：GPU 服务器 | IB/RoCE 网络 | 并行存储 │
└───────────────────────────────────────────────────────┘
▲ ▲
└──── 可观测性体系：DCGM 监控 / 日志 / 告警 ────┘对应到本教材：第二部分解决"资源层→运行时层"（驱动与环境），第三、四部分解决"调度层"（虚拟化、K8s 调度），第五部分解决网络，第六部分解决可观测性，第七、八部分解决稳定运行与成本优化。
4.5 GPU 利用率为什么常常很低
很多集群的 GPU 平均利用率只有 20%~40%，钱花了，算力却闲着。常见原因：
| 原因 | 说明 | 解决方向（后续章节） |
|---|---|---|
| 数据加载瓶颈 | 存储/网络喂不上数据，GPU 空转等待 | 数据预热、缓存、并行加载（第八部分） |
| 通信等待 | 多卡同步时慢节点拖累全局 | NCCL 调优、拓扑感知调度（第五部分） |
| 资源独占浪费 | 开发任务独占整卡但用不满 | MIG/共享切分、超卖（第三、四部分） |
| 任务编排不合理 | 小任务占大卡、任务间空窗期长 | 批调度、混部、弹性伸缩（第四、八部分） |
| 代码效率低 | 用户代码没用好 Tensor Core、batch 太小 | 性能分析工具、混合精度（第八部分） |
运维的目标不是让 GPU 100% 跑满（这可能以牺牲任务排队时间为代价），而是在保障 SLA 的前提下，让每一份昂贵算力创造最大价值。 这条主线贯穿全书。
本章小结
- 训练负载：长时间、多机协同、对网络存储敏感、靠 checkpoint 保命。
- 推理负载：低延迟、高并发、显存瓶颈在 KV Cache、需要弹性伸缩。
- 开发负载：交互式、占用不规律，是资源碎片和利用率低的重灾区。
- 算力平台 = 资源池化 + 多租户 + 任务调度 + 计量计费，K8s 是调度层的事实标准。
- GPU 利用率低的根因：数据瓶颈、通信等待、独占浪费、编排不合理、代码低效——后续章节逐一解决。
动手实验与练习
- 思考题：某集群有 100 张 GPU，账面分配率 95%（几乎都分出去了），实际平均算力利用率只有 25%。结合本章内容，列出至少三种可能的原因。
- 概念自测：用自己的话解释 KV Cache 是什么，为什么它决定推理服务能同时接待多少用户。
- 有 GPU 环境：执行
nvidia-smi --query-gpu=utilization.gpu,memory.used,memory.total --format=csv -l 2，观察空闲 GPU 的利用率与显存占用，理解"分配≠使用"。 - 架构练习：参照 4.4 节的框图，画出你心目中"为 50 人算法团队服务的 GPU 平台"架构草图，标注每一层你目前已知的组件。
本部分总结
通过本部分 4 章的学习，你已经建立了 GPU 集群运维的完整背景知识框架：
- 为什么：AI 的矩阵运算天然适合 GPU 的海量并行架构，大模型算力需求催生了 GPU 集群
- 是什么：认识了 NVIDIA GPU 硬件（架构、产品线、关键指标、精度格式）与 CUDA 软件生态
- 干什么：理解了训练/推理/开发三类负载的特征，以及算力平台的整体架构
- 难在哪：版本兼容、资源碎片、利用率低——这些正是后续章节要解决的问题
下一部分将进入实操：GPU 服务器与驱动环境，你将亲手完成驱动安装、CUDA 部署和容器工具链配置。