当我们回顾计算机发展的历史，会发现一个清晰的规律：每一个计算时代，都建立在一个全新的计算堆栈之上，并由一个为该时代量身定制的“计算引擎”所驱动。
在客户机/服务器时代，是以Windows Server或Unix为核心；在互联网时代，是LAMP架构（Linux, Apache, MySQL, PHP）；在移动云时代，是容器化（Docker/Kubernetes）和大数据（Hadoop/Spark）。
而现在，我们正站在一个新的起点：AI原生时代（AI-Native Era）。
在这个时代，所有的应用、所有的基础设施，都在围绕AI模型重构。而Ray，正是这个AI原生时代的“计算引擎”。
为什么旧的堆栈不再适用？
在Ray Summit 2025上，Anyscale的联合创始人兼执行主席Ion Stoica深刻地指出了当下的痛点。很多企业面临“创新者的窘境”，试图通过“搬运（Lift and Shift）”的方式，将现有的Web架构强行套用在AI应用上。
然而，AI工作负载与传统的微服务有着本质的区别。面对构建AI堆栈，你只有三个选择：
- Option 1（扩展现有堆栈）：试图修补现有的Web架构。但这就像当年试图把桌面应用强行搬到移动端一样，注定失败。
- Option 2（仅依赖前沿模型）：完全依赖闭源模型API。但这会让你失去对数据的控制权和差异化竞争的能力。
- Option 3（构建AI原生基础设施）：这是唯一的出路。
为什么必须是Option 3？因为AI的底层逻辑变了。
首先，硬件变得极度异构化。不再是单纯的CPU集群，而是CPU、GPU、TPU以及各种AI加速器的混合体，配合着RDMA和高速网络互连。
(图：多模态数据，经历预训练、推理、强化学习等处理流程，涉及到多种类型的算力资源)
(图：跨节点的算力资源调度复杂度)
其次，处理流程变得极度复杂。过去我们认为的数据处理（CPU）、训练（GPU）、推理（单节点）的界限正在模糊。现在的AI管道是多模态的：数据处理需要GPU加速，后训练（Post-training）和强化学习（RL）需要异构计算，而推理（Inference）正在变成复杂的分布式系统。
Ray：为复杂性而生的计算引擎
正是为了解决这种复杂性，Ray应运而生。
故事要回到2016年的UC Berkeley，当时Robert Nishihara, Philipp Moritz和Ion Stoica正在研究强化学习（Reinforcement Learning）。他们发现现有的工具根本无法满足RL所需的动态、分布式和低延迟要求。于是，他们构建了Ray。
(图：Ray的创始团队在2016年的UC Berkeley，Ray最初是为了解决最复杂的强化学习问题而生)
Ray的核心优势在于它填补了底层硬件（Kubernetes, GPUs）与上层应用框架（PyTorch, vLLM, Hugging Face）之间的巨大鸿沟。
(图：Ray位于AI堆栈的核心位置，向下管理异构硬件，向上支撑AI应用)
Ray不仅是一个简单的调度器，它是AI原生堆栈的计算引擎。它提供了四大核心能力来满足AI时代的需求：
- 细粒度、动态的任务编排：能够在异构集群中灵活调度数百万个微小任务。
- 灵活性（Flexibility）：支持从今天的训练任务到明天的Agentic AI工作负载。
- 容错性（Fault Tolerance）：确保长达数周的训练任务或大规模推理服务不会因为单点故障而中断。
- Pythonic API：让所有Python开发者都能无缝编写分布式系统。
(图：AI原生计算的四大核心需求)
Ray为何在当下爆发式增长？
在过去的一年里，Ray的下载量增长了5倍。为什么是现在？
Ion Stoica将AI的发展分为三个阶段，这也解释了Ray的增长曲线：
- 传统深度学习阶段：模型较小，数据并行即可解决，Ray的优势未完全体现。
- 生成式AI第一阶段（ChatGPT时刻）：预训练（Pre-training）成为主流，模型变大，Ray开始被OpenAI等公司用于扩展训练。
- 生成式AI第二阶段（当下）：这是Ray彻底爆发的时刻。
在这个阶段，重心从单纯的“预训练”转向了后训练（Post-training）、多模态处理和复杂推理（Reasoning/Agents）。
| | | |
|---|
数据处理
| | 大规模文本处理
(Large text processing) | 多模态处理
|
训练
| | 稠密模型
(Dense models)
(数据并行，模型并行) | MoE 模型
(MoE models)
(数据并行，张量并行，流水线并行，序列并行，Token 并行，上下文并行) |
推理服务
| 单 GPU 模型
(Single-GPU models) | 单节点模型
(Single-node models) | 多节点模型
(Multi-node models)
(专家路由 Expert-routing，预填充解耦 Prefill disaggregation 等) |
说明：
- DNN: 深度神经网络 (Deep Neural Network)
- MoE: 混合专家模型 (Mixture of Experts)
- Parallel (并行): 在 GEN AI 第二阶段的训练中，出现了多种并行计算策略：
- Prefill disaggregation: 通常翻译为“预填充解耦”或“Prefill/Decode 分离”，指在推理过程中将 Prompt 处理（Prefill）和生成（Decode）阶段分离到不同计算单元的技术。
Ray下载趋势也正好映射到这三个阶段，可以看出从Gen-1阶段开始爬坡，直到进入Gen-2阶段，出现了爆发式增长。
(图：Ray的周下载量的趋势图。随着模型规模和数据量的指数级增长，复杂性迫使开发者寻找更强大的基础设施)
现在的AI不再只是训练完就结束。我们需要做RLHF（人类反馈强化学习），需要处理视频/图像等多模态数据，需要运行复杂的Agent推理（思考链）。这些工作负载是动态的、异构的、且高度依赖分布式协同的。
正如Ion所说：“工作负载越复杂，Ray的光芒就越耀眼。”
AI生态的关键拼图
如今，Ray不仅仅是一个项目，它已经成为AI生态系统的通用货币。
- 对于基础设施：Ray正在与Kubernetes深度集成（包括GKE和AKS），成为云原生AI的标准运行时。
- 对于模型层：几乎所有主流的开源后训练框架、大规模推理框架（如vLLM）都构建在Ray之上。
- 对于开发者：它提供了一个统一的平台（Unified AI Platform），让你可以在一套代码中完成数据处理、训练、微调和推理服务。
(图：大多数OpenSource的RL Framework都是基于Ray构建的)
结论：这是AI领域的Hadoop时刻
如果你觉得在2010年错过了Hadoop和Spark的大数据浪潮，那么今天，千万不要错过Ray。
我们正处在一个巨大的技术转折点。AI应用正在从简单的Chatbot进化为能够自主行动、处理复杂逻辑的Agent；计算模式正在从静态的微服务转向动态的分布式计算。
Ray之于AI，正如Hadoop之于大数据。
当我们无法在这个项目启动之初就开始介入的话，那么当下就是介入最好的时机。因为AI的复杂性才刚刚开始爆发，而Ray正是驾驭这种复杂性、构建未来AI应用的最佳武器。
Let's Go, Ray!
