CoreWeave 支持 NVIDIA Collective Communication Library (NCCL),以支持多 GPU 和多节点神经网络训练。NCCL 支撑了绝大多数分布式训练框架,例如 https://github.com/microsoft/DeepSpeed%E3%80%81PyTorch Distributed 和 Horovod。
CoreWeave 的所有 NVIDIA GPU 均支持通过以太网和 InfiniBand 运行 NCCL。此外,专门的 GB200 NVL72 集群采用 NVIDIA Quantum-X800 InfiniBand 网络构建,并通过 NVIDIA SHARP 实现网络内集合操作,以提供尽可能高的分布式训练性能。
本仓库包含可直接使用或作为分布式训练应用模板的 Dockerfile。这些 Dockerfile 包含以下组件:
CoreWeave 还https://github.com/coreweave/nccl-tests/pkgs/container/nccl-tests%EF%BC%8C%E5%8F%AF%E7%94%A8%E4%BD%9C%E6%82%A8%E8%87%AA%E5%B7%B1%E9%95%9C%E5%83%8F%E7%9A%84%E5%9F%BA%E7%A1%80%E3%80%82%E4%BB%A5%E4%B8%8B%E9%95%9C%E5%83%8F%E5%8C%85%E5%90%AB NCCL v2.30.4-1、HPC-X v2.26 和 cuDNN v9.20.0.48-1。每个镜像都是多架构的,可用于 linux/amd64 和 linux/arm64 容器。支持最高达 Blackwell(10.0 和 12.0)的计算能力。
| 镜像标签 | CUDA 版本 |
|---|---|
| ghcr.io/coreweave/nccl-tests:13.2.1-devel-ubuntu24.04-nccl2.30.4-1-111c25a | 13.2.1 |
| ghcr.io/coreweave/nccl-tests:13.1.1-devel-ubuntu24.04-nccl2.30.4-1-111c25a | 13.1.1 |
| ghcr.io/coreweave/nccl-tests:13.0.2-devel-ubuntu24.04-nccl2.30.4-1-111c25a | 13.0.2 |
| ghcr.io/coreweave/nccl-tests:12.9.1-devel-ubuntu24.04-nccl2.30.4-1-111c25a | 12.9.1 |
| 镜像标签 | CUDA 版本 |
|---|---|
| ghcr.io/coreweave/nccl-tests:13.2.1-devel-ubuntu22.04-nccl2.30.4-1-111c25a | 13.2.1 |
| ghcr.io/coreweave/nccl-tests:13.1.1-devel-ubuntu22.04-nccl2.30.4-1-111c25a | 13.1.1 |
| ghcr.io/coreweave/nccl-tests:13.0.2-devel-ubuntu22.04-nccl2.30.4-1-111c25a | 13.0.2 |
| ghcr.io/coreweave/nccl-tests:12.9.1-devel-ubuntu22.04-nccl2.30.4-1-111c25a | 12.9.1 |
| ghcr.io/coreweave/nccl-tests:12.8.1-devel-ubuntu22.04-nccl2.30.4-1-111c25a | 12.8.1 |
| ghcr.io/coreweave/nccl-tests:12.6.3-devel-ubuntu22.04-nccl2.30.4-1-c25a | 12.6.3 |
本仓库中有许多示例任务,展示了如何使用以下工作负载管理器运行分布式 NCCL 测试:
CoreWeave 提供 https://github.com/kubeflow/mpi-operator 的托管实例,允许以容器原生方式运行 MPI 任务。用户无需安装,只需在您的命名空间中执行 MPIJob 清单即可。
示例清单位于 mpi-operator/ 目录中。您可以在其中找到以下 64 GPU(8 节点)运行的示例:
要启动 NCCL 测试,请使用 kubectl 将示例清单应用到您的命名空间:
$ kubectl apply -f nccl-test-distributed-h100-64-sharp-mpijob.yaml
$ kubectl get pods
nccl-test-64-launcher-lnnrw 1/1 Running 0 14s
nccl-test-64-worker-0 1/1 Running 0 16s
nccl-test-64-worker-1 1/1 Running 0 16s
nccl-test-64-worker-10 1/1 Running 0 15s
...
$ kubectl logs -f -l=training.kubeflow.org/job-role=launcher
# nThread 1 nGpus 1 minBytes 4 maxBytes 2147483648 step: 2(factor) warmup iters: 50 iters: 50 validation: 1
#
...
# 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)
536870912 134217728 float sum -1 2984.6 179.88 356.01 0 2979.7 180.18 356.60 0
1073741824 268435456 float sum -1 5808.0 184.87 365.90 0 5882.2 182.54 361.28 0
2147483648 536870912 float sum -1 11163 192.37 380.73 0 11203 191.70 379.40 0
4294967296 1073741824 float sum -1 22181 193.63 383.23 0 22570 190.29 376.62 0
8589934592 2147483648 float sum -1 43980 195.31 386.56 0 44094 194.81 385.56 0
# Out of bounds values : 0 OK
# Avg bus bandwidth : 373.187
#
在运行新的测试实例前,请使用以下命令删除旧实例:
kubectl delete mpijob 或 kubectl delete mpijob --all。请注意,在启动同名新作业前,必须等待先前作业的所有 Pod 完成终止,这一点非常重要。
CoreWeave 提供了一种在我们的托管 Kubernetes 集群上部署 slurm 集群的方法,使用名为 sunk 的工具。
slurm/ 目录中提供了示例 SBATCH 脚本。您可以在其中找到以下 64 GPU(8 节点)运行的示例:
要在 slurm 集群上提交作业,请先将脚本复制到登录节点。
脚本会设置各种参数,但提交作业时请确保指定所需的分区。
要启动 NCCL 测试,请通过 sbatch 提交作业:
export PARTITION=
sbatch --partition="$PARTITION" nccl-test-distributed-h100-64.slurm
您还可以轻松覆盖测试使用的节点数量。以下命令将使用 4 个节点而非 8 个:
sbatch --partition="$PARTITION" -N 4 nccl-test-distributed-h100-64.slurm
日志将写入 ./nccl_test_jobID.out。
[!NOTE] 不使用 enroot 的作业依赖于
/opt/nccl-tests路径下安装的nccl-tests,这在每个sunk集群的计算节点上都是成立的。登录节点很可能没有此目录。
https://github.com/nvidia/enroot 是一款支持运行非特权容器的工具。结合 slurm 容器插件 https://github.com/NVIDIA/pyxis%EF%BC%8C%E6%82%A8%E5%8F%AF%E4%BB%A5%E5%9C%A8 docker 镜像内运行 slurm 作业。
https://github.com/NVIDIA/pyxis 支持其他参数,但在这些示例脚本中,它通过 srun 的 --container-image 参数使用。这避免了在所有计算节点上安装脚本及其依赖项的需求。
[!NOTE] 您可以在
sbatch中指定容器镜像,但之后所有命令都将在容器内运行。因此,我们建议仅在后续的srun调用中指定容器镜像。
这两种工作负载管理器都可用于运行基于 DeepSpeed 的分布式训练作业,方式与运行 NCCL 测试作业类似。它们都会为您创建 MPI 主机文件,并且 DeepSpeed 可以像手动设置主机文件时一样直接作为命令运行。
在某些用例中,可以启用 GDRCopy 来改善 CPU 到 GPU 的内存通信。NCCL 通过隐藏环境变量 NCCL_GDRCOPY_ENABLE 支持 GDRCopy。在我们的测试中,常规 NCCL allreduce 工作负载的性能提升未被观测到。我们不建议在未进行充分基准测试以确保性能提升的情况下为 NCCL 启用 GDRCopy。GDRCopy 文档中指出,在某些情况下性能会下降而非提升。
以下结果显示了在 CoreWeave 集群上运行示例作业的性能。
[!WARNING] 性能可能因 NCCL 版本、环境变量变化甚至每次运行而有所不同。比较运行结果时请记住这一点。
以下运行使用了 NCCL 2.26.2。
# Rank 71 Group 0 Pid 14840 on slurm-gb200-207-171 device 3 [0x01] NVIDIA Graphics Device
#
# 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)
536870912 134217728 float sum -1 1806.7 297.16 586.06 0 1835.9 292.43 576.74 0
1073741824 268435456 float sum -1 3108.8 345.38 681.17 0 2924.7 367.13 724.06 0
2147483648 536870912 float sum -1 5589.1 384.22 757.78 0 5474.6 392.26 773.62 0
4294967296 1073741824 float sum -1 10094 425.49 839.16 0 10141 423.54 835.32 0
8589934592 2147483648 float sum -1 20299 423.16 834.57 0 20006 429.37 846.82 0
# Out of bounds values : 0 OK
# Avg bus bandwidth : 745.53
# Rank 143 Group 0 Pid 14840 on slurm-gb200-207-171 device 3 [0x01] NVIDIA Graphics Device
#
# 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)
536870912 134217728 float sum -1 2156.8 248.92 493.94 0 2093.7 256.42 508.83 0
1073741824 268435456 float sum -1 3574.4 300.40 596.10 0 3565.5 301.15 597.59 0
2147483648 536870912 float sum -1 6264.0 342.83 680.30 0 6258.4 343.14 680.91 0
4294967296 1073741824 float sum -1 11469 374.47 743.09 0 11435 375.61 745.36 0
8589934592 2147483648 float sum -1 21493 399.65 793.06 0 21525 399.06 791.88 0
17179869184 4294967296 float sum -1 42067 408.40 810.41 0 41557 413.41 820.36 0
# Out of bounds values : 0 OK
# Avg bus bandwidth : 688.487
# Rank 1439 Group 0 Pid 21082 on slurm-gb200-218-073 device 3 [0x01] NVIDIA GB200
# 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)
536870912 134217728 float sum -1 7108.4 75.53 150.95 0 7145.8 75.13 150.16 0
1073741824 268435456 float sum -1 9805.7 109.50 218.85 0 9819.6 109.35 218.54 0
2147483648 536870912 float sum -1 14980 143.36 286.52 0 15087 142.34 284.49 0
4294967296 1073741824 float sum -1 24782 173.31 346.38 0 24975 171.97 343.71 0
8589934592 2147483648 float sum -1 45004 190.87 381.48 0 44930 191.19 382.11 0
17179869184 4294967296 float sum -1 84625 203.01 405.74 0 84828 202.53 404.77 0
# Out of bounds values : 0 OK
# Avg bus bandwidth : 297.808
探索更多轩辕镜像的使用方法,找到最适合您系统的配置方式
通过 Docker 登录认证访问私有仓库
无需登录使用专属域名
Kubernetes 集群配置 Containerd
K3s 轻量级 Kubernetes 镜像加速
VS Code Dev Containers 配置
Podman 容器引擎配置
HPC 科学计算容器配置
ghcr、Quay、nvcr 等镜像仓库
Harbor Proxy Repository 对接专属域名
Portainer Registries 加速拉取
Nexus3 Docker Proxy 内网缓存
需要其他帮助?请查看我们的 常见问题Docker 镜像访问常见问题解答 或 提交工单
docker search 限制
站内搜不到镜像
离线 save/load
插件要用 plugin install
WSL 拉取慢
安全与 digest
新手拉取配置
镜像合规机制
不支持 push
manifest unknown
no matching manifest(架构)
invalid tar header(解压)
TLS 证书失败
DNS 超时
域名连通性排查
410 Gone 排查
402 与流量用尽
401 认证失败
429 限流
D-Bus 凭证提示
413 与超大单层
来自真实用户的反馈,见证轩辕镜像的优质服务