[Python/AI/分布式计算] Ray 框架：AI 时代的通用分布式计算引擎

0 序

定位：Ray 是"以 AI 为中心的通用分布式计算引擎"——用一套 Python 原生的 Task/Actor/Object 抽象，把数据、训练、调优、推理、强化学习等 AI 负载统一到同一个计算底座上；它既不是批处理引擎（Spark），也不是流处理引擎（Flink），更不是存储系统（Fluss），而是可承载这些框架的"AI 计算层"。

1 概述

产品介绍

产品定位：Ray 是一个开源的统一框架（unified framework），用于扩展 AI 与 Python 应用（尤其是机器学习）。它提供并行处理的计算层，使开发者无需成为分布式系统专家，即可将单机 Python 代码无缝扩展到多节点集群。

诞生的背景与原因：Ray 诞生于 UC Berkeley RISELab（2015 年前后启动）。核心动因是——当时的分布式框架（MapReduce/Spark）面向批量同步并行（BSP）设计，无法高效承载强化学习（RL）等新兴 AI 负载：这类负载由海量短生命周期任务（如环境模拟）与长运行有状态计算（如模型训练）混合构成，且计算图是动态、异构、异步的。研究人员在 Spark 上尝试跑 RL 时发现"Spark 的形状不对"（Spark 是静态 DAG + 粗粒度血统），于是从零设计了 Ray。

解决的核心问题：在 Ray 出现之前，一条 ML 流水线往往要拼装多套系统——Spark 处理数据、Horovod 做分布式训练、Celery 跑异步任务、K8s 部署推理服务。这带来三重痛点：

①多套系统的学习与运维成本叠加；

②系统间数据交换依赖磁盘/网络序列化，额外开销大；

③Python 缺少细粒度分布式原语。Ray 用 @ray.remote 一个装饰器 + Task/Actor/Object 三个抽象，把整条链路收敛到"一套代码、一个系统"。

URLs：

发展历程

时间 里程碑
2015–2016 作为 UC Berkeley RISELab 研究项目启动，由 Robert Nishihara、Philipp Moritz、Ion Stoica 主导
2017-05 首个公开版本 v0.1 发布
2017 论文《Ray: A Distributed Framework for Emerging AI Applications》发表于 arXiv（OSDI 2018）
2019 Anyscale 公司成立（Nishihara、Moritz、Stoica，Michael Jordan 任创始/顾问），推进 Ray 商业化
~2019-2021 早期大规模生产用户：蚂蚁集团（首个重要生产环境用户）、Uber、Pinterest 等
2022-08 Ray 2.0 发布：引入 Ray AI Runtime（AIR）、KubeRay Operator、原生支持 100TB+ 数据 shuffle、增强 Dashboard
2025-10-22 Ray 加入 PyTorch 基金会（Linux Foundation 旗下），与 PyTorch、vLLM 并列成为基金会托管项目；当时累计下载量 2.37 亿次（同比近 10 倍增长）
2026-03 Google Cloud TPU 成为 Ray 一等公民加速器
2026-07-30 英国 AI 云公司 Nscale 宣布收购 Anyscale，据彭博社报道交易额约 16.5 亿美元（官方未确认金额），整合 AI 全栈
2026-08-23 最新稳定版 Ray 2.58.0 发布；Windows 支持进入 beta

主要功能

Ray 由三层构成：Ray AI Libraries（上层 AI 库）+ Ray Core（核心运行时）+ Ray Clusters（集群层）。

Ray Core（底层分布式计算底座）

  • Task（任务）：任意 Python 函数加 @ray.remote 即成为可异步执行的远程任务，可声明 CPU/GPU/自定义资源需求。
  • Actor（参与者）：有状态常驻服务（类加 @ray.remote），方法串行执行、跨调用保持状态，适合承载模型权重、连接池等。
  • Object / ObjectRef（分布式对象）：不可变对象存于分布式共享内存对象存储，跨节点通过 ObjectRef 零拷贝引用。
  • Placement Group：跨节点原子化预留资源组，支持 PACK/SPREAD 摆放，用于 gang-scheduling。
  • runtime_env：按任务/作业动态安装 Python 依赖、注入文件与环境变量。
  • 容错与弹性：血统重建（Lineage Reconstruction）、Actor 重启、对象溢出（Object Spilling 至磁盘/S3）、自动扩缩容（Autoscaler）。

Ray AI Libraries（五大原生库）

  • Ray Data：框架无关的可扩展数据加载与转换（面向 ML 训练/推理的流式批处理）。
  • Ray Train：多节点多卡分布式训练，内置容错，深度集成 PyTorch / TF / JAX / XGBoost / HuggingFace 等。
  • Ray Tune：可扩展超参调优，支持 ASHA、PBT 等调度器与 Optuna 等搜索算法。
  • Ray Serve：可编程的在线模型服务，支持动态批处理、模型组合、多模型复用，并可服务大模型（vLLM / SGLang 集成、Prefill/Decode 分离、KV Cache 卸载等）。
  • Ray RLlib：分布式强化学习库，覆盖主流算法与多智能体场景。

Ray Clusters（集群与部署）

  • 支持单机 → 多节点 → 云（AWS/GCP/Azure）→ 本地 → K8s（KubeRay CRD：RayCluster / RayJob / RayService / RayCronJob）→ YARN / Slurm。
  • 提供 Dashboard（观测、调试、profiling）、Ray Jobs CLI / SDK / REST API、Prometheus/Grafana 监控等。

生态集成

  • 可把其他框架"跑在 Ray 上"：RayDP（Spark on Ray）、Dask on Ray、Modin（Pandas on Ray）、Joblib/Sklearn 分布式、Mars on Ray 等。
  • 支持 Python / Java / C++ 多语言调用。

核心优势

  1. 一套 API 覆盖全 ML 生命周期：数据 → 训练 → 调优 → 推理 → RL 统一到同一套抽象，端到端无需切换系统；同一份 Python 代码从笔记本平滑跑到大集群。
  2. 动态、异构、细粒度的计算图：天然支持异步、异构（CPU/GPU/TPU）、细粒度并行与动态任务编排，这是 Spark/Flink 静态 DAG 不具备的能力。
  3. Python 原生 + 深度融入 AI 生态：与 PyTorch / TensorFlow / JAX / HuggingFace / vLLM 无缝集成，面向 Python 开发者而非 SQL 用户。
  4. 自下而上（Bottom-up）+ Spillback 的分布式调度：任务先在本地节点就近调度，资源不足再溢出到远端，单机场景任务提交开销亚毫秒级，避免中心调度器瓶颈。
  5. 共享内存对象存储 + 零拷贝：同节点多 Worker 零拷贝共享大对象（尤其 numpy/tensor），大幅降低数据搬运开销。
  6. 异构硬件与细粒度资源：支持 fractional GPU、自定义资源、TPU/GB200 等新一代加速器的一等资源建模。
  7. 容错与弹性：细粒度血统重建、Actor 自动重启、对象 LRU 溢出、集群自动扩缩容。
  8. 开放治理 + 极活跃社区：加入 PyTorch 基金会实现中立治理，GitHub 4.3 万+ Star、下载量 2.3 亿+，已被 OpenAI、xAI、Cursor、蚂蚁、Uber、Pinterest、Bilibili 等大规模采用。

主要短板

  1. Windows 支持仍为 beta：官方以 Linux（x86_64/aarch64）为主，Windows 用户体验与文档完整性弱于 Linux。
  2. 没有 SQL：Ray Core / Ray Data 不提供 SQL 接口（对比 Spark SQL / Flink SQL），面向 SQL/BI 用户不友好。
  3. 流处理能力尚不成熟：Anyscale 官方对比表标注 Ray 的流处理为"Coming Soon"——它不是真正的流引擎，原生不提供 exactly-once、checkpoint、事件时间等语义。
  4. ETL/分析能力弱于 Spark：无 Catalyst 式优化器、无成熟的 SQL/DataFrame 关系优化，复杂 join/聚合的批处理性能与工具链（BI、数据湖、Hadoop 生态）不如 Spark。
  5. API 灵活但学习曲线陡：低层原语能力强的同时，需要使用者自己组装复杂逻辑；高层库（如 Ray Data）API 仍在快速演进，版本间有迁移成本。
  6. Actor 状态不自动容错：Actor 崩溃后虽会重启进程，但内部状态不保证恢复，业务级容错需自行实现 checkpoint。
  7. 商业化依赖单一公司历史：Anyscale 是主要推动者，虽已捐入基金会并随 Nscale 收购，但商业公司集中度仍是潜在风险点（好消息是项目治理已中立化）。

局限性

  • 不是实时流处理引擎：亚秒级延迟、状态流计算（exactly-once、watermark、event-time）请用 Flink。
  • 不是数仓 / SQL 引擎：纯离线数仓、复杂 BI 分析场景，Spark 生态更成熟。
  • 不提供持久化存储：对象存储是易失的内存存储（可溢出到磁盘/S3，但定位不是数据库/消息队列）；流式数据持久化应交给 Kafka / Fluss / Paimon 等。
  • 不是调度器：Ray 自带资源调度与自动扩缩容，但大型组织的统一队列调度/多租户治理仍常与 K8s / Volcano / YuniKorn / Kueue 结合使用。
  • 极端大规模 HPC 训练：超大规模集群的集合通信/专用网络场景，MPI + 专用库仍有优势。

适用场景

  • 大模型/深度学习的分布式训练与微调（数据并行、张量并行、流水并行编排）
  • 批量推理（CPU/GPU 离线推理）与在线模型服务（Ray Serve，含 LLM serving、RAG、多模型组合）
  • 超参调优与大规模实验管理（Ray Tune）
  • 强化学习（RLlib，含 RLHF 等训练后对齐）
  • 端到端 ML 流水线：数据预处理 → 训练 → 调优 → 部署推理，在一个系统内闭环
  • 将现有单机 Python 代码并行化（multiprocessing/joblib 的分布式替代）
  • AI Agent / 向量检索 / 多模态数据处理等新兴 AI 应用
  • 作为通用分布式底座承载其他框架（Spark on Ray / Dask on Ray / Modin 等）

同类竞品

竞争者 定位 与 Ray 的关系
Dask Python 分布式并行库 最直接竞争对手，共享"Python 原生并行"心智，但 Dask 更偏数据并行/调度，Ray 更偏 AI 全栈 + actor 模型
Apache Spark 批处理 + SQL 数据分析 数据/ETL 场景互补，Ray 通过 RayDP 把 Spark 跑在自己之上
Apache Flink 真正的流处理引擎 实时流计算场景互补，Flink 是流处理标杆，Ray 侧流处理尚在演进
Horovod 分布式训练 训练层面重叠，Ray Train 集成或替代之
Celery / Airflow 异步任务 / 工作流编排 任务编排层面部分重叠（Ray 提供更底层的分布式执行，Airflow 负责 DAG 编排）
vLLM / Triton / KServe 推理服务 服务层面部分重叠；Ray Serve 可与 vLLM 集成互补
MLflow / Kubeflow ML 平台/工作流 平台层部分重叠，常与 Ray 组合使用

发展趋势

社区活跃度（2026-09-03 GitHub 实时数据）

  • Star：43,688（GitHub 最活跃的 AI 基础设施项目之一）
  • Fork：7,996
  • Commit：31,583，Open Issues：约 2,900，Contributors：数千级
  • 发布节奏：高频迭代（2026 年内已发布 2.55 / 2.56 / 2.57 / 2.58 等版本），PyPI 累计下载量 2.3 亿+ 且同比近 10 倍增长

总结：Ray 正从"通用分布式计算框架"演进为 AI 计算引擎（AI Compute Engine）——随 LLM 训练/推理与 AI Agent 爆发成为开源 AI 技术栈的计算层标配，并通过 PyTorch 基金会实现中立治理、借 Nscale 收购完成 AI 云全栈整合，但与此同时也在主动补齐流处理（如 Ray Data 流式、编译图 API）以向 Spark/Flink 的领地延伸。

2 Ray 与 Flink / Spark / Fluss 的关联关系、本质区别与核心优势

本章为本次调研的补充重点。

结论先行：四者处于"数据栈"的不同层，本质上是【互补】而非【替代关系】——Ray（AI 计算层）、Spark（批处理/SQL 计算层）、Flink（流处理计算层）是"算"的引擎；Fluss 是"存/流"的存储层。

真正会被放在一起 PK 的，是 Ray 与 Spark/Flink 在"谁做 AI/数据计算"上的边界，以及 Ray 与 Fluss 在"实时 AI 数据底座"上的协同。

2.1 定位总览：四个系统各是什么

系统 一句话定位 类型 主要语言 治理组织
Ray AI 计算引擎（通用分布式计算，面向 AI/ML） 计算引擎（范式无关） Python（原生）/ Java / C++ PyTorch 基金会（Linux Foundation）
Apache Spark 大规模批处理 + SQL 数据分析引擎 计算引擎（BSP 批处理） Scala / Java / Python / SQL Apache
Apache Flink 真正的流处理引擎（批视为流的特例） 计算引擎（流式 Dataflow） Java / Scala / Python / SQL Apache
Apache Fluss Lakehouse 原生流式存储（消息+KV+状态+湖仓冷存储合一） 存储层（非计算引擎） Rust / Java（服务端） Apache（2026-07 毕业为顶级项目）

2.2 关联关系：它们如何协作

（1）Ray × Spark：可"上下叠放"的血缘兄弟

  • 血缘：两者都诞生于 UC Berkeley——Spark 出自 AMPLab（2009，现 Databricks 商业化，创始人 Ion Stoica 同时是 Ray/Anyscale 创始人），Ray 出自 RISELab（2017），同一师门、同一设计哲学（语言集成 API + 中央控制面 + 血统容错）。
  • 协作方式：
    • 管线串联：Spark 做离线 ETL/特征工程 → 产出表/文件 → Ray 做训练/推理，互为上下游节点。
    • RayDP（Spark on Ray）：Spark 的 Executor 以 Ray Actor 形式运行在 Ray 集群上，通过 Ray Object Store 实现 Spark DataFrame 与 Ray Dataset 之间零拷贝互转，在一个 Python 程序里同时写 PySpark 与 Ray。
    • Databricks 官方支持同一环境内串联 Ray 与 Spark（配合 Delta Lake / Unity Catalog）。
  • 本质：Ray 把 Spark 视为自己生态里的一个"库"，反向用 Ray 的对象存储与调度来增强 Spark。

（2）Ray × Flink：流计算与 AI 计算的分工协作

  • 协作方式：
    • Flink 做实时流处理（状态、checkpoint、exactly-once、窗口、CEP），产出特征/实时结果 → 交给 Ray 做实时推理、训练或在线服务。
    • 阿里云等厂商探索"Flink 实时特征 + Ray 模型推理"的实时 ML 组合（Flink 写 Kafka → Ray 消费推理）。
    • 存在将 Flink 运行在 Ray 集群上的项目（Flink on Ray），复用 Ray 的资源管理/弹性。
  • 本质：Flink 是"流处理标杆引擎"，Ray 是"AI 计算引擎"，二者在实时智能（实时数仓 + 实时 AI）场景互补；Ray 自身的流处理能力尚不成熟，因此真实的低延迟流式计算仍首选 Flink。

（3）Ray × Fluss：计算引擎 × 实时数据存储底座

  • 协作方式：
    • Fluss 官网将 Ray 列为其支持的查询/消费引擎之一：Ray 可直接读取 Fluss 的流式数据（Log Table 的 changelog 流、PK Table 的实时视图），用于特征工程、实时推理、训练数据供给。
    • Fluss Roadmap 明确规划"高性能 Rust/Python SDK，集成 PyTorch、Ray、Pandas、PyArrow"——即在数据平面直接打通 AI 生态。
    • 在"实时 AI/Agentic 数据底座"愿景里：Fluss 提供流式存储（消息 + 在线 KV + 湖仓冷存储 + 向量），Ray 提供 AI 计算（训练 + 推理 + Agent 编排），Flink/Spark 提供流批计算，四者构成完整栈。
  • 本质：Fluss 是"存"，Ray 是"算"——两者不竞争，Fluss 解决的是"实时数据从哪来、如何统一可读"，Ray 解决的是"拿到数据后怎么算、怎么训练推理"。

一图看关联

flowchart LR subgraph Storage["存储 / 流式数据层"] Fluss[Apache Fluss<br/>流式存储 + KV + 湖仓冷存储] Kafka[Kafka / 消息队列] Lake[(数据湖 Paimon/Iceberg/Hudi)] end subgraph Compute["计算层"] Spark[Spark<br/>批处理/SQL] Flink[Flink<br/>流处理] Ray[Ray<br/>AI 训练/推理/调优/RL] end subgraph AI["AI 应用层"] LLM[LLM / Agent / RAG / 实时推理] end Fluss -- "Flink/Spark/Ray 统一消费" --> Compute Flink -- "CDC/实时 ETL" --> Lake Fluss -- "Tiering 分层" --> Lake Spark -- "RayDP 跑在 Ray 上" --> Ray Flink -- "实时特征 → AI" --> Ray Ray --> LLM

2.3 本质区别（多维度对比）

维度 Ray Apache Spark Apache Flink Apache Fluss
本质 通用分布式计算引擎（AI 优先） 批处理 + SQL 分析引擎 流优先的流批一体引擎 流式存储系统
核心抽象 Task / Actor / Object RDD / DataFrame / Dataset DataStream / State / Checkpoint Log Table / PK Table（KV + Log 双视图）
计算图 动态、异步、可变的图 静态 DAG（BSP 阶段化） 静态 Dataflow 图（流式算子） 无计算图（纯存储）
并行粒度 细粒度（单任务/单 Actor） 粗粒度（Stage/Job） 中细粒度（算子并行度） N/A（存储侧分桶）
范式绑定 不绑定任何范式（可承载任意范式） 绑定 BSP 批处理 绑定流式 Dataflow N/A
语言 / API Python 原生，Java/C++ Scala/Java/Python/SQL Java/Scala/Python/SQL 客户端 SDK / Flink-SQL 优先
SQL 支持 ❌ 无 ✅ Spark SQL（成熟） ✅ Flink SQL（成熟） 通过引擎间接提供
流处理语义 弱（流能力演进中，无原生 exactly-once/event-time） 中（Structured Streaming，微批/持续） 强（状态管理 + checkpoint + exactly-once + watermark/CEP） 存储侧支持流式读写（changelog）
状态管理 Actor 内存态（不自动容错） 阶段内状态（宽依赖 shuffle） 一等公民（Keyed State + 可插拔状态后端） 内置状态/在线 KV 存储（供计算引擎外置状态）
容错 血统重建 + Actor 重启 + 对象溢出 血缘 + 任务重试 + shuffle 恢复 checkpoint + 状态恢复（精确一次） 副本 + WAL + Tiering（存储级持久化）
数据形态 非结构化/多模态优先（图像、文本、向量、模型） 结构化/半结构化优先（表、SQL） 流式事件流 流式列式数据 + KV + 向量
硬件 异构（CPU/GPU/TPU/自定义） 以 CPU 集群为主 CPU 为主（可配 GPU） 存储节点（CPU/内存/磁盘）
典型时延 亚秒~秒级（调度） 秒~分钟级（批） 毫秒~秒级（流） 毫秒级读写（存储侧）
定位关键词 训练、推理、调优、RL、AI 全栈 ETL、数仓、BI、批分析 实时数仓、实时风控、CEP 实时数据底座、湖流一体、实时 AI 数据层

2.4 各自核心优势

  • Ray 的核心优势：①AI 全生命周期一站式（数据→训练→调优→服务→RL 一套 API）；②动态/异构/细粒度计算 + Python 原生；③与 PyTorch/vLLM 等 AI 生态深度融合；④低延迟分布式调度 + 零拷贝对象存储；⑤作为"可承载其他引擎的底座"（Spark on Ray 等）。
  • Spark 的核心优势：①成熟 SQL/DataFrame 与 Catalyst/Tungsten 优化，复杂 ETL/join/聚合高效；②Hadoop 生态与 BI/数据湖工具链完善；③社区与生产案例规模全球第一梯队；④批处理吞吐与稳定性经过 10+ 年打磨。
  • Flink 的核心优势：①真流式处理，毫秒级低延迟；②一等状态管理 + checkpoint 精确一次；③事件时间、watermark、乱序处理、CEP 等流语义完备；④流批一体（批是流的特例）。
  • Fluss 的核心优势：①Lakehouse 原生：流存储直接对接 Paimon/Iceberg/Hudi/Lance，热冷一体、Union Read；②一个系统替代 Kafka（消息）+ KV（在线）+ 状态后端 + 湖仓冷存储，消除多系统同步开销；③列式（Arrow）+ 服务端裁剪/谓词下推，I/O 效率高；④为实时 AI 提供在线特征/向量/上下文一体存储。

2.5 选型建议（面向大数据架构师）

你的核心诉求 首选 说明
离线 ETL / 数仓 / BI / SQL 分析 Spark 生态与优化器最成熟
毫秒级实时流计算（风控、实时数仓、CEP） Flink 状态与精确一次是硬实力
大模型训练 / 微调 / 推理服务 / 超参调优 / RL / Agent Ray AI 计算层事实标准
实时数据底座（消息 + 在线 KV + 湖仓冷存储统一） Fluss 供给上表各计算引擎
实时 ML 流水线（实时特征 + 在线推理） Flink + Fluss + Ray 三层协同，各司其职

关键判断：Ray 与 Spark/Flink 不是"你死我活"，而是"按负载分层"。

真实生产往往是 Fluss（或 Kafka）做数据底座，Flink 做实时计算，Spark 做离线批分析，Ray 做 AI 训练/推理/Agent，四者组合成现代实时数据 + AI 平台。

3 工作原理与架构

概念术语

术语 含义
Task @ray.remote 修饰的远程函数，无状态，是调度的基本单位
Actor @ray.remote 修饰的类实例化出的常驻有状态进程（服务）
Object / ObjectRef 分布式共享内存对象存储中的不可变对象；ObjectRef 是其句柄/引用
Driver 提交任务、创建 Actor 的客户端入口进程
GCS（Global Control Service） 集群级中央元数据服务（节点健康、Actor 位置、Job/PG 元数据）
Raylet 每节点守护进程，内含 Node Manager（调度）+ Object Manager（对象管理）
Object Store 节点内共享内存对象存储（早期为独立 Plasma，Ray 2.x 起内嵌于 Raylet）
Placement Group 跨节点原子预留资源组（PACK/SPREAD）
Spillback 本地资源不足时把任务溢出调度给远端节点的机制
runtime_env 作业级环境依赖（Python 包、文件、环境变量）的运行时注入
Object Spilling 对象超出内存时按 LRU 异步序列化到磁盘/云存储
Lineage Reconstruction 基于对象血统在节点故障后重新计算丢失对象的容错机制

总体架构

Ray 采用"中心化控制面 + 去中心化数据面"的混合架构：

flowchart TB subgraph Head["Head Node"] GCS[GCS<br/>集群元数据服务] RHead[Raylet] D[Driver] end subgraph W1["Worker Node 1"] R1[Raylet] O1[(Object Store)] A1[Worker] A2[Worker] AC1[Actor] end subgraph W2["Worker Node 2"] R2[Raylet] O2[(Object Store)] A3[Worker] AC2[Actor] end GCS <--> RHead GCS <--> R1 GCS <--> R2 R1 <--> O1 R2 <--> O2 O1 <-.P2P 对象传输.-> O2
  • Head Node：运行 GCS、头节点 Raylet、Driver；GCS 保存集群级元数据（早期基于 Redis，现已自研服务）。
  • Worker Node：每个节点运行一个 Raylet + 共享内存对象存储 + 若干 Worker 进程（执行 Task）与 Actor 进程（有状态服务）。
  • 通信：GCS↔Raylet 为控制面（星形）；节点间对象传输走 P2P（Object Manager 直接从远端拉取，不经 GCS 中转）。

运行原理与关键技术

1. 自下而上（Bottom-up）调度 + Spillback

与 Hadoop/Spark 的"中心调度器自上而下分配"不同：Driver 先把任务提交给本地 Raylet，本地优先就近执行（利用数据本地性、亚毫秒级开销）；本地资源不足或依赖在远端时，任务溢出（Spillback）给有剩余资源的远端 Raylet。该机制在保持低延迟的同时避免了中心调度器成为瓶颈。

2. 所有权模型（Ownership Model）与分布式 GC

创建 Task 的 Worker"拥有"其返回 ObjectRef，负责该对象的位置、生命周期、失败重试与 GC。当 Python 层引用计数归零，Owner 通知所在 Raylet 从对象存储删除对象。对象总量超内存时按 LRU 溢出到磁盘/S3，对上层透明。

3. 容错机制

  • 数据容错（血统重建）：无状态 Task 因节点宕机丢失 Object 时，Owner 依据血统重新提交任务重算。
  • 计算容错（Actor 重启）：Actor 所在节点宕机后，GCS 通过心跳检测并在其他节点重新调度该 Actor——但不保证内部状态恢复，业务级容错需开发者配合 checkpoint 实现。

4. 共享内存对象存储与零拷贝

同节点不同 Worker 读取同一对象时，numpy/tensor 等基于缓冲区对象可零拷贝访问；一般 Python 对象仍需反序列化。这对海量数据与模型预加载场景尤为关键。

5. 执行模型本质

Ray 的任务执行是图驱动 + 依赖自动调度：Task 间无需直接通信，只需引用彼此输出的 ObjectRef 即建立依赖，调度器据此自动决定执行顺序与数据放置。这种"进程级原语 + 动态图"正是它与 BSP（Spark）/ Dataflow（Flink）的本质分野——Ray 本身不绑定任何计算范式，可承载任意范式。

4 使用指南

安装部署

环境要求：Linux x86_64 / aarch64、macOS（Apple Silicon）为官方支持；Windows 目前为 beta；需 Python ≥ 3.10。

pip 安装（推荐）

# 仅核心
pip install -U "ray"
# 核心 + Dashboard + Cluster Launcher（通用 Python 应用）
pip install -U "ray[default]"
# 机器学习应用（数据+训练+调优+推理）
pip install -U "ray[data,train,tune,serve]"
# 强化学习
pip install -U "ray[rllib]"
# 全部组件（不推荐，按需指定 extras 更好）
pip install -U "ray[all]"

可组合 extras，如 pip install -U "ray[default,train]"。

conda-forge（Linux / Windows）

# 基于 conda 新建 python 环境，并激活 | `--channel`，指定软件源通道（conda‑forge 社区源包）; `--name`，指定 conda 环境名称(ray)
conda create -c conda-forge python=3.10 -n ray && conda activate ray

conda install -c conda-forge "ray-default"   # 含 Dashboard + Cluster Launcher

# 从 `conda‑forge` 源安装 Ray 的几个子模块库：`ray‑data`/Ray 的数据处理、`ray‑train`/模型训练、`ray‑tune`/超参调优、`ray‑serve`/服务部署
conda install -c conda-forge "ray-data" "ray-train" "ray-tune" "ray-serve"

注：conda 包由社区维护，官方建议在 conda 环境内仍用 pip install ray。

Docker

docker run --shm-size=<shm-size> -t -i rayproject/ray

关键操作

本地快速启动与验证

import ray

ray.init()                     # 启动本地集群（本机所有核）
# ray.init(address="ray://<head>:10001")   # 连接已有集群

@ray.remote
def f(x):
    return x * x

futures = [f.remote(i) for i in range(10)]
print(ray.get(futures))        # [0, 1, 4, ..., 81]

@ray.remote
class Counter:
    def __init__(self):
        self.n = 0
    def inc(self):
        self.n += 1
        return self.n

c = Counter.remote()
print(ray.get(c.inc.remote())) # 1

命令行（Head / Worker 集群）

ray start --head --port=6379          # 启动 head 节点
ray start --address=<head-ip>:6379    # 在 worker 节点加入集群
ray status                            # 查看集群状态
ray job submit --working-dir . -- python train.py   # 提交作业
# Dashboard 默认 http://localhost:8265

Kubernetes 部署：使用 KubeRay Operator，提供 RayCluster / RayJob / RayService / RayCronJob 等 CRD，支持 GPU、TPU、gang-scheduling（与 Volcano / Kueue / YuniKorn 集成）。

Z FAQ for Ray

Q: Ray 和 Spark 能共存吗？会不会冲突？

能，且被官方支持。二者定位不同：Spark 强在批处理/SQL/ETL，Ray 强在 AI 训练/推理。可通过 RayDP 让 Spark 运行在 Ray 上（Executor 变 Ray Actor、对象存储零拷贝互转），或管线串联（Spark 产出特征 → Ray 训练推理）。Databricks 也在同一环境内同时支持 Ray 与 Spark。

Ray 提供 Ray Data 的流式/批式数据处理，也有流式生成器、编译图 API 等演进方向，但其定位不是流处理引擎：原生不提供 exactly-once、checkpoint、事件时间/watermark、CEP 等流语义（Anyscale 官方对比表也将 Ray 的流处理标为"Coming Soon"）。亚秒级、有状态、精确一次的真实流计算应使用 Flink；Ray 更擅长"消费流数据后的 AI 计算"。

Q: Ray 和 Fluss 是什么关系？

存储 × 计算的互补关系。Fluss 是流式存储系统（数据底座），Ray 是 AI 计算引擎；Fluss 将 Ray 列为其查询/消费引擎之一，并在 Roadmap 中规划面向 PyTorch/Ray/Pandas 的高性能 Rust/Python SDK。二者组合可构建"实时数据 → 实时特征 → 在线推理"的实时 AI 链路。

Q: Ray 的 Actor 崩溃后状态会丢失吗？

会。Actor 崩溃后 Ray 会重启进程，但不恢复其运行时内部状态（成员变量）。需要业务级容错时，应自行实现 checkpoint/持久化（Ray Train/Serve 提供相关机制辅助）。

Q: Ray 支持哪些语言？

原生 Python，另提供 Java API 与 C++ API；Java/Python 版本号需保持一致。多语言可互相调用。

Q: Ray 在 Windows 上能用吗？

处于 beta 支持阶段。官方推荐 Linux（x86_64 / aarch64）与 macOS（Apple Silicon）；Windows 可用 pip install ray 跑核心功能，但部分高级特性与集群部署体验有限。

Q: Ray 收费吗？

开源免费（Apache 2.0，核心托管于 PyTorch 基金会）。Anyscale 是其商业化托管平台（2026-07 被 Nscale 收购），提供托管控制面/企业功能；开源 Ray 本身无许可费用。

Q: Ray 的现状地位如何？还值得投入学习吗？

非常值得。Ray 是当前开源 AI 基础设施的事实计算层：GitHub 4.3 万+ Star、下载量 2.3 亿+，OpenAI、xAI、Cursor、蚂蚁、Uber、Bilibili 等大规模使用；2025 年加入 PyTorch 基金会、2026 年被 Nscale 以约 16.5 亿美元收购，均说明其在 AI 技术栈中的战略地位持续上升。

Y 推荐文献

X 参考文献

posted @ 2026-09-04 01:01  千千寰宇  阅读(53)  评论(0)    收藏  举报