Pi0.5 ref 트랙 복원 + RoboCasa sim eval 경로 복구

TL;DR

발단: "pi0.5 학습 때 코덱 뭐가 빨랐지" 질문 → 답은 PyAV 12.8 ms vs torchcodec 0.73 ms (17×), decord는 AV1을 아예 못 엶. 그 결정이 반영된 launch_pi05_b{0,1,2}_ref.sh가 repo에도 git에도 없음을 확인.
원인: git 원격 HEAD가 9a2a2d4(260508)인데 ref 스크립트는 260508~0512 작성 → 미커밋 상태로 260606 디스크 사고에 소실. 남은 건 claude_reports HTML뿐.
복원 전 감사에서 지뢰 2개: (A) HF stats.json이 아직 broken — gripper q01 = -0.9252(실측 -1.000) → full close 명령 생성 불가. (B) B1 계획 dataset P2는 observation.state가 전부 0인데 ref config는 proprio=on → degenerate.
eval 쪽에도 조용한 버그: eval_pi05_envutils_poc.py의 state 추출이 broken legacy schema 하드코딩 → ref 트랙(H50 16-dim)과 train/eval 불일치 → loss 정상인데 SR만 0. 260520 pi05_delta와 동일 함정.
실측 검증: robocasa env 생성 → reset_to → render → step PASS. eval 하네스 end-to-end PASS. task→hdf5 map 24개 재생성. train_bc CLI flag 34/34 존재.

17×

torchcodec vs PyAV

복원 전 차단한 지뢰

복원/수정 파일

34/34

CLI flag 검증

task map 재생성

1 배경 / 목적

사용자 질문은 단순한 회상이었다 — "pi0.5 wandb validation 학습 때 코덱 뭐가 느리고 뭐가 빨랐더라". 기록을 추적하다 그 결정(video_backend=torchcodec)이 반영된 학습 스크립트 3종이 현재 repo에도 git 히스토리에도 없다는 것이 드러났다.

소실 경위: DreamData 원격 gr00t 브랜치 HEAD = 9a2a2d4 (260508 시점). ref 스크립트는 260508~260512에 작성돼 커밋되지 않은 채 260606 디스크 정리 사고로 삭제됐다. 생존 기록은 ~/repos/claude_reports/DreamData/의 HTML 리포트뿐.

따라서 목표를 셋으로 잡았다: (1) 코덱 결정 근거 회수, (2) 리포트 기반 스크립트 복원, (3) "그대로 복원하면 재발하는 버그"가 있는지 먼저 감사. 이어서 사용자가 "다른 세션에서 robocasa sim 바로 돌릴 수 있게" 요청해 eval 경로까지 확장했다.

2 Video backend — 원 질문의 답

데이터가 AV1 (libsvtav1) 로 인코딩돼 있던 것이 발단이었다. 260511 벤치마크 (mg30_real_h50 left cam, 30 random seek):

Backend	2-frame seek	3-cam aggregate	비고
decord	—	—	✗ AV1 open 실패
opencv VideoCapture	—	—	✗ seek 후 read() False
PyAV (libdav1d)	12.8 ms	38 ms	✓ 동작하지만 느림
torchcodec	0.73 ms	~2 ms	✓ 채택 (17×)

end-to-end __getitem__ warm은 44–48 ms → 12 ms (4×).

단, 학습 throughput 이득은 거의 없다: mini train 11.47 → 10.82 it/s. SiglipImageProcessor(resize 224 + normalize)가 더 큰 bottleneck이라, decode 가속의 실이득은 dataloader worker를 덜 써도 된다는 쪽이다.

# torchcodec은 dlopen 체인 때문에 셸에서 LD_LIBRARY_PATH를 export해야 로드된다 # libtorchcodec_core*.so → libavcodec → libopenvino → libstdc++(CXXABI_1.3.15) / libnppicc.so.12 PI05_VENV=~/conda_envs/envs/pi05 export LD_LIBRARY_PATH="$PI05_VENV/lib:$(ls -d $PI05_VENV/lib/python3.12/site-packages/nvidia/*/lib | tr '\n' ':')$LD_LIBRARY_PATH" # Python 안에서 os.environ으로 세팅하면 무효 (dlopen이 import 시점에 이미 끝남)

실측 대조 — 패치 有: torchcodec 0.5+cu128 OK / 패치 無: libnppicc.so.12: cannot open shared object file.

3 복원 전 자산 감사

스크립트를 다시 쓰기 전에 그것이 의존하는 것들이 아직 존재하는지 전수 확인했다.

자산	상태	근거
`robot-data-gen/.../train_bc.py`	생존 (후기 패치 포함)	aux mix + pi05_delta statefix 코드 존재
`libs/lerobot` (editable 0.4.3)	생존	pi05 optimizer/scheduler preset 확인
conda env `pi05`	생존	torchcodec 0.5+cu128, nvidia/npp
`Keh0t0/robocasa_mg30_real_v2` (HF)	생존	720 ep / 206,570 fr / state[16]
`Dataset/robocasa/mg30_real_h50` (로컬)	소실	디렉토리 자체 없음 → HF본으로 대체 가능
pi05 b0/b1/b2 ckpt	소실	outputs엔 frappe 계열만
`recompute_stats_action_state.py`	소실	→ 재작성
`mapping_heldout_to_hdf5.json`	소실	→ 생성 스크립트 신규 작성

재생성 가능한 것과 아닌 것

소실 자산이 다 같지 않았다. HDF5 원본(minhopark)이 살아있어 task→hdf5 map은 스캔으로 복구했고, 데이터셋은 HF 사본이 있었다. 반면 ckpt는 재학습 외에 방법이 없다. 복원 작업의 실제 비용은 "코드를 다시 쓰는 것"이 아니라 여기서 갈린다.

4 지뢰 — 그대로 복원했으면 재발했을 것들

① HF `stats.json`이 아직 broken

260514에 발견한 stats template 버그의 fix는 로컬 사본에만 적용됐고 HF push는 "Next Step"으로 남아 있었다. 그 로컬본이 260606에 소실 → 지금 HF에서 받으면 broken stats가 그대로 따라온다. HF 원본을 직접 열어 실측:

dataset	action q01[0]	gripper q01[6]	판정
`Keh0t0/robocasa_mg30_real_v2` (HF)	-0.8065	-0.9252	broken template
실측 기대치	-1.000	-1.000	—

gripper는 open(-1)/close(+1) binary로 98% 포화인데 q01 = -0.925면 QUANTILES unnormalize가 거기서 잘린다 → full close 명령이 물리적으로 생성 불가. 260514 리포트가 지목한 close-task SR=0의 결정적 원인 후보 그대로다.

대응: scripts/recompute_stats_action_state.py 재작성. --check로 진단만 가능. P2(133,920 fr)에 실행해 max |q01/q99 drift| = 0.8722 검출 확인.

② P2는 `observation.state`가 전부 0

260508 계획의 B1 dataset = dreamgen_robocasa_p2인데 실측 min = max = 0. ref config는 proprio를 켜므로(disable_proprioceptive_obs=false) 상수 0을 state 입력으로 학습하는 degenerate가 된다. → B1 기본 dataset을 dreamgen_robocasa_p3_<variant>_v2_droid(state 실제 값 존재)로 변경.

③ eval의 state 추출이 broken schema 하드코딩

eval_pi05_envutils_poc.py:extract_proprio_state가 legacy 레이아웃(joint_pos[7] + gripper[1] + zero[8])으로 고정돼 있었다. ref 트랙은 H50 16-dim으로 학습하므로 그대로 쓰면 train/eval 입력 불일치다.

이 부류가 가장 위험하다 — 학습은 정상으로 보이고 eval만 0이 나온다. 260520에 pi05_delta에서 똑같은 구조(observation.state가 (2,16)으로 malform)로 v1/v2/normfix 세 실험 결과를 전부 무효화한 전례가 있다.

--state_schema h50 # mg30_real_v2 / DAVIAN H50 / MG_30 ← ref 트랙 전부 --state_schema legacy # Keh0t0/robocasa_heldout_real (broken 8-dim) 로 학습한 구 ckpt --state_schema zero # DreamGen P2 (zero-state) # h50 레이아웃 (16-dim) state[0:3] robot0_base_to_eef_pos state[9:12] robot0_base_pos state[3:7] robot0_base_to_eef_quat state[12:16] robot0_base_quat state[7:9] robot0_gripper_qpos

5 복원물 & 검증 결과

파일	구분	내용
`launch_pi05_b0_ref.sh`	복원	real only (mg30_real_v2)
`launch_pi05_b1_ref.sh`	복원	synth only — P2→P3 변경 (지뢰 ②)
`launch_pi05_b2_ref.sh`	복원	real+synth 5:5 mix
`recompute_stats_action_state.py`	재작성	지뢰 ① 해소
`build_task_hdf5_map.py`	신규	소실된 mapping 파일 대체
`eval_pi05_envutils_poc.py`	수정	`--state_schema`, `--ckpt_dir`, 경로 계산 버그
`run_pi05_eval_24tasks.sh`	수정	코드 루트 / map 자동생성 / ref 트랙

config는 DAVIAN 완료 run(...chunk=50-correct-prep, eval/SR=0.75) 정렬: chunk 50 / n_action 25 / eff batch 64 / proprio on / gradient_checkpointing off / lr 1e-4 cosine warmup 1000→2.5e-6 / num_workers 16 / torchcodec / seed 1000.

scheduler_decay_steps=20000을 명시한 이유: 기본 30000이면 CosineDecayWithWarmupSchedulerConfig.build()가 scale_factor = 20000/30000으로 warmup을 667로 auto-scale 해버려 DAVIAN의 1000과 어긋난다.

실측 검증 (login GPU 1장)

항목	결과
robocasa env 생성 → reset_to → render → step 5회	PASS (doors init 0.938 / 0.934)
H50 state key 5종 존재/정합	5/5, `base_to_eef_pos` [0.235,-0.025,0.585] vs H50 [0.234,-0.026,0.585]
eval 하네스 end-to-end (frappe ckpt)	PASS — ckpt→preprocessor→select_action→env.step→mp4→summary.json
`build_task_hdf5_map.py`	24 task 생성 (heldout 셋과 정확히 일치)
train_bc CLI flag 대조	스크립트가 쓰는 34개 flag 전부 존재 (MISS 0 / 전체 420개 중)
torchcodec import 대조	패치 有 OK / 無 `libnppicc.so.12` 실패
`bash -n` / `py_compile`	7개 파일 전부 통과

검증 안 한 것: 의미 있는 SR (평가할 pi0.5 ckpt가 없음 — smoke에 쓴 pi05_frappe_base는 frappe 변형이고 로드 시 embed_tokens.weight missing key 경고가 뜬다). 실제 학습 실행. --pad_state_first=true는 DAVIAN config에 대응 항목이 없어 추론으로 넣은 유일한 값.

6 Takeaway

ref config 자체는 검증된 recipe다. 260520 리포트가 launch_pi05_b0_ref.sh를 "working SR recipe"로 명시했고, 이 recipe 기반 통제 실험(Job 4933)이 2K step SR 0.60 → 5K 0.80을 냈다.
위험은 config가 아니라 데이터·인터페이스 쪽에 남아 있었다. 스크립트만 복원했으면 stats 지뢰와 state schema 불일치를 그대로 재현했을 것이고, 둘 다 "학습은 정상, SR만 0"으로 나타나 원인 규명에 며칠이 걸리는 부류다.
sim/eval 코드는 지금 바로 돌아간다. 막힌 건 평가할 ckpt가 없다는 것 하나뿐.
커밋되지 않은 스크립트는 사고 한 번에 사라진다. 이번 복원분은 즉시 커밋 대상.

7 Next

# 1) stats fix — 안 하면 close-task가 죽는다 python scripts/recompute_stats_action_state.py --repo_id Keh0t0/robocasa_mg30_real_v2 hf upload Keh0t0/robocasa_mg30_real_v2 meta/stats.json --repo-type=dataset # 2) 200-step smoke → 본 학습 (4 GPU, 20K step, ~6h) conda activate pi05 sbmr 5 "bash scripts/launch_pi05_b0_ref.sh" --gres=gpu:4 -c 32 --mem 800GB --qos=extra # 3) 24-task eval sbm "EXP_DIR=pi05_b0_ref_4gpu STATE_SCHEMA=h50 bash scripts/run_pi05_eval_24tasks.sh" \ --gres=gpu:1 -c 8 --mem 200GB --qos=extra

smoke 로그에서 확인할 3줄: torchcodec 로드 / Updated preprocessor: PI05PadStateProcessorStep / v3.0 reader의 episode_index 파싱
DAVIAN 0.75와 비교 시 relaxed threshold(0.15) 판정 차이 감안 — strict 0.05면 GT replay도 70%밖에 안 된다
미복원: run_pi05_eval_watch_chain.sh, push_eval_to_wandb.py

자립형 handoff (다른 세션용): claude/260806/HANDOFF_robocasa_sim_eval.md — 환경/Quick start/지뢰 7개/파일 인덱스/검증 범위.