中兴通讯基于Ray的融合计算底座实践：微服务弹缩、智能体与大模型训练

导读：随着通信网络向自智化和 6G 演进，AI 与数据驱动的融合计算底座正成为支撑电信业务智能化转型的关键基础设施。中兴通讯基于 Ray 构建的融合计算平台，涵盖从微服务弹性伸缩、智能体服务编排、大模型端到端训练，到国产加速器适配等多个核心场景。通过深度整合 Ray 的分布式能力，中兴不仅实现了资源利用率的显著提升和系统响应的秒级弹性，还推动了 AI 原生网络（native AI）理念在实际产品中的落地。本演讲系统阐述了 Ray 如何满足电信级高可靠、低延迟、异构协同的严苛需求，并展望了其在轻量化部署、通信协议优化及行业场景拓展方面的未来方向，为 AI 时代分布式操作系统的发展提供了重要参考。

今天的分享围绕下面五点展开：

1. 通信网络演进与业务需求
2. 基于 Ray 的融合计算底座
3. 三大典型应用场景
4. Ray 适配国产加速器通信协议
5. 未来展望

01 通信网络演进与业务需求

首先，让我们回顾一下通信网络的发展历程以及业务需求的演变。中兴通讯作为一家主流的通信设备提供商，大家可以通过下面的 5G 通信网络逻辑架构图来了解我们产品的结构。从终端到无线接入网，即我们专业术语中的基站，再通过承载网络连接到核心网络，从而实现用户语音和数据的通信需求。

当前网络演进有两个主要趋势：

• 自智网络的演进：这是一个专业术语，指的是大型网络过去主要依赖人工运维，而自智网络的目标是利用数据和人工智能实现自动化运维。目前的做法是将最近热门的智能体 Agent 与大模型结合，应用于网络运维中。例如，当出现电话掉线等故障时，我们的 Agent 和大模型能够进行整体的根因分析，并提供解决方案，这一过程需要借助相关的数据和计算底座。
• 5G 网络到 6G 网络的演进：我们提出了一个概念叫做 native AI，即网元设备中内置大模型，具备网络内生的能力。它能够根据用户的意图执行网元的功能，例如保障和自愈。此外，未来数据将由统一的数据管理网元进行管理。

因此，这些对演进的诉求为我们的计算底座提出了三大方面的要求。首先，它需要支持异构计算资源，包括嵌入式设备、边缘端以及云端的计算能力。此外，它还应适应多样化的分布式计算负载，涵盖推理、模型训练以及服务弹缩等任务。另外，我们还希望整合数据和智能计算。

02 基于 Ray 的融合计算底座

关于这三大需求，我们将考察 Ray 如何满足我们的需求。

首先是异构资源和通用底座，Ray 能够自定义底层的异构资源。此外，它对底层资源的细粒度感知和拓扑结构也便于我们进行调度。另外，我们还可以在 Ray 上编排一些定制的智算任务和通算任务。

其次，Ray 还支持多种引擎和业务，包括微服务的弹性伸缩、智能体服务的构建，以及大模型的端到端开发，这些都可以基于 Ray 进行构建。

此外，我们还整合了数据和 AI 计算。首先，其编程模式和任务编排采用统一范式，接口简单易用，基于此我们可以进行融合计算。其下是基于 Ray 的融合计算架构。我们认为，在 AI 时代，Ray 将成为分布式操作系统的核心。

03 三大典型应用场景

场景一：微服务实例弹缩

这是一个微服务弹缩的具体实例。以我们的网络产品为例，最初微服务的部署基于 K8s 平台，采用固定的模式。这意味着副本数量和配置资源是固定的。这样的好处是架构简单，运行稳定。然而，这导致了资源利用率低和缺乏弹性的问题。

随着业务的发展，我们需要处理日益增长的业务流量。我们的目标是在计算资源不变的情况下，提高系统的处理能力，并且能够应对突发流量。这意味着我们需要实现秒级的扩缩容，同时在 CPU 和 I/O 内存高负荷下稳定运行。

为了解决这个问题，我们尝试组建了基于 RayServer 的系统。
系统由三个组件构成。如左图所示，基于 RayServer 启动 Ray 集群；另一个是微服务控制器，基于 Ray Actor 开发，用于收集微服务进程的指标并传递给 server controller。接着，server controller 根据这些指标判断是否需要进行扩容。同时，我们也会备一个 worker pod，作为一个预热的 pod，在扩容时能更快响应。
此外，我们的方案还与现有的微服务架构兼容。我们目前的架构是基于自研 MSB 组件进行服务注册和发现。因此，基于这一架构，我们可以迅速实现资源副本的弹性扩展。

在这一过程中，我们讨论的关键点包括以下 3 点：

• 微服务的副本与 worker 的映射关系。我们考虑了两种方案：一种是一对一映射，另一种是一对多映射。经过讨论，我们最终决定采用一对一映射方式，因为它更为简单。尽管这可能会带来额外的资源开销，但其提供的可靠性和业务处理稳定性更优。
• 微服务的副本控制，我们利用了 Ray Server 的高级特性。例如，我们设定了三个参数，假设微服务在达到 100 的设定值时，系统将进行自动的扩容和缩容。具体来说，一旦微服务的 upscaling_factor 设置为 0，就代表只要达到 100 的负载，系统会立即进行扩容。同时，当微服务的 downscaling_factor 设置为降低到 80 的请求时，系统会进一步执行缩容操作。这样就实现了快速扩容和保守缩容的策略。此外，我们还对微服务的 Head 单点路由进行了改进，使其不仅能够基于请求进行调整，还能根据其他的业务指标进行优化。
• 在资源占用方面，我们对一些不必要的进程进行了优化和裁剪。

优化后，弹出效率从原来的 80 多秒分钟级降低到了现在的秒级。此外，资源占用方面保持不变，我们仍然可以处理十万小区的业务量。采用这种优化方法后，CPU 资源减少了 37%，内存资源减少了 19%，并且引入了 Ray 这个集群，其本身占用的资源小于 3%。
我们还测试了在 CPU 和 I/O 高负荷情况下，基于 Ray 的方案，其指标的弹性决策依然可以保持在亚秒级，表现较为稳定。

场景二：智能体服务构建

下面介绍中兴通讯基于 Ray 的一些智算场景，主要包括智能体和大小模型的端到端开发实践。首先，关于智能体服务的构建，中兴通讯拥有名为“Co-Sight”的智能体框架，在 GAIA 排行榜中位列第 5。该框架主要采用分层的 Agent 架构，并结合任务分解的组合模式。具体来说，它包含一个 TaskPlannerAgent，该 Agent 将所有任务去结构化地拆解为各个步骤。每个步骤都对应一个 TaskActorAgent，用于独立执行。每次执行过程中，通过调用工具并进行多轮 ReAct 循环来完成任务。

由于它本质上是一个单机 Agent 的分布式开发。为了实现快速迭代，在推广至生产环境时，我们遇到了一些挑战：

• 进行分布式改造时成本较高，需要重复开发许多功能。
• 使用某些工具从数据库检索特定基站的日志记录，将其服务化需额外投入成本。
• 目前缺乏处理大规模日志数据的能力，且没有反压机制。
• 需要开发额外的服务监控模块。

我们主要与 Co-Sight 团队进行沟通，并提出了一种基于 Ray 构建 Co-Sight 服务的方案。该方案组成如下：

• 通过 Ray Serve 托管了原生 Co-Sight FastAPI 服务，提供用户访问请求接入的端口。
• 通过 Ray Actor 构建了具有状态管理与调度的 Agent。
• 基于 Ray Task 的 Tool 实现并行和无状态的执行。
• 利用 Ray DAG 实现了 step 的编排与调度，即将下一个 step 添加到 DAG 中，最终执行整个 DAG。

完成上述四点之后，整个 Agent 的执行流程将变为用户的请求接入到 RayServer 的 proxy 代理中。接着，代理会具体地将请求转发至某个特定的 worker，并进行相应的初始化。这包括创建 TaskPlannerAgent 的 Actor 实例，进行任务调度与编排，构建 DAG，并执行 TaskActorAgent。执行完毕后，系统将处理结果的回传和结果认证。

实施此方案后，原本单机服务的并发量可提升至 200 路，同时有效提高资源利用率。更重要的是，通过 Ray 服务原生的容错和可观测性能力，实现了节点和 Actor/Task 实例的容错及故障自愈，这对于业务方来说在处理外场问题时尤为可取。这正是将 人工智能 框架能力进行分布式扩展并应用于实际生产环境的典型例证。

场景三：模型端到端 - 大模型后训练

在第三个场景中，我们关注的是大模型的后训练阶段。这一过程的步骤相对固定，我们通过组合各个大模型后训练会用到的组件来搭建模型后训练。我们发现，许多模型组件可以部署在 Ray 上执行。对于那些不支持 Ray 执行的模型组件，例如 OpenCompass 的模型评估工具，我们也可以方便地对其进行改造，使其能够在 Ray 上运行。因此，我们进行了一项尝试，即将所有大模型后训练的各个阶段部署到 Ray 集群上。

具体而言，在该方案中，主要分为管理和业务管理。主要是提供一个用户进行大模型后训练的任务平台，每个 stage 的编排由用户自行完成。业务集群主要运行四个任务：数据参数准备、模型的 SFT、强化学习和模型评估。这四个阶段构成了大模型后训练的四个阶段。然而，这种 Pipeline 作业实际上需要人工的串行处理，相当于原来的分开执行的方式，资源利用率并没有得到明显的提升。我们目前正致力于增强 Ray 的这种工作的解析方式，尽可能将 stage 里面串行的部分拆解成符合我们依赖关系需求的并行执行的 stage，以实现并行阶段的并行化执行。

该思想实际上源自 SQL 的物理执行计划优化方法。第二点是，各个 stage 之间的数据传输仍然主要依赖于数据的落盘，这是一种较为稳健的做法。通过采用这种设计，结合 RayData 的流式处理和 RDT 的方式，可以在内存级别上实现数据流转，从而提升数据传输效率。

场景三：模型端到端 - 小模型反电诈业务

我们也在 Ray 上开发了基于小模型的端到端应用。

首先介绍的反电信诈骗业务。主要聚焦于三个关键业务点：

1. 特征工程和模型推理：首先是利用 RayData 和 Iceberg 提升特征工程和模型推理的效率，并借助 Ray Data 的分布式离线批量推理和流式推理能力增强推理服务。这种结合有效提升了 大数据 处理管道的性能。
2. 模型训练：在模型训练方面，主要采用 Ray Train 实现跨节点的 DDP 训练，相较于 torch 的 DDP，它提高了用户友好性，方便开发人员进行快速迭代，并根据模型复杂度分配不同资源。
3. 模型在线更新：由于反电诈业务在不同时间会更新一批数据，但模型没有必要重新训练，主要通过 Ray Train 和 Tune 进行增量训练。并通过 read 指标体系采集准确率等指标，更方便的透传到前端，方便开发人员进行模型评估验证，从而使得端到端模型开发耗时降低约 84%。

04 Ray 适配国产加速器通信协议

接下来我们将分享 Ray 在适配国产加速器，或者称国产卡上的工作。中兴通讯是设备服务器的提供商，提供的服务器会包括昆仑芯、寒武纪和沐曦等国产卡。在 Ray 里面，有三个用到了国产加速器通信协议等重要特性：Ray 编译图、Ray 集合通信以及 Ray Direct Transport。这部分是需要对这种高速通信协议 xCCL 的支持。遗憾的是，很多国产卡没有像 N 卡那样具有完善的 NCCL 等 P2P 协议通信的底层支持。我们采用的是更通用的方案，通过 torch 的集合通信组来实现 Device 之间的直接通信，并且用 torch 提供了这种流管理来实现计算和通信的重叠。

这又带来一个问题，许多上层框架在初始化 RayExecutor 时，会帮你初始化通信组，例如这边的 vLLM，在具体实现过程中会继续复用上层框架创建的组或者重新初始化 torch 的通信组。在具体使用方式上，主要是在启用 Ray 集群时完成对应的环境变量设置和节点资源声明，然后在程序中通过环境变量自动发现设备，或手动将 Device 注册到我的加速器上下文管理器。

第三步主要是在执行时指定执行后端，即你的 backend 或者你的 transport 的类型。在使用时，可以复用或创建你的 torch 通信组。

最终，性能表现相较于原始的 Object Store 实现了大约两倍的提升。在应用到我们的 vLLM 推理时，特别是针对 DeepSeek-R1-671B 多卡推理，使用 vLLMv1 + Ray CG 以及对比 v1 + Ray 的情况能够将性能提升 62% 左右。这样的性能提升是相当显著的。

05 未来展望

对于未来，我们主要关注三个方面：

• 持续丰富国产加速硬件和高速通信协议的生态及应用：希望国产的加速通信协议和加速器能够形成类似 N 卡的生态系统，并持续推广 Ray 中这种加速通信协议。在强化学习中，特别是在我们最近研究的这种具身仿真强化学习中，涉及到仿真器与推理之间的通信，通过使用 RDT 协议可以提升数据传输速率。在此基础上，我想补充的是，尽管基于 torch 通信组的方法在实现通信方面具有一定的优势，但同时也存在一些局限性。例如，所有 Device 和 rank 必须在同步初始化时处于同一通信组内，无法实现跨通信组的数据传输。其次，send 和 receive 操作必须按照特定顺序进行，比如必须是先 send 再 receive，否则会导致空转。我们希望在 Ray 的层次上去为这种基于 torch 通信组来实现 Device 之间通信的这种方式提供更稳健的这种可观测性。
• Ray whl 包的部署和使用，以及其轻量化：我们在使用 Ray 的时候比较关心它的资源使用量。需要实现更细粒度的 whl 包选择安装，允许业务方根据需要选择所需的模块和功能，从而进一步减少例如 Ray whl 包和 pod 的大小。第二点是 Ray 集群减少资源占用量，例如内存和周期等资源的使用。第三点是提供 Actor Pool 高级抽象，类似于线程池的方式降低框架接入和用户使用的门槛，并推动用户向 Ray 这种融合计算底座去做改造。
• 推广 Ray 在电信业务场景的进一步应用：虽然 Ray 在互联网场景，例如模型推理和模型训练方面已有非常成功的应用，但在电信业务场景中，其应用仍需进一步推广。因此，我们的目标是基于 Ray 构建一个面向 AI 异构兼容、灵活调度、弹性扩展和高可靠性的融合计算底座。我们致力于将这种 云原生/IaaS 层面的先进技术，深入融合到电信网络产品中，以支撑未来更复杂的业务需求。

以上就是本次分享的内容，谢谢大家。