Index
2026-08-21 — Plan

E2E 실행 SR 파이프라인 계획 — VLM eval 답 → 벤치마크 상태 복원 → VLA 실행

scene_bench | Tier B(접지+도달) / Tier C(VLA 실조작) · VLM 재호출 0 · 설계 승인·구현 계획 작성 완료

TL;DR

1,121
고유 (질의,답) 플랜
+353
oracle-loc 플랜
909
기권 행 (26%)
2.5 min
조작 1회 (실측)
≈45 GPU-h
Stage C 예상

1 배경 / 목적

두 트랙이 따로 굴러왔다. VLM eval(src/sbench_eval/, S3 260819)은 353질의 × 5전략 × 2모델에 {category, room, surface} 답을 받아 기호 수준(loc_set)으로 채점했고, Online 2-stage 제어(src/sbench_online/, N14 R5 260820)는 VLM subgoal → VLA 600스텝 조작 → 하네스 오라클 판정 루프를 실증했다. 사용자 목표는 "VLM이 뽑은 subtask를 실제로 VLA로 수행해 최종 Success Rate"이고, 직관은 "subtask는 이미 뽑혀 있으니 환경만 벤치마크 상태로 올려 online control로 SR만 뽑으면 된다"였다.

판정: 직관이 코드·데이터 실물과 맞는다. 설계 문서의 3-Tier 하네스(Tier A 기호 = S3 / Tier B 항법 물리 + 조작 오라클 / Tier C 풀스택) 중 B·C를 세우는 일이며, 공리 A3(메모리/제어 분리)를 지키는 분해식 SR_C = P(reached) × P(lift|reached)가 핵심 산출물이다.

2 실물 확인 — 두 트랙을 잇는 재료

필요한 것어디 있나상태
질의별 VLM 답(=플랜)tmp/s3_*/results.json rows: episode · query · strategy · answer.selections[{category,room,surface}] · gt[] · scores · labels있음 — 기권 909/3,530, 파스실패 0
벤치마크 종료 상태HF final_state.npz = names(25)·pose(25,7)·robot_base_pose(7)·frame (샘플 v1 states/final.npz 키 동일)있음
GT 채점 근거eval_spec.answers[]: body id · scoring lifted 634 / reached_only 125 · (v1) reach_min 0.65 / r_support 0.85있음 — "grasped body id로 채점"
같은 씬 재생성sampler.sample_task(house_index) + meta.scene_fingerprint(nbody 266, body sha)있음 — N10 렌더↔데이터셋 프레임 일치
상태 복원episode_state.restore_frame0 (h5 tracked pose → free-joint body, match_ratio≥0.9, T3 val_136 통과)npz 변형만 추가
항법 / 조작 / 판정nav0.teleport_to(receptacle 0.3–0.8 m) · run_episode(ScriptedPlanner) · PickTask.judge_success(lift≥1 cm+로봇만 접촉)있음 (exp_matrix.decisions_for 동일 패턴)
답 → 씬 접지eval facts.room_name_map(정수↔이름) ↔ 시뮬 inventory.snapshot() room 라벨 room_N(uid 접미사와 같은 인덱스)역매핑만 작성
MolmoSpaces 씬 save/restore본체 없음(R1). 대안 EpisodeSpec(object_poses, robot_base_pose, cameras) + JsonEvalTaskSampler폴백 경로

속도 실측: job 87852(N14 R5) = 600스텝 조작 16회 + 서버 워밍업 = 52분 → 조작 1회 ≈ 2.5 min/GPU. S3 결과 해부: 고유 (질의, 답집합) 플랜 1,121(질의당 3.2), 층 분포 find_target single lifted 1,015 / distractor single lifted 954 / reached_only 계 475 / multi 계 274.

3 설계 (승인본)

입력 단위 ExecPlan

(episode, query, source, selections[], category=질의 name, gt_bodies[], scoring, r_support). source ∈ {strategy×model 10셀, oracle-loc(GT 위치를 답으로 = 조작 ceiling), blind}. 동일 (질의, 답집합)은 dedupe → ≈1,470 실행.

Stage R — 복원

씬 빌드 → npz 25 pose + 로봇 base 복원 → 게이트: fingerprint(nbody/body sha) ∧ match_ratio ≥ 0.9 ∧ pose 오차 < 1 cm. 실패 시 JsonEvalTaskSampler 경로.

Stage B — 접지 + 도달 (CPU, 플랜당 수 초)

답 (room, surface) → room_N 안의 해당 가구 = 앵커. 국소 지각 오라클 규칙(A3, GT 불사용): 앵커 위에 support된 질의 카테고리 인스턴스가 있으면 그 인스턴스(uid 오름차순 첫 번째 — 쌍둥이 혼동은 그대로)로 접근(pick 반경 0–0.7 m), 없으면 가구 앞(0.3–0.8 m). 의미: "답의 granularity(방·가구)까지는 메모리 책임, '그 가구 위의 X'를 찾는 지각은 하네스가 대신". 도달 = min dist(base, GT) ≤ r_support(0.85). reached_only 질의는 여기서 최종.

큰 식탁은 중심 기준 0.3–0.8 m 안에 free point가 없어 N14에서 navigate 실패가 났던 경로 — 인스턴스 접근이 기본이고 가구-앞-서기는 답이 틀린 경우의 폴백이다.

Stage C — VLA 실조작 (GPU)

Stage B reached 플랜 + oracle-loc만. Stage B가 정한 베이스 포즈 그대로(재샘플 금지) ScriptedPlanner([pick, pick, done]); 프롬프트 단어 = 질의 카테고리("Pick up the bowl"), 판정 = GT body 집합 any-of(SubgoalDecision.prompt_name / judge_object_ids 신설). 수평선 600 × 재시도 2(≤1,200 ≤ budget 1,500). multi는 선택마다 반복 + retract_arm_home. 정책 mixv2-20k, 정책 입력 zed2(CAMERAS=sim_exo_random) / 기록 bench_exo_L — longmem 워커의 이중 운용 그대로. sbm 1-GPU 샤드 6개, 플랜 단위 체크포인트.

집계

셀별 SR_B / SR_C, 층별(kind/steps/scoring/twin/floor — S3 표와 같은 축). SR_C(s) = P(reached|s) × P(lift|reached); oracle-loc = ceiling, blind = 상식 바닥선, S3 loc_set ↔ SR_B 격차 = 접지/항법 손실.

src/sbench_exec/ plans.py S3 results + eval_spec → ExecPlan (dedupe, oracle-loc, cells.jsonl) restore.py final_state.npz 복원 + fingerprint 게이트 grounding.py 답 → 앵커/인스턴스 (순수 함수, GT 불사용) stage_b.py 접지 → teleport_to → 도달 판정 → stage_b.jsonl stage_c.py Stage B 포즈 고정 → run_episode(ScriptedPlanner pick×2) → stage_c.jsonl (샤딩) aggregate.py SR_B/SR_C 격자 + 분해식 + 층별 → summary.json/md sbench_online: SubgoalDecision.prompt_name/judge_object_ids, build_subgoal_task 프롬프트 오버라이드, orchestrator make_judge(any-of) scripts: run_stage_b.sh, run_exec_worker.sh (sbm inner, #SBATCH 없음)

4 게이트 / 규모

게이트내용규모
G0 스파이크val_144__2: fingerprint(nbody 266/sha) → npz 복원 match_ratio ≥ 0.9, pose 오차 < 1 cm, GT가 답 가구 위에 support되는지, bench_exo_L 렌더 ↔ 데이터셋 마지막 프레임CPU/EGL, 수 분
G1 Stage B 전량1,470 플랜 grounded/reached. oracle-loc reached ≈ 1.0 이어야1 잡, <1 h
G2 Stage C 스모크oracle-loc 10플랜 × mixv2 → P(lift|reached), 영상 확인1 GPU, ~30 min
G3 Stage C 전량B-통과 ~700–900 + oracle 353 ≈ 1,100 × 2.5 min ≈ 45 GPU-h → 6잡 병렬 ≈ 1일GPU
G4 리포트SR_B/SR_C 격자 + 층별 + 분해식 + 실패 클립

범위 밖

restore(샘플 v1): find 답(현재) + origin 답 → nav→pick→carry→place; eval 계약(from/to) 확장 뒤 같은 실행기에 pnp 플랜 추가. resume(type2): cut_*.npz가 mobile 11-dim 모델의 MuJoCo 전체 덤프(qpos 82)라 FR3 고정 베이스 모델과 nq 불일치 → 별도 embodiment 필요.

5 Takeaway / Next

왜 이 구조인가

벤치마크의 최종 지표는 총점 하나가 아니라 SR_C 격자 + 분해식이다. S3에서 본 층별 상보성(textlog=사건, 시각=본 것)이 실행에서도 유지되는지, 조작 ceiling(oracle-loc)이 메모리 차이를 얼마나 가리는지가 관전 포인트. Tier B는 headline이 아니라 Stage C의 배선·게이트이자 "접지/항법 손실"의 분리 장치다.