01배포 모델 — 연속 검출 + 알람 시 게이트
화재/균열 감시는 상시 CCTV다. 검출기가 모든 프레임을 실시간 처리(76 FPS)하고, VLM 오탐게이트는 검출 알람이 뜰 때만 후보 크롭을 판정한다(매 프레임 전수 VLM 아님). 즉 무거운 VLM은 드문 이벤트에만 돈다 — 이게 실시간을 자연히 만족시키는 구조.
02실측 지연 (node52 RTX PRO 6000 Blackwell)
| 단계 | 지연 | 처리량 | 비고 |
|---|---|---|---|
| YOLO 검출기 (프레임) | 13 ms | 76 FPS | 연속 감시 실시간 |
| VLM 게이트 (후보, single) | 117 ms | 8.5/s | 알람 시만 |
| VLM 게이트 (후보, batch8) | 26 ms | 39/s | 4.5× · 정확도 100% 유지 |
알람 판정 end-to-end vs RFP 예산
우리 알람 지연 ≈ 0.13~0.37초 (검출 13ms + VLM 후보 1~3개) — 초록. RFP 예산 2~30초 전체 대비 1% 미만.
03최적화 발견 (measure-first)
- 생성 길이·thinking은 지연과 무관. max_new 180 vs 8, thinking on/off 모두 0.117초 동일 — 병목은 생성이 아니라 비전 인코더/prefill(짧은 판정 답변이라 생성이 애초에 빠름).
- 배칭 = 4.5× 처리량, 무손실. 후보 크롭을 batch8로 묶으면 0.117→0.026초/후보(38.7/s). 단 배치 생성엔 left-padding 필수(안 하면 정확도 80→45%로 붕괴 — 실측). 이 수정으로 100% 유지.
- 다중 카메라 스케일. 배치 VLM ~39 후보/초/GPU → 한 GPU로 다수 카메라의 알람을 실시간 게이트. 검출기는 76 FPS라 카메라 다중화도 여유.
04함의
- 실시간은 이미 충족 — 최적화 불요. RFP "2~30초"를 100× 여유로 통과. VLM 게이트를 실시간화하려 애쓸 필요가 없다는 걸 measure-first로 확인(엔지니어링 자원 절약).
- 영업 근거: "검출 76 FPS + 오탐게이트 알람 0.1초대, 다중 카메라 온프레미스"를 측정 수치로 제시 가능. 엣지/온디바이스는 별도(경량 검출기 + 알람만 게이트).
재현: crack_poc/scripts/bench_vlm.py(padding_side=left). 맥락: 악조건 강건성(VLM 오탐게이트 −89%) · VLM 2차 데모.
NeMo AI 학습 솔루션 · 이상탐지 플랫폼 · 실시간 배포 지연 · 2026-07-07 · brain 리포트 서버