PyTorch 宣布成立 Ray 加速器特别兴趣小组（SIG）

今天，我们宣布成立 Ray 硬件加速器特别兴趣小组（SIG）。

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

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

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 工作负载在加速器碎片化、专用化的时代持续演进。

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

开发与测试基础设施

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

我们的初步优先事项是：

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

硬件感知调度

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

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

我们的初始优先级是：

通用硬件接口。定义厂商中立的接口，用于标记硬件、表示其架构并描述其规格，使应用和库能够面向能力而非编写厂商特定的代码。这包括一种一致的方式来识别加速器 SKU，包括在发布时识别新 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 的零日支持，而框架作者和 ML 从业者则根据真实工作负载需求为我们的路线图提供依据。

参与其中

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

在 Ray Slack 上加入讨论。
参加我们的社区会议，讨论提案、审阅路线图优先级并分享工作负载反馈。
查看 Github 上与加速器相关的开放 issue 和 PR，并向上游贡献。

文章 Announcing the Special Interest Group (SIG) for Ray on Accelerators 首次发表于 PyTorch。