저는 카메라 에이전트가 내장된 오픈 소스 비디오 녹화기인 OpenNVR을 유지 관리하고 있습니다. 이 시스템에 카메라의 상황을 물어보거나, 경보를 설정하거나, 오래된 영상을 검색할 수 있으며, 곧은 스스로 이벤트까지 살펴볼 것입니다.
대부분의 사용자는 GPU가 없습니다. 그들은 4코어를 가진 작은 PC를 가지고 있습니다. 그래서 이번 테스트에서는 GPU가 없는 4 vCPU 머신을 사용하여 에이전트가 의존하는 모든 모델을 테스트했습니다. 지금까지는 대부분의 프로젝트처럼 명성으로 모델을 선택해 왔습니다. 우리는 오픈 소스 누구나 확인할 수 있는 숫자를 원했기 때문에, 모든 테스트 스크립트는 레포지토리에 있습니다.
저희 기본 설정 네 가지가 변경되었습니다. 일부 결과는 예상과 달랐습니다.
테스트 방법
작업당 하나의 작은 테스트를 진행했습니다:
- 언어 모델 (Language model): 도구를 사용하고 다단계 조사를 완료할 수 있는가?
- 비전 모델 (Vision model): 라벨링된 이미지에 대한 알려진 답변이 있는 질문.
- 음성 인식 (Speech to text): 에이전트에게 실제로 말하는 구절에 대한 단어 오류율(word error rate).
- 음성 합성 (Text to speech): 실시간보다 빠른지, 그리고 이해하기 쉬운가?
- 검색 (Search): 텍스트 설명으로부터 올바른 이미지를 찾는 것.
모든 시간 측정은 4 CPU 스레드에서 이루어졌습니다.
언어 모델
저희는
또한 자체 에이전트에서 버그를 발견했습니다. 모델에게 항상 설명하기 전에 보는(look) 것이라고 지시했기 때문에, 사용자가 "고맙습니다, 이게 다예요"라고 말했을 때 Granite가 카메라를 확인하러 갔습니다. 이제 잡담은 어떤 도구 없이 모델로 전달됩니다. 이는 Granite뿐만 아니라 모든 모델에 도움이 되었습니다.
비전 모델 (Vision model)
레이블링된 이미지 128장, 각 3개의 질문: 그림 속의 무언가에 대한 질문 1개, 존재하지 않는 것에 대한 질문 1개(여기서 "예"는 환각(hallucination)임), 그리고 사람 수 계산.
| 모델 | 잘못된 "예", 총 126건 중 | 하나 내에서 카운트, 총 61건 중 | 새로운 프레임당 CPU 시간 |
|---|
| qwen3-vl:2b-instruct | 0 | 50 | 18초 (후속 질문은 무료) |
| ... | | | |
| Qwen3-VL은 존재하지 않는 것에 대해 "예"라고 말한 적이 없습니다. GPU에서는 약 3초 만에 답변하므로, GPU가 있을 때는 기본값입니다. 하지만 4코어에서는 프레임 하나를 읽는 데만 18초가 걸립니다. 만약 누군가가 게이트에 있다면, 18초 후의 답변은 유용하기에는 너무 늦습니다. 따라서 CPU에서는 Moondream을 유지했습니다. | | | |
Ollama를 사용하는 경우 한 가지 팁: 일반 qwen3-vl:2b 태그는 사고(thinking) 버전이며 think: false를 무시합니다. -instruct 태그를 사용하세요.
음성 인식 (Speech to text)
| 모델 | 단어 오류율 (Word error rate) | 문장당 시간 |
|---|
| Parakeet TDT 0.6B v3 (onnx-asr, int8) | 1.4% | 0.31초 |
| ... | | |
| 이것은 쉬운 결정이었습니다. 오류는 절반으로 줄었고 시간은 약 5분의 1로 줄었습니다. 음성 인식(Speech recognition)은 한 번의 음성 상호작용에서 가장 느린 단계였는데, 이제는 3분의 1초가 걸립니다. Parakeet은 번역을 할 수 없고 힌디어를 처리하지 못하므로, 해당 기능이 필요한 사이트에는 여전히 Whisper를 사용합니다. | | |
음성 합성 (Text to speech)
Kokoro-82M이 Piper보다 소리가 더 좋지만, 4코어에서는 실시간의 1.9배로 실행되므로 오디오를 재생하는 것보다 시간이 오래 걸리고 답변이 문장 중간에 끊기게 됩니다. Piper는 0.23배로 실행됩니다. 따라서 Piper를 유지했습니다.
검색 및 감지 (Search and detection)
설명으로 푸티지(footage)를 검색하는 경우, 예를 들어 "부두에 있는 빨간 트럭" 같은 검색에서는 SigLIP 2 B/16이 CLIP ViT-B/32의 0.571을 상대로 0.672 mAP를 기록했습니다. 이미지당 속도는 느리지만(26ms 대비 57ms), 여기서는 검색 품질이 더 중요합니다. 이것이 현재 기본값이며, OpenNVR은 업그레이드 후 오래된 푸티지를 자동으로 재임베딩(re-embed)합니다.
항상 작동하는 디텍터는 YOLOv8n에서 YOLO26n으로 변경되었습니다: 프레임당 75ms 대신 62ms로, 정확도는 약간 더 높고 출력 형식은 동일합니다.
우리가 배운 점
- 에이전트에게 중요한 것은 크기가 아니었습니다. 모델이 결정을 내리기 전에 도구(tools)를 확인하는지가 매개변수 개수보다 중요했습니다.
- 카메라에서 느린 답변은 나쁜 답변입니다. 8초 만에 나온 좋은 답변이 18초 만에 나온 최고의 답변보다 나았습니다.
- 사용자가 가진 하드웨어에서 테스트하세요. 이러한 순위의 대부분은 GPU에서 뒤집히며, 우리의 사용자 대부분은 GPU를 가지고 있지 않습니다.
모든 스크립트와 원시 데이터는 리포지토리(MODELS_AND_LATENCY.md)에 있습니다. 다른 하드웨어에서 실행했다면, 여러분의 수치를 담아 PR을 보내주세요.
우리가 메울 수 없었던 한 가지 격차: CPU에서 5초 이내에 프레임을 읽고 여전히 환각(hallucinate)을 일으키지 않는 2B 미만의 비전 모델입니다. 만약 알고 계신 것이 있다면 댓글로 알려주세요.
원래 opennvr.org에 게시됨. AI의 도움을 받아 작성되었으며, 모든 측정값은 OpenNVR 리포지토리에서 가져왔습니다.