AEGLOSLAB Arduino UNO Q 완전 가이드

제9부 AI·엣지 응용

9.4 App Lab 없이 GPU 직접 추론하기 (커뮤니티 방법)

이 장은 Arduino 공식 지원이 아니다. App Lab과 Brick(9.2)을 거치지 않고, SSH로 접속한 Debian 셸에서 Adreno 702 GPU에서 직접 추론을 실행하려는 커뮤니티 시도를 다룬다. 이 책 집필 시점 기준, 이 경로는 미해결 상태다 — 아래에서 근거가 되는 두 개의 Arduino 포럼 스레드를 실제로 확인한 내용을 그대로 옮긴다.

9.4.1 왜 이런 시도가 나오는가

App Lab의 Bricks는 편리하지만 두 가지를 감춘다. 첫째, 어떤 런타임·백엔드로 추론하는지(9.3에서 다룸). 둘째, App Lab GUI 자체의 오버헤드 — 웹 UI, 컨테이너, 이벤트 루프 등. SSH로 직접 접속해(5.2 참고) Python 스크립트만으로 GPU에 접근하고 싶은 사용자들이 있고, 그 시도 중 하나가 실제로 Arduino 공식 포럼에 기록돼 있다.

9.4.2 커뮤니티 스레드 — "AI Inference on UNO Q Adreno 702 GPU without App Lab"

스레드 주소: forum.arduino.cc/t/ai-inference-on-uno-q-adreno-702-gpu-without-app-lab/1449276 (2026년 6월 22일 게시, 작성자 deneb23). 이 책 집필 시점에 직접 확인한 결과, 이 스레드는 게시물 1개뿐이며 어떤 답변도 달리지 않은 상태였다(자동 종료 타이머만 설정되어 있음).

작성자는 다음과 같이 설명한다.

  • 목표: 엣지 AI 프로젝트를 위해 UNO Q의 GPU에서 추론 성능을 벤치마크하고 싶었다.
  • 방법: onnxruntime-qnn 패키지로 ONNX 형식 MobileNetV2 모델을 실행 시도. App Lab이 아니라 SSH로 접속해 Python 스크립트를 직접 실행하는 방식.
  • 결과: QNN_BACKEND_ERROR_CANNOT_INITIALIZE 오류 발생.
  • 작성자 본인의 진단: "Adreno 702용 Qualcomm 독점 OpenCL 드라이버가 보드에 없다"고 추정하며, 관련 Qualcomm 지원 포럼 논의를 근거로 들었다.
  • 요청: App Lab 밖에서 GPU에 접근하는 방법에 대한 조언을 구함.

9.4.3 관련 스레드 — QNN/TFLite delegate 지원 현황 문의

스레드 주소: forum.arduino.cc/t/status-of-qualcomm-qnn-tflite-delegate-edge-impulse-qnn-acceleration/1447565 (2026년 6월 8일 게시, 작성자 speccy). 이 스레드도 게시물 1개, 응답 없음 상태로 확인됐다.

이 게시물이 유용한 이유는 작성자가 보드를 직접 조사해서 얻은 구체적 사실을 남겼기 때문이다.

  • /dev/fastrpc-adsp 디바이스 노드가 존재한다.
  • fastrpc 커널 모듈이 로드돼 있다.
  • QCM2290/QRB2210 계열 ADSP 펌웨어가 정상 부팅된다.
  • GPU 가속은 Mesa/Turnip/Rusticl 조합으로 Vulkan·OpenCL이 동작한다(즉 오픈소스 그래픽 드라이버 스택은 동작한다).
  • 그러나 libQnnTFLiteDelegate.so를 비롯한 QNN 유저랜드 라이브러리는 공식 이미지에 없다.

작성자가 제기한 다섯 가지 질문(QNN이 공식 지원되는지, runner-linux-aarch64-qnn이 동작하는지, 공식 이미지에 QNN 라이브러리가 추가될 계획이 있는지, QCM2290/QRB2210이 의미 있는 가속을 주는지, 유저랜드를 직접 설치하는 공식 방법이 있는지)는 모두 집필 시점까지 미답변이다.

9.4.4 두 스레드를 합쳐 보면

이 장을 위해 조사하며 9.2.4에서 확인한 사실(Arduino 공식 모델 매니페스트에서 hw_acceleration_backend: qnn 태그가 붙은 모델은 전부 supported_boards: ["ventunoq"]뿐이고 UNO Q용에는 하나도 없음)과 위 두 포럼 스레드는 서로 다른 방향에서 같은 결론을 가리킨다.

포럼: onnxruntime-qnn QNN_BACKEND_ ERROR_ CANNOT_ INITIALIZE UNO Q 공식 이미지에는 QNN 유저랜드 스택이 없는 것으로 보임 포럼: libQnnTFLiteDele gate.so 이미지에 없음 확인 모델 매니페스트: qnn 태그 = VENTUNO Q 전용

다만 이것은 정황 증거이지 확정이 아니다. 세 근거 모두 2026년 6월 무렵의 스냅샷이며, Arduino가 이후 이미지 업데이트로 QNN 스택을 추가했을 가능성을 배제할 수 없다. 실습 전 반드시 find / -iname "*qnn*" 2>/dev/null, find / -iname "*fastrpc*" 2>/dev/null 같은 명령으로 자신의 보드 이미지 상태를 직접 확인하기 바란다.

9.4.5 두 가지 접근 — Qualcomm 독점 스택 vs Mesa 오픈소스 스택

직접 작성한 Python 스크립트 경로 A: QNN·QAIRT Qualcomm 독점 경로 B: Mesa 오픈소스 Turnip Vulkan · Rusticl OpenCL libQnnTFLiteDelegate.so 등 포럼 보고: 공식 이미지에 없음 /dev/fastrpc-adsp 등 기본 드라이버는 존재 확인됨

9.4.5.1 경로 A — QNN/QAIRT(Qualcomm 독점 AI 스택)

이론적으로는 가장 빠를 경로다. Hexagon DSP·GPU를 AI 연산에 맞춰 최적화한 커널을 쓰기 때문이다. 그러나:

  • 필요한 유저랜드 라이브러리가 공식 UNO Q Debian 이미지에 없는 것으로 보고됐다(9.4.3).
  • Qualcomm 개발자 계정을 통해 QAIRT SDK를 별도로 내려받아 수동 설치하는 방법이 이론상 있을 수 있으나, UNO Q라는 특정 보드·커널 조합에 대해 이 절차가 문서화돼 있는지는 확인하지 못했다.
  • 라이선스·서명·커널 모듈 버전 호환 등 변수가 많아, 성공하더라도 재현 가능한 절차로 정리하기 어려울 수 있다.

9.4.5.2 경로 B — Mesa 오픈소스 스택(Turnip·Rusticl)

Adreno GPU용 오픈소스 드라이버는 Mesa 프로젝트가 역공학으로 만들어 왔다. Turnip은 Vulkan 드라이버, Rusticl은 Gallium 위에서 동작하는 OpenCL 구현이다. 포럼 스레드(9.4.3)에 따르면 이 스택은 UNO Q에서 이미 동작한다.

보드에서 직접 확인하는 명령:

# Vulkan 디바이스 확인
sudo apt install vulkan-tools
vulkaninfo --summary

# OpenCL 디바이스 확인
sudo apt install clinfo
clinfo

이 경로로 AI 추론을 하려면, 표준 컴퓨트 셰이더(Vulkan compute)나 OpenCL 커널을 직접 작성하거나, Vulkan/OpenCL 백엔드를 지원하는 범용 추론 엔진(예: ncnn의 Vulkan 백엔드)을 이 드라이버 위에 구축하는 방식이 된다. 다만:

  • 검색 과정에서 "llama.cpp가 UNO Q의 Vulkan·OpenCL에서 동작하지 않는 것 같다"는 제목의 별도 포럼 스레드도 발견했다 — 본문까지는 확인하지 못했고 제목만 확인했으므로 확정적 근거로 인용하지는 않지만, 방향성(Mesa 스택 위에서 실제 AI 워크로드를 실행하는 것도 원활하지 않다는 정황)은 위 결론과 일치한다.
  • Turnip·Rusticl은 범용 그래픽/컴퓨트 API 구현이지, Qualcomm의 AI 전용 커널처럼 신경망 연산에 최적화돼 있지 않다. 성공하더라도 속도는 QNN 경로보다 크게 낮을 가능성이 있다(측정 전까지는 추정일 뿐이다).

9.4.6 장단점 정리

항목경로 A: QNN/QAIRT경로 B: Mesa(Turnip/Rusticl)
성숙도(UNO Q 기준)포럼 보고상 유저랜드 부재 — 사실상 미완드라이버 존재 확인됨, AI 워크로드 사례는 미확인
설치 난이도확인 필요(공식 절차 없음)낮음(APT로 도구 설치, 드라이버는 이미 있음)
Arduino 공식 지원아니오아니오
기대 속도이론상 가장 빠름(NPU/DSP 최적화)미지수, QNN보다 낮을 가능성
리스크시스템 이미지 손상 가능성, 재현성 낮음상대적으로 낮음(표준 오픈소스 도구)

9.4.7 시도해볼 것과 하지 말아야 할 것

  • 프로덕션에는 쓰지 않는다. 이 장의 내용은 실험·탐구 목적이다. 신뢰할 수 있는 기준선은 어디까지나 9.3의 CPU 경로다.
  • 시스템 이미지를 백업한다. 커스텀 드라이버·라이브러리를 수정하기 전에 SD카드/eMMC 이미지를 백업해 두면 복구가 쉽다(5.3 OTA 업데이트, 5.4 저장 공간 관리 참고).
  • 먼저 자신의 보드 상태를 확인한다. 9.4.4에서 제시한 find 명령, vulkaninfo, clinfo로 현재 이미지에 무엇이 있는지부터 점검한다. 이 책이 인용한 포럼 스냅샷과 다를 수 있다.
  • 결과를 커뮤니티에 공유한다. 두 포럼 스레드 모두 미답변 상태였다. 성공이든 실패든 스레드에 결과를 남기면 다른 사용자와 Arduino 팀에 도움이 된다.
  • 트러블슈팅은 A.1을 참고하고, 이 장에서 막히면 9.2(App Lab 경유)이나 9.3(CPU 경로) 같은 검증된 대안으로 돌아가는 것을 권한다.

9.4.8 다음 장으로

  • 9.5: 카메라 비전 예제로 (가속 여부와 무관하게) 실제 추론 지연·FPS를 측정하는 방법.
  • 9.1: 이 장에서 다룬 GPU 드라이버 스택의 배경이 되는 하드웨어 사양.
  • A.1: 부록 A 트러블슈팅에서 이 장 관련 문제를 별도로 정리할 수 있다.