AWS 基础模型训练与推理的构建模块

来源：https://huggingface.co/blog/amazon/foundation-model-building-blocks 返回文章列表 (https://huggingface.co/blog)

• AWS 构建模块 (https://huggingface.co/blog/amazon/foundation-model-building-blocks#the-aws-building-blocks)- 基础设施：计算、网络与存储 (https://huggingface.co/blog/amazon/foundation-model-building-blocks#infrastructure-compute-network-and-storage) - 资源编排：Slurm 和 Kubernetes (https://huggingface.co/blog/amazon/foundation-model-building-blocks#resource-orchestration-slurm-and-kubernetes) - ML 软件栈 (https://huggingface.co/blog/amazon/foundation-model-building-blocks#ml-software-stack) - 可观测性 (https://huggingface.co/blog/amazon/foundation-model-building-blocks#observability)
• 结论 (https://huggingface.co/blog/amazon/foundation-model-building-blocks#conclusion)
• 作者 (https://huggingface.co/blog/amazon/foundation-model-building-blocks#authors)

长期以来，基础模型中的“扩展”主要意味着一件事：在预训练上投入更多算力，模型能力随之提升。这种直觉得到了诸如 Kaplan 等人 (2020) (https://arxiv.org/abs/2001.08361) 等实证研究的支持，该研究指出随着模型参数、数据集规模和训练算力的扩展，损失值呈现出可预测的幂律趋势。在实践中，这些趋势证明了持续投资大规模加速器容量以及维持其高效利用所需的分布式基础设施是合理的。但前沿领域已经演变——扩展不再是一条单一的曲线。NVIDIA 提出的“从一到三的扩展定律”框架有力地强调，除了预训练之外，性能越来越通过后训练（例如，基于监督微调 (SFT) 和强化学习 (RL) 的方法）以及推理时计算（“长时间思考”、搜索/验证、多样本策略）来扩展。

3-Scaling-Laws-Chart-1280x720 (https://cdn-uploads.huggingface.co/production/uploads/64d6b270c2eedf9af82baa23/X5ZiXBoPmJzcDhaiL_Zkf.jpeg)

**图：**改编自“AI 的三大扩展定律详解” (https://blogs.nvidia.com/blog/ai-scaling-laws/)(NVIDIA 博客)。

综合来看，这些扩展机制推动基础模型生命周期——预训练、后训练和推理——走向收敛的基础设施需求：紧密耦合的加速器计算、高带宽低延迟网络以及分布式存储后端。这也提高了资源管理编排的重要性，以及应用级和硬件级可观测性对于维护集群健康和诊断大规模性能问题的重要性。

另一个关键趋势是基础模型生命周期对开源软件 (OSS) 生态系统的依赖日益增加，该生态系统涵盖模型开发框架、集群资源管理和运营工具。在集群层，资源管理通常由 Slurm (https://slurm.schedmd.com/documentation.html)和 Kubernetes (https://kubernetes.io/docs/) 等系统提供。模型开发和分布式训练通常在 PyTorch (https://pytorch.org/)和 JAX (https://jax.readthedocs.io/) 等框架中实现。监控和可视化（即可观测性）通常使用 Prometheus (https://prometheus.io/docs/introduction/overview/) 进行指标收集，使用 Grafana (https://grafana.com/docs/grafana/latest/) 进行可视化和告警，作为基础设施和资源管理之上的运营层。图 1 展示了这种分层架构，说明了硬件基础设施如何支持资源编排，进而启用 ML 框架，而可观测性则贯穿所有层。

Building Blocks Intro (https://cdn-uploads.huggingface.co/production/uploads/64d6b270c2eedf9af82baa23/QSBYRirLS8pkgJK3rvqMF.png)

图 1：用于基础模型训练和推理的开源软件栈的分层架构

本文面向参与基础模型训练和推理的机器学习工程师和研究人员，特别关注基于 OSS 框架构建的工作流。它分析了 AWS 基础设施（包括多节点加速器计算、高带宽低延迟网络、分布式共享存储及相关托管服务）如何与基础模型生命周期中常见的 OSS 栈交互。主要目标是提供技术基础，以理解跨越预训练、后训练和推理的系统瓶颈和扩展特性。这篇介绍性文章揭示了整体系统架构，强调了 AWS 基础设施组件与支撑大规模分布式训练和推理的 OSS 工具之间的集成点。

https://huggingface.co/blog/amazon/foundation-model-building-blocks#the-aws-building-blocksAWS 构建模块

本系列的其余部分将探讨这种分层架构如何在 AWS 上实现，依次介绍基础设施、资源编排、ML 软件栈和可观测性。以下各节预览每一层。

https://huggingface.co/blog/amazon/foundation-model-building-blocks#infrastructure-compute-network-and-storage基础设施：计算、网络与存储

如图 1 所示，基础设施由三个耦合的构建模块锚定——具有大设备内存的加速计算、用于集合通信的宽带宽互连，以及用于数据和检查点的可扩展分布式存储。

加速计算构成了大规模基础模型预训练、后训练和推理的基础。AWS 在其 Amazon EC2 加速计算实例 (https://aws.amazon.com/ec2/instance-types/accelerated-computing/) 中提供了几代 NVIDIA GPU，包括 Amazon EC2 P 实例家族。P5 实例家族 (https://aws.amazon.com/ec2/instance-types/p5/) 包括配备八 NVIDIA H100 (https://www.nvidia.com/en-us/data-center/h100/) GPU 的 p5.48xlarge，配备单个 H100 GPU 以处理较小规模工作负载的 p5.4xlarge，以及配备 NVIDIA H200 (https://www.nvidia.com/en-us/data-center/h200/) GPU 的 p5e.48xlarge/p5en.48xlarge 变体。P6 实例家族 (https://aws.amazon.com/ec2/instance-types/p6/) 引入了 NVIDIA Blackwell B200 (https://www.nvidia.com/en-us/data-center/dgx-b200/) 架构，包括 p6-b200.48xlarge 以及 Blackwell Ultra B300 (https://developer.nvidia.com/blog/inside-nvidia-blackwell-ultra-the-chip-powering-the-ai-factory-era/) 的 p6-b300.48xlarge。在这些代际中，主要的扩展轴是峰值 Tensor 吞吐量、HBM 容量和带宽，以及互连带宽（节点内和跨节点）。

作为一阶近似，峰值 Tensor Core 吞吐量（以每秒浮点运算数 (FLOPS) 衡量）有助于将这些加速器置于一个共同的轴上。下表总结了每张 GPU 的密集 BF16/FP16 和 FP8 Tensor 操作的峰值吞吐量，以及 HBM 容量和 HBM 带宽，使用的是与基于 NVSwitch/NVLink 的多 GPU 节点对齐的 SXM/HGX 级规范。

随着模型规模扩大，步骤时间通常由集合通信和内存移动主导，而不是原始计算吞吐量，这促使进行明确的向上扩展（scale-up）和向外扩展（scale-out）带宽核算。对于多 GPU 实例，GPU 通信跨越两种机制。**内部向上扩展（NVLink/NVSwitch）**提供节点内高带宽、低延迟的 GPU 到 GPU 连接，使 all-reduce 和 all-gather 等集合操作得以执行而无需遍历主机网络栈。**外部向外扩展（EFA）**提供跨节点的操作系统旁路网络，AWS 将其用作 Amazon EC2 UltraClusters (https://aws.amazon.com/ec2/ultraclusters/) 的构建模块，其中通信密集型集合操作跨越数千个实例。下表总结了这些实例类型的关键规格：

Elastic Fabric Adapter (EFA) 是 Amazon EC2 的网络接口，使用 Scalable Reliable Datagram (SRD) (https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/efa.html) 协议提供操作系统旁路的远程直接内存访问 (RDMA) 能力。通过允许应用程序通过 Libfabric API 直接与网络设备通信——绕过操作系统内核——EFA 减少了延迟并提高了分布式训练中集合操作的吞吐量。

不同实例家族上提供多代 EFA。Amazon EC2 P5 和 P5e 实例配备了 EFA 第 2 版 (EFAv2)。在 P5en 实例上提供的 EFA 第 3 版 (EFAv3) 相比 EFAv2 将数据包延迟降低了约 35% (https://aws.amazon.com/blogs/aws/new-amazon-ec2-p5en-instances-with-nvidia-h200-tensor-core-gpus-and-efav3-networking/)。在 P6 实例上可用的 EFA 第 4 版 (EFAv4) 相比 EFAv3 在集合通信性能上又提高了 18% (https://aws.amazon.com/blogs/machine-learning/aws-ai-infrastructure-with-nvidia-blackwell-two-powerful-compute-solutions-for-the-next-frontier-of-ai/)。

在大规模场景下，分布式训练（流式语料库和写入多 TB 检查点）和大规模推理（暂存权重和管理 KV 缓存增长）都推动了分层存储层次结构——用于热数据的本地 NVMe SSD、用于共享高吞吐访问的 Lustre 以及用于持久存储的 Amazon S3 (https://aws.amazon.com/s3/)。

在本系列的主要多 GPU 实例中，本地 NVMe 作为**实例存储（临时）**提供，原始容量为 30.72 TB（8 × 3.84 TB NVMe SSD）；请参阅 EC2 加速计算实例存储规范 (https://docs.aws.amazon.com/ec2/latest/instancetypes/ac.html#ac_instance-store)。

Lustre (https://www.lustre.org/about/) 是一种开源、符合 POSIX 的分布式文件系统，广泛用于高性能计算 (HPC)，以在多个客户端之间提供具有高聚合吞吐量的共享命名空间。Amazon FSx for Lustre (https://aws.amazon.com/fsx/lustre/) 提供 Lustre 作为完全托管服务，并将其暴露为并行文件系统，能够提供 TB/秒的吞吐量、数百万 IOPS 和亚毫秒级延迟。数据仓库关联 (Data Repository Associations) 支持与 Amazon S3 (https://aws.amazon.com/s3/) 的集成，支持训练数据集的懒加载和自动检查点导出以确保持久性。

在集群规模上，这些实例部署在 Amazon EC2 UltraClusters (https://aws.amazon.com/ec2/ultraclusters/) 中，后者在一个可用区内将数千个加速实例配置为单个紧密放置的集群，并使用 PB 级无阻塞网络互连它们。

ec2-ultraclusters-gen2 (https://cdn-uploads.huggingface.co/production/uploads/64d6b270c2eedf9af82baa23/iMu8fYvHpDiGrquj6d-6m.jpeg)

**图：**第二代 Amazon EC2 UltraClusters（示例 P5 UltraCluster）。

对于每步通信强度高的工作负载（例如，MoE 模型中的专家并行性，其中 all-to-all 令牌分发跨越多个 GPU），NVLink 域的大小可能成为一阶约束。作为内部向上扩展轴的扩展，增加 NVLink 域可以减少性能关键通信必须离开 NVLink 织构的频率。

Amazon EC2 UltraServers (https://aws.amazon.com/ec2/ultraservers/) 通过专用加速器互连连接多个组件实例，将 NVLink 域扩展到单个 EC2 实例之外。AWS 报道，P6e-GB200 UltraServers (https://aws.amazon.com/about-aws/whats-new/2025/07/amazon-p6e-gb200-ultraservers-gpu-performance-ec2/) 构建在 NVIDIA GB200 NVL72 (https://www.nvidia.com/en-us/data-center/gb200-nvl72/) 平台之上，在一个 NVLink 域内暴露多达 72 个 Blackwell GPU 和 13.4 TB 的聚合 HBM3e。在更大规模上，EFA 仍然是跨多 UltraServer 作业的节点间织构，但增加域内 GPU 数量可以减少性能关键通信必须离开 NVLink 织构的频率。

这些系统由 NVIDIA Grace–Blackwell 超级芯片构建，通过缓存一致的 NVLink-C2C (https://developer.nvidia.com/blog/nvidia-grace-hopper-superchip-architecture-in-depth/) 耦合 Grace CPU 内存和 Blackwell GPU HBM， enabling 直接访问 CPU 和 GPU 附加内存而无需显式的主机-设备复制。在实践中，这可以扩展 GPU 工作负载的有效可用内存（例如，将较冷的模型状态或 KV 缓存放置在 CPU 附加内存中），同时避免 PCIe 级复制开销，尽管其延迟更高且带宽低于本地 HBM。

P6e-GB200 UltraServers 的组件实例类型为 p6e-gb200.36xlarge (https://aws.amazon.com/ec2/instance-types/p6/)，提供四个 GPU 和 Elastic Fabric Adapter (EFA) v4 网络。下表总结了每实例和组合 UltraServer 配置。

注意：p6e-gb200.36xlarge 的 EFA 带宽从发布的聚合 EFA 网络（4 × 400 Gbps）转换为 GB/s（÷8）；请参阅 EC2 加速计算网络规范 (https://docs.aws.amazon.com/ec2/latest/instancetypes/ac.html#ac_network)。