Azure Kubernetes Service (AKS) 团队发布了在 AKS 上运行 Anyscale 托管 Ray 服务的规模化部署指南。该指南重点解决三大核心问题：GPU 容量限制、机器学习存储分散以及凭证过期问题。
本文是对此前关于开源 KubeRay on AKS 概述内容的延伸。文章重点介绍了 Anyscale 优化后的运行时环境（原 RayTurbo），该运行时提供智能弹性扩缩容、增强的监控能力以及容错训练特性，所有功能均基于开源 Ray 框架构建。
Ray 是一款面向 Python 的原生分布式计算框架，可将 AI 与机器学习工作负载从单台笔记本电脑扩展至数千节点的集群。Anyscale 托管平台通过生产级能力对 Ray 进行了增强。这份新的指南展示了微软与 Anyscale 在优化 Azure 集成方面的合作成果。
GPU 资源紧缺是大规模机器学习场景中最突出的运维挑战之一。NVIDIA GPU 这类高需求加速器在 Azure 各区域中常出现配额与可用资源紧张的问题，可能导致集群部署与作业调度出现延迟。
微软提出的解决方案采用多集群、多区域架构。通过将 Ray 集群分布在不同 Azure 区域的多个 AKS 实例中，团队可以：聚合超出单区域限制的 GPU 配额，在故障或容量不足时自动重新路由工作负载，并借助 Azure Arc 与 AKS 将计算池扩展至本地机房或其他云平台。
Anyscale 控制台可在单一视图中展示所有已注册集群。Anyscale Workspaces 可根据可用容量手动或自动管理工作负载调度。你可以通过创建 cloud_resource.yaml 清单文件，再使用 Anyscale CLI 应用该文件来添加新区域。这种配置优先的方式让多区域扩展更易于管理。
机器学习运营中的一个常见问题是在管道各阶段之间传输训练数据、模型检查点与相关工件——包括从预训练到微调，再到推理的全流程。该指南通过 Azure BlobFuse2 解决这一问题，它可将 Azure Blob 存储挂载到 Ray 的 Pod 中作为兼容 POSIX 的文件系统使用。
从 Ray 的视角来看，挂载点仅相当于一个本地目录。任务和 Actor 通过标准文件 I/O 读取数据集、写入检查点，BlobFuse2 会将数据持久化到 Azure Blob 存储中，从而实现数据在不同 Pod 和节点池之间共享。本地缓存可避免大规模训练过程中出现 GPU 等待停滞，同时由于数据与计算解耦，Ray 集群可自由扩缩容而不会丢失数据。
设置时，在创建集群时启用 Blob CSI 驱动程序，然后定义使用工作负载身份进行认证的 StorageClass，最后创建具备 ReadWriteMany 访问权限的 PersistentVolumeClaim。这允许位于不同节点的多个 Ray 工作器同时访问共享数据。该方案在为基础设施层带来 Azure 原生存储的持久性与扩展性的同时也保证了 Ray 代码的可移植性。
另一个重要问题是身份验证的可靠性。此前 Anyscale 与 Azure 集成使用的是每 30 天过期的 CLI 令牌或 API 密钥，这需要手动轮换，存在服务中断的风险。
新方案采用 Microsoft Entra 服务主体与 AKS 工作负载身份，可自动颁发短期令牌。Anyscale Kubernetes Operator Pod 使用用户分配的托管身份，向 Entra ID 请求 Anyscale 服务主体的访问令牌。Azure 会透明处理令牌刷新，集群中无需存储长期凭证，也无需手动轮换。
作者表示，这在多集群环境中尤为重要——在这类场景下，跨多个集群手动管理凭证会显著增加运维负担。工作负载身份模型为 Azure 资源访问提供细粒度的 RBAC 权限控制，并可通过 Azure 活动日志自动生成完整的审计追踪记录。
Anyscale on AKS 集成目前处于私有预览阶段。希望申请访问权限的团队可联系微软客户团队，或在 AKS GitHub 仓库提交申请，并提供 Ray 工作负载与目标区域的相关详情。你可以在 GitHub 的 Azure-Samples/aks-anyscale 仓库中查看基于 DeepSpeed 和 LLaMA-Factory 的微调示例配置与工作负载，其中还包含大语言模型推理端点。
微软并非唯一押注这一方案的厂商。AWS 在 2024 年 Ray 峰会上宣布与 Anyscale 合作，将 EKS 集群接入 RayTurbo 运行时，并通过结合 NVIDIA GPU 与 AWS 自研的 Trainium、Inferentia 加速器来提升硬件层面的灵活性。此外，SageMaker HyperPod 现已可作为需要节点级弹性的长期训练任务的部署目标。谷歌云则在开源贡献方面处于领先地位。
GKE 团队与 Anyscale 工程师合作，将基于标签的调度功能合并到 Ray v2.49 中。他们还构建了 ray.util.tpu 层，以减少多芯片 TPU 环境中的资源碎片。此外，他们为全新的 GB200 支持实例实现了动态资源分配能力。
三大云厂商均采用了相同的托管 Ray Operator，并各自集成了自身的基础设施。这表明行业更倾向于使用 Kubernetes 搭配 Ray 运行 AI 工作负载。如今，竞争焦点已不再是运行时本身，而是哪家云厂商能最优化周边基础设施，简化使用流程。
【声明：本文由 InfoQ 翻译，未经许可禁止转载。】
查看英文原文：https://www.infoq.com/news/2026/03/ray-aks-ai-microsoft/
