长期以来，基础模型中的“扩展”主要意味着一件事：在预训练上投入更多算力，能力就会提升。这一直觉得到了 Kaplan 等人（2020）等实证研究的支持，该研究报告了在扩展模型参数、数据集规模和训练算力时，损失函数呈现可预测的幂律趋势。在实践中，这些趋势证明了持续投资大规模加速器容量以及维持其高效利用所需的周边分布式基础设施是合理的。但前沿已经演变——扩展不再是单一曲线。NVIDIA 提出的“从一条扩展定律到三条扩展定律”框架有效地强调了，除了预训练之外，性能还越来越多地通过后训练（例如，监督微调（SFT）和基于强化学习（RL）的方法）以及测试时计算（“长思考”、搜索/验证、多样本策略）来实现扩展。
图：改编自“AI 的三条扩展定律，详解”（NVIDIA 博客）。
综合来看，这些扩展机制将基础模型的生命周期——预训练、后训练和推理——推向趋同的基础设施需求：紧密耦合的加速器计算、高带宽低延迟的网络，以及分布式存储后端。它们还提升了资源管理编排的重要性，以及应用级和硬件级可观测性在维护集群健康和诊断大规模性能问题方面的重要性。
另一个关键趋势是，基础模型生命周期越来越依赖一个涵盖模型开发框架、集群资源管理和运维工具的开源软件（OSS）生态系统。在集群层面，资源管理通常由 Slurm 和 Kubernetes 等系统提供。模型开发和分布式训练则普遍采用 PyTorch 和 JAX 等框架来实现。监控与可视化——即可观测性——通常通过 Prometheus 采集指标、Grafana 进行可视化和告警来实现，它们被定位为基础设施与资源管理之上的运维层。图 1 展示了这种分层架构，说明了硬件基础设施如何支撑资源编排，资源编排又如何赋能机器学习框架，而可观测性则贯穿所有层级。
图 1：用于基础模型训练与推理的开源软件栈分层架构
本文面向参与基础模型训练与推理的机器学习工程师和研究人员，尤其关注基于开源软件框架构建的工作流。文章分析了 AWS 基础设施——包括多节点加速计算、高带宽低延迟网络、分布式共享存储及相关托管服务——如何与基础模型生命周期中常见的开源软件栈进行交互。主要目标是提供技术基础，帮助理解涵盖预训练、后训练和推理环节的系统瓶颈与扩展特性。这篇介绍性文章概述了整体系统架构，重点阐述了 AWS 基础设施组件与支撑大规模分布式训练和推理的开源软件工具之间的集成点。
AWS 基础构建模块
本系列的其余部分将探讨这种分层架构如何在 AWS 上实现，依次深入基础设施、资源编排、机器学习软件栈和可观测性。以下各节将预览每一层。
基础设施：计算、网络与存储
如图 1 所示，基础设施由三个相互耦合的构建模块支撑——配备大容量设备内存的加速计算、用于集合通信的宽带互联网络，以及用于数据和检查点的可扩展分布式存储。
加速计算构成了大规模基础模型预训练、后训练和推理的基础。AWS 提供多代 NVIDIA GPU，作为其 Amazon EC2 加速计算实例的一部分，包括 Amazon EC2 P 实例系列。P5 实例系列包括配备八块 NVIDIA H100 GPU 的 p5.48xlarge、配备单块 H100 GPU 用于较小规模工作负载的 p5.4xlarge，以及配备 NVIDIA H200 GPU 的 p5e.48xlarge/p5en.48xlarge 变体。P6 实例系列引入了采用 NVIDIA Blackwell B200 架构的 p6-b200.48xlarge 和采用 Blackwell Ultra B300 的 p6-b300.48xlarge。在这些代际中，主要的扩展维度是峰值 Tensor 吞吐量、HBM 容量和带宽，以及互联网络带宽（节点内和节点间）。
作为一阶近似，峰值 Tensor Core 吞吐量——以每秒浮点运算次数（FLOPS）衡量——有助于将这些加速器置于同一坐标轴上。下表总结了每块 GPU 在密集 BF16/FP16 和 FP8 Tensor 运算下的峰值吞吐量，以及 HBM 容量和 HBM 带宽，采用与基于 NVSwitch/NVLink 的多 GPU 节点对齐的 SXM/HGX 级规格。
| GPU（代表性变体） | BF16/FP16 Tensor 峰值（密集） | FP8 Tensor 峰值（密集） | FP4 Tensor 峰值（密集） | HBM 容量 | HBM 带宽 |
|---|---|---|---|---|---|
| H100（SXM） | 0.9895 PFLOPS | 1.979 PFLOPS | — | 80 GB HBM3 | 3.35 TB/s |
| H200（SXM） | 0.9895 PFLOPS | 1.979 PFLOPS | — | 141 GB HBM3e | 4.8 TB/s |
| B200（HGX，每块 GPU） | 2.25 PFLOPS | 4.5 PFLOPS | 9 PFLOPS | 180 GB HBM3e | 8 TB/s |
| B300（HGX，每块 GPU） | 2.25 PFLOPS | 4.5 PFLOPS | 13.5 PFLOPS | 288 GB HBM3e | 8 TB/s |
注意：NVIDIA 产品表通常报告“含稀疏性”的 Tensor 吞吐量；本表报告的是密集吞吐量。在适用情况下，密集吞吐量取稀疏吞吐量的一半，遵循 NVIDIA 针对 HGX 级平台的指导（NVIDIA）。DGX 数据为系统级；B200 的 HBM 容量和带宽值通过将 DGX 总数除以八得到每块 GPU 的值（NVIDIA）。
随着模型规模扩大，步进时间往往由集合通信和内存移动主导，而非原始计算吞吐量，这促使我们需要明确核算纵向扩展和横向扩展的带宽。对于多 GPU 实例，GPU 通信涵盖两个领域。内部纵向扩展（NVLink/NVSwitch）在节点内提供高带宽、低延迟的 GPU 到 GPU 连接，使得 all-reduce 和 all-gather 等集合操作无需经过主机网络协议栈即可执行。外部横向扩展（EFA）提供跨节点的操作系统旁路网络，AWS 将其作为 Amazon EC2 UltraClusters 的构建模块，在这些集群中，通信密集型的集合操作可跨越数千个实例。下表总结了这些实例类型的关键规格：
| 实例类型 | GPU | GPU 数量 | GPU 内存 | NVLink | NVLink 带宽（聚合） | EFA | EFA 带宽（聚合） |
|---|---|---|---|---|---|---|---|
| p5.4xlarge | H100 | 1 | 80 GB HBM3 | — | — | v2 | 12.5 GB/s |
| p5.48xlarge | H100 | 8 | 640 GB HBM3 | 第 4 代 | 7.2 TB/s | v2 | 400 GB/s |
| p5e.48xlarge | H200 | 8 | 1,128 GB HBM3e | 第 4 代 | 7.2 TB/s | v2 | 400 GB/s |
| p5en.48xlarge | H200 | 8 | 1,128 GB HBM3e | 第 4 代 | 7.2 TB/s | v3 | 400 GB/s |
| p6-b200.48xlarge | B200 | 8 | 1,440 GB HBM3e | 第 5 代 | 14.4 TB/s | v4 | 400 GB/s |
| p6-b300.48xlarge | B300 | 8 | 2,100 GB HBM3e | 第 5 代 | 14.4 TB/s | v4 | 800 GB/s |
注意：EFA 带宽已从 Gbps 转换为 GB/s（除以 8），以与其他带宽指标保持一致；请参阅 EC2 加速计算网络规格。NVLink 和 EFA 带宽数据以每个实例的聚合值而非每个链路的值显示；请参阅 P5 实例系列页面和 P6 实例系列页面，了解相应的节点内互连和网络特性。
Elastic Fabric Adapter (EFA) 是 Amazon EC2 的一种网络接口，它使用可扩展可靠数据报 (SRD) 协议提供操作系统旁路远程直接内存访问 (RDMA) 能力。通过使应用程序能够通过 Libfabric API 直接与网络设备通信（绕过操作系统内核），EFA 降低了分布式训练中集合操作的延迟并提高了吞吐量。
不同实例系列上提供多代 EFA。Amazon EC2 P5 和 P5e 实例配备 EFA 第二代（EFAv2）。P5en 实例提供的 EFA 第三代（EFAv3）相比 EFAv2 将数据包延迟降低了约 35%。P6 实例上可用的 EFA 第四代（EFAv4）相比 EFAv3，在集合通信性能上又提升了 18%。
在大规模场景下，分布式训练（流式处理语料库和写入数 TB 级别的检查点）和大规模推理（暂存权重和管理 KV 缓存增长）都促使采用分层存储体系——本地 NVMe SSD 用于热数据，Lustre 用于共享高吞吐量访问，Amazon S3 用于持久化存储。
在本系列的主要多 GPU 实例中，本地 NVMe 以实例存储（临时）的形式提供，原始容量为 30.72 TB（8 × 3.84 TB NVMe SSD）；详情请参阅 EC2 加速计算实例存储规格。
Lustre 是一个开源、符合 POSIX 标准的分布式文件系统，广泛应用于高性能计算（HPC），为众多客户端提供具有高聚合吞吐量的共享命名空间。Amazon FSx for Lustre 将 Lustre 作为完全托管服务提供，并将其呈现为一个并行文件系统，能够提供每秒数 TB 的吞吐量、数百万的 IOPS 以及亚毫秒级延迟。数据存储库关联功能支持与 Amazon S3 集成，可实现训练数据集的延迟加载和检查点的自动导出以实现持久化。
在集群规模上，这些实例部署在 Amazon EC2 UltraClusters 中，该集群将数千个加速实例作为一个紧密放置的单一集群部署在单个可用区内，并使用 PB 级无阻塞网络将它们互连。
图：第二代 Amazon EC2 UltraClusters（示例 P5 UltraCluster）。
对于每步通信强度高的工作负载（例如 MoE 模型中的专家并行，其中全对全的 token 分发跨越多个 GPU），NVLink 域的大小可能成为首要约束。作为内部纵向扩展轴的一个延伸，增大 NVLink 域可以减少性能关键的通信必须离开 NVLink 结构的频率。
Amazon EC2 UltraServers 通过专用加速器互连连接多个组件实例，将 NVLink 域扩展到单个 EC2 实例之外。AWS 报告称，P6e-GB200 UltraServers 基于 NVIDIA GB200 NVL72 平台构建，并在一个 NVLink 域内提供多达 72 个 Blackwell GPU 和总计 13.4 TB 的 HBM3e。在更大规模下，EFA 仍然是多 UltraServer 作业的跨节点互联结构，但增加域内 GPU 数量可以减少性能关键型通信必须离开 NVLink 结构的频率。
这些系统由 NVIDIA Grace–Blackwell 超级芯片构建，该芯片通过缓存一致性 NVLink-C2C 将 Grace CPU 内存与 Blackwell GPU HBM 耦合，从而无需显式的主机-设备拷贝即可直接访问 CPU 和 GPU 连接的内存。在实践中，这可以扩展 GPU 工作负载可用的有效内存（例如，将较冷的模型状态或 KV cache 放置在 CPU 连接的内存中），同时避免 PCIe 级别的拷贝开销，尽管其延迟高于本地 HBM，带宽低于本地 HBM。
P6e-GB200 UltraServers 的组件实例类型为 p6e-gb200.36xlarge，提供四个 GPU 和 Elastic Fabric Adapter (EFA) v4 网络。下表总结了每个实例和组合后的 UltraServer 配置。
| 实例类型 | GPU | GPU 数量 | GPU 内存 | 内存带宽 | NVLink | NVLink 带宽 | EFA | EFA 带宽 |
|---|---|---|---|---|---|---|---|---|
| p6e-gb200.36xlarge | GB200 NVL72 | 4 | 740 GB HBM3e | — | — | — | v4 | 200 GB/s |
注意：p6e-gb200.36xlarge 的 EFA 带宽由已发布的聚合 EFA 网络（4 × 400 Gbps）换算为 GB/s（÷8）；请参阅 EC2 加速计算网络规格。
| UltraServer | 组件实例类型 | GPU 数量（NVLink 域） | HBM3e（总计） | EFA | EFA 带宽 |
|---|---|---|---|---|---|
| u-p6e-gb200x36 | p6e-gb200.36xlarge | 36 | 6.7 TB | v4 | 1,800 GB/s |
| u-p6e-gb200x72 | p6e-gb200.36xlarge | 72 | 13.4 TB | v4 | 3,600 GB/s |
注意：UltraServer EFA 带宽由 AWS 报告的每秒太比特 (Tbps) 换算为 GB/s（÷8）；请参阅 P6e-GB200 UltraServers 公告和 P6 实例系列页面。
资源编排：Slurm 和 Kubernetes
当训练任务横跨数百或数千台加速器时，手动资源管理将变得难以处理。例如，一个需要 512 块 GPU 的训练任务必须同时调度 64 个八 GPU 节点（P 实例），并在任务完成或失败时原子化地释放资源。Slurm 和 Kubernetes 都通过控制平面架构来解决这一挑战：集中式调度器维护集群状态并做出分配决策，而工作节点则执行分配的工作负载。
图 2：基于 Slurm 和基于 Kubernetes 的资源编排在 AWS 上的高层架构
Slurm（简单 Linux 资源管理工具）是高性能计算领域占主导地位的工作负载管理器，基于模块化插件架构构建，允许调度算法、拓扑模型、资源类型和计费后端独立配置。其调度模型将资源组织成分区（节点的逻辑分组），通过 sbatch 接受作业提交，并通过 srun 在分配的节点上同步启动并行任务。对于分布式训练而言至关重要的一点是，Slurm 在作业级别进行调度——在任何任务启动之前，原子化地分配整个多节点作业。回填调度器会在空闲槽位中启动优先级较低的作业，而不会延迟优先级较高的作业；同时，多因子优先级系统会权衡公平份额使用量、作业年龄和服务质量等级，以跨租户对队列进行排序。Slurm 还通过插件支持拓扑感知放置，这些插件可对网络交换机层级进行建模——在 AWS 上，可编码 EFA 结构拓扑，将作业共同放置在交换机跳数最少的节点上——并通过其通用资源（GRES）接口支持原生 GPU 调度，该接口可追踪 GPU 类型并强制实施设备亲和性。
AWS 为基于 Slurm 的编排提供了多种部署选项。AWS ParallelCluster 是一款开源集群管理工具，可自动在 EC2 上部署 Slurm 集群，负责管理头节点配置、计算集群扩缩容以及与共享存储的集成。AWS Parallel Computing Service (PCS) 则提供了另一种选择，它具备托管控制平面。针对分布式训练工作负载，Amazon SageMaker HyperPod 支持 Slurm 模式，并提供了专为大规模训练定制的额外功能，例如持续节点健康监控和作业自动恢复功能。
Kubernetes 采用声明式、基于 API 的方法：用户通过资源清单指定期望状态，控制器则负责协调实际状态以匹配期望。虽然 Kubernetes 在模型部署方面表现出色，但其原生调度模型在紧密耦合的分布式训练方面暴露出若干不足。Kubernetes 在 Pod 级别进行调度；缺乏作业级原子性意味着，一个多节点训练作业可能部分启动——某些进程已运行而其他进程仍处于 Pending 状态——从而浪费 GPU 或导致死锁。原生 Kubernetes 也缺乏基于优先级的回填批处理队列语义，以及用于放置通信密集型集合的内置网络拓扑感知能力（NVLink 域、EFA 互连）。
多个 Kubernetes 原生项目在不同层面解决了这些不足。Kueue 作为默认调度器之上的准入控制器运行，管理作业级群体准入、具有层次化公平共享的多租户配额以及基于优先级的抢占——同时将 Pod 放置委托给底层调度器。Volcano 和 NVIDIA KAI Scheduler 则采用不同方法，它们替换或增强默认调度器，将群体调度直接与拓扑感知的 Pod 放置集成——Volcano 作为通用批处理调度器，KAI Scheduler 则具备深度 NVLink/NVSwitch 感知能力，用于 GPU 优化放置。这些层面是互补的：Kueue 可以管理准入和配额策略，同时将已准入的作业传递给拓扑感知调度器进行放置。
在基于 Kubernetes 的 AWS 编排方案中，Amazon Elastic Kubernetes Service（EKS）通过 NVIDIA 设备插件提供托管 Kubernetes 及 GPU 调度能力。Amazon SageMaker HyperPod 也支持 EKS 模式，将 Kubernetes 编排与 HyperPod 的专用训练能力相结合。HyperPod EKS 扩展了 EKS，增加了专为大规模基础模型训练而设计的功能。任务治理功能可跨团队提供计算分配和策略执行，集成了托管 Kueue 用于准入控制，以及 Karpenter 用于即时节点配置。无检查点训练解决了传统基于检查点的容错机制中固有的恢复延迟问题。无检查点训练并非定期将模型状态序列化到共享存储，而是在 GPU 之间维持持续的点对点状态复制。当发生故障时，存活的节点通过基于 EFA 的通信重建丢失的状态，而不是从 FSx for Lustre 或 S3 读取数 TB 大小的检查点。弹性训练使任务能够根据资源可用性自动扩缩。当有额外的加速器可用时（例如，来自已完成的任务或新配置的容量），弹性任务可以扩展以利用它们；当更高优先级的工作负载需要资源时，任务可以收缩，同时保持训练进度。
机器学习软件栈
分布式训练和推理涉及多个软件层，这些层必须正确配置和协调。一个有用的模型将运行时栈视为五个层次，从靠近硬件的组件（这些组件必须正常运行，任何东西才能运行）到框架级别的抽象（这些抽象决定了程序员的生产力和模型吞吐量）：硬件使能、加速器运行时和数学库、通信基础层、机器学习框架，以及分布式训练/推理框架。
图 3：EC2 实例上用于分布式训练和推理的机器学习软件栈
硬件使能：内核驱动程序
在基础层面，Linux 内核驱动程序提供直接的硬件访问。NVIDIA GPU 驱动暴露了计算能力，并支持 GPUDirect RDMA，用于 GPU 与网络适配器之间的直接数据传输。GDRCopy 驱动（gdrdrv）实现了由 CPU 发起的、与 GPU 内存之间的低延迟数据拷贝，NCCL 将其用于小消息传输。EFA 驱动通过 libfabric API 提供绕过操作系统的网络能力，而 Lustre 客户端驱动则支持通过 POSIX 方式访问 FSx for Lustre 并行文件系统。
加速器运行时、编译器与内核库
CUDA 平台为 GPU 计算提供了编程模型和运行时环境。针对 CUDA 编译的应用程序可以在 NVIDIA GPU 上启动内核、管理设备内存，并协调跨多个设备的执行。当前版本为 CUDA Toolkit 13.x，支持 Blackwell 架构（计算能力 10.x）。
现代训练和推理性能日益依赖于专门的优化库和自定义内核，而不仅仅是通用的厂商原语。像 FlashAttention 这样的内核将注意力机制融合为一次内存高效的传递，减少了 HBM 流量并提升了吞吐量。许多团队还会编写针对其具体模型优化的、形状和精度专门化的融合内核（例如，层归一化/残差/激活函数、量化 GEMM、MoE 调度、KV 缓存操作）。这得益于可编程工具链，如 Triton（Python GPU 内核编译器）和 NVIDIA 的 CuTe（张量布局与 warp 级 DSL），以及像 CUTLASS 这样提供高度优化 GEMM 和融合构建块的库。在实践中，这一内核与编译器层对端到端性能的决定性作用，往往不亚于机器学习框架本身。
通信基础：NCCL 与传输插件
多 GPU 训练依赖于高效的集合通信。NVIDIA 集体通信库（NCCL）实现了集合操作——包括全规约、全收集、规约-分散、全到全、广播以及点对点发送/接收——并采用拓扑感知算法，利用 NVLink 进行节点内通信，利用网络传输进行节点间通信。NCCL 能够动态检测通信拓扑，并根据消息大小和可用带宽选择环形或树形算法。虽然数据并行和张量并行策略主要依赖全规约和全收集，但采用专家并行的混合专家（MoE）模型则依赖全到全集合操作在 GPU 之间路由 token：一个分发全到全操作将每个 token 发送到其指定专家所在的 GPU，一个合并全到全操作将专家输出返回给原始 GPU（NVIDIA 开发者博客）。由于专家并行组中的每个 GPU 都会与其他所有 GPU 交换数据，全到全通信量会随专家数量扩展，并在高专家并行度下成为主要瓶颈。
在 AWS 上，NCCL 的节点间通信通过 aws-ofi-nccl 插件实现，该插件将 NCCL 的传输 API 映射到 libfabric 接口。这使得 NCCL 能够利用 EFA 的绕过操作系统机制和可扩展可靠数据报（SRD）协议，而无需修改应用程序。
对于推理工作负载，集合操作并不能涵盖所有通信模式。解耦式推理架构——将预填充和解码阶段分离到不同的 GPU 池中——需要高效的点对点数据移动，特别是在实例之间传输 KV 缓存状态时。NVIDIA 推理传输库（NIXL）通过提供统一的 API，支持跨内存层级（HBM、DRAM、NVMe、分布式存储）和互连方式（NVLink、InfiniBand、以太网）的点对点传输，从而满足这一需求。NIXL 与 NVIDIA Dynamo 等推理框架集成，并支持 UCX 和 GPUDirect Storage 等后端。
机器学习框架：PyTorch
基础模型开发的两大主流框架是 PyTorch 和 JAX。JAX 通过 XLA 采用 SPMD（单程序多数据）方式，即同一程序在多个设备上执行，并自动进行数据分布和集合通信降级。本篇博客聚焦于 PyTorch，它在开源生态系统中应用更广泛，也是下文讨论的分布式训练和推理框架的基础。
PyTorch 提供了支持 GPU 加速的张量计算、自动微分以及灵活的即时执行模式。对于分布式工作负载，PyTorch 的 `torch.distributed` 模块提供了核心原语：用于集合通信的进程组，以及包括分布式数据并行（DDP）和全分片数据并行（FSDP2）在内的分布式数据并行抽象。DDP 在多个 GPU 上复制模型并通过 all-reduce 同步梯度，而 FSDP2 则利用 ZeRO 算法的技术，在工作节点间分片参数、梯度和优化器状态，从而能够训练超出单 GPU 内存容量的模型。
分布式训练与推理框架
顶层是构建在 PyTorch 之上的框架，它们为大规模分布式训练和推理提供了更高级的抽象。在训练方面，三类框架在复杂性与性能的权衡中各有侧重。以下是一些示例：
Hugging Face Transformers 提供了 Trainer 类，通过 Accelerate 内置了对分布式训练的支持，Accelerate 对 DDP、FSDP 和 DeepSpeed 进行了抽象。这一路径优先考虑易用性和广泛的模型兼容性，适用于微调和中等规模的训练场景，在这些场景中，配置的简洁性比最大化吞吐量更重要。
NVIDIA Megatron Core 旨在实现大规模下的最高效率，它实现了 3D 并行（张量并行、流水线并行和专家并行），并通过 Transformer Engine 进行了 FP8 混合精度等优化。NeMo 框架构建在 Megatron Core 之上，为预训练和微调提供了端到端的工作流程。
对于基于人类反馈的强化学习（RLHF）及相关后训练方法，veRL（火山引擎强化学习）提供了一个灵活的框架，实现了包括 PPO、GRPO 和 REINFORCE++ 在内的算法。veRL 的 HybridFlow 架构允许在同一任务中混合使用训练后端（FSDP2、Megatron）与推理引擎（vLLM、SGLang），通过在 Actor 和 Rollout 组件之间共享内存中的模型权重，避免了权重同步的开销。
在推理服务方面，vLLM 实现了 PagedAttention，将 KV 缓存作为分页虚拟内存进行管理，以减少碎片化并支持更高的批处理规模。SGLang 在此基础上扩展了 RadixAttention，实现了跨请求的自动前缀复用，并配备了一个零开销的批处理调度器，可将 CPU 调度与 GPU 计算重叠执行，以及一个缓存感知的负载均衡器，可根据预测的缓存命中率来路由请求。这两个框架都支持张量并行，用于服务超出单 GPU 内存的模型，并且都与 NVIDIA Dynamo 集成，支持将预填充和解码阶段分离的解耦式服务架构。
可观测性
可观测性是调试和运维大规模分布式训练系统的前提。当训练任务停滞或吞吐量下降时，从业人员需要了解原因究竟是硬件故障、网络拥塞、存储瓶颈，还是应用层面的低效。在本系列讨论的基础设施规模下——数千块 GPU、每秒 PB 级的互联带宽以及 TB 级的检查点数据——挑战已从简单的监控转变为系统化的遥测数据采集、存储与分析。可观测性涵盖三类遥测数据：基础设施指标（GPU、网络、存储）、工作负载指标（训练吞吐量、队列延迟），以及用于主动故障检测的告警机制。
核心技术栈：Prometheus 和 Grafana
Kubernetes 和 HPC 环境中可观测性的事实标准，是将 Prometheus 用于指标采集，与 Grafana 用于可视化和告警相结合。Prometheus 采用基于拉取的模型，定期抓取指标导出器暴露的 HTTP 端点。采集到的指标存储在时序数据库（TSDB）中，并通过 PromQL（一种灵活的查询语言，用于聚合、过滤和告警规则评估）进行查询。Grafana 将 Prometheus 作为数据源使用，基于 PromQL 表达式渲染仪表盘并触发告警。
对于生产部署，Amazon Managed Service for Prometheus（AMP）提供了一个完全托管的、兼容 Prometheus 的时序数据库，能够扩展以每秒处理数百万个样本，无需运维人员管理存储、复制或高可用性。Amazon Managed Grafana（AMG）提供了一个托管的 Grafana 工作空间，原生集成了 AMP，并通过 IAM Identity Center 实现 AWS 身份验证。这些服务共同消除了运维开销，同时保持与现有 Prometheus 导出器和 Grafana 仪表盘的兼容性。
GPU、网络和应用遥测
DCGM-Exporter 以 Prometheus 格式暴露 NVIDIA GPU 指标，包括利用率、内存使用量、功耗、温度以及硬件健康指标（如 ECC 错误和 XID 事件）。对于训练工作负载，SM 活动（DCGM_FI_PROF_SM_ACTIVE）通常比基本利用率指标更能准确衡量计算效率。
EFA 暴露驱动级别的统计数据（字节数、数据包数、重传次数、超时次数），有助于诊断分布式训练中的集合通信瓶颈。aws-ofi-nccl 插件将 NCCL 桥接到 libfabric 接口，运维人员可以将 EFA 计数器与 NCCL 诊断信息（NCCL_DEBUG=INFO）结合使用，以隔离网络层问题。
Amazon FSx for Lustre 暴露客户端侧指标，包括吞吐量和元数据延迟，而应用层指标（训练中的步骤时间、每秒 token 数、损失值；推理中的 TTFT、token 间延迟）可以通过 Prometheus 客户端库导出。
GPU 健康监控与告警
主动故障检测可防止硬件问题演变为长时间的训练中断。典型的工作流程会监控 DCGM 健康指标，并在错误计数超过阈值时触发告警。少量 ECC 单比特错误 (SBE) 或许可以容忍，但加速增长的 SBE 速率往往预示着双比特错误 (DBE) 或其他故障。XID 63（行重映射失败）、XID 64（GPU 从总线脱落）以及 XID 94/95（受控/非受控错误）通常需要立即更换节点。
GPU 健康 - 集群仪表盘（Grafana 仪表盘 ID 21645）为常见的 GPU 错误模式提供了参考可视化。该仪表盘汇总了所有集群节点上的 ECC 错误、XID 事件、热违规和行重映射状态，使运维人员能够在故障硬件影响训练任务之前识别出来。
图 4：GPU 健康 - 集群仪表盘，显示 GPU 错误模式和实例报告
结论
从单一的预训练扩展定律转变为三个互补的范式——预训练、后训练和测试时计算——并未分散基础设施需求，反而强化了它们。所有这三个范式都要求紧密耦合的加速器计算、高带宽低延迟的网络以及可扩展的分布式存储，主要区别在于工作负载特征和资源调度模式。
本文揭示了在 AWS 上满足这些需求的四层架构：基础设施构建块（EC2 P 实例、EFA 网络和分层存储）、资源编排（Slurm 和 Kubernetes 配合 SageMaker HyperPod）、机器学习软件栈（从内核驱动和 CUDA，经 NCCL 到 PyTorch），以及可观测性（Prometheus、Grafana 和 GPU 健康监控）。每一层都约束并赋能其上层——一个配置错误的驱动程序或饱和的网络链路，与一个次优的并行策略一样，都能有效地使原本调优良好的训练运行陷入瓶颈。
理解这些集成点是诊断性能瓶颈并在基础模型生命周期中做出明智扩展决策的基础。
Aman Shanbhag 是 NVIDIA MARS MLOps 团队的 AI 性能与基础设施工程师，他协助研究团队构建可扩展的高性能机器学习训练与推理系统。此前，他曾在 AWS 担任专家解决方案架构师，为全球客户提供 AWS 上的机器学习训练与推理优化支持。Aman 拥有莱斯大学计算机科学、数学与创业学学位，主要研究方向为 AI 基础设施、性能优化以及分布式训练与推理。
Pavel Belevich 是 Amazon Web Services GenAI ML 框架团队的高级应用科学家。他将自己在分布式训练与大规模模型推理方面的研究成果应用于生产规模的实际客户工作负载中。在加入 AWS 之前，Pavel 曾在 PyTorch 分布式团队工作，为 FSDP 和流水线并行等核心分布式训练技术做出了贡献。在 AWS，他专注于 MoE 通信模式以及大规模服务/训练工作流。他还定期通过关于专家并行和大规模模型系统的深度技术分享来传播最佳实践。
Keita Watanabe 是 Amazon Web Services GenAI ML 框架团队的首席解决方案架构师，他专攻机器学习系统性能工程，并为全球客户提供 AWS 上的机器学习训练与推理优化支持。他的背景是机器学习研究与开发。在加入 AWS 之前，Keita 曾在乐天担任研究科学家，开发了一套基于图像的商品搜索系统。Keita 拥有东京大学的科学博士学位。