Ray

一句话定位

Ray 是面向 Python/AI 工作负载的分布式运行时，用 task、actor、object store 和资源调度组织跨进程、跨节点工作。

它负责

  • 启动和管理 task、actor 与 GPU workers
  • placement group、资源调度和故障恢复
  • 组织 learner、rollout、reward 与 environment workers
  • 通过 Ray Train/Serve/Data 提供更高层能力

它不负责

  • 不定义 Transformer 或 Attention
  • 不执行 attention kernel
  • 不替代 PyTorch autograd
  • 不替代 DeepSpeed/ZeRO 的训练状态切分
  • 不等于 vLLM 的 KV Cache 与请求调度算法

适合拆开的工作流

1
2
3
4
5
Kubernetes/节点资源
→ Ray placement group
→ actor/task（learner、rollout、reward、env）
→ object store / checkpoint
→ 训练或服务编排

Ray 的价值在跨进程角色和生命周期，不在替代 GPU kernel 或模型并行。若任务只是单机多卡训练，先用 PyTorch DDP/DeepSpeed；引入 Ray 前要确认确实需要异构 actor、弹性 rollout、故障恢复或跨节点编排。观察指标应包含 actor 重启、对象存储拷贝、GPU 利用率和端到端队列等待。

相关节点：Kubernetes、Agentic RL。

一个 actor 工作流如何落地

以 rollout/learner 训练为例，Kubernetes 先把 head、worker 和存储服务放到节点上；Ray 再根据 placement group 把 rollout actor、环境 actor 和 learner 放进满足 GPU/CPU 约束的 worker。actor 之间通过 object reference 或显式消息传输轨迹，learner 完成更新后再把权重版本发布给 rollout。这里的权重同步和 checkpoint 是应用语义，不能由 Pod 重启自动推导出来。

1
2
3
4
5
6
resource request
→ Pod scheduled and Ray worker registered
→ placement group reserves role topology
→ actor produces object/trajectory
→ learner consumes and publishes checkpoint/weight version
→ rollout accepts only a declared staleness window

什么时候 Ray 是多余的

如果作业只有一个训练进程、资源拓扑固定、失败后从外部 checkpoint 重启即可，Ray 只会增加 head、object store 和调试层。先用 DDP/DeepSpeed 或服务自己的 worker 管理；只有当任务需要动态 actor、异构资源、gang placement、弹性 rollout 或跨任务数据流时，Ray 的控制抽象才有回报。验证方式是删除 Ray 后比较代码复杂度、恢复时间和资源利用率，而不是看 Ray 组件数量。

故障分析要同时看两层：Pod Running 只说明容器活着，actor 可能已经死循环或 object store 爆满；Ray actor ALIVE 也不代表 GPU 上的模型权重版本正确。至少记录 worker 注册、actor 重启、placement pending、object store spill、权重版本和端到端队列等待。

与 Kubernetes 的边界

Kubernetes 负责 Pod、节点、容器资源和服务生命周期；Ray 负责已获得资源内的 task、actor、placement group 与对象流。两层可以协作，但不会自动替彼此恢复应用状态：Pod 重启后，Ray 仍需重新注册 actor；actor 重启后，应用仍需从 checkpoint 或外部状态恢复权重与轨迹。