X-WAM depth 학습 자체 재현 가능성 분석

TL;DR

가능합니다. 파이프라인은 이미 이 클러스터에서 20,000 step 완주 이력이 있고 4개 loss 전부 단조 수렴했습니다(total 2.77→0.42, depth 0.449→0.101).
단 그 재현본은 baseline으로 쓸 수 없습니다. 릴리스 레시피와 3가지가 달랐습니다 — pretrained 초기화 없음, 1 GPU(global batch 4 vs 32), 데이터 노출 0.27 epoch. 결과 SR 11.0% vs 릴리스 75.3%.
막고 있던 병목은 해소됐습니다 — pretrained 체크포인트(37GB)를 이번에 확보했고, 데이터셋도 로컬 완비(1,235 ep / 5.2GB).
재실행 비용: 8 GPU · 20k step ≈ 7~8 h(실측 0.845 step/s 기반), checkpoint 111 GB/개.

가능

재현 가능성

7~8 h

8 GPU · 20k step

111 GB

checkpoint 1개

11.0%

이전 재현 SR (무효)

1왜 자체 재현이 필요한가

목표는 depth 대신 point cloud로 학습했을 때의 효과 측정입니다. 그런데 배포된 robocasa_sft 체크포인트와 직접 비교하면 변수가 섞입니다 — 학습 환경, 데이터 셔플, 하드웨어, 미공개 세부 설정이 모두 다릅니다. point cloud 변형의 순수 효과를 보려면 같은 환경·같은 recipe로 돌린 depth 버전이 대조군으로 있어야 합니다.

즉 필요한 것은 "논문 수치 재현"이 아니라 내부적으로 통제된 A/B의 A입니다. 다만 A가 릴리스 수치와 크게 벗어나면 recipe 자체가 틀렸다는 뜻이므로, 릴리스 SR 75.3%에 근접하는지가 A의 유효성 검사가 됩니다.

2확인된 것 — 가능하다는 근거

항목	상태	근거
학습 데이터	완비	`X-WAM-RoboCasa` 로컬 5.2 GB — 1,235 episodes / 341,017 frames / 3뷰 × (video + depth) 전부 존재. `sft_datasets/RoboCasa` 심링크 연결됨
초기화 체크포인트	확보	`checkpoints/pretrained/` 37 GB (5,800h 사전학습). config가 요구하는 `pretrained_checkpoint` 경로와 일치 — 이번에 다운로드해서 해소된 병목
코드 실행 검증	완주 이력	Lightning + DeepSpeed ZeRO-2 + bf16-mixed로 step 0 → 19,999 완주. validation 영상도 0/2500/…/20000 전 구간 생성됨
학습 건전성	수렴 확인	4개 loss 전부 단조 감소 + val PSNR 개선 (아래 표)
preempt 대응	구현됨	`scripts/train_sft_repro.py`에 최신 checkpoint 자동 resume 패치. 실제로 2회 preempt 후 재개해 완주(tb_logs version_0/1/2)
평가 파이프라인	가동 중	`scripts/eval_robocasa.sh`로 24-task SR 측정 이력 다수 (릴리스 ckpt 75.3% 포함)

실측 학습 곡선 (이전 재현본, tb_logs 파싱)

loss	0–1k	5k	10k	19–20k
train/loss	2.766	0.682	0.492	0.423
train/video_loss	0.584	0.224	0.203	0.197
train/depth_loss	0.449	0.143	0.117	0.101
train/action_loss	0.830	0.214	0.096	0.066
train/proprio_loss	0.903	0.102	0.076	0.059

val/rgb_psnr: 17.92 → 18.24 → 17.81 → 17.81 → 18.32 → 18.63 → 19.05 → 18.76 dB (2.5k step 간격). 학습 자체는 정상 작동합니다.

3⚠️ 핵심 문제 — 이전 재현본은 대조군으로 부적합

완주는 했지만 릴리스 recipe와 3가지가 달랐습니다.

항목	릴리스 recipe	이전 재현본 (`vanilla_repro`)	근거
초기화	`pretrained/` (5,800h)	null → wan22_5b 원본 base	`experiments/vanilla_repro/config.yaml`의 `pretrained_checkpoint: null`
world_size	8 (README `--nproc_per_node=8`)	1	checkpoint에 `bf16_zero_pp_rank_0` 단 하나만 존재
global batch	32 (4 × 8)	4 — 8배 작음	`batch_size_per_gpu=4`, `accumulate_grad_batches=1`
데이터 노출	~2.15 epoch	0.27 epoch	clips ≈ 296,557, epoch 인덱스가 끝까지 0에 머묾

결과: 24-task 평균 SR 11.0% (53/480, job 48099) vs 릴리스 robocasa_sft 75.3% (1808/2400). 약 64 %p 차이 — 이 상태로는 point cloud 변형과 비교할 baseline이 될 수 없습니다.

해석: 세 가지가 겹쳐 있어 각각의 기여를 분리할 수는 없지만, X-WAM의 핵심 주장이 "video foundation model의 사전학습 prior 활용"인 만큼 pretrained 초기화 누락이 지배적 요인일 것으로 봅니다. 당시엔 그 체크포인트가 로컬에 없어 불가피한 선택이었고, 지금은 해소됐습니다.

4자원 요구량

자원	필요량	근거 / 비고
GPU	8	릴리스 recipe(global batch 32) 재현에 필요. core 그룹 `own` 상한과 정확히 일치
시간 (compute)	≈ 7~8 h	실측 0.845 step/s(1 GPU) → 20k step 6.6 h. 8 GPU는 GPU당 batch가 같아 step time 유사 + allreduce 오버헤드 → 0.7~0.8 step/s 추정
시간 (wall)	--time 12:00:00	이전 실행은 preempt 2회로 11.4 h 소요(중복 재학습 ~2~3k step 포함). 여유 포함 권장
디스크	111 GB × N	model `mp_rank_00_model_states.pt` 36.2 GB + optimizer `bf16_zero_pp_rank__optim_states.pt` 74.6 GB. `save_top_k=-1`·`every_n_train_steps=5000` → 5k/10k/15k/20k + last = 최대 ~555 GB*
CPU / RAM	`-c 64 --mem 1600GB`	`num_workers_per_gpu=8` × 8 GPU = 64 worker. sbm 8-GPU 표준값과 일치
큐 대기	발생 예상	분석 시점 클러스터 120/120 GPU 사용 중(avail 0). core/sub/free 전부 여유 0 → `--qos=own`으로도 대기 필요

디스크는 미리 정리하는 편이 좋습니다. 555 GB는 GPFS 여유(64 T) 대비 문제없지만 낭비입니다. save_interval을 10000으로 올리거나 save_top_k를 제한하면 절반 이하로 줄고 모델 품질에는 영향이 없습니다(체크포인트 저장 정책일 뿐). 기존 vanilla_repro/checkpoints/last.ckpt 111 GB도 무효 실험이므로 회수 대상입니다.

5권장 실행 계획

config 수정 (2줄) — 새 실험명 + pretrained 초기화 복원. 나머지는 릴리스 recipe 그대로 둡니다.
exp_name: depth_baseline_v1 pretrained_checkpoint: ./checkpoints/pretrained/checkpoints/last.ckpt # (선택) save_interval: 10000 ← 디스크 절약, 품질 무관
스모크 테스트 — 로그인 1 GPU에서 ~100 step. 확인 항목: pretrained 로딩 성공(load_state_dict 경고 없음), 4개 loss가 낮은 값에서 시작(초기화가 먹혔다는 신호 — 이전엔 total 2.77에서 시작), step/s 실측.
본 학습 — sbmr로 preempt 자동 재개. train_sft_repro.py의 resume 패치가 이미 검증됨.
conda activate xwam sbmr 5 "bash scripts/train_depth_baseline.sh" \ --qos=own --gres=gpu:8 -c 64 --mem 1600GB --time 12:00:00 -J xwam_depth_base
유효성 검사 — scripts/eval_robocasa.sh로 24-task SR 측정 후 릴리스 75.3%와 비교.
합격 기준 판단 — 아래 표 참조.

재현 SR	해석	다음 행동
70 % 이상	recipe 재현 성공 — 유효한 depth baseline	point cloud 실험 착수
50–70 %	부분 재현. 배치·스텝·데이터 셔플 등 잔여 격차	baseline으로 사용 가능하나 A/B 양쪽을 동일 조건으로 돌리고 절대 수치는 인용 자제
50 % 미만	recipe에 아직 빠진 요소 있음	point cloud 진행 전 원인 규명 필요 (init 로딩·통계·데이터 경로 재점검)

중요: A/B 비교의 관점에서는 절대 SR이 75.3%에 못 미쳐도 치명적이지 않습니다 — depth와 point cloud를 같은 환경에서 돌리면 상대 비교는 성립합니다. 다만 baseline이 너무 낮으면(예: 11%) 두 조건 모두 바닥에 깔려 차이가 안 보이므로, 충분히 학습된 baseline 확보가 실험 감도의 전제입니다.

6다음 단계 스케치 — point cloud 표현으로의 전환

(이번 분석 범위는 depth 재현이므로 아래는 설계 방향 메모입니다.)

X-WAM은 depth를 pseudo-RGB(그레이 3채널)로 타일링해 RGB와 같은 VAE에 통과시킵니다. 이 구조를 살리는 가장 침습이 적은 전환은 pointmap — 픽셀별 XYZ를 3채널 이미지로 두는 것입니다.

방안	아키텍처 변경	장점	위험
(a) pointmap (픽셀별 XYZ 3채널)	거의 없음 — depth의 1채널 복제 대신 XYZ를 3채널로. 슬롯 수·VAE 동일	정규화 문제가 자연 해결(XYZ는 metric). PointWorld 계열과 정합. 뷰별 스케일 얽힘 소멸	VAE가 RGB 통계로 학습돼 XYZ 분포에 부적합할 수 있음
(b) 별도 point encoder	큼 — 인코더/토크나이저 추가	표현력 상한 높음	사전학습 prior를 못 씀 → X-WAM의 핵심 이점 상실

데이터 준비는 이미 가능합니다. RoboCasa cam_cache에 뷰별 intrinsic + 프레임별 extrinsic이 있고, sim GT depth를 world/camera XYZ로 unproject하는 코드도 이미 작성해 검증했습니다(tmp/viz_droid_calib.py의 adjust_K / unproject_world, tmp/viz_robocasa_multi.py). 즉 depth → pointmap 변환은 기존 코드 재사용으로 해결됩니다.

부수 효과로, 이번 조사에서 확인한 X-WAM의 결함(에피소드별·뷰별 min-max 정규화 → metric 복원 불가 + wrist 스케일 얽힘)이 pointmap에서는 구조적으로 사라집니다. "왜 point cloud인가"에 대한 동기가 이미 정량 근거로 마련돼 있습니다.

7불확실성 & 확인이 필요한 것

8 GPU 처리량은 추정치입니다. 실측 0.845 step/s는 1 GPU 값이고, 8 GPU에서의 step time은 allreduce 오버헤드에 따라 달라집니다 → 스모크 테스트에서 확정 필요.
이전 재현본의 3가지 편차 각각의 기여도는 분리 불가합니다. pretrained init이 지배적일 것으로 추정하지만 검증된 바는 아닙니다. (원한다면 init만 복원하고 1 GPU로 다시 돌려 분리 가능 — 다만 6.6 h 추가 비용.)
flash-attn 부재로 SDPA 폴백 상태입니다(xwam env). 이전 재현본도 동일 조건이었으므로 A/B 비교에는 영향 없지만, 릴리스 수치와의 절대 비교에는 잔여 변수입니다.
학습 job의 slurm 로그가 정리돼 당시 정확한 제출 파라미터(GPU 수·QOS·시간)는 checkpoint 구조와 tb 메타데이터로 역산했습니다.
클러스터가 만석(120/120)이라 착수 시점은 큐에 좌우됩니다. --qos=own은 preempt 면역이지만 대기는 발생합니다.