Hailo-15H 는 NPU·ARM 코어·영상 인코더·ISP 를 한 칩에 담은 비전 SoC 이고, 이 카메라는 센서와 이더넷 보드를 한 하우징에 넣은 일체형입니다. 속성 헤드를 붙인 객체 탐지 모델을 이 카메라에서 직접 구동할 수 있는지 약 한 달간 시험했습니다. 정해야 했던 것은 두 가지입니다. 처음 계획한 모델이 변환되는지, 변환되지 않는다면 어느 모델로 바꿔야 하는지였습니다.
이 글은 변환과 구동에 성공한 항목, 변환 실패 원인, 그리고 버전 불일치·저장 공간·발열에서 확인한 한계를 실측 값과 함께 정리합니다.
시험 범위. 속도와 발열은 학습 전(무작위 가중치) 모델로 측정했으므로 정확도는 검증하지 않았습니다. 변환 가능 여부의 판정은 Dataflow Compiler(DFC) 5.3.0 과 D-FINE n·s 규모에 한정됩니다.
시험한 두 모델의 구조 차이
두 모델은 한 번의 추론으로 클래스(대분류) 와 속성(소분류와 상태) 을 함께 출력하는 구조이고, 기반 탐지기만 다릅니다. 속성은 별도의 두 번째 모델이 아니라 같은 모델의 병렬 헤드가 출력하므로, 소분류가 틀려도 대분류 결과는 남습니다.
| 항목 | D-FINE-Tag | YOLO26-Tag |
|---|---|---|
| 기반 탐지기 | D-FINE. 트랜스포머 디코더를 쓰는 실시간 DETR 계열 | YOLO26. CNN 기반 단일 단계 탐지기 |
| 속성 헤드 | 디코더 출력에 병렬로 부착 | P3, P4, P5 특징에 1x1 Conv 한 층을 붙여 17채널(속성 5축) 출력 |
| 분류 체계 | 클래스 대분류 + 속성 5축 | 클래스 9종 + 속성 5축 |
| 시험한 규모 | n, s | n, s, m, l, x. 헤드 추가 파라미터는 n 7,667 개에서 x 32,691 개 |
| 이 글에서의 역할 | 처음 탑재하려던 모델. 변환 불가 | 대체 모델. 변환과 구동 성공 |
두 모델의 차이는 곧 변환 가능 여부의 차이였습니다. 트랜스포머 디코더에는 컴파일러가 지원하지 않는 연산이 있었고, CNN 구조는 지원 범위 안에 있었습니다.
장비와 소프트웨어 구성
Hailo-15H 는 20 TOPS NPU 와 ARM Cortex-A53 4코어를 쓰고, 메모리는 LPDDR4 4GB 입니다. 실물의 센서는 IMX678(3840x2160, 30fps)이었고, 운영체제는 Yocto 기반 HailoOS(커널 5.15.32)이며 SSH 22 포트만 열려 있었습니다. 사양서에는 전력·동작 온도·방수 정보가 없었고, 접합부 온도가 104°C 에 이르면 성능이 제한된다는 내용만 매뉴얼에서 확인했습니다.
A53 4코어와 4GB 메모리로는 AI 전처리를 함께 수행하기 어렵습니다. 따라서 이 카메라에는 추론과 인코딩을 맡기고 나머지는 장비 외부에서 처리하는 구성을 전제로 했습니다.
구동에 성공한 항목
먼저 출고 시 탑재된 YOLOv5m 예제(apps/detection)로 장비 전체를 점검했습니다. 센서 인식, H.264 RTP 송출, 탐지 결과 메시지, 분할 녹화가 모두 정상이었습니다.
hailoexportzmq메시지 607건을 수신했고, 그중 탐지가 포함된 것은 14건이었습니다.splitmuxsink로 59.4초 분량의 1080p H.264 분할 MP4 를 생성했습니다.- 부팅부터 첫 추론 결과가 나오기까지 걸린 시간은 전원 재투입 시 약 12.9초, 소프트 재부팅 시 약 15.1초였습니다(카메라 로그 기준).
ONNX 모델은 Dataflow Compiler(DFC)를 거쳐 HEF 파일로 변환해야 장비에서 실행됩니다. 변환 환경은 WSL2 Ubuntu 22.04, DFC 5.3.0 과 Model Zoo 5.3.0 조합이었습니다. 이 조합으로 생성한 HEF 는 장비(HailoRT 5.0.0)에서 정상적으로 로드되었습니다.
새 모델은 YOLO26n 에 5개 속성 축(17채널)의 분류 헤드를 붙인 시험 모델로 확인했습니다. 변환과 실행 시험을 모두 통과했고, 실장비 300프레임 기준 합성 입력에서 약 122.8 FPS 를 기록했습니다. 이후 n, s, m, l, x 다섯 규모를 같은 방식으로 컴파일했습니다.
측정 수치의 한계. 가중치가 학습 전 무작위 값이라 정확도는 전혀 검증되지 않았고, 합성 입력이라 실제 영상의 전후처리 비용도 포함되지 않았습니다. 구동 가능성과 처리 한도의 상한을 확인한 수치입니다.
탐지 결과만 전송하는 구성도 가능했습니다. 영상 송출을 비활성화하고(video_network_sink: false) ZeroMQ 루프백으로 내보내면, 메시지에 라벨·클래스 번호·신뢰도·정규화 박스가 JSON 으로 담깁니다. 장비에 상주하는 송신기가 이를 구독해 서버 API 로 전달하는 구조를 만들 수 있습니다. 장비에는 SQLite 스풀을 거쳐 원격 DB 에 적재하는 예제(line_crossing.py)도 포함되어 있어 참고할 수 있었습니다.
D-FINE-Tag 변환 실패 원인
처음 탑재하려던 모델은 속성 헤드를 추가한 D-FINE 입니다. 2026-10-15 에 격리 환경에서 DFC 5.3.0 파서로 n, s 규모를 시험했고, 두 규모 모두 파싱 단계에서 실패했습니다.
| 시험 대상 | 결과 | 원인 |
|---|---|---|
| D-FINE n, s | 파싱 실패 | GridSample · TopK · GatherElements 미지원 |
| CNN 대조군 | 파싱 성공 | 시험 환경 자체의 문제가 아님을 확인 |
대조군을 둔 이유는 환경 문제와 모델 문제를 구분하기 위해서입니다. 대조군이 통과했으므로 원인은 모델의 연산 구성에 있습니다. 세 연산은 변형 가능한 어텐션과 쿼리 선택 단계에서 쓰이는 것으로 보이지만, 연산별 원인 분석까지는 하지 않았습니다. Model Zoo 에도 D-FINE, RT-DETR, DEIM 은 없었습니다.
시사점. 이 판정은 DFC 5.3.0 과 시험한 두 규모에 한정됩니다. 이 장비에서는 탑재 모델을 YOLO26-Tag 로 바꿔야 했고, 장비의 연산 지원 범위가 모델 구조 선택을 좌우한 사례가 되었습니다.
런타임과 툴체인의 버전 불일치
세 가지 버전이 서로 달랐습니다.
- 장비 HailoRT·펌웨어 5.0.0
- 제공받은 DFC 5.3.0
- 함께 받은 매뉴얼 5.4.0
5.3.0 으로 만든 HEF 는 5.0.0 장비에서 로드되었지만, 5.1.0 이후에 추가된 기능은 장비 런타임을 갱신하기 전에는 사용할 수 없다고 판단하고 설계했습니다. 매뉴얼에 있는 기능이라도 장비에서 지원된다는 보장이 없어, 문서를 참고할 때마다 버전 확인이 필요했습니다. DFC 의 GPU 가속은 Pascal·Turing·Ampere 만 기재되어 있고 로컬 RTX 5080(Blackwell)은 지원 목록에 없었으며, WSL2 에서의 GPU 지원은 문서마다 내용이 달랐습니다.
내장 저장 공간과 영상 보존
1분 단위 세그먼트를 재인코딩 없이 며칠씩 보관하려면 저장 공간 확보가 핵심입니다. 2026-10-15 의 df 결과로는 루트 파티션 총용량이 2.2GB, 여유 공간이 817MB 로 2Mbps 기준 약 54분 분량에 불과했습니다. 이 수치만 고려하면 장비 단독 보존은 불가능해 보입니다.
그런데 이후 점검에서 저장 매체가 31.9GB SD 카드이고 미할당 영역이 남아 있다는 점이 확인되었습니다. 용량 기준으로는 256GB 카드에서 2Mbps 로 11.8일, 4Mbps 로 5.9일 동안 저장이 가능합니다. 7일을 4Mbps 로 보존하려면 302.4GB 가 필요합니다. 내장 파티션 여유만 보고 내린 결론은 외장 매체까지 확인하면 달라질 수 있습니다.
규모별 발열 시험 결과
YOLO26-Tag 다섯 규모를 각각 10분씩 실영상으로 구동하며 SoC 열 센서(pvt-ts-0/1)를 기록했습니다. 예열 시작 온도는 약 48℃ 이고, 측정 사이에 10여 분씩 냉각 시간을 두었습니다. x 규모는 30분과 60분 구동 시험을 추가했습니다.
- 어느 규모에서도 104℃ 에 도달하지 않았고, 처리 FPS 는 일정하게 유지되었습니다.
- x 60분은 순간 최대 67.9℃ 였고, 두 단계 지수 곡선으로 외삽한 포화 온도는 약 68.4℃ 입니다.
- 실시간(LIVE) 처리 FPS 는 n 14.55 에서 x 7.74 까지 감소했습니다. 입력은 640x360 으로 조정한 센서 RGB 입니다. 박스 그리기와 MJPEG 인코딩, CPU 전후처리를 추론과 순차 처리한 값이므로 추론만 측정한 수치와는 직접 비교할 수 없습니다.
결과 해석 시 주의점. 이 값은 케이스 표면 온도가 아니라 칩 내부 센서에서 측정한 온도입니다. 주변 온도와 밀폐 함체 조건, 4K 인코딩과 ISP 가 켜진 기본 파이프라인을 포함했는지는 기록에 남아 있지 않습니다. 이 결과만으로 발열 문제가 없다고 결론 내릴 수는 없습니다.
정리
- 모델 구조를 정하기 전에 연산 지원부터 확인합니다. 파서 시험은 짧은 시간에 끝나지만, 그 결과가 모델 선택과 이후 일정까지 영향을 줄 수 있습니다. 대조군을 함께 두면 환경 문제와 모델 문제를 바로 구분할 수 있습니다.
- 문서의 버전과 장비의 버전을 따로 기록합니다. 런타임, 컴파일러, 매뉴얼이 모두 달랐고, 장비에서 직접 로드해 본 조합만 확정으로 취급했습니다.
- 저장 용량은 보존 기간 계산에서 가장 먼저 검토합니다. 파티션 여유와 물리 매체 용량이 달라서, 어느 쪽을 기준으로 삼느냐에 따라 보존 가능 여부 판정이 달라졌습니다.
- 발열은 측정 지점과 조건을 함께 적습니다. 케이스, SoC 센서, 주변 온도, 파이프라인 구성이 빠진 온도는 서로 비교할 수 없습니다.
- 정확도를 검증하지 않는 시험은 그 한계를 수치 옆에 적습니다. 무작위 가중치 모델의 FPS 는 구동 가능성의 증거일 뿐 성능의 증거가 아닙니다.
남은 한계도 분명합니다. 정확도는 학습된 가중치로 다시 측정해야 합니다. D-FINE 의 변환 불가 판정은 DFC 5.3.0 과 두 규모에 한정됩니다. 발열 수치는 칩 센서 기준이므로 함체 안에서의 온도는 따로 측정해야 합니다.