Data+AI标配：Ray的2024年度总结_

TLDR

Ray Summit 2024已经过去一个多月（国内的两场Meetup包括Ray Connect和Ray Forward也已经在国内落幕），我终于有时间翻完了所有的视频，在此做一下总结。去年我也曾在社区分享过Ray Summit 2023总结性的文章，感兴趣的同学可以回顾下。作为Ray社区每年最重要活动，Ray Summit信息量巨大，本文仅从Ray开发者和用户的角度梳理大家关心的干货，需要展开了解的请大家自行搜索相应的视频。

Ray Summit 2024核心要点

Who uses Ray

首先仍然是新用户最关心的一个问题，谁在用Ray？去年我人肉统计过所有在Summit上分享use case的企业，今年我们看到在keynotes中ansyscale官方汇总了一个更全面的图，如下：

Ray的企业用户（from @anyscale）

近两年我们看到，Ray在国内外大厂、大模型创业公司、硬件厂商等行业已经实现了广泛的应用，时至今日Ray的用户已经不用再担心Ray的普及度，其应用案例已经数不胜数。

从上图中我们可以发现一些新面孔，如Apple、Reddit、ebay等。记得去年在Ray Summit 2023现场曾经与Apple数据平台团队有过短暂的交流，当时他们还在对Ray做一些调研，然后今年就看到了他们Serverless Ray架构的分享。无独有偶，Ray在ebay落地前也曾与我进行过比较深入的交流，也就是今年的事情，Ray已经在ebay构建了完善平台体系。从以上两个案例可以看出，Ray在企业从0到1的落地是比较丝滑的，Ray在易用性方面正逐渐完善。

另外值得注意的是，越来越多数据方向的公司在集成Ray，比如databricks、Alluxio、LanceDB等。今年4月份，databricks在blog中宣布Ray 在databricks已经达到General Availability状态，这也预示着databricks正在通过集成Ray补充平台在Data + AI方向的计算能力。

Statistics

关于统计数据方面，今年主要呈现了两个点：Ray在今年达到了每月100万clusters的启动，以及5年内超过1000的contributors。首先对于百万clusters的启动，解读起来并不是那么容易。一方面anyscale的统计一定是不准确的，因为Ray在企业内部的部署都是私有化环境，anyscale很难统计到；另一方面Ray的clusters有大有小，小到1个节点大到8000个节点（今年宣布已经达到的单集群上限），单纯统计clusters的启动并不能反映真实的使用情况。再说contributors数量，这个数据对于做开源的朋友来说还是比较敏感的。个人认为contributors比stars更有说服力，毕竟是实实在在参与项目开发的，比单独点一个star门槛高很多。1000 contributors可以说是大部分活跃开源项目的一个门槛，Ray在今年实现了这一里程碑。

另一组数据是在一年内，Ray社区的PRs数量1100+，issues数量3000+，Slack messages数量71k，这些数据就不做解读了，大家自行品味。

Why Ray

接下来讨论另外一个高频问题，为什么用Ray。你是否曾经在公司使用Ray过程中，被老板问到这个问题？我想一定会。在我多年的Ray开发、使用和布道中常常会被问到该问题。一般来说，我会从五个角度来阐述：“通用分布式”、“融合计算”、“资源调度”、“研发体验”和“AI生态化”。今天我不会展开自己的观点，我们主要看下Summit上大家都怎么说。以下是PPT中截取的相关内容：

我们总结一些关键词：“Unified”、“Scalability”、“heterogenous CPU/GPU”、“python native”、”Dynamic“、”Model composition“、”Platform Agnostic“、“Ecosystem”、“vllm”...

Announcements

Ray & Anyscale发布概览

下面是汇总下本次Ray Summit的发布内容，主要分为开源Ray和闭源Anyscale两部分。

Ray

Ray本次Announcements包括三个方向：Compiled Graphs、Ray Data和Stability。

首先是Ray Core今年最大的feature：Compiled Graphs。这个特性对Ray Core的改动非常大，经过半年多的迭代才形成现在的alpha版本。Compiled Graphs之前的名字叫做aDAGs（accelerated DAGs），开发这个特性的原因有一部分是来源于Google在2022年发布的论文Pathways。Pathways是AI大神Jeff Dean团队研发的下一代AI编排与调度系统，论文中曾经提到Ray可以作为这套系统的分布式底座（由于Ray具备single controller的设计以及通用的分布式能力）。但当时论文中提到Ray还有一些功能无法满足pathways的需求，比如Ray Objects无法做到GPU to GPU传输，因此就有了Compiled Graphs。

关于Compiled Graphs的出现，我们从数据流计算模型的角度去分析会更加合理。Ray最初是为强化学习设计，Ray Core提供的一个主要的能力是动态数据流，或者说动态DAG。有了动态数量流之后，Ray可以支持更多的计算范式，但同时也带来一个问题，底层关于计算图的性能优化不好实现，这限制了Ray在高性能计算方向的优化上限。Compiled Graphs的出现，就是在不改变Ray Core基础API形态的前提下，支持静态数据流，进而实现底层的性能优化，如GPU to GPU直传、Memory复用等。下图是优化后的效果：

第二，宣布Ray Data达到General Availability状态。从目前的发展状态来看，Ray Data已经成为除Ray Core外最重要的原生库，没有之一。Ray Data能够将Ray的异构计算和融合计算能力更好地发挥出来，在训练和推理的场景都有很高的应用价值。这部分我也会在后面的发展趋势中再深入分析。

最后是Stability方面的工作。这部分的数据主要关注下Ray规模化的能力，目前Ray社区版本最大支持8k节点的cluster，这对于目前大部分公司的场景已经够用了。但如果后期Ray在多租户方向逐渐成熟的话，还需要持续突破这个上限。

Anyscale

Anyscale在本次Summit上发布了众多引擎和产品化的能力，主要包括RayTurbo、Provider for K8S、Machine Pools、Governance Suite等。站在社区的角度来看，我们这里不去解析Anyscale的云产品，我们主要关注一个点，即RayTurbo。

RayTurbo是Anyscale内部版本的Ray，这次是在Ray Summit上首次公布。这给我们传递了一个信号，即Anyscale开始重点搞内外差异化版本，将一些重要的优化点闭源在内部，形成商业化壁垒。这或许是依靠开源项目做商业化公司的必经之路。对于Ray开源的开发者和用户来说，我们当然希望拿到一个更好的open source software。我们可以先从Ansycale相关的talks来了解下他们内部对Ray增强了哪些功能，这些方向也可以为做Ray二次开发的团队找到一些迭代的方向。下面我从Ray Data、Ray Train、Ray Serve三个方向分别举一个例子。

在RayTurbo中，有个Ray Data的优化是关于fault tolerance。Anyscale优化了Ray Data的调度器，使dataset pipeline能够更好地感知failure，并通过支持checkpointing机制提升fault tolerance的效率。这方面的工作确实是目前社区版欠缺的，目前社区版主要可以通过rerunning进行恢复。

在Ray Train上，Anyscale有个优化点同样是关于fault tolerance，叫做Elastic training。意思是在一些spot instances的场景，Ray Train可以在节点变少的情况下继续完成训练。这方面优化在很多训练系统中都是支持的，但在分布式训练过程中进行resharding也是一个非常重的操作，不确定这方面细节的优化在RayTurbo中是如何实现的。

在Ray Serve中，Anyscale实现了滚动更新的能力。在社区版本中，如果要实现deployment的热更新，需要2倍的资源，即2N的资源。Anyscale实现了最小N + 1资源的滚动更新，降低了应用的运维成本。这看起来也是Ray Serve生产化落地中的一个重要的优化方向。

通过上面几个Case可以看出，Anyscale在RayTurbo上还是做了非常多务实的特性或者优化。对于社区而已，我们呼吁有相关需求的团队可以投身社区进行贡献，但如果您所在的团队只是一个Ray的用户而非开发者，可以考虑直接试用Anyscale平台提供的RayTurbo。

Challenges

同时，我们也发现有团队在Ray Summit上分享了一些Ray的问题。

Aryn分享了他们遇到的问题：Ray在小任务上延迟比较大；Ray集群中分析failure相关日志不太方便；datasets内只允许有相同的attributes等。

Motional吐槽了下Ray Data没有join算子的问题，这个在社区也曾经有激烈的讨论。Ray Data目前定位是AI workloads的最后一公里数据处理，到底是否需要支持join？不知道大家怎么看这个问题？

Ray在新时代的发展趋势

下面，结合我在Ray Summit上看到的use cases，谈谈Ray的发展趋势。

Ray在Data + AI方向的应用逐渐成为主流

这似乎有点出乎意料。从Ray的历史来看，Riselab在2016年开源之初面向强化学习场景设计Ray Core，后续发展出了独立的强化学习库RLlib，再后来有了Ray Serve。Ray Data的出现并不算早，也就是近几年的事情，为什么感觉今年迎来了爆发式的应用，逐渐成为了Data + AI方向最主流的计算引擎？

这里的主要原因是Ray在Data + AI方向找到了两个非常典型又能发挥Ray优势的场景：batch inference和ingest for training。在去年的Ray Summit 2023会议上，Anyscale有两个重要的Talks分别解读了这两个应用场景，从结果看都有着相当可观的benchmark结果。其中一张经典的示意图如下：

Ray可以在CPU+GPU混合计算的场景实现更高效的吞吐，这恰恰跟Data + AI的场景相吻合。蚂蚁早在2018年提出了“Ray融合计算”的概念，实际上说的也是这回事，“融合” 既可以是CPU workloads和GPU workloads的融合，也可以是Data workloads和AI workloads的融合。

这么一看，Ray在Data + AI方向的爆发又是情理之中。

下面我们看几个今年Ray Summit上分享过的use cases。

近年来，Ray在字节的应用越来越广泛。今年字节团队分享了他们利用Ray Data处理语音、视频等多模态数据的案例。他们在典型的batch inference pipeline中引入了Ray Serve的deployment，以此达到更灵活的devops链路。

Nivdia同样分享了他们batch inference的应用场景，主要是处理视频数据。

Nivdia除了拥有强大的AI硬件生态，在AI软件生态上同样处在主导地位。此次引入Ray做batch inference，相信对Ray的发展也会产生积极的促进作用。

在训练方面，Pinterest分享了他们ingest for training的案例。传统的训练系统（如pytorch）一般都是利用GPU节点本地的CPU做训练前的数据加载和处理，这种实现中的CPU与GPU的资源配比固定，无法达到理想的吞吐。而Ray将数据加载和处理的CPU计算拓展到分布式环境，在复杂的训练任务中通过合理调整CPU与GPU资源配比达到更理想的吞吐。

谈到Data + AI，另外一个不得不提的计算引擎就是Spark。目前社区对Ray Data的定位是AI workloads的最后一公里数据处理，因此严格来讲，Ray和Spark从能力和生态位上并不是重合的。所以我们也看到很多Spark + Ray融合的架构，比如Uber分享的：

虽然Ray社区并没有将Ray Data的定位拓展到纯Data领域，但我们也可以看到很多Ray在大数据领域的Case，比如蚂蚁基于Ray在图计算、流计算等领域的相关工作，以及今年Amazon分享的Ray在湖仓领域的大规模落地。基于Ray的Exoshuffle系统在去年打破了利用云端资源进行大规模排序的记录，这同样也是Ray在大数据领域成绩。Ray Core的本质是通用分布式系统，理论上可以应用于任何需要分布式能力的场景，因此未来一定会有更广阔的探索空间。

Ray在AI生态的集成正逐渐深入

Ray由于其“framework agnostic”的设计已经集成了丰富的AI和Data的框架，形成了庞大的生态。如今我们看到，Ray与很多开源框架的融合已经成了行业共识的组合，集成和优化工作正逐渐深入。

比如在推理领域，Ray是vllm默认的分布式并行推理底座。近期随着Ray Compiled Graphs的推出，Ray可以更好地优化并行推理中的通信开销和内存开销，实现更高的吞吐：

vllm集成Ray

另外，在线推理方向，Ray Serve + Nvidia Triton的组合也被广泛应用，Nvidia工程师在本次Summit上分享了相关的实践：

Nvidia Triton集成Ray

多租户任重而道远，Workflow仍然是调度Ray Cluster的主流用法

随着Ray在企业内落地规模的增长，关于是否走多租户路线一直是社区近几年讨论的热点问题。今年Ray Summit，也有不少议题针对多租户问题进行了讨论：

Apple分享了他们的观点。他们认为，单集群多任务在workload启动上占据优势，但在隔离性、GPU调度和管理等方面不如单集群单任务。

Netflix分析了三种共享集群的方式，分别是：“不共享”、“团队内共享”、和“全局共享”。最终他们通过权衡选择了“团队内共享”的方式。

Google选择了Job模式（单租户）构建万节点的Ray on K8S集群，每个集群仅有44个CPUs。

可以看出，业界对于Ray多租户使用方式还比较“谨慎”。这里的原因主要还是Ray开源版本对于多租户的支持不完善，虚拟集群（Virtual Cluster）在社区的REP还没有被实现，同节点Tasks之间的物理隔离也没有好用的解决方案，这方面在业界应该只有蚂蚁集团拥有相关的落地实践。

但社区今年也有这方面的进展，比如最新的版本已经支持最大8k节点，相比之前有了一倍以上的提升，这方面规模化能力也是后续推动多租户方式必不可少的。

Ray的多租户能力有待完善，同时其强大的编排能力也有待进一步被挖掘。从编排的层面来看，Ray是有能力在一个大集群内调度一个完整的业务DAG的，但由于生态能力和Job编排能力需要进一步补充，目前主流的用法是通过Ray Job实现业务DAG中的一部分或者某几部分，然后整个业务DAG的编排交给外围的workflow框架，比如Airflow + Ray的用法：

在workflow中，为了在有限的资源池调度更多的Ray Jobs，常常引入如Kueue之类的job队列管理组件来优化作业调度，比如spotify的分享：

以及google的分享：

从我个人的视角来看，当Ray的规模化能力和多租户能力完善时，是不需要Kueue这种Job队列来调度Ray Job的。不同于其他计算引擎，Ray Job是无法在创建之初确定总资源的，所以Kueue看到的资源需求是预估的，很难保证准确。另外Job粒度的资源调度过于粗糙，实际上两个Job之间是可以共享Ray Cluster实现资源的超卖运行的，用队列的方式去严格控制资源很难把资源利用率优化到理论上限。Ray的Task调度更细粒度，Ray的Task列表本身就有队列的属性，再配合placement group的gang scheduling能力，我们可以放弃Job队列直接把所有任务扔到一个大的Ray Cluster中进行排队和执行。这方面目前Ray内部还缺少一个Task优先级和抢占的能力。以上描述的是一个比较理想的状态，考虑到目前Ray还有很多限制，我们观察到通过workflow + job queue仍然是主流的使用方式。

Ray on K8S 成为行业共识

Spotify的分享

关于Ray和K8S是否存在生态位冲突的问题，我想随着近两年KubeRay的成熟以及大量的Ray on K8S实践的出现，在业界已经有了明确的答案。K8S在云原生时代在云技术栈上找到了一个完美的“横截面”，成为了容器化调度的事实标准；Ray的出现同样也在尝试寻找下一个“横截面”。为了能够完美支持Data&AI领域的融合计算和异构计算，Ray内部实现了Task调度，因此常常被拿与K8S调度来比较。从目前的发展趋势来看，Ray on K8S形成的两层调度系统，更能够满足业务各方面的场景需求，Ray和K8S正逐渐融合，加速协同。

今年Google团队分享了他们在GKE上基于Ray构建的分布式平台。Google作为K8S的缔造者，近几年也在积极地拥抱Ray生态，这对Ray on K8S的发展具有独特的意义。

Ray可以借助K8S丰富的基础设施生态，为Data&AI场景提供开箱即用的能力。比如存储方面，数据处理、训练、推理等场景往往都需要CSI fuse提供分布式共享存储：

需关注新兴方向

大模型爆发至今，看模型训练的话，逐渐进入深水区，通过强化学习在post-training阶段优化模型已经成为研究的热点。然而RLHF并不是什么新的概念，这个架构早在ChatGPT推出之前就已经被OpenAI的论文公开。2022年底，ChatGPT发布开始颠覆行业。当时由于Ray的RLlib在传统强化学习领域早已广泛应用，蚂蚁也尝试在ColossalAI项目中验证RLHF的可行性。后来在社区也出现了多个基于Ray的RLHF框架，比如trlx、OpenRLHF等。今年，字节在Ray Summit分享了他们最新开源的基于Ray的RLHF框架veRL：

字节分享基于Ray的RLHF框架veRL

RLHF on Ray一直是我非常看好的方向，因为在这个场景中有多个模型，模型之间需要同步权重、传输样本数据，并且同时有推理和训练的计算过程，非常适合用Ray去调度并通过Ray Task和Object Store进行粘合。字节在veRL中选择了single controller + multiple controllers的混合架构，未来随着模型越来越大，这种架构的优势会比较明显。

另一个值得关注的新方向就是Agent on Ray。今年Agent的热度持续走高，逐渐从实验性阶段走向生产化。未来，随着Agent的大规模落地和部署，分布式的需求也会逐渐的显现。相比传统web应用，Agent需要在内部通过循环的方式进行规划和分步执行，并且在执行过程中需要进行模型推理、RAG召回、tools调用、大模型生成代码执行等。从这个角度来看，Agent会从一个服务型系统转变成一个计算型系统。在今年的Ray Summit上，蚂蚁分享了自研的分布式Agent框架Ragent，基于Ray提供分布式、可扩展、易于与其他开源生态集成的Agent中间件。