問題喺個 image，唔喺模型
想喺多機上面行 PyTorch 訓練，卡住你嘅通常唔係模型代碼，而係個 container image。每個 container 都要同一套 CUDA runtime、對應嘅 PyTorch 編譯版本、NCCL（NVIDIA 集合通訊庫）、EFA（Elastic Fabric Adapter）用户層庫、AWS OFI NCCL 插件，再加一個集群管理員認可嘅 Ray 版本。呢啲嘢每換一層就要 rebuild 一次 image，成個工程同你要訓練嘅模型冇任何關係。
AWS 而家出咗一個預製方案：Ray Train Deep Learning Container（DLC）。由 AWS 組裝、測試、發佈到 Amazon ECR Public，並持續補補丁。
個樣本做乜
文章示範一個可重複嘅流程：用 DLC 原樣，喺兩部 g6.12xlarge 實例（共八塊 NVIDIA L4 GPU）上面，用 PyTorch FSDP（Fully Sharded Data Parallel，完全分片數據並行）微調 Qwen2.5-1.5B。訓練代碼只有一個函數，集群配置只係一個 RayCluster manifest 加一個變數檔案，全程冇 build 任何 image。
邊個負責開 pod
Ray 集群有兩個角色：head node 負責協調、追蹤集群狀態、運行 dashboard 同 job server；worker nodes 提供 GPU 同運行訓練。喺 Kubernetes 上面，每個角色對應一個 pod。Kubernetes 本身唔認識 Ray cluster 呢個概念，所以需要一個 operator 去建立 pod、啟動正確角色嘅 Ray、指向 head、以及故障時替換 pod。呢個角色由 KubeRay（開源 Kubernetes operator）負責：你喺一個 manifest 寫明 head group 同 worker group，佢就建立並維護成個集群。
資料圖片：Pixabay
同一個 tagged image 同時運行 head 同 worker，唔管係喺 Amazon EKS 定係你自己喺 EC2 上面開。你加嘅只係配置：用邊部實例、每個 pod 幾多 GPU、NCCL 用邊個網絡傳輸、要加邊啲 Python package。全部喺 image 外面設定。
最麻煩嘅 networking 一層
原文話明，networking 一層係「最唔想自己執」嘅部分。NCCL 同 EFA 驅動之間有 mismatch 嘅時候唔會報錯——NCCL 會默默跌返 TCP sockets，個 job 照行，但速度變成一小部分。DLC 入面呢啲庫係一齊 build、一齊測試嘅；AWS 每個 release 都必須通過多節點 EFA 同多節點 KubeRay 訓練測試先可以出貨，而呢條路徑正正就係呢個樣本用嘅。
另外，image 係公開嘅，節點拉取唔使認證，中途冇 build 冇 push。
阿調搞兩下
呢篇本質上係 AWS 嘅產品功能教學，唔係獨立評測。DLC 由 AWS 本身組裝同維護，測試標準亦由 AWS 定，呢個係廠商自評。對於需要喺 EKS 上面做分佈式訓練嘅團隊，呢個方案確實省卻咗 image 組裝嘅重複勞動，但「即開即用」嘅條件係你要用 AWS 嘅棧。如果你用唔同雲、唔同網絡棧，或者唔想用 KubeRay，呢篇同你關係唔大。
另外要講明：呢個係功能解説，本站冇做獨立實測。Qwen2.5-1.5B 微調嘅實際收斂速度、GPU 利用率、EFA 對 TCP 嘅速度提升幅度，原文冇提供數字，我哋亦冇測過。想行呢條路嘅團隊，最好用自己的模型同自己的數據集跑一次先。
阿調｜深度調教
