# Snapshot 정리·Tracking 보정 결과

상시 CPU Snapshot 캐시/API 제거와 Tracking 보정은 반영됐습니다. 실제 10 FPS는 여전히 미달입니다.
| 구성 | 실제 결과 FPS | 판단 |
|---|---:|---|
| 이전 계측 Off/On | 1.038 / 0.956 | 기존 evidence 재사용 |
| 1차: Snapshot 제거+DISCARD 경로 | 미측정 | 첫 Frame timeout, SDK cleanup 실패, 안전 중지 |
| 최종: Snapshot 제거+기존 retrieve+Tracking/BLAS | 0.961 | 정상 전달/cleanup, 10 FPS 미달 |

첫 결과 2.508초, cleanup 2.208초. 워밍업5초 뒤 15.61초 측정했습니다.
현재 healthy/stopped, 표시0.25/모델/version2/인증 유지, 상세 계측Off, restart on-failure:3 복원.

## Tracking 비교
고정 300후보/12클래스/35 Frame(빈 Frame·reset 포함), CPU2/RAM4GiB, 구버전과 ID 결과 동일.
| BLAS | 이전 adapter 준비 ms | 새 준비 ms | 이전 전체 ms | 새 전체 ms |
|---|---:|---:|---:|---:|
| default | 1.648 | 0.765 | 19.616 | 18.412 |
| 1 | 1.595 | 0.761 | 19.567 | 18.385 |

NumPy/SciPy OpenBLAS는 기본 각각20 thread, 제한 각각1 thread. BLAS 제한 자체의 속도 향상은 이번 입력에서 뚜렷하지 않았습니다.
실제 FastAPI OPENBLAS_NUM_THREADS=1, Triton unset을 확인했습니다. Host/OMP/MKL/OpenCV는 변경하지 않았습니다.
실제 Tracking 평균 9.85ms/p95 20.38ms. 이전 약13.76ms와 입력이 달라 순수 보정 효과로 단정하지 않습니다.

## 남은 지연
선택→전처리 출력 평균 1015.5ms, 전처리 출력→infer 출력 평균 2032.0ms. SDK queue 대기를 포함합니다.
Snapshot 복사 제거 뒤에도 같은 초 단위 대기가 남아 주원인 가설은 약해졌습니다. 전체 callback/SDK queue/consumer 반환 경계의 정확한 원인은 미확정입니다.
RGB 변환 제거용 DISCARD 경로는 실제 실패로 채택하지 않았습니다. 현재는 기존 SDK retrieve의 RGB 변환을 유지합니다.
모델/precision/pool/해상도 탐색이나 세 번째 Runtime은 하지 않았습니다. 다음은 이미 제거한 Snapshot이 아니라 남은 SDK 경로의 표적 판별입니다.

## 한계
첫 window는 입력 전달이 없어 Snapshot 단독 효과를 분리하지 못했습니다. 최종은 Snapshot+Tracking/BLAS 조합 결과입니다.
latency는 상세 On 뒤 워밍업5초를 포함하며 FPS는 워밍업 제외입니다. 고정 입력 CPU 비교와 실제 live 성능은 구분합니다.
원본1920x1080/모델576x576은 유지했습니다. Event/Artifact·Pose/Fire·16채널·정확도·장시간 무누수는 이번 검증 범위가 아닙니다.