Ray（分散式統一計算架構）

3 秒看懂

Ray 是一個開源分散式計算架構，由 UC Berkeley RISELab 孵化，旨在為 AI/ML 全生命週期（資料處理→訓練→調參→服務）提供統一的程式設計介面和叢集排程層。 它不是訓練架構本身（不替代 PyTorch/TensorFlow），而是在其之上的”分散式作業系統”——把單機 Python 程式碼幾乎原封不動地擴充套件到數千節點叢集。商業公司 Anyscale 圍繞 Ray 建置商業化產品，OpenAI 等頭部 AI 實驗室被多方報道為深度使用者。

3 分鐘產業解釋

為什麼需要 Ray？

在大型模型時代，一個典型的 AI 工作流至少涉及 4 個獨立環節：

環節	傳統方案（碎片化）	Ray 的統一方案
資料預處理	Spark / Dask / 自研指令碼	Ray Data
分散式訓練編排	Horovod / DeepSpeed 手動整合	Ray Train
超參搜尋	Optuna / 自研迴圈	Ray Tune
模型服務	TF Serving / Triton / vLLM 獨立部署	Ray Serve

傳統方案的痛點在於：每個環節需要獨立的叢集、獨立的排程器、獨立的序列化/通訊協議，運維複雜度隨規模呈超線性增長。

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 分鐘專家深入

歷史脈絡

時間	里程碑	意義
2017	UC Berkeley RISELab 開源 Ray	RISELab 是 AMPLab（孵化了 Apache Spark）的繼任實驗室
2018	OSDI 論文發表	”Ray: A Distributed Framework for Emerging AI Applications”，奠定學術地位
2019	Anyscale 成立（Robert Nishihara、Ion Stoica 等）	商業化推動
~2020	Ray 1.0 釋出	API 穩定化，生產就緒訊號
~2021	Ray AIR (AI Runtime) 統一品牌	將 Tune/Train/Serve/Data 整合為統一產品敘事
~2022	Ray 2.0 釋出	架構重構：Ray Data 成為一等公民，統一資料-訓練-服務流水線
2023-至今	LLM 時代加速滲透	多方報道 OpenAI、Anyscale 與 LLM 訓練/推論/RLHF 管線深度繫結

注：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 採用兩層排程：

層級	元件	職責
全域性排程	GCS + Global Scheduler	將 Task/Actor 分配到節點（考慮資源、親和性、資料區域性性）
本地排程	Raylet (每節點一個守護程序)	在節點內部將 Task 分配到具體 CPU/GPU 核；管理本地資源（CPU slots、GPU、記憶體）

效能最佳化：對於本地可滿足的任務，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

---

技術演進史

階段	時間	核心特徵
學術原型期	2017-2019	Ray Core + RLlib；定位為強化學習的分散式執行時
平台化期	2019-2021	加入 Tune、Serve；開始服務通用 ML 工作負載
統一 AI Runtime 期	2021-2022	Ray AIR 品牌統一；Ray Data 升級為一等公民
LLM 基建期	2022-至今	深度整合 LLM 訓練/推論/RLHF 管線；Anyscale 推出 Anyscale Platform（商業版）；開源 Anyscale 託管的 RayTurbo 引擎

關鍵架構變遷：

• Ray 1.x → 2.x：GCS 從 Redis-based 演進為內建 GCS Server（減少外部依賴、提升可靠性）；Ray Data 從實驗性質變為資料-訓練-服務統一管線的核心

---

技術路線對比

維度	Ray	Apache Spark	Dask	Kubeflow	純 K8s + 手動編排
核心抽象	Task + Actor（動態 DAG）	RDD/DataFrame（批/流）	Task + Delayed（動態 DAG）	K8s CRD + Pipeline	Pod + Service
原生 Python 生態	★★★★★	★★☆ (PySpark 有限)	★★★★★	★★★☆	N/A
ML 訓練編排	原生（Ray Train）	無（需外部架構）	有限	原生（但較重）	手動
模型服務	原生（Ray Serve）	無	無	KServe（獨立）	Triton/vLLM 等
細粒度低延遲任務	★★★★★（毫秒級）	★★☆（批處理導向）	★★★☆	N/A（編排層）	取決於實現
大規模資料 ETL	★★★☆（改進中）	★★★★★	★★★★☆	N/A	N/A
狀態管理	Actor 原生支援	無原生支援	有限	無	手動
運維複雜度	中（需理解 Ray 概念）	高	低-中	高	非常高
GPU 排程成熟度	中-高（持續改進）	低	低	中	中（取決於排程器）
社群/生態成熟度	中-高（增長快）	非常高	中	中	N/A

總結：Ray 的獨特定位是 “Python-native + 細粒度任務 + 有狀態 Actor + ML 全棧”。Spark 主導大數據 ETL；Dask 是輕量 Python 並行；Kubeflow 是 K8s 上的 ML pipeline 編排工具集；Ray 嘗試用一個執行時統一以上場景。

---

上下游

上游依賴

層級	具體技術	關係
程式語言	Python, C++ (核心執行時)	Python API 是主要使用者介面
序列化/資料	Apache Arrow (Plasma object store)	物件儲存層直接複用 Arrow 的 Plasma
通訊	gRPC（節點間控制面）, 共享記憶體（節點內資料面）	—
叢集管理	Kubernetes (KubeRay Operator), 雲端 API	KubeRay 是主流部署方式
ML 架構	PyTorch, TensorFlow, JAX, HuggingFace Transformers	Ray Train 封裝這些架構進行分散式訓練
GPU 通訊	NCCL (通過 PyTorch DDP/DeepSpeed)	Ray 自身不直接實現 AllReduce，而是編排

下游消費者

消費者	使用方式
AI 研究團隊	用 Ray Tune 做大規模超參搜尋；用 Ray Train 做分散式訓練
LLM 訓練/推論平台	資料預處理(Ray Data) → 訓練(Ray Train+DeepSpeed) → 服務(Ray Serve/vLLM on Ray)
推薦系統	特徵工程 + 線上推論服務
強化學習	RLlib 提供分散式 RL 訓練和環境模擬
MLOps 平台	作為底層計算引擎（如 Anyscale Platform）

---

關鍵指標

指標	數值/狀態	說明
GitHub Stars	~34k+（截至 2024 年中，估算）	開源社群活躍度的粗略代理
叢集規模上限	數千節點級別	Anyscale 官方案例中有大規模部署描述，具體上限取決於工作負載
任務排程延遲	亞毫秒~毫秒級（本地任務）	本地 Raylet 排程路徑極短
物件儲存吞吐	取決於共享記憶體頻寬	節點內零複製；節點間受限於網路
支援語言	Python（主要）, Java, C++	Python 是絕大多數使用者的選擇
容錯機制	Task/Actor 自動重試 + lineage-based 重建	Actor 支援 checkpoint + 重啟
排程策略	預設基於資源的貪心排程；支援 Placement Group 和自定義排程策略	Placement Group 用於保證親和性（如 GPU 節點拓撲感知）

---

供需與市場資料

需求側驅動力

1. LLM 訓練/推論規模爆炸：單模型訓練動輒數千 GPU，傳統手動編排已不可行
2. RLHF 管線複雜性：涉及多階段（SFT→Reward Model→PPO/DPO），每階段資源需求不同，需要彈性排程
3. GPU 資源稀缺：統一叢集排程可提升 GPU 利用率（避免各環節獨立叢集的資源碎片化）
4. Python 生態主導：AI 研發幾乎全部用 Python，Ray 的 Python-native 特性是剛需

供給側格局

供應商/專案	產品	定位
Anyscale（商業公司）	Anyscale Platform, RayTurbo	Ray 的商業化託管平台（SaaS + 私有部署）
Ray OSS	ray (PyPI)	開源版本，社群維護
AWS	Amazon SageMaker 分散式訓練	底層集成了 Ray 元件（具體整合深度需據實確認）
雲端廠商	各家 K8s 託管服務 + KubeRay	基礎設施層支援

Anyscale 融資（公開報道資訊，具體金額以官方公告為準）

輪次	時間（約）	金額（報道口徑）
Series B	~2020	報道約 $40M 量級
Series C	~2021	報道約 $100M，估值報道約 $1B 量級
Series D	~2023	報道約 $100M，估值報道約 $2.5B 量級

注：以上為多家科技媒體報道的概數，Anyscale 未在公開 SEC 檔案中揭露全部細節，請以官方公告為準。

---

代表公司與資本對映

公司/組織	與 Ray 的關係	上市/融資狀態
Anyscale	Ray 創始團隊創立的商業公司	私有（如上融資）
OpenAI	多方報道為 Ray 深度使用者（用於內部訓練/推論編排），未官方確認完整技術棧	私有
Uber	公開案例：用 Ray 支撐大規模 ML 管線	上市 (UBER)
Spotify	公開案例：推薦系統	上市 (SPOT)
Ant Group (螞蟻集團)	多方報道在 ML 基礎設施中使用 Ray	私有
Intel	Ray 開源貢獻者，Intel 最佳化相關的合作	上市 (INTC)
Amazon (AWS)	SageMaker 與 Ray 有整合	上市 (AMZN)
Google Cloud	Vertex AI 與 Ray 的互操作性支援	上市 (GOOGL)

投資對映思路：

• 直接受益：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、客戶數等）未充分揭露，本文不編造。