随着大模型时代的到来AI 基础设施AI Infra正在经历深刻的变革。面对日益复杂的计算需求传统上与单一计算范式深度耦合的调度系统已难以应对全局性挑战。本文结合开源社区的演进趋势与工业界的超大规模落地实践深入探讨 Ray 的技术定位与核心设计逻辑并阐述它如何与 Kubernetes以下简称 K8s进行协同设计co-design共同构建大模型时代 AI Workload 调度的通用范式。01 大模型时代 AI 基础设施的技术栈演进要理解这一全新的调度范式首先需要审视当前大模型基础设施的技术栈现状。借助蚂蚁开源技术委员会绘制的 AI Infra 开源生态全景图[1]我们可以全面了解当下 AI Infra 领域的主要开源项目。从这张全景图中可以提炼出一条典型的 AI Infra 技术栈Ray PyTorch vLLM。值得一提的是这三个项目目前均隶属于 PyTorch 基金会其中 Ray 于 2025 年 PyTorch 大会上正式作为托管项目加入。在此之上再叠加工业界事实标准的部署与调度底座K8s便构成了K8s Ray PyTorch vLLM的黄金组合。这套技术栈贯穿大模型生命周期的全链路涵盖数据处理、预训练、后训练、在线推理与 Agent 等场景。为更直观地理解这套技术栈的运作方式我们以强化学习RLHF为例。当前主流的 RL 训练框架普遍采用训推分离架构训练端依托 PyTorch 生态如 Megatron、DeepSpeed提供高性能训练能力。推理端以 vLLM 作为核心推理后端Backend。编排与调度由 Ray 串联全局承担训推流程的编排以及角色间的复杂通信。底层基座K8s 作为应用部署的事实标准提供底层物理资源支撑。目前业界 90% 以上的 RL 训练框架均构建于这套 K8s Ray PyTorch vLLM 黄金组合之上。关于该组合的深度探讨可参见四个项目的技术负责人在 Ray Summit 2025 上的对谈[2]本文不再赘述。这套技术栈也已经过开源社区的真实检验。从 2021—2025 年的开源活跃度以 Commit 数为指标来看作为 AI 应用时代最关键的推理引擎vLLM 在过去一年贡献了超过 8000 个 Commit活跃度极高Kubernetes 始终保持极高且稳定的活跃度与其云原生部署事实标准的地位相称而 Ray 作为通用计算引擎活跃度已明显超越 Spark、Flink 等传统大数据计算引擎。让 Ray 在近两年迎来爆发的正是它在两类核心场景中的不可替代性多模态数据处理与后训练/强化学习。下图梳理了基于 Ray 构建的 AI Infra 开源项目可以看出 Ray 在数据处理与后训练/强化学习这两个方向上的生态最为活跃。此外我们也汇总了 Ray 在国内主要企业的落地情况如今国内头部厂商包括 DeepSeek、月之暗面等在多模态数据处理上几乎全面采用 Ray90% 以上的 RL 训练框架基于 Ray 构建主流云厂商均已提供 Ray 托管服务阿里等企业也开始探索基于 Ray 构建 Agent Sandbox。在非 AI 场景方面蚂蚁集团早在 2017—2018 年便已将 Ray 应用于图计算与隐私计算。接下来我们将从 AI Workload 调度的视角深入解析大模型时代的 AI Infra 为何选择 Ray以及 Ray 究竟解决了哪些传统计算引擎难以应对的调度痛点。02 基于 Ray 的 AI Workload 调度我们首先通过两个典型场景归纳当下 AI Workload 提出的调度需求。2.1 多模态数据处理下图展示了多模态数据处理的典型 Pipeline系统需要持续读取、处理并输出大批量多模态数据。整条 Pipeline 由多个 Stage 串联组成其中既包含 CPU 密集型算子如抽帧、格式转换也包含强依赖 GPU 的算子如 OCR、语音识别、大语言模型推理。所有算子需要在统一的资源池内参与调度。这带来了三大挑战异构调度CPU 与 GPU 算子需要被高效地匹配到对应的异构节点动态分配需根据实时负载动态调整各 Stage 的资源量与并发度以打破吞吐瓶颈高容错由于链路长、耗时久单点故障如 OOM、GPU Error、Spot Instance 回收几乎不可避免。因此容错粒度必须下探到 Stage、Pod 乃至进程级避免单点故障拖垮整条 Pipeline。2.2 强化学习RLHF以 RLHF 中一次典型的 PPO Training Step 为例用户的 Prompt 经 Actor 推理生成 Response 后需并发分发给 Reference、Reward 与 Critic 进行打分评估再经 Advantage 计算回传给 Actor 与 Critic 完成参数更新。这本质上是一个多异构角色的协同调度问题。它不仅涉及多种角色其中 Actor 还可能进一步拆分为训练与推理两部分而且各角色依赖的运行时完全不同例如推理需拉起 vLLM/SGLang训练需加载 FSDP/Megatron并发设置与资源需求也各不相同。更复杂的是任务流转并非简单的线性 DAG而是需要在多角色之间以复杂的多播multicast形式传递。面对后训练/RLHF 中异构、多角色协同的调度需求预训练阶段长期沿用的计算范式变得难以匹配。主流预训练框架如 FSDP、Megatron通常采用Multi-Controller / SPMDSingle Program, Multiple Data范式要求每个计算单元运行同构进程并依赖同步 Barrier 与集合通信。这种范式存在三方面局限灵活性差难以表达异构角色、容错率低单点故障会导致整个通信组崩溃、缺少一个能够以全局视角统一编排复杂任务流的中心角色。为突破这一限制大模型时代的强化学习框架 如 veRL[3]、SkyRL[4]纷纷转向Single-Controller / MPMDMultiple Program, Multiple Data范式引入一个中心 DriverSingle-Controller来统一编排多个异构角色。Driver 能够以全局视角组织跨角色的复杂任务流各异构角色内部仍可保留 SPMD 架构以获取局部高性能。借助中心 Driver异构角色之间得以松耦合容错也能在角色粒度上独立完成。2.3 AI Workload 调度需求小结基于上述两个典型场景我们将大模型时代 AI Workload 的调度需求归纳为四点异构资源将异构算子/角色高效地调度到异构节点上动态分配根据实时负载为每个算子/角色动态分配计算资源避免出现局部吞吐瓶颈高容错局部故障不影响全局任务出错的计算单元支持自动重新调度并恢复状态原生支持 Single-Controller由 Single-Controller 统一编排跨角色/跨算子的复杂任务流2.4 Ray 核心 API 设计本节通过 Ray 的核心 API展示上述四项调度需求如何在 Ray 中被一一满足。下面的 Python 代码片段简要模拟了 RLHF 训推分离场景import ray def main(): # 主函数中声明当前进程为中心 Driver ray.init() # 定义一个 Rollout 角色 (类该角色的每个实例需要 # 1. 分配 2 个 CPU 和 1 个 GPU # 2. 出错后无限次自动重启 ray.remote(num_cpus2, num_gpus1, max_restarts-1) class RolloutWorker: def __init__(self): # 如果当前实例为重启状态非首次创建 if ray.get_runtime_context().was_current_actor_reconstructed: # 自定义状态恢复行为 self._recover_state() def generate(self, prompt): return Hi there # 定义一个 Trainer 角色类该角色的每个实例需要分配 2 个 GPU ray.remote(num_gpus2) class Trainer: def fit(self, experience): return 0 # 创建 2 个 RolloutWorker 远程实例组成 rollout worker group rollout_worker_group [RolloutWorker.remote() for _ in range(2)] # 创建 1 个 Trainer 远程实例 trainer Trainer.remote() # 开始 RL 训练流程 while True: for rollout_worker in rollout_worker_group: # 远程调用 (异步) RolloutWorker 实例的 generate 方法 response rollout_worker.generate.remote(Hello) # 将 RolloutWorker 实例的 response 派发给 Trainer 实例 ret trainer.fit.remote(response) # 动态增加远程实例提升 rollout 并发度 rollout_worker_group.append(RolloutWorker.remote())在上述代码中我们首先通过ray.init将当前进程声明为中心 DriverSingle-Controller。然后通过ray.remote装饰器定义异构角色类定义并声明每个角色实例的资源与容错需求。对每个角色我们都可以通过remote()接口创建任意数量的远程实例进程并按需分组管理。在训练循环中可以调用任意远程实例的方法并将上游返回值ObjectRef派发给指定下游实例从而编排任意形式的任务流。运行过程中也可以动态增减角色实例以调节各角色的并发度。本质上Ray 作为分布式计算引擎其调度的核心对象是进程级计算单元。在进程粒度上Ray 同时实现了异构资源调度、动态分配与高容错能力。中心 DriverSingle-Controller则可充分利用这些调度能力灵活编排任务流。2.5 分布式计算引擎对比调度能力总结完 AI Workload 的调度需求与 Ray 的对应支持之后我们进一步将 Ray 与其他主流分布式计算引擎Spark、Flink、PyTorch在调度能力上进行对比SparkFlinkPyTorchRay计算范式BSP批处理流式 DataflowSPMD无范式通用分布式异构资源粗粒度Stage 内同构粗粒度Slot 切分不支持细粒度进程级动态分配粗粒度AQEStage 间生效支持不支持静态通信组细粒度进程级容错粗粒度RDD Lineage 重算粗粒度Checkpoint 回滚粗粒度整组重启细粒度进程级Single-Controller支持支持不支持支持从计算范式来看Spark 绑定了 BSP 批处理Flink 绑定了流式 DataflowPyTorch 绑定了 SPMD而 Ray 本身是无范式的——基于其提供的进程级计算单元用户可以根据业务形态自由构建任意计算范式。反过来看正因为 Spark、Flink、PyTorch 与固定计算范式深度耦合它们在异构资源调度、动态分配与容错能力方面均缺乏足够细粒度的支持难以全面覆盖大模型时代 AI Workload 的多样化需求。综合来看Ray 凭借进程级调度的灵活性成为复杂 AI Workload 调度的最优解。2.6 Ray 架构与调度实现在本章最后我们简要介绍一下 Ray 的整体架构与调度实现。Ray 集群架构如上图所示。其中Head 节点上运行 Global Control StoreGCS负责集群元数据管理与节点状态同步每个 Worker 节点上运行 Raylet负责调度决策与本地进程管理。当用户的中心 Driver 创建角色实例时调度会经历以下流程实际略有差异此处仅作示意调度请求首先发送至本地 Raylet由其做出调度决策选择目标节点调度请求被转发至目标节点的 Raylet目标节点 Raylet 根据本地资源状态决定是否接受请求若接受则在本地创建 Worker 进程并运行角色实例调度完成后Driver 即可通过 gRPC或 RDMA直接调用远程实例的方法。目前Raylet 内置了多种调度策略包括 Round-Robin 调度、按堆叠水位调度、Node/Label 亲和性调度、Gang Scheduling 以及 Data Locality 调度用户可以根据业务场景的调度需求自由调配。对更多技术细节感兴趣的读者可以参考 Ray 官方文档[5]。03 K8s Ray 的协同调度范式目前Ray 的主流生产部署方式都构建在 K8s 之上。在近几届 Ray Summit 全球峰会上AWS、Microsoft、Google 等主流云厂商也相继披露了各自基于 K8s Ray 的部署方案。为什么必须引入 K8sK8s 作为企业级基础设施能够高效、统一地管理大规模物理资源池并提供容器化部署、服务发现、存储编排以及成熟的监控、运维与权限体系。借助 K8s 的成熟生态Ray 才能快速在生产环境中实现稳定、规模化的落地。K8s Ray职责分工当采用 K8s 结合 Ray 的部署方式时两者的职责分工如下所示K8sRay定位物理资源调度与管理应用层调度与编排资源管理对象大规模物理节点资源Ray Cluster 内的资源生命周期管理容器/PodWorker 进程调度对象Pod → 物理节点Worker 进程 → Ray Node (Pod)API 形态YAML 声明式Python 编程式从定位上来说K8s 是物理资源调度与管理而 Ray 在其之上充当应用层调度与编排。从调度上来说K8s 负责将 Pod 调度到物理节点上整个流程涉及 API Server、Scheduler、Kubelet 等多个组件以及状态同步/持久化操作而 Ray 则以二层调度的方式负责将 Worker 进程调度到 PodRay Node上调度策略更加贴合上层任务的需求整体流程更加轻量。从 API 设计上来说K8s 是 YAML 声明式的更面向集群管理/运维人员而 Ray 提供编程式接口更适合分布式应用的研发人员。K8s Ray协同调度将 K8s 与 Ray 结合做协同调度时整体流程可以概括为K8s 负责将资源从统一资源池中分配给 Ray而 Ray 负责将分配到的资源以更细粒度分配给上层任务。为了将 Ray 无缝接入 K8s 生态Ray 开源社区提供了 KubeRay Operator。用户提交自定义的RayClusterCR 后由 KubeRay Operator 负责持续调谐创建并维护对应的 Ray 集群。Ray 集群包含 Head 节点和任意数量、异构规格的 Worker 节点并支持运行时的自动扩缩容。Ray 集群内的资源则进一步由 Ray Scheduler 以轻量、细粒度的方式分配给上层任务。如上图所示通过 K8s → KubeRay → Ray Scheduler 这条自底向上、由粗到细的协同调度链路资源可以被稳定、高效、灵活地分配给 AI 任务。04 K8s Ray 在腾讯的落地实践从开源社区的视角来看K8s → KubeRay → Ray 这套协同调度方案已经相当成熟。然而当我们将它真正落地到腾讯内部尤其是面对企业级的超大规模集群时现实远比想象复杂。在腾讯 TEG 内部Ray 平台的整体架构涉及多个层级。最底层是峰峦 K8s 云原生架构作为统一算力平台管理海量异构算力资源并提供联邦调度、智能调度等能力。中间层涵盖完整的 Ray 生态从 Ray 调度内核到数据处理、训练、在线服务三大高阶框架能力再到 DAGFlow 离在线一体化的服务封装。上层是数据平台与机器学习平台承接各业务线的具体需求。首先我们要面对的复杂性来自底层峰峦 K8s 云原生架构。这套架构有几个关键特点K8s 物理集群不直接向上暴露由联邦层进行统一管理生产环境存在上百个 K8s 物理集群以 CPU 算力与 GPU 算力维度分离WeData 数据平台与太极 AI 平台分别维护两套独立的 K8s 基础设施这些特点给 Ray 的落地带来了显著挑战Ray 提供的是异构融合计算能力需要 K8s 云原生层供给CPU GPU混合资源而这些资源往往分散在不同的 K8s 物理集群中但社区版 KubeRay 仅支持 RayCluster 在单一 K8s 物理集群内部署与调度。4.1 核心挑战云原生联邦架构的演进针对底层 K8s 架构现状我们首要的目标是支持 RayCluster 跨 K8s 集群部署。在技术选型阶段我们对以下三种方案进行了深入评估二层调度方案在各 K8s 集群中预申请大量 Pod 常驻并在这些 Pod 之上构建一层自定义调度器来调度 RayCluster。该方案引入了额外的调度层使整个系统从K8s Ray的两层调度演变为K8s 中间层 Ray的三层调度显著增加了系统复杂度与调优难度。平台层 Standalone 组网方案在平台侧直接调度多个 K8s 集群的 Deployment 形成多个 Pod 组并在每个 Pod 内部启动 Ray 进程指定其中一个节点为 Head以 Standalone 方式完成组网。该方案虽然没有引入额外的调度层但放弃了 KubeRay 的能力需要在平台层重新构建大量替代逻辑。KubeRay 联邦方案保留原生 KubeRay并在其之上扩展支持跨集群联邦。我们希望尽可能地兼容并复用开源社区的已有能力因此最终选择了方案 3——扩展 KubeRay 以支持集群联邦。在落地过程中KubeRay 联邦架构经历了两个演进阶段阶段一Virtual KubeletVK架构为实现跨集群组网我们构建了第一版基于 Virtual KubeletVK的架构在 CPU 集群上保留完整的 KubeRay 能力并通过 VK 将太极集群的 GPU 资源抽象为虚拟 Kubelet。创建 GPU Pod 的实际链路是KubeRay 调用 VKVK 再调用 ModelService 创建太极服务最终由太极服务拉起真正的 Pod。该方案在 TEG 内部成功落地但在规模化推广时暴露出明显瓶颈架构依赖倒置底层 VK 反向依赖上层服务调用链路冗长——每创建一个 GPU Pod 都要触发一次太极服务创建。在后期的业务落地中当 RayCluster 节点数超过 100 时太极链路便会承受较大压力难以满足生产需求。阶段二KubeRay 联邦架构考虑到 VK 架构的瓶颈我们进一步推进了更合理的 KubeRay 联邦架构。该架构在多个 K8s 物理集群中并发部署 KubeRay Workload并通过配置约束仅由其中一个 Workload 启动 GCSGlobal Control Store其余 Workload 的节点均作为 Worker 节点组加入同一 Ray 集群。在此基础上我们还实现了联邦集群的 Autoscaling 能力借助联邦机制完成全局资源弹性。4.2 跨层协同设计跨层弹性调度解决了基础的跨集群组网问题后我们开始直面业务在规模化推广中遇到的真实痛点。在多模态数据处理场景中我们发现业务方往往难以根据产能要求直接评估出所需的 CPU/GPU 规格与数量并且在任务运行前也无法准确预知瓶颈所在例如华南 CPU 与华北 GPU 跨地域协同导致的 IO 带宽瓶颈或 GPU 节点上 CPU 预处理资源不足导致 GPU 利用率低下使得运行时效率难以保障。为此我们设计了跨层弹性调度机制业务方无需再纠结资源规格只需提交算子与预期产能由 Ray 在运行时动态完成资源匹配。整体流程如下用户算子和预期产能通过业务平台提交后由智能调度器输出推荐配置并下发至 K8sKubeRay Operator 通过跨 K8s 联邦调度创建出初始 Ray 集群。任务运行过程中系统会进行三级自动调优动态扩缩容根据 Ray 集群资源水位与任务负载情况实时调整异构 Ray 节点Pod的数量避免长时间资源空转或数据堆积。Pod 重调度对出现隐患例如 GPU ECC Error、磁盘空间不足等的 Ray 节点触发重新调度。任务重调度若上述两级调整仍无法达到预期产能则对整个任务进行重新调度由 K8s 层重新做智能资源池决策后任务继续执行。每一级自动调优都需要 Ray 任务调度层与 K8s 资源调度层协同处理。通过这一系列闭环反馈系统可自动将任务调整至最佳运行状态。4.3 跨层协同设计跨层自动化容灾除了资源配置稳定性是业务的另一大需求。这里我们以对故障高度敏感的强化学习场景为例。在现有的强化学习业务中RL 框架层与 K8s 算力层之间缺乏故障协同处理主要表现为两类问题当 K8s 算力层检测并屏蔽故障卡后RL 框架无法及时感知往往要等到训练任务失败、并经人工确认后才能介入处理。RL 训练任务因故障卡失败后无法自动通知 K8s 算力层做调度屏蔽导致任务再次拉起时可能再次命中同一张故障卡反复失败。为此我们打造了跨层自动化容灾方案覆盖故障感知、故障标记与故障处理三个环节。全方位故障感知在 Ray Worker 节点内由 Dashboard Agent 周期性检测关键资源指标如磁盘、GPU 健康度等在 Head 节点内由 Train Monitor 基于训练任务日志感知异常在 K8s 算力层由定期巡检发现故障卡。统一故障标记任意组件感知到故障后都可通过 Ray Dashboard 提供的开放接口对故障节点进行统一标记。故障节点替换与任务续训当训练任务无法推进而触发重启时所有被标记的故障节点会被自动替换并在 K8s 层完成故障卡屏蔽新任务拉起时将自动避开所有已知故障节点。通过这一闭环机制故障从被动等待人工介入转变为自动感知—自动隔离—自动恢复显著提升了大规模 RL 训练任务的稳定性。05 未来展望通过上述跨层协同调度的实践我们打通了 K8s 与 Ray沉淀出一套行之有效的 AI Workload 调度通用范式。面向未来我们将在以下三个方向持续深耕更原生的 Ray 联邦架构当前的 KubeRay 联邦方案仍需要接入层感知在不同场景间部署仍需迁移成本未来希望将这部分能力收敛进 K8s Ray 技术栈内部进一步提升易用性与普适性。更通用的分布式底座面向多模态数据处理、预训练、强化学习、在线推理、Agent 应用等场景构建更通用的分布式底座与平台强化调度、通信、存储等通用分布式能力。更统一的 Agentic RL Infra在训练 推理统一到 Ray 计算范式的基础上进一步覆盖 Agentic RL 场景中更广泛的调度统一问题例如 Agent 与 Sandbox 运行环境的统一编排。当 K8s 遇见 Ray大模型时代的 AI Workload 调度正在开启新的篇章。期待更多开发者加入我们共同见证并参与这场 AI 基础设施的变革。References[1] Open Source LLM Development Landscape, https://github.com/antgroup/agentic-ai-landscape[2] Ray Summit 2025 Keynote: AI OSS Stack Panel with vLLM PyTorch Kubernetes, https://youtu.be/c0tjHzKRVJM?simSSUIiWEAhXWY9uo[3] verl: Volcano Engine Reinforcement Learning for LLMs, https://github.com/volcengine/verl[4] SkyRL: A Modular Full-stack RL Library for LLMs, https://github.com/NovaSky-AI/SkyRL[5] Ray Official Docs, https://docs.ray.io/en/latest/index.html