TL;DR
- 네, 더 잘합니다. hand-off 상태(물체를 든 채 시작)의 val 39,040프레임에서 action 오차 −22.0%, 릴리즈를 좌우하는 gripper 오차 −36.4% (mix20k → place10k)
- 기존 태스크는 손해 없음 — Pick 21.0→21.0(성공 횟수까지 동일), PnP 37.0→41.0, NextTo 14.0→17.0. 평균 24.0 → 26.3%로 지금까지 평가한 전 ckpt 중 최고
- 통제된 A/B: init(
pi05_droid)·step(10k)·batch 동일, place 0.20 추가만 다름. (원래 mix@10k 이어받기였으나 스크립트 버그로 droid 시작 → 오히려 깔끔한 설계가 됨)
- Q2(goal image)는 같은 조건에 goal만 켠 학습(107367)이 방금 시작. 약 7시간 뒤 val goal on/off로 판정
−22.0%
val 오차 (all) · 39,040 샘플
26.3%
rollout 3태스크 평균 (역대 최고)
±0 / +4 / +3
Pick / PnP / NextTo Δ%p
1실험 설계
학습 job 105831 · init pi05_droid · 10k step · batch 256 · 8×B200 · 7h13m · loss 0.0050
main 0.30 / Pick 0.15 / PnP-p0 0.10 / NextTo 0.15 / Color 0.10 / place 0.20
비교 mix v2 @10k — init·step 동일, place 없음 (5종, main 0.35/0.20/0.10/0.20/0.15)
평가① rollout HardBench 200ep × {Pick, PnP, NextTo} → 기존 태스크 유지 여부
평가② val open-loop L1 (house 단위 분리 460궤적 / 39,040프레임) → hand-off 배치 능력
비교군: droid0(학습 전) · mix20k(place 없음; mix10k는 삭제됨) · place10k
평가②가 왜 필요한가: PnP/NextTo HardBench는 깨끗한 초기 상태에서 집기+놓기를 재므로 물체를 든 채 넘겨받는 hand-off 상황을 측정하지 못한다.
val의 모든 프레임은 그 hand-off 분포에서 나온 관측이라, 여기서의 action 예측 오차가 가장 직접적인 대리 지표다.
2결과 ① — rollout, 기존 태스크는 망가지지 않았나
| 벤치 (200ep) | mix v2 @10k | place @10k | Δ | z |
|---|
| Pick | 21.0% (42) | 21.0% (42) | ±0 | 0 |
| PnP | 37.0% (74) | 41.0% (82) | +4.0%p | +0.82 |
| NextTo | 14.0% (28) | 17.0% (34) | +3.0%p | +0.90 |
| 평균 | 24.0% | 26.3% | +2.3%p | — |
세 태스크 모두 유지 또는 상승. 개별 상승폭은 노이즈 범위(|z|<1)지만 방향이 일관되고, 평균 26.3%는 전 ckpt 최고다(이전 최고 mix@10k 24.0%).
place 데이터는 프레임 기준 전체의 0.7%인데 샘플의 20%를 차지해 약 28배 오버샘플링됐음에도 부작용이 없다.
3결과 ② — val open-loop, hand-off 배치를 잘하나
| 모델 | all (8d×16) | arm (7d) | gripper (1d) | step0 (8d) |
|---|
| zero 예측 (기준선) | 0.2362 | — | 1.0004 | — |
| droid0 (MolmoSpaces 학습 전) | 0.3926 | 0.3684 | 0.5618 | 0.4249 |
| mix20k (place 없음) | 0.1116 | 0.1062 | 0.1495 | 0.1097 |
| place10k | 0.0870 | 0.0859 | 0.0950 | 0.0856 |
| place10k vs mix20k | −22.0% | −19.1% | −36.4% | −21.9% |
gripper −36.4%가 핵심이다. hand-off 배치에서 가장 어려운 건 "언제 놓느냐"인데,
mix20k는 물체를 든 채 시작하는 궤적을 본 적이 없어 릴리즈 타이밍이 흔들린다(0.1495). place 데이터가 정확히 이 부분을 가르쳤다.
사용자가 말한 "잘 내려놓지를 못해"가 이 숫자로 드러난다.
droid0가 zero 예측보다 나쁘다(0.3926 > 0.2362). DROID 사전학습의 action 분포가 MolmoSpaces와 달라 정규화 공간에서 방향 자체가 틀린다.
MolmoSpaces 학습이 오차의 71.6%를 걷어내고, place 데이터가 거기서 22%를 더 걷어낸다 — 두 단계의 기여가 분리돼 보인다.
스모크 n=32의 gripper 0.003은 착시였다. 전체 val에서는 0.095. 32샘플이 우연히 쉬운 프레임이었다.
당시 "n=32라 믿지 말라"고 단서를 달았던 것이 그대로 맞았다 — 소표본 수치는 방향 확인용으로만.
4해석과 한계
place 데이터는 "공짜 점심"에 가깝다. 목표 능력은 확실히 오르고(val −22%, gripper −36%), 기존 태스크는 잃은 게 없이 소폭 오른다(평균 +2.3%p).
val L1과 rollout이 같은 방향을 가리킨다는 점은 val L1이 대리 지표로 쓸 만하다는 간접 증거이기도 하다.
- val은 open-loop다. 예측 오차가 작아도 closed-loop에서 누적되면 실패할 수 있다. 최종 판정은 2-stage 파이프라인의 실제 place 성공률.
- mix20k 기준선은 20k step이라 place10k(10k)와 step이 다르다. mix10k가 외부 삭제돼 불가피했다. rollout에서 mix10k(24.0)와 mix20k(20.0)의 차이가 작아 step 차이로 22%를 설명하긴 어렵지만, 완전한 통제는 아니다.
- rollout 개별 상승(+4, +3%p)은 통계적으로 노이즈 범위. "손해 없음"은 확실하고 "상승"은 방향만 확인.
5Q2로 — goal image가 큰 의미가 있는가
place10k와 init·step·혼합비·지시문을 완전히 동일하게 두고 3번째 이미지 슬롯에 goal만 켠 학습이 시작됐다(job 107367, pi05_mlspaces_place_goal, dropout 0.5).
완료 후 val을 goal 켜고 / 끄고 두 번 재서 place10k와 비교하면 goal의 순효과가 나온다.
예상되는 함정: 지시문이 정밀한 NextTo 문장("Place the X next to the Y")이라 언어만으로 위치가 풀리면 모델이 goal을 무시할 수 있다.
그 경우 goal on/off 오차가 같게 나올 텐데, 그것도 "이 설정에서는 의미 없음"이라는 유효한 답이다. replace처럼 언어로 특정 안 되는 위치를 goal이 채우는 상황은 후속 실험(거친 지시문 + goal)으로 분리.
오늘의 인프라 사고 3건 (전부 수습)
| 사고 | 원인 | 수습 |
|---|
| val 3잡 OOMKilled → JobHeldAdmin | openpi TorchDataLoader는 무한 반복. 종료 조건 없이 3.6 epoch(157k) 돌다 RAM 초과 | 인덱스에서 길이 계산 → num_batches로 1 epoch 고정. 부분 수치(0.0870/0.1117)는 정식과 일치 |
goal 학습 1차(107304)가 place/에 붙어 place/10000에서 auto-resume | GOAL 블록 EXP_NAME이 ${VAR:-} 우선순위로 무시(함정 #17 재발) | 1분 19초에 취소. ckpt 무사, 최상위 train_config.pkl만 덮어써져 ckpt assets에서 복구. resume 가드 추가 |
mix/10000·part1/15000 등 중간 ckpt 소실 | 04:27 외부 세션 정리(추정). 이 세션 학습의 cleanup은 로그상 자기 dir만 삭제 | 수치는 유효, 이어받기 불가. place/{5000,10000} 보존 요청 |