SageMaker HyperPod 加入受管 Ray：訓練、推論與故障恢復共用 KubeRay 介面

AWS 在 SageMaker HyperPod 的 EKS 路徑加入受管 Ray 能力，把原本需要自行撰寫 Kubernetes manifest、建立映像、設定 port-forward，以及配置 Prometheus／Grafana 的工作收進 SageMaker Studio。使用者可從介面建立 RayCluster、查看 Ray Dashboard 和 Amazon Managed Grafana、提交分散式工作，亦可設定掛起工作偵測。底層仍由開源 KubeRay 管理 RayCluster、RayJob 與 RayService，因此既有 Ray Train、Ray Serve 和標準提交 API 原則上毋須改寫。

開發流程亦有實質變化。JupyterLab 或 Code Editor 空間可作為不配置計算資源的 worker 接入既有叢集，程式以 `ray.init(address="auto")` 連線；依賴可透過 `runtime_env` 注入，減少每次變更套件便重建容器。遠端工作則使用 `toolkit-for-ray-on-sagemaker-ai`，把 SageMaker 叢集名稱解析及 EKS IAM 憑證接到 Ray CLI。Dashboard URL 為短效、經 IAM 驗證且綁定建立者的端點，比公開 Ray head service 或長期 port-forward 更適合多人環境。

在長時間 AI 工作負載方面，HyperPod 節點健康監控與自動復原會配合 Ray 的容錯機制；訓練可使用分層 checkpoint，先把高頻狀態寫入叢集 CPU 記憶體，再週期性持久化。Ray Serve 還可從 JumpStart 載入權重，並把長上下文推論的 KV cache 卸載至分層儲存。不過這不是一鍵啟用：前置條件包括 EKS HyperPod、Spaces、Observability、KubeRay 與 Ray Endpoint Operator。AWS 未提供相對自管 Ray 的啟動時間、故障恢復或單位成本基準；工程團隊仍應測量 checkpoint 佔用的主記憶體、端點權限邊界及 KV 卸載對尾延遲的影響。