Ray（分布式统一计算框架）

3 秒看懂

Ray 是一个开源分布式计算框架，由 UC Berkeley RISELab 孵化，旨在为 AI/ML 全生命周期（数据处理→训练→调参→服务）提供统一的编程接口和集群调度层。 它不是训练框架本身（不替代 PyTorch/TensorFlow），而是在其之上的”分布式操作系统”——把单机 Python 代码几乎原封不动地扩展到数千节点集群。商业公司 Anyscale 围绕 Ray 构建商业化产品，OpenAI 等头部 AI 实验室被多方报道为深度用户。

3 分钟产业解释

为什么需要 Ray？

在大模型时代，一个典型的 AI 工作流至少涉及 4 个独立环节：

传统方案的痛点在于：每个环节需要独立的集群、独立的调度器、独立的序列化/通信协议，运维复杂度随规模呈超线性增长。

Ray 的核心价值主张：用一套统一的运行时和 API 覆盖以上所有环节，共享同一个集群资源池，通过自动扩缩容和细粒度调度降低成本。

产业位置

┌──────────────────────────────────────────────────────┐
│                    应用层 (LLM/推荐/RLHF...)          │
├──────────────────────────────────────────────────────┤
│         ML 框架层 (PyTorch / TensorFlow / JAX)        │
├──────────────────────────────────────────────────────┤
│     ★ Ray: 分布式编排 & 统一计算运行时 (本页) ★       │
│     (Ray Core → Ray Data/Train/Tune/Serve/RLlib)     │
├──────────────────────────────────────────────────────┤
│         资源管理层 (Kubernetes / YARN / 云 API)        │
├──────────────────────────────────────────────────────┤
│              硬件层 (GPU/TPU/InfiniBand/NVLink)       │
└──────────────────────────────────────────────────────┘

Ray 位于 ML 框架与集群资源管理之间，是”AI 时代的中间件”。

15 分钟专家深入

历史脉络

注：OpenAI 使用 Ray 的信息来自多家行业媒体报道及 Anyscale 公开引用，OpenAI 自身未正式发布详细技术栈白皮书确认全部细节。

创始团队的学术谱系

Ray 背后的核心团队与以下实验室/项目有直接传承关系：

• AMPLab → Apache Spark、Apache Mesos
• RISELab → Ray、Clipper（早期模型服务系统）
• Ion Stoica 是 Spark 和 Ray 的共同导师级人物

这意味着 Ray 在分布式调度理论、Actor 模型、共享内存对象存储方面有深厚学术积累。

技术原理（深度机制层）

1. 核心架构

                        ┌─────────────────────────┐
                        │       Driver（用户进程）    │
                        │   提交 task / 创建 actor   │
                        └──────────┬──────────────┘
                                   │ gRPC
                        ┌──────────▼──────────────┐
                        │  GCS (Global Control     │
                        │  Store) — 全局元数据中心    │
                        │  · Actor 表 · Placement   │
                        │  · 资源视图 · 失败恢复      │
                        └──────────┬──────────────┘
                                   │
              ┌────────────────────┼────────────────────┐
              │                    │                    │
     ┌────────▼────────┐  ┌───────▼───────┐  ┌────────▼────────┐
     │    Head Node     │  │  Worker Node  │  │  Worker Node    │
     │  (GCS Server +   │  │               │  │                 │
     │   Dashboard)     │  │  ┌─────────┐  │  │  ┌─────────┐    │
     │                  │  │  │ Raylet  │  │  │  │ Raylet  │    │
     │                  │  │  │(本地调度+ │  │  │  │(本地调度+│    │
     │                  │  │  │ 资源管理) │  │  │  │ 资源管理)│    │
     │                  │  │  ├─────────┤  │  │  ├─────────┤    │
     │                  │  │  │Plasma   │  │  │  │Plasma   │    │
     │                  │  │  │Object   │  │  │  │Object   │    │
     │                  │  │  │Store    │  │  │  │Store    │    │
     │                  │  │  │(共享内存) │  │  │  │(共享内存)│    │
     │                  │  │  └─────────┘  │  │  └─────────┘    │
     │                  │  │  Worker 进程   │  │  Worker 进程    │
     └──────────────────┘  └───────────────┘  └─────────────────┘

2. 两种编程原语：Task 与 Actor

这是 Ray 的核心抽象，直接映射到分布式执行：

Task（无状态远程函数）：

@ray.remote
def process_data(data):
    # 无状态，可被任意调度到任何 worker
    return heavy_computation(data)

# 提交远程任务，返回 ObjectRef（future）
ref = process_data.remote(data)
# 按需获取结果
result = ray.get(ref)

Actor（有状态远程对象）：

@ray.remote
class ParameterServer:
    def __init__(self, model):
        self.model = model
    def update(self, gradients):
        self.model.apply_gradients(gradients)
    def get_weights(self):
        return self.model.get_weights()

# 在集群中创建一个有状态的 Actor 实例
ps = ParameterServer.remote(model)
ps.update.remote(gradients)

关键设计决策：

• Task 通过 Ray 的分布式调度器全局调度，适合数据并行的无状态计算
• Actor 绑定到特定节点，维护状态（如模型权重、环境状态），适合有状态的服务或 RL 环境
• 两者都通过 ObjectRef（类似 future/promise）进行异步数据流编排

3. 分布式对象存储（Plasma）

Ray 内嵌了一个基于共享内存的分布式对象存储（源自 Apache Arrow 的 Plasma 项目）：

• 节点内：通过共享内存（shared memory）实现零拷贝数据传递——同一节点上的 Task/Actor 直接读取共享内存段，避免序列化/反序列化开销
• 节点间：当某个 ObjectRef 对应的数据不在本地时，Raylet 自动从远程节点拉取
• 对象不可变：一旦写入 Plasma 的对象不可修改（immutable），这简化了一致性模型，但也是设计约束

这正是 Ray 相比纯消息传递框架的核心性能优势：大量 AI 工作负载涉及大型 NumPy/PyTorch 张量在不同计算步骤间传递，共享内存零拷贝可带来数量级的延迟降低。

4. 调度架构

Ray 采用两层调度：

性能优化：对于本地可满足的任务，Raylet 直接在本地调度，绕过全局调度器以降低延迟。这是 Ray 能支撑毫秒级小任务的关键。

5. 自动扩缩容（Autoscaler）

Ray 内置集群 Autoscaler：

• 监控任务队列深度和资源利用率
• 自动向底层资源管理器（Kubernetes、云 API）申请/释放节点
• 支持对 Ray on K8s (KubeRay) 的原生集成

6. Ray AI 库栈（Ray 2.x）

┌────────────────────────────────────────────────────┐
│  Ray Serve          │  Ray Train   │  Ray Tune     │
│  (模型服务推理)       │  (分布式训练)  │  (超参搜索)    │
├────────────────────────────────────────────────────┤
│              Ray Data（分布式数据管道）                │
│         · 流式读取 · 映射/转换 · 与 Train 无缝衔接     │
├────────────────────────────────────────────────────┤
│              Ray Core（Task/Actor/Object Store）     │
├────────────────────────────────────────────────────┤
│              Cluster Manager / Autoscaler           │
└────────────────────────────────────────────────────┘

Ray Train 本身不做梯度计算——它是一个编排层，负责：

• 设置分布式环境变量
• 在多个 Worker 上启动 PyTorch DDP / DeepSpeed / HuggingFace Accelerate 等
• 管理 checkpointing、容错、弹性训练

Ray Serve 的特点：

• 支持复杂 DAG 部署（多模型 pipeline、shadow testing、A/B 测试）
• 动态批处理（dynamic batching）
• 可独立扩展每个模型副本
• 与 Ray Core 的 Actor 模型深度整合——每个 Serve Replica 就是一个 Ray Actor

技术演进史

关键架构变迁：

• Ray 1.x → 2.x：GCS 从 Redis-based 演进为内置 GCS Server（减少外部依赖、提升可靠性）；Ray Data 从实验性质变为数据-训练-服务统一管线的核心

技术路线对比

总结：Ray 的独特定位是 “Python-native + 细粒度任务 + 有状态 Actor + ML 全栈”。Spark 主导大数据 ETL；Dask 是轻量 Python 并行；Kubeflow 是 K8s 上的 ML pipeline 编排工具集；Ray 尝试用一个运行时统一以上场景。

上下游

上游依赖

下游消费者

关键指标

供需与市场数据

需求侧驱动力

1. LLM 训练/推理规模爆炸：单模型训练动辄数千 GPU，传统手动编排已不可行
2. RLHF 管线复杂性：涉及多阶段（SFT→Reward Model→PPO/DPO），每阶段资源需求不同，需要弹性调度
3. GPU 资源稀缺：统一集群调度可提升 GPU 利用率（避免各环节独立集群的资源碎片化）
4. Python 生态主导：AI 研发几乎全部用 Python，Ray 的 Python-native 特性是刚需

供给侧格局

Anyscale 融资（公开报道信息，具体金额以官方公告为准）

注：以上为多家科技媒体报道的概数，Anyscale 未在公开 SEC 文件中披露全部细节，请以官方公告为准。

代表公司与资本映射

投资映射思路：

• 直接受益：Anyscale（未上市）
• 间接受益：GPU 供应商（NVIDIA）、云厂商（通过提升 GPU 集群利用率降低客户 TCO）、采用 Ray 提升研发效率的 AI 公司

投资逻辑

看多逻辑

1. LLM 时代的”分布式操作系统”刚需：随着模型规模和集群规模同步扩大，统一调度编排层的市场空间确定性高
2. 事实标准地位：OpenAI（据多方报道）+ 众多头部 AI 公司的采用形成了强网络效应；学术引用量高
3. Python 生态壁垒：AI 研发几乎 100% Python，Ray 的 Python-native 优势是结构性的
4. Anyscale 的商业化路径清晰：开源漏斗 → Anyscale Platform SaaS → 企业私有部署
5. 向上整合潜力：Ray 作为中间件，有可能逐步吸收更多 ML 框架层功能（如数据处理、特征工程）

看空/风险

1. 云厂商自建替代：AWS、Google、Azure 可能在自己的 ML 平台中内置类似功能，挤压 Anyscale 的独立市场空间
2. Kubernetes 生态竞争：KubeFlow、Knative 等 K8s 原生方案持续演进；K8s 本身也可能增加更智能的调度能力
3. 技术风险：Ray 的复杂性持续增长（Core + 6-7 个子库），维护和稳定性挑战加大
4. Moat 验证期：开源框架的商业化从来不容易（参见 Databricks 之于 Spark 的漫长商业化路径，且 Databricks 有 Spark 的大数据市场作为基本盘，Ray 的 ML 中间件市场更窄）
5. OpenAI 依赖风险：如果核心大客户自建替代方案（OpenAI 有动力和能力自研）

关键观察点

• Anyscale ARR 增速和客户集中度
• Ray 在非 OpenAI 客户中的渗透率
• KubeRay 的 K8s 社区采纳度
• Ray Data vs Spark/Dask 在 ML 数据管道中的竞争态势
• vLLM、TensorRT-LLM 等推理引擎与 Ray Serve 的整合深度

常见误读纠偏

误读 1：“Ray 是一个训练框架，和 PyTorch 竞争”

纠正：Ray 不是训练框架。Ray Train 不做梯度计算，它是编排层——负责在多个节点上启动 PyTorch DDP / DeepSpeed / HuggingFace Trainer 等实际训练框架。类比：Ray 是”交响乐指挥”，PyTorch 是”乐器”。两者是互补关系，不是竞争关系。

误读 2：“Ray 只适合强化学习”

纠正：Ray 最初因 RLlib（分布式强化学习库）而知名，这导致了”Ray = RL 工具”的早期印象。但实际上 Ray Core 是通用分布式计算框架，RL 只是其应用之一。在 LLM 时代，Ray 更广泛地用于数据预处理、分布式训练编排、推理服务等非 RL 场景。

误读 3：“Ray 的对象存储 Plasma 是独立的分布式存储系统”

纠正：Plasma 不是独立的存储系统（如 Redis/Alluxio），而是嵌入在每个节点 Raylet 中的共享内存管理器。它利用操作系统级的 shared memory 实现节点内零拷贝，节点间通过内部协议按需传输。这是设计选择——追求低延迟而非持久化。

误读 4：“Ray 可以替代 Spark 做大数据 ETL”

纠正：Ray Data 确实提供了数据处理能力，但其设计重心是ML 管线中的数据准备（如图像解码、tokenization、特征变换），而非通用的大规模 ETL。对于 TB/PB 级的数据清洗和 SQL 分析，Spark 仍然是更成熟的选择。两者有交集但并非全面替代关系。

学习路径

阶段 1：入门（1-2 天）

1. 官方 Quick Start：pip install ray → 跑通 @ray.remote 的 Task 和 Actor 示例
2. 理解 ObjectRef：ray.get() / ray.put() 的异步语义
3. 核心概念：Driver、Task、Actor、Object Store、GCS

阶段 2：中级（1-2 周）

1. Ray Data：学习 ray.data.Dataset 的 API，理解与 Spark DataFrame 的异同
2. Ray Train：跑通一个 PyTorch DDP on Ray 的端到端示例
3. Ray Serve：部署一个简单的模型服务，理解 Deployment、Replica、Ingress 的概念
4. Placement Group：理解资源亲和性控制

阶段 3：高级（持续）

1. 阅读 Ray 源码：从 python/ray/ 目录入手，重点看 Raylet 和 GCS 的实现
2. OSDI 2018 论文：理解设计动机和架构权衡
3. 生产部署实践：KubeRay 部署、监控（Ray Dashboard + Prometheus）、调试
4. 性能调优：对象存储溢出控制、调度策略调优、GPU 资源隔离
5. RLHF 管线实战：用 Ray 编排 SFT→Reward→PPO 的完整流程

推荐阅读

• Ray 官方文档（最权威的一手资料）
• Ray Architecture Whitepaper（如有更新）
• “Ray: A Distributed Framework for Emerging AI Applications” (OSDI 2018)
• “RLlib: Abstractions for Distributed Reinforcement Learning” (ICML 2018)
• Anyscale 博客中的 LLM infra 相关文章

一句话总结

Ray 是 AI 基础设施栈中”分布式操作系统”层的事实标准候选者——它不替代 PyTorch，而是在其之上为数据→训练→推理的全链路提供统一的 Python-native 分布式编排，其战略地位随 LLM 集群规模扩大而持续提升。

延伸阅读与来源

1. Moritz, P. et al., “Ray: A Distributed Framework for Emerging AI Applications”, OSDI 2018 — Ray 的奠基论文
2. Liang, E. et al., “RLlib: Abstractions for Distributed Reinforcement Learning”, ICML 2018
3. Ray 官方文档 — 技术规格和 API 参考的一手来源
4. Anyscale 官方博客 — 商业化案例和技术深度文章
5. KubeRay GitHub — K8s 上部署 Ray 的 operator
6. Ray GitHub — 源码和社区讨论
7. 各大科技媒体对 Anyscale 融资的报道（TechCrunch、The Information 等）

数据来源说明：本页中的具体数字标注了来源口径。未明确标注的定量数据多为行业估算或公开报道汇编，不构成投资建议。Anyscale 的具体财务数据（ARR、客户数等）未充分披露，本文不编造。