Ray在微信AI计算中的大规模实践

页 码 ：2/193目录Ray在微信AI计算中的大规模实践...................................................................3HybridFlow：基于Ray构建灵活且高效的RLHF编程框架..........................24蚂蚁集团基于Ray构建的分布式AI Agent框架............................................41Ray在Bilibili的场景探索与落地实践..............................................................57云原生场景下如何利用Ray快速构建分布式系统............................................85小红书图数据库在分布式并行查询上的探索.....................................................119分布式Data Warebase技术解析与应用实践..................................................144vivo超大数据规模分布式消息中间件架构演进实践........................................171 扫码关注公众号免费下载资料Ray在微信AI计算中的大规模实践导读：本文将探讨Ray在微信AI计算中的大规模实践。主要围绕下面六点展开：1.背景2.百万级节点的集群管理3.高效稳定的利用低优资源4.降低应用部署复杂度5.Astra-Ray使用样例6.Q&A分享嘉宾｜陈国敏腾讯微信专家工程师，微信Astra平台负责人苏文豪腾讯微信高级工程师编辑整理｜马同学内容校对｜李瑶出品社区｜DataFun微信现在已经成为人们日常生活中非常重要的组成部分，而随着人工智能的发展，微信内也为用户提供了多种涉及AI计算的服务体验。例如，语音消息的文字转换、视频号的AIGC和推荐、扫一扫功能的图像识别等。这些功能由于微信的用 页 码 ：3/19301背景 扫码关注公众号免费下载资料户规模巨大，所以AI计算的服务规模也非常大。为了应对大规模的AI计算任务，我们建立了Astra平台，目前，有许多业务已经 接 入 了Astra平 台 ， 这 些 业 务 在 平 台 上 构 建 了 众 多AI算 法 服 务 ， 覆 盖 了LLM/多媒体处理等多个方面。目前我们对于Ray的使用场景主要是Ray Serve，在Astra平台之前，我们团队是一个纯粹的后台开发团队。因此在我们在实际工作中，会更加深入的思考AI算法服务与传统微服务之间的区别。首先，关于应用规模，传统的微服务一般最多只有几千个节点、十来万核。然而，在AI算法这种计算密集型的任务上，我们的AI算法服务往往需要数十万节点，其计算资源需求可达数百万核。这种超级应用对我们的模块管理系统以及K8S集群提出了极高的要求，要支撑如此大规模的应用部署是非常困难的。其次，随着资源数量和资源种类的增加，部署复杂度快速升高。AI算法服务对GPU资源有特殊需求，市场上存在多种类型的GPU，例如NVIDIA、紫霄、昇腾等品牌。这些不同型号的GPU需要特定的适配工作，这无疑增加了每次部署 页 码 ：4/193 扫码关注公众号免费下载资料时的复杂性和工作量。再者，运维难度亦不容忽视。微服务主要涉及业务逻辑，不存在复用性，但AI算法是一种纯算法服务，并不存在业务逻辑，不同的业务可能都会需要分别部署独立的集群，这也相应地提高了运维工作的复杂程度。最后，成本问题同样突出。当前GPU的价格高昂，算力资源十分昂贵。降低AI推理的成本并提高资源利用率也是我们的重要目标之一。鉴于上述考虑，我们选择了Ray。它可以提供统一的分布式平台，整合多种计算模式，构建一个完整的生态系统。早在2022年，我们就注意到Ray的优势，当时对于Ray的理解尚浅，但观察到国内外众多企业，包括ChatGPT等先进应用的成功案例，我们决定加大对Ray的投入，利用其将单机应用轻松扩展至分布式环境的能力，简化我们的开发流程，并实现更高效的资源管理。接下来介绍Astra平台与Ray结合的整体架构。在这一架构中，平台管理的基本单位是基于Ray的应用，其底层由我们自主设计的联邦集群架构支撑。该架 页 码 ：5/193 扫码关注公众号免费下载资料构底层连接至公司内部多个K8S集群，允许我们的应用部署于不同的K8S集群之上。这些K8S节点是我们预先从K8S申请的资源，每个节点上都会集成我们Starlink集群管理的Agent、网络穿透P2P下载组件以及TFCC AI运行时。架构图的下层展示了Starlink集群管理模块，它主要提供了以下几项核心能力：服务发现、负载均衡、容灾调度以及应用调度。面对的主要挑战是支持多达数十万个节点的大规模集群管理，这意味着我们需要具备处理百万级Pod节点的能力，并确保高效的集群管理。此外，为了降低成本，考虑到腾讯内部可能存在资源利用不充分的情况，我们致力于优化资源配置，充分利用那些利用率较低或空闲的资源。最后，为了简化应用部署流程，我们为算法开发人员提供了便捷的方式，使他们能够迅速且轻松地部署应用程序。通过这样的架构设计，我们不仅能够应对大规模集群管理带来的技术挑战，还能够在成本控制和部署效率上取得显著进步，从而更好地支持微信平台上的AI计算需求。 页 码 ：6/193 页 码 ：7/19302百万级节点的集群管理接下来，将详细探讨在处理百万级节点集群管理时所面临的挑战及解决方案。调度架构通常可以分为三种类型：单层、两层以及共享调度。每种架构都有其特单层调度：这种架构类似于K8S，适用于规模较小的集群，一般为数千个节点。单层调度的一个主要限制是其较低的并发度，因为整个集群通常只依赖于单一的两层调度：此架构预先将资源池中的机器分配给上层调度器，例如Spark采用的就是这种模式。相比单层调度，两层调度具有更高的并发度，支持更大规模的共享调度：这一概念源于谷歌的Omega论文。其核心特点是支持无限数量的调度器，每个应用都有自己的调度器，且所有调度器都能查看到整个资源池的状态。我们实现了乐观调度策略，即每个调度器假设没有冲突地分配资源，并在检测到冲突时进行调整。这种方法不仅能够显著提升调度规模和资源利用率，还能大幅提高调度并发度，非常适合处理数十万节点的大规模集群需求。对于需要管理几十万甚至更多节点的超级应用而言，选择共享调度架构几乎是必然的。它通过允许多个调度器同时工作，确保了高并发度和高效的资源利用，满足了大规模集群管理的需求。我们的Astra平台结合Ray，正是采用了这样的共享调度策略，以应对微信AI计算中遇到的巨大挑战。 点和适用场景。调度器进行资源分配。集群。 扫码关注公众号免费下载资料接下来，将深入介绍Astra自研调度架构的整体设计，我们从下往上介绍。最底层是部署在不同K8S集群上的节点，这些资源是预先分配好的。例如，特定 业 务 可 以 向K8S申 请 所 需 的 资 源 ， 并 将 其 集 成 到 我 们 的 平 台 中 使 用 。 每个K8S集群包含各自的节点，这些节点会定期向resource集群发送心跳信号，以报告其状态。Resource集群会聚合这些心跳信息，并通过广播的方式实现轻量级的状态同步。这一机制保证了即使单个集群仅由几台机器组成，也能够支持多达百万级别的节点管理，并维持一个在线节点列表，作为高性能资源管理的基础。Resource是整个系统的核心部分，它不仅负责收集和同步节点状态，还提供了高效的资源管理能力。Resource集群能够实时掌握所有节点的最新状态，为上层调度提供准确的信息。在Resource集群之上，是APP级别的独立调度器。每个应用程序（APP）都有自己的调度器，这些调度器可以直接访问整个集群中所有节点的状态信息。每个调度器的主要职责包括：资源调度、负载均衡、容灾调度。得益于共享调度的 页 码 ：8/193 扫码关注公众号免费下载资料设计，调度器每分钟可以处理数万节点的调度任务，极大提升了系统的响应速度和效率。最上层是用户操作界面，用于执行诸如扩缩容等操作。这一层直接与最终用户交互，提供了直观的操作体验，使得用户可以轻松管理其应用程序和服务。这套架构构成了我们进行百万级别集群管理的基础，通过分层设计和资源共享调度机制，实现了对大规模节点的有效管理，同时保证了高并发度和资源利用率，满足了微信AI计算中的复杂需求。此架构不仅支持了数十万节点的大规模集群管理，还显著降低了运维复杂度和成本，提高了整体的服务质量和用户体验。高效稳定地利用低优资源下面探讨如何高效且稳定地利用低优资源。腾讯内部低优资源的总量非常庞大，但与此同时也伴随着诸多挑战，“天下没有免费的午餐”，尽管低优资源的成本 页 码 ：9/19303 扫码关注公众号免费下载资料较低，但也带来了新的问题。以下是从我们系统监控中截取的几张图，能说明我们所遇到的一些问题。首先，节点处于亚健康状态的比例较高，例如CPU时间片可能会被抢占，或者节点可能随时被高优先级任务抢占。在Ray的应用上，当Ray应用部署到低优资源时，节点被抢占会导致集群难以恢复。特别是在Ray Cluster错误处理方面，如果头节点出现故障，会难以恢复。当前社区版仅提供通过Redis备份的方式进行恢复，但我们不希望在服务中引入额外的依赖。因此，我们希望有一种简洁的解决方案，能快速的地解决这一问题。针对亚健康节点及被移除节点的快速处理，我们采取了一系列措施以确保系统的高效与稳定。以下是具体方法：首先，对于异常节点的下线，K8S平台通常不会提前很长时间通知即将缩容。因此，我们使用K8S的Pre Stop特性来迅速响应。由于我们的心跳检测频率为每秒一次，一旦触发Pre Stop，我们可以立即从在线列表中移除该节点。在3秒钟内更新路由表，这意味着在Pre Stop触发后的4秒内，该节点将被完全移 页 码 ：10/193 扫码关注公众号免费下载资料除。即使节点随后被资源平台直接终止，也不会对我们的服务造成影响。其次，对于性能较低的节点，我们会实时监控并收集其运行数据。通过自动调节权重的路由算法调整节点接收的请求量。具体而言，性能较差的节点将被赋予较低权重，而高性能节点则保持较高权重。这种机制确保了任务能够根据节点的实际性能进行合理分配，从而优化了serving层的工作负载分配，优化了整体服务吞吐和耗时。通过上述措施，我们不仅能够快速处理异常节点，还能有效管理性能差异较大的节点，确保系统在面对低优资源固有问题时仍能保持高效稳定的运行。从我们在Astra平台上使用低优资源的效果图中可以清晰地看到优化前后的对比。图中的绿色线条代表优化之前的状态，而红色线条则展示了优化之后的结果。通过对比可以看出，优化后我们的失败率显著降低，同时平均处理时间也得到了大幅改善。 页 码 ：11/193 扫码关注公众号免费下载资料在低优资源上使用Ray时，我们必须良好的设计系统来容忍节点（包括worker和头节点）被频繁踢出的情况。为此，我们借鉴了K8S联邦集群的概念，提出了Ray联邦集群的架构。这一架构的核心特点是每个Ray cluster作为一个服务的最小单位，每个Ray Cluster都能够独立提供完整的服务。这种设计确保了即使任意一个Ray cluster出现故障，整体服务依然不受影响。Ray联邦集群的特点包括：◼服务单元化：每个Ray cluster都是一个独立的服务单元，可以单独提供完整的服务。◼容灾能力：通过增加更多的Ray cluster来实现容灾。每个cluster都可以视为一个容灾单元，从而增强了系统的鲁棒性。◼突破规模限制：由于我们的基础设施本身支持百万级节点管理，我们可以将每个Ray cluster设计得较小，从而突破单个cluster的规模限制。◼无状态服务般的容灾：无论哪个节点或