B200 클러스터의 온라인 잡이 yj-3/4(A6000)보다 느리다는 체감 보고가 있어, 병목 원인을 확인하고 서버 종류와 무관하게 속도를 개선하는 것이 목표였다.
실측 비교(oracle restore 행의 secs/steps_used): 로컬 s0~7 543행 중앙값 0.372s/step, yj sx* 150행 0.326s/step — 12% 차이로 크지 않았다. 러닝 잡 프로파일: CPU 11%/8코어(=1코어), GPU util 25% → 단일 스레드 CPU 바운드로 확인.
구현: subgoal_factory.slim_sensor_cameras() / slim_sensor_suite() — 폴링 목록만 축소한다(카메라 자체는 씬에 남아 VLM 이미지·영상과는 무관). SB_SLIM_SENSORS=1로 미사용 카메라 5대+depth+task_info 제거, SB_SLIM_OIP=1로 ObjectImagePointsSensor까지 추가 제거.
| 모드 | 액션당 | 궤적·정책 입력 이미지 |
|---|---|---|
| full(현행) | 587 ms | 기준 |
| A: 카메라 5+depth+task_info 제거 | 499 ms (−15%) | 비트 동일 |
| A+OIP(SB_SLIM_SENSORS+SB_SLIM_OIP) | 254 ms (2.3배) | 분포 동일, 비트 다름 |
OIP 제거 시 비트가 달라지는 이유: OIP가 np.random.choice로 전역 RNG를 소비하는데, 하네스의 datagen 액션 노이즈(scipy truncnorm.rvs)가 같은 전역 RNG를 써서 OIP 유무에 따라 노이즈 표본열이 밀리기 때문이다(OIP 계산+RNG 원복 == OIP 제거, 비트 동일로 확인). 하네스가 원래 무시드(cfg.seed=None)라 판단 기준은 "분포 동일"이다.
tests/exec 393개 통과(플래그 유무와 무관하게 동일). 관측 캐시 메모리는 스텝당 5.3MB → 1.3MB로 감소.
B200/A6000 서버 차이가 아니라 하네스 구조(불필요 센서 폴링)의 문제였다 — 서버 종류와 무관하게 개선 가능했고, 클러스터 전체 처리량을 사실상 2.3배로 늘렸다. 사용자 결정으로 새 캠페인부터 A+OIP를 채택하고, 진행 중이던 캠페인은 조건을 섞지 않기 위해 그대로 두었다.
GPU util 25%·CPU 1코어라 여유는 크지만, 편당 메모리 누적(최대 ~128GiB)이 걸림돌 — 씬 메모리 누적 문제 해결이 선행되어야 한다.
평가 중 datagen 액션 노이즈(robots/abstract.py:135)가 켜져 있는 것이 의도된 것인지 확인이 필요하다(기록만, 변경 없음).