LLM Wiki

资料摘要：A100 SXM GPU 节点认识、配置与带宽测试

10分钟阅读

资料摘要：A100 SXM GPU 节点认识、配置与带宽测试

五道口纳什的 32 分钟 A100 节点实操入门。以一台 8× A100 80GB SXM4 + 6× NVSwitch 节点为例，建立从 GPU 封装、节点内拓扑到算力/PCIe/NVLink/HBM 分层测试的最小心智模型。AI Infra 的关键不是背某个跑分，而是先判断数据正在跨越哪条硬件边界。

核心要点

  • SXM 与 PCIe 是 GPU 模组/封装形态，不等于通信协议。 A100 SXM4 仍经 PCIe Gen4 x16 与 CPU 通信；SXM/HGX 的优势是可把 GPU、供电散热与高速互联集成在专用底板。
  • 拓扑决定多卡通信能力。 视频中的 HGX A100 由 6 个 NVSwitch 组成交换层，每张 GPU 与每个 switch 以两条 NVLink 相连，共 12 条；任意 GPU 对均可经统一交换网络通信。典型 PCIe 卡则多为相邻双卡的 NVLink bridge 配对。
  • HGX 是 GPU 子系统，DGX 是完整整机。 前者围绕 GPU + NVLink/NVSwitch + 管理/供电；后者再集成 CPU、DRAM、NVMe、网络和软件栈。
  • 带宽必须分路径测量： CPU DRAM ↔ GPU HBM 受 PCIe/NUMA 影响；GPU ↔ GPU 受 NVLink/NVSwitch 影响；HBM ↔ SM 是单卡内部带宽。三者不可混为一个“带宽”。
  • 视频样机的基准是合理性检查而非通用规格： PCIe Gen4 x16 单向约 23–24 GB/s（理论约 31.5）；GPU 对单向约 277–281 GB/s（理论 300）；HBM 本地 copy 约 1824 GB/s（标称约 2 TB/s）。
  • GPU Burn 用于高压力稳定性。 它循环矩阵乘并校验结果；视频中不开 Tensor Core 约 19 TFLOPS，打开后约 144–147 TFLOPS。它不能代表真实模型训练吞吐。
  • CPU–GPU 路径要优先关注 NUMA。 非本地 CPU socket 的 DRAM 到 GPU 可能多跨一次 CPU 互联，影响数据加载、offload 与 PCIe benchmark。

详细笔记

1. SXM、PCIe、HGX、DGX 的层级（00:00–10:55）

PCIe 版本是插槽卡，经金手指接主板。SXM 是固定在 HGX baseboard 上的扁平服务器 GPU 模组；它并非“GPU 不再使用 PCIe”，而是让 GPU 可以和 NVLink/NVSwitch 构成更高密度平台。视频中 8 卡 A100 SXM4 由 6 枚 NVSwitch 组成全交换网络：每 GPU 有 12 条 NVLink 接入交换层。

因此“同为 8×A100”不等价：NVLink bridge 的双卡岛与 HGX 的全互联，对张量并行、专家并行以及 all-reduce 的代价不同。

flowchart LR
 CPU[CPU + 主机 DRAM] <-->|PCIe Gen4 x16| G0[GPU 0
A100 SXM4]
 G0 <-->|12× NVLink| SW[NVSwitch 交换层]
 SW <-->|12× NVLink| G1[任意其他 A100]
 G0 <-->|本地 HBM2e| SM[SM / Tensor Core]

2. 到手节点先建立可重复的验机环境（10:55–18:45）

视频先配置 ~/.ssh/config 别名、KeepAlive 和 ssh-copy-id 免密，再设置代理；工具层使用 zsh、补全/语法高亮、fzf 和 uv。硬件盘点分为：

  1. OS、CPU、DRAM、存储：inxi、btop、dmidecode 等；示例节点为 Ubuntu 22.04、双路 AMD EPYC 7742、1 TB DDR4、NVMe + SATA SSD。
  2. GPU 状态与进程：nvidia-smi 为基础，nvtop/nvitop 用于实时观察。
  3. 拓扑：确认 GPU–GPU 链路、PCIe generation/width 和 NUMA affinity；不能只看“安装了 NVLink”。

3. GPU Burn：健康压力而非端到端训练 benchmark（18:45–23:55）

GPU Burn 以高显存占用反复计算 ，并比较结果一致性，以发现持续重载下的散热、供电、显存或计算错误。视频以约 90% 可用显存测试；不用 Tensor Core 时约 19 TFLOPS，使用后约 144–147 TFLOPS。

矩阵乘工作量约为 FLOPs，但该分数只能说明特定精度/实现下的压力表现。真实训练还取决于 dtype、kernel、集体通信、数据管线、并行策略和显存管理。

4. 分层带宽：先标注路径、方向与并发（23:55–32:24）

路径物理链路视频样机的量级主要影响
Host ↔ DeviceCPU DRAM ↔ PCIe Gen4 x16 ↔ GPU HBM理论约 31.5 GB/s 单向；实测约 23–24 GB/s数据加载、CPU offload、checkpoint、NUMA
Device → DeviceNVLink + NVSwitch理论约 300 GB/s 单向；实测约 277–281 GB/s节点内 all-reduce、TP/EP
Device ↔ Device双向 NVLink标称约 600 GB/s 双向必须区分 copy engine/SM、单向/双向
Device localHBM2e ↔ SM/本地 copy标称约 2 TB/s；实测约 1824 GB/smemory-bound kernel、KV cache

视频使用 NVIDIA/nvbandwidth 测量 host↔device、device↔device、双向与聚合模式。即使 7 张卡同时对一张卡发送数据，也不能将 7 个对端读数简单相加；接收 GPU 的总 NVLink 注入能力仍是上界。

5. 课件代码把「带宽」落实为可复现实验（课件 17–24 单元）

已获得授权的课件仓库提供了同一节课的 notebook，以及两个最小、可读的 PyTorch 基准脚本。它们使视频中的“23–24 GB/s PCIe”和“约 1.8 TB/s HBM”不再只是跑分结论，而是可以核对计量口径的实验。

文件实验对象实现与计量口径应如何解读
pcie_bw_core.pyHost pinned DRAM ↔ PCIe DMA ↔ GPU HBM分配 512 MiB pinned uint8 host buffer 与 GPU buffer；各 warm-up 5 次、计时 50 次 copy_(..., non_blocking=True)；仅按实际搬运的 payload 字节数除以时间分别报告 H2D / D2H 单向有效载荷带宽；进程应在目标 GPU 所属 NUMA CPU 上启动，再分配 pinned memory
hbm_bw_core.py单卡 HBM 内部分配 3 个 1 GiB float32 GPU tensor；warm-up 5 次、计时 30 次；z.copy_(x) 报 payload 与 读+写 = 2N HBM 流量，z=x+y 按 2 读 + 1 写 = 3N 计这是单 GPU 内存子系统的吞吐实验，不经过 PCIe；copy engine 和 SM stream-add 的结果不能混作同一指标

两段代码都使用 torch.cuda.Event 计时并在 warm-up 后 torch.cuda.synchronize()；因此测量的是已提交 CUDA 工作完成的 GPU 侧时间，而不是 Python 调度开销。pcie_bw_core.py 的 pin_memory=True 不是优化细节：它提供可 DMA 的 page-locked host buffer，缺失它会让 H2D/D2H benchmark 失去可比性。

字节计数是这节课最容易被忽略的部分。 对 z.copy_(x)，payload 是 bytes，但 HBM 同时读源并写目标，故 HBM traffic 应报 ；对 z=x+y，两个输入读加一个输出写，故是 。同样，PCIe 脚本只报告跨总线的 payload，不能把 HBM 内部读/写再加进去。

课件还给出可直接复现实验的环境入口，例如 GPU=0 uv run --no-project --index https://download.pytorch.org/whl/cu130 --with torch,numpy python pcie_bw_core.py；运行前需将脚本置于 CUDA Linux 节点并确认 torch.cuda.is_available()。我已在当前 Mac 上验证代码可被读取，但没有把它当成已在本机运行成功的 GPU 结果：此主机没有 CUDA PyTorch，调用会在 torch.cuda.set_device 处失败。

6. 可复用验机顺序

  1. 盘点 GPU 型号/显存、驱动/CUDA、CPU sockets、NUMA、DRAM、存储与网络。
  2. 检查 PCIe generation/width、GPU–GPU link 和 NUMA affinity。
  3. 用 GPU Burn 结合温度、功耗、ECC/Xid 做单卡与全卡稳定性压力。
  4. 分别测 host↔device、每对 GPU、聚合通信与 HBM；记录方向、buffer、并发与测试引擎。
  5. 最后用真实框架的 NCCL collective 与目标模型，确认微基准能否转成端到端吞吐。

引用与数据

相关

关系图谱

反向链接