Ray 到底解决了什么问题？为什么 AI 团队都在用它

📝

Ray 提供一套统一的分布式计算抽象——用 Task 表达无状态计算、Actor 表达有状态计算、ObjectRef 表达异步依赖、逻辑资源表达调度需求，从单机到多机用同一种方式描述。

痛点场景

800 组模型参数需要评估，每组 2 分钟：单进程 26 小时。16 核 CPU 理论只需 2 小时。但引入多进程后：

• 800 个任务如何分配？
• 进程崩溃后失败任务怎么办？
• 一台机器不够，怎么扩展到多台？
• CPU/GPU 异构资源怎么管？
• 长期状态如何保存？

→ 这就是 Ray 要解决的。

四大核心抽象

概念	用途	判断标准
Task（@ray.remote 函数）	无状态计算：文件分片、模型参数评估、批量推理	不需要保存状态 → 优先用 Task
Actor（@ray.remote 类）	有状态计算：模型常驻 GPU、计数器、聚合器	需要跨调用保存状态 → 用 Actor
ObjectRef	异步结果 + 任务依赖串联	不用 ray.get() 取中间结果，直接传给下游
逻辑资源	声明 num_cpus=2, num_gpus=1	调度准入，非 OS 级资源隔离

数据流设计

data_ref = load_data.remote()
transformed_ref = transform.remote(data_ref)    # 直接传 ObjectRef
total_ref = summarize.remote(transformed_ref)

中间不需要 ray.get()，Ray 自动等待依赖就绪并安排执行。

故障处理

Ray 提供 Task/Actor/Object/节点的故障处理机制，但不承诺 exactly-once 语义。如果任务带有外部副作用（如数据库写入），仍需要考虑幂等、事务或去重。

用 Ray 就一定更快吗？

不一定。 并行有成本：调度开销、序列化、Worker 启动、数据传输。几微秒的函数拆成几千个 Task，调度开销可能比函数本身还大。

什么时候值得用：

• 单任务耗时较长
• 任务数量大
• 资源需求复杂（CPU + GPU 混合）
• 需要跨多台机器

什么时候不该用：

• 任务本身很短
• 单机进程池已经够用

一句话总结

Ray 是一套统一的分布式计算抽象：Task（无状态）+ Actor（有状态）+ ObjectRef（异步依赖）+ 逻辑资源（调度），由运行时统一调度——当你的任务正在从单机走向多机，Ray 才真正值得引入。

本文转载自微信公众号「xnzone」。