Cosmos Predict2 Path B — DROID 2×2 그리드 8GPU 본학습 착수

TL;DR

Path 선택: DROID로 학습된 진짜 멀티뷰 체크포인트는 없음(Cosmos-Predict2.5는 auto/multiview, robot/multiview-agibot뿐) → DROID init을 살리려면 Predict2.0 14B Cosmos-Predict2-14B-Sample-GR00T-Dreams-DROID 기반 2×2 그리드 single-view(Path B)를 사용해야 함. 사용자가 Path B 선택.
B200 비호환 오진단 → 정정: 초기 torch.randn @ 스모크에서 "no kernel image available" 발견해 B200 불가로 결론냈으나, 실제 원인은 apex가 sm_80/90 커널만 등록하는 것. torch nightly cu128 + apex/flash-attn/TE 제거로 해결(과거 260409 문서에 이미 recipe 존재).
Dry-run 성공: job 31933(4GPU, max_iter=10) COMPLETED, loss iter1 0.938 → iter2-10 0.26~0.95, 6.7s/iter. DROID pretrained 정상 활용 확인(random init이면 loss ~15).
본학습 RUNNING: job 31988(8GPU, 20k step, sbmr 5-retry) iter200 도달, loss 0.20~0.41, 6.77s/iter. 전체 grid stitch 70,492 + T5 임베딩 70,492 완비.

0.20~0.41

loss @iter200

6.77s

iter time (8GPU)

20K

target steps

~37h

예상 소요

1 배경 / 목적

사용자가 "DROID로 학습된 checkpoint를 초기화로 쓰면 도메인 일치로 더 빨리 수렴할 것"이라 판단해 DROID init을 요구했다. Cosmos-Predict2.5 계열(2B, cu128, B200-native)은 이미 3-view 파인튜닝 준비가 진행 중이었지만(별도 카드 참조), DROID로 사전학습된 진짜 멀티뷰 체크포인트는 존재하지 않는다 — Predict2.5의 multiview 계열은 auto/multiview(AV) 또는 robot/multiview-agibot(camera-conditioned, 다른 네트워크) 두 종류뿐. DROID-pretrained Cosmos 비디오 모델은 nvidia/Cosmos-Predict2-14B-Sample-GR00T-Dreams-DROID (Predict2.0 / 14B / single-view)가 유일하다.

트레이드오프: 진짜 멀티뷰(Path A, 2.5/2B)는 즉시 dry-run 가능한 상태였지만 DROID init이 없다. DROID init(Path B, 2.0/14B)은 3뷰를 2×2 그리드 한 장으로 붙이는 트릭이 필요하고 착수 비용이 훨씬 크다(env 재빌드, 14B ckpt 다운로드, CPU-heavy grid stitch, stale 경로 수정). 사용자는 Path B를 선택.

2 작업 내용

Path B 본체는 DreamData/cosmos-predict2/(Predict2.0). Experiment 등록: predict2_video2world_training_14b_groot_robocasa_mg30_480(cosmos_predict2/configs/base/experiment/groot.py), dataset=robocasa_mg30, num_frames=93, video_size=(432,768)(2×2 그리드 832×480 → 리사이즈).

데이터 준비 2단계

1. scripts/prepare_robocasa_for_cosmos.py --src_dir /home/nas_main/hyojinjang/DATA/robocasa_mg3000_droid_lerobot_20fps_v2_merged --dst_dir cosmos-predict2/datasets/benchmark_train/robocasa → 3뷰(exterior_1_left, exterior_2_left, wrist_image_left)를 2×2 그리드로 stitch (좌상 exterior좌, 우상 exterior우, 좌하 wrist, 우하 검정) + DROID_PROMPT_TEMPLATE + metadata.csv → 70,492 grid videos (CPU-only sbatch, gres:gpu=0 -c32 --mem128G, num_workers=30, job 31938, ~2.8h) 2. scripts/prepare_robocasa_mg30_official.py → minhopark HDF5 mask에서 공식 30-demo/task 서브셋 심링크 → robocasa_mg30 (dry-run/pilot용)

B200 호환 recipe (260409 문서 재적용)

초기 스모크에서 torch.randn @부터 "no kernel image available for execution on the device"가 나와 Path B 전체를 B200 비호환으로 오판했다. 사용자 지적으로 정정 — 과거(260409)에 이미 B200에서 돌린 이력과 recipe가 DreamData/claude/260409-cosmos_b200_compat.md에 문서화되어 있었다.

1. torch 2.6+cu126 → nightly cu128 uv pip install --reinstall --prerelease=allow torch torchvision --index-url https://download.pytorch.org/whl/nightly/cu128 (--prerelease=allow 필수) 2. flash_attn / transformer_engine / apex 제거 → apex가 sm_80/90 커널만 등록 → "no kernel image available" 근본 원인 3. 코드 fallback (이미 repo에 반영): - text2image_dit.py: TE RMSNorm → torch.nn.RMSNorm, RoPE native fallback - optimizer.py: adamw 등록 (mg30 experiment는 override /optimizer: adamw, apex-free) - fused_adam*.py: apex lazy import, qwen2_5_vl.py: flash_attn assert→warning 4. opencv-python → opencv-python-headless (libGL 없음)

본학습 제출

sbmr 5 "bash scripts/run_cosmos_train_robocasa_full_14b_droid_8gpu.sh" \ --gres=gpu:8 -c 64 --mem 1600GB --qos=extra --time=2-00:00:00 (own qos는 기존 job 31825가 8GPU 점유 중 → extra + sbmr auto-requeue) fsdp_shard_size=8, CP=1, max_iter=20000, DROID init, NVTE_FUSED_ATTN=0 optimizer: fusedadamw → adamw (apex 제거로 인한 수정, groot.py) ckpt rotation: checkpointer.py에 _prune_old_checkpoints(keep_n) 추가, env COSMOS_KEEP_LAST_N=3 (model/optim/scheduler/trainer 4폴더, resume 대상은 항상 보존)

3 결과

Job	구성	Loss	속도	상태
31933	4GPU, max_iter=10, robocasa_pilot(200ep)	iter1 0.938 → iter2-10 0.26~0.95	6.7s/iter	COMPLETED, ExitCode 0 (5:59)
31988	8GPU, max_iter=20000, robocasa(70,492 grid)	iter200: 0.20~0.41	6.77s/iter	RUNNING

DROID pretrained 정상 활용 확인: dry-run loss가 0.26~0.95 수준으로, random init 시 예상되는 ~15 대비 훨씬 낮음 — DROID checkpoint의 사전학습 지식이 실제로 전이되고 있음을 시사.

비치명적 이슈: 일부 짧은 에피소드가 93프레임×fps_downsample_4를 못 채워 "insufficient frames"로 dataset이 random 재샘플로 스킵. 70k 중 극소수라 학습 진행에 지장 없음(필요시 min-length 필터로 metadata.csv 정리 가능).

DROID DiT ckpt

27GB

VAE tokenizer

485MB

T5-11B encoder

43GB

Grid videos

70,492

4 Takeaway

의미

DROID init의 이점(도메인 일치 → 빠른 수렴)은 실재하며, dry-run loss 수치로 실제 활용을 확인했다. 한때 "B200 비호환"으로 성급히 결론냈던 것은 근본 원인 분석 부족 때문이었다 — apex의 sm_80/90 하드코딩 커널이 실제 원인이었고, torch nightly cu128 + apex/TE/flash-attn 제거라는 이미 문서화된 recipe로 완전히 해결됐다. 같은 예산(8GPU)으로 Path A(진짜 멀티뷰, DROID init 없음)와 Path B(그리드 트릭, DROID init 있음)가 동시에 진행 중이므로, 두 경로의 수렴 속도/최종 품질을 비교할 수 있는 위치에 있다.

5 Next Steps

미해결 한계

20k step ≈ 37h 장기 학습 — extra qos라 own 사용자 job이 들어오면 preempt 가능(sbmr 5-retry로 대응 중이나 checkpoint rotation이 keep_n=3이라 preempt 타이밍에 따라 최신 ckpt 손실 리스크는 낮지만 0은 아님). "insufficient frames" 스킵 비중을 정량화하지 않음.

다음 작업

job 31988 모니터링(sjob 31988 / tail 로그). 완료 후 DCP→pt 변환 + scripts/run_cosmos_inference_robocasa.sh로 3뷰 그리드 비디오 생성 확인. Path A(predict2.5 multiview) dry-run 결과 나오면 두 경로 loss curve/생성 품질 비교.