AWS 提出 SageMaker HyperPod 管理與治理四層模型

AWS 的新指南聚焦於多個機器學習團隊共用 Amazon SageMaker HyperPod 時的管理方式。HyperPod 為模型訓練與微調提供大型加速運算資源；團隊可將既有叢集連接至 Amazon SageMaker Unified Studio 專案，讓成員從專案工作環境啟動工作負載、查看叢集與任務資訊，或開啟 JupyterLab。叢集本身仍透過 Amazon SageMaker AI 介面與 API 管理。

文章將治理拆成組織、專案、叢集和工作負載四層，並提醒專案是協作邊界，不是強效的執行階段安全邊界。將叢集連接至專案，不會取代 IAM、EKS 或 Slurm 控制；AWS 因此建議依各自邊界設定權限，並避免單靠專案成員資格授予資源存取權。

在容量治理方面，AWS 建議由指定的容量帳戶集中管理 HyperPod 叢集、排程器與稀缺加速器資源，再以核准的跨帳戶存取方式服務使用者。對 EKS 叢集，建議按租戶區分命名空間，並搭配 RBAC、服務帳戶、EKS Pod Identity 角色、預設拒絕的網路政策及租戶專屬儲存與 KMS 權限；對 Slurm 叢集，則建議運用階層式帳戶與關聯、QoS、優先權、公平分享政策及分割區。

AWS 也建議透過 IAM 角色和資源政策管理資料服務及相關資源的存取，而非把專案成員資格當成唯一依據。這篇指南延伸了 AWS 先前針對 HyperPod 任務治理的建議：早期文章著重運算配額、任務優先順序與閒置運算分配，新文則把管理框架擴展到組織、專案、叢集及工作負載之間的責任與控制分工。