69b117f) · 방법론 감사(b444a9b) · goal 팔 분리 결정babysit_main.sh:22 는 OVER_COST_CAP 시 재제출을 포기 → 8샤드 중 7개가 중간에 멈춘 채 조용히 종료했을 것. 캡 20 으로 상향.--max-episodes 3 이라 잡당 3편 → 93편/2샤드 ≈ 샤드당 16회 재제출이 필요한데 babysitter 없음 → 범용 babysit_run.sh 신설.family==restore and strategy in TAGMEM 화이트리스트(능력이 아니라 이름으로 배제), M3 KEEP 판단은 exo‖wrist 타일인데 저장은 exo 원본, M4 시드 규모 tagmem 34줄+8장 vs 나머지 1~6줄. M2 는 유효 KEEP 0.237→0.092 로 정정.ROW_PATTERNS 고정 등 14항목.사용자 260920: "확실하게 오류 없이, 다시 측정하는 일 없게" → 제출 전 인프라 점검, 이어서 "prompt 나 세팅이나, 메모리 쪽 방법론에 문제가 있으면 안 된다" → 조건 자체 감사. 재측정 총액이 $120(restore 잔여 $73 + find vis-pure $21 + find tagmem $26)이고 Letsur 일일 캡 $100 을 이틀로 나눠 써야 해서, 한 번 망치면 하루가 날아간다. 재측정의 배경(execute-state 채널 개조)은 execute_state_keep_diag 참조.
| 샤드 | s0 | s1 | s2 | s3 | s4 | s5 | s6 | s7 |
|---|---|---|---|---|---|---|---|---|
| 칸 | 52 | 55 | 57 | 39 | 67 | 80 | 60 | 54 |
| 예상 비용 | $10.0 | $9.3 | $9.8 | $6.8 | $11.8 | $15.3 | $10.4 | $10.3 |
캡 $8 이면 7/8 샤드가 캡 초과. babysit_main.sh:22 가 OVER_COST_CAP 에서 재제출을 포기하는 것은 무한 재제출 방지 설계라, 런이 조용히 미완으로 끝난다.
--max-episodes 3(씬 메모리 누적 대책) → 잡 하나는 3편만 돌고 끝. 93편 / 2샤드 ≈ 47편/샤드 → 샤드당 ≈16회 재제출 필요, 재제출 주체 없음.
| # | 항목 | 결과 |
|---|---|---|
| A1–A3 | src_w2 import · sbench_eval 동결본 일치 · live 와 drift 없음 | ✓ |
| A4 | 전체 시스템 프롬프트 parity | blind·textlog·frames·rf-v3 바이트 동일 / vis-pure·tagmem +195B(의도) |
| B1 | 선택기를 tagmem restore 노트 52칸에 재생 | 46% 칸 발동 · 표시 줄 전부 ≤12 · 오래된 줄부터 버리고 최근 성공 기록 유지 |
| C1–C5 | 셀 중복 0 · 편 ⊆ 컨텍스트 · resume 스킵(완료 69행, vis-pure 0행) · REMAINING_EPISODES→0 · 제출 dry-run 3종 | ✓ |
| D1–D2 | 옛 vis-pure 행 분리(find 287·restore 17) · 집계 ROW_PATTERNS 고정 | ✓ 지금 돌리면 4전략 821행만 |
| E1 | 이전 restore 잡 OOM 이력 | 없음 (128GB 충분) |
| # | 발견 | 증거 | 결정 |
|---|---|---|---|
| M1 | goal 이미지 어포던스가 tagmem restore 에만 열림 — build_goal_picker 화이트리스트가 전략 이름 기준(vis-pure·frames-uniform 도 메모리 이미지가 있어 원리적으로 가능) | 5전략 본 런 goal_pick null: restore 86/86 · find 821/821 | tagmem goal-off 본표, goal-on 은 별도 표(사용자) |
| M2 | [정정] 새로 연 KEEP 의 61%가 마지막 done 턴 | 유효 KEEP 0.237 → 0.092/턴 | 측정 무대 = restore |
| M3 | 모델은 exo‖wrist 타일(640×180)을 보고 KEEP 하는데 저장은 exo 원본(prev_frames_writer, 260918 결정) | 손목 뷰 신호가 저장 시점에 약해짐 | keep 전략만 타일 저장으로 변경(3432dee) |
| M4 | tagmem 시드가 구조적으로 최대 — 수정 대상 아님, 표에 명시 | 시드 줄/이미지: blind 1/0 · textlog 6/0 · rf-v3 2/0 · frames 1/8 · vis-pure 1/8 · tagmem 34/8 | 캡션에 명시 |
감사 통과: 계획 줄은 시드에 들어가고 선택기 필터 밖(예산 초과에도 항상 보임) · 온라인 검색 질의 = 읽기 트랙과 동일(query_tags, obj_v2=False) · 전 전략 obs_budget=4, TILE_WIDTH=640 · seed_left + online_kept == 8 16/16칸 · 실행 조건(lifted_guard=False · nav_loop=6 · stall=6 · image_cap=8 · reach_radius=1.0 · place_mode=vla · arm_init=home) 전 전략 동일 · plan_mode 는 rf-v3 만 rewrite(의도).
| 항목 | 이전 런 | 지금 |
|---|---|---|
| vis-pure 프롬프트 | — | 축출 정상화 문장 +195B |
| 나머지 4전략 프롬프트 | — | 바이트 동일 |
| 결정 D(tagmem 재검색) | — | 이 런에 tagmem 없음 — note_select 0/114행 |
| goal 이미지 | off | off (goal_pick null 114/114) |
| COST_CAP | 8 (부족) | 20 |
제출 상태: restore 8샤드 140630~140637(캡 20) + babysitter, 계정 GPU 캡으로 대기(다른 세션 tagmem_on_restore 4잡 점유). 최종 12잡 제출 시점에는 babysitter 3개(restore·tagmem_find·vis2_find) 전부 429 30분 백오프 포함.
1) 이번 점검이 없었다면 $120 짜리 재측정이 에러 메시지 없이 절반쯤 완료된 상태로 끝나 "다시 측정하는 일"이 그대로 벌어졌을 것이다. 두 블로커 모두 코드 결함이 아니라 파라미터·운영 공백(비용 캡, 재제출 주체)이라 테스트로는 안 걸린다 — 비용 캡은 실측 단가 × 샤드 칸 수 로 사전 계산해야 잡힌다.
2) M1 은 "메모리 품질 차이"와 "액추에이터 보조 차이"를 분리하는 결정이다. goal-on 수치를 5전략 옆에 놓으면 tagmem 만 VLA 에 추가 조준 정보를 받은 비교가 된다. 본표=goal-off 로 고정해 이 교란을 제거했다.
M4(시드 규모 비대칭)는 수정하지 않고 캡션 명시로 처리 — 메모리 예산 자체가 이 벤치마크의 비교 축이기 때문. 다만 "tagmem 이 좋은 이유가 시드 크기인지 구조인지"는 이 표만으로 분리되지 않는다. 사용자 결정 대기 항목: textlog oracle 로그 복원(결정 A, 보류 유지).
재측정 완주 후 (1) 4전략+vis-pure+tagmem 6전략 restore 표를 goal-off 기준으로 합치고 (2) tagmem goal-on 은 별도 표(tagmem_online_goal_ab)로 첨부. 비용 추적: Letsur 일일 캡 $100 대비 restore $70 + find $47 을 이틀에 분할.