Ray / Anyscale

1. 调研缘由

之所以关注 Ray / Anyscale，主要是因为它同时串起了三条线索：第一，Ray 的定位已从“分布式 Python 框架”延伸到了 AI 数据处理、训练、调参、强化学习和模型服务等场景；第二，Ray 在 2025 年进入 PyTorch Foundation，被放进 PyTorch、vLLM、DeepSpeed 等组成的开源 AI 计算栈版图里；第三，Anyscale 正在把 Ray 封装成面向企业 AI 基础设施的商业平台，包括托管 Ray、BYOC、多云/Kubernetes 部署、Anyscale Runtime 和企业支持 [S1][S2][S4][S5][S6][S7]。

这篇简调以 Ray 开源项目 为主体，把 Anyscale 商业平台 作为它的生产化层来展开，这样既可以避免把 Anyscale 的托管能力误写成 Ray OSS 自带能力，也能避免把 Ray 的开源生态信号直接等同于 Anyscale 的商业表现。

2. 简介与产品工作流

Ray 是一个开源分布式计算框架。按官方文档的说法，它是“用于扩展 AI 和 Python 应用的开源统一框架”，能帮你把分布式应用从单机一路扩展到集群 [S1]。打个比方：开发者平时在单机上用 Python 写函数、类和训练/推理脚本；一旦数据量、模型规模或并发超出单机上限，Ray 就通过 Task、Actor、Object Store 这些抽象，把这些 Python 工作负载分发到集群里去跑 [S1][S3]。

Ray 覆盖的工作流主要有：批量推理、大模型/生成式 AI、模型服务、特征工程与数据预处理、超参调优、分布式训练和强化学习 [S2]。其中 Ray Data 负责机器学习数据处理，官方文档明确说它可以处理视频、音频、非结构化文本、图像等多模态数据；注意，这里的“多模态”指数据处理的对象，不代表 Ray 本身具备图像、语音或视频生成能力 [S2]。

Anyscale 是 Ray 原班人马创立的商业公司，目标就是帮团队在生产环境里部署、扩展和管理 Ray 的工作负载 [S2][S5]。典型的用法是：团队先用 Ray 开发数据处理、训练、批量推理或在线服务，再通过 Anyscale 平台把这些负载跑在托管环境、自己的云账号或 Kubernetes 集群上 [S5][S6]。

部署方面，Ray OSS 能跑在单机、集群、云厂商和 Kubernetes 上；Anyscale 额外提供 Hosted 和 Bring Your Own Cloud（BYOC）两种模式，BYOC 支持部署在你自己的云或本地环境里 [S3][S10]。这也是最容易搞混的地方：Ray 是开源框架，Anyscale 是围绕它做的商业生产平台。

3. 团队与资本背景

Ray 起源于 UC Berkeley 的 RISELab。Linux Foundation / PyTorch Foundation 的公告提到，Ray 最初由 Anyscale 开发，项目根源在 UC Berkeley；进入 PyTorch Foundation 后，Ray 成为基金会的托管项目之一 [S4]。Ray 早期论文作者包括 Philipp Moritz、Robert Nishihara、Stephanie Wang、Alexey Tumanov、Richard Liaw、Eric Liang、Melih Elibol、Zongheng Yang、William Paul、Michael I. Jordan 和 Ion Stoica 等 [S25]。

Anyscale 的创始背景和 Berkeley 的分布式系统研究深度绑定。2021 年的融资公告称，公司位于旧金山，专注围绕 Ray 做 AI 应用的扩展和生产化；外面的公开资料也总是把它和 Ray 的原班团队联系在一起 [S8][S2]。

在资本侧，Anyscale 2021 年完成了 1 亿美元的 C 轮融资，投后估值 10 亿美元，累计融资 1.6 亿美元；领投方是 Andreessen Horowitz 和 Addition，NEA、Intel Capital、Foundation Capital 跟投 [S8]。2022 年，它又宣布追加 9900 万美元 C 轮资金，由 Addition 和 Intel Capital 共同领投，Foundation Capital 参投 [S9]。这些信息表明，Anyscale 在 2021–2022 年已循着“围绕 Ray 做商业化 AI 基础设施平台”这条路拿到了大额融资；不过这次调研没找到公开资料能确认它最新的营收、付费客户数，或 2023 年之后有没有新一轮融资。

4. 技术基础与生态位

Ray 的底层是一个分布式运行时。核心抽象有三块：Tasks（无状态函数调度到集群执行）、Actors（有状态的长生命周期进程）和 Objects（集群内传递不可变值）[S3]。在这些基础上，Ray 提供面向 AI/ML 的上层库：Ray Data 负责数据处理，Ray Train 做分布式训练，Ray Tune 做超参搜索，RLlib 做强化学习，Ray Serve 负责模型和 Python 服务的在线推理 [S1][S2]。

从生态位看，Ray 更偏 AI 计算层/分布式执行层，既不是模型，也不是应用，也不是某个单一的 MLOps 工具。2025 年 PyTorch Foundation / Linux Foundation 接纳 Ray 时，把它定义为 AI 工作负载的开源分布式计算框架，覆盖数据处理、模型训练和大规模推理；同时把 Ray 和 PyTorch、vLLM、DeepSpeed 放在了同一个开源 AI 计算栈的语境里 [S4]。这意味着 Ray 的角色更像一个“把 Python/AI 工作负载扩展到多机、多 GPU、多云环境里的执行层”。

Anyscale 在 Ray 之上叠加了平台层。官方资料说，它能让团队跨多云、VM 或 Kubernetes 来管理、观测和共享 Ray 工作负载 [S5]。Anyscale Runtime 是专门在 Anyscale 上跑工作负载的 Ray 版本，官方说它保持了对 Ray API 和库的兼容，同时通过底层调优、checkpoint、执行引擎优化来提升性能和生产可靠性 [S7]。

技术路线上，Anyscale 走的是“开源 Ray + 专有 Runtime + 托管控制平面”这条路。架构文档显示，控制平面是一个多租户 SaaS，管集群生命周期、资源调度、用户认证授权、状态配置、指标和日志聚合；客户数据平面跑在客户自己的云账号或 K8s 集群里，包含 Ray 集群、VM/K8s Pod、日志和 checkpoint 存储、网络以及容器镜像 [S6]。因此，这个项目同时涉及开源基础设施和企业 AI 平台两个层面；frontmatter 里 primary_category 填 infrastructure，是因为 Ray 的主要生态位仍是 AI 分布式计算基础设施。

5. 市场与外部信号

在开源采用上，Linux Foundation / PyTorch Foundation 2025 年的公告称，Ray 当时已攒下超过 39000 个 GitHub stars 和超过 2.37 亿次下载；并称 Ray 加入 PyTorch Foundation 后，会和 PyTorch、vLLM、DeepSpeed 等项目构成更统一的开源 AI 计算栈 [S4]。这些是基金会公告的口径，可以当作开源生态信号，但不能直接等同 Anyscale 的商业收入或客户转化。

商业化方面，Anyscale 官网把自己定位为“Production-scale AI with Ray”，强调能做多模态数据整理、分布式模型训练、批量 embedding、后训练等基础模型相关负载 [S5]。客户页上列了 Coinbase、Character.AI、TwelveLabs、Canva、Reflection、Torc Robotics、Tripadvisor、Runway、Grab、Recursion、Attentive、Notion、Bedrock、Physical Intelligence、Riot Games 等一堆 logo；这些只是官方展示的信息，看得出 Anyscale 主攻 AI 团队和企业平台团队，但没法据此推断收入规模或客户用得有多深 [S11]。

定价上，Anyscale 官网分了 pay-as-you-go 和 committed contracts 两种。Hosted 模式主打免配基础设施，BYOC 模式强调部署到你自己的云或本地环境、能用现有的 GPU 预留，并带 24x7 企业支持；官网还列了按 Anyscale Credits 计费的 CPU、T4、L4、A10G、A100 实例小时价格 [S10]。

云生态上，AWS APN 博客把 Ray 描述为“扩展 AI 与 Python 工作负载的开源统一计算框架”，称 Anyscale 是 AWS Machine Learning Competency 合作伙伴，提供在 AWS 上构建生成式 AI 应用的托管服务 [S13]。Microsoft Learn 在 2026 年 6 月更新的文档显示，Anyscale on Azure 目前是 Public Preview，是一个运行 Ray 分布式 Python 工作负载的托管平台，会部署到你自己的 AKS 集群里，并和 Entra ID、Blob/ADLS、Container Registry、Load Balancer 等 Azure 服务打通 [S12]。

产品更新方面，Runtime 文档提到，它在 Ray Data、Ray Train、Ray Serve、RLlib 等方向都加了增强能力，比如数据处理 checkpoint、智能 autoscaling、训练中断恢复、Serve 的高吞吐和低延迟优化等 [S7]。这些都是官方文档的说法，可以看出 Anyscale 的商业层在往生产可靠性、性能和平台治理方向扩展；不过这次没找到独立资料能验证这些优化在不同生产环境里的普遍效果。

6. 公开评价与主要分歧

正面评价（官方 / 合作方 / 独立媒体 / 开发者与社区用户）：

官方和合作方的评价都集中在“统一 AI 计算层”这个点上。Linux Foundation / PyTorch Foundation 公告认为，Ray 进来之后补上了开源 AI 栈的关键一层，能撑住从单机到几千节点的数据处理、训练和在线服务 [S4]。AWS APN 博客则从生成式 AI 基础设施视角强调，Ray 可以 Python-native 地扩展训练、embedding、模型服务等工作流，而 Anyscale 提供托管、BYOC、可观测性、成本优化和治理能力 [S13]。这些来源都是官方或合作方口径，能当事实和生态信号看，不算独立评价。

在独立对比里，Onehouse 2025 年一篇 Spark/Ray/Dask 对比文章，把三者都归为分布式 ML/DS 计算引擎，各自的侧重点不同：Spark 偏数据管道的韧性，Ray 偏 GPU/CPU 异构计算，Dask 偏从单机 Python 平滑扩展到分布式 [S24]。Databricks 的文档也把 Ray 和 Spark 放在不同场景下：Ray 更擅长 task parallelism，即多个独立任务并发；Spark 更擅长 data parallelism，即对大数据集的每个元素做相同操作 [S22]。

社区反馈方面，Reddit r/mlops 上有用户觉得 Ray 适合做分布式学习和调参，还提到能在本地和分布式环境之间切换 [S19]。这些是 Tier3 社区声音，只能反映部分使用者的主观体验和讨论热点，不能单靠它来评判 Ray 的整体产品力或普遍口碑。

主要批评/质疑（安全研究 / 用户评价平台 / 社区用户）：

安全方面的争议，是 Ray 公开评价里最直接的一个负面信号。2024 年，Oligo Security 披露了 ShadowRay，称 CVE-2023-48022 跟 Ray Jobs API 缺授权有关，并指出如果 Ray Dashboard / Jobs API 被意外暴露，攻击者就可能在远程主机上执行任意任务 [S14]。NVD 对 CVE-2023-48022 的描述也写明，Anyscale Ray 2.6.3 和 2.8.0 允许远程攻击者通过 job submission API 执行任意代码，同时注明了厂商的立场：Ray 不该部署在严格受控的网络环境之外，且从 2.52.0 开始用户可以选择 token 认证 [S16]。

Anyscale / Ray 维护方的回应则有所不同。Anyscale 在 2023 年的 CVE 更新里说，5 个被报告的 CVE 中有 4 个已在 master 修复，会进入 Ray 2.8.1；关于 CVE-2023-48022 的核心分歧在于，Ray 的安全边界到底该由集群外部网络环境来兜底，还是框架本身要有内置防护 [S15][S16]。到了 Ray 2.52.0，官方文档说 token 认证已经可用，但默认还是关的，并提到未来版本计划默认开启 [S17]。这形成了一个清晰的差异：安全研究方更在意“未认证接口暴露到现实中的风险”，维护方更强调 Ray 的设计前提是跑在可信网络边界内。

在用户评价平台上，G2 上有人肯定 Anyscale 能把 AI/ML 工作负载从开发推向生产，而且不用大幅重写；同一条评论也提到，对不熟悉 Ray 概念的团队，学习曲线很明显，定价不够透明让成本规划比较费劲 [S18]。这属于 Tier3 用户评价平台，样本量不多，不能当成普遍评价，但可以当作外部使用体验的一个信号。

存在分歧之处：

第一，Ray 的安全边界到底清不清晰。维护方强调 Ray 应该在受控网络里跑，认证是额外保护；安全研究方则认为公开暴露的 Ray 集群已经被现实中的攻击盯上，说明这种部署假设在用户那里容易失效 [S14][S15][S16][S17]。

第二，Ray 和 Spark / Dask 的关系，不是谁替代谁这么简单。Databricks 的建议是把 Ray 用在 task parallelism、强化学习、仿真、超参搜索、深度学习训练这些场景，把 Spark 用在大规模数据处理、ETL、聚合、报表和 Spark MLlib 上 [S22]。Onehouse 的独立对比也倾向于按工作负载拆分，而不是下一个谁好谁坏的定论 [S24]。

第三，Ray OSS 与 Anyscale 商业平台的边界需要拆开看。Ray 的开源能力、Anyscale Runtime 的专有优化、Anyscale 控制平面的 SaaS / BYOC 能力分别属于不同层；如果把它们混在一起叫“Ray 产品能力”，事实边界就模糊了 [S1][S2][S5][S6][S7]。

7. 同类对比（与头部/高知名度同类项目）

主要对标项目: Apache Spark、Dask、Kubernetes / KubeRay。
说明一下：Spark 和 Dask 是分布式数据/计算框架层面的参照；Kubernetes 本身不是 Ray 的同类计算框架，但在生产部署和资源编排上，它俩经常挨着出现，所以放在一起比较。

关键维度对比（事实，标来源）:

维度	Ray / Anyscale	Apache Spark	Dask	Kubernetes / KubeRay
基本定位	Ray 是扩展 AI 与 Python 应用的开源统一框架；Anyscale 是基于 Ray 的生产平台 [S1][S5]	Spark 是面向数据工程、数据科学和机器学习的多语言大规模数据分析引擎 [S20]	Dask 是做并行与分布式计算的 Python 库，通常和 NumPy、pandas、Scikit-learn 等生态搭配 [S21]	Kubernetes 是容器编排层；KubeRay 是在 Kubernetes 上管理 Ray 集群的 operator [S23]
核心抽象	Ray Core 的 Tasks、Actors、Objects；Ray Data、Train、Tune、RLlib、Serve 等 AI 库 [S1][S2][S3]	Spark SQL、DataFrame、Structured Streaming、MLlib 等大数据处理和分析能力 [S20]	Dask DataFrame、Array、Delayed、Futures 等 Python 并行计算接口 [S21]	KubeRay 提供 RayCluster、RayJob、RayService 等 Kubernetes CRD 来管理 Ray 集群和服务 [S23]
主要适用工作负载	数据处理、分布式训练、超参搜索、强化学习、模型服务、批量推理 [S2]	ETL、聚合、SQL 分析、流处理、机器学习等大规模数据处理 [S20][S22]	Python 数据分析、科学计算、并行 for-loop 类任务、从单机扩展到分布式 [S21][S24]	容器化工作负载编排；在 Ray 场景下负责部署和管理 Ray 集群，不替代 Ray 的分布式 Python/AI 执行语义 [S23]
Ray / Spark 的公开对比口径	Databricks 文档称 Ray 擅长 task parallelism，Spark 擅长 data parallelism；两者可在同一环境中组合使用 [S22]	同左 [S22]	Onehouse 把 Dask 归为与 Spark、Ray 并列的分布式 ML/DS 计算引擎，强调其从单机 Python 扩展到分布式的路径 [S24]	KubeRay 是 Ray 在 Kubernetes 上的推荐管理方式，支持 RayCluster、RayJob、RayService 等资源 [S23]
商业化 / 托管层	Anyscale 提供 Hosted、BYOC、企业支持、Anyscale Runtime 与控制平面 [S5][S6][S7][S10]	Spark 的商业化一般由 Databricks、云厂商或企业数据平台承接；这里不展开具体商业产品	Dask 的商业化生态包括 Coiled、Anaconda 等；这里不展开具体商业产品	Kubernetes 的商业化主要由云厂商托管 K8s、企业发行版和平台工程服务承担；这里仅作为部署参照

公开评价中的对比（标源，非个人裁决）：

Databricks 的公开文档把 Ray 和 Spark 分在不同适用场景：Ray 更偏任务并行、仿真、强化学习、深度学习训练、高性能计算等计算密集任务；Spark 更偏大规模数据处理、ETL、聚合和报表等数据并行任务 [S22]。Onehouse 的独立对比也没有把三者写成简单替代关系，而是把 Spark、Ray、Dask 分别放在数据管道韧性、GPU/CPU 异构计算、Python 生态平滑扩展三个侧重点上 [S24]。因此，本文不会写“Ray 优于 Spark / Dask”或“Ray 会取代 Spark / Dask”，只是把它们当作不同工作负载下的参照系。

8. 信息缺口与后续观察

1. Anyscale 最新的商业数据还看不到。 这次找到了 2021–2022 年的融资信息、客户页和云生态合作信息，但没翻到能确认最新 ARR、付费客户数、留存率或云市场收入的公开资料。

2. Ray OSS 与 Anyscale Runtime 的性能差距需要更多独立实测。 Anyscale 文档列出了 Runtime 在性能、checkpoint、autoscaling、dashboard、Serve 优化等方面的能力，但这些主要来自官方资料；独立、可复现、跨工作负载的长期 benchmark 还缺。

3. 安全边界仍要持续盯着。 Ray 从 2.52.0 开始支持 token 认证，但文档显示默认还是关闭的，只说未来版本计划默认开启。后面得关注默认认证策略会不会改，以及类似 ShadowRay 的攻击还会不会出现。

4. Azure 的原生集成仍在 preview。 Microsoft Learn 文档显示 Anyscale on Azure 目前是 Public Preview，在 region、功能和 CLI 上有限制；它能不能转正 GA、功能会不会补齐，是观察 Anyscale 企业分发能力的一个重要看点。

5. 同类对比还可拉上 Modal、Runpod、SkyPilot、Slurm / HPC 调度栈。 本篇第 7 栏先选了 Spark、Dask、Kubernetes/KubeRay 作为基础参照；如果后面做深挖，可以补进 AI workload scheduler、serverless GPU、HPC / Kubernetes 混合调度层的对比。

9. 归纳洞察 ★

Ray / Anyscale 呈现的是 AI 基础设施里一个很清晰的分层：模型训练、数据处理、批量推理、在线服务这些工作负载，越来越像是同一条 AI 计算流水线上的不同环节，而不是各自独立的工具。Ray 试图用一个 Python-native 的分布式运行时把这些环节串在一起，Anyscale 则把运行时进一步包装成企业可以用的控制平面、Runtime、托管部署和资源调度平台。

它的核心生态位不是“做模型”，也不是“做应用”，而是夹在 PyTorch / vLLM / Kubernetes / 云 GPU 之间，解决 AI 工作负载的分布式执行和资源利用问题。Ray 进入 PyTorch Foundation 之后，这个定位就更明白了：开源 AI 技术栈里，除了模型框架和推理引擎，还需要一个能把数据处理、训练、推理和调度串起来的计算层。

这个项目也说明了一件事：AI 基础设施的商业化，往往不是直接卖开源项目本身，而是卖它在生产环境里那些麻烦的部分——部署、治理、可观测性、认证、资源调度、故障恢复、成本管理和企业支持。Anyscale 的机会和争议都集中在这儿：它有机会把 Ray 的开源采用转化成生产平台的价值，但也必须处理好 Ray OSS 和商业 Runtime 的边界、安全的默认配置、成本透明度以及多云部署的复杂度。

10. 来源与更新时间

• 信息截至(as_of): 2026-07-13
• 最后复查(last_checked): 2026-07-13
• 最后更新(last_updated): null