第2章 硬件基础
第2章 硬件基础
“Hardware is the stage on which the software drama unfolds.”
—— David Patterson
2.1 本章导入：硬件是 AI 的物理地基
2023 年，NVIDIA H100 GPU 的发布让 AI 训练性能跃升了一个数量级。但许多工程师只是把 GPU 当成一个”更快的 CPU”来使用——买来、插上、跑代码，就期待一切变快。
这是远远不够的。
理解硬件不只是采购决策的事。你写的每一行代码的性能上限，都由底层硬件的物理特性决定。为什么大 batch size 训练更高效？因为 GPU 的并行架构善于利用大规模数据并行。为什么显存比内存贵那么多？因为 GDDR/HBM 的制造工艺和良率限制。为什么 InfiniBand 比 Ethernet 更适合训练？因为 RDMA 绕过了内核协议栈的拷贝开销。
本章将系统讲解 AI 基础设施中涉及的各类硬件——CPU、GPU、AI 加速器、内存、网络和存储——帮助你建立从物理层面理解系统性能的直觉。
2.2 CPU 架构与在 AI 系统中的角色
2.2.1 现代 CPU 架构概览
CPU（中央处理器）在 AI 系统中扮演的是协调者而非计算主力的角色。理解它的架构对于数据预处理流水线、推理服务的 I/O 路径以及集群管理至关重要。
┌──────────────────────────────────────────┐
│ CPU 封装 (Socket) │
│ ┌──────┐ ┌──────┐ ┌──────┐ ┌──────┐ │
│ │Core 0│ │Core 1│ │Core 2│ │Core 3│ │
│ │ALU │ │ALU │ │ALU │ │ALU │ │
│ │FPU │ │FPU │ │FPU │ │FPU │ │
│ │L1 I$ │ │L1 I$ │ │L1 I$ │ │L1 I$ │ │
│ │L1 D$ │ │L1 D$ │ │L1 D$ │ │L1 D$ │ │
│ │L2$ │ │L2$ │ │L2$ │ │L2$ │ │
│ └──┬───┘ └──┬───┘ └──┬───┘ └──┬───┘ │
│ └────────┴────────┴────────┘ │
│ 共享 L3 Cache │
│ ┌──────────────────────────────────┐ │
│ │ 内存控制器 / PCIe Root │ │
│ │ UPI / Infinity Fabric │ │
│ └──────────────────────────────────┘ │
└──────────────────────────────────────────┘关键参数： - 核心数：服务器 CPU 通常 32-128 核（如 AMD EPYC 9654 有 96 核） - 频率：2.5-4.0 GHz（远低于 GPU 的时钟频率，但单核复杂逻辑更强） - PCIe 通道：CPU 提供的 PCIe lane 数量决定了能连接多少 GPU - Intel Xeon Platinum: 80 lanes - AMD EPYC 9004: 128 lanes - 一个 8-GPU 服务器至少需要 64 条 PCIe Gen5 lanes
2.2.2 CPU 在 AI 系统中的角色
CPU 不做矩阵乘法（那是 GPU 的活），但它负责几乎所有其他事情：
| 功能 | 说明 |
|---|---|
| 数据预处理 | Tokenizer、图像增强、数据增强 |
| I/O 调度 | 从存储读取训练数据、管理 DataLoader |
| 通信协调 | 触发和调度 GPU 间的集合通信操作 |
| 推理编排 | KV Cache 管理、请求调度、采样 |
| 系统管理 | 容器编排、监控 Agent、日志收集 |
Tip
性能建议：在 GPU 训练中，如果 DataLoader 成为瓶颈（表现为 GPU 利用率出现周期性低谷），优先检查 CPU 核心数和内存带宽是否充足。一个经验法则是每张 GPU 配备 4-8 个 CPU 核心用于数据加载。
2.2.3 服务器级 CPU 选型考量
# 一个评估 CPU 是否能跟上 GPU 数据需求的简单计算
# 假设训练 ImageNet 类似的任务
gpu_count = 8
gpu_throughput_per_gpu = 2500 # images/sec (A100)
total_throughput = gpu_count * gpu_throughput_per_gpu # 20,000 images/sec
# 每张图像预处理需要 ~2ms CPU 时间（JPEG 解码 + resize + augment）
cpu_time_per_image = 0.002 # seconds
required_cpu_cores = total_throughput * cpu_time_per_image
print(f"需要的 CPU 核心数: {required_cpu_cores:.0f}") # 40
# 如果 CPU 只有 32 核，则数据加载将成为瓶颈
# 解决方案: 增加核心数，或使用 GPU 上的 JPEG 解码 (nvJPEG)2.3 GPU 体系结构
GPU 是现代 AI 系统的心脏。理解 GPU 架构是理解所有 AI 系统性能特征的基础。
2.3.1 GPU vs CPU：设计哲学的根本差异
CPU: 低延迟、复杂控制
┌────┬────┬────┬────┐
│Core│Core│Core│Core│ ← 少量强大的核心
│ALU │ALU │ALU │ALU │ 大量缓存、分支预测、乱序执行
│L1$L2│L1$L2│L1$L2│L1$L2│
└────┴────┴────┴────┘
GPU: 高吞吐、简单控制
┌───┬───┬───┬───┬───┬───┬───┬───┬───┬───┬───┬───┬───┬───┬───┬───┐
│SM │SM │SM │SM │SM │SM │SM │SM │SM │SM │SM │SM │SM │SM │SM │SM │ ← 数千个简单核心
│ │ │ │ │ │ │ │ │ │ │ │ │ │ │ │ │ 少量缓存，大量算术单元
└───┴───┴───┴───┴───┴───┴───┴───┴───┴───┴───┴───┴───┴───┴───┴───┘| 特性 | CPU | GPU |
|---|---|---|
| 核心数 | 8-128 | 数千（A100: 6912 CUDA cores + 432 Tensor cores） |
| 单核性能 | 极强（复杂指令、分支预测） | 弱（简单指令、锁步执行） |
| 内存带宽 | 50-100 GB/s（DDR5） | 2-3 TB/s（HBM3） |
| 缓存 | 大（30-100 MB L3） | 相对小（A100: 192 MB L2） |
| 设计目标 | 最小化延迟 | 最大化吞吐 |
2.3.2 NVIDIA GPU 架构演进
NVIDIA 是 AI GPU 的绝对主导者。以下是近几代架构的关键演进：
Volta (2017) - V100 引入 Tensor Core，16GB HBM2
│ NVLink 2.0, 300GB/s
│
Turing (2018) - T4 推理优化，INT8 支持
│
Ampere (2020) - A100 稀疏化加速，40GB/80GB HBM2e
│ NVLink 3.0, 600GB/s
│ MIG (Multi-Instance GPU)
│
Hopper (2022) - H100 Transformer Engine (FP8)
│ 80GB HBM3, 3.35TB/s 带宽
│ NVLink 4.0, 900GB/s
│ DPX (动态编程加速)
│
Blackwell (2024) - B200 双芯片设计, 192GB HBM3e
8TB/s 带宽, FP4 支持
NVLink 5.0, 1.8TB/s2.3.3 Tensor Core：AI 计算的核心单元
Tensor Core 是 NVIDIA 从 Volta 架构开始引入的专用矩阵计算单元。一个 Tensor Core 可以在每个时钟周期执行一个矩阵乘加运算（MMA）：
\[D = A \times B + C\]
其中 A、B、C、D 都是矩阵片段（如 16×16）。
传统 CUDA Core:
每个时钟周期执行 2 FLOPS (一次乘+加)
Tensor Core:
每个时钟周期执行 512 FLOPS (FP16, 16x16x16 MMA)
H100 的 Transformer Engine: 1024 FLOPS (FP8)
→ Tensor Core 比传统 CUDA Core 快 256-512 倍（在矩阵计算中）
Tip
实践建议：确保你的模型训练使用了 Tensor Core。这意味着： 1. 使用 FP16/BF16 混合精度训练（而非 FP32） 2. 确保矩阵维度是 8 的倍数（A100）或 16 的倍数（H100 FP8），以实现对齐 3. 使用框架内置的 torch.cuda.amp 或 autocast 自动启用
2.3.4 AMD GPU 与国产芯片
AMD Instinct 系列：
MI250X (2021) - 128GB HBM2e, 3.2TB/s
CDNA2 架构, 6.9TB/s Infinity Fabric
MI300X (2023) - 192GB HBM3, 5.3TB/s ← 显存容量超过 H100
CDNA3 架构, 860GB/s Infinity Fabric
MI325X (2024) - 288GB HBM3e, 6.0TB/sAMD 的优势在于更大的显存容量（MI300X 的 192GB 对比 H100 的 80GB），这使得它可以在单卡上放下更大的模型，减少模型并行的通信开销。
国产 AI 芯片概览：
| 芯片 | 厂商 | 算力 (FP16) | 显存 | 生态 |
|---|---|---|---|---|
| 昇腾 910B | 华为 | 376 TFLOPS | 64GB HBM | CANN + MindSpore |
| 寒武纪 MLU370 | 寒武纪 | ~256 TFLOPS | 48GB | Neuware |
| 壁仞 BR100 | 壁仞科技 | ~64 TFLOPS (BF16) | 64GB HBM2e | BIRENSUPA |
| 燧原 DTU | 燧原科技 | ~20 TFLOPS | 32GB | Enflame |
国产芯片面临的最大挑战不是算力本身，而是软件生态——CUDA 的护城河远比想象中深。
2.3.5 GPU 性能计算实例
# 计算 H100 GPU 在 FP16 训练中的理论峰值算力
# H100 SXM5 规格
tensor_cores = 528
clock_mhz = 1830 # boost clock
# 每个 Tensor Core 每周期: 512 FLOPS (FP16 MMA 16x16x16)
flops_per_cycle = tensor_cores * 512
flops_per_second = flops_per_cycle * clock_mhz * 1e6
print(f"H100 FP16 峰值算力: {flops_per_second / 1e15:.1f PFLOPS")
# H100 FP16 峰值算力: ~0.99 PFLOPS (FP16), 1.98 PFLOPS (with sparsity)
# FP8 (Transformer Engine)
flops_per_cycle_fp8 = tensor_cores * 1024 # FP8 每周期 1024 FLOPS
flops_per_second_fp8 = flops_per_cycle_fp8 * clock_mhz * 1e6
print(f"H100 FP8 峰值算力: {flops_per_second_fp8 / 1e15:.1f PFLOPS")
# ~2.0 PFLOPS (dense), ~4.0 PFLOPS (sparse)
# 实际训练中 MFU 通常为 40-55%
# 即一个 8xH100 节点的有效算力约为:
effective = flops_per_second * 8 * 0.50 # 50% MFU
print(f"8xH100 有效算力 (50% MFU): {effective / 1e15:.1f} PFLOPS")2.4 AI 加速器与专用芯片
GPU 是通用并行处理器，但并非所有 AI 计算都适合 GPU。专用加速器在特定场景下可以超越 GPU 的性能和能效。
2.4.1 Google TPU
TPU（Tensor Processing Unit）是 Google 为机器学习定制的 ASIC：
TPU v1 (2016) - 92 TOPS (INT8), 推理专用
TPU v2 (2017) - 180 TFLOPS (FP16), 训练+推理
TPU v3 (2018) - 420 TFLOPS (FP16), 液冷
TPU v4 (2021) - 275 TFLOPS (BF16), 光电路交换 (OCS)
TPU v5p (2023) - 459 TFLOPS (BF16), 95GB HBM
Trillium (2024) - 918 TFLOPS (INT8), 2x v5e 性能TPU 的核心计算单元是脉动阵列（Systolic Array）——一种专为矩阵乘法设计的数据流动架构：
数据流向 (从左到右)
┌───┬───┬───┬───┐
│ ● │ ● │ ● │ ● │ ← 输入数据流入
├───┼───┼───┼───┤
│ ● │ ● │ ● │ ● │
├───┼───┼───┼───┤
│ ● │ ● │ ● │ ● │ ← 每个单元执行乘加运算
├───┼───┼───┼───┤ 结果向下流动
│ ● │ ● │ ● │ ● │
└───┴───┴───┴───┘
↓ ↓ ↓ ↓
输出结果TPU 的优势在于：矩阵计算能效比 GPU 高 3-6 倍（同等工艺）。劣势在于灵活性差——如果算子不被脉动阵列支持，性能会急剧下降。
2.4.2 NPU 与 DSA
NPU（Neural Processing Unit） 泛指面向神经网络推理的轻量级加速器，常见于边缘设备：
- Apple Neural Engine (ANE)：M 系列芯片中集成，16 核设计，15.8 TOPS
- Qualcomm Hexagon NPU：骁龙 8 Gen 3 中集成，集成于手机 SoC
- Intel NPU：Meteor Lake 开始集成的低功耗 AI 推理单元
DSA（Domain-Specific Architecture） 的核心思想是用硅片面积换能效：
通用 CPU: 1 TOPS/W (能效比)
GPU: 10-50 TOPS/W
NPU/DSA: 50-200 TOPS/W
专用 ASIC: 100-1000 TOPS/W (极限优化)2.4.3 推理加速卡
推理场景对硬件的需求与训练不同——更看重低成本、低功耗、高吞吐：
| 加速卡 | 类型 | 特点 | 适用场景 |
|---|---|---|---|
| NVIDIA L4 | 推理卡 | 24GB, 30W, 适合视频/语音 | 推理服务 |
| NVIDIA L40S | 推理卡 | 48GB, 350W, 推理+图形 | 大模型推理 |
| NVIDIA H200 | 训练+推理 | 141GB HBM3e | 大模型推理（大 KV Cache） |
| Groq LPU | 推理专用 | 极低延迟（<100ms 生成 500 token） | 超低延迟推理 |
| Cerebras WSE | 晶圆级 | 整个晶圆做成一颗芯片 | 大模型训练/推理 |
2.5 内存层次结构与显存带宽瓶颈
2.5.1 GPU 内存层次
┌────────────────────────────────────────────┐
│ Register File │ ← 最快, 每线程私有
│ (~256KB/SM, 1 cycle) │
├────────────────────────────────────────────┤
│ Shared Memory / L1 │ ← 编程可控
│ (192KB/SM, ~30 cycles) │
├────────────────────────────────────────────┤
│ L2 Cache │ → 所有 SM 共享
│ (40-50MB, ~200 cycles) │
├────────────────────────────────────────────┤
│ HBM (显存) │ → 容量大但延迟高
│ (80-192GB, ~400 cycles) │
├────────────────────────────────────────────┤
│ Host Memory (CPU) │ → 通过 PCIe/UPI 访问
│ (256-1024GB DDR5) │ 极慢 (~10,000 cycles)
├────────────────────────────────────────────┤
│ NVLink Peer GPU │ → 访问其他 GPU 的显存
│ (其他 GPU 的 HBM) │ 比本地 HBM 慢 2-3x
└────────────────────────────────────────────┘2.5.2 显存带宽：AI 计算的第一瓶颈
在大多数 AI 工作负载中，瓶颈不是算力，而是显存带宽。
为什么？ 一个直观的计算：
# 矩阵乘法的算术强度分析
# Y = X @ W, 其中 X:[M, K], W:[K, N], Y:[M, N]
M, K, N = 4096, 4096, 4096
# 计算量
flops = 2 * M * K * N
print(f"FLOPS: {flops:,}") # 137,438,953,472
# 内存访问量: 需要读取 X, W, 写入 Y
bytes_per_element = 2 # FP16
mem_access = (M * K + K * N + M * N) * bytes_per_element
print(f"Memory: {mem_access / 1e9:.2f} GB") # 0.10 GB
# 算术强度 (Arithmetic Intensity)
ai = flops / mem_access
print(f"Arithmetic Intensity: {ai:.1f} FLOPS/Byte") # ~1365
# H100 的平衡点
peak_flops = 989e12 # 989 TFLOPS FP16
peak_bw = 3.35e12 # 3.35 TB/s
balance = peak_flops / peak_bw
print(f"Roofline 平衡点: {balance:.1f} FLOPS/Byte") # ~295
# 结论: 对于 4096x4096 的矩阵, AI=1365 > 295
# → 计算密集型, 能充分利用 GPU 算力
# 但对于小矩阵 (如推理时 batch_size=1), AI 可能低于平衡点
# → 内存密集型, 大量算力被浪费这就解释了为什么推理（特别是 batch_size=1 的场景）严重受限于显存带宽——矩阵太小，算术强度太低。
2.5.3 HBM 技术演进
HBM2 (2016) - ~1TB/s (V100)
HBM2e (2020) - ~2TB/s (A100, 80GB)
HBM3 (2022) - ~3.35TB/s (H100, 80GB)
HBM3e (2024) - ~4.8TB/s (B200, 192GB)
HBM4 (2026 预期) - ~6-8TB/sHBM 通过3D 堆叠技术将多个 DRAM 芯片垂直连接，通过硅通孔（TSV）与 GPU 封装在同一个基板上，实现了极高的带宽密度：
┌──┬──┬──┬──┐ ← 多层 DRAM 芯片堆叠
│D │D │D │D │
├──┼──┼──┼──┤
│D │D │D │D │
├──┼──┼──┼──┤
│D │D │D │D │
├──┼──┼──┼──┤
│硅│通│孔│TSV│ ← 硅通孔连接
└──┴──┴──┴──┘
│
┌────┴────┐
│ GPU Die │ ← 逻辑芯片
└─────────┘
Warning
瓶颈认知：HBM 产能有限且价格昂贵。2024-2025 年，HBM 产能是 AI 芯片出货量的主要制约因素。这也是为什么 GPU 价格居高不下——限制因素不是硅片面积，而是 HBM 堆叠的良率和产能。
2.6 网络硬件
网络是大规模 AI 训练中仅次于 GPU 本身的第二大成本和性能因素。
2.6.1 为什么 AI 训练对网络要求极高
在分布式训练中，每个训练步骤都需要在所有 GPU 之间同步梯度。以 8xH100 节点为例：
# 计算每步训练的通信量（数据并行场景）
model_size_bytes = 175e9 * 2 # 175B 参数, FP16
print(f"模型大小: {model_size_bytes / 1e9:.0f} GB")
# 数据并行: 每步需要一次 AllReduce
# 通信量约为 2 * 模型大小 (ring allreduce 的因子)
comm_per_step = 2 * model_size_bytes
print(f"每步通信量: {comm_per_step / 1e9:.0f} GB")
# 假设每秒 2 步训练
steps_per_sec = 2
comm_bw_required = comm_per_step * steps_per_sec
print(f"所需网络带宽: {comm_bw_required / 1e12:.1f TB/s")
# → 需要 0.7 TB/s 的有效带宽！2.6.2 InfiniBand vs. RoCE vs. 高速以太网
┌─────────────┬───────────────┬───────────────┐
│ InfiniBand │ RoCE │ Ethernet │
│ (NVIDIA) │ (RDMA over │ (TCP/IP) │
│ │ Ethernet) │ │
├─────────────┼───────────────┼───────────────┤
│ NDR 400Gbps │ 400Gbps │ 400Gbps │
│ XDR 800Gbps │ │ │
├─────────────┼───────────────┼───────────────┤
│ 延迟: ~1μs │ 延迟: ~2-3μs │ 延迟: ~10-50μs │
├─────────────┼───────────────┼───────────────┤
│ RDMA: 原生 │ RDMA: 通过 │ RDMA: 不支持 │
│ │ UDP 封装 │ │
├─────────────┼───────────────┼───────────────┤
│ 成本: 高 │ 成本: 中 │ 成本: 低 │
├─────────────┼───────────────┼───────────────┤
│ 生态: HPC/ │ 生态: AI/ │ 生态: 通用云 │
│ AI 集群 │ 企业 │ │
└─────────────┴───────────────┴───────────────┘RDMA（Remote Direct Memory Access） 是理解高性能 AI 网络的关键概念：
传统网络 (TCP/IP):
App → Socket → TCP → IP → NIC → Wire → NIC → IP → TCP → Socket → App
↑ 内核拷贝 ↑ ↑ 内核拷贝 ↑
(~30-50μs 延迟)
RDMA:
App → NIC ─────────────────────→ NIC → App
↑ 直接内存写入 ↑
(~1-3μs 延迟)RDMA 绕过了操作系统内核，直接从一个 GPU 的显存写入另一个 GPU 的显存，延迟降低了一个数量级。
2.6.3 典型网络拓扑
Fat-Tree（胖树）拓扑是 AI 集群最常用的网络架构：
[Core Switch] ← 交换机层
/ | | \
[Aggr] [Aggr] [Aggr] [Aggr] ← 聚合层
/|\ /|\ /|\ /|\
[T1][T2][T3][T4][T5][T6][T7][T8] ← Tier-2 (ToR)
|X8| |X8| |X8| |X8|
节点1 节点2 节点3 节点4
每个节点 8 张 GPU, 连接到 ToR 交换机
胖树保证了任意两个节点间的带宽对等NVLink / NVSwitch 用于节点内 GPU 互联：
┌──────────────────────────────────┐
│ NVSwitch Fabric │
│ ┌───┐ ┌───┐ ┌───┐ ┌───┐ │
│ │GPU│ │GPU│ │GPU│ │GPU│ │
│ │ 0 │ │ 1 │ │ 2 │ │ 3 │ │
│ └─┬─┘ └─┬─┘ └─┬─┘ └─┬─┘ │
│ │ │ │ │ │
│ ┌─┴─┐ ┌─┴─┐ ┌─┴─┐ ┌─┴─┐ │
│ │GPU│ │GPU│ │GPU│ │GPU│ │
│ │ 4 │ │ 5 │ │ 6 │ │ 7 │ │
│ └───┘ └───┘ └───┘ └───┘ │
│ │
│ 每张 GPU 可直接访问任意其他 │
│ GPU 的显存 (900GB/s on H100) │
└──────────────────────────────────┘2.6.4 网络选型建议
| 规模 | 推荐网络 | 理由 |
|---|---|---|
| 1-8 GPU (单机) | NVLink | 节点内全互联，无需外部网络 |
| 8-64 GPU | RoCE 200G | 性价比最优，满足中小规模训练 |
| 64-1000 GPU | InfiniBand NDR 400G | 低延迟、无损网络，大规模训练必需 |
| 1000+ GPU | InfiniBand XDR 800G + 多平面 | 超大规模训练，需要多轨网络 |
Tip
成本提示：在一个万卡集群中，网络设备（交换机 + 线缆 + 网卡）的成本约占总投资的 15-25%。不要低估网络的成本——InfiniBand 交换机价格大约是同带宽以太网交换机的 2-3 倍，但它带来的训练效率提升通常能在 6 个月内收回差价。
2.7 存储介质与 I/O 性能特征
2.7.1 AI 工作负载的存储需求
AI 训练的存储需求主要来自：
- 训练数据读取：需要持续高吞吐（GB/s 级别）
- Checkpoint 保存/加载：突发性大文件 I/O（几十到数百 GB）
- 模型权重存储：版本化管理多个模型版本
存储类型 延迟 带宽 适用场景
─────────────────────────────────────────────────────────
GPU HBM ~400ns 2-4 TB/s 计算（最快）
NVMe SSD ~100μs 3-7 GB/s 本地缓存
NVMe-oF ~200μs 1-3 GB/s 共享存储
SAS SSD ~1ms 0.5-1 GB/s 冷数据
SATA SSD ~2ms 0.5 GB/s 一般存储
HDD ~10ms 0.1-0.2 GB/s 归档存储
对象存储 (S3) ~10-100ms 可弹性扩展 原始数据2.7.2 并行文件系统
对于大规模 AI 训练集群，单个存储节点无法满足数百个 GPU 同时读取数据的需求。需要使用并行文件系统：
Lustre / GPFS (Spectrum Scale) / WEKA：
┌─────────────────────┐
│ 并行文件系统命名空间 │
└──────────┬──────────┘
│
┌───────────────┼───────────────┐
│ │ │
┌───┴───┐ ┌────┴───┐ ┌────┴───┐
│ OSS 1 │ │ OSS 2 │ │ OSS 3 │ ← Object Storage Servers
│ (OST) │ │ (OST) │ │ (OST) │
│ NVMe │ │ NVMe │ │ NVMe │
└───┬───┘ └────┬───┘ └────┬───┘
│ │ │
└───────────────┼───────────────┘
│
高速网络 (InfiniBand)
│
┌───────┬───────┼───────┬───────┐
GPU GPU GPU GPU GPU ← 计算节点一个文件被分散存储在多个 OST 上，多个 GPU 可以并行从不同 OST 读取数据的不同部分，从而实现聚合带宽的线性扩展。
2.7.3 存储分层策略
# 典型的 AI 训练存储分层配置
storage_tiers:
tier_0_local_nvme: # GPU 节点本地 NVMe
capacity: "7.68 TB / node"
purpose: "当前 epoch 的训练数据缓存"
latency: "100μs"
tier_1_parallel_fs: # 并行文件系统 (Lustre/Weka)
capacity: "500 TB"
purpose: "训练数据集 + checkpoint 实时写入"
bandwidth: "200 GB/s aggregate"
tier_2_object_storage: # 对象存储 (S3/OSS)
capacity: "10+ PB"
purpose: "原始数据、历史 checkpoint、模型仓库"
cost: "$0.023/GB/month"
tier_3_cold_storage: # 冷存储 / 磁带库
capacity: "100+ PB"
purpose: "合规存档、长期保留"
cost: "$0.001/GB/month"
Tip
实践建议：Checkpoint 写入是最容易被忽视的 I/O 瓶颈。一个 175B 模型的 checkpoint 大小约 700GB（含优化器状态）。如果直接写入并行文件系统，可能导致网络拥塞和训练暂停。推荐使用两阶段写入：先写入本地 NVMe（秒级完成），再异步上传到并行文件系统和对象存储。
2.7.4 I/O 性能基准测试
# 测试训练数据读取的实际吞吐
# 使用 fio 测试 NVMe 随机读性能
fio --name=test \
--filename=/data/testfile \
--rw=randread \
--bs=4k \
--ioengine=libaio \
--iodepth=32 \
--runtime=60 \
--time_based \
--numjobs=4
# 使用 iperf3 测试节点间网络带宽
# 在 server 节点
iperf3 -s
# 在 client 节点
iperf3 -c <server_ip> -t 30 -P 8 # 8 个并行流
# 使用 nccl-tests 测试 GPU 间通信性能
# 测量 AllReduce 的实际带宽
./all_reduce_perf -b 8 -e 1G -f 2 -g 8
# 输出示例:
# Avg bus bandwidth: 380 GB/s (8xH100 NVLink)2.8 小结
- CPU 在 AI 系统中扮演协调者角色，负责数据预处理、I/O 调度和通信协调。
- GPU 是 AI 计算的核心，理解 Tensor Core 和显存层次结构是性能优化的基础。
- AI 加速器（TPU、NPU、DSA）在特定场景下可以超越 GPU 的性能和能效。
- 显存带宽往往是 AI 工作负载的第一瓶颈，HBM 技术的演进直接决定了下一代 AI 芯片的能力上限。
- 网络硬件（InfiniBand、RoCE）决定了分布式训练的扩展效率，RDMA 是高性能 AI 网络的核心技术。
- 存储系统需要分层设计，将热数据放在高速介质、冷数据放在廉价介质，并使用并行文件系统支撑聚合带宽。
延伸阅读
- 《Computer Organization and Design: RISC-V Edition》 — Patterson & Hennessy，理解计算机体系结构的经典教材
- NVIDIA Hopper Architecture Whitepaper — 深入理解 H100 架构设计
- AMD CDNA 3 Architecture Whitepaper — MI300X 架构详解
- Google TPU v4 论文 (ISCA 2023) — TPU 架构和大规模部署经验
- “The Illustrated Transformer” — Jay Alammar，理解 Transformer 计算图
- Roofline 模型论文 — Williams et al., Communications of the ACM 2009
- NVIDIA NCCL Documentation — 理解 GPU 集合通信库的实现
- Lustre Operations Manual — 并行文件系统运维指南