Ray 的起源和价值

Ray 诞生于伯克利的研究项目，其起源可追溯至人工智能的萌芽时期。彼时，AI 训练领域涌现出两大关键需求：其一，下一代 AI 应用需要在动态交互环境中持续进化，通过人机或机机交互实现能力迭代升级，这与当今通过持续训练优化 AI 模型性能的理念一脉相承；其二，新一代 AI 应用对系统架构的灵活性与运行效率提出了前所未有的挑战，要求基础设施能够支持更复杂的任务调度与资源管理。

由于存在不同架构的 NPU、CPU，在同一平台、同一架构下训练同一模型的传统模式已无法满足需求，模型训练、数据清洗等工作都需要基于分布式架构或不同平台进行，异构计算成为必然趋势。在此背景下，数据的分布式协同问题亟待解决。

回顾 2016 - 2017 年，分布式计算框架众多，像 Apache Spark 等已被广泛应用。但 Ray 另辟蹊径，确定了两个独特的发展方向。其一为融合方案，借助通用计算框架实现数据处理、模型训练与服务提供；其二是组合方案，基于多套系统进行融合拼接，以此达成调度容灾、灰度部署、数据清洗与迁移等多样化功能。

Ray 秉持两大关键理念。其一，不绑定计算模式，将业务需求或目标作为计算模式的牵引方向；其二，追求极致简化，具体表现为将单机概念拓展至分布式领域，通过抽象复杂内容，类比 Java 中 Spring Boot 利用注解简化开发流程的方式，为用户提供便捷的开发体验。其开发模式由无状态、有状态和有依赖的输出三部分构成，这一模式为开发者构建分布式应用提供了清晰的思路。

Ray 采用基于 Python 的分布式编程模型，通过 @ray.remote 装饰器定义远程任务与 Actor，利用 ray.get 和 ray.put 实现数据与任务的分布式调度，支持在异构计算集群上高效执行并行计算与状态管理。

Ray 框架以 Ray Core 为高性能分布式计算中间层，我们在上面叠加了分布式业务数据处理层。

自 2016 年起，Ray 框架历经近十年的发展，不断迭代演进。早期 Ray 被定义为 “framework”，但该定义存在局限性，因其缺乏平台抽象能力。到 1.0 版本时，Ray 的定义更新为“build”。目前，Ray 推荐的主版本为 2.4，在2.0 版本及以后，其被定义为 “scaling AI and Python applications”，这一转变体现了 Ray 框架的发展方向和功能拓展。

关于 Ray 框架，我们一直思考：“Ray 到底是什么”“Ray 到底能做什么”“Ray 这几年到底做到了什么” 三个核心问题。

Ray 主要面向 AI 领域，且高度依赖数据处理。它构建了一整套涵盖从构建、训练、推理到在线服务的 AI 基础设施（AI Infra）。在 Python 技术栈中，早期 Python 在 AI 领域应用较少，常被视为“胶水语言”或“玩具语言”，缺乏工业化的落地实践。随着 PyTorch 和 Ray 等技术的出现，Python 在 AI 训练和分布式模型部署方面获得了工业级的解决方案。

从大数据计算迈向 AI 计算的进程中，Ray 期望能够实现从大数据集到 AI 计算的跨越，取代 Spark 成为 AI 计算平台的中间层。Ray 的目标不仅仅是成为一个分布式计算框架，更致力于成为分布式应用层的综合解决方案。

与专注于容器编排的 K8s 不同，Ray 更聚焦于 AI 应用领域。形象地说，K8s 类似 PaaS（平台即服务），而 Ray 则类似于 SaaS（软件即服务），两者在功能定位和应用场景上存在显著差异。

与 K8s 对比，研发效率上，Ray 开发周期更短（2 人天，K8s 为 15 人天 ）；代码量方面，Ray 主要用 Python，代码量少（260 行，K8s 涉及多种语言且代码量多 ）。K8s 是云原生方式，多语言、多程序入口，应用、运维部署、配置解耦；Ray 是单语言、单程序入口，应用、运维部署、配置融为一体。

Ray 的核心层（Ray Core）是使用 Ray 的基础，该层较为轻薄，可部署在 AWS、Google Cloud、K8s 等多种环境中，减轻了使用负担。基于 Ray Core 构建的上层组件对于实现 Ray 的功能至关重要，它们在 AI 相关的各个环节，如数据处理、模型训练、调试和服务部署等方面，都提供了对应的解决方案，共同构成了 Ray 丰富的生态系统。