69 aziende Edge AI con NPU: chip, SDK e YOLO (2026)

Non esiste un unico mercato delle NPU. Questa guida non esaustiva segue 69 aziende ed ecosistemi di piattaforma: 51 fornitori con chip o piattaforme distribuibili, nove fornitori di IP NPU e nove aziende da tenere d'occhio, indicate chiaramente. Coprono classi di acceleratori incompatibili e quasi altrettanti stack di compilazione. Quasi tutti promettono lo stesso percorso: esportare un modello, quantizzarlo, compilarlo, copiare su una scheda un artefatto proprietario e avviarlo con il runtime del fornitore. I dettagli determinano se bastano un pomeriggio o un trimestre di ingegneria.

Questa guida mappa le aziende che nel 2026 forniscono hardware credibile per la computer vision. Riporta i chip pertinenti, i nomi di SDK e compilatori, gli artefatti di deployment, il livello di accesso pubblico e i modelli documentati dal fornitore. Dedica inoltre particolare attenzione ad Amlogic, il cui nuovo stack ADLA è sostanzialmente diverso dal precedente ecosistema NPU A311D.

Ambito della ricerca: le fonti sono state verificate il 15 agosto 2026. Le affermazioni sui modelli specifici provengono da pagine prodotto, documentazione, model zoo, repository o tutorial dei fornitori, salvo dove indicato diversamente. I TOPS dichiarati sono valori dei fornitori, non benchmark confrontabili in modo indipendente. Questa è una guida per sviluppatori, non un consiglio d'investimento né una classifica a pagamento.

Navigazione rapida: tabelle delle aziende | approfondimento su Amlogic | profili dei fornitori | tabella degli artefatti compilati | accesso e ciclo di vita | roadmap LibreYOLO

Il risultato più importante

L'hardware è frammentato, ma il modello di deployment è sorprendentemente uniforme:

PyTorch checkpoint
    -> ONNX or TFLite interchange graph
    -> representative calibration data
    -> vendor quantizer and graph compiler
    -> chip-specific binary or model package
    -> vendor runtime on the target
    -> application preprocessing, decode, NMS and rendering

ONNX consente esplicitamente runtime, generatori di codice e implementazioni hardware, ma un file ONNX è solo il punto di passaggio. Non significa che ogni operatore ONNX possa essere tradotto per ogni acceleratore. Forme statiche degli input, vincoli sugli operatori supportati, regole di quantizzazione e fallback sull'host determinano cosa viene davvero eseguito sulla NPU.

Lo stack software fa quindi parte del chip. Una NPU teoricamente veloce, ma con un compilatore ad accesso limitato o fragile, può essere un target di deployment peggiore di un dispositivo più piccolo con toolchain pubblica, model zoo, simulatore e runtime stabile.

Cosa significa "supportato" in questa guida

La documentazione dei fornitori usa il termine supporto con molta disinvoltura. Questo articolo distingue quattro livelli di evidenza:

La distinzione conta. "Importa ONNX" non equivale a "supporta la segmentazione YOLO11". Un modello può essere analizzato, ma poi passare alla CPU, compilarsi con valori numerici di output errati, superare la memoria dell'acceleratore o perdere accuratezza durante la quantizzazione.

Aziende e piattaforme NPU a colpo d'occhio

Le tabelle includono intenzionalmente SoC, acceleratori discreti, sensori intelligenti e target adiacenti basati su GPU o FPGA. Competono per la stessa decisione di deployment anche quando i fornitori usano nomi come NPU, AIPU, BPU, KPU, DLA, HTP, TPU o MLA.

SoC embedded, sensori intelligenti e processori industriali

Acceleratori edge e moduli dedicati

Piattaforme adiacenti che gli sviluppatori confrontano con le NPU

Amlogic: due generazioni NPU, non una

Amlogic merita un approfondimento perché sul web spesso si mescolano prodotti incompatibili. L'azienda ha un percorso precedente basato su VeriSilicon e il nuovo percorso proprietario ADLA. Usano compilatori, artefatti e runtime diversi.

La scheda tecnica A311D identifica la NPU originale INT8 da 5 TOPS. La vecchia pagina applicativa Khadas VIM3 e la panoramica NPU documentano DenseNet CTC, MTCNN, RetinaFace, YOLOFace, YOLOv2, YOLOv3, YOLOv3-tiny, YOLOv4, YOLOv7-tiny e YOLOv8n; la panoramica documenta inoltre YOLOv8n-pose e indica FaceNet come deprecato. Sono esempi reali, ma riguardano il vecchio ecosistema Acuity .nb, non gli attuali chip ADLA. A311D non è A311D2 e C305X non è C305X2.

C'è anche una seconda insidia hardware. La guida alle revisioni Khadas VIM4 spiega che la scheda originale V12/A311D2 revisione B non ha una NPU; la NPU dichiarata da 3.2 TOPS appare sulle schede V13A e successive, con componente A311D2-N0D revisione C. Il solo nome del prodotto non basta per scegliere un dispositivo di test.

Lo stack AMLNN e ADLA attuale

L'attuale AMLNN Toolkit copre conversione dei modelli, quantizzazione, compilazione, inferenza e profiling. La guida utente di maggio 2026, fissata a una revisione specifica, documenta importatori per ONNX, TFLite in virgola mobile o quantizzato, TorchScript .pt e PyTorch 2 ExportedProgram/PT2. Nella guida dettagliata i percorsi TensorFlow, Paddle e Keras sono indicati come pianificati, anche se la panoramica del repository usa formulazioni più ampie. Il compilatore produce .adla. Il deployment Python usa AMLNN o amlnn_edge_toolkit_lite; il C/C++ nativo collega libnnsdk.so tramite nnsdk2.h. Lo sviluppo host può usare ADB con nnserver; il runtime supporta anche Android, Buildroot, Yocto e alcuni ambienti Debian/Armbian.

Gli identificativi di piattaforma pubblicati dal toolkit sono:

Il campo target non è cosmetico. Amlogic richiede che .adla, nnsdk2.h, libnnsdk.so, BSP e generazione di compilatore/runtime corrispondano. La guida rapida fissata a una revisione richiede ADLA driver 2.0.2 o superiore, NNSDK 3.0.0 o superiore e NNSDK2 1.0.0 o superiore; la guida al deployment Android chiarisce i rapporti tra libreria, header, driver e BSP. Considera .adla un artefatto di build vincolato all'ABI, non un modello portabile.

Anche la quantizzazione dipende dalla generazione NPU. I target ADLA2 da 001 a 006 documentano la compilazione W8A8 e W8A16. I target ADLA3 007 e 008 aggiungono le combinazioni W4A8, W4A16, W8A8, W8A16 e W16A16, con supporto nativo INT4, FP16 e BF16 nella guida agli operatori. Amlogic consiglia da 200 a 500 campioni di calibrazione rappresentativi. L'opzione con dati casuali è esplicitamente destinata ai test di prestazioni, non a una quantizzazione che preservi l'accuratezza.

Copertura dei modelli Amlogic documentata

Il model playground Amlogic fissato a una revisione è un'evidenza molto più solida di una generica affermazione sul supporto ONNX. La sua matrice di supporto/esempi pubblicata cita A311D2, S905X5, A311Y3, C305X2 e A123X. L'accettazione da parte del compilatore degli altri ID target non dimostra che l'intero elenco sia stato convalidato su di essi.

Lo stesso repository pubblica i seguenti valori W8A8 di runtime dei modelli. Sono misurazioni del fornitore sulla rete neurale eseguita sulla NPU, non pipeline complete da videocamera.

Le riserve sono particolarmente importanti. La guida agli operatori di Amlogic colloca NMS nel software sia su ADLA2 sia su ADLA3. Il README definisce questi valori come risultati nativi di runtime del modello NPU, escludendo preelaborazione e postelaborazione; non specifica se includano tutti i trasferimenti di memoria. Le righe sull'accuratezza YOLO usano sottoinsiemi COCO di 300 immagini, non l'intero set di validazione; le righe di classificazione usano ImageNet val1000. Le tabelle riportano inoltre una latenza YOLOv8n A311Y3 diversa da quella della tabella FPS, in condizioni che il repository non chiarisce. Non sono indicati clock, modalità di alimentazione, raffreddamento, stato termico a regime, versione esatta di SDK/BSP e durata del test. Usa i valori per capire uno stack del fornitore, non per classificarlo rispetto ad altri.

Perché Amlogic è strategicamente interessante

Amlogic combina quattro caratteristiche insolite: un'ampia presenza nei SoC embedded, uno stack di compilazione appena reso pubblico, una matrice di modelli attuale che si sovrappone molto ai task di LibreYOLO e una presenza limitata di integrazioni di prima classe nelle principali librerie di training. Anche i repository attuali sono recenti: sono apparsi pubblicamente tra la fine del 2025 e l'inizio del 2026, con manuali sostanziali datati da maggio a luglio 2026. Questo crea un'opportunità concreta per muoversi per primi e un corrispondente rischio di stabilità delle API.

Un'integrazione pulita dovrebbe usare l'esportazione ONNX deterministica di LibreYOLO come input del compilatore, richiedere immagini di calibrazione rappresentative per le build a bassa precisione, produrre .adla con un manifest di metadati e caricarlo tramite un adapter NNSDK2. A311D legacy dovrebbe usare un target .nb chiaramente distinto, perché presentare .nb e .adla come un unico backend causerebbe incompatibilità silenziose. I repository Amlogic riportano licenze Apache-2.0 di primo livello, ma prima che LibreYOLO ne ridistribuisca mirror occorre confermare direttamente i diritti sui pacchetti wheel inclusi, sulle librerie condivise, su nnserver e sui binari Android AAR.

Gli ecosistemi pubblici di deployment più solidi

Le aziende seguenti offrono attualmente la combinazione più chiara di hardware reperibile, materiali tecnici pubblici ed evidenze su modelli specifici. Questo non significa che siano sempre più veloci. Significa che è più facile valutare le loro dichiarazioni di compatibilità prima di acquistare l'hardware.

Hailo

Hailo è un esempio di riferimento per un ecosistema di acceleratori per la visione dedicati. I modelli vengono analizzati in un Hailo Archive, ottimizzati e quantizzati usando immagini rappresentative, poi compilati in un file Hailo Executable Format (.hef). Le applicazioni caricano il file HEF tramite HailoRT.

Il Hailo Model Zoo contiene ricette, modelli preaddestrati, configurazioni di postelaborazione e dati prestazionali per rilevamento, segmentazione, classificazione, posa e altri task. La copertura YOLO include YOLOv3/v4/v5/v6/v7/v8/v9/v10/11/12 e YOLO26, oltre a YOLOX, DAMO-YOLO, SSD ed EfficientDet. La tabella di object detection Hailo-8, fissata a una versione, è una fonte di compatibilità migliore di una pagina prodotto generica; l'applicazione standalone documenta pipeline YOLO distribuibili.

C'è un'importante distinzione tra versioni. Hailo-8 e Hailo-8L usano la linea precedente Model Zoo 2.x, Dataflow Compiler 3.x e HailoRT 4.x, mentre Hailo-10 e Hailo-15 usano la generazione attuale 5.x. Ricette, comportamento degli analizzatori e file HEF non sono intercambiabili solo perché tutti i dispositivi si chiamano Hailo.

Hailo-15 ha anche un livello applicativo distinto. Usa Vision Processor Software Package e Hailo Media Library, non il percorso host in stile TAPPAS di Hailo-8/10H. Il repository di riferimento pubblico hailo-camera-apps è stato archiviato il 3 maggio 2026, mentre hailo-apps-core resta un framework applicativo pubblico separato. L'archiviazione di un repository non prova la fine del ciclo di vita del prodotto, ma per i progetti Hailo-15 va verificato nel Developer Zone quale pacchetto applicativo sia attuale.

La guida al deployment Hailo di LibreYOLO si ferma intenzionalmente al passaggio statico ONNX, perché il compilatore proprietario non può essere incluso come dipendenza Python. Questo è il limite corretto tra la produzione di un grafo adatto e l'affermazione di avere un HEF testato.

Rockchip

Rockchip ha una delle maggiori presenze nell'embedded Linux per hobbisti e aziende, soprattutto tramite schede RK3588, RK3576 e RK356x. Il RKNN-Toolkit2 pubblico converte e quantizza modelli su un host Linux x86; RKNN Runtime o Toolkit-Lite eseguono il file .rknn risultante sulla scheda.

Il RKNN Model Zoo è particolarmente chiaro su chip, famiglie di modelli e precisione. La tabella attuale elenca percorsi FP16 e INT8 per YOLOv5/6/7/8/10/11, YOLOX, PP-YOLOE, YOLO-World e varianti di segmentazione YOLOv5/v8; YOLOv8 OBB e YOLOv8 pose sono elencati solo per INT8. Copre anche OCR, volti e altre reti di segmentazione.

LibreYOLO dispone già di un esportatore RKNN diretto e prudente. Convalida quattro varianti esatte di rilevamento su RK3588, può confrontare il simulatore del compilatore con ONNX Runtime e rifiuta famiglie non convalidate, invece di equiparare una build riuscita a predizioni corrette. Questa dichiarazione di supporto circoscritta è un buon modello per ogni futuro backend NPU.

Axelera AI

Axelera AI, spesso scritto erroneamente "Accelera", produce l'AIPU Metis e lo vende in prodotti M.2, PCIe e multi-chip. La famiglia Metis è acquistabile pubblicamente; Europa e Titania sono prodotti annunciati per la gamma, quindi la disponibilità non va appiattita in un solo stato. Il Voyager SDK è pubblico su GitHub e gestisce selezione, compilazione, quantizzazione, esecuzione e pipeline applicative; il supporto clienti richiede ancora un account.

Il Voyager Model Zoo pubblico è tra i più informativi del settore. Elenca variante, dimensione d'input, precisione, accuratezza e prestazioni misurate per YOLOv3, YOLOv5, YOLOv7, YOLOv8, YOLOv9, YOLOv10, YOLO11, YOLO26 n/s/m/l/x, YOLOX, YOLO-NAS, OBB, posa e segmentazione, oltre a molti modelli di classificazione e predizione densa. Pubblicare la perdita di quantizzazione e l'accuratezza insieme alla velocità è più utile dei soli TOPS di picco.

I nomi degli artefatti sono cambiati con la generazione API. Il flusso di compilazione alpha Pipeline Builder produce un modello .axm e può impacchettare una pipeline portabile come .axe. La documentazione della pipeline classica descrive .axmodel più metadati del modello e un manifest. L'integrazione deve rilevare la generazione Voyager installata, invece di codificare un'unica estensione.

Qualcomm

Qualcomm raggiunge un enorme numero di dispositivi, ma l'espressione "NPU Qualcomm" nasconde interfacce diverse. Gli sviluppatori incontrano Hexagon HTP tramite QAIRT/QNN, il flusso SNPE precedente, i servizi di compilazione Qualcomm AI Hub, LiteRT oppure il provider QNN di ONNX Runtime, a seconda del dispositivo e della categoria del prodotto.

Il repository ufficiale Qualcomm AI Hub Models offre solide evidenze a livello di modello. Pubblica pacchetti ottimizzati per rilevamento/segmentazione/posa YOLOv3, YOLOv5, YOLOv6, YOLOv7, YOLOv8, YOLOv9, YOLOv10, YOLO11 e YOLO26, oltre a YOLOX, YOLO-World, YOLOR, RF-DETR e molti modelli di classificazione, profondità e posa. AI Hub consente anche profiling specifico per dispositivo, importante perché un modello compilato per una generazione HTP non è automaticamente portabile a un'altra.

Il costo principale d'integrazione deriva dall'ampiezza della matrice: Android o Linux embedded, componenti ordinabili QCS o Snapdragon consumer, architettura HTP, versione QNN/QAIRT e schema di quantizzazione sono tutti rilevanti. Le pagine attuali di Qualcomm sono inoltre in disaccordo sullo stato di Dragonwing IQ-9075: la pagina prodotto lo indica come Active e la sua EVK è valutabile, mentre il Product Longevity Program lo indica ancora come Sampling e riporta una longevità fino al 2038. Il prefisso di ordinazione/SKU è QCS9075; Qualcomm dichiara configurazioni da 50 e 100 TOPS INT8 dense più supporto Ubuntu/Yocto. Lo stato di produzione va confermato per lo SKU ordinato esatto e un'integrazione LibreYOLO dovrebbe registrare quello SKU, non creare una cartella generica "Qualcomm".

DEEPX

Gli acceleratori DX-M1/DX-M1M di DEEPX usano l'SDK DXNN. DX-COM compila e quantizza il modello, DX-RT lo esegue e l'artefatto distribuito usa il formato .dxnn. L'azienda pubblica DX-AllSuite, esempi applicativi in DX-APP e un ampio Model Zoo online.

Alla verifica del 15 agosto 2026 il catalogo pubblico riportava 354 voci con DX-COM 2.4.0 e DX-RT 3.4.0. La copertura documentata comprende YOLOv3 fino a YOLO11 e YOLO26, YOLOX, SSD, EfficientDet, NanoDet, DAMO-YOLO, segmentazione YOLO, posa e box orientati. DEEPX è un target d'integrazione particolarmente plausibile perché i confini tra compilatore e runtime e l'artefatto di deployment hanno nomi chiari, con un'ampia copertura pubblica della visione.

I SoC industriali sono ecosistemi diversi

I fornitori industriali spesso offrono cicli di vita più lunghi e una migliore integrazione con videocamere, safety e sistemi real-time rispetto ai SoC per schede maker. I loro stack AI possono essere più complessi perché lo stesso fornitore può offrire contemporaneamente diverse architetture NPU senza relazione tra loro.

Texas Instruments

Gli attuali processori edge AI di TI includono AM62A, AM67A, AM68A, AM69A e dispositivi TDA4 correlati. Il percorso software combina Processor SDK Linux, compilatore/runtime TIDL, Edge AI TIDL Tools ed Edge AI Model Zoo. TIDL può integrarsi con ONNX Runtime, TensorFlow Lite e altri runtime applicativi, delegando i sottografi supportati.

TI pubblica ben più di un'affermazione sull'importazione di framework: lo zoo contiene modelli convertiti e metadati prestazionali per rilevamento di oggetti, segmentazione, posa, classificazione, profondità e altri task. TI avverte inoltre che gli artefatti del model zoo sono punti di partenza per lo sviluppo e non asset automaticamente pronti per la produzione. È una precisazione utile, spesso assente nei confronti tra fornitori.

TI indica anche TDA54-Q1 come Preview, con fino a quattro NPU C7 e fino a 400 TOPS per quel componente; la più ampia famiglia TDA5 è dichiarata fino a 1.200 TOPS. Sono dichiarazioni del fornitore per una nuova generazione, non autorizzano a trasferire la convalida TIDL dei modelli AM6xA/TDA4 a TDA54-Q1 prima della pubblicazione di una matrice specifica per target.

NXP

NXP richiede almeno quattro descrizioni di backend:

L'eIQ Model Zoo contiene asset o ricette per YOLOv4-tiny, YOLOv8, NanoDet, CenterNet, FastestDet, SSD Lite, YOLACT e altri modelli; la voce YOLOv5 è stata aggiunta solo come documentazione. Una voce convalidata per un backend non dimostra la compatibilità degli altri tre. Le indicazioni NXP per esportare YOLO sulle piattaforme i.MX illustrano questo problema di conversione specifico per target. NXP afferma che il monolitico eIQ Toolkit non riceve aggiornamenti dopo la versione 1.17 del terzo trimestre 2025; i flussi attuali usano pacchetti autonomi come eIQ Neutron SDK.

NXP ha completato l'acquisizione di Kinara nell'ottobre 2025. La scheda tecnica Ara240 dichiara fino a 40 eTOPS e riporta 313 immagini al secondo per YOLOv8n. NXP elenca Ara SDK ed eIQ Toolkit nella pagina prodotto, ma ciò non dimostra l'intercambiabilità degli artefatti con il separato percorso Neutron i.MX 95. Il modulo M.2 da 16 GB è attivo, mentre l'opzione USB è in preproduzione. NXP definisce la "e" in eTOPS come "equivalent", non "effective": non è la stessa metrica TOPS INT8 densa di altri fornitori e non va confrontata direttamente.

STMicroelectronics

I dispositivi STM32N6x7, inclusi STM32N657 e STM32N647, integrano un acceleratore Neural-ART da 600 GOPS in un prodotto di classe MCU; la linea general-purpose N6x5 non include quell'acceleratore. STM32Cube AI Studio e ST Edge AI Core analizzano e ottimizzano i modelli importati, mentre STM32 AI Model Zoo Services fornisce flussi di deployment, ottimizzazione, benchmark ed esempi.

L'attuale panoramica object detection documenta Tiny YOLOv2, YOLOv5u, YOLOv8, YOLO11, YOLO26 e ST-YOLOX, oltre a servizi di classificazione, posa e segmentazione. Non è la stessa classe prestazionale di una scheda PCIe da 200 TOPS. È interessante perché acquisizione dalla videocamera, inferenza e controllo possono rientrare in limiti embedded molto stretti di potenza e memoria.

Renesas

I processori Renesas RZ/V integrano acceleratori DRP-AI. Il software è passato da DRP-AI Translator e DRP-AI TVM verso RUHMI, basato sulla tecnologia MERA di EdgeCortix. Il repository open RZ/V DRP-AI TVM e l'elenco di convalida RZ/V2H indicano varianti YOLOv5, YOLOv8, YOLO11 e YOLO26 n/s/m, YOLOX, reti per posa e segmentazione, oltre a modelli di classificazione.

Renesas è un target credibile per robotica e industria, ma per garantire la riproducibilità occorre registrare la scheda esatta, la generazione DRP-AI, la versione del translator e la postelaborazione lato CPU.

Sensori intelligenti e processori progettati per le videocamere

Sony IMX500

Sony IMX500 non è un normale processore applicativo. Integra rilevamento delle immagini ed elaborazione AI in modo che l'inferenza possa avvenire nel sensore, riducendo la quantità di dati immagine che deve uscire dalla videocamera. Raspberry Pi AI Camera rende questa architettura particolarmente accessibile.

Il repository ufficiale Raspberry Pi IMX500 pubblica modelli YOLOv8n, YOLO11n, EfficientDet Lite0, NanoDet+ e SSD MobileNetV2 FPN Lite già impacchettati. La documentazione AI Camera spiega conversione, packaging e postelaborazione sul sensore. L'unità di deployment è un pacchetto RPK, non un file ONNX generico; memoria del sensore e vincoli sugli operatori sono limiti progettuali fondamentali. La pagina prodotto di Raspberry Pi dichiara che la videocamera resterà in produzione almeno fino a gennaio 2028.

Ambarella

I processori CVflow di Ambarella sono consolidati in videocamere, droni e visione automotive. Le famiglie prodotto attuali includono CV72/CV75 per videocamere, CV5/CV52 per sistemi di visione con prestazioni superiori e dispositivi automotive CV3-AD. La piattaforma per sviluppatori Cooper e il flusso di compilazione/runtime CVflow costituiscono lo stack software dichiarato pubblicamente.

Il model garden pubblico per sviluppatori cita YOLOX, RTMDet, DeepLabV3+, TopFormer, OWL-ViT e modelli multimodali. Tuttavia, la documentazione dettagliata del compilatore e i download restano orientati ai partner. Un'integrazione Ambarella dovrebbe quindi partire da un rapporto con il fornitore o l'OEM, non dall'ipotesi che sia disponibile un pacchetto pip pubblico.

Synaptics Astra

Synaptics ha tre target pertinenti. I sistemi Astra SL1600/SL1680 usano il toolkit SyNAP, che converte un modello sorgente insieme a una descrizione YAML in un pacchetto model.synap. I dispositivi SL2611/13/15/17/19 più recenti usano la piattaforma Torq, un flusso basato su IREE/MLIR che produce .vmfb. La serie SR100 è una famiglia MCU distinta, basata su Cortex-M55 ed Ethos-U55, con un proprio SDK. Questi artefatti e API non sono intercambiabili.

Il tutorial ufficiale di benchmark YOLO è molto concreto: esporta YOLOv8 in TFLite, esegue la calibrazione asimmetrica UINT8 in SyNAP, compila per SL1680 e poi avvia synap_cli e l'applicazione object detection. Dimostra YOLOv8n/v8s su SL1680 e descrive il supporto SyNAP fino a YOLO11. Una guida separata al rilevamento oggetti SL261x esegue YOLOv8 da un .vmfb Torq. Sono esempi ufficiali specifici per target, non la prova che ogni grafo YOLO sia supportato su tutte e tre le famiglie.

MediaTek Genio

MediaTek merita una sezione dedicata perché il suo attuale IoT AI Hub espone ora la matrice hardware/software, pacchetti modello e tabelle di benchmark che le vecchie analisi del settore non riuscivano a verificare. Genio 360/360P/420/520/720 usa NeuroPilot 8 con MDLA 5.3; Genio 510/700 usa NP6 con MDLA 3.0; Genio 1200 usa NP6 con MDLA 2.0. MediaTek dichiara che generazione NeuroPilot/MDLA, operatori, compilatore e runtime sono vincolati alla versione per tutto il ciclo di vita del SoC.

Il percorso AI analitico è incentrato su TFLite:

PyTorch model
    -> NeuroPilot Converter and representative calibration
    -> quantized .tflite
    -> version-matched ncc-tflite compiler
    -> chip-generation-specific .dla
    -> Neuron Runtime on MDLA

I prodotti Genio più recenti offrono anche delega LiteRT online e un percorso ONNX Runtime CPU/NPU sui sistemi operativi supportati. Sono modalità di esecuzione diverse dal deployment offline .dla. La guida all'architettura software e la matrice delle risorse rendono esplicita la distinzione.

La tabella ufficiale dei modelli analitici pubblica voci benchmark YOLOv5s e YOLOv8s e guide di conversione per più generazioni MDLA. Non distribuisce esplicitamente artefatti YOLO preconvertiti a causa delle restrizioni AGPL-3.0. Le misurazioni offline Quant8 a 640 x 640 includono rispettivamente 5.35 ms e 8.04 ms su Genio 720. La pagina del modello YOLOv8s pubblica tensori input/output, tempi specifici per backend e avvisi sulle operazioni personalizzate MediaTek. Sono benchmark del fornitore, non risultati di una pipeline completa da videocamera.

Il limite è l'accesso. La documentazione Yocto è pubblica e dettagliata, ma l'attuale bundle convertitore/compilatore completo NP8 e molti materiali Android sono indicati come risorse NDA o per clienti diretti. Un normale account sviluppatore non dà lo stesso accesso di un account cliente MediaTek Online. LibreYOLO dovrebbe quindi considerare Genio tecnicamente dimostrato, ma dipendente da una partnership per un'integrazione riproducibile del compilatore con modelli proprietari.

Ecosistemi edge AI incentrati sulla Cina

Alcune delle piattaforme di visione più capaci e accessibili a basso costo sono poco rappresentate nelle liste di mercato in lingua inglese.

D-Robotics e piattaforme BPU derivate da Horizon

D-Robotics gestisce l'ecosistema di schede per sviluppatori RDK basato su acceleratori BPU usati nei prodotti RDK X3, X5, Ultra e nelle nuove serie S100. Il ramo attuale rdk_x5 del RDK Model Zoo documenta percorsi YOLOv5/v5u, YOLOv8/9/10/11/12/13/26, YOLOE, YOLO-World, rilevamento, segmentazione, posa, classificazione, OCR e CLIP per RDK X5. X3 usa un ramo separato; la distribuzione attuale della serie S si trova nel ramo rdk_s del zoo principale; il vecchio repository rdk_model_zoo_s contiene demo storiche. L'elenco moderno X5 non prova quindi che ogni modello sia stato convalidato su X3, Ultra o S100.

OpenExplorer/Algorithm Toolchain importa ONNX o Caffe per PTQ e supporta flussi QAT orientati a PyTorch. Il deployment dipende dalla piattaforma: l'attuale RDK X5 usa .bin tramite hbm_runtime sopra libdnn, mentre il flusso principale attuale rdk_s usa .hbm tramite API hbm_runtime omonima sopra libhbucp; X3 conserva il ramo e le interfacce d'inferenza precedenti. Anche i materiali del vecchio rdk_model_zoo_s descrivono percorsi storici .bin e .hbm, quindi quegli artefatti devono restare abbinati al rispettivo ramo e toolchain. Gli operatori non supportati possono passare alla CPU. Gli esempi pubblici sono validi, ma l'abbinamento di versione tra RDK OS, firmware della scheda, toolchain e binario del modello fa parte del contratto di compatibilità.

AXERA

Le famiglie AX650/AX630/AX620 di AXERA compaiono in videocamere AI compatte e schede come la linea MaixCAM di Sipeed. Pulsar2 importa ONNX, esegue calibrazione e analisi della precisione, quindi produce .axmodel; AXEngine esegue l'artefatto.

Gli esempi ufficiali AXERA coprono YOLOv5/6/7/8/9/10/11/13/26, YOLOX e YOLO-World, con supporto dei task e dei chip variabile secondo la piattaforma. Sui target supportati, gli esempi YOLO26 attuali includono rilevamento, posa, segmentazione e OBB. Gli esempi di conversione Pulsar2 mostrano il lavoro effettivo: nomi esatti dei tensori, tagli dell'output, trasformazioni di layout, archivi di calibrazione e impostazioni hardware target.

SOPHGO

TPU-MLIR di SOPHGO è uno stack di compilazione interessante per integrazioni indipendenti perché il compilatore stesso è open source. Importa ONNX, PyTorch, TFLite e Caffe, abbassa e quantizza i grafi, quindi produce .bmodel per target BM o .cvimodel per hardware CV18xx.

Il progetto TPU-MLIR supporta flussi FP32, BF16, FP16 e INT8 in base al target. La raccolta di demo SOPHON cita YOLOv3/4/5/7/8/9/10/11/12/26, YOLOX, PP-YOLOE, YOLO-World, varianti OBB/segmentazione, SSD, CenterNet, RetinaFace, SAM/SAM2 e OCR. Come sempre, una demo su BM1684X non convalida lo stesso artefatto su BM1688 o CV18xx.

Huawei Ascend

La linea edge di inferenza Huawei include silicio Ascend 310/310P/310B nei prodotti Atlas 200I e 300I. CANN fornisce il compilatore ATC, il runtime AscendCL e kernel specifici per chip; ATC trasforma ONNX e altre rappresentazioni sorgenti in un modello offline .om.

L'attuale documentazione Atlas 200I DK A2 e gli esempi CANN forniscono un percorso YOLOv5 .om per Ascend 310B. Il più ampio e precedente Ascend ModelZoo contiene YOLOv2/3/4/5, YOLOX, YOLOR, SSD, RetinaNet, Mask R-CNN, posa e modelli di segmentazione, ma non va descritto come se ogni voce fosse stata riconvalidata su 310B. CANN, kernel, firmware e SoC devono corrispondere. Un .om per Ascend310P non è un artefatto Ascend generico.

Cambricon

Gli acceleratori MLU Cambricon usano Neuware e il motore d'inferenza MagicMind. Il repository pubblico MagicMind Cloud è fissato a MagicMind 1.7 e a una matrice MLU370-X4/S4; è evidenza storica di compatibilità, non una matrice per l'SDK attuale o per MLU270. Il repository documenta percorsi PyTorch, ONNX, Caffe e Paddle; TensorFlow è stato rimosso dal supporto del framework in 1.7 anche se restano esempi storici TensorFlow. L'attuale portale sviluppatori 3-series di Cambricon elenca release SDK complessive più recenti, quindi repository di esempi pubblici e stack commerciale attuale non vanno presentati come un'unica versione.

L'ufficiale repository cloud di modelli MagicMind pubblica una matrice MLU370-X4/S4 particolarmente diretta. Indica esempi YOLOv3, Tiny-YOLOv3, YOLOv4, YOLOv5, YOLOv7, YOLOv8, PP-YOLOE, SSD, RetinaFace, RetinaNet, Mask R-CNN, DeepLab e UNet, specificando anche se esistono esempi C++ o Python. L'evidenza è solida; la barriera principale è ottenere SDK e container tramite i canali Cambricon.

Canaan/Kendryte

I chip KPU attuali K230/K230D e quelli legacy K210/K510 di Kendryte sono importanti per le schede economiche e le videocamere intelligenti. Il compilatore nncase importa ONNX o TFLite, usa dati di calibrazione per la conversione a virgola fissa, simula il risultato su host e genera .kmodel.

La guida ufficiale allo sviluppo nncase K230 mostra come compilare, simulare ed eseguire YOLOv5s. Il catalogo separato delle demo AI include artefatti YOLOv8n di rilevamento, segmentazione e posa, mentre l'attuale changelog CanMV aggiunge esempi ottimizzati YOLOv8/11/26 di classificazione, rilevamento, segmentazione, OBB e posa. Il risultato YOLOv5s nella scheda tecnica è il benchmark effettivamente pubblicato; versioni del compilatore e plug-in KPU binario devono corrispondere all'SDK della scheda.

Allwinner

Allwinner V853 combina hardware multimediale orientato alle videocamere con una NPU Vivante da 1 TOPS. La guida NPU ufficiale in inglese descrive importazione Acuity/Pegasus, quantizzazione, verifica e deployment tramite viplite. Le pagine modello Allwinner e la guida YOLOv5 citano YOLOv2/3/4/4-tiny/5/5s, RetinaNet, MobileNet, ResNet e reti per volti/persone.

È supporto reale alla computer vision, ma resta vincolato alla vecchia toolchain Tina Linux/Vivante e a download SDK che dipendono dall'account. Va incluso nella mappa con questo limite esplicito.

Piattaforme coreane, taiwanesi e cinesi spesso trascurate

Le liste in inglese spesso passano da Rockchip a NVIDIA, ignorando una seconda fascia di silicio reale e documentato. Alcuni di questi ecosistemi hanno matrici YOLO attuali più ampie di quelle di startup occidentali più note.

Mobilint

Il fornitore coreano Mobilint vende REGULUS a basso consumo e l'acceleratore ARIES MLA100 con throughput superiore. Il suo SDK qb accetta input orientati a PyTorch, TensorFlow, TFLite, ONNX e Keras, quantizza in INT8 e genera un artefatto .mxq compilato. La matrice pubblica per la visione elenca rilevamento YOLOv3/v5/v7/v8/v9/v10/11/12/26 e varianti YOLO per segmentazione, posa e OBB. La pagina ARIES pubblica persino risultati specifici YOLO11s e YOLO26m. È una forte evidenza d'integrazione, anche se l'accesso a SDK e hardware resta commerciale.

Sunplus

Sunplus SP7350/C3V usa uno stack NPU derivato da Vivante, ma con un packaging diverso da Allwinner o dal vecchio Amlogic. Il flusso pubblico combina conversione Acuity, ambiente Docker NPU, runtime SNNF e output .nb. La guida ufficiale per YOLOv8 personalizzato descrive conversione e deployment, non si limita ad affermare il supporto del framework. IP correlati non rendono .nb portabile verso un altro SoC basato su Vivante.

ESWIN Computing

La famiglia RISC-V ESWIN include EIC7700/EIC7700X e i dual-die EIC7702/EIC7702X; EIC7700 è presente in schede in vendita come Milk-V Megrez. ENNP include EsQuant, l'attuale compilatore EsAAC, generazione di dati di riferimento, simulazione e runtime ESSDK, con output .model; materiali ENNP più vecchi usavano il nome ennc-compile. L'attuale pagina EsAAC documenta input ONNX, quindi gli altri framework devono essere esportati o convertiti in quel formato IR supportato. La panoramica ENNP e il tutorial YOLOv3 ospitati da Milk-V dimostrano un percorso pubblico end-to-end, ma non un'ampia matrice attuale di modelli/accuratezza.

Nuvoton M55M1

Nuvoton M55M1 è una soluzione di classe MCU Cortex-M55 più Ethos-U55-256, non un processore applicativo Linux. NuEdgeWise/NuML e Arm Vela preparano modelli TFLite Micro quantizzati. Il repository pubblico NuEdgeWise cita YOLOv8-nano, YOLOX-nano, YOLO Fastest v1.1, SSD-MobileNet FPNLite e diversi classificatori. Sono esempi credibili per i vincoli di memoria e potenza del dispositivo, non prove per le varianti YOLO standard a 640 pixel.

Rebellions e FuriosaAI

La linea ATOM di Rebellions usa l'RBLN SDK e artefatti compilati .rbln. La release ufficiale di supporto cita YOLOv3 tiny/full/SPP, YOLOv5 da n a x, YOLOv6 da n a l, varianti YOLOv7 e YOLOv8 da n a x. L'attuale matrice di supporto delle schede indica ATOM CA02 e ATOM+ CA12 come EoL, mentre ATOM+ CA22 e ATOM-Max CA25 sono Active. ATOM-Lite CA21 ha una pagina prodotto ma non compare nella matrice SDK, quindi lo stato attuale della toolchain è incerto. La documentazione è pubblica, ma il pacchetto del compilatore richiede credenziali Rebellions Portal.

FuriosaAI va suddivisa per generazione. Warboy è il vecchio acceleratore per computer vision, con artefatti INT8 .enf e un model zoo ufficiale che contiene SSD, YOLOv5M/L e YOLOv7-w6-pose. RNGD usa uno stack .fxb diverso, rivolto soprattutto a carichi LLM/VLM. La roadmap attuale di Furiosa registra il supporto YOLOv8m per la visione come completato nel quarto trimestre 2024, ma le attuali risorse pubbliche su modelli supportati e prestazioni sono incentrate su LLM/VLM e non espongono una matrice dettagliata di accuratezza/prestazioni YOLOv8m. È una prova relativa a una generazione rilasciata, non una dichiarazione di compatibilità Warboy.

Realtek, Telechips, T-Head e SigmaStar

Queste quattro piattaforme sono reali, ma offrono percorsi BYOM pubblici più limitati, datati o soggetti ad accesso:

La smart vision HiSilicon è distinta da Huawei Ascend

I SoC per videocamere Hi3516CV610/DV500, Hi3519DV500 e Hi3403V100 di HiSilicon espongono un flusso ATC verso .om tramite runtime NNN/SVP-NNN. L'HiSpark model zoo ufficiale cita YOLOv3/4/5/6/7/8/9/10/11, segmentazione/posa YOLO11, OBB/World/segmentazione YOLOv8, OCR, profondità e TinySAM in una matrice specifica per target, soprattutto per Hi3403 e Hi3591P. Non dimostra che ogni voce funzioni su tutti i SoC smart vision elencati sopra. Alcune voci sono elementi di roadmap, quindi esempi rilasciati e supporto pianificato devono restare distinti; il repository dichiara inoltre che i modelli ModelZoo forniti sono solo per uso non commerciale. La terminologia ATC/.om condivisa non dimostra la compatibilità di artefatti o runtime con la linea Ascend basata su CANN.

Aziende di acceleratori emergenti e specializzati

MemryX

I moduli MemryX MX3 usano un'architettura dataflow e possono combinare più chip. Il Neural Compiler accetta modelli ONNX, TensorFlow Lite, Keras e TensorFlow e genera un pacchetto DFP utilizzato dal runtime dell'acceleratore. Le API runtime supportano pipeline multi-modello e streaming.

La documentazione e gli esempi MemryX includono preelaborazione e postelaborazione YOLO ottimizzate per rilevamento, segmentazione e posa. Le note di rilascio SDK citano esplicitamente il supporto YOLOv10, YOLO11 e YOLO26. I materiali pubblici sono tecnicamente utili, ma manca una tabella unica di modelli/accuratezza/dispositivi come quella di Axelera.

Kneron

I prodotti KL520/KL530/KL630/KL720/KL730 di Kneron coprono piccoli acceleratori USB ed embedded. Kneron PLUS gestisce il runtime applicativo, mentre l'attuale Model Toolchain 0.33.1 documenta conversione, quantizzazione, valutazione, simulazione e compilazione .nef per questi target. KL830 appare in alcune API runtime PLUS, ma non nell'attuale elenco dei target del compilatore; non attribuire una capacità generica di compilazione .nef a KL830 senza conferma del fornitore.

L'esempio YOLO ufficiale mostra il procedimento con Tiny-YOLOv3; altri materiali Kneron trattano training e deployment YOLOv5. Le prove sono credibili, ma più limitate delle ampie matrici YOLO moderne di Hailo, Axelera, Rockchip o DEEPX.

SiMa.ai

La piattaforma MLSoC di SiMa.ai e il sistema Modalix da 50 TOPS in produzione usano l'ambiente software Palette. ModelSDK, il compilatore MLA e ModelExecutor coprono importazione, quantizzazione, compilazione, profiling ed esecuzione. A seconda del carico e del prodotto, gli strumenti supportano flussi orientati a INT8, INT16 e BF16.

Le note di rilascio dell'azienda citano pipeline convalidate YOLOv7, YOLOv8 per rilevamento/posa/segmentazione, YOLOX e segmentazione YOLOX, DETR, Mask R-CNN ed EfficientDet. Non va nascosto un limite attuale: le note Palette SDK 2.1 dichiarano che QAT non funziona per una regressione di quantizzazione Python/PT2E. Il workaround documentato è creare l'ONNX annotato in SDK 2.0 e compilarlo con 2.1. Accesso e acquisto restano orientati alle aziende.

Anche il confine del deployment è documentato: il flusso di compilazione ModelSDK produce un .tar.gz compilato e può generare un ELF eseguibile, mentre MPK Tool impacchetta un .mpk distribuibile. Questi output restano vincolati al target MLSoC/Modalix e alla release Palette.

EdgeCortix

SAKURA-II è un acceleratore dichiarato da 60 TOPS per visione e AI generativa, compilato con il framework software MERA. EdgeCortix fornisce inoltre la tecnologia MERA al più recente flusso RUHMI di Renesas.

I materiali prodotto SAKURA-II definiscono hardware e compilatore; l'hardware M.2/PCIe è proposto tramite richiesta di prova o ordine. Non è stata trovata una matrice YOLO pubblica, attuale e abbastanza precisa. L'assenza è un'informazione utile per l'acquisto: prima di scegliere l'hardware occorre chiedere la convalida del modello.

BrainChip

Akida di BrainChip è un processore neuromorfico a eventi, non una NPU convenzionale a tensori densi. L'ambiente MetaTF comprende pacchetti Python installabili per creare modelli, quantizzarli a bassa precisione, convertirli, simularli ed eseguirli sull'hardware. BrainChip vende ora il coprocessore AKD1500 in formato M.2, disponibile, oltre all'hardware AKD1000 legacy e all'IP Akida 2.

L'attuale scheda modello Akida 2 cita un rilevatore YOLOv2 AkidaNet0.5, CenterNet, AkidaUNet e reti di riconoscimento facciale. Altri materiali trattano FOMO e carichi basati su eventi. Akida supporta pesi e attivazioni a precisione molto bassa, ma il deployment riuscito può richiedere una conversione consapevole dell'architettura, non un target ONNX INT8 generico. Un risultato del model zoo AKD1000 o Akida 2 non va attribuito ad AKD1500 finché un rapporto esplicito di mappatura/adattamento non lo convalida.

Blaize

Blaize vende prodotti Pathfinder e Xplorer basati su P1600; il percorso software usa Picasso SDK, NetDeploy e AI Studio. Le pagine prodotto indicano chiaramente visione e edge AI come mercati di riferimento, ma non è disponibile una matrice pubblica attuale di compatibilità per singolo modello.

Questa guida classifica quindi Blaize come commerciale e ad accesso limitato, senza colmare la lacuna con affermazioni della community. Prima di procedere dovrebbe essere richiesto un rapporto di compilazione e accuratezza del fornitore per il modello previsto.

TinyML e visione endpoint

Arm Ethos-U e Alif

Arm concede in licenza l'IP NPU Ethos-U55, U65 e U85 alle aziende che producono chip. Il compilatore Vela prende grafi LiteRT/TFLite quantizzati e riscrive i sottografi supportati come operazioni personalizzate Ethos-U. Le operazioni non supportate possono restare sulla CPU, quindi "l'applicazione funziona" e "l'intera rete gira sulla NPU" sono affermazioni diverse.

Implementazioni reali includono Ethos-U55 in Alif Ensemble E7, Ethos-U65 in NXP i.MX 93 ed Ethos-U85 nei sistemi più recenti. L'E7 AI/ML AppKit di Alif documenta due acceleratori ML e mostra il percorso TFLite-to-Vela su E7; Ensemble E8 combina un Ethos-U85 con due NPU Ethos-U55. Alif pubblica anche un benchmark INT8 di famiglia per il rilevamento di volti YOLO-Fastest a 192 per 192 su Cortex-M55 più Ethos-U55, ma non un'ampia matrice moderna YOLO specifica per target. Questi sistemi con poca memoria sono adatti a piccole reti di classificazione e rilevamento, non a rilevatori arbitrari a 640 pixel solo perché esprimibili in TFLite.

Infineon PSOC Edge, Himax WiseEye2 e Analog Devices MAX7800x

Le famiglie PSOC Edge E83 ed E84 di Infineon abbinano Cortex-M55 a Ethos-U55 e aggiungono un blocco NNLite separato sul lato M33 a basso consumo. Il manuale dell'architettura E84 documenta pesi a 8 bit, attivazioni a 8 o 16 bit e un flusso Vela in cui gli operatori supportati diventano un flusso di comandi NPU e il lavoro non supportato resta sulla CPU. Il DEEPCRAFT Model Converter accetta percorsi TFLite, Keras e PyTorch, mentre i materiali architetturali citano MobileNetV1/V2 come kernel rappresentativi, non come benchmark dei target. L'E84 AI Kit include una videocamera e usa ModusToolbox, ma i materiali pubblici non offrono ancora una matrice di compatibilità YOLO per modelli specifici. È una vera piattaforma di visione programmabile con evidenze sui modelli in crescita, non un target generico di rilevamento già convalidato.

Anche HX6538 WiseEye2 di Himax combina Cortex-M55 ed Ethos-U55 per la visione sempre attiva. La documentazione software pubblica è particolarmente concreta per questa classe di consumi: gli esempi ufficiali Grove Vision AI Module V2 includono rilevamento oggetti YOLOv8n, posa e classificazione del genere, rilevamento YOLO11n, face mesh e PeopleNet. Il percorso unificato usa TFLite Micro e Vela, poi ripiega su CMSIS-NN e sui kernel di riferimento quando serve. Si tratta di modelli e risoluzioni volutamente ridotti, non di prove che un grafo YOLO convenzionale per server possa essere eseguito.

Analog Devices segue un percorso diverso con gli acceleratori CNN MAX78000/MAX78002. Lo strumento pubblico ai8x-synthesis quantizza la rete addestrata e genera codice C, pesi e configurazione dell'acceleratore specifici per il target, invece di un pacchetto runtime ONNX portabile. Le evidenze dirette includono identificazione facciale, rilevamento QR TinierSSD nello zoo modelli ADI e classificatori d'immagini. I dispositivi sono pertinenti alla visione endpoint, ma non è stata trovata una matrice ufficiale attuale per YOLO moderno.

GreenWaves GAP9

GAP9 combina calcolo RISC-V con il motore neurale NE16. NNTool importa e quantizza le reti, mentre AutoTiler e GAP SDK generano codice distribuibile. Il menu reti neurali GAP9 pubblico contiene applicazioni MobileNet, EfficientNet, ResNet, MobileNet SSD, rilevamento volti e riconoscimento. GreenWaves pubblica anche un progetto YOLOX di rilevamento persone con risultati di accuratezza e simulazione.

Sono evidenze TinyML insolitamente trasparenti, ma l'SDK completo è disponibile solo ai clienti qualificati e i modelli sono molto più piccoli delle varianti YOLO convenzionali a 640 x 640.

Lattice sensAI

Lattice sensAI è un'alternativa FPGA a una NPU fissa. sensAI Studio e Neural Network Compiler mappano un grafo supportato su IP acceleratore configurabile per dispositivi ECP5, iCE40 UltraPlus, CrossLink-NX, CertusPro-NX, Avant-E e Avant-X. L'output è vincolato all'FPGA scelto, alla modalità dell'acceleratore, al layout di memoria e al bitstream, non è un modello runtime portabile.

L'attuale manuale Neural Network Compiler include una tabella topologica particolarmente diretta. Elenca YOLOv1 per ECP5, YOLOv5 e YOLOv8 per le modalità optimized/advanced su CrossLink-NX e CertusPro-NX, e YOLO11 solo con IP Advanced. Elenca anche SSD, MobileNetV2-SSD, ResNet, ENet, SqueezeDet e altre reti di visione, mostrando le celle non supportate per famiglia FPGA. L'Advanced CNN Accelerator è IP commerciale per Avant-E/Avant-X/CertusPro-NX. Sono evidenze da tabella del compilatore, non una promessa che un bitstream supporti simultaneamente ogni topologia.

Microchip VectorBlox

Il VectorBlox SDK 3.1 pubblico di Microchip preelabora e compila reti TFLite INT8 quantizzate completamente per IP CoreVectorBlox configurabile negli FPGA PolarFire SoC. tflite_preprocess e vnnx_compile producono asset .vnnx, .hex e .ucomp; il repository include un simulatore e un driver C lato target. I grafi TensorFlow, ONNX e OpenVINO upstream devono comunque passare dal percorso documentato di preparazione TFLite/INT8.

L'attuale matrice dei tutorial include YOLOv5n, YOLOv8n per rilevamento, classificazione, OBB, posa e segmentazione, YOLOv9t, varianti YOLO sparse/compresse, MobileNet, EfficientNet-Lite0, ResNet18, MiDaS, FFNet e QuickSRNet. La guida C alla postelaborazione cita separatamente decoder YOLOv2/3/4/5 e Ultralytics per rilevamento, posa e OBB. SDK 3.1 supporta attualmente PolarFire SoC Video Kit ed esclude esplicitamente PolarFire Video Kit senza SoC, quindi le demo per schede più vecchie non vanno confuse con il contratto attuale.

L'SDK è scaricabile pubblicamente con una licenza specifica di Microchip che limita software e derivati ai prodotti Microchip. Microchip offre licenze Libero Silver e CoreVectorBlox gratuite, ma su richiesta. Il deployment resta un contratto di sistema FPGA: configurazione dell'acceleratore, bitstream, firmware, dati di rete generati dall'SDK e layout di memoria devono corrispondere. Una compilazione VectorBlox riuscita non trasforma il modello in un binario copiabile su un progetto PolarFire qualsiasi.

Syntiant

NDP200 di Syntiant è destinato a inferenza sempre attiva per visione, audio e sensori, al di sotto dei consumi dei normali SoC Linux. La tabella hardware attuale indica NDP200 in produzione di massa e NDP250 in campionatura. La scheda prodotto NDP200 documenta supporto per reti CNN, RNN e fully connected sotto 1 mW; l'annuncio NDP250 descrive invece riconoscimento immagini sempre attivo sotto 30 mW. Il dato "inferiore al milliwatt" non va generalizzato a entrambi i componenti.

I materiali pubblici non dimostrano ampia compatibilità YOLO, quindi il prodotto va valutato per piccoli classificatori e rilevatori sempre attivi tramite una valutazione dei modelli supportata dal fornitore, non presumendo un'esportazione ONNX generica.

Google Coral: due generazioni non correlate

I prodotti Edge TPU legacy usano Edge TPU Compiler, libedgetpu e PyCoral con modelli TFLite interamente INT8. I repository principali Edge TPU e PyCoral sono archiviati. È un rischio concreto per la manutenzione, ma non un annuncio formale di fine vita dell'hardware.

Google mantiene anche una Coral NPU distinta, attiva e open source: IP acceleratore RISC-V da integrare in SoC a basso consumo. Il progetto pubblico offre al momento RTL, simulazione hardware, toolchain ed esempi ELF. Non è un successore USB/M.2 intercambiabile di Edge TPU e non pubblica una matrice attuale di deployment YOLO.

Insidie tra GPU, NPU client e calcolo adattivo

NVIDIA, AMD, Intel e Apple compaiono spesso nelle ricerche sulle NPU, ma non offrono una sola categoria di acceleratore intercambiabile.

NVIDIA Jetson: Jetson Orin combina una GPU CUDA con core DLA dedicati. TensorRT può costruire un engine serializzato per DLA, ma i layer non supportati girano sulla GPU solo se il fallback GPU è abilitato esplicitamente. L'attuale tabella DeepStream YOLO copre YOLOv4/v7/v8/v9/11, ma la maggior parte delle voci ha come target la GPU; l'unica voce ONNX DLA esplicita è YOLOv8s INT8. Le restrizioni DLA di NVIDIA spiegano i limiti degli operatori. Thor è un altro caso: la guida alla migrazione DriveOS di NVIDIA dichiara che Thor ha rimosso i core DLA per favorire la flessibilità di scheduling GPU. "Funziona su Jetson" quindi non identifica l'acceleratore.

AMD Vitis AI: la vecchia generazione Kria/DPU compilava grafi .xmodel eseguiti tramite VART. L'attuale Vitis AI 6.2 è GA per due percorsi distinti Versal AI Edge: Gen1 su VEK280/VE2802 usa ONNX, AMD Quark e un flusso snapshot/sottografo legato al target; Gen2 su VEK385 ha un proprio contratto di compilazione e runtime. Gen1 pubblica esempi YOLOv5, YOLOv7, YOLOv8 e YOLOX. Ryzen AI è un quarto stack NPU client separato. Non trasferire artefatti o convalide tra DPU legacy, Versal Gen1, Versal Gen2 e Ryzen AI solo perché condividono il nome Vitis o AMD.

Intel OpenVINO: OpenVINO può usare CPU, GPU e NPU Core Ultra tramite un'unica API. La documentazione del plug-in NPU Intel identifica le generazioni NPU supportate, mentre la matrice dei modelli verificati espone colonne specifiche per dispositivo. Un notebook YOLO dimostra una ricetta applicativa, non la convalida NPU, a meno che non lo indichi la matrice. Operazioni, forme, precisione supportate e driver NPU installato determinano ancora se il grafo completo viene eseguito lì. OpenVINO IR (.xml più .bin) è un IR sorgente riutilizzabile; la cache di un modello compilato dipende dal dispositivo e dal software.

Apple Core ML: coremltools converte i modelli in .mlpackage, che Xcode compila in .mlmodelc. Core ML può pianificare il lavoro su CPU, GPU e Apple Neural Engine, ma astrae intenzionalmente la ripartizione precisa. Apple è quindi un'eccellente piattaforma di deployment e una cattiva base per affermare che "l'intero grafo YOLO è stato eseguito sulla NPU" senza prove di profiling.

Le aziende di IP NPU dietro ai produttori di chip

Alcune aziende non vendono schede o acceleratori confezionati. Concedono in licenza progetti NPU ai produttori di SoC. Sono rilevanti perché la stessa architettura di base può apparire sotto diversi marchi di chip, ma l'SDK e l'artefatto finali possono comunque essere personalizzati dal licenziatario.

Imagination mostra perché le indicazioni su accesso e ciclo di vita devono affiancare i nomi delle architetture. Il programma Open Access offre tre configurazioni Series3NX verificate sul silicio senza tariffa iniziale per la licenza IP, ma solo dopo la valutazione dell'azienda, con supporto/manutenzione a pagamento e royalty sulla produzione. Il Neural Compute SDK fornisce strumenti per compilazione, ottimizzazione, quantizzazione e runtime; una collaborazione ufficiale con Baidu PaddlePaddle cita rilevamento PP-YOLOE, classificazione EfficientNet e segmentazione HRNet. Questi esempi non convalidano ogni configurazione Series3NX o Series4; inoltre le attuali pagine prodotto Series4 indicano i prodotti come non disponibili, quindi Series4 va considerata storica finché il reparto vendite non conferma il contrario.

Questo livello spiega somiglianze apparenti tra famiglie. Non rende portabili gli artefatti. Due SoC con IP Vivante o Ethos correlato possono avere mappe di memoria, driver, versioni del compilatore, set di operatori e runtime differenti.

Cosa distribuisci davvero: tabella del vincolo sugli artefatti

È l'ultimo file della pipeline del compilatore a segnare la fine dell'apparente portabilità ONNX. Nomi ed estensioni cambiano, ma la regola pratica è stabile: conserva il modello originale e i dati di calibrazione perché l'artefatto nativo di solito non si può spostare su un'altra generazione NPU né ricompilare in modo affidabile con un'altra release dell'SDK.

Questa tabella non è solo un promemoria delle estensioni. Versione del compilatore, identificativo target, driver, firmware e BSP fanno parte dell'identità riproducibile del modello. Un futuro esportatore LibreYOLO dovrebbe registrarli in un manifest leggibile dalle macchine accanto a ogni artefatto.

Accesso agli strumenti e segnali sul ciclo di vita

Disponibilità dell'hardware e accesso al compilatore sono due cose indipendenti. Una scheda può essere facile da acquistare mentre il compilatore attuale richiede un accordo cliente; un SDK pubblico può supportare silicio difficile da reperire. Quelli seguenti sono segnali concreti di prima parte, non una classifica universale della longevità.

Perché i TOPS non bastano per scegliere

I TOPS di picco possono essere utili all'interno di un singolo fornitore e architettura, ma i confronti tra fornitori di solito non sono validi a meno che corrispondano tutti questi elementi:

• Precisione numerica, inclusi INT8, INT4, FP16 o modalità miste
• Se una moltiplicazione-accumulazione conta come una o due operazioni
• Calcolo denso o sparso strutturato
• Risoluzione d'ingresso, dimensione del batch e grafo del modello
• Accuratezza dopo la quantizzazione
• Latenza solo NPU o pipeline applicativa completa
• Trasferimenti di memoria e fallback sull'host
• Stato termico e funzionamento sostenuto, non a raffica

Un rilevatore fa parte di una pipeline: acquisizione immagine, resize/letterbox, normalizzazione, trasferimento al dispositivo, inferenza neurale, decodifica, NMS, conversione delle coordinate e logica applicativa. I fornitori spesso pubblicano solo la fase centrale di inferenza neurale. MLPerf Inference Edge è utile perché definisce scenari, requisiti di qualità e regole per misurare il sistema completo invece di confrontare numeri di marketing isolati.

Per i deployment YOLO, una scheda benchmark minima credibile registra:

exact checkpoint + checksum
source and compiled model format
compiler, runtime, driver and firmware versions
target board and clock/power mode
input resolution and batch
precision and calibration dataset
accuracy before and after compilation
warmup and sample count
preprocess, inference and postprocess latency
power measurement boundary

Senza questi campi, due valori FPS misurano spesso cose diverse.

Come scegliere una NPU per computer vision

Scegli in questo ordine, non in base al numero più grande stampato sulla pagina prodotto.

1. Verifica la compatibilità del grafo. Compila il modello esportato esatto, non un checkpoint dello zoo dal nome simile.
2. Misura l'accuratezza. Convalida l'artefatto compilato sul dataset reale del task, dopo calibrazione e quantizzazione.
3. Misura l'intero flusso. Includi conversione dell'input, trasferimenti, decodifica e NMS.
4. Verifica l'accesso software. Scopri se il compilatore è pubblico, disponibile previa registrazione o solo dopo un accordo commerciale.
5. Fissa la matrice delle versioni. Registra compilatore, runtime, driver, firmware e identificativi dei target.
6. Verifica i sistemi operativi effettivamente supportati. Android, Debian, Yocto, Buildroot, RTOS e Windows non sono intercambiabili.
7. Controlla fornitura e ciclo di vita. Un chip eccellente dal punto di vista tecnico è una scelta di produzione debole se moduli, driver o supporto a lungo termine sono incerti.
8. Poi confronta costo, consumi e prestazioni. Queste misure hanno senso solo dopo che lo stesso modello funziona correttamente su entrambi i target.

Punti di partenza pratici per caso d'uso

Questa tabella è una selezione per la ricerca, non una classifica delle prestazioni. Acquisti, disponibilità regionale e modello esatto possono cambiare l'ordine.

Cosa significa per LibreYOLO

Un'architettura scalabile non consiste in decine di esportatori scollegati. Serve un unico contratto rigoroso di interscambio più piccoli adapter per compilatori e runtime dei fornitori:

LibreYOLO model
    -> deterministic static ONNX
    -> VendorCompiler.compile(model, target, calibration, precision)
    -> native artifact + manifest
    -> VendorRuntime.load() / infer()
    -> shared task-specific decode and Results objects

Ogni artefatto nativo dovrebbe avere un manifest accessorio con:

• Fornitore, target chip e target scheda
• Versioni di compilatore, runtime, driver e firmware
• Checksum del checkpoint sorgente e di ONNX
• Nomi input, forme, layout, spazio colore, normalizzazione e dtype
• Precisione di quantizzazione, scale se esposte e hash dei dati di calibrazione
• Nomi e forme dei tensori di output e significato semantico
• Task di rilevamento, nomi classi e indicazione se decode/NMS avviene sul chip o sull'host
• Parità numerica e accuratezza sul task registrate

LibreYOLO fornisce già esportazione ONNX portabile, strumenti di quantizzazione, un'esportazione RKNN diretta ma volutamente limitata e un flusso Hailo onesto con compilatore esterno. Secondo i criteri usati in questa guida, Amlogic ADLA è un forte candidato alla prossima integrazione: il toolkit è pubblico, la copertura dei modelli coincide ampiamente con LibreYOLO e il vecchio percorso A311D può restare chiaramente separato.

La priorità dopo Amlogic dovrebbe dipendere dall'hardware degli utenti e dalla possibilità di convalidare l'accuratezza, non solo dalla disponibilità del compilatore. DEEPX, Sony IMX500, D-Robotics, AXERA, SOPHGO e Qualcomm sono interessanti sul piano tecnico; TI, NXP, ST e Renesas diventano particolarmente preziose quando i partner industriali possono fornire schede e accesso CI a lungo termine.

Da tenere d'occhio: silicio reale senza contratto d'integrazione pubblico

Escludere del tutto un'azienda può rendere fuorviante una mappa di mercato. Includerla come "supportata" può essere peggio. Questi fornitori vendono, campionano o hanno annunciato silicio pertinente, ma le evidenze pubbliche non dimostrano ancora un percorso attuale e riproducibile con compilatore, artefatto e modello specifico, adatto a un backend LibreYOLO.

Questa lista da monitorare si basa intenzionalmente sulle evidenze. Un fornitore può entrare nelle tabelle delle piattaforme distribuibili pubblicando una toolchain o un percorso di valutazione attuale, un contratto dell'artefatto specifico per target e almeno un modello nominato con una ricetta end-to-end.

Cosa non è stato affermato

Questo articolo non sostiene che ogni modello citato funzioni a partire da ogni repository upstream. I modelli dei vendor zoo sono spesso modificati, suddivisi in corrispondenza di nodi di output diversi o abbinati a postelaborazione personalizzata.

Non trasforma neppure queste affermazioni in dichiarazioni di supporto:

• Un compilatore importa ONNX.
• Un chip dichiara un driver Android NNAPI.
• Un distributore afferma che la scheda è "compatibile con YOLO".
• Un repository della community esegue un fork di un modello.
• Un modello si compila senza errori.
• Un fornitore dichiara FPS solo NPU senza un risultato di accuratezza.

Gli acceleratori Tensor per telefoni Google e numerosi ASIC personalizzati riservati agli OEM sono reali, ma Google non espone Tensor come target di compilazione self-service generico paragonabile alle piattaforme sopra. L'esistenza di un'azienda, uno schema a blocchi NPU o l'accelerazione Android non bastano per inventare una dichiarazione d'integrazione LibreYOLO.

Allo stesso modo, gli acceleratori cloud come Google TPU, AWS Inferentia/Trainium, Microsoft Maia e le schede AI solo per data center sono fuori ambito. Questa guida riguarda hardware che uno sviluppatore di computer vision può realisticamente distribuire all'edge.

La licenza del modello è un livello separato. La ricetta di conversione YOLO pubblicata da un produttore di chip non concede i diritti per usare o ridistribuire pesi upstream, codice di training o derivati compilati. Per il prodotto previsto occorre verificare separatamente supporto hardware, licenza SDK e licenza del modello.

Metodologia di ricerca e correzioni

Per ogni azienda la ricerca ha esaminato quattro fonti primarie:

1. Una pagina prodotto o scheda tecnica attuale che identifichi il silicio.
2. Documentazione di compilatore e runtime che spieghi il vero percorso di deployment.
3. Model zoo, tabella di compatibilità o tutorial end-to-end che citi modelli di visione.
4. Un segnale relativo a ciclo di vita o accesso che mostri se gli sviluppatori possono ottenere gli strumenti.

Le organizzazioni GitHub di prima parte contano come fonti del fornitore. La documentazione del produttore della scheda è indicata come evidenza dell'ecosistema quando l'azienda che produce il chip non pubblica gli stessi materiali. Le dichiarazioni prestazionali di terze parti sono state escluse dalle tabelle comparative.

La bozza completa è stata poi riesaminata in passate separate per gruppi di fornitori e tabelle incrociate. I controlli hanno verificato nuovamente ambito dei target, nomi degli artefatti, precisione, evidenze su modelli e postprocessori, stato annunciato o in distribuzione, etichette del ciclo di vita, denominatori dei benchmark e conteggi di tutte le entità. Quando due pagine di prima parte sono in conflitto, la guida mostra il conflitto invece di scegliere in silenzio il valore più comodo.

Questo mercato cambia rapidamente. Se lavori per una di queste aziende e un chip, SDK, elenco di modelli o stato d'accesso non è corretto, invia a LibreYOLO l'URL esatto della documentazione pubblica e la versione. Le correzioni supportate da evidenze primarie dovrebbero sostituire questo testo; le affermazioni di marketing non documentate no.

FAQ

Quante aziende producono NPU per l'edge AI?

Non esiste un totale universale di aziende, perché si sovrappongono fornitori di prodotti, licenziatari di IP, sensori intelligenti, GPU e ASIC automobilistici proprietari. Questa guida non esaustiva segue 69 aziende ed ecosistemi di piattaforma con chip edge AI pertinenti, piattaforme di accelerazione, IP NPU concessibile in licenza o silicio da tenere d'occhio con basi credibili, aggiornati ad agosto 2026.

Che cos'è una NPU?

Una neural processing unit è hardware specializzato per operazioni di rete neurale come convoluzioni e moltiplicazioni di matrici. I nomi usati dai fornitori includono NPU, AIPU, BPU, KPU, DLA, HTP, TPU e MLA; in genere i modelli compilati non sono portabili tra aziende.

Quali aziende con NPU supportano ufficialmente i modelli YOLO?

Amlogic, Hailo, Axelera AI, Rockchip, Qualcomm, MediaTek, DEEPX, D-Robotics, AXERA, SOPHGO, Huawei, Cambricon, Sony IMX500 tramite il repository ufficiale AI Camera di Raspberry Pi, STMicroelectronics, Renesas, Lattice, Himax, Microchip e diverse altre aziende pubblicano voci nei model zoo, tutorial o risultati convalidati per almeno una generazione di YOLO. La generazione esatta, il task, il chip di destinazione e la versione dell'SDK restano determinanti.

Qualsiasi modello ONNX può essere eseguito su qualsiasi NPU?

No. ONNX è un formato di interscambio, non una garanzia di compatibilità hardware. Il compilatore NPU deve supportare ogni operatore, forma dei tensori e tipo di dato del grafo. Forme statiche, tagli del grafo, operazioni personalizzate e fallback sulla CPU sono comuni.

Qual è la NPU migliore per YOLO?

Non esiste una vincitrice universale. Hailo, Rockchip, Axelera AI, DEEPX e Amlogic offrono un supporto YOLO documentato consistente, mentre Qualcomm raggiunge un numero eccezionale di dispositivi. Scegli in base all'accuratezza dopo la quantizzazione, alla latenza dell'intera pipeline, ai consumi sostenuti, al prezzo, alla disponibilità, all'accesso all'SDK e al supporto del sistema operativo.

Perché non si possono confrontare direttamente i valori TOPS delle NPU?

I fornitori possono conteggiare precisioni diverse, operazioni sparse, moltiplicazioni-accumulazioni e ipotesi diverse sull'utilizzo di picco. I TOPS non includono traffico di memoria, operatori non supportati, preelaborazione, postelaborazione e overhead dell'host. Confronta lo stesso modello, la stessa precisione, risoluzione, accuratezza e pipeline completa.

Che cos'è la calibrazione di una NPU?

La calibrazione esegue sul modello immagini rappresentative, di solito senza etichette, dell'ambiente di deployment, così che il compilatore possa stimare gli intervalli delle attivazioni per INT8 o un altro formato a bassa precisione. Anche immagini casuali o non rappresentative possono produrre un artefatto compilato, ma compromettere l'accuratezza del task.

LibreYOLO supporta le NPU edge?

LibreYOLO esporta ONNX e diversi formati per runtime, dispone di un percorso diretto verso il compilatore RKNN per alcuni modelli Rockchip e documenta il flusso esterno di compilazione Hailo. Per ogni altro artefatto nativo del fornitore serve ancora il relativo SDK; va considerato un candidato all'integrazione finché non viene compilato, convalidato ed eseguito su hardware.