RayOrch, 멀티모달 데이터 준비에 계보 기반 병렬 처리 도입

배경

파운데이션 모델을 위한 데이터 준비는 단순한 레코드 단위 처리와 다릅니다. 하나의 문서는 여러 페이지로 나뉠 수 있고, 동영상은 수많은 프레임으로 확장된 뒤 인식, 필터링, 구조화 단계를 거칩니다. 입력마다 생성되는 하위 항목의 수가 다르고 긴 꼬리 분포를 보일 수 있기 때문에, GPU를 효율적으로 사용하려면 여러 부모에서 준비된 작업을 함께 배치해야 합니다. 그러나 최종 결과는 원래 문서나 동영상에 연결되고, 자식 항목의 순서도 유지되어야 합니다. RayOrch는 이 문제를 데이터 계보를 보존하는 실행 모델로 다룹니다.

핵심 설계

• 부모-자식 관계를 프로그램에 포함. 사용자는 순서가 있고 개수가 가변적인 확장 연산과 이에 대응하는 집계 연산을 선언합니다. 컴파일러가 두 연산의 대응을 검증하므로, 애플리케이션이 평면 레코드를 직접 다시 묶는 부담을 줄일 수 있습니다.
• 부모를 넘나드는 GPU 배치. 각 호출에는 FIFO Ready Queue가 유지됩니다. 서로 다른 문서나 동영상에서 실행 가능한 자식 작업을 모아 GPU에 전달하기 때문에, 부모별 자식 수가 크게 달라도 자원을 채우기 쉽습니다.
• 완료 순서가 아닌 계보로 복원. 런타임은 자식의 소속, 직접 부모, 변경되지 않는 순번, 종료 상태를 기록합니다. 따라서 작업이 순서 없이 끝나거나 여러 배치로 나뉘어도, 배치 경계에 의존하지 않고 원래 결과 구조를 재구성할 수 있습니다.
• 부모 단위의 진행과 장애 격리. 한 부모에 필요한 자식 작업이 모두 종료 상태가 되면 해당 부모는 다음 단계로 진행할 수 있습니다. 특정 부모에서 유형이 지정된 장애가 발생하면 아직 배포되지 않은 형제 작업을 중단하고, 관련 없는 부모는 계속 처리합니다.

보고된 성능

NVIDIA H20 환경에서 MinerU를 4개 GPU에서 64개 GPU로 확장했을 때 15.14배, 동영상 파이프라인을 8개에서 64개로 확장했을 때 7.82배의 가속이 보고됐습니다. MinerU 엔드투엔드 비교에서는 Ray Data보다 13.1%, Daft보다 29.0% 처리 시간이 줄었고, Docling에서는 Ray Data보다 16.0% 개선됐습니다. 다만 이는 논문에 제시된 특정 워크로드의 결과이며, 실제 효과는 연산 비용, 입력 편차, 클러스터 구성에 따라 달라질 수 있습니다.

의미와 한계

RayOrch의 핵심은 스케줄링만 개선한 것이 아니라 데이터 계보, 동적 병렬화, 결과 집계를 하나의 추상화로 결합했다는 점입니다. 문서 파싱과 동영상 이해처럼 처리 과정에서 데이터의粒度가 반복적으로 바뀌는 파이프라인에서는, GPU 병렬성을 확보하면서 순서 복원과 실패 처리를 애플리케이션 코드에서 직접 구현하는 부담을 낮출 수 있습니다.

반면 부모-자식 확장 구조가 뚜렷한 작업일수록 적합성이 높으며, 모든 배치 처리 엔진을 대체하는 범용 해법이라고 보기는 어렵습니다. 공개된 구현이 더 다양한 멀티모달 워크로드와 실제 운영 환경의 장애 대응에서 어떤 결과를 낼지는 추가 검증이 필요합니다.

출처: Hugging Face Daily Papers