1. 课程导入与全景认知
在开始学习可观测性与性能诊断之前，必须先建立一张清晰的“网络地图”。NVIDIA AI集群的网络并不是一张普通的以太网：它由多条功能、速率、协议各不相同的网络平面叠加而成，每一层承载的流量类型、故障模式和观测手段都不一样。如果分不清哪条流量走哪张网，后续的抓包、计数器和时延分析都会失去参照。
典型的大规模AI训练集群（以DGX/HGX SuperPOD类架构为例）包含以下几张关键网络：
- 计算网络（Compute Fabric / 东西向）：承载GPU之间的集合通信（AllReduce、AllGather、ReduceScatter等），通常采用InfiniBand NDR 400Gb/s或Spectrum-X以太网400/800Gb/s，配合NVLink Switch构成节点内与节点间的分级互联。这是对带宽和时延最敏感的一张网。
- 存储网络（Storage Fabric）：连接计算节点与并行文件系统（如Lustre、GPFS、WEKA），承载checkpoint写入与数据集读取，多为200/400Gb/s以太网或InfiniBand。
- 管理网络（In-band Management）：承载BMC/IPMI、SSH、监控采集、Kubernetes控制面流量，通常为25/100Gb/s以太网。
- 带外网络（Out-of-Band）：独立于业务网的BMC管理通道，用于断电重启、固件升级和带外传感器读取。
节点内部同样存在分层：GPU之间通过NVLink/NVSwitch互联（H100节点内NVLink 4.0单向450GB/s），GPU与网卡之间通过PCIe Gen5 x16连接，网卡再接入外部Fabric。这意味着一次跨节点AllReduce的完整路径是：GPU → NVLink → PCIe → ConnectX网卡 → 光模块/铜缆 → 交换机 → 对端网卡 → PCIe → NVLink → 对端GPU。任何一个环节的瓶颈或错误都会体现在端到端性能上，而定位到具体环节正是本课程要解决的问题。
从图中可以看到，一次跨节点集合通信要穿越至少六个层次。可观测性的价值就在于：把这条路径上每一层的“健康状态”变成可量化、可对比、可告警的数据。缺少任何一层的观测，故障定位就会退化为猜测。
可观测性与性能诊断的核心价值
AI训练任务的性能问题有一个显著特点：症状与根因往往不在同一层。例如，训练吞吐下降30%，表面看是GPU利用率低，实际根因可能是某台交换机的某个端口出现了PFC风暴，或者某条链路发生了降速（从400G协商到200G），又或者NCCL选择了非最优的通信拓扑。如果没有分层观测数据，运维人员只能反复重启任务、更换节点，效率极低。
可观测性体系通常由三类数据构成，它们回答不同的问题：
| 数据类型 | 典型来源 | 回答的问题 | 时间粒度 |
|---|---|---|---|
| 指标（Metrics） | DCGM、Prometheus、IB perfquery | “现在是否正常？趋势如何？” | 秒级～分钟级 |
| 日志（Logs） | NCCL日志、内核dmesg、交换机syslog | “发生了什么事件？何时发生？” | 事件触发 |
| 追踪（Traces） | NCCL拓扑dump、集合通信时间线 | “时间花在哪一段？谁在等谁？” | 微秒级 |
性能诊断则是把这三类数据关联起来，形成从“现象”到“根因”的推理链。例如：观察到AllReduce耗时从8ms涨到15ms（指标），查看NCCL日志发现某条ring路径被跳过（日志），再结合拓扑dump确认是某台leaf交换机端口down导致绕行（追踪），最终定位到具体硬件。
课程目标与学习路径
本课程围绕“看得见、算得清、定得准”三个目标展开。看得见，是指能够采集并理解GPU、网卡、交换机、NCCL四个层面的关键指标；算得清，是指能够根据拓扑和流量模型估算理论带宽、判断实际效率；定得准，是指能够用系统化的方法把性能问题收敛到具体链路、端口或配置项。
学习路径按“架构认知 → 数据采集 → 指标解读 → 诊断方法 → 实战案例”递进。前几章建立网络分层与通信路径的完整图景，中间章节深入DCGM、InfiniBand计数器、NCCL日志、NetQ等工具的具体用法和参数含义，后续章节通过典型故障场景（链路降速、PFC死锁、NCCL拓扑误选、GPU掉卡等）训练诊断思维。
需要特别强调的是，本课程中的示例参数、日志片段和性能数据，除明确标注为实测外，均为教学用合理假设，用于说明分析方法，不代表任何特定生产环境的真实数值。实际诊断时，应以自己集群的基线数据为准。