博客 宣布成立 Ray 加速器特别兴趣小组(SIG) 作者: Zhe Zhang、Mengjin Yan、Ryan O’Leary、Richard Liaw2026年11月2日暂无评论 /row

精选项目

今天,我们宣布成立 Ray 硬件加速器特别兴趣小组(SIG)。

十多年前,Ray 在加州大学伯克利分校诞生时,计算领域的格局与今天大不相同。当时,“分布式计算”指的是运行 Apache Hadoop 和 Apache Spark 等框架的 CPU 集群。GPU 才刚刚从图形和科学计算领域进入机器学习。

如今, 加速计算 已成为人工智能开发与部署的核心,加速器及其能力也变得更加专用化和多样化。例如:

  • NVIDIA RTX PRO 6000 Blackwell 服务器版 GPU 支持涵盖 AI 训练、推理、图形和视频的灵活工作负载
  • NVIDIA HGX B200 及全栈平台提供大幅提升的内存容量以支持更大的模型,而 NVIDIA GB200 NVL72 连接 72 块 NVIDIA Blackwell GPU,用于通信密集型的大规模训练和推理。
  • AMD MI355X 同样为大型模型提供可观的显存容量
  • Google Ironwood TPU 面向超大规模 AI 工作负载
  • NVIDIA Groq 3 LPU 专注于低延迟推理。

Ray 社区一直在积极跟进这一转变。如今,Ray 支持十余种硬件加速器,从 NVIDIA 和 AMD GPU 到 TPU、Trainium、Gaudi 等。我们认为,现在正是关键时机,在这一基础上开展更宏大、更系统化的全 Ray 范围工作,让加速器易于使用、在大规模下高效、并在生产环境中可靠。

加速器特别兴趣小组旨在汇聚硬件厂商、Ray 贡献者和应用开发者,共同制定并推进一份共享的、厂商中立的 Ray 加速器支持路线图。这一公开兴趣小组将负责确保 Ray 工作负载在加速器碎片化、专用化的时代持续演进。

我们的初步路线图聚焦 3 个核心领域: 开发与测试基础设施、硬件感知能力,以及网络/传输,详见以下各节。

开发与测试基础设施

可靠的加速器支持需要可靠地访问硬件,以进行开发、测试和调试。维护者和贡献者需要在其改动所影响的设备上验证变更、复现故障,并在问题到达用户之前发现回归。随着智能体软件工程加速开发,可靠的测试与验证变得更加重要:人类贡献者和编码智能体都需要来自真实硬件和代表性工作负载的可复现反馈。我们希望让这成为为 Ray 做贡献的常规环节,并为硬件厂商和云提供商提供清晰的路径来贡献资源和专业知识。

我们的初步优先事项是:

  • 共享硬件访问. 建立一套有文档记录的流程,将云和厂商托管的加速器纳入 Ray 的开发与测试基础设施,包括为贡献者提供复现和调试故障的访问权限。
  • 可复现的开发与测试环境. 提供持续维护的环境,明确驱动、运行时和依赖版本,使贡献者能够复现 CI 结果,并在不同提供商之间一致地验证变更。
  • 更广泛的 CI 覆盖. 扩展现有流水线,为拉取请求增加有针对性的检查,并扩大夜间测试和发布测试。覆盖范围应包括分布式工作负载、故障恢复和性能回归,以及基本的设备功能。
  • 可持续的运维与归属. 明确维护环境、调查故障以及确保集成在各版本间持续可用的职责。让测试结果和基础设施健康状况可见,并管理容量和成本,使基础设施能够随参与度增长。

硬件感知调度

要让应用充分发挥加速器的性能,Ray 首先必须了解每个节点拥有什么硬件以及其结构如何。随着加速器生态的演进,加速器节点不再只是相同设备的数量。工作负载性能取决于设备之间的互连性、设备与 CPU 和网卡的关系,以及节点如何分组为机架和 TPU 切片等更大的域。

我们的目标是让 Ray 跨厂商和平台准确、一致地掌握这一结构。有了这一图景,Ray 的调度器就能将任务和 actor 放置到正确的硬件上,用户也能看到其集群由什么构成以及如何连接。

我们的初步优先事项是:

  • 通用硬件接口。 定义厂商中立的接口,用于标记硬件、表示其架构并描述其规格,使应用和库能够面向能力而非编写厂商特定代码。这包括以一致的方式识别加速器 SKU,包括新发布的产品。它还包括为添加新加速器的厂商提供有文档记录的扩展点和检查清单。
  • 强化的发现机制。 加强 Ray 的发现机制,明确每种加速器集成的归属,并以上一节所述的 CI 覆盖作为支撑。发现机制应捕获硬件的拓扑和架构,而不仅仅是设备的类型和数量。
  • 平台与云集成。 与云提供商和部署平台合作,使发现机制能够反映集群运行所在位置的底层结构。其中一些信息,例如节点属于哪个机架或切片,只能从平台获取,而非来自节点本身。
  • 硬件可见性。 在 Ray 仪表盘上提供查看集群中加速器及其连接方式的方法,并展示加速器指标。这使用户能够确认 Ray 正确识别了他们的硬件,并了解其工作被放置在何处。它也为贡献者提供了一种验证新集成的方式。
  • 清晰的用户指南。 记录 Ray 如何发现和表示硬件,以及如何在放置工作时使用这些信息。良好的指南既有助于应用开发者,也有助于越来越多为他们编写 Ray 代码的编码智能体。

网络与 I/O 传输

在加速器之间移动数据往往与在加速器本身上运行计算同样重要。现代 AI 工作负载,例如大规模强化学习,需要跨设备和节点将大型模型权重张量从训练工作进程移动到推理工作进程。过去,Ray 的对象存储是为 CPU 数据构建的,这意味着加速器张量必须先复制到主机内存、序列化,并通过标准主机网络发送,才能到达另一个设备。

为了避免这一瓶颈, Ray Direct Transport (RDT) 被引入,使 actor 能够通过 Ray 传递张量的引用,同时在设备之间直接传输实际数据,并使用 UCX 和 RDMA 等高性能传输方式。我们的目标是让高速、直接的数据传输在不同加速器、框架和网络结构上可靠工作,同时保持 Ray 熟悉的编程模型。

我们的首要任务是:

  • 广泛的传输集成. 在 RDT 中支持更广泛的加速器、框架和互连,使 Ray 能够在 Actor 之间选择最快的路径,无论是通过片内 TPU ICI、纵向扩展的 NVIDIA NVLink,还是横向扩展的 GPUDirect RDMA。
  • 传输生命周期与恢复. 确保每种硬件传输在真实设备上妥善处理初始化、拆除和错误恢复,使 RDT 在强化学习和解耦式服务等动态工作负载中,随着 actor 的扩缩容或重启而可靠运行。
  • 经过验证的配方与可观测性. 使云和硬件提供商能够发布经过验证的部署配置、对高吞吐量工作负载进行基准测试,并呈现清晰的诊断信息和传输指标。

范围

核心调度与放置逻辑仍保留在 Ray Core 中,而 SIG Accelerator 负责定义 Ray 中加速器的插件接口、CI 测试和成熟度分级。硬件厂商和云提供商贡献并维护各自的设备插件、传输层以及新 SKU 的零日支持,而框架作者和机器学习从业者则让我们的路线图立足于真实工作负载需求。

参与其中

无论你是在构建新的加速器集成、在 Ray 上运行大规模训练或推理,还是提供云和 CI 基础设施,我们都邀请你参与其中!

  • 在以下平台加入讨论: Ray Slack.
  • 参加我们的社区会议,讨论提案、审阅路线图优先级并分享工作负载反馈。
  • 查看与加速器相关的开放 议题 以及在 Github 上提交 PR 并向上游贡献。
/row /row