torch.compile이 default 2.16×, reduce-overhead(CUDA graphs) 2.99× (767→256ms) — sparsity 1.20×보다 2.5배 큼. 그런데 이건 평가 스크립트의 TORCHDYNAMO_DISABLE=1에 막혀 꺼져 있던 것frame sparsity의 원래 동기는 정책 추론 가속이었다. 토큰이 33%(drop)/24%(mae) 줄면 계산량도 그만큼 준다는 건 분명한데, 문제는 그것이 wall-clock에 반영되는가였다. 세 층위(forward 1회 / policy 호출 1회 / end-to-end 평가)에서 각각 측정했더니 전부 이득이 없었다 — 그런데 그 측정치가 노이즈에 오염되어 있었다는 것이 이 카드의 핵심.
재검증의 계기: 진단 과정에서 evaluation/policy_server.py:165가 torch.compile(model.model)을 호출하도록 되어 있는데, scripts/eval_robocasa.sh:75의 export TORCHDYNAMO_DISABLE=1이 이를 무력화하고 있었다는 것을 발견(주석: 워커 ubuntu:22.04에 C 컴파일러가 없어 inductor가 실패). 즉 지금까지의 모든 추론 측정은 compile OFF 상태였다. "오버헤드를 먼저 제거하면 토큰 감소가 비로소 효과를 낸다"는 예측이 성립하는지 compile을 켜서 검증했다.
1차 (3중 측정): scripts/bench_forward.py(job 85009, bs 1/4/8, warmup 5+측정 30회) → scripts/bench_generate.py(job 92531, XWAMRunner.generate(early_stop=True, cfg=0) = policy server가 액션 청크마다 실행하는 경로, action denoise 10스텝, warmup 2+측정 10회) → end-to-end 24×50 wall-clock 비교.
2차 (compile × sparsity 매트릭스): scripts/bench_compile.py로 {eager, compile default, compile reduce-overhead} × {none, drop_middle} 6조합 측정, warmup 3+측정 10회, torch.cuda.synchronize(). 실행: job 92645, --container=nvcr.io/nvidia/pytorch:25.04-py3(gcc 13.3 확인), TORCHDYNAMO_DISABLE unset, 1 GPU.
| B | none | mae25 | drop | mae 배속 | drop 배속 |
|---|---|---|---|---|---|
| 1 | 55.9 | 55.8 | 56.1 | 1.00× | 1.00× |
| 4 | 86.4 | 72.7 | 69.6 | 1.19× | 1.24× |
| 8 | 152.6 | 123.1 | 114.9 | 1.24× | 1.33× |
| arm | ms/call | 배속 |
|---|---|---|
| none | 699.9 ± 69.2 | 1.00× |
| drop_middle | 703.6 ± 67.4 | 0.995× (→ 정정됨, 아래 참조) |
| mae_middle | 722.3 ± 56.5 | 0.969× |
end-to-end 평가 wall-clock (24×50, 4 GPU): mot_v1b 1:00:55 vs dropmid 1:01:41 (+46초, 사실상 무이득).
| none (761토큰) | drop_middle (521토큰) | sparsity 이득 | |
|---|---|---|---|
| eager | 766.9 ± 8.7 ms | 638.6 ± 8.8 ms | 1.20× |
| compile (default) | 355.1 ± 1.6 ms | 357.0 ± 2.4 ms | 0.995× |
| compile (reduce-overhead) | 256.3 ± 2.9 ms | 255.5 ± 0.6 ms | 1.003× |
eager/none(767ms) 대비 compile 배속: default 2.16×, reduce-overhead 2.99×. 첫 호출 컴파일 비용은 67~75s(정책 서버는 프로세스당 1회라 무시 가능).
이 레짐에서 frame sparsity는 추론 가속 수단이 아니다. 정책 추론(bs1) 1.00~1.20×(측정 노이즈에 따라 다르지만 어느 쪽이든 미미), 학습(4 GPU bs4×accum8) 1.01×, end-to-end 평가 1.00×. 반면 compile은 코드에 이미 있었는데 인프라 제약(워커에 C 컴파일러 없음)으로 꺼져 있던 2.16~2.99× 레버였다 — 사용자의 원래 목표("joint denoise + ANS 유지하면서 추론 감당 가능하게")는 sparsity가 아니라 compile 복원만으로 이미 달성된다(767ms→256ms).
compile 이후 sparsity 이득이 사라지는 이유는 두 가지로 추정된다: (a) 남은 시간(25.6ms/스텝, roofline 4.4~1.6ms의 4~5배)이 러너의 denoise 루프(UniPC 스케줄러 multistep 연산, 조건부 마스킹)로 이동했는데 이는 full latent 그리드에서 동작해 sparsity와 무관, (b) sparsity 구현 자체의 per-forward 오버헤드(build_keep_index의 .nonzero() device sync)가 모델이 빨라지면서 절약분과 맞먹게 됐을 가능성. 둘 다 미검증.
compile 이후 sparsity 소멸의 두 가설(러너 루프 이동 vs. keep_idx 재계산 오버헤드) 미분리. compile 하 SR 동등성(inductor/CUDA graphs가 출력을 바꾸지 않는지)도 아직 24×50으로 검증하지 않음.
가장 실용적: 평가 파이프라인에 compile 복원 — eval_robocasa.sh의 TORCHDYNAMO_DISABLE=1을 걷어내고 --container=nvcr.io/nvidia/pytorch:25.04-py3로 제출하면 RoboCasa 평가가 ~3배(1시간→20분대 예상) 빨라질 것. 첫 pull + compile 67s 오버헤드만 확인.
keep_idx를 generate 호출당 1회 캐시 후 compile+sparsity 재측정 — 단 modules/frame_sparsity.py는 mae25 학습(job 91863)이 현재 사용 중이라 완주 후 진행.