${VAE_TYPE}를 매칭에 포함하지 않아, job 33146/33147(Cosmos 태그)이 실제로는 Wan VAE로 학습되고 있었음 — 크래시 없이 조용히 잘못된 실험 진행 중attrs["num_samples"] overreport로 OOB → T_stored 클램프로 수정, job 37399로 재개keep_last_n=3 + milestone_every=10000 자동 정리로 해결260709 latent normalization 진단(claude/260708/research-cosmos_latent_normalization.md) 이후, fp32 재전처리 + latent normalize + 재산출된 Conv3d init을 적용한 Cosmos-norm 학습을 새로 launch하는 과정에서, train_lgm_robocasa_vggt_v0.sh launcher와 robocasa_dataset.py 데이터로더에 누적돼 있던 문제들이 잇따라 드러났다. 이 버그들은 대부분 크래시를 내지 않고 조용히 잘못된 결과를 만들어내는 유형이라, 방치했다면 GPU-hour를 들여 무효한 실험을 계속 쌓을 위험이 있었다.
발생 순서대로 원인을 추적해 각각 launcher 스크립트(bash) 또는 학습 스크립트(python)에 patch를 적용했다.
| # | 버그 | 원인 | 수정 |
|---|---|---|---|
| 1 | 33146/33147 exp dir 공유 | launcher grep이 ${VAE_TYPE} 없이 lgm_robocasa_vggt_v0_${STITCH_TAG}_만 매칭 → Cosmos job이 Wan dir를 재개해 두 job이 동시에 같은 파일에 write | grep 패턴에 ${VAE_TYPE} 포함 |
| 2 | 33146/33147이 실제로는 Wan으로 학습됨 | launcher가 --vae_type $VAE_TYPE을 python에 전달하지 않아 default(wan)로 fallback | STITCH_ARGS에 --vae_type $VAE_TYPE 추가 |
| 3 | 37231/37232이 renamed 백업 dir을 재개 시도 | grep이 substring 매칭이라 _nonorm_fp16depth suffix가 붙은 완주 백업 dir도 여전히 매칭 | grep -E '_[0-9]{4}_[0-9]{4}$'로 strict anchor 적용 |
| 4 | fp16 depth quantization | HDF5에 depth가 float16 저장 → OpenGL z-buffer 0.99 근방에서 metric 변환 시 ~0.4m 계단식 오차 | 사용자가 fp32로 재전처리 완료 (본 세션 이전) |
| 5 | 37234 IndexError (step 3950) | fp32 재전처리 후 일부 demo의 attrs["num_samples"]가 실제 저장 frame 수보다 커서 linspace가 OOB index 생성 | robocasa_dataset.py에서 T_stored = depth.shape[0]로 clamp |
| 6 | phaseB_50000.pt 미저장 | save_every 조건이 step % 500 == 0인데 max_steps 도달 시점이 이 조건을 안 맞고 루프가 종료돼 최종 ckpt 누락 | max_steps 도달 시 phaseB_{max_steps}.pt 강제 저장 로직 추가 |
| 7 | 디스크 2.5TB 방치 | ckpt cleanup 로직 부재 — 500 step 간격 × 최대 100회 × 5.2GB/파일이 그대로 누적 | _prune_ckpts(keep_last_n=3, milestone_every=10000)를 매 save 후 자동 호출 |
| 항목 | Before | After |
|---|---|---|
| exp dir 재사용 오탐 | substring 매칭, VAE 구분 없음 | ${VAE_TYPE} + strict anchor로 정확 매칭 |
| 33146/33147 상태 | Cosmos 태그로 Wan 학습 중 (오염) | exp dir 삭제, launcher 수정 후 재제출 |
| 37234 IndexError | step 3950에서 크래시 | clamp 적용 후 37399로 재개, step 3500까지 재발 없음 |
| 최종 ckpt 저장 | 50000 step 도달해도 미저장 사례 발생(완주 3개 run이 phaseB_45000이 실질 최종) | max_steps 강제 저장 로직 적용 |
| 디스크 사용량 | ~2.5TB (500 step × 100 checkpoint × 5.2GB) | ~110GB (milestone {10K,20K,30K,40K,45K} + 최근 3개만 유지) |
phaseB_49500.pt가 함께 삭제되어, 완주 run들의 실질 최종 체크포인트는 phaseB_45000.pt가 되었다 (5K step 차이는 eval에는 무시 가능한 수준으로 판단).버그 #1~#3은 전부 "크래시 없이 조용히 틀린 데이터/설정으로 학습이 진행되는" 유형이었다 — 에러 로그를 봐서는 절대 발견할 수 없고, exp dir 이름과 실제 로드된 VAE weight를 교차 검증해야만 드러난다. 향후 VAE/backbone/stitch 등 여러 축을 조합하는 ablation launcher는 exp dir naming에 모든 축을 명시적으로 포함하고, 재개 시 assert로 config 일치 여부를 검증하는 방어 로직이 필요하다는 교훈을 남겼다.
디스크 회수(2.5TB→110GB)는 단기적으로 여러 ablation을 동시에 돌릴 수 있는 여유를 확보했다는 점에서, 이번 주 진행 중인 Cosmos-norm 2-run 외에 추가 축(예: Wan fp32 재학습)을 병행할 물리적 여유가 생겼다.
attrs["num_samples"] overreport의 근본 원인(fp32 재전처리 스크립트 자체의 버그)은 아직 확인되지 않았다 — 현재는 dataset loader에서 clamp로 방어만 하고 있어, 다른 방식으로 overreport가 나타나면 다시 드러나지 않을 위험이 있다.
37399(_0709_0341/) 로그를 slurms/taewoongkang_37399.out에서 계속 모니터링해 IndexError 재발 여부 확인. 재발하지 않으면 clamp가 충분한 방어로 확정, 재발하면 fp32 전처리 스크립트 자체를 재점검해 근본 원인 수정.