RayOrch: 面向基础模型数据准备的谱系受控多粒度数据流编程与执行

TL;DR RayOrch 为基座模型数据准备构建保留父子血缘的多粒度数据流引擎,支持跨父项 GPU 批处理与有序收集,在 MinerU/视频流水线扩展加速 15.1/7.8 倍。

问题

基础模型训练依赖高质量数据准备流水线，需将异构文档、视频转换为结构化记录并高效利用 GPU。

现有方法局限：现有数据流水线系统通常只能在两种不完美方案中取舍：

• 粗粒度函数将每个文档或视频视为不透明作业，掩盖了可并行处理的页面、片段或帧；
• 扁平记录函数暴露单个项目，但强制应用自行维护每个项目的父级归属、位置、完成跟踪，并在全局重组结果以重建原始对象。 这两种方式割裂了并行执行与血缘管理，导致 GPU 利用率低或开发负担重、正确性难保证。

为什么难：流水线中处理单元动态变化，父项产生有序、输入依赖的子项序列，且子项数量跨父项呈长尾分布。GPU 需要在不同父项之间批量子项以最大化利用率，同时系统必须保留父子关系、子顺序、完成状态和结果路由。这一矛盾使数据准备成为基础模型训练的关键瓶颈，也解释了 RayOrch 在 NVIDIA H20 上 4 至 64 GPU 扩展 MinerU 取得 15.14 倍加速的原因。

行业类比：类似 PDF 解析流水线中将文档拆分为页面并行 OCR，但需按原始文档聚合页面以重建结构化内容。

核心洞察

• RayOrch 将数据管线的 lineage 建模为一等公民，通过声明式 expansion-gather 对保持 parent-child 关系，使 GPU 批处理与结果归组完全解耦。现有系统要么用 coarse-grained job 隐藏可并行的 children，要么将数据展平为 flat record 并强制应用自行维护 lineage 与 regroup；而 RayOrch 由编译器静态验证 expansion-gather 匹配，运行时记录每个 child 的 membership、ordinal 和 terminal state，gather 不依赖 batch boundary 或 completion order，parent 可以在所有必需 child 完成后立即推进，从根本上消除了应用层的手工状态跟踪。
• RayOrch 的 Per-Call FIFO Ready Queues 实现跨 parent 的 child 批处理且保持顺序与完成状态，配合 typed parent-scoped failure，形成针对长尾分布数据管线的高效调度与故障隔离机制。常规批处理通常按 batch 或 completion order 聚合，破坏 lineage；RayOrch 让 ready children 进入队列按 FIFO 顺序派发到 GPU，既保证吞吐又保留 child 的不可变 ordinal，同时当某个 parent 失败时，系统只抑制该 parent 尚未派发的 sibling，其他 parent 继续执行。这一设计解决了多模态数据准备中 child counts 长尾分布带来的 GPU 利用率不稳定和故障扩散问题，是相比 Ray Data、Daft 等系统在端到端时间上取得 13–29% 提升的关键。

方法

输入与编程模型

RayOrch 将数据准备管道建模为父子关系数据流。输入为异构文档 / 视频等原始项，每个父项通过声明式变基数 expansion 生成有序子项序列，子项数量具有长尾分布。

关键模块

1. 编译期结构验证：开发者声明 expansion 与匹配的 gather，编译器验证每一对 expansion-gather 的结构一致性。
2. 运行时 lineage 记录：系统记录每个 expansion 的具体子集、子项的 immediate parent、不可变 ordinal 以及结果 terminal 状态，保证血缘关系可追踪。
3. Per-Call FIFO Ready Queues：调度器维护每个 call 的 FIFO ready 队列，跨父项批量收集 ready 子项，提升 GPU 利用率。
4. Gather 语义重建：gather 依赖声明的成员关系和 ordinal 重建父结果，不依赖 batch 边界或完成顺序，父项在所有必需子项 terminal 后即可推进。
5. 失败隔离：采用 typed parent-scoped failure，失败父项的未调度子项被抑制，无关父项继续执行。

输出

最终输出为保持父子关系、子项顺序、完成状态和正确结果路由的父项结果。

与同类方法差异：现有系统要么以粗粒度 job 隐藏并行机会，要么以 flat record 暴露子项却要求应用手动管理 lineage 与 regrouping；RayOrch 通过内置 lineage 状态和声明式 expansion-gather 契约，将父子关系贯穿执行始终，免去应用层的手动协调。

实验

实验设计

• 评测在 NVIDIA H20 GPU 上进行，覆盖 MinerU(文档解析)和一个视频处理流水线，扩展规模为 4→64 GPU。
• 端到端对比基线为 Ray Data 与 Daft；另设调度消融和 lineage 范围内故障隔离测试。

关键发现

• MinerU 从 4 到 64 GPU 扩展获得 15.14× 加速；视频流水线从 8 到 64 GPU 获得 7.82× 加速。
• 在 MinerU 上，端到端时间比 Ray Data 减少 13.1%，比 Daft 减少 29.0%；在 Docling 上比 Ray Data 减少 16.0%。
• Per-Call FIFO Ready Queues 跨 parent 批量 ready children，Gather 基于 lineage 的 member/ordinal 重建结果，避免依赖 batch boundary 或 completion order。

与基线对比解读

• 增益来自保持 parent-child lineage 与按 Call 级 FIFO batching，减少全局 regrouping 和 completion tracking 开销；Ray Data/Daft 的 flat record 模型迫使应用自行管理 lineage，带来额外 group by 成本。
• 故障隔离按 parent scope 抑制未调度 sibling，允许无关 parent 继续，比全局失败恢复更细粒度，适合长尾、大规模数据准备任务。

行业影响

落地场景

RayOrch 适合基础模型数据准备 中多粒度、长尾展开的管道:文档解析(如 MinerU/Docling)、视频切帧、网页抽取。可落地于电商多模态商品表征、内容平台视频理解、企业知识库构建等业务。

商业价值

通过跨父级批处理 与父级作用域失败隔离 提升 GPU 利用率,降低无效重算。论文显示 MinerU 从 4 到 64 GPU 扩展获 15.14 倍加速,端到端较 Ray Data 快 13.1%、较 Daft 快 29.0%。直接缩短训练数据生产周期,加速模型迭代。

与现有产品/工作流接口

RayOrch 基于 Ray 生态,提供声明式 expand/gather 原语,编译器校验配对。现有 Ray Data/Daft 管道可渐进替换数据准备阶段,应用只需声明父子关系与聚合逻辑,运行时自动管理血缘、顺序和终态,无需手动重组。

具体落地用例

• 电商多模态搜索:解析商品详情页,展开为标题/图片/属性片段,GPU 批量嵌入,按商品聚合向量。
• 视频审核平台:切分长视频为镜头/帧,分布式识别违规内容,结果按原始视频有序汇总,便于定位。

局限

• **实验评估的硬件与基线范围较窄。** 所有性能数据均基于 NVIDIA H20 GPU 测得，未验证在 A100、H100 或 CPU 集群上的表现，结论的普适性存疑。对比系统仅限 Ray Data 和 Daft，缺少与 Spark、Beam 等更通用数据流引擎的横向比较，尤其在处理非层级数据时，RayOrch 的优势可能被高估。此外，论文未讨论在超大规模集群（如数千节点）下调度器或元数据存储的单点压力，扩展性上限不明确。
• **编程模型对 parent-child 结构的依赖较强。** RayOrch 的核心抽象是 ordered variable-cardinality expansion 与 matching gather，这天然适合文档解析、视频切片等结构化提取任务，但对更通用的数据流图（如多路 join、shuffle 重分区、迭代计算）支持不足。若应用无法表达为清晰的层级展开关系，用户仍需回退到 Ray Data 等通用系统，造成混合架构的运维负担。论文未提供与这些通用场景的对比或兼容策略，限制了其作为通用数据准备基础设施的潜力。
• **容错机制的可靠性缺乏充分验证。** 论文提出了 typed parent-scoped failures 和 commit/failure/recovery 流程，但缺少大规模故障注入实验（如节点宕机、网络分区）来量化恢复效率和正确性。实际生产中，子任务部分失败后父级如何重算、未被分发的兄弟任务如何清理、checkpoint 开销等均未详细评估。另外项目 GitHub star 数仅 17，社区反馈有限，生产级稳定性和 API 易用性尚未经广泛检验，可能影响早期采用者的信心。