RayOrch：让多模态数据处理兼顾并行效率与数据血缘

导语

基础模型的数据准备，往往不是把一条记录送入一个算子那么简单。一份文档可能被拆成数量不固定的页面，一段视频可能展开为大量帧，后续步骤还可能继续对这些子项进行识别、清洗和结构化。任务数量具有长尾分布，处理完成顺序也不稳定，但最终结果仍必须回到正确的父对象，并保持原有顺序。RayOrch 针对的正是这类多粒度、动态扩展的数据流水线。

核心要点

• 显式表达父子关系。 RayOrch 允许程序声明有序、可变数量的扩展操作，以及与之匹配的聚合操作。编译器会检查扩展和聚合是否成对，减少应用层手动维护分组关系的负担。
• 跨父对象组批。 运行时为每个调用维护 FIFO 就绪队列，把不同父对象下已经准备好的子任务汇集起来交给 GPU 执行。这种方式比以完整文档或完整视频为单位调度，更容易填满 GPU，也能适应子任务数量差异。
• 按血缘和序号还原结果。 系统记录子项成员关系、直接父节点、不可变序号及终止状态。聚合阶段依据这些信息重建结果，而不是依赖批次边界或任务完成顺序，因此乱序执行不会改变输出结构。
• 更细粒度的推进和故障处理。 当一个父对象所需的子任务全部进入终止状态后，后续阶段即可继续，不必等待其他父对象。若某个父对象发生特定类型的失败，尚未派发的兄弟任务可以被抑制，而无关父对象仍能继续处理。

实测表现

论文在 NVIDIA H20 GPU 上评估了 RayOrch 的扩展能力：MinerU 从 4 张 GPU 扩展到 64 张时，报告最高 15.14 倍加速；一个视频处理流水线从 8 张扩展到 64 张时，达到 7.82 倍加速。在 MinerU 端到端测试中，RayOrch 相比 Ray Data 快 13.1%，相比 Daft 快 29.0%；在 Docling 测试中，相比 Ray Data 快 16.0%。这些数字属于论文给出的特定工作负载结果，实际收益仍会受到算子开销、数据分布和集群配置影响。

意义与影响

RayOrch 的价值不只是提供一个新的调度器，而是把数据血缘、动态并行和结果聚合放进同一套编程抽象中。对于文档解析、视频理解等需要频繁在不同粒度之间切换的流程，这可以减少应用代码中的 regroup、排序和失败重试逻辑，并让 GPU 批处理更贴近真实的可用任务。

不过，系统的适用性仍取决于流水线是否具有明确的父子扩展结构，以及运行时元数据管理带来的成本。它更像是对现有数据处理框架的补充，而不是所有批处理场景的替代方案。RayOrch 代码已开源，后续值得关注其在更多模型数据管线、异构资源和生产级容错场景中的表现。

来源：Hugging Face Daily Papers