콘텐츠로 이동

AI 가속기

소개

SDK에서 NNACC라고 부르는 AI 가속기는 일부 SF32 디바이스에서 지원되는 신경망 연산을 오프로드합니다. 추론을 클라우드 서비스에 의존하지 않고 로컬에서 실행하는 엣지 AI를 지원합니다. 가속이 지연 시간, CPU 점유율, 에너지를 줄여 주는지는 모델, 메모리 배치, 소프트웨어 구현, 전체 제품 워크로드에 따라 달라집니다.

웨어러블, 건강 모니터링 디바이스, 스마트 디스플레이, 음성 지원 액세서리, 센서 퓨전 시스템, 소형 AIoT 제품이 잠재적인 응용 분야입니다. 이런 제품은 배터리로 동작하는 디바이스에서 Bluetooth, 그래픽, 오디오, 센싱, 사용자 상호작용을 함께 처리하는 경우가 많습니다. 지원되는 연산을 오프로드하면 다른 작업에 쓸 CPU 시간을 더 확보할 수 있지만, 그 결과로 얻는 응답성과 에너지 절감은 반드시 측정해야 합니다.

정확한 AI 기능 집합은 SF32 디바이스와 SDK 지원에 따라 달라집니다. 모델 아키텍처나 메모리 계획을 확정하기 전에 항상 대상 칩의 데이터시트, 레퍼런스 매뉴얼, SDK 문서를 확인하십시오.

아래의 CMSIS-NN 연산자 상세 내용과 디바이스별 NNACC 개수는 SiFli SDK v2.5.1 문서를 기준으로 합니다. 해당 릴리스의 NNACC 가이드는 SF32LB55x/56x/58x의 리소스를 나열하지만 SF32LB52x나 SF32LB57x에서의 사용 가능 여부는 확정하지 않으며, 목록에 없다는 사실이 두 제품군에 NNACC가 없다는 증거는 아닙니다. 주소 윈도 검사, 대기 동작, GC032A 구성은 해당 릴리스의 HAL 또는 드라이버 소스에서 관찰한 내용이며, 모든 실리콘 리비전이나 SDK 버전에서 보장되는 것은 아닙니다. 인용한 NNACC 가이드와 예제는 모든 부품과 보드에 대한 엔드 투 엔드 모델 변환기나 그래프 런타임, 자동 CPU 폴백, 카메라 캡처 지원을 확정하지 않습니다. 설계를 확정하기 전에 정확한 SDK 리비전과 구성, 칩 리비전, 런타임, 보드를 확인하십시오.

선택한 SF32 디바이스에 로컬 AI 기능이 적합한지 판단하거나, 센서, CPU, 메모리, 가속기 사이에서 추론 파이프라인을 나누어야 할 때 이 페이지를 읽으십시오. 모델 통합과 배포 워크플로는 함께 제공되는 AI 개요에서 시작하십시오.

온디바이스 AI가 중요한 이유

많은 임베디드 제품은 원시 데이터를 휴대폰이나 클라우드 서비스로 계속 스트리밍하지 않고도 지능적인 동작을 해야 합니다. 온디바이스 AI는 여러 면에서 제품을 개선할 수 있습니다.

  • 지연 시간 감소 가능성: 로컬 추론은 휴대폰이나 클라우드 서비스와의 왕복을 피할 수 있습니다. 다만 전체 제품에서 센서부터 판단까지의 지연 시간을 측정하십시오.
  • 개인정보 보호 향상: 원시 생체, 오디오, 모션 데이터를 로컬에 둘 수 있습니다.
  • 무선 트래픽 감소: 이벤트나 요약만 전송하면 됩니다.
  • 오프라인 동작 향상: 핵심 기능이 네트워크 접속 없이도 동작할 수 있습니다.
  • 평균 전력 감소: 오프로드 오버헤드를 포함하여, 동일한 정확도와 감지 범위에서 같은 사용 구간 동안 전체 기능이 더 적은 에너지를 쓰는 경우에 한합니다.

웨어러블과 AIoT 디바이스에서 이러한 이점은 추상적이지 않고 실용적입니다. 워치는 디스플레이, Bluetooth, 애플리케이션 프로세서의 응답성을 유지하면서 제스처를 분류하고, 활동 상태를 감지하고, 건강 신호를 모니터링하고, 간단한 음성 트리거를 인식하고, 센서 데이터를 처리할 수 있습니다.

이러한 이점에는 조건이 있습니다. 로컬 처리는 제품이 원시 데이터를 전송하지 않는 경우에만 무선 트래픽을 줄이며, 개인정보 보호에는 여전히 적절한 저장, 접근 제어, 전송 데이터 보호가 필요합니다. 아래의 사용 사례는 설계 가능성을 보여 줄 뿐이며, SDK가 모든 모델을 제공한다는 뜻이 아닙니다.

SF32 시스템에서의 위치

단순화한 SF32 엣지 AI 파이프라인은 다음과 같습니다.

다이어그램: 처리 단계와 펌웨어가 제어하는 추론
Sensors / Audio / Camera
        │
        ▼
Pre-processing
  - filtering
  - framing
  - normalization
  - feature extraction
        │
        ▼
Firmware / Inference Runtime
  - model graph orchestration
  - supported operations on NNACC
  - other operations on CPU, if implemented
        │
        ▼
Post-processing
  - thresholding
  - smoothing
  - event detection
  - application decisions
        │
        ▼
Application, UI, Bluetooth, or Storage

가속기는 전체 AI 파이프라인의 한 부분입니다. 실제 제품에는 여전히 데이터 캡처, 버퍼링, 전처리, 추론 스케줄링, 후처리, 애플리케이션 수준의 판단 로직이 필요합니다. 추론을 독립된 함수 호출로 취급하기보다 메모리 계층과 사용 가능한 가속기를 중심으로 파이프라인 전체를 설계할 때 대체로 가장 좋은 성능을 얻습니다.

AI 가속기의 역할

많은 신경망 워크로드가 같은 수학적 패턴을 수천, 수백만 번 반복하기 때문에 AI 가속기가 유용합니다. 이러한 패턴에는 컨볼루션, 행렬 곱셈, 벡터 연산, 활성화 함수, 풀링 또는 기타 고정 소수점 산술 커널이 포함될 수 있습니다. 전용 하드웨어는 선택된 커널을 범용 CPU보다 높은 에너지 효율로 실행할 수 있습니다.

이는 신경망 수학의 예시일 뿐, SF32 NNACC가 지원하는 연산 목록이 아닙니다. SiFli SDK v2.5.1 NNACC 가이드는 깊이별(depthwise) 컨볼루션을 포함한 CMSIS-NN q7 컨볼루션 함수 세 가지에 대한 NNACC 가속을 문서화하고, NNACC를 사용하는 CMSIS-NN 구현이 CMSIS-NN의 ARM DSP 구현보다 8배 빠르다고 보고합니다. 이 가이드는 이 수치의 벤치마크 조건을 밝히지 않으므로, 전체 모델의 지연 시간이나 에너지 개선을 보장하는 값이 아니라 벤더가 보고한 비교로 취급하십시오. 모델의 각 연산자와 그 수치 형식을 선택한 구현과 대조하여 확인하십시오. 행렬 곱셈, 활성화, 풀링이 개별적으로 가속된다고 가정해서는 안 됩니다. SDK는 가속기를 직접 제어하는 HAL API도 제공하지만, 두 인터페이스 중 어느 쪽이든 완전한 모델 변환기나 그래프 런타임을 제공한다고 가정하지 마십시오. 레이어를 조율하고 버퍼를 관리하는 일은 펌웨어 또는 별도의 추론 런타임이 맡아야 하며, 지원되지 않는 연산자에 대한 CPU 폴백에도 구현이 필요합니다.

SF32 디바이스는 메모리와 대역폭이 한정되어 있으므로 소형 임베디드 모델로 시작하십시오. 정확한 부품에서 NNACC 사용 가능 여부와 연산자 지원을 확인한 다음, 전체 파이프라인에 걸쳐 메모리 사용량, 지연 시간, 에너지를 측정하십시오. 제품군 이름만으로 지원 여부를 추정하지 마십시오.

일반적인 AI 관련 워크로드는 다음과 같습니다.

  • 키워드 스포팅 또는 간단한 음성 이벤트 감지.
  • 가속도계 및 자이로스코프 데이터를 이용한 제스처 인식.
  • 활동 분류와 모션 상태 감지.
  • 웨어러블 및 헬스 디바이스를 위한 센서 퓨전.
  • 센서와 알고리즘 지원에 따른 생체 신호 분석.
  • 카메라 입력이 있는 디바이스에서의 간단한 이미지 또는 카메라 기반 분류.
  • 이상 감지와 로컬 이벤트 필터링.

CPU, 가속기, 메모리의 역할

CPU가 워크플로를 제어하고 가속기는 연산 부하가 큰 일부 커널을 처리한다고 이해하면 좋습니다.

표: CPU, 가속기, 메모리의 역할
구성 요소 일반적인 역할
애플리케이션 CPU 애플리케이션 로직을 실행하고, 추론을 스케줄링하고, 버퍼를 관리하고, UI, Bluetooth, 스토리지, 시스템 정책을 처리합니다.
저전력 프로세서 사용자가 프로그래밍할 수 있는 디바이스에서 상시 센싱이나 백그라운드 작업을 처리할 수 있습니다.
AI 가속기 지원되는 NNACC 연산을 실행합니다. CPU 시간과 전체 파이프라인의 에너지를 소프트웨어 기준과 비교하십시오.
DMA / 메모리 시스템 메모리 접근을 제공하며, 구성된 경우 데이터 전송을 담당합니다. 모든 NNACC 입력이나 출력에 별도의 DMA 복사가 필요한 것은 아닙니다.
기타 가속기 오디오, 그래픽, 암호화 또는 센서 처리 블록이 전체 제품 파이프라인을 지원할 수 있습니다.

가속기는 CPU를 대체하지 않으며 임의의 모델을 스스로 실행하지도 않습니다. 입력을 준비하고, 지원되는 연산을 구성하고, 완료를 기다리고, 결과를 처리하고, 애플리케이션을 제어하는 일은 여전히 펌웨어가 합니다. 지원되지 않는 연산은 선택한 런타임이나 애플리케이션이 실제로 그 구현을 제공하는 경우에만 CPU에서 실행할 수 있으며, 그렇지 않으면 배포가 실패할 수 있습니다. 하드웨어 지원만으로는 자동 CPU 폴백이 보장되지 않습니다.

디바이스 제품군별 위치

제품군 전체의 성능 순위가 아니라 연산자, 메모리 예산, 전체 제품 워크로드를 기준으로 디바이스를 선택하십시오. SDK v2.5.1 가이드는 SF32LB55x와 SF32LB56x에는 HCPU NNACC 하나를, SF32LB58x에는 HCPU와 LCPU 서브시스템 각각에 NNACC 하나씩을 문서화합니다. 이러한 리소스는 선택을 위한 입력 정보일 뿐, 전체 모델이 더 빠르게 실행되거나 에너지를 적게 쓴다는 보장이 아닙니다. 정확한 부품과 구성에서 사용 가능 여부, 접근 가능한 메모리, 소프트웨어 지원을 확인하십시오.

표: 디바이스 제품군별 위치
디바이스 제품군 AI 측면의 위치
SF32LB52x 비용에 최적화된 Bluetooth, 오디오, 기본 HMI 제품에 고려할 수 있습니다. 특정 가속이 검증되기 전에는 경량 CPU 구현을 기준으로 삼으십시오.
SF32LB55x BLE 웨어러블과 센서가 풍부한 제품에 적합하며, 저전력 센싱과 소형 알고리즘에 유용합니다.
SF32LB56x 더 풍부한 UI, 커넥티드 HMI, 센서 또는 멀티미디어 파이프라인에 고려할 수 있습니다. 선택한 구성과 HCPU NNACC 연산자 지원을 확인하십시오.
SF32LB57x 인용한 가이드는 이 제품군의 NNACC 사용 가능 여부를 확정하지 않습니다. AI용으로 선택하기 전에 정확한 부품, 보드, SDK의 연산자, 런타임, 메모리 지원을 확인하십시오.
SF32LB58x 선택한 부품의 메모리와 HCPU/LCPU 리소스가 제품 요구 사항을 충족하는 경우, AI, 그래픽, 오디오를 함께 처리하는 워크로드에 고려할 수 있습니다. 연산자, 통합 비용, 측정된 에너지를 확인하십시오.

이 표는 제품 선택을 위한 가이드이며 데이터시트를 대체하지 않습니다. 정확한 가속기 사용 가능 여부, 지원되는 연산자, 메모리 한도, SDK 툴링은 선택한 부품 번호에서 확인해야 합니다.

모델 개발 흐름

일반적인 임베디드 AI 워크플로는 여러 단계로 이루어집니다.

  1. 대표 데이터를 사용해 워크스테이션에서 모델을 학습시키거나 선택합니다.
  2. 모델 선택, 프루닝, 양자화 또는 아키텍처 변경으로 임베디드 제약에 맞게 모델을 줄입니다.
  3. 추론 런타임과 모델 표현을 선택하거나 구현한 다음, 선택한 SDK 커널에 대한 연산자 커버리지와 수치 호환성을 확인합니다. NNACC HAL에 전체 모델 변환기가 포함되어 있다고 가정하지 마십시오.
  4. 변환과 양자화 후 수치 정확도를 검증합니다.
  5. 전처리, 추론, 후처리를 펌웨어에 통합합니다.
  6. 실제 하드웨어에서 지연 시간, 메모리 사용량, 전력, 정확도를 프로파일링합니다.
  7. 의도한 저전력 상태로의 진입과 복귀를 포함하여, Bluetooth, 디스플레이, 오디오, 센서 워크로드가 현실적으로 동시에 실행되는 상황을 테스트합니다.

가장 흔한 실수는 신경망만 최적화하고 파이프라인의 나머지를 무시하는 것입니다. 많은 임베디드 제품에서 전처리, 메모리 이동, 센서 타이밍, 후처리는 가속기만큼 중요할 수 있습니다.

양자화와 모델 크기

마이크로컨트롤러급 AI는 대개 소형 모델과 효율적인 수치 형식에 의존합니다. 흔히 8비트 정수 데이터를 사용하는 양자화 모델은 부동 소수점 모델에 비해 메모리 사용량, 필요한 메모리 대역폭, 연산 비용을 줄일 수 있습니다.

8비트 모델이라고 해서 NNACC와 자동으로 호환되는 것은 아닙니다. SDK v2.5.1 HAL 구성은 int8_t 버퍼와 bias_shift / out_shift 필드를 사용합니다. 이 필드들은 임의의 제로 포인트, 채널별 스케일, 최신 int8 연산자 전체에 대한 지원을 확정하지 않습니다. 텐서 레이아웃, 부호 여부, 시프트, 바이어스 표현을 정확한 커널 구현과 대조하여 확인한 다음, 대표 입력과 경계 입력으로 출력을 소프트웨어 레퍼런스와 비교하십시오.

양자화에는 트레이드오프가 있습니다.

  • 효율을 크게 향상시킬 수 있습니다.
  • 모델 크기와 텐서 메모리를 줄일 수 있습니다.
  • 모델을 신중하게 학습하거나 보정하지 않으면 정확도가 떨어질 수 있습니다.
  • 일부 연산자는 가속기나 런타임에 깔끔하게 매핑되지 않을 수 있습니다.

양산에서는 변환 후 정확도와 시스템 성능을 모두 측정하십시오. 데스크톱 학습 환경에서 잘 동작하는 모델도 양자화, 센서 노이즈 노출, 임베디드 전처리를 거치면 다르게 동작할 수 있습니다.

메모리와 대역폭 고려 사항

모델이 작아 보여도 AI 워크로드는 메모리를 많이 쓸 수 있습니다. 시스템에는 다음을 위한 메모리가 필요할 수 있습니다.

  • 모델 가중치.
  • 입력 텐서.
  • 중간 활성화 버퍼.
  • 출력 텐서.
  • 오디오 프레임, 센서 윈도, 카메라 프레임.
  • 전처리 및 후처리 버퍼.
  • 동시에 실행되는 UI, Bluetooth, 애플리케이션 데이터.

선택한 디바이스의 내부 SRAM, 플래시, PSRAM, 캐시 구성에 맞춰, 자주 접근하는 텐서와 중간 버퍼를 CPU와 가속기가 효율적으로 접근할 수 있는 위치에 배치하십시오. 모델 크기만 최적화하지 말고 외부 스토리지, 스테이징 버퍼, 복사본을 함께 예산에 반영하십시오.

먼저 선택한 NNACC가 모든 버퍼에 접근할 수 있는지 확인하십시오. 외부 플래시나 PSRAM에 배치한 버퍼는 스테이징 복사 없이는 자동으로 사용할 수 없습니다. 복사 시간, 작업용 RAM, 에너지를 예산에 포함하십시오. SDK v2.5.1 HAL 구현은 검사 대상 버퍼 크기를 4바이트 단위로 올림하며, 버퍼의 시작 주소와 검사된 끝 주소가 서로 다른 1 MiB(1,048,576바이트) 주소 윈도에 걸치면 해당 버퍼를 거부합니다. 입력과 바이어스도 같은 윈도에 있어야 합니다. 끝 주소가 정확히 다음 윈도 경계에 있으면 이 검사에 실패합니다. 이러한 실제 검사에 맞춰 할당을 계획하고, 다음 작업을 시작하기 전에 오류 반환값을 확인하십시오.

CPU가 DMA 또는 NNACC와 버퍼를 공유할 때는 각 전송이나 작업 동안 독점 소유권을 지정하십시오. 하드웨어가 읽기 전에 CPU가 쓴 입력을 클린(clean)하십시오. 하드웨어가 쓰기 전에 SDK에 따라 대상의 캐시 라인을 준비하여, 더티 CPU 라인이 나중에 결과를 덮어쓰지 않게 하십시오. 하드웨어 완료가 확인된 후에는 출력을 읽기 전에 오래된 CPU 복사본을 무효화(invalidate)하십시오. 캐시 유지보수 대상 범위는 완전한 캐시 라인 단위로 정렬하고, 관련 없는 활성 데이터와 해당 라인을 공유하지 않도록 하십시오. 하드웨어가 쓴 뒤에 오래된 출력을 클린하면 결과가 손상될 수 있으며, 클린과 무효화는 서로 대체할 수 없습니다.

오디오, 센서, 카메라 파이프라인

AI 가속이 단독으로 동작하는 경우는 드뭅니다. 대개 센서, 오디오 또는 카메라 파이프라인의 일부입니다.

오디오와 음성

음성 또는 오디오 이벤트 감지의 파이프라인에는 마이크 입력, DMA 버퍼링, 프레이밍, 필터링, 특징 추출, 추론, 이벤트 스무딩이 포함될 수 있습니다. NNACC는 지원되는 신경망 연산을 실행할 수 있으며, 나머지 그래프는 펌웨어 또는 선택한 런타임이 처리하고, CPU 또는 오디오 서브시스템이 샘플과 특징을 관리합니다. 모델과 검증된 소프트웨어 구현은 여전히 필요합니다.

대표적인 예는 다음과 같습니다.

  • 키워드 스포팅.
  • 소프트웨어 지원에 따른 웨이크 워드 감지.
  • 오디오 장면 또는 이벤트 분류.
  • 음성 활동 감지.

모션과 센서 퓨전

웨어러블 제품의 센서 데이터는 흔히 가속도계, 자이로스코프, 심박 센서, SpO2 센서, ECG 프런트엔드 또는 기타 주변 장치에서 옵니다. AI는 모션 상태, 제스처, 활동 패턴 또는 건강 관련 신호 특징을 분류할 수 있습니다.

요구되는 감지 범위와 지연 시간이 허용하는 경우 샘플을 일괄 처리하고 인터럽트를 사용하십시오. 적합한 백그라운드 처리를 사용자가 프로그래밍할 수 있는 저전력 프로세서로 옮기면 애플리케이션 CPU의 웨이크업을 줄일 수 있지만, 비교에는 해당 프로세서의 동작, 센서 샘플링, 웨이크업 비용을 포함하십시오. 이벤트를 감지하는 데 필요한 센싱을 끄지 마십시오.

카메라와 이미지 입력

카메라 입력은 정확한 칩, 패키지, 보드, 캡처 드라이버에 따라 달라집니다. SDK v2.5.1 GC032A 센서 드라이버는 8비트 DVP 또는 2비트 SPI 센서 출력을 구성하지만, 이것이 두 캡처 경로가 모든 SF32 디바이스에서 동작한다는 증거는 아닙니다. 카메라를 선택하기 전에 핀, 주변 장치 또는 PTM 캡처 지원, 센서 타이밍, 드라이버를 확인하십시오. 이미지 워크로드는 오디오나 모션 워크로드보다 큰 프레임 버퍼와 더 많은 대역폭이 필요한 경우가 많지만, 실제 해상도와 속도를 비교하십시오.

더 작은 프레임, 관심 영역, 더 낮은 프레임 속도 또는 임베디드 지향 모델을 고려하십시오. 캡처 후 펌웨어에서 자르면 모델 입력은 줄어들지만 카메라 전송 트래픽이나 캡처 버퍼 크기가 반드시 줄어드는 것은 아닙니다. 이러한 비용을 줄이려면 센서 측 크롭이나 축소된 수집이 필요할 수 있습니다.

스케줄링과 전력 관리

AI 작업은 시스템의 나머지 부분을 고려하여 스케줄링하는 것이 좋습니다. 웨어러블 제품은 전력 또는 지연 시간 목표를 넘지 않으면서 Bluetooth 연결을 유지하고, 디스플레이를 갱신하고, 오디오를 캡처하고, 센서를 읽고, 추론을 실행해야 할 수 있습니다.

좋은 스케줄링 방법은 다음과 같습니다.

  • 감지 범위, 이벤트 누락 위험, 지연 시간 요구 사항에 따라 주기적 또는 이벤트 게이트 방식으로 추론합니다.
  • 인터럽트나 이벤트로 작업을 트리거할 수 있다면 폴링 루프를 피합니다.
  • 지연 시간 요구 사항이 허용하는 경우 센서 샘플을 일괄 처리합니다.
  • 안정적인 감지에 필요한 입력 윈도를 유지하면서 입력에서 판단까지의 지연 시간을 제한합니다.
  • AI 워크로드를 디스플레이 및 Bluetooth 동작과 조율합니다.
  • 완료, 버퍼 인계, 전력 관리 잠금 해제가 확인된 후에 CPU와 가속기를 허용된 저전력 상태로 되돌립니다. 필요한 센싱과 그 밖의 대기 중인 작업은 계속 활성 상태로 유지합니다.

추론 지연 시간만 보지 말고, 측정한 공급 전력(공급 전압 × 전류)을 시간에 대해 적분하여 전체 기능의 에너지를 측정하십시오. 센서 수집, 전처리, 복사, 가속기 작업, CPU 폴백, 후처리, 유휴 구간을 포함하십시오. 실행이 빨라지면 활성 에너지는 줄어들 수 있지만 더 일찍 슬립에 들어가지 못할 수도 있으며, 절감량은 나머지 시스템 부하에 따라 달라집니다. 추론 빈도를 줄이기 전에 동등한 감지 범위와 정확도를 비교하십시오.

SDK v2.5.1에서 블로킹 HAL 시작은 자체적인 명시적 타임아웃 없이 완료를 폴링합니다. 인터럽트 모드 동작에는 정상 동작하는 IRQ 핸들러와 완료 알림이 필요합니다. 시작 오류를 확인하고, 애플리케이션의 대기 시간을 제한하고, 버퍼를 재사용하거나 전력 관리 잠금을 해제하기 전에 복구 방법을 정의하십시오.

정확도, 지연 시간, 전력의 트레이드오프

임베디드 AI 설계는 정확도, 지연 시간, 전력 사이의 삼각 트레이드오프입니다.

표: 정확도, 지연 시간, 전력의 트레이드오프
목표 일반적인 설계 고려 사항
더 높은 정확도 더 큰 모델, 더 많은 특징 또는 더 긴 입력 윈도가 필요할 수 있습니다. 실제 정확도 향상과 메모리 비용을 검증하십시오.
더 낮은 지연 시간 수집, 큐잉, 연산 지연을 줄입니다. 윈도가 짧아지면 정확도가 떨어질 수 있고, 추론 빈도가 높아지면 에너지가 늘어날 수 있습니다.
더 낮은 전력 소형 모델과 효율적인 배치를 사용합니다. 감지 범위가 허용하는 경우에만 추론 빈도를 줄이고, 센싱과 슬립 정책을 확인하십시오.

적절한 균형은 제품마다 다릅니다. 제스처 감지기는 전력을 아낄 수 있다면 약간의 지연을 허용할 수 있습니다. 음성 트리거는 빠른 응답이 필요하지만 오탐에 의한 웨이크업은 피해야 합니다. 건강 모니터링 알고리즘은 즉각적인 분류보다 견고성과 장기 배터리 수명을 우선할 수 있습니다.

실용적인 설계 지침

SF32 AI 제품을 계획할 때는 모델이 아니라 제품 동작에서 시작하십시오.

  • 디바이스가 로컬에서 내려야 하는 판단은 무엇입니까?
  • 어떤 센서가 입력 데이터를 제공합니까?
  • 추론은 얼마나 자주 실행되어야 합니까?
  • 허용되는 지연 시간은 얼마입니까?
  • 모델 가중치와 텐서에 할당할 수 있는 최대 메모리 예산은 얼마입니까?
  • 정확도를 크게 잃지 않고 모델을 양자화할 수 있습니까?
  • 선택한 칩과 SDK에서 가속되는 연산은 무엇입니까?
  • Bluetooth, 디스플레이, 오디오, 추론이 함께 활성화되면 어떻게 됩니까?
  • 실제 제품 데이터로 모델 정확도를 어떻게 검증할 것입니까?
  • 필요한 경우 펌웨어가 현장에서 모델을 어떻게 업데이트하거나 교체할 것입니까?

성공적인 임베디드 AI 제품은 대개 소형 모델, 신중한 데이터 수집, 하드웨어를 고려한 메모리 배치, 현실적인 프로파일링, 불필요한 웨이크업을 피하는 전력 정책을 결합합니다.

대표적인 사용 사례

지원되는 연산자와 측정된 시스템 예산이 맞는 경우, 배터리로 동작하는 커넥티드 제품의 소형 로컬 추론에 SF32 AI 가속을 고려하십시오.

  • 워치, 밴드, 휴대용 디바이스의 제스처 인식.
  • 피트니스 및 건강 제품의 활동 분류.
  • 오디오 액세서리의 음성 이벤트 또는 키워드 감지.
  • 웨어러블용 센서 퓨전 알고리즘.
  • 센서와 소프트웨어가 지원하는 경우의 생체 신호 분석.
  • 스마트 디바이스의 로컬 이상 감지.
  • 카메라 입력이 있는 디바이스에서의 간단한 이미지 분류 또는 카메라 트리거 이벤트.
  • 사용자 컨텍스트에 적응하는 스마트 HMI 동작.

핵심 요약

  • NNACC는 지원되는 연산을 오프로드하고 CPU 점유율을 줄일 수 있습니다. 지연 시간과 에너지 이점은 전체 기능에서 검증해야 합니다.
  • NNACC는 센서, 오디오 또는 카메라 입력, 전처리, 메모리 이동, 후처리, 애플리케이션 로직까지 포함하는 전체 파이프라인의 일부입니다.
  • SDK v2.5.1은 SF32LB55x, SF32LB56x, SF32LB58x의 NNACC 리소스를 문서화하지만 SF32LB52x와 SF32LB57x의 사용 가능 여부는 확정하지 않습니다. 제품군 이름으로 지원 여부나 부재를 추정하지 말고 정확한 부품과 워크로드를 확인하십시오.
  • 실제 성능은 모델 크기, 양자화, 지원되는 연산자, 메모리 배치, 캐시 처리, DMA 동작, SDK 런타임 지원에 따라 달라집니다.
  • 로컬 추론은 제품의 응답, 오프라인, 개인정보 보호 또는 무선 트래픽 목표를 충족할 때 유용하며, 이러한 이점 중 어느 것도 가속기 하드웨어만으로 얻어지지는 않습니다.

최종 업데이트: