AWS Ray Train DLC：分布式 PyTorch 训练通常卡在容器，不是模型代码
AWS 的 Ray Train 预构建容器把 CUDA、PyTorch、NCCL、EFA 用户态库和 AWS OFI NCCL 插件打包为一个已测试的整体，使多节点 FSDP 训练只需配置环境变量和资源请求即可运行，无需构建任何镜像。文章给出了在两个 g6.12xlarge 实例上用八张 NVIDIA L4 GPU 微调 Qwen2.5-1.5B 的完整可复现方法。
做分布式 PyTorch 训练的人通常把精力花在模型代码上，但真正阻止训练从单机扩展到多节点集群的往往是容器。每个容器需要同一套 CUDA 运行时、针对该 CUDA 编译的 PyTorch 构建、NCCL（NVIDIA 集合通信库）、EFA（Elastic Fabric Adapter）用户态库、把 NCCL 连到 EFA 的 AWS OFI NCCL 插件，以及集群运营方认可的 Ray 版本。构建这个镜像并在其中任何一块移动时重新构建，本身就是一项工程，和你要训练的模型毫无关系。
AWS 把这套东西做成了 Ray Train Deep Learning Container（DLC），在 Amazon ECR Public 上发布并持续打补丁。文章用这个镜像原样运行了一个示例：在两个 g6.12xlarge 实例上，用八张 NVIDIA L4 GPU 以 PyTorch FSDP 微调 Qwen2.5-1.5B。训练代码是一个函数，集群是一个 RayCluster manifest 加一个变量文件，全程没有构建任何镜像。
网络栈那一行是多数团队最不想自己维护的部分。这里的关键风险不是报错，而是静默降级：如果 EFA 用户态库和 NCCL 版本不匹配，NCCL 会回退到 TCP sockets，任务照常跑完，但速度只有正常的一小部分。DLC 把这些库一起构建、一起测试，AWS 每次发布都跑多节点 EFA 和多节点 KubeRay 训练测试，正是这个示例使用的路径。
镜像之外的一切差异都通过配置解决，而不是重新构建。集群布局由 KubeRay manifest 描述：一个 CPU 系统节点跑 KubeRay operator 和 Ray head（不申请 GPU），两个 g6.12xlarge 各跑一个申请四张 GPU 和一个 EFA 接口的 worker pod。网络传输由四个环境变量决定：FI_PROVIDER 设为 efa 让 libfabric 只走 EFA，NCCL_NET_PLUGIN 设为 ofi 加载 AWS OFI 插件，NCCL_SOCKET_IFNAME 指向 pod 的 eth0，NCCL_DEBUG 设为 INFO 以便验证实际选择的传输。这些变量写在 manifest 里，行为在一个文件中可见，不依赖镜像默认值。
Ray Train 在容器内负责启动器的工作。多节点 PyTorch 通常意味着在每台主机上为每张 GPU 启动一个进程，并给每个进程分配 rank、world size 和 rendezvous 地址。用 Ray Train 只需把训练循环写成一个函数传给 TorchTrainer，Ray 自动在集群有 GPU 的地方各启动一个 worker，组建 torch.distributed 进程组，在每个 worker 上运行该函数。示例要求 FSDP 策略，把模型权重、梯度和优化器状态分片到全部八张 GPU 上。Qwen2.5-1.5B 在 bfloat16 下这四项张量约占 12 GB，八分片后每张 L4 承载约 1.5 GB。
代价是通信：FSDP 在每步中先 gather 各层权重再使用，之后 reduce-scatter 梯度，整个模型在每步都要跨 rank 传输。跨实例的这部分流量由 DLC 自带的 EFA 栈承载。文章末尾给出一个归因结果：EFA 路径通过四个环境变量启用后，在代码不变的情况下吞吐量相比 TCP 翻倍。这是 AWS 自己的演示结论，示例使用随机 token 批次，判定标准是 FSDP 集合通信是否确实跨过了两个节点、任务是否完成，而非训练收敛质量。
整套方案的价值在于把容器构建从训练流程中移除。镜像是公开的，节点无需凭据即可拉取；入口脚本在启动时检查宿主机 NVIDIA 驱动，如果比镜像的 CUDA 旧就自动启用捆绑的 CUDA forward-compatibility 库；同一个 tag 既跑 head 也跑 worker，没有角色区分。需要额外 Python 包时通过 Ray 的 runtime_env 在提交时安装，镜像不变。需要换模型、调步数、改序列长度或 batch size，只改变量文件中的参数。切换 GPU 实例族时只需确认新族支持 EFA 且在设备插件允许列表内，代码和镜像都不动。