simple-world-lab/HiFi-UMI-2K는 로봇 없이 수집한 bimanual manipulation 데모 2,000시간을
LeRobot v3 포맷으로 배포한 데이터셋이다 (CC BY 4.0, arXiv:2607.25895). 6-view 동기 비디오 +
3 mm 정확도의 양팔 EEF 궤적 + 언어 라벨을 포함한다.
단 1 바이트의 비디오도 받지 않고 HF API만으로 repo 전체를 계측했다. 5 TB를 받아보고 나서 "생각보다 크네"를 깨닫는 비용을 피하는 것이 목적.
| 항목 | 전체 398 shard | shard당 | 비중 |
|---|---|---|---|
| 총계 | 16.04 TB (14.59 TiB) | 37.5 GiB | 100% |
video head_main | 2.852 TB | 6.67 GiB | 17.8% |
video head_main_stereo_right | 2.837 TB | 6.64 GiB | 17.7% |
video right_hand_up | 2.591 TB | 6.06 GiB | 16.2% |
video right_hand_down | 2.579 TB | 6.03 GiB | 16.1% |
video left_hand_down | 2.578 TB | 6.03 GiB | 16.1% |
video left_hand_up | 2.574 TB | 6.02 GiB | 16.0% |
data/*.parquet + meta/ 전부 | 0.033 TB | 0.081 GiB | 0.2% |
마지막 shard chunk-0397만 예외적으로 작다 (140 ep / 4 task / 18.7 GiB). 나머지 397개는 균일.
0~397에 균등 배치한 17개 shard의 tasks.parquet을 비교했다.
chunk-0000~0123 같은 연속 구간을 받으면 task 다양성을 크게 잃는다.| 병렬 스트림 | 처리량 | 1 TB | 5 TB | 16 TB (전체) |
|---|---|---|---|---|
| 1 | 32 MB/s | 8.7 h | 43 h | 139 h |
| 8 | 133 MB/s (1.1 Gbps) | 2.1 h | 10.4 h | 33.5 h |
| 16 | 251 MB/s (2.0 Gbps) | 1.1 h | 5.5 h | 17.8 h |
/home/nas_main = 370 T GPFS, 현재 55 T free / 86% 사용)data/ + meta/는 모든 안에서 선택한 shard 전부에 대해 항상 포함.
| 안 | view | shard당 | 1 TB | 3 TB | 5 TB | 398 shard 전부 |
|---|---|---|---|---|---|---|
A head_main만 | 1 | 6.75 GiB | 137 | 398 = 전체 2,000 h | — | 2.88 TB |
| B head stereo pair | 2 | 13.39 GiB | 69 | 208 | 347 (~1,745 h) | 5.72 TB |
| C head + 양손 up | 3 | 18.83 GiB | 49 | 148 | 247 (~1,242 h) | 8.05 TB |
| D head + 손목 4개 | 5 | 33.2 GiB | 30 | 90 | 150 (~750 h) | 13.21 TB |
| E 6 view 전부 | 6 | 37.53 GiB | 24 | 74 | 124 (~624 h) | 16.04 TB |
1~5 TB 예산으로 충분히 의미 있는 규모를 받을 수 있다. 그리고 트레이드오프가 "view 수 ↔ 시간(h)" 단 한 축으로 깔끔하게 환원된다는 것이 이번 계측의 실질적 수확이다.
A안이 특이점이다. head_main 단일 view면 2.88 TB로 2,000시간 릴리스 전체를
빠짐없이 받을 수 있다. 5 TB 예산의 6-view(624 h)보다 시간 축으로 3.2배 넓다.
ego-view world model / 단일 시점 pretraining 목적이라면 다른 안을 고려할 이유가 거의 없다.
반대로 wrist view가 policy 입력에 필수인 VLA post-training이면 D/E로 가되 커버리지 손실을 감수해야 한다.
또 하나: shard 간 task 중복이 8%에 불과하다는 사실은 부분 다운로드의 품질이 "얼마나 받느냐"보다 "어떻게 고르냐"에 더 민감할 수 있음을 뜻한다. 균등 샘플링은 옵션이 아니라 기본값이어야 한다.
worker pod의 outbound 인터넷 접근 여부 미확인. 가능하면 CPU-only sbatch로 돌리는 게 깔끔하고,
불가하면 login node tmux에서 실행한다 (네트워크 I/O 바운드라 CPU 부하는 낮음).
소형 job으로 curl -I huggingface.co 한 번 찍으면 결론.
hf_xet은 openpi env에 미설치(hf_transfer는 있음). 실측 251 MB/s는 순수 curl 기준이므로
snapshot_download(max_workers=16)의 실효 처리량은 실행 후 재측정 필요.
view/shard 조합 확정 → scripts/download_hifi_umi.py 실행.
downloader는 view preset + shard 균등 샘플링 + resume을 지원하며 4개 시나리오에 대해 --dry-run 검증 완료.