这篇教程将深入探讨微信AI计算中Ray技术的大规模实践，涵盖从百万级节点集群管理到高效利用低优资源、降低部署复杂度等核心内容，帮助您理解如何构建高效稳定的AI服务平台。

一、背景

微信作为国民级应用，其AI计算服务规模巨大，例如语音转文字、视频号推荐、扫一扫图像识别等。为了应对这一挑战，微信团队建立了Astra平台，并在此基础上大规模使用Ray技术（主要用于Ray Serve）。

在引入Ray之前，开发团队发现AI算法服务与传统微服务存在显著区别，主要面临以下挑战：

• 应用规模巨大：传统微服务通常只有几千个节点，而AI计算服务需要数十万节点，资源需求达数百万核。
• 部署复杂度高：AI服务对GPU有特殊需求（如NVIDIA、紫霄、昇腾等），不同型号GPU需要特定适配，增加了部署工作量。
• 运维难度大：不同业务可能需要各自部署独立集群，运维工作复杂。
• 成本高昂：GPU算力资源昂贵，降低推理成本和提高利用率是重要目标。

Ray提供了统一的分布式平台，能够整合多种计算模式，形成完整生态系统。早在2022年，团队就关注到Ray的优势，并参照国内外成功案例（如ChatGPT等），决定利用Ray将单机应用轻松扩展至分布式环境，简化开发流程，实现更高效的资源管理。

Astra平台与Ray的整体架构

在Astra平台与Ray结合的架构中，平台管理的基本单位是基于Ray的应用。底层采用自主设计的联邦集群架构，连接公司内部多个K8S集群。每个K8S节点上集成了Starlink集群管理的Agent、网络穿透P2P下载组件以及TFCC AI运行时。

架构图的底层是Starlink集群管理模块，提供以下核心能力：

• 服务发现
• 负载均衡
• 容灾调度
• 应用调度

主要挑战在于：支持数十万个节点的大规模集群管理；优化利用率较低或空闲的低优资源以降低成本；简化应用部署流程。

通过以上设计，不仅应对了技术挑战，还在成本控制和部署效率上取得了显著进步。

二、百万级节点的集群管理

处理百万级节点集群管理时，调度架构通常分为三种类型：

• 单层调度：类似K8S，适用于数千节点的小规模集群，并发度较低。
• 两层调度：预先将资源池中的机器分配给上层调度器（如Spark），并发度更高，支持更大规模。
• 共享调度：源自谷歌Omega论文，支持无限数量调度器，每个应用拥有自己的调度器，所有调度器都可查看整个资源池状态。采用乐观调度策略，假设无冲突分配资源，检测到冲突时调整，显著提升调度规模和资源利用率。

提示：对于管理数十万节点的超级应用，共享调度架构几乎是必然选择，它通过多调度器同时工作，确保高并发度和高效资源利用。

Astra自研调度架构

架构从下往上分为四层：

• 最底层：部署在不同K8S集群上的节点，资源预先分配。每个K8S集群的节点定期向Resource集群发送心跳信号报告状态。
• Resource集群：核心部分，聚合心跳信息并通过广播实现轻量级状态同步，维持百万级别节点的在线节点列表，为高性能资源管理提供基础。
• APP级别调度器：每个应用程序拥有独立调度器，能直接访问整个集群所有节点状态信息，负责资源调度、负载均衡、容灾调度。得益于共享调度设计，每分钟可处理数万节点调度任务。
• 最上层：用户操作界面，用于执行扩缩容等操作，提供直观体验。

这套架构通过分层设计和资源共享调度机制，实现了对大规模节点的有效管理，显著降低了运维复杂度和成本。

三、高效稳定地利用低优资源

腾讯内部低优资源总量庞大，但存在以下问题：节点亚健康比例高（CPU时间片被抢占、节点可能随时被高优先级任务抢占）。当Ray应用部署到低优资源时，节点被抢占会导致集群难以恢复，尤其头节点故障时社区版仅提供Redis备份恢复方案，团队希望寻找简洁解决方案。

快速处理亚健康与移除节点

• 异常节点下线：利用K8S的Pre Stop特性，心跳检测频率为每秒一次，触发Pre Stop后立即从在线列表移除节点，3秒内更新路由表，4秒内节点被完全移除。
• 性能较低节点：实时监控并收集运行数据，通过自动调节权重的路由算法调整节点接收请求量，性能差节点赋予较低权重，高性能节点保持较高权重，优化整体服务吞吐和耗时。

提示：低优资源上使用Ray时，必须设计系统容忍节点（包括worker和头节点）被频繁踢出的情况。

Ray联邦集群架构

借鉴K8S联邦集群概念，提出Ray联邦集群架构，核心特点是：

• 服务单元化：每个Ray cluster作为独立服务单元，可单独提供完整服务。
• 容灾能力：通过增加Ray cluster实现容灾，每个cluster视为一个容灾单元。
• 突破规模限制：将每个Ray cluster设计较小，突破单个cluster的规模限制。
• 无状态服务般的容灾：无论节点或整个cluster挂掉，都可迅速替换。

容灾方案：

• 头节点故障：心跳异常时立即从路由算法移除该cluster，调度新Ray cluster替换。
• Worker节点故障：仅替换故障worker节点，cluster可继续使用。
• 扩展性：支持纵向扩容，根据需求调整worker数量。

训练任务自动调速

针对低优资源随时可能被移除导致集群处理能力下降的问题，开发了自动调速工具：

• 性能预估：根据资源类型（如GPU型号）和数量动态评估节点处理能力。
• 动态调整消费速率：基于性能预估，检测到资源变化时自动调整任务消费速率。
• 保障服务连续性：即使资源被移除，系统仍能保持正常运行。

优化后的效果显示，失败率显著降低，平均处理时间大幅改善。

四、降低应用部署复杂度

一个 APP可能包含多个模型，每个模型需部署在不同类型GPU上，且某些GPU类型会超过集群规模限制，复杂度约为O(N^3)。为降低复杂度，采取以下措施：

• 多模型扩展：使用Ray可仅需一个脚本实现多模型有效管理和调度。
• 多卡型扩展：设计相应扩展机制。
• 多模块扩展：灵活应对不同类型和数量组件需求。

具体实现

• 统一基座环境：包含核心组件（P2P网络穿透、TFCC、特定版本CUDA），允许用户使用Conda管理包，支持自定义环境配置及CI编译操作。
• TFCC引擎支持：屏蔽底层GPU卡类型（如NVIDIA、昇腾），用户只需调用推理接口即可完成推理任务。
• P2P下载优化：通过NAT穿透、节点限速和全局限速功能，将140GB的模型在10分钟内完成下发。

提示：P2P下载优化极大缩短了模型部署时间，提高了整体工作效率。

五、Astra-Ray 使用样例

以下是平台上的使用界面和部署流程：

• 第一步：修改代码，按ray serve做简单改写。
• 第二步：打包并上传至Git仓库，选择Python版本，平台自动生成部署包。
• 第三步：变更Ray配置（调整服务deployment配置），通过灰度发布机制逐步应用新配置，确保稳定性和兼容性。
• 第四步：进行扩容，可在平台查看集群机器列表（例如包含约4000个请求者，每个请求者对应5台机器，总计超过2万个节点）。

平台还提供Ray Dashboard查看请求状态和性能指标，以及日志调试功能帮助快速定位问题。

六、常见问题（Q&A）

Q1：关于低优资源的抖动状态问题

问：低优资源存在3秒更新路由表和每秒更新机制。对于状态不稳定的资源（如性能一会儿好一会儿坏），是否会引发抖动？如何处理？

答：存在两种情况：

• 性能波动：当节点CPU被压制时，通过动态调整权重应对，确保性能波动不影响服务质量。
• 节点掉线与重启：掉线后重新启动的节点视为新节点。若触发PreStop机制，节点被移除，重新上线时作为新节点加入资源池。

Q2：关于每秒更新频率的问题

问：每秒更新的频率是否过高？是否带来额外压力？

答：每秒心跳确实产生较高请求量，尤其面对数十万个节点时。团队采用聚合扩散机制减轻集群负担：保证自身服务性能；在集群容量接近极限时，可扩展更多集群支持更大规模。Starlink架构可灵活扩展至多个集群。

Q3：超级APP跨集群调度机制

问：超级APP如何实现跨多个Ray Serve的调度？

答：通过RPC方式，不同Ray集群之间不互通，但保证每个Ray集群都有完整功能。

Q4：超级APP副本故障恢复机制

问：超级APP拥有大量副本时，如果部分副本挂掉，由哪个调度器负责重启？

答：由APP自身的调度器负责维护所有Ray Serve状态。即使应用规模庞大（如100万个集群），调度器只需定时扫描，每秒一次即可完成管理，不太可能成为瓶颈。

Q5：联邦集群的逐步扩展与负载均衡

问：联邦集群如何逐步扩展并淘汰旧集群？版本升级时如何保持负载均衡？

答：联邦集群的扩展和淘汰是渐进过程。头节点不执行业务逻辑，与worker等价，减少系统影响。做路由算法时，将所有节点视为等同，简化管理和调度过程。

Q6：在线服务Runtime优化

问：是否在Ray的runtime层面进行了特定优化？

答：目前尚未对Ray框架本身进行修改。项目从今年上半年开始引入Ray，现阶段重点在集成而非深度定制。

Q7：TFCC引擎的透明性与模型转换

问：实际使用者是否需要关注推理引擎的选择？模型转换和优化如何处理？

答：用户无需关注底层推理引擎。打包时将运行内容分为三部分：软件包、环境包和数据集（模型）。上传时对模型进行预处理，转换成适用于各种GPU卡的版本并进行性能优化，所有这些自动完成，用户只需提供输入参数。

Q8：推理引擎通用接口

问：不同推理引擎的特性（如Dynamic Batch、Attention机制）是否通过通用接口封装？

答：当前并非所有推理任务都使用TFCC，但计划未来增加支持。最常用接口只需提供输入形状等基本信息。不同推理引擎特性正在考虑如何通过通用接口适配，但目前尚未完全封装。

Q9：Ray联邦集群间的通信

问：腾讯内部的Ray联邦集群是否实现分布式共享内存的打通？不同Ray serve之间是否可以直接通信？

答：不同requester之间的对象无法直接获取。要访问其他requester的对象，只能通过API接口进行间接访问。

Q10：TFCC与显存管理

问：TFCC是否实现显存的分布式管理？

答：目前还未实现。

通过以上实践，微信AI计算成功借助Ray技术构建了高效、稳定的AI服务平台。未来，随着低优资源利用率的进一步提升和部署流程的简化，我们将继续探索更多可能性。