能力边界

724 字约 2 分钟

RayOrch 有意保持为一层小而明确的编排能力：它负责在 Ray 上协调有限、多阶段的 AI 工作负载，但不会替代周围的计算引擎和基础设施。

RayOrch 提供什么

用静态、无环的 Pipeline 显式表达阶段依赖。
用常驻 Ray Actor 承载普通的批量 Python UDF。
完成驱动调度：某个下游任务的输入一旦到齐，就可以立即开始。
用 expand、filter、broadcast、reduce 显式表达基数变化和血缘。
按阶段配置 CPU、GPU、副本数、批处理和 Ray runtime_env。
借助已有 Ray 集群进行多机、多卡执行。
有界恢复策略、失败感知的结果重建，以及内部死锁检测。
Benchmark 懒加载注册、参数化运行、Ray Job 提交和可复现报告。

仍由用户或平台负责什么

模型计算： vLLM、SGLang、PyTorch 等引擎仍然负责实际推理或处理。
集群运维： 节点发现、资源放置、通信和资源统计仍由 Ray 负责。
环境准备： RayOrch 可以为阶段选择 runtime_env，但不会自动在所有节点创建一致的 Conda 环境。
数据分发： 模型、数据集和输出路径必须预先对相应节点可见。
外部调用超时： RayOrch 能发现内部状态无法继续推进，但无法中断永远阻塞的任意 UDF；模型客户端和外部服务应自行配置超时。
副作用幂等： 恢复策略可能再次调用 UDF。启用重试时，对外部系统的写入需要由业务保证幂等。

当前模型不覆盖的工作负载

当前运行时面向有限、按行对齐的输入和静态无环图，目前不提供：

无界流处理、窗口和长期流式 checkpoint；
动态修改拓扑或反馈环；
任意跨输入 join；
外部副作用的 exactly-once 保证；
自动构建各类模型后端所需的运行环境；
所有负载都一定快于直接使用 Ray 的保证。

当负载包含多个异构阶段、不规则的展开或聚合、昂贵的常驻模型，并且具有足够的独立任务可供完成驱动调度和批处理重叠时，RayOrch 最有价值。

超时的职责划分

需要区分三种情况：

内部语义死锁： 当活跃输入批次无法推进且没有待完成 RPC 时，RayOrch 会主动报错。
UDF 或外部服务阻塞： 应在对应 UDF 或客户端内部设置超时。
等待已提交的 Ray Job： BenchmarkRun.wait(timeout_s=...) 只限制客户端等待时间；若还要终止远端 Job，需要显式调用 run.stop()。

这种划分比设置一个看似统一、实际无法安全覆盖所有模型与外部系统的全局超时更明确。