허깅페이스 스트리밍 데이터셋 업데이트

허깅페이스는 load_dataset('dataset', streaming=True) 기능을 크게 향상시켜 사용자가 로컬에 다운로드하지 않고도 멀티테라바이트 규모의 데이터셋에서 학습할 수 있게 했습니다. 이러한 최적화는 "디스크 공간 부족" 오류 및 429 속도 제한 응답과 같은 일반적인 문제를 제거하고, 고성능 컴퓨팅 환경에서 로컬 SSD 속도에匹配하는 성능을 제공합니다.

규모에서의 성능 향상

스트리밍 백엔드의 개선으로 대규모 학습에서 상당한 효율성 향상이 이루어졌습니다. 256명의 워커와 함께 64xH100 GPU에서 학습할 때, 허깅페이스는 다음과 같은 지표를 보고했습니다:

• Startup Requests: 최대 100배 더 효율적 (요청 수 감소).
• Data Files Resolution Time: 10배 더 빠름.
• Streaming Speed: 최대 2배 더 빠름.
• In-flight Requests: 최대 2배 더 효율적.
• Stability: 256명의 동시 워커에서 워커 충돌 없음.

기술적 최적화

성능 향상은 시작 및 스트리밍이라는 두 가지 주요 단계로 나뉩니다.

시작 최적화

각 DataLoader 워커가 독립적으로 데이터셋을 초기화하여 발생하는 "요청 폭풍"을 방지하기 위해 허깅페이스는 다음과 같은 기능을 도입했습니다:

• Persistent Data Files Cache: 첫 번째 워커가 허브에서 파일 목록을 해결하고, 이후 모든 워커는 로컬 캐시에서 읽어 실질적으로 중복된 시작 요청을 제거합니다.
• Optimized Resolution Logic: 파일 목록을 가져오기 위해 필요한 API 호출이 이제 더 효율적으로 묶여 지연 시간을 줄입니다.

스트리밍 처리량

GPU가 데이터를 기다리지 않도록 하기 위해 다음과 같은 기능이 추가되었습니다:

• Parquet용 프리페칭: 라이브러리는 모델이 현재 청크를 처리하는 동안 백그라운드에서 다음 데이터 청크를 미리 가져옵니다.
• 구성 가능한 버퍼링: 고급 사용자는 이제 버퍼의 블록 크기와 프리페치 볼륨을 조정할 수 있습니다. 예를 들어, 기본값인 32MiB에서 128MiB로 최소 요청 크기를 pyarrow.dataset.ParquetFragmentScanOptions를 사용하여 늘릴 수 있습니다.

데이터 전송 및 저장 인프라

허깅페이스는 업로드 및 다운로드를 가속화하기 위해 중복 제거 기반 저장 시스템인 Xet를 활용합니다. Parquet Content Defined Chunking (CDC) 를 활용하면 중복된 데이터는 한 번만 전송되어, 허깅페이스로의 업로드가 전통적인 원격 저장소보다 빨라집니다. 이는 pyspark_huggingface 패키지로 더욱 지원되는데, 이 패키지는 Xet과 Parquet CDC를 지원하는 Spark 데이터 소스를 제공하여 데이터셋의 읽기 및 쓰기를 가능하게 합니다.

맞춤 스트리밍 파이프라인

datasets 라이브러리가 기본적으로 지원하지 않는 형식이나 세부적인 제어가 필요한 사용자를 위해 허깅페이스는 huggingface_hub 라이브러리의 HfFileSystem을 개선했습니다. 이를 통해 .read(), .readline(), .seek() 를 사용하여 데이터셋 저장소의 파일을 효율적으로 원격으로 읽을 수 있습니다.

HfFileSystem이 PyTorch DataLoader에 전달되면, .ls()와 .glob()의 캐시된 결과를 재사용하여 데이터 파일 목록을 나열할 때 추가 요청이 필요하지 않게 됩니다. 이 접근 방식은 LeRobot 라이브러리에서 비디오 프레임 샘플링에 사용되고, WebDataset 라이브러리에서는 TAR 아카이브 스트리밍에 활용됩니다.

실제 적용 사례: nanoVLM

이러한 향상 기능은 다음 세대 SmolVLM을 위한 nanoVLM 개발 과정에서 실전 테스트를 거쳤습니다. 허깅페이스는 스트리밍이 이제 로컬 SSD에서 읽는 것과 동일한 속도임을 발견했으며, 이로 인해 로컬 SSD로 데이터를 전송하여 학습 시작이 세 시간 지연되었던 이전의 병목 현상이 제거되었습니다.