📔读「大模型时代的基础架构：大模型算力中心建设指南」

第1章 AI与大模型时代对于基础架构的需求

机器学习的核心认知

1. 训练：先构建参数待定的高次线性方程模型，输入海量训练样本（模型的自变量、因变量值），由计算机求解出模型参数（即权重）；

2. 推理：基于训练得到的成熟模型，输入自变量即可计算出因变量，实现对未知场景的判断与输出。

为何 CPU 不适合重复的向量计算？

1. 运算单元串行执行：单个 CPU 核心仅有 1 个 ALU（算术逻辑单元），处理向量卷积等简单重复运算时，只能串行执行指令，无法并行处理批量数据，运算效率极低；

2. SIMD 并行能力有限：即便 CPU 通过 SIMD（单指令多数据）单元实现并行加速，但其寄存器位宽（如早期 SSE 的 128bit）受硬件设计限制，单次并行运算的数量（加速比）难以突破 16，无法满足向量运算对大规模并行的需求。

第2章 软件程序与专用硬件的结合

CUDA 并行计算编程框架核心梳理

1. 数据入 GPU：GPU 发起 DMA（直接内存访问），将系统主内存中的计算数据复制到 GPU 专属内存中，为并行计算做数据准备；

2. 指令注入：CPU 向 GPU 下发计算指令，明确 GPU 需执行的运算逻辑；

3. 并行执行：GPU 调度内部多个计算线程，并行执行接收到的 GPU 指令，充分利用海量计算单元的并行能力；

4. 结果回传：GPU 计算完成后，再次发起 DMA，将 GPU 内存中的运算结果搬运回系统主内存，供 CPU 后续处理或调用。

第3章 GPU硬件架构剖析

NVIDIA H100 笔记（Hopper 架构）

基本规格

• 芯片：GH100

• 工艺：TSMC 4N

• 晶体管数：800 亿

• Die 大小：814 mm²

• 主流变体：H100 SXM（重点） vs H100 PCIe vs H100 NVL（94 GB HBM3e 版本）

H100 SXM 核心参数（主流训练/推理版本）

• GPC：8

• TPC：66

• SM：132

• FP32 CUDA Core：16,896（每个 SM 128 个）

• 第4代 Tensor Core：528（每个 SM 4 个）

• L2 Cache：50 MB（支持压缩/解压）

• 显存：80 GB HBM3，带宽 3.35 TB/s

• PCIe 版：80 GB HBM2e，带宽 ≈2.0 TB/s

• NVL 变体：94 GB HBM3e，更高带宽（≈4.8 TB/s 部分场景）

关键新特性

• Transformer Engine：动态 FP8/FP16 混合精度切换，专为 LLM 优化

• TMA（Tensor Memory Accelerator）：异步张量内存访问

• Thread Block Cluster：多 SM 协作共享内存，提升并行效率

• DPX 指令：动态规划加速（基因序列等场景提升显著）

• 第2代 MIG：最多 7 个实例

• Confidential Computing：硬件级可信执行环境

CUDA Core vs 第4代 Tensor Core 对比

多卡互联体系（核心定位与差异）

• NVLink 4.0 → 节点内 GPU 点对点高速基础

• NVSwitch → 节点内全互联无阻塞（HGX 平台专用）

• PCIe Gen5 → 通用兜底 + CPU/外设通信

• NVLink Switch System → 跨节点扩展（256 GPU 域）

• InfiniBand / Ethernet → 超大规模集群节点间互联

1. 第4代 NVLink（点对点高速互联基础）

• 单 GPU 双向带宽：900 GB/s（18 条 × 50 GB/s）

• 对比：A100 的 600 GB/s 提升 50%；PCIe Gen5 x16 仅 128 GB/s（≈7 倍差距）

• 优势：P2P 直连、原子操作、硬件 All-Reduce 支持，延迟极低（微秒级）

• 限制：纯 NVLink 仅支持部分互联，单节点最多高效 4 张 GPU

• 适配场景：H100 PCIe 服务器（2/4 卡轻量训练/推理）、成本敏感部署

2. 第3代 NVSwitch（节点内全互联核心）

• 单芯片：64 端口，每端口双向 50 GB/s，总吞吐 13.6 Tbit/s（≈1.7 TB/s）

• HGX H100 8-GPU 配置：通常 4 个 NVSwitch 级联，实现 8 张 GPU 全互联（任意 GPU ↔ 任意 GPU 均 900 GB/s 双向）

• 节点内总通信带宽：超 25 TB/s（PCIe 的 200 倍+）

• 优势：无阻塞全对全、SHARP 硬件加速集体操作（All-Reduce 提升 3×）

• 硬件要求：NVIDIA HGX/HGX-like 定制平台，成本高

• 适配场景：H100 SXM 8-GPU 节点、大模型单节点训练（追求 90%+ 算力利用率）

3. NVLink Switch System（集群级 NVLink 扩展）

• 支持：最多 256 张 H100 全互联（32 节点 × 8 GPU）

• 全-to-all 带宽：57.6 TB/s

• 拓扑：2:1 胖树 + SHARP 加速

• 优势：跨节点 GPU 接近节点内通信性能，实现“数据中心级单一大 GPU”

• 适配场景：千卡～万卡超大规模训练集群（如 xAI Colossus 前期阶段）

4. PCIe Gen5（兜底 + 通用通道）

• 双向带宽：128 GB/s（x16）

• 定位：GPU ↔ CPU/内存、GPU ↔ NIC/SSD、外设交互；无 NVLink 时的低配 GPU 互联

• 短板：带宽低、延迟高（毫秒级），GPU 间互联利用率常 <50%

• 适配场景：通用服务器、低成本部署、非 AI 密集任务

5. 集群级跨节点互联（补充）

• 主流：Quantum-2 InfiniBand NDR 400 Gb/s（双向 50 GB/s）、Spectrum-X Ethernet 800 Gb/s + BlueField-3 DPU

• 标准组网：节点内 NVLink/NVSwitch + 节点间 InfiniBand/Ethernet

三者核心对比表（H100 平台）

同 Node / 跨 Node GPU 通信核心总结

同Node（单服务器）内GPU通信

1. 主流方案（高端计算卡）
• 核心硬件：NVLink（直连）+ NVSwitch（多卡交换）（H100/A100标配）
• 数据路径：GPU←→NVLink/NVSwitch←→GPU，完全绕开CPU/主机内存
• 核心协议：NVIDIA NCCL（底层适配NVLink硬件协议）
• 性能：延迟微秒级，H100单卡NVLink双向带宽达12.8TB/s，8卡通过NVSwitch实现无阻塞全互联

2. 兜底方案（入门卡/消费卡）
• 核心硬件：服务器PCIe 4.0/5.0总线（主板PCIe控制器）
• 数据路径：GPU←→PCIe总线←→主机内存←→PCIe总线←→GPU，必须经CPU/内存转发
• 性能：延迟十微秒级，PCIe4.0 x16双向带宽仅64GB/s，CPU开销高

3. 适用场景：单机2/4/8卡分布式训练/推理、大模型算力基础单元

跨Node（多服务器）间GPU通信

1. 主流方案（生产/云环境）
• 核心硬件：NVIDIA ConnectX-7/8 RDMA专用网卡（RNIC） + InfiniBand交换机（生产级）/RoCE无损以太网交换机（云/中小集群）
• 数据路径：GPU←→GPUDirect RDMA←→RDMA网卡←→集群交换机←→目标RDMA网卡←→GPU，绕开CPU/操作系统内核，显存直传
• 核心协议：NCCL + RDMA（原生InfiniBand协议/以太网RoCE v2协议）
• 性能：延迟百微秒级（InfiniBand）/毫秒级（RoCE），单端口带宽400Gbps（ConnectX-7）/800Gbps（ConnectX-8），CPU开销几乎为0

2. 兜底方案（测试/低算力）
• 核心硬件：普通10G/25G以太网网卡+常规交换机
• 核心协议：TCP/IP
• 性能：延迟毫秒级，带宽低、CPU开销大，会导致GPU空闲等待，完全不适用于大模型训练

3. 适用场景：多节点分布式训练/推理、千亿/万亿参数大模型集群部署、K8s跨节点GPU Pod调度

核心差异极简对比表

第4章 GPU服务器的设计与实现

第5章 机器学习所依托的I/0框架体系

NVIDIA Magnum IO 介绍

核心目标

• 绕过CPU：实现 GPU ↔ 存储、GPU ↔ GPU、GPU ↔ 网络 的直接数据路径

• 消除I/O瓶颈：数据加载、shuffle、checkpoint 等环节提速数倍至数十倍

• 支持海量数据：PB级数据集下的高效训练/推理

Magnum IO 四大核心组成部分

关键技术亮点：GPUDirect Storage (GDS)

• 传统路径：存储 → CPU内存 → CPU拷贝 → GPU显存（多次拷贝、CPU开销大）

• GDS路径：存储 → NIC → GPU显存（直接DMA，零拷贝）

• 支持本地NVMe、远程NVMe-oF、BeeGFS、Lustre、IBM Spectrum Scale 等文件系统

• 已集成进 CUDA Toolkit（11.4+），PyTorch、TensorFlow、DALI、RAPIDS 等框架可直接使用

典型应用场景收益（官方数据参考）

一句话总结

第7章 GPU板卡级算力调度技术

基于虚拟化技术的GPU调度（VM）

基于容器技术的GPU调度（k8s）

1. 调度器（Scheduler）决策：找到合适的 GPU 节点

• 当你提交一个包含 GPU 资源请求（比如 nvidia.com/gpu: 1）的 Pod 时，Kubernetes 控制面的调度器会介入。

• 调度器会从 API Server 获取全集群节点的资源状态，筛选出那些有可用 GPU（nvidia.com/gpu 资源量 ≥ Pod 请求量）的节点。

• 调度器通过优选策略（比如节点负载、GPU 型号匹配等）选择最优节点，然后通过 bind API 将 Pod 绑定到该节点。

• 这个绑定操作会被记录到 etcd 中，同时目标节点的 kubelet 会通过监听 API Server 得知“有一个 Pod 被分配到我这里了”。

2. kubelet 启动容器创建流程，触发设备分配

• 目标节点的 kubelet 监听到 Pod 绑定事件后，开始准备创建容器。

• kubelet 解析 Pod 的资源清单，发现它包含 GPU 这类扩展设备请求，于是将该请求转发给内部的 Device Plugin Manager。

• Device Plugin Manager 向对应的设备插件（比如 nvidia-device-plugin）发起 AllocateRequest（分配请求），传递 Pod 要使用的设备 ID 列表。

3. Device Plugin 执行设备分配，返回资源信息

• 设备插件收到 AllocateRequest 后，会实时检查节点上的物理 GPU 状态，找到一个可用的 GPU 设备。

• 设备插件收集该 GPU 的关键信息：
• 设备路径：Linux 下的设备文件路径（比如 /dev/nvidia0）
• 环境变量：容器运行时需要的 GPU 驱动环境变量（比如 NVIDIA_VISIBLE_DEVICES）
• 挂载信息：驱动文件的挂载路径（比如 /usr/local/nvidia）

• 设备插件将这些信息通过 AllocateResponse 返回给 kubelet 的 Device Plugin Manager。

4. kubelet 配置容器运行时，完成设备隔离与启动

• kubelet 收到 AllocateResponse 后，会将 GPU 设备路径、环境变量和挂载信息注入到容器的配置中。

• 为了保证 GPU 独占，kubelet 会将设备路径的 Namespace 与目标容器的 Namespace 进行绑定，这样其他容器就无法访问该设备文件。

• 最后，kubelet 调用容器运行时（比如 containerd），传递完整的容器配置，启动容器。

• 容器启动后，就可以通过注入的设备路径和环境变量，独占使用这块 GPU 了。

第8章 GPU虚拟化调度方案

第9章 GPU集群的网络虚拟化设计与实现

• IOMMU：IOMMU（Input/Output Memory Management Unit，输入输出内存管理单元）是芯片组上的硬件组件，作用是为外设（GPU / 网卡 / 存储等 PCI-E 设备）提供内存地址转换和隔离能力。IOMMU 是实现 GPU 直通的硬件前提，核心解决 “外设如何安全、独立地访问虚拟机内存” 问题，是虚拟化场景下硬件级设备隔离和直通的基础。