高效地调度GPU非常重要（使用Ideogram 2.0生成的AI图像）
GPU 调度高效，能够支持 MLOps 中的大规模分布式训练和部署日益复杂的模型。在处理大型机器学习模型或 PB 级数据时，GPU 的计算能力远远高于 CPU。通过并行处理数千个任务，GPU 能够大大缩短训练时间并降低相关成本。
组织可以通过有效地将工作负载分配到多个GPU上来降低能耗和运营成本。例如，DeepSeek-V3——一个需要2,788,000个NVIDIA H800 GPU小时的6710亿个参数专家混合体模型，在不到两个月的时间里，使用一个2048个GPU的集群训练了14.8万亿个token。 这展示了如何通过高效使用GPU显著提升大规模性能。
如果您错过了我关于MLOps中分布式处理的迷你系列的第一部分，我在其中讨论了分布式训练的核心策略和MLOps实现的实际模式。在这第二篇里，我们将更深入地探讨GPU加速的分布式训练，剖析扩展现代机器学习工作负载所需的关键技术考量等等。
- 系统设置 — 如何启用 GPU 加速的机器来进行分布式训练？
- 编排 — 在 Kubernetes 和 HPC 系统中优化 GPU 集群的策略
- 性能优化 — 系统级调优以提高吞吐量和优化资源利用。
查看本系列的其他文章
使用分布式计算加速MLOps，实现可扩展的机器学习让您的MLOps平台能够更快更高效地训练大规模模型——因为您的模型需要团队合作来变得更快更强大 打破GPU供应商的锁定：在混合AMD和NVIDIA集群上进行分布式MLOps解锁混合GPU集群上的分布式PyTorch作业：在混合GPU集群上运行分布式PyTorch作业，使用AWS的NVIDIA g4dn和AMD GPU…medium.com我在这次演示中使用了配备了 NVIDIA T4 GPU 的 AWS G4dn 实例和配备了 AMD Radeon Pro V520 GPU 的 G4ad 实例。虽然这款特定的 AMD GPU 已不再被最新的 ROCm 版本正式支持，但是可以通过从源代码构建来获取所需的库：从源代码构建。所有相关的图像定义、构建说明、CUDA 12.4（适用于 Turing 架构）和 ROCm 6.2.2（适用于 GFX1011）以及 PyTorch 2.5.1（含示例训练任务和云基础设施）都可在我的代码库中找到：你可以在这里找到它们：
GitHub — RafalSiwek/distributed-mlops-overview: MLOps分布式处理解决方案的探索，探索分布式处理解决方案。 — RafalSiwek/distributed-mlops-overview 开启多GPU通信功能来进行分布式训练高效的多GPU通信对于扩展分布式训练至关重要，但没有适当优化却颇具挑战，因为在没有适当优化的情况下达到近乎线性的加速效果颇具挑战。
想象将一个模型分布在多个GPU上：理论上，训练应该近乎线性地扩展，但在实践中，每个all_reduce操作——梯度同步的核心——变成了内存复制的系列过程。如果没有经过GPU优化的通信库，数据必须经过一个复杂的路径：GPU → PCI-E → CPU RAM → PCI-E → NIC → 网络 → 重复以上过程。这会导致显著的延迟和吞吐量下降。
使用基于gRPC的集体通信将数据从GPU传输到CPU时，需要在CPU上进行内存缓冲——这样做会增加处理的延迟时间。
标准的多节点通信方法，如 gRPC ，在许多分布式系统中很常见。gRPC 非常适合一般的远程过程调用，但并不特别适合高吞吐量和低延迟的需求。它依赖于 CPU 来进行数据的序列化、反序列化以及在网络层之间传输的额外数据处理工作。这使得 gRPC 在处理大量张量传输时速度明显较慢。
GPU优化的集体通信库，如NCCL（NVIDIA）和RCCL（AMD），提供了更好的性能。它们的优势在于巧妙地配合现代硬件拓扑结构，例如在一个CUDA或ROCm（HIP）内核中执行整个All-Reduce操作的过程。在基于TCP的云网络环境中，NCCL/RCCL将小张量聚合为更少的大包，摊薄了TCP/IP的通信开销。这种方法避免了通信碎片化，并使得数据可以直接从GPU内存传输到网络接口，从而释放了CPU的处理周期。
基准测试显示，与标准的 CPU 中介方法（如 gRPC）相比，这些库可以让多节点通信速度提高到原来的 5 到 6 倍，特别是在处理大量张量任务时。
MPI+NCCL与gRPC的整体性能比较（来自https://arxiv.org/pdf/1901.01703，如下所示）
像 PyTorch 这样的框架提供了多种方式来抽象这些后端（https://pytorch.org/docs/stable/distributed.html）。NCCL/RCCL 在 GPU 工作负载中表现出色，采用了拓扑感知算法（环状和树状）来最大化网络带宽利用率，使其成为同构多节点 GPU 集群的理想选择。相比之下，Gloo 更侧重于可移植性，但依赖 CPU 来进行网络传输。
使用 PyTorch 实现 GPU 加速的多进程分布式训练非常简单，该过程主要包括两个步骤。
# [...]
#1 分配指定的GPU设备并选择`nccl`后端（用于分布式训练的通信后端）
def ddp_setup():
torch.cuda.set_device(int(os.environ["LOCAL_RANK"])) # 获取分配的GPU索引
init_process_group(backend="nccl")
# [...]
#2 将模型移到分配的GPU上
model = model.to(int(os.environ["LOCAL_RANK"])) # 将模型移动到对应索引的GPU上其他部分就跟标准的分布式训练一样。
使用 torchrun 弹性启动程序进行 PyTorch 的分布式数据并行 (DDP) 多机分布式训练示例，在两个 AWS G4dn.xlarge 实例（NVIDIA T4 GPU）上运行。
这是使用 PyTorch 分布式数据并行（DDP）进行多节点的分布式训练的一个示例，使用 torchrun 弹性启动器在每台都配备 AMD Radeon V520 GPU 的 2 台 AWS G4ad.xlarge 实例上运行。
PyTorch 使用 AMD RCCL 和 NVIDIA NCCL 库时，使用方式相同，无需额外的精力。这是因为它们的 API 类似，得益于AMD 的 HIP 可移植性特性和设备感知构建技术。 若要详细了解 all_reduce 的工作原理并比较未优化的原始 C++ 实现与 NCCL 和 RCCL 的优化，我为此构建了一个实际示例 在这里。
从以CPU为中心的通信转移到GPU优化的集体运算，让分布式深度学习更有效。去除了瓶颈并实现了接近线性的扩展，这些改进措施使得大规模模型和数据集能够用于生产环境。
GPU加速的Kubernetes分布式训练管理数千个GPU，就像Uber部署的五千多个GPU一样，是一项艰巨的挑战。组织必须确保有效的GPU利用率，以避免过度配置或利用率不足的情况。如果没有合适的调度和集群扩展，这些资源可能变得既浪费又低效，闲置时还会浪费电力。
Kubernetes（简称 K8s）是最流行的容器编排平台之一，可以自动处理大规模集群中的资源分配、调度和扩展规模。它通过以下方式高效管理 GPU 资源：
- 通过声明式配置抽象基础设施。
- 集成供应商的驱动程序（例如 NVIDIA、AMD）来暴露 GPU 资源。
- 优化 GPU 资源分配。
- 根据拓扑结构分配资源。
- 自动化维护任务，例如驱动程序更新。
这些功能让 Kubernetes 更适合大规模 AI 和机器学习任务的绝佳选择。
要在 Kubernetes 中启用 GPU 支持，需要安装供应商的驱动程序并部署匹配的设备插件（例如 NVIDIA 或 AMD）。这会公开自定义的 GPU 资源（如 nvidia.com/gpu），让 pod 能够请求，以便使用这些资源。
资源:
限制:
nvidia.com/gpu: 1使用这些注释，可以成功启动分布式训练作业，方法与系列文章第一篇中描述的相同。
GPU 操作Kubernetes 通过其设备插件框架提供了访问专用硬件（如网络接口控制器、Infiniband 和 ROCE 适配器）的功能。但是，要管理这些资源的节点，需要配置多个软件组件，例如驱动程序、容器运行时和库。
GPU操作符由AMD和NVIDIA提供，通过简化管理所有必需组件的自动化过程（例如CUDA或ROCm的设备驱动程序、Kubernetes GPU设备插件、自动节点标记以及资源监视）来简化任务，
手动安装 vs. 通过GPU Operator自动化安装（基于完全容器化的组件：来自NVIDIA的文章）
这些操作符部署了自动化GPU节点配置过程、节点标注和功能识别的组件。它们安装和更新驱动程序，配置遥测，并执行资源发现，以确保每个节点的GPU能力满足计划的工作负载需求。例如，NVIDIA的GPU操作符配置了设备共享功能，使一个GPU能够为多个任务提供服务，为机器学习框架（如PyTorch）提供最佳驱动程序，并集成了支持RDMA的资源来提高数据传输效率。
这两个操作员也提供了可以被工具如Datadog或Dash0等使用的监控和可观测指标，以提供实时资源利用率的洞察，从而实现动态集群监控。
尽管有这些好处，额外的初始化步骤可能会拖慢 pod 的启动时间，延迟可能在分布式操作中累积。
在两个AWS G4dn.xlarge节点（配备NVIDIA T4 GPU）上运行基于GPU的PyTorchJob需要20分钟来启动，安装驱动程序并拉取容器镜像。训练任务耗时5秒。
此外，与外部 webhook 处理程序和插件 CRD 的整合需谨慎，以避免可能的配置错误，同样至关重要。
通过调度数千个高性能GPU，Kubernetes大幅缩短了训练时间——处理PB级数据集的时间从数月缩减到几天。将Kubernetes的调度功能与下一代硬件相结合，简化了机器学习，使得更大规模模型的训练更快，同时通过优化资源使用降低成本。
性能调优与优化尽管有先进的通信库和Kubernetes插件，GPU利用率通常徘徊在60–70%，因资源碎片化、通信开销问题和调度低效所致。 这种利用率低影响了分布式训练的流程，拖慢了模型训练进度并增加了运营成本。
这可以提高GPU利用率，缩短训练时间，并有效利用基础设施。对于公司而言，这意味着更快地将AI产品推向市场，以及在GPU上的更高投资回报。
通过设备共享提升GPU利用率即使团队优化批处理大小和数据加载器以充分利用GPU，完全利用GPU仍然很棘手。有时，跨工作负载（如 pod 或进程）共享单个物理GPU可能更有效。然而，在这种情况下保持隔离并以避免性能下降是关键问题。
GPU并发处理机制（来源：NVIDIA）（来源：_NVIDIA _）
目前，NVIDIA GPU 提供了 高级 GPU 共享功能，包括 CUDA 多进程服务 (MPS)、时间切片和通过 MIG 实现的多实例化。这些功能都可以通过 Kubernetes 设备插件进行配置和支持。
--- # https://github.com/NVIDIA/k8s-device-plugin?tab=readme-ov-file#shared-access-to-gpus
# 时间轮转
version: v1
sharing:
timeSlicing:
resources:
- name: nvidia.com/gpu
replicas: 10
# MPS
version: v1
sharing:
mps:
resources:
- name: nvidia.com/gpu
replicas: 10
---
# MIG https://docs.nvidia.com/datacenter/cloud-native/gpu-operator/latest/gpu-operator-mig.html#gpu-operator-with-mig
resources:
limits:
nvidia.com/mig-1g.10gb: 1AMD GPU可以通过直接SR-IOV或AMD的MxGPU进行设备共享功能，以便在虚拟化分区下实现设备共享。
SR-IOV 可以将一个物理的 PCIe GPU 分割成多个“虚拟功能”（VF），每个 VF 都会作为一个独立且专用的 GPU 实例存在，可以直接分配给 guest 环境，或者说是“直通”给 guest 环境，例如虚拟机或容器环境。
AMD GPU的分区能力通常在数据表中详细说明，例如AMD Instinct™ MI325X 加速器，它支持通过SR-IOV最多八个分区的虚拟化。启用SR-IOV上的VF配置需要特定系统配置，并且可能需要手动配置VF。
AMD K8s 设备插件工具可以将这些 GPU 分区识别为可用设备，让它们可以作为可安排的 Kubernetes 资源。
利用SR-IOV的GPU分区机制:
限制：
- 在使用MIG实例时，NCCL会将每个切片视为单独的设备。跨MIG的通信可能会通过网络进行（甚至在同一GPU上），从而增加延迟时间。
- 使用SR-IOV分区进行GPU共享并不完全是通过软件配置实现的。AMD K8s GPU插件提供的配置灵活性不如NVIDIA操作员。
配置 Kubernetes 工作负载的 GPU 共享，让团队能够根据任务需求灵活分配 GPU。这不仅支持在同一硬件上同时进行轻量推理和密集训练任务，还通过提高 GPU 利用率来降低基础设施成本。
网络、NUMA和拓扑意识提高GPU利用率有助于减少设备层面的低效，但多节点分布式训练面临着不同的挑战：网络通信和硬件拓扑结构带来的额外开销。
使用torchrun弹性启动器在1x G4dn.12xlarge（左，配置有四个NVIDIA T4 GPU）和4x G4dn.xlarge（右，每台配置有一个NVIDIA T4 GPU）上进行多节点分布式PyTorch DDP训练的示例。
如上视频对比所示，当工作负载跨越节点时，使用较慢的25 Gbps TCP传输进行通信，并伴有跨NUMA节点的内存访问争用，会悄然降低性能。
NUMA 对调度进程的优化可以减少内存延迟并提高效率。在 NUMA 系统中，每个处理器都有本地内存，访问速度远快于访问其他处理器的远程内存。例如，如果一个训练进程在一个处理器上运行，但其数据位于远程 NUMA 节点上，那么远程访问造成的额外延迟可能会减慢整体训练进度。
本地资源的访问速度比远程资源快得多。 (来源: Boost)
在 Kubernetes 集群中，异构节点架构增加了挑战的难度，需要将 GPU、CPU 和内存精确对齐到 NUMA 域，以降低延迟。
拓扑管理器（Topology Manager）可以通过设置 --topology-manager-policy=single-numa-node 和 --cpu-manager-policy=static 选项来强制实现 NUMA 对齐。此外，还可以在 Pod 中使用 numactl 来将 CPU 和 GPU 绑定到 NUMA 节点：
command: ["numactl", "--cpunodebind=0", "--membind=0", "python", "train.py"] 现代调度程序，如 Volcano，提供了 NUMA 感知的调度能力。
volcano/docs/design/numa-aware.md at master · volcano-sh/volcano一个云原生批量处理系统（CNCF 旗下的项目）。欢迎贡献代码。
点击这里查看numa-aware.md
限制条件：
- 严格的NUMA策略可能导致资源碎片化，从而使pod调度失败，因为资源分散在多个NUMA区域中。这意味着虽然一个节点可能拥有足够的总资源，但这些资源分散在多个NUMA区域中——每个区域通常由一个独立的CPU插槽及其专用内存构成，而不是集中在一个区域中。因此，需要从单个NUMA域获取所有资源的pod可能会无法获取所需资源而卡在待处理状态。
- 集群节点间混合的NUMA拓扑结构会增加亲和力规则的复杂性，因为不一致的NUMA配置（例如节点数量不同或CPU和内存布局不匹配）使得将相关工作负载调度到单个NUMA节点上变得困难。结果，工作负载可能分布在多个NUMA节点上（即跨越多个节点），这会导致远程内存访问，增加延迟并降低性能。
通过将GPU与相关的CPU和内存放置在同一NUMA节点内，团队能够减少跨域通信流量和PCIe瓶颈，从而使集体操作的通信变得更顺畅。
减少CPU和GPU瓶颈CPU与GPU之间缓慢的数据传输，或是低效的预处理，会阻塞训练流程，让GPU处于闲置状态。
优化数据加载器以在固定在CPU上的内存中预先分配数据可以解决此问题。这实现了异步、非阻塞的GPU传输。在PyTorch中，你可以通过设置 pin_memory=True 参数来实现这一点。
这是另一种解决此问题的方法：使用RDMA在GPU之间传输数据，从而在集体操作期间绕过CPU进行数据传输。
通过RDMA，数据可以直接在设备之间传输，无需CPU的介入或处理（来源：Dell博客）（源链接：Dell博客）
RDMA 需要兼容硬件，包括支持 RDMA 的网卡（例如，Mellanox ConnectX-6/7 用于 InfiniBand/RoCE）和具备 GPUDirect RDMA 支持的 GPU（如 NVIDIA 的 A100 和 H100，或 AMD Instinct MI 系列）。在 Kubernetes 中，RDMA 通过使用 设备插件（如 [k8s-rdma-device-plugin](https://github.com/Mellanox/k8s-rdma-shared-dev-plugin) 插件）和 内核模块（如 NVIDIA 的 nvidia-peermem 或 AMD 的 rocm-core 配合 libfabric）来启用。
AWS EKS 支持 RDMA over AWS EFA，但仅限于特定实例类型（不支持 g4ad），性能提升非常显著：
[AWS EKS 支持 RDMA over AWS EFA](https://docs.aws.amazon.com/eks/latest/userguide/node-efa.html) 但仅限于[特定实例类型](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/efa.html#efa-instance-types)（不支持 g4ad），性能提升非常显著。
AWS EFA性能表现（据 AWS 博客）（来源：AWS 博客）
采用DMA和RDMA驱动的数据传输策略可以释放显著的效率提升。锁定内存分配减少了延迟，使GPU能够持续处理数据，而无需等待CPU到GPU的数据传输。
快速存取低效的存储系统会减慢特征存储和数据仓库中数据检索速度，当数百或数千个GPU访问存储在特征存储或数据仓库系统中的数据时，这会限制系统的可扩展性。
多模态工作负载，比如vLLM训练，需要将大型模型快速加载到GPU上。张量并行操作使得数千个设备同时访问存储在对象存储中的训练数据和元数据的共享部分，而频繁的检查点则需要临时存储能够处理持续的覆盖操作。
来自Weka、Vast Data、DDN或Dell ECS等供应商的面向AI的存储产品，采用了软硬件结合的RDMA技术，实现了数据直接从存储传输到GPU，跳过CPU处理。
RDMA优化的存储系统绕过CPU来提高吞吐
使用高性能存储系统可以提供高IOPS和超低延迟，支持数千个并发任务。
集体基准测试和调优网络架构、GPU架构和工作负载模式不同，需要调整集体操作，如all_reduce和all_gather。例如，调整chunk size参数定义了每次减少操作处理的数据量，而设置ring buffer count则决定了用于重叠计算和通信的缓冲区的数量。
像NCCL和RCCL这样的框架提供了优化插件来自动优化算法和协议，使之更高效，而MPI提供了参数调整的指导。不过，这些工具需要通过反复进行基准测试来确保其有效性。
无论采用何种方法，通过使用现有的测试来评估设置——例如用于MPI集合的OSU基准测试，或专门为NCCL和RCCL设计的测试套件——可以确保性能评估的准确性：
# 在多节点环境中对RCCL进行测试
mpirun --allow-run-as-root -np 2 -H 10.10.15.200,10.10.12.86 /rccl-tests/build/all_reduce_perf -b 8 -e 128M -f 2 -g 1
警告：永久地将'[10.10.12.86]:2222' (ED25519) 添加到已知主机列表中。
警告：永久地将'[10.10.15.200]:2222' (ED25519) 添加到已知主机列表中。
# nThread 1 nGpus 1 minBytes 8 maxBytes 134217728 step: 2(factor) warmup iters: 5 iters: 20 agg iters: 1 validation: 1 graph: 0
#
rccl-tests 版本开发分支：448c4c7
# 使用的设备如下
# Rank 0 Pid 18349 在 ip-10-10-15-200 设备 0 [0000:00:1e.0] 上的AMD Radeon Pro V520
# nThread 1 nGpus 1 minBytes 8 maxBytes 134217728 step: 2(factor) warmup iters: 5 iters: 20 agg iters: 1 validation: 1 graph: 0
#
rccl-tests 版本开发分支：448c4c7
# 使用的设备如下
# Rank 0 Pid 15345 在 ip-10-10-12-86 设备 0 [0000:00:1e.0] 上的AMD Radeon Pro V520
#
# out-of-place in-place
# size count type redop root time algbw busbw #wrong time algbw busbw #wrong
# (B) (elements) (us) (GB/s) (GB/s) (us) (GB/s) (GB/s)
#
# out-of-place in-place
# size count type redop root time algbw busbw #wrong time algbw busbw #wrong
# (B) (elements) (us) (GB/s) (GB/s) (us) (GB/s) (GB/s)
8 2 float sum -1 4.66 0.00 0.00 0 0.17 0.05 0.00 0
16 4 float sum -1 4.22 0.00 0.00 0 0.17 0.09 0.00 0
32 8 float sum -1 4.25 0.01 0.00 0 0.17 0.19 0.00 0
64 16 float sum -1 4.26 0.02 0.00 0 0.17 0.38 0.00 0
128 32 float sum -1 4.42 0.03 0.00 0 0.17 0.75 0.00 0
256 64 float sum -1 4.50 0.06 0.00 0 0.17 1.49 0.00 0
512 128 float sum -1 4.39 0.12 0.00 0 0.18 2.78 0.00 0
1024 256 float sum -1 5.55 0.18 0.00 0 0.17 5.95 0.00 0
2048 512 float sum -1 4.46 0.46 0.00 0 0.17 11.94 0.00 0
8 2 float sum -1 4.58 0.00 0.00 0 0.30 0.03 0.00 0
4096 1024 float sum -1 4.41 0.93 0.00 0 0.17 23.88 0.00 0
16 4 float sum -1 4.21 0.00 0.00 0 0.17 0.09 0.00 0
8192 2048 float sum -1 4.76 1.72 0.00 0 0.17 47.63 0.00 0
32 8 float sum -1 4.33 0.01 0.00 0 0.17 0.19 0.00 0
16384 4096 float sum -1 4.45 3.69 0.00 0 0.17 95.53 0.00 0
64 16 float sum -1 4.30 0.01 0.00 0 0.17 0.37 0.00 0
32768 8192 float sum -1 4.52 7.25 0.00 0 0.17 192.75 0.00 0
128 32 float sum -1 4.75 0.03 0.00 0 0.17 0.75 0.00 0
65536 16384 float sum -1 4.53 14.48 0.00 0 0.17 379.92 0.00 0
256 64 float sum -1 6.17 0.04 0.00 0 0.17 1.49 0.00 0
131072 32768 float sum -1 5.51 23.77 0.00 0 0.17 768.75 0.00 0
512 128 float sum -1 4.41 0.12 0.00 0 0.17 2.99 0.00 0
1024 256 float sum -1 4.48 0.23 0.00 0 0.17 5.95 0.00 0
262144 65536 float sum -1 5.58 47.01 0.00 0 0.17 1533.01 0.00 0
2048 512 float sum -1 4.39 0.47 0.00 0 0.21 9.66 0.00 0
4096 1024 float sum -1 4.73 0.87 0.00 0 0.17 23.88 0.00 0
524288 131072 float sum -1 6.96 75.36 0.00 0 0.17 3066.01 0.00 0
8192 2048 float sum -1 4.72 1.74 0.00 0 0.17 47.91 0.00 0
16384 4096 float sum -1 4.41 3.71 0.00 0 0.17 95.81 0.00 0
1048576 262144 float sum -1 9.66 108.57 0.00 0 0.17 6096.37 0.00 0
32768 8192 float sum -1 4.54 7.21 0.00 0 0.17 192.75 0.00 0
65536 16384 float sum -1 4.51 14.52 0.00 0 0.17 383.25 0.00 0
2097152 524288 float sum -1 14.89 140.84 0.00 0 0.17 12122.27 0.00 0
131072 32768 float sum -1 4.74 27.65 0.00 0 0.17 768.75 0.00 0
4194304 1048576 float sum -1 24.85 168.81 0.00 0 0.17 24456.58 0.00 0
262144 65536 float sum -1 5.65 46.36 0.00 0 0.17 1528.54 0.00 0
524288 131072 float sum -1 6.90 75.97 0.00 0 0.17 3057.07 0.00 0
8388608 2097152 float sum -1 44.42 188.86 0.00 0 0.17 48349.33 0.00 0
1048576 262144 float sum -1 9.64 108.76 0.00 0 0.17 6114.15 0.00 0
2097152 524288 float sum -1 14.93 140.43 0.00 0 0.17 12264.05 0.00 0
16777216 4194304 float sum -1 84.99 197.40 0.00 0 0.21 78398.21 0.00 0
4194304 1048576 float sum -1 24.93 168.21 0.00 0 0.17 24672.38 0.00 0
8388608 2097152 float sum -1 141.6 59.22 0.00 0 0.17 48913.17 0.00 0
33554432 8388608 float sum -1 167.0 200.91 0.00 0 0.17 195652.66 0.00 0
16777216 4194304 float sum -1 84.86 197.71 0.00 0 0.17 78398.21 0.00 0
33554432 8388608 float sum -1 167.6 200.18 0.00 0 0.17 195652.66 0.00 0
67108864 16777216 float sum -1 333.2 201.39 0.00 0 0.17 392334.78 0.00 0
67108864 16777216 float sum -1 334.8 200.42 0.00 0 0.17 390167.81 0.00 0
134217728 33554432 float sum -1 672.0 199.73 0.00 0 0.17 780335.63 0.00 0
134217728 33554432 float sum -1 678.5 197.81 0.00 0 0.17 778073.79 0.00 0
# 带星号的错误表示已超出最大阈值。
# 超出界限的值：0，表示正常。
# 平均总线带宽：0 GB/s
#
# 带星号的错误表示已超出最大阈值。
# 超出界限的值：0，表示正常。
# 平均总线带宽：0 GB/s
#系统地调整集体操作可以使分布式训练工作流中底层硬件的使用最大化。通过迭代测试配置，例如缓冲区的大小、协议的选择或线程的数量，团队可以通过这种方式找到适合其基础设施的最佳配置。
将这些优化集成到基于Kubernetes的管道和自动化工具中，定期重新调优，可以保持AI基础设施高效应对不断变化的工作负载。这确保了高GPU利用率和大规模模型训练的成本效益。
简介管理包含数千个GPU的集群会遇到诸如网络拥堵、资源分配效率低下和通信开销等问题，这可能会导致性能瓶颈和运营成本的增加。如果没有有效的调度，组织可能会面临硬件使用效率低下、训练速度变慢和能源消耗增加的风险。
提高GPU效率的一些策略包括：
- 优化的多GPU通信：NCCL（NVIDIA）和RCCL（AMD）通过直接的GPU到网络通信减少了延迟，避免了CPU成为瓶颈，并提高了吞吐量。
- Kubernetes的可扩展性：Kubernetes自动管理GPU资源，确保在多台机器上高效调度和扩展，从而使大规模数据集的训练更迅速。
- 性能优化：GPU共享（MPS、时间分割、MIG）、NUMA感知调度和RDMA数据传输最大化GPU的使用率并减少闲置时间。
- 集体通信基准测试：通过迭代基准测试调整集体通信接口（如NCCL、RCCL、MPI），以确保最佳性能并利用硬件能力实现更快的训练。
战略性分布式GPU管理使组织能够高效利用计算资源，促进创新，降低成本开支，并在竞争市场中取得领先地位。
你可以通过我的领英联系我