69 Edge-AI-NPU-Unternehmen: Chips, SDKs und YOLO für Computer Vision (2026)

Es gibt keinen einheitlichen NPU-Markt. Dieser nicht abschließende Leitfaden erfasst 69 Unternehmen und Plattform-Ökosysteme: 51 Anbieter mit auslieferbaren Chips oder Plattformen, neun NPU-IP-Anbieter und neun klar gekennzeichnete Unternehmen auf der Beobachtungsliste. Sie decken mehrere inkompatible Beschleunigerklassen und fast ebenso viele Compiler-Stacks ab. Die meisten versprechen denselben Ablauf: Modell exportieren, quantisieren, kompilieren, ein proprietäres Artefakt auf ein Board kopieren und eine Hersteller-Runtime aufrufen. Die Details entscheiden, ob das einen Nachmittag oder ein Quartal Entwicklungsarbeit kostet.

Dieser Leitfaden ordnet die Unternehmen ein, die 2026 glaubwürdige Computer-Vision-Hardware anbieten. Er erfasst relevante Chips, SDK- und Compilernamen, Deployment-Artefakte, öffentlichen Zugangsstatus und die vom Anbieter tatsächlich dokumentierten Modelle. Besonderes Augenmerk gilt außerdem Amlogic, dessen neuerer ADLA-Stack sich wesentlich vom älteren A311D-NPU-Ökosystem unterscheidet.

Umfang der Recherche: Der Quellenstand ist August 15, 2026. Aussagen zu namentlich genannten Modellen beruhen, sofern nicht anders gekennzeichnet, auf Produktseiten, Dokumentation, Model Zoos, Repositories oder Tutorials der Hersteller. Beworbene TOPS-Werte stammen von den Herstellern und sind keine unabhängig vergleichbaren Benchmark-Ergebnisse. Dies ist ein Entwicklerleitfaden, keine Anlageberatung und kein bezahltes Ranking.

Schnellnavigation: Unternehmenstabellen | Amlogic im Detail | Anbieterprofile | Tabelle kompilierter Artefakte | Zugang und Lebenszyklus | LibreYOLO-Roadmap

Wichtigste Erkenntnis

Die Hardware ist fragmentiert, das Deployment-Muster dagegen bemerkenswert einheitlich:

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 unterstützt ausdrücklich Runtimes, Codegeneratoren und Hardwareimplementierungen, doch eine ONNX-Datei ist nur die Übergabe. Daraus folgt nicht, dass sich jeder ONNX-Operator auf jeden Beschleuniger abbilden lässt. Statische Eingabeformen, Einschränkungen bei unterstützten Operatoren, Quantisierungsregeln und Host-Fallback bestimmen, was tatsächlich auf der NPU läuft.

Der Software-Stack gehört daher zum Chip. Eine nominell schnelle NPU mit einem eingeschränkten oder fragilen Compiler kann ein schlechteres Deployment-Ziel sein als ein kleineres Gerät mit öffentlicher Toolchain, Model Zoo, Simulator und stabiler Runtime.

Was „unterstützt“ in diesem Leitfaden bedeutet

In Herstellertexten wird der Begriff Unterstützung sehr großzügig verwendet. Dieser Artikel unterscheidet vier Evidenzstufen:

Diese Unterscheidung ist wichtig. „Importiert ONNX“ ist nicht gleichbedeutend mit „unterstützt YOLO11-Segmentierung“. Ein Modell kann eingelesen werden, dann aber auf eine CPU zurückfallen, mit falschen Ausgabewerten kompiliert werden, den Beschleunigerspeicher überlasten oder bei der Quantisierung Accuracy verlieren.

NPU-Unternehmen und Plattformen im Überblick

Die Tabellen führen bewusst SoCs, diskrete Beschleuniger, intelligente Sensoren und angrenzende GPU-/FPGA-Ziele gemeinsam auf. Sie konkurrieren um dieselbe Deployment-Entscheidung, auch wenn Hersteller Bezeichnungen wie NPU, AIPU, BPU, KPU, DLA, HTP, TPU oder MLA verwenden.

Eingebettete SoCs, intelligente Sensoren und Industrieprozessoren

Dedizierte Edge-Beschleuniger und Module

Angrenzende Plattformen, die Entwickler mit NPUs vergleichen

Amlogic: zwei NPU-Generationen, nicht eine

Amlogic verdient eine genauere Erklärung, weil Webquellen häufig inkompatible Produkte zusammenfassen. Das Unternehmen hat einen älteren Pfad auf VeriSilicon-Basis und einen neueren proprietären ADLA-Pfad. Sie verwenden weder denselben Compiler noch dasselbe Artefakt oder dieselbe Runtime.

Das A311D-Datenblatt weist die ursprüngliche 5-TOPS-INT8-NPU aus. Die ältere Khadas-VIM3-Anwendungsseite und der NPU-Überblick dokumentieren DenseNet CTC, MTCNN, RetinaFace, YOLOFace, YOLOv2, YOLOv3, YOLOv3-tiny, YOLOv4, YOLOv7-tiny und YOLOv8n. Der Überblick dokumentiert zusätzlich YOLOv8n-pose und kennzeichnet FaceNet als veraltet. Diese Beispiele sind echt, belegen aber das alte Acuity-.nb-Ökosystem und nicht die aktuellen ADLA-Chips. A311D ist nicht A311D2, und C305X ist nicht C305X2.

Es gibt noch eine zweite Hardware-Falle. Der Revisionsleitfaden für Khadas VIM4 besagt, dass das ursprüngliche Board V12/A311D2 Revision B keine NPU hat. Die beworbene NPU mit 3.2 TOPS gibt es erst auf V13A und neueren Boards mit Bauteil A311D2-N0D Revision C. Der Produktname allein genügt nicht, um ein Testgerät auszuwählen.

Der aktuelle AMLNN- und ADLA-Stack

Das aktuelle AMLNN Toolkit deckt Modellkonvertierung, Quantisierung, Kompilierung, Inferenz und Profiling ab. Sein festgeschriebener Nutzerleitfaden von May 2026 dokumentiert Importe für ONNX, Fließkomma- oder quantisiertes TFLite, TorchScript .pt und PyTorch-2-ExportedProgram/PT2. Die detaillierte Anleitung führt TensorFlow-, Paddle- und Keras-Pfade als geplant auf, obwohl die Repository-Übersicht eine breitere Formulierung verwendet. Der Compiler erzeugt .adla. Python-Deployment verwendet AMLNN oder amlnn_edge_toolkit_lite; natives C/C++ bindet libnnsdk.so über nnsdk2.h ein. Die Entwicklung auf dem Host kann ADB mit nnserver nutzen. Die Runtime zielt außerdem auf Android, Buildroot, Yocto und ausgewählte Debian-/Armbian-Umgebungen.

Die veröffentlichten Plattformkennungen des Toolkits sind derzeit:

Das Zielfeld ist nicht kosmetisch. Amlogic verlangt, dass .adla, nnsdk2.h, libnnsdk.so, BSP und Compiler-/Runtime-Generation zusammenpassen. Der festgeschriebene Quick Start verlangt ADLA Driver 2.0.2 oder neuer, NNSDK 3.0.0 oder neuer und NNSDK2 1.0.0 oder neuer. Der Android-Deployment-Leitfaden macht die Abhängigkeiten zwischen Bibliothek, Header, Driver und BSP konkret. Behandle .adla als ABI-gebundenes Build-Artefakt, nicht als portables Modell.

Die Quantisierung hängt ebenfalls von der NPU-Generation ab. Für ADLA2-Ziele 001 bis 006 ist die Kompilierung mit W8A8 und W8A16 dokumentiert. ADLA3-Ziele 007 und 008 ergänzen Kombinationen aus W4A8, W4A16, W8A8, W8A16 und W16A16 sowie native INT4-, FP16- und BF16-Unterstützung im Operatorleitfaden. Amlogic empfiehlt 200 bis 500 repräsentative Kalibrierungsbeispiele. Die Option für Zufallsdaten ist ausdrücklich für Leistungstests vorgesehen, nicht für eine accuracy-erhaltende Quantisierung.

Dokumentierte Modellabdeckung von Amlogic

Der festgeschriebene Amlogic Model Playground ist ein deutlich besserer Beleg als eine allgemeine Behauptung zur ONNX-Unterstützung. Seine veröffentlichte Support-/Beispielmatrix nennt A311D2, S905X5, A311Y3, C305X2 und A123X. Die Compilerunterstützung der anderen Ziel-IDs belegt nicht, dass die gesamte Modellliste auf ihnen validiert wurde.

Dasselbe Repository veröffentlicht folgende W8A8-Laufzeitwerte. Es handelt sich um Herstellerwerte für das neuronale Netz auf der NPU, nicht um vollständige Kamerapipelines.

Die Einschränkungen sind hier besonders wichtig. Amlogics Operatorleitfaden führt NMS sowohl auf ADLA2 als auch ADLA3 als Software aus. Laut README sind dies native NPU-Modelllaufzeitwerte ohne Vor- und Nachverarbeitung. Ob jeder Speichertransfer enthalten ist, wird nicht offengelegt. Für die YOLO-Accuracy-Zeilen wurden COCO-Teilmengen mit 300 Bildern statt des vollständigen Validierungssatzes verwendet. Die Klassifikationszeilen verwenden ImageNet val1000. Die Tabellen nennen außerdem für YOLOv8n auf A311Y3 eine andere Latenz als die FPS-Tabelle, ohne die Bedingungen abzugleichen. Takt, Leistungsmodus, Kühlung, thermischer Dauerzustand, genaue SDK-/BSP-Version und Testdauer sind nicht angegeben. Nutze die Werte, um einen Hersteller-Stack einzuordnen, nicht um ihn mit anderen zu vergleichen.

Warum Amlogic strategisch interessant ist

Amlogic vereint vier ungewöhnliche Eigenschaften: eine große Verbreitung eingebetteter SoCs, einen neu öffentlich verfügbaren Compiler-Stack, eine aktuelle Modellmatrix mit großer Überschneidung zu den Aufgaben von LibreYOLO und eine bislang geringe erstklassige Integration in verbreitete Trainingsbibliotheken. Die aktuellen Repositories sind noch jung: Sie wurden Ende 2025 und Anfang 2026 öffentlich, umfangreiche Handbücher stammen von May through July 2026. Daraus ergeben sich sowohl eine echte Chance für frühe Integration als auch ein Risiko durch instabile APIs.

Eine saubere Integration sollte den deterministischen ONNX-Export von LibreYOLO als Compiler-Eingabe verwenden, repräsentative Kalibrierungsbilder für Builds mit niedriger Präzision verlangen, .adla samt Metadatenmanifest erstellen und über einen NNSDK2-Adapter laden. Für das ältere A311D sollte ein klar unterscheidbares .nb-Ziel verwendet werden, da eine gemeinsame Backend-Bezeichnung für .nb und .adla stille Kompatibilitätsfehler verursachen würde. Die obersten Lizenzen der Amlogic-Repositories sind Apache-2.0. Die Weiterverteilungsrechte für enthaltene Wheels, Shared Libraries, nnserver und Android-AAR-Binärdateien sollten jedoch direkt bestätigt werden, bevor LibreYOLO sie spiegelt.

Die stärksten öffentlichen Deployment-Ökosysteme

Die folgenden Unternehmen bieten derzeit die klarste Kombination aus erhältlicher Hardware, öffentlichen technischen Unterlagen und Evidenz für benannte Modelle. Das macht sie nicht grundsätzlich schneller. Ihre Kompatibilitätsaussagen lassen sich vor dem Hardwarekauf leichter bewerten.

Hailo

Hailo ist ein Referenzbeispiel für ein Ökosystem dedizierter Vision-Beschleuniger. Modelle werden in ein Hailo Archive eingelesen, optimiert und mit repräsentativen Bildern quantisiert. Anschließend kompiliert man sie in eine Datei im Hailo Executable Format (.hef). Anwendungen laden dieses HEF über HailoRT.

Der Hailo Model Zoo enthält Rezepte, vortrainierte Modelle, Nachverarbeitungskonfigurationen und Leistungsdaten für Erkennung, Segmentierung, Klassifikation, Pose und weitere Aufgaben. Die YOLO-Abdeckung umfasst YOLOv3/v4/v5/v6/v7/v8/v9/v10/11/12 und YOLO26 sowie YOLOX, DAMO-YOLO, SSD und EfficientDet. Die versionsgebundene Tabelle zur Objekterkennung auf Hailo-8 ist eine bessere Kompatibilitätsquelle als eine allgemeine Produktseite. Die Standalone-Anwendung dokumentiert ausführbare YOLO-Pipelines.

Es gibt eine wichtige Versionsgrenze. Hailo-8 und Hailo-8L verwenden die ältere Generation Model Zoo 2.x, Dataflow Compiler 3.x und HailoRT 4.x. Hailo-10 und Hailo-15 verwenden die aktuelle Generation 5.x. Rezepte, Parserverhalten und HEFs sind nicht austauschbar, nur weil auf jedem Gerät der Name Hailo steht.

Hailo-15 besitzt außerdem eine eigene Anwendungsschicht. Dort kommt das Vision Processor Software Package mit Hailo Media Library statt des TAPPAS-ähnlichen Host-Pfads von Hailo-8/10H zum Einsatz. Das öffentliche Referenz-Repository hailo-camera-apps wurde am May 3, 2026 archiviert. hailo-apps-core bleibt ein separates öffentliches Anwendungs-Framework. Die Archivierung eines Repositorys belegt nicht das Produktende. Für Hailo-15-Projekte sollte das aktuelle Anwendungspaket in der Developer Zone bestätigt werden.

LibreYOLOs Hailo-Deployment-Leitfaden endet bewusst bei der statischen ONNX-Übergabe, da der proprietäre Compiler nicht als Python-Abhängigkeit gebündelt werden kann. Das ist die ehrliche Grenze zwischen der Erstellung eines geeigneten Graphen und der Behauptung, ein HEF getestet zu haben.

Rockchip

Rockchip hat eine der größten Verbreitungen im Embedded-Linux-Hobbybereich und im kommerziellen Bereich, insbesondere über RK3588-, RK3576- und RK356x-Boards. Das öffentliche RKNN-Toolkit2 konvertiert und quantisiert Modelle auf einem x86-Linux-Host. RKNN Runtime oder Toolkit-Lite führt die resultierende .rknn-Datei auf dem Board aus.

Der RKNN Model Zoo ist ungewöhnlich genau bei Chips, Modellfamilien und Präzision. Die aktuelle Tabelle führt FP16- und INT8-Pfade für YOLOv5/6/7/8/10/11, YOLOX, PP-YOLOE, YOLO-World sowie YOLOv5-/v8-Segmentierungsvarianten auf. YOLOv8 OBB und YOLOv8 pose sind nur mit INT8 aufgeführt. Der Zoo deckt auch OCR, Gesichtsmodelle und andere Segmentierungsnetzwerke ab.

LibreYOLO bietet bereits einen vorsichtigen direkten RKNN-Exporter. Er validiert vier genau definierte Erkennungsvarianten auf RK3588, kann den Compilersimulator mit ONNX Runtime vergleichen und lehnt nicht validierte Familien ab, statt einen erfolgreichen Build mit korrekten Vorhersagen gleichzusetzen. Dieser enge Supportumfang ist ein sinnvolles Modell für jedes künftige NPU-Backend.

Axelera AI

Axelera AI, oft fälschlich „Accelera“ geschrieben, entwickelt die Metis AIPU und verkauft sie in M.2-, PCIe- und Mehrchip-Produkten. Metis ist die öffentlich bestellbare Familie; Europa und Titania sind angekündigte Produkte im Portfolio. Ihr Verfügbarkeitsstatus sollte nicht zu einem einheitlichen Produktstatus zusammengezogen werden. Der Voyager SDK ist öffentlich auf GitHub verfügbar und übernimmt Modellauswahl, Kompilierung, Quantisierung, Ausführung und Anwendungspipelines. Kundensupport ist weiterhin kontogeschützt.

Der öffentliche Voyager Model Zoo gehört zu den informativsten des Marktes. Er führt Modellvariante, Eingabegröße, Präzision, Accuracy und gemessene Leistung für YOLOv3, YOLOv5, YOLOv7, YOLOv8, YOLOv9, YOLOv10, YOLO11, YOLO26 n/s/m/l/x, YOLOX, YOLO-NAS, OBB, Pose und Segmentierung sowie viele Klassifikations- und dichte Vorhersagemodelle auf. Quantisierungsverlust und Accuracy neben der Geschwindigkeit zu veröffentlichen ist nützlicher, als nur einen Spitzen-TOPS-Wert anzugeben.

Die Artefaktbezeichnung änderte sich mit der API-Generation. Der Alpha-Kompilierungsablauf des Pipeline Builders erzeugt ein .axm-Modell und kann eine portable Pipeline als .axe verpacken. Die klassische Pipeline-Dokumentation beschreibt .axmodel samt Modellmetadaten und Manifest. Eine Integration muss die installierte Voyager-Generation erkennen, statt eine einzelne Dateiendung fest einzutragen.

Qualcomm

Qualcomm bietet eine enorme Deployment-Reichweite, doch unter „Qualcomm-NPU“ verbergen sich mehrere Schnittstellen. Entwickler begegnen Hexagon HTP über QAIRT/QNN, dem älteren SNPE-Ablauf, Qualcomm AI Hub-Kompilierungsdiensten, LiteRT oder dem QNN Execution Provider von ONNX Runtime, je nach Gerät und Produktklasse.

Das offizielle Repository Qualcomm AI Hub Models liefert starke Evidenz auf Modellebene. Es veröffentlicht optimierte Pakete für YOLOv3, YOLOv5, YOLOv6, YOLOv7, YOLOv8, YOLOv9, YOLOv10, YOLO11, YOLO26 für Erkennung/Segmentierung/Pose, YOLOX, YOLO-World, YOLOR, RF-DETR und zahlreiche Klassifikations-, Tiefen- und Posemodelle. AI Hub bietet auch gerätespezifisches Profiling. Das ist wichtig, weil ein für eine HTP-Generation kompiliertes Modell nicht automatisch auf eine andere übertragbar ist.

Der größte Integrationsaufwand entsteht durch die Breite der Matrix: Android gegenüber Embedded Linux, QCS-Bestellvarianten gegenüber Consumer-Snapdragon, HTP-Architektur, QNN-/QAIRT-Version und Quantisierungsschema sind entscheidend. Die aktuellen eigenen Seiten von Qualcomm widersprechen sich außerdem beim Status von Dragonwing IQ-9075: Die Produktseite kennzeichnet ihn als Active und das EVK ist evaluierbar, während das Product Longevity Program den IQ-9075 weiterhin als Sampling kennzeichnet und eine Langlebigkeit bis 2038 nennt. Das Bestell-/SKU-Präfix ist QCS9075. Qualcomm bewirbt Konfigurationen mit 50 und 100 dichten INT8-TOPS sowie Unterstützung für Ubuntu/Yocto. Der Produktionsstatus sollte für die genaue Bestell-SKU bestätigt werden. Eine LibreYOLO-Integration sollte diese SKU dokumentieren, statt einen allgemeinen Ordner „Qualcomm“ zu erzeugen.

DEEPX

Die Beschleuniger DX-M1/DX-M1M von DEEPX verwenden das DXNN SDK. DX-COM kompiliert und quantisiert das Modell, DX-RT führt es aus, und das Deployment-Artefakt nutzt das Format .dxnn. Das Unternehmen veröffentlicht die DX-AllSuite, Anwendungsbeispiele in DX-APP und einen umfangreichen Online Model Zoo.

Bei der Prüfung mit Stichtag August 15, 2026 meldete der öffentliche Katalog 354 Einträge unter DX-COM 2.4.0 und DX-RT 3.4.0. Die dokumentierte Abdeckung umfasst YOLOv3 bis YOLO11 und YOLO26, YOLOX, SSD, EfficientDet, NanoDet, DAMO-YOLO, YOLO-Segmentierung, Pose und orientierte Boxen. DEEPX ist ein besonders plausibles Integrationsziel, weil die Compiler-/Runtime-Grenze und das Deployment-Artefakt klar benannt sind und die öffentliche Vision-Abdeckung umfangreich ist.

Industrielle SoCs sind mehrere Ökosysteme, nicht eines

Industrieanbieter bieten oft längere Produktlebenszyklen sowie bessere Kamera-, Sicherheits- und Echtzeitintegration als SoCs für Maker-Boards. Ihre KI-Stacks können komplizierter sein, weil ein Anbieter unter Umständen mehrere voneinander unabhängige NPU-Architekturen gleichzeitig ausliefert.

Texas Instruments

Zu den aktuellen Edge-AI-Prozessoren von TI gehören AM62A, AM67A, AM68A, AM69A und verwandte TDA4-Geräte. Der Softwarepfad kombiniert Processor SDK Linux, TIDL-Compiler/Runtime, Edge AI TIDL Tools und den Edge AI Model Zoo. TIDL kann sich in ONNX Runtime, TensorFlow Lite und andere Anwendungs-Runtimes integrieren und unterstützte Teilgraphen auslagern.

TI veröffentlicht mehr als nur die Aussage, ein Framework importieren zu können: Der Zoo enthält konvertierte Modelle und Leistungsmetadaten für Objekterkennung, Segmentierung, Pose, Klassifikation, Tiefe und weitere Aufgaben. TI weist auch darauf hin, dass Modell-Zoo-Artefakte Ausgangspunkte für die Entwicklung und nicht automatisch produktionsreife Assets sind. Dieser wertvolle Vorbehalt fehlt in vielen Herstellervergleichen.

TI führt außerdem TDA54-Q1 als Preview mit bis zu vier C7-NPUs und bis zu 400 TOPS bei diesem Bauteil. Für die breitere TDA5-Familie werden bis zu 1.200 TOPS beworben. Das sind Herstellerangaben zu einer neuen Generation und keine Grundlage, die TIDL-Modellvalidierung für AM6xA/TDA4 auf TDA54-Q1 zu übertragen, bevor TI eine zielgenaue Matrix veröffentlicht.

NXP

NXP benötigt mindestens vier Backend-Beschreibungen:

Der eIQ Model Zoo enthält Assets oder Rezepte für YOLOv4-tiny, YOLOv8, NanoDet, CenterNet, FastestDet, SSD Lite, YOLACT und andere Modelle. Der YOLOv5-Eintrag wurde nur als Dokumentation ergänzt. Ein Eintrag, der für ein Backend validiert ist, belegt nicht die Eignung für alle vier. NXPs eigene YOLO-Exportanleitung für i.MX-Plattformen veranschaulicht die zielabhängige Konvertierung. NXP zufolge erhielt das monolithische eIQ Toolkit nach Version 1.17 im Q3 2025 keine Updates mehr. Aktuelle Abläufe verwenden eigenständige Pakete wie das eIQ Neutron SDK.

NXP schloss die Übernahme von Kinara in October 2025 ab. Das Ara240-Datenblatt nennt bis zu 40 vom Hersteller beworbene eTOPS und 313 Bilder pro Sekunde bei YOLOv8n. NXP listet Ara SDK und eIQ Toolkit auf der Produktseite, was aber keinen Austausch von Artefakten mit dem separaten Neutron-Pfad von i.MX 95 belegt. Das M.2-Modul mit 16 GB ist aktiv, die USB-Option befindet sich in der Vorproduktion. NXP definiert das „e“ in eTOPS als „equivalent“, nicht als „effective“. Das ist keine dichte INT8-TOPS-Kennzahl eines anderen Herstellers und sollte nicht direkt verglichen werden.

STMicroelectronics

STM32N6x7-Geräte, darunter STM32N657 und STM32N647, integrieren einen Neural-ART-Beschleuniger mit 600 GOPS in ein MCU-Produkt. Die universellen Produktlinien N6x5 enthalten diesen Beschleuniger nicht. STM32Cube AI Studio und ST Edge AI Core analysieren und optimieren importierte Modelle. STM32 AI Model Zoo Services stellt Deployment-, Optimierungs-, Benchmark- und Beispielabläufe bereit.

Die aktuelle Übersicht zur Objekterkennung dokumentiert Tiny YOLOv2, YOLOv5u, YOLOv8, YOLO11, YOLO26 und ST-YOLOX sowie Klassifikations-, Pose- und Segmentierungsdienste. Das ist nicht dieselbe Leistungsklasse wie eine PCIe-Karte mit 200 TOPS. Interessant ist die Plattform, weil Kameraeingang, Inferenz und Steuerung in ein enges Energie- und Speicherbudget eingebetteter Systeme passen.

Renesas

Renesas-RZ/V-Prozessoren integrieren DRP-AI-Beschleuniger. Die Software entwickelte sich vom DRP-AI Translator und DRP-AI TVM in Richtung RUHMI, das auf EdgeCortix-MERA-Technologie basiert. Das offene RZ/V-DRP-AI-TVM-Repository und die Validierungsliste für RZ/V2H nennen YOLOv5, YOLOv8, YOLO11 und YOLO26 in den Größen n/s/m, YOLOX sowie Pose- und Segmentierungsnetzwerke neben Klassifikationsmodellen.

Renesas ist ein glaubwürdiges Ziel für Robotik und Industrie. Für Reproduzierbarkeit müssen jedoch das genaue Board, die DRP-AI-Generation, die Translator-Version und die CPU-seitige Nachverarbeitung dokumentiert werden.

Intelligente Sensoren und kamerazentrierte Prozessoren

Sony IMX500

Sony IMX500 ist kein normaler Anwendungsprozessor. Bildsensor und KI-Verarbeitung sind gestapelt, sodass die Inferenz im Sensor stattfinden kann und weniger Bilddaten die Kamera verlassen müssen. Die Raspberry Pi AI Camera macht diese Architektur ungewöhnlich zugänglich.

Das offizielle Raspberry-Pi-IMX500-Modellrepository veröffentlicht paketierte Modelle für YOLOv8n, YOLO11n, EfficientDet Lite0, NanoDet+ und SSD MobileNetV2 FPN Lite. Die Dokumentation der AI Camera beschreibt Konvertierung, Paketierung und Nachverarbeitung auf dem Sensor. Die Deployment-Einheit ist ein RPK-Paket statt einer allgemeinen ONNX-Datei. Sensor-Speicher und Operatorbeschränkungen sind zentrale Designgrenzen. Auf der Produktseite von Raspberry Pi steht, dass diese Kamera mindestens bis January 2028 produziert wird.

Ambarella

Ambarellas CVflow-Prozessoren sind in Kameras, Drohnen und Automotive Vision fest etabliert. Zu den aktuellen Produktfamilien gehören CV72/CV75 für Kameras, CV5/CV52 für leistungsfähigere Vision-Systeme und CV3-AD für Automotive. Die Cooper Developer Platform sowie der CVflow-Kompilierungs- und Runtime-Ablauf bilden den öffentlich benannten Software-Stack.

Der öffentliche Entwickler-Model-Garden nennt YOLOX, RTMDet, DeepLabV3+, TopFormer, OWL-ViT und multimodale Modelle. Detaillierte Compiler-Dokumentation und Downloads bleiben jedoch partnerorientiert. Eine Ambarella-Integration sollte daher mit einer Beziehung zum Hersteller oder OEM beginnen und nicht mit der Annahme, ein öffentliches pip-Paket sei erhältlich.

Synaptics Astra

Für Synaptics sind drei Ziele relevant. Astra-Systeme SL1600/SL1680 verwenden das SyNAP Toolkit, das ein Quellmodell samt YAML-Beschreibung in ein model.synap-Paket umwandelt. Neuere Geräte SL2611/13/15/17/19 verwenden die Torq-Plattform, einen IREE-/MLIR-basierten Ablauf, der .vmfb erzeugt. Die SR100-Serie ist eine separate MCU-Familie auf Basis von Cortex-M55 und Ethos-U55 mit eigenem SDK. Diese Artefakte und APIs sind nicht austauschbar.

Das offizielle YOLO-Benchmark-Tutorial ist ungewöhnlich konkret: Es exportiert YOLOv8 nach TFLite, führt asymmetrische UINT8-Kalibrierung in SyNAP aus, kompiliert für SL1680 und startet anschließend synap_cli sowie die Objekterkennungsanwendung. Das belegt YOLOv8n/v8s auf SL1680 und beschreibt SyNAP-Unterstützung bis YOLO11. Ein separater Leitfaden zur Objekterkennung auf SL261x führt YOLOv8 mit Torq-.vmfb aus. Dies sind offizielle Beispiele für bestimmte Ziele und keine Behauptung, jeder YOLO-Graph werde auf allen drei Familien unterstützt.

MediaTek Genio

MediaTek verdient einen ausführlichen Eintrag, denn der aktuelle IoT AI Hub stellt jetzt Hardware-/Softwarematrix, Modellpakete und Benchmarktabellen bereit, die ältere Marktübersichten nicht prüfen konnten. Genio 360/360P/420/520/720 verwenden NeuroPilot 8 mit MDLA 5.3. Genio 510/700 verwenden NP6 mit MDLA 3.0, Genio 1200 NP6 mit MDLA 2.0. MediaTek erklärt, dass NeuroPilot- und MDLA-Generation, Operatorsatz, Compiler und Runtime für die Lebensdauer jedes SoC versionsgebunden sind.

Der analytische KI-Pfad ist auf TFLite ausgerichtet:

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

Neuere Genio-Produkte bieten außerdem Online-Delegation über LiteRT und auf unterstützten Betriebssystemen einen ONNX-Runtime-CPU-/NPU-Pfad. Diese Ausführungsmodi unterscheiden sich von einem Offline-.dla. Der Softwarearchitektur-Leitfaden und die Ressourcenmatrix machen den Unterschied ausdrücklich.

Die offizielle Tabelle analytischer Modelle veröffentlicht YOLOv5s- und YOLOv8s-Benchmarkeinträge und Konvertierungsleitfäden für mehrere MDLA-Generationen. Vorab konvertierte YOLO-Artefakte werden wegen der Beschränkungen von AGPL-3.0 ausdrücklich nicht verteilt. Die Quant8-Offline-Messungen bei 640 x 640 nennen 5.35 ms beziehungsweise 8.04 ms auf Genio 720. Die Modellseite zu YOLOv8s veröffentlicht Ein-/Ausgabe-Tensoren, Backend-spezifische Zeiten und Warnungen zu benutzerdefinierten MediaTek-Operationen. Diese Werte sind Hersteller-Benchmarks und keine Ergebnisse vollständiger Kamerapipelines.

Der Zugang ist der begrenzende Faktor. Die öffentliche Yocto-Dokumentation ist detailliert, doch das aktuelle NP8-Komplettpaket für Converter und Compiler sowie viele Android-Unterlagen sind als NDA- oder Direktkundenressourcen gekennzeichnet. Ein normales Entwicklerkonto bietet nicht denselben Zugang wie ein MediaTek-Online-Kundenkonto. LibreYOLO sollte Genio deshalb als technisch belegt, aber für eine reproduzierbare Compilerintegration mit eigenen Modellen als partnerschaftsabhängig behandeln.

Auf China ausgerichtete Edge-AI-Ökosysteme

Einige der leistungsfähigsten und zugänglichsten kostengünstigen Vision-Plattformen sind in englischsprachigen Marktübersichten unterrepräsentiert.

D-Robotics und von Horizon abgeleitete BPU-Plattformen

D-Robotics unterhält das Entwickler-Board-Ökosystem RDK für BPU-Beschleuniger in RDK X3, X5, Ultra und neueren Produkten der S100-Serie. Der aktuelle Branch rdk_x5 des RDK Model Zoo dokumentiert für RDK X5 YOLOv5/v5u, YOLOv8/9/10/11/12/13/26, YOLOE, YOLO-World sowie Pfade für Erkennung, Segmentierung, Pose, Klassifikation, OCR und CLIP. X3 verwendet einen eigenen Branch, während die aktuelle S-Serie im Haupt-Zoo im Branch rdk_s bereitgestellt wird. Das ältere Repository rdk_model_zoo_s enthält historische Demos. Die moderne X5-Liste belegt daher keine Validierung aller Modelle auf X3, Ultra oder S100.

OpenExplorer/Algorithm Toolchain importiert ONNX oder Caffe für PTQ und unterstützt QAT-Abläufe mit PyTorch. Das Deployment ist plattformspezifisch: Aktuelles RDK X5 verwendet .bin über hbm_runtime und libdnn. Der aktuelle primäre rdk_s-Pfad verwendet .hbm über eine gleichnamige hbm_runtime-API und libhbucp. X3 behält seinen älteren Branch und seine Inferenzschnittstellen. Älteres Material in rdk_model_zoo_s beschreibt ebenfalls historische .bin- und .hbm-Pfade. Diese Artefakte müssen jeweils mit dem zugehörigen Branch und der passenden Toolchain gepaart bleiben. Nicht unterstützte Operatoren können auf die CPU zurückfallen. Die öffentlichen Beispiele sind hilfreich, doch die Versionskompatibilität von RDK OS, Board-Firmware, Toolchain und Modell-Binärdatei gehört weiterhin zum Kompatibilitätsvertrag.

AXERA

Die AX650-/AX630-/AX620-Familien von AXERA kommen in kompakten KI-Kameras und Boards wie der MaixCAM-Reihe von Sipeed vor. Pulsar2 importiert ONNX, führt Kalibrierung und Präzisionsanalyse aus und erzeugt .axmodel. AXEngine führt das Artefakt aus.

Die offiziellen AXERA-Beispiele decken YOLOv5/6/7/8/9/10/11/13/26, YOLOX und YOLO-World ab. Aufgaben- und Chipunterstützung variieren je nach Plattform. Für unterstützte Ziele enthalten die aktuellen YOLO26-Beispiele Erkennung, Pose, Segmentierung und OBB. Die Pulsar2-Konvertierungsbeispiele zeigen den tatsächlichen Aufwand: genaue Tensor-Namen, Ausgabeaufteilungen, Layout-Transformationen, Kalibrierungsarchive und Zieleinstellungen für die Hardware.

SOPHGO

TPU-MLIR von SOPHGO ist einer der attraktiveren Compiler-Stacks für unabhängige Integration, da der Compiler selbst Open Source ist. Er importiert ONNX, PyTorch, TFLite und Caffe, senkt Graphen ab und quantisiert sie. Für BM-Ziele erzeugt er .bmodel, für CV18xx-Hardware .cvimodel.

Das TPU-MLIR-Projekt unterstützt abhängig vom Ziel Abläufe mit FP32, BF16, FP16 und INT8. Die SOPHON-Demo-Sammlung nennt YOLOv3/4/5/7/8/9/10/11/12/26, YOLOX, PP-YOLOE, YOLO-World, OBB-/Segmentierungsvarianten, SSD, CenterNet, RetinaFace, SAM/SAM2 und OCR. Wie immer validiert eine Demo für BM1684X nicht dasselbe Artefakt auf BM1688 oder CV18xx.

Huawei Ascend

Zu Huaweis Edge-Inferenzlinie gehören Ascend-310/310P/310B-Chips in Atlas-200I- und -300I-Produkten. CANN stellt ATC-Compiler, AscendCL-Runtime und chipspezifische Operator-Kernels bereit. ATC wandelt ONNX und andere Quellrepräsentationen in ein Offline-Modell .om um.

Die aktuelle Dokumentation zum Atlas 200I DK A2 und CANN-Beispiele stellen einen YOLOv5-.om-Pfad für Ascend 310B bereit. Der breitere, ältere Ascend ModelZoo enthält YOLOv2/3/4/5, YOLOX, YOLOR, SSD, RetinaNet, Mask R-CNN, Pose- und Segmentierungsmodelle. Diese Einträge sollten jedoch nicht so dargestellt werden, als seien alle auf 310B erneut validiert worden. CANN, Kernels, Firmware und SoC müssen zusammenpassen. Ein .om für Ascend310P ist kein allgemeines Ascend-Artefakt.

Cambricon

Cambricons MLU-Beschleuniger verwenden Neuware und die Inferenz-Engine MagicMind. Das öffentliche MagicMind-Cloud-Repository ist auf MagicMind 1.7 und eine MLU370-X4/S4-Matrix festgelegt. Es ist historische Evidenz zur Kompatibilität, keine Matrix für ein aktuelles SDK oder MLU270. Das Repository dokumentiert PyTorch-, ONNX-, Caffe- und Paddle-Pfade. TensorFlow-Framework-Unterstützung wurde in 1.7 entfernt, obwohl historische TensorFlow-Beispiele verbleiben. Cambricons aktuelles 3-Series-Entwicklerportal führt spätere SDK-Gesamtversionen auf. Öffentliches Beispielrepository und aktueller kommerzieller Stack dürfen daher nicht als eine Version dargestellt werden.

Das offizielle MagicMind-Cloud-Modellrepository veröffentlicht eine ungewöhnlich direkte MLU370-X4/S4-Matrix. Sie führt Beispiele zu YOLOv3, Tiny-YOLOv3, YOLOv4, YOLOv5, YOLOv7, YOLOv8, PP-YOLOE, SSD, RetinaFace, RetinaNet, Mask R-CNN, DeepLab und UNet auf und nennt jeweils, ob C++- oder Python-Beispiele verfügbar sind. Die Evidenz ist stark; die größte Hürde ist der SDK- und Containerzugang über Cambricon-Kanäle.

Canaan/Kendryte

Kendrytes aktuelle K230/K230D- und älteren K210/K510-KPU-Chips sind am kostengünstigen Board- und Smart-Kamera-Ende des Marktes relevant. Der nncase-Compiler importiert ONNX oder TFLite, verwendet Kalibrierungsdaten für die Festkommaumwandlung, simuliert das Ergebnis auf einem Host und erstellt .kmodel.

Der offizielle K230-nncase-Entwicklungsleitfaden führt durch Kompilierung, Simulation und Ausführung von YOLOv5s. Der separate KI-Demokatalog enthält YOLOv8n-Artefakte für Erkennung, Segmentierung und Pose. Das aktuelle CanMV-Changelog ergänzt optimierte Beispiele für Klassifikation, Erkennung, Segmentierung, OBB und Pose mit YOLOv8/11/26. Das YOLOv5s-Ergebnis im Datenblatt ist der tatsächlich veröffentlichte Benchmark. Versionen des Compilers und des binären KPU-Plug-ins müssen zum Board-SDK passen.

Allwinner

Allwinner V853 kombiniert medienorientierte Kamerahardware mit einer Vivante-NPU mit 1 TOPS. Der offizielle englische NPU-Leitfaden beschreibt Import, Quantisierung, Verifizierung und Deployment über Acuity/Pegasus und viplite. Die eigenen Modellseiten von Allwinner und der YOLOv5-Leitfaden nennen YOLOv2/3/4/4-tiny/5/5s, RetinaNet, MobileNet, ResNet sowie Gesichts- und Personennetzwerke.

Das ist eine echte Unterstützung für Computer Vision, sie bleibt aber an die ältere Tina-Linux-/Vivante-Toolchain und SDK-Downloads mit Kontoanforderung gebunden. Mit sichtbarer Einschränkung gehört sie in die Marktübersicht.

Weniger beachtete Plattformen aus Korea, Taiwan und China

Englischsprachige Listen springen häufig von Rockchip zu NVIDIA und übersehen eine zweite Gruppe realer, dokumentierter Chips. Einige dieser Ökosysteme haben aktuell breitere YOLO-Matrizen als bekanntere westliche Start-ups.

Mobilint

Der koreanische Beschleunigeranbieter Mobilint verkauft den stromsparenden REGULUS und den leistungsstärkeren ARIES MLA100. Sein qb SDK akzeptiert PyTorch, TensorFlow, TFLite, ONNX und Keras-Eingaben, quantisiert nach INT8 und erzeugt ein kompiliertes .mxq-Artefakt. Die öffentliche Vision-Matrix nennt YOLOv3/v5/v7/v8/v9/v10/11/12/26 für Erkennung sowie YOLO-Segmentierungs-, Pose- und OBB-Varianten. Die ARIES-Seite veröffentlicht sogar Ergebnisse speziell für YOLO11s und YOLO26m. Das ist ein starker Integrationsbeleg, auch wenn Zugang zu SDK und Hardware kommerziell bleibt.

Sunplus

Sunplus SP7350/C3V verwendet einen von Vivante abgeleiteten NPU-Stack, verpackt ihn aber anders als Allwinner oder das ältere Amlogic. Der öffentliche Ablauf kombiniert Acuity-Konvertierung, eine NPU-Docker-Umgebung, SNNF-Runtime und .nb-Ausgabe. Der offizielle YOLOv8-Leitfaden für angepasste Modelle führt durch Konvertierung und Deployment, statt lediglich Framework-Unterstützung zu behaupten. Verwandte IP macht dessen .nb nicht auf einem anderen Vivante-basierten SoC portabel.

ESWIN Computing

Zu ESWINs RISC-V-Familie gehören EIC7700/EIC7700X und das Dual-Die-Modell EIC7702/EIC7702X. EIC7700 steckt in ausgelieferten Boards wie Milk-V Megrez. ENNP umfasst EsQuant, den aktuellen EsAAC-Compiler, Erzeugung von Golden Data, Simulation und ESSDK-Runtime sowie die kompilierte Ausgabe .model. Älteres ENNP-Material verwendete den Namen ennc-compile. Die aktuelle EsAAC-Seite dokumentiert ONNX als Eingabe. Für andere Frameworks muss daher exportiert oder in diese unterstützte IR konvertiert werden. Die von Milk-V bereitgestellte ENNP-Übersicht und das YOLOv3-Tutorial belegen einen öffentlichen End-to-End-Pfad, aber keine aktuelle, umfassende Modell-/Accuracy-Matrix.

Nuvoton M55M1

Nuvoton M55M1 kombiniert die Cortex-M55-Klasse mit Ethos-U55-256 und ist ein MCU-Design, kein Linux-Anwendungsprozessor. NuEdgeWise/NuML und Arm Vela bereiten quantisierte TFLite-Micro-Modelle vor. Das öffentliche NuEdgeWise-Repository nennt YOLOv8-nano, YOLOX-nano, YOLO Fastest v1.1, SSD-MobileNet FPNLite und mehrere Klassifikatoren. Diese Beispiele für kleine Netzwerke belegen die Speicher-/Leistungsklasse, nicht Standard-YOLO-Varianten mit 640 Pixeln.

Rebellions und FuriosaAI

Die ATOM-Reihe von Rebellions verwendet das RBLN SDK und kompilierte .rbln-Artefakte. Das offizielle Support-Release nennt YOLOv3 tiny/full/SPP, YOLOv5 n bis x, YOLOv6 n bis l, YOLOv7-Varianten und YOLOv8 n bis x. Die aktuelle Kartensupport-Matrix kennzeichnet ATOM CA02 und ATOM+ CA12 als EoL sowie ATOM+ CA22 und ATOM-Max CA25 als Active. ATOM-Lite CA21 hat eine Produktseite, fehlt aber in der SDK-Matrix. Der aktuelle Toolchainstatus ist daher unklar. Die Dokumentation ist öffentlich, das Compiler-Wheel erfordert aber Anmeldedaten für das Rebellions Portal.

FuriosaAI muss nach Generationen getrennt werden. Warboy ist der ältere Computer-Vision-Beschleuniger mit INT8-.enf-Artefakten und einem offiziellen Model Zoo mit SSD, YOLOv5M/L und YOLOv7-w6-pose. RNGD nutzt einen anderen .fxb-Stack, der hauptsächlich auf LLM-/VLM-Arbeitslasten ausgelegt ist. Furiosas aktuelle Roadmap führt Vision-Unterstützung für YOLOv8m als in 2024 Q4 abgeschlossen auf. Die aktuellen öffentlichen Modell- und Leistungsseiten konzentrieren sich jedoch auf LLM/VLM und enthalten keine detaillierte Accuracy-/Leistungsmatrix für YOLOv8m. Das belegt einen abgeschlossenen Release, nicht Kompatibilität mit Warboy.

Realtek, Telechips, T-Head und SigmaStar

Diese vier Plattformen sind real, bieten aber engere, ältere oder zugangsbeschränkte Möglichkeiten, eigene Modelle einzubringen:

HiSilicon Smart Vision ist nicht Huawei Ascend

HiSilicon-Kamera-SoCs Hi3516CV610/DV500, Hi3519DV500 und Hi3403V100 bieten einen ATC-zu-.om-Ablauf über NNN-/SVP-NNN-Runtimes. Der offizielle HiSpark Model Zoo nennt in einer zielbezogenen Matrix, insbesondere für Hi3403 und Hi3591P, YOLOv3/4/5/6/7/8/9/10/11, YOLO11-Segmentierung/Pose, YOLOv8 OBB/World/Segmentierung, OCR, Tiefe und TinySAM. Daraus folgt nicht, dass alle Einträge auf jedem oben genannten Smart-Vision-SoC laufen. Einige Einträge sind Roadmap-Punkte. Ausgelieferte Beispiele und geplante Unterstützung müssen daher getrennt bleiben. Im Repository steht außerdem, dass die bereitgestellten Model-Zoo-Modelle nur für nicht kommerzielle Nutzung bestimmt sind. Gleiche Begriffe wie ATC/.om belegen keine Kompatibilität von Artefakten oder Runtimes mit der CANN-basierten Ascend-Produktlinie.

Neue und spezialisierte Beschleunigerunternehmen

MemryX

MemryX-MX3-Module verwenden eine Datenflussarchitektur und lassen sich zu Systemen mit mehreren Chips kombinieren. Der Neural Compiler akzeptiert ONNX-, TensorFlow-Lite-, Keras- und TensorFlow-Modelle und erzeugt ein DFP-Paket, das die Beschleuniger-Runtime verwendet. Die Runtime-APIs unterstützen Pipelines mit mehreren Modellen und Streaming.

Die MemryX-Dokumentation und Beispiele enthalten optimierte YOLO-Vor- und Nachverarbeitung für Erkennung, Segmentierung und Pose. Die SDK-Release-Notes nennen ausdrücklich Unterstützung für YOLOv10, YOLO11 und YOLO26. Das öffentliche Material ist technisch hilfreich, bietet aber keine einzelne übersichtliche Tabelle für Modell, Accuracy und Gerät wie bei Axelera.

Kneron

Knerons Produkte KL520/KL530/KL630/KL720/KL730 reichen von kleinen USB- bis zu eingebetteten Beschleunigern. Kneron PLUS deckt die Anwendungs-Runtime ab. Die aktuelle Model Toolchain 0.33.1 dokumentiert Konvertierung, Quantisierung, Evaluierung, Simulation und .nef-Kompilierung für diese Ziele. KL830 erscheint in einigen PLUS-Runtime-APIs, aber nicht in der aktuellen Compiler-Zielliste. Eine allgemeine Aussage über .nef-Kompilierung sollte daher ohne Herstellerbestätigung nicht auf KL830 übertragen werden.

Das offizielle YOLO-Beispiel demonstriert den Ablauf mit Tiny-YOLOv3. Anderes Material von Kneron behandelt Training und Deployment mit YOLOv5. Die Belege sind glaubwürdig, aber enger gefasst als die umfangreichen modernen YOLO-Matrizen von Hailo, Axelera, Rockchip oder DEEPX.

SiMa.ai

SiMa.ai MLSoC und die produktive Modalix-Plattform mit 50 TOPS verwenden die Palette-Softwareumgebung. ModelSDK, MLA-Compiler und ModelExecutor decken Import, Quantisierung, Kompilierung, Profiling und Ausführung ab. Je nach Arbeitslast und Produkt unterstützen die Tools Abläufe mit INT8, INT16 und BF16.

In den Release Notes des Unternehmens werden validierte Pipelines mit YOLOv7, YOLOv8 für Erkennung/Pose/Segmentierung, YOLOX, YOLOX-Segmentierung, DETR, Mask R-CNN und EfficientDet genannt. Eine aktuelle Einschränkung sollte nicht verschwiegen werden: Laut Palette SDK 2.1 Notes funktioniert QAT wegen einer Python-/PT2E-Quantisierungsregression nicht. Als Workaround soll die annotierte ONNX-Datei mit SDK 2.0 erstellt und mit 2.1 kompiliert werden. Zugang und Beschaffung bleiben auf Unternehmen ausgerichtet.

Die Deployment-Grenze ist ebenfalls dokumentiert: Der ModelSDK-Kompilierungsablauf erzeugt ein kompiliertes .tar.gz und kann eine ausführbare ELF-Datei erstellen. Das MPK Tool verpackt ein auslieferbares .mpk. Diese Ausgaben bleiben an das MLSoC-/Modalix-Ziel und die Palette-Version gebunden.

EdgeCortix

SAKURA-II ist ein mit 60 TOPS beworbener Beschleuniger für Vision und generative KI, der über das MERA-Software-Framework kompiliert wird. EdgeCortix liefert außerdem MERA-Technologie für Renesas' neueren RUHMI-Ablauf.

Die SAKURA-II-Produktunterlagen belegen Hardware und Compiler. M.2-/PCIe-Hardware wird auf Anfrage zur Teststellung oder Bestellung angeboten. Eine hinreichend genaue, aktuelle öffentliche YOLO-Kompatibilitätsmatrix wurde nicht gefunden. Das ist bei der Beschaffung nützlich: Vor einer Hardwarezusage sollte eine Modellvalidierung angefragt werden.

BrainChip

BrainChip Akida ist ein neuromorpher Ereignisprozessor und keine konventionelle Dense-Tensor-NPU. Die MetaTF-Umgebung besteht aus installierbaren Python-Paketen zum Erstellen von Modellen, Quantisieren auf niedrige Bitbreiten, Konvertieren, Simulieren und Ausführen auf Hardware. BrainChip verkauft inzwischen einen ausgelieferten AKD1500-Coprozessor im M.2-Format sowie ältere AKD1000-Hardware und Akida-2-IP.

Die aktuelle Akida-2-Modellkarte nennt einen AkidaNet0.5-YOLOv2-Detektor, CenterNet, AkidaUNet und Gesichtserkennungsnetzwerke. Weiteres Supportmaterial umfasst FOMO und ereignisbasierte Arbeitslasten. Akida unterstützt ungewöhnlich niedrige Bitbreiten bei Gewichten und Aktivierungen. Für ein erfolgreiches Deployment kann jedoch eine architekturbewusste Konvertierung nötig sein, statt Akida wie ein weiteres allgemeines INT8-ONNX-Ziel zu behandeln. Ein Modellergebnis für AKD1000 oder Akida 2 darf AKD1500 erst zugeschrieben werden, wenn ein expliziter Zuordnungs-/Fit-Bericht dies validiert.

Blaize

Blaize verkauft Pathfinder- und Xplorer-Produkte auf Basis von P1600. Picasso SDK, NetDeploy und AI Studio bilden den Softwarepfad. Die Produktseiten richten sich klar an Vision und Edge AI, stellen aber keine aktuelle öffentliche Kompatibilitätsmatrix für einzelne Modelle bereit.

Dieser Leitfaden ordnet Blaize daher als kommerziell und zugangsbeschränkt ein, statt die Lücke mit Community-Aussagen zu füllen. Ein vom Hersteller bereitgestellter Kompilierungs- und Accuracy-Bericht für das vorgesehene Modell sollte Voraussetzung sein.

TinyML und Vision am Endgerät

Arm Ethos-U und Alif

Arm lizenziert NPU-IP Ethos-U55, U65 und U85 an Chipunternehmen. Der Vela-Compiler übernimmt quantisierte LiteRT-/TFLite-Graphen und wandelt unterstützte Teilgraphen in benutzerdefinierte Ethos-U-Operationen um. Nicht unterstützte Operationen können auf der CPU verbleiben. „Die Anwendung läuft“ und „das ganze Netzwerk läuft auf der NPU“ sind unterschiedliche Aussagen.

Reale Implementierungen sind Ethos-U55 in Alif Ensemble E7, Ethos-U65 in NXP i.MX 93 und Ethos-U85 in neueren Systemen. Alifs E7 AI/ML AppKit dokumentiert zwei ML-Beschleuniger und zeigt den E7-TFLite-zu-Vela-Pfad. Ensemble E8 kombiniert einen Ethos-U85 mit zwei Ethos-U55-NPUs. Alif veröffentlicht außerdem einen INT8-Benchmark für einen YOLO-Fastest-Gesichtsdetektor auf Familienebene bei 192 mal 192 auf Cortex-M55 plus Ethos-U55, aber keine breite, zielgenaue Matrix für moderne YOLO-Modelle. Diese speicherbegrenzten Systeme eignen sich für kleine Klassifikations- und Erkennungsnetzwerke, nicht für beliebige Detektoren mit 640 Pixeln, nur weil sie sich mit TFLite darstellen lassen.

Infineon PSOC Edge, Himax WiseEye2 und Analog Devices MAX7800x

Infineons Familien PSOC Edge E83 und E84 kombinieren Cortex-M55 mit Ethos-U55 und ergänzen einen separaten NNLite-Block auf der stromsparenden M33-Seite. Das E84-Architekturhandbuch dokumentiert 8-Bit-Gewichte, 8- oder 16-Bit-Aktivierungen und einen Vela-Ablauf. Dabei werden unterstützte Operatoren zu einem NPU-Befehlsstrom und nicht unterstützte Arbeit bleibt auf der CPU. Der DEEPCRAFT Model Converter akzeptiert TFLite-, Keras- und PyTorch-Pfade. Die Architekturunterlagen nennen MobileNetV1/V2 als repräsentative Kernels, nicht als Ziel-Benchmarks. Das E84 AI Kit enthält eine Kamera und verwendet ModusToolbox. Öffentliches Material bietet jedoch noch keine YOLO-Kompatibilitätsmatrix mit benannten Modellen. Das ist eine programmierbare Vision-Plattform mit einer sich entwickelnden Modellevidenz, kein validiertes allgemeines Detektorziel.

Himax HX6538 WiseEye2 kombiniert für Always-on-Vision ebenfalls Cortex-M55 und Ethos-U55. Die öffentliche Softwaredokumentation ist für diese Leistungsklasse ungewöhnlich konkret: Die offiziellen Beispiele für Grove Vision AI Module V2 umfassen YOLOv8n-Objekterkennung, Pose und Geschlechterklassifikation, YOLO11n-Erkennung, Face Mesh und PeopleNet. Der einheitliche Pfad verwendet TFLite Micro und Vela und fällt bei Bedarf auf CMSIS-NN und Reference-Kernels zurück. Es handelt sich ausdrücklich um kleine Modelle und Auflösungen, nicht um einen Nachweis, dass ein herkömmlicher YOLO-Graph im Serverformat passt.

Analog Devices verfolgt mit den CNN-Beschleunigern MAX78000/MAX78002 einen anderen Weg. Das öffentliche Tool ai8x-synthesis quantisiert ein trainiertes Netzwerk und erzeugt zielspezifischen C-Code, Gewichte und Beschleunigerkonfiguration statt eines portablen ONNX-Runtime-Pakets. Evidenz des Herstellers umfasst Gesichtsidentifikation, TinierSSD zur QR-Erkennung im ADI Model Zoo und Bildklassifikatoren. Die Geräte sind für Vision am Endgerät relevant, aber eine aktuelle offizielle Matrix für moderne YOLO-Modelle wurde nicht gefunden.

GreenWaves GAP9

GAP9 kombiniert RISC-V-Rechenleistung mit der NE16 Neural Engine. NNTool importiert und quantisiert Netzwerke; AutoTiler und GAP SDK erzeugen daraus ausführbaren Code. Das öffentliche GAP9-Netzwerkmenü enthält MobileNet, EfficientNet, ResNet, MobileNet SSD sowie Anwendungen für Gesichts- und Wiedererkennung. GreenWaves veröffentlicht außerdem ein YOLOX-Projekt zur Personenerkennung mit Accuracy- und Simulationsergebnissen.

Das ist ungewöhnlich transparente TinyML-Evidenz. Das vollständige SDK erhalten aber nur qualifizierte Kunden, und die Modelle sind deutlich kleiner als gängige YOLO-Varianten mit 640 mal 640 Pixeln.

Lattice sensAI

Lattice sensAI ist eine FPGA-basierte Alternative zu einer festen NPU. sensAI Studio und der Neural Network Compiler bilden einen unterstützten Graphen auf konfigurierbare Beschleuniger-IP für ECP5-, iCE40-UltraPlus-, CrossLink-NX-, CertusPro-NX-, Avant-E- und Avant-X-Geräte ab. Die Ausgabe ist an das gewählte FPGA, den Beschleunigermodus, das Speicherlayout und das Bitstream gebunden und nicht als Runtime-Modell portabel.

Das aktuelle Handbuch zum Neural Network Compiler enthält eine ungewöhnlich direkte Topologietabelle. Sie führt YOLOv1 für ECP5, YOLOv5 und YOLOv8 für optimierte/erweiterte CrossLink-NX- und CertusPro-NX-Modi sowie YOLO11 nur mit Advanced-Mode-IP auf. Außerdem sind SSD, MobileNetV2-SSD, ResNet, ENet, SqueezeDet und weitere Vision-Netzwerke mit nicht unterstützten Zellen für einzelne FPGA-Familien aufgeführt. Der Advanced CNN Accelerator zielt auf Avant-E/Avant-X/CertusPro-NX und ist kommerzielle IP. Das ist ein Beleg aus einer Compilertabelle, kein Versprechen, ein einzelnes Bitstream unterstütze alle aufgeführten Topologien gleichzeitig.

Microchip VectorBlox

Microchips öffentlicher VectorBlox SDK 3.1 bereitet vollständig quantisierte INT8-TFLite-Netzwerke für konfigurierbare CoreVectorBlox-IP in PolarFire-SoC-FPGAs vor und kompiliert sie. tflite_preprocess und vnnx_compile erzeugen die Deployment-Assets .vnnx, .hex und .ucomp. Das Repository enthält auch einen Simulator und einen C-Treiber für das Zielsystem. TensorFlow-, ONNX- und OpenVINO-Graphen müssen zuvor den dokumentierten TFLite-/INT8-Aufbereitungspfad durchlaufen.

Die aktuelle Tutorialmatrix enthält YOLOv5n, YOLOv8n für Erkennung, Klassifikation, OBB, Pose und Segmentierung, YOLOv9t, dünn besetzte/komprimierte YOLO-Varianten, MobileNet, EfficientNet-Lite0, ResNet18, MiDaS, FFNet und QuickSRNet. Der C-Leitfaden zur Nachverarbeitung nennt separat YOLOv2/3/4/5 sowie Ultralytics-Decoder für Erkennung, Pose und OBB. SDK 3.1 unterstützt derzeit das PolarFire SoC Video Kit ausdrücklich nicht aber das PolarFire Video Kit ohne SoC. Ältere Board-Demos dürfen daher nicht mit dem aktuellen Zielvertrag verwechselt werden.

Das SDK steht öffentlich unter einer Microchip-spezifischen Lizenz zum Download bereit, die Software und abgeleitete Werke auf Microchip-Produkte beschränkt. Microchip bietet kostenlose, aber antragsbasierte Lizenzen für Libero Silver und CoreVectorBlox. Das Deployment bleibt ein FPGA-Systemvertrag: Beschleunigerkonfiguration, Bitstream, Firmware, vom SDK erzeugte Netzwerkdaten und Speicherlayout müssen zusammenpassen. Eine erfolgreiche VectorBlox-Kompilierung macht das Modell nicht zu einer Binärdatei, die auf ein beliebiges PolarFire-Design kopiert werden kann.

Syntiant

Syntiants NDP200 zielt auf Always-on-Inferenz für Vision, Audio und Sensoren unterhalb des Leistungsbudgets gewöhnlicher Linux-SoCs. Die aktuelle Hardwaretabelle führt NDP200 als Massenproduktion und NDP250 als Sampling. Das NDP200-Produktbriefing dokumentiert CNN-, RNN- und vollständig verbundene Netzwerke bei weniger als 1 mW. Die Ankündigung von NDP250 beschreibt dagegen Always-on-Bilderkennung bei weniger als 30 mW. „Sub-Milliwatt“ sollte nicht auf beide Bauteile verallgemeinert werden.

Öffentliches Material belegt keine breite YOLO-Kompatibilität. Das Produkt sollte deshalb über eine vom Hersteller unterstützte Modellbewertung für kleine Always-on-Klassifikatoren und -Detektoren geprüft werden, statt eine allgemeine ONNX-Exportannahme zugrunde zu legen.

Google Coral: zwei nicht verwandte Generationen

Die älteren Edge-TPU-Produkte verwenden den Edge TPU Compiler, libedgetpu und PyCoral mit vollständig INT8-quantisierten TFLite-Modellen. Die zentralen Repositories Edge TPU und PyCoral sind archiviert. Das ist ein echtes Wartungsrisiko, aber keine formelle Mitteilung zum Produktende der Hardware.

Google pflegt daneben eine separate, aktive, offene Coral NPU: RISC-V-Beschleuniger-IP zur Integration in stromsparende SoCs. Das öffentliche Projekt stellt derzeit RTL, Hardwaresimulation, Toolchain und ELF-Beispiele bereit. Es ist kein direkter USB-/M.2-Nachfolger der Edge TPU und veröffentlicht keine aktuelle YOLO-Deployment-Matrix.

Fallstricke bei angrenzenden GPUs, Client-NPUs und adaptiven Beschleunigern

NVIDIA, AMD, Intel und Apple tauchen häufig in NPU-Suchen auf, stellen aber keine austauschbare Beschleunigerklasse dar.

NVIDIA Jetson: Jetson Orin kombiniert eine CUDA-GPU mit dedizierten DLA-Kernen. TensorRT kann eine serialisierte Engine für DLA erstellen. Nicht unterstützte Layers laufen auf der GPU, sofern GPU-Fallback ausdrücklich aktiviert ist. Die aktuelle DeepStream-YOLO-Tabelle deckt YOLOv4/v7/v8/v9/11 ab, doch die meisten Einträge zielen auf GPUs. Der ausdrückliche ONNX-DLA-Eintrag ist YOLOv8s INT8. NVIDIAs DLA-Einschränkungen erklären die Operatorgrenzen. Thor ist ein weiterer Sonderfall: Laut NVIDIAs DriveOS-Migrationsleitfaden wurden DLA-Kerne in Thor zugunsten flexibler GPU-Planung entfernt. „Läuft auf Jetson“ sagt daher nicht, welcher Beschleuniger verwendet wird.

AMD Vitis AI: Die ältere Kria-/DPU-Generation kompilierte .xmodel-Graphen, die mit VART ausgeführt wurden. Das aktuelle Vitis AI 6.2 ist GA für zwei getrennte Versal-AI-Edge-Pfade: Gen1 auf VEK280/VE2802 nutzt ONNX, AMD Quark und einen zielgebundenen Snapshot-/Teilgraph-Ablauf. Gen2 auf VEK385 hat einen eigenen Compile- und Runtime-Vertrag. Gen1 veröffentlicht Beispiele für YOLOv5, YOLOv7, YOLOv8 und YOLOX. Ryzen AI ist ein vierter, separater Client-NPU-Stack. Artefakte und Validierung dürfen nicht zwischen älterer DPU, Versal Gen1, Versal Gen2 und Ryzen AI übertragen werden, nur weil überall der Name Vitis oder AMD vorkommt.

Intel OpenVINO: OpenVINO kann über eine API CPU, GPU und Core-Ultra-NPU ansprechen. Die Dokumentation des Intel-NPU-Plug-ins nennt unterstützte NPU-Generationen. Die Matrix verifizierter Modelle enthält gerätespezifische Spalten. Ein YOLO-Notebook belegt ein Anwendungsrezept, aber keine NPU-Validierung, sofern die Matrix dies nicht angibt. Unterstützte Operatoren, Formen, Präzision und installierter NPU-Treiber bestimmen weiterhin, ob der vollständige Graph darauf läuft. OpenVINO IR (.xml plus .bin) ist wiederverwendbare Quell-IR; ein Cache kompilierter Modelle ist geräte- und softwareabhängig.

Apple Core ML: coremltools konvertiert Modelle nach .mlpackage, das Xcode zu .mlmodelc kompiliert. Core ML kann Arbeit zwischen CPU, GPU und Apple Neural Engine verteilen, abstrahiert aber bewusst die genaue Aufteilung. Apple ist damit eine ausgezeichnete Deployment-Plattform. Aussagen wie „der gesamte YOLO-Graph lief auf der NPU“ sind ungeeignet, sofern Profilingdaten dies nicht belegen.

Die NPU-IP-Unternehmen hinter den Chipunternehmen

Einige Unternehmen verkaufen weder ein Board noch einen fertigen Beschleuniger. Sie lizenzieren NPU-Designs an SoC-Anbieter. Sie sind wichtig, weil dieselbe zugrundeliegende Architektur unter mehreren Chipmarken auftauchen kann, der endgültige SDK- und Artefaktpfad vom Lizenznehmer aber dennoch angepasst sein kann.

Imagination zeigt, warum Angaben zu Zugang und Lebenszyklus neben Architekturnamen stehen sollten. Das Open-Access-Programm bietet drei siliziumerprobte Series3NX-Konfigurationen ohne anfängliche IP-Lizenzgebühr, jedoch erst nach Unternehmensprüfung und mit kostenpflichtigem Support/Wartung sowie Produktionsroyalties. Das Neural Compute SDK stellt Kompilierungs-, Optimierungs-, Quantisierungs- und Runtime-Tools bereit. Eine offizielle Zusammenarbeit mit Baidu PaddlePaddle nennt PP-YOLOE-Erkennung, EfficientNet-Klassifikation und HRNet-Segmentierung. Diese Beispiele validieren nicht jede Series3NX- oder Series4-Konfiguration. Aktuelle einzelne Series4-Produktseiten kennzeichnen die Produkte als nicht verfügbar. Series4 sollte daher als historisch gelten, sofern der Vertrieb nichts anderes bestätigt.

Diese Schicht erklärt Ähnlichkeiten zwischen Produktfamilien. Sie schafft keine Portabilität von Artefakten. Zwei SoCs mit verwandter Vivante- oder Ethos-IP können unterschiedliche Speicherzuordnungen, Treiber, Compilerversionen, Operatorsätze und Hersteller-Runtimes haben.

Was tatsächlich ausgerollt wird: Tabelle zur Artefaktbindung

Am Ende der Compilerpipeline endet die scheinbare ONNX-Portabilität. Namen und Dateiendungen ändern sich, die praktische Regel bleibt: Bewahre das Originalmodell und die Kalibrierungsdaten auf, denn das native Artefakt lässt sich in der Regel weder auf eine andere NPU-Generation verschieben noch zuverlässig mit einem anderen SDK-Release neu erstellen.

Diese Tabelle ist mehr als eine Übersicht über Dateiendungen. Compilerversion, Zielkennung, Treiber, Firmware und BSP gehören zur reproduzierbaren Identität eines Modells. Ein künftiger LibreYOLO-Exporter sollte sie zusammen mit jedem Artefakt in einem maschinenlesbaren Manifest festhalten.

Toolzugang und Lebenszyklussignale

Hardwareverfügbarkeit und Compilerzugang sind unabhängig voneinander. Ein Board kann leicht zu kaufen sein, obwohl sein aktueller Compiler eine Kundenvereinbarung erfordert. Ein öffentliches SDK kann wiederum Silizium adressieren, das schwer zu beschaffen ist. Im Folgenden stehen konkrete Erstquellensignale, kein allgemeingültiges Ranking zur Lebensdauer.

Warum TOPS keine Kaufempfehlung sind

Spitzen-TOPS können innerhalb eines Anbieters und einer Architektur nützlich sein. Herstellerübergreifende Vergleiche sind meist ungültig, wenn nicht alle folgenden Punkte übereinstimmen:

• Numerische Präzision, etwa INT8, INT4, FP16 oder ein gemischter Modus
• Ob ein Multiply-Accumulate als eine oder zwei Operationen gezählt wird
• Dichte oder strukturiert dünn besetzte Arithmetik
• Eingabeauflösung, Batch-Größe und Modellgraph
• Accuracy nach der Quantisierung
• Nur NPU-Latenz oder Latenz der vollständigen Anwendungspipeline
• Speichertransfers und Host-Fallback
• Thermischer Zustand sowie Dauerbetrieb statt Spitzenlast

Ein Detektor ist eine Pipeline: Bilderfassung, Größenänderung/Letterboxing, Normalisierung, Geräteübertragung, neuronale Inferenz, Decode, NMS, Koordinatenskalierung und Anwendungslogik. Hersteller veröffentlichen oft nur den mittleren Inferenzschritt. MLPerf Inference Edge ist wertvoll, weil es Szenarien, Qualitätsziele und Regeln für Messungen auf Systemebene definiert, statt Marketing-Arithmetik isoliert zu vergleichen.

Für YOLO-Deployments sollte der minimale glaubwürdige Benchmarkbericht Folgendes enthalten:

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

Ohne diese Angaben messen zwei FPS-Zahlen meist unterschiedliche Dinge.

Eine NPU für Computer Vision auswählen

Entscheide in dieser Reihenfolge und nicht nach dem größten Wert auf einer Produktseite.

1. Graph-Kompatibilität belegen. Kompiliere genau das exportierte Modell, nicht einen ähnlich benannten Checkpoint aus einem Zoo.
2. Accuracy messen. Validiere das kompilierte Artefakt nach Kalibrierung und Quantisierung auf dem echten Aufgabedatensatz.
3. Ablauf vollständig messen. Berücksichtige Eingabekonvertierung, Transfers, Decode und NMS.
4. Softwarezugang prüfen. Kläre, ob der Compiler öffentlich, nur nach Registrierung oder nur über eine kommerzielle Vereinbarung erhältlich ist.
5. Versionsmatrix fixieren. Halte Compiler, Runtime, Treiber, Firmware und Zielkennungen fest.
6. Betriebssystemrealität prüfen. Android, Debian, Yocto, Buildroot, RTOS und Windows sind nicht austauschbar.
7. Lieferung und Lebenszyklus prüfen. Ein technisch hervorragender Chip eignet sich schlecht für die Produktion, wenn Module, Treiber oder Langzeitsupport unsicher sind.
8. Erst dann Kosten, Leistung und Performance vergleichen. Diese Messungen sind erst aussagekräftig, wenn dasselbe Modell auf beiden Zielen korrekt läuft.

Praktische erste Auswahl nach Anwendungsfall

Diese Tabelle ist eine Recherche-Auswahlliste, kein Leistungsranking. Beschaffung, regionale Verfügbarkeit und das genaue Modell können die Reihenfolge ändern.

Was das für LibreYOLO bedeutet

Die skalierbare Architektur besteht nicht aus Dutzenden unabhängigen Exportern. Sie braucht einen strikten Austauschvertrag und kleine Compiler- und Runtime-Adapter der Anbieter:

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

Jedes native Artefakt sollte ein Manifest mit folgenden Angaben erhalten:

• Anbieter, Chipziel und Boardziel
• Versionen von Compiler, Runtime, Treiber und Firmware
• Checksummen des Quell-Checkpoints und ONNX
• Eingabenamen, Formen, Layout, Farbraum, Normalisierung und Datentyp
• Quantisierungspräzision, verfügbare Skalen und Hash der Kalibrierungsdaten
• Ausgabetensor-Namen und -Formen sowie ihre semantische Bedeutung
• Erkennungsaufgabe, Klassennamen und Angabe, ob Decode/NMS auf dem Chip oder Host läuft
• Gemessene numerische Parität und Ergebnisse zur Accuracy der Aufgabe

LibreYOLO bietet bereits portablen ONNX-Export, Quantisierungstools, einen direkten, bewusst eng gefassten RKNN-Export und einen ehrlichen Ablauf mit externem Compiler für Hailo. Nach den Kriterien dieses Leitfadens ist Amlogic ADLA ein starker nächster Integrationskandidat: Das Toolkit ist öffentlich, die Modellabdeckung überschneidet sich stark mit LibreYOLO, und der ältere A311D-Pfad kann ausdrücklich getrennt bleiben.

Die Priorität nach Amlogic sollte sich an der Hardware der Nutzer und an der Möglichkeit zur Accuracy-Validierung orientieren, nicht allein an der Compilerverfügbarkeit. DEEPX, Sony IMX500, D-Robotics, AXERA, SOPHGO und Qualcomm sind technisch attraktiv. TI, NXP, ST und Renesas werden besonders wertvoll, wenn Industriepartner Boards und dauerhaften CI-Zugang bereitstellen können.

Beobachtungsliste: echtes Silizium ohne öffentlichen Integrationsvertrag

Ein Unternehmen ganz auszuschließen kann eine Marktübersicht verzerren. Es als „unterstützt“ einzubeziehen kann schlimmer sein. Diese Anbieter verkaufen, bemustern oder haben relevantes Silizium angekündigt. Die öffentlichen Belege weisen jedoch noch keinen reproduzierbaren aktuellen Compiler-, Artefakt- und Modellpfad mit konkreten Modellnamen nach, der sich für ein LibreYOLO-Backend eignet.

Diese Beobachtungsliste folgt bewusst der Evidenz. Ein Anbieter kann in die Tabellen für auslieferbare Produkte wechseln, wenn er eine aktuelle Toolchain oder Evaluierungsmöglichkeit, einen zielbezogenen Artefaktvertrag und mindestens ein benanntes Modell mit End-to-End-Rezept veröffentlicht.

Was bewusst nicht behauptet wird

Dieser Artikel behauptet nicht, dass jedes genannte Modell mit jedem Upstream-Repository funktioniert. Modelle in Vendor Zoos sind häufig angepasst, an anderen Ausgabeknoten aufgeteilt oder mit eigener Nachverarbeitung kombiniert.

Auch die folgenden Aussagen werden nicht als Support-Nachweis gewertet:

• Ein Compiler importiert ONNX.
• Ein Chip bewirbt einen Android-NNAPI-Treiber.
• Ein Distributor nennt ein Board „YOLO-kompatibel“.
• Ein Community-Repository führt einen Fork eines einzelnen Modells aus.
• Ein Modell lässt sich fehlerfrei kompilieren.
• Ein Hersteller meldet NPU-FPS ohne Accuracy-Ergebnis.

Google-Tensor-Beschleuniger in Smartphones und zahlreiche proprietäre OEM-ASICs existieren ebenfalls. Google bietet Tensor jedoch nicht als allgemeines Self-Service-Compilerziel vergleichbar mit den obigen Plattformen an. Die Existenz eines Unternehmens, ein NPU-Blockdiagramm oder Android-Beschleunigung reichen nicht aus, um eine LibreYOLO-Integrationsaussage zu erfinden.

Cloud-Beschleuniger wie Google TPU, AWS Inferentia/Trainium, Microsoft Maia und ausschließlich für Rechenzentren vorgesehene KI-Karten liegen ebenfalls außerhalb des Umfangs. Dieser Leitfaden behandelt Hardware, die ein Entwickler für Computer Vision plausibel am Edge einsetzen kann.

Die Modelllizenzierung ist eine separate Ebene. Wenn ein Chipanbieter ein YOLO-Konvertierungsrezept veröffentlicht, erteilt das keine Rechte an den Upstream-Gewichten, dem Trainingscode oder einem kompilierten Derivat. Für das vorgesehene Produkt müssen Hardwareunterstützung, SDK-Lizenz und Modelllizenz jeweils geprüft werden.

Forschungsmethodik und Korrekturen

Für jedes Unternehmen wurden vier Primärquellenbereiche gesucht:

1. Eine aktuelle Produktseite oder ein Datenblatt, das den Chip benennt.
2. Compiler- und Runtime-Dokumentation zum tatsächlichen Deploymentpfad.
3. Ein Model Zoo, eine Kompatibilitätstabelle oder ein End-to-End-Tutorial mit Vision-Modellen beim Namen.
4. Ein Signal zu Lebenszyklus oder Zugang, das zeigt, ob Entwickler die Tools tatsächlich erhalten können.

GitHub-Organisationen des Herstellers gelten als Herstellerquellen. Dokumentation des Boardanbieters wird als Ökosystembeleg gekennzeichnet, wenn der Chiphersteller das Material nicht selbst veröffentlicht. Leistungsangaben Dritter wurden aus den Vergleichstabellen ausgeschlossen.

Der fertige Entwurf wurde anschließend in getrennten Anbietergruppen- und tabellenübergreifenden Prüfungen erneut auditiert. Dabei wurden Zielumfang, Artefaktnamen, Präzision, Modell- gegenüber Postprozessor-Evidenz, angekündigter gegenüber ausgeliefertem Status, Lebenszyklusangaben, Benchmark-Nenner und sämtliche Unternehmenszahlen nochmals geprüft. Wenn sich zwei Primärquellen widersprechen, macht der Leitfaden den Konflikt sichtbar, statt stillschweigend den bequemeren Wert auszuwählen.

Dieser Markt verändert sich schnell. Wenn du für eines dieser Unternehmen arbeitest und ein Chip, SDK, eine Modellliste oder ein Zugangsstatus falsch ist, sende LibreYOLO die genaue URL zur öffentlichen Dokumentation samt Version. Korrekturen mit Primärquellenbeleg sollten diesen Text ersetzen; undokumentierte Marketingaussagen nicht.

FAQ

Wie viele Edge-AI-NPU-Unternehmen gibt es?

Eine allgemeingültige Zahl gibt es nicht, da Produkthersteller, IP-Lizenzgeber, intelligente Sensoren, GPUs und proprietäre Automotive-ASICs überlappen. Dieser nicht abschließende Leitfaden erfasst mit Stand August 2026 insgesamt 69 Unternehmen und Plattform-Ökosysteme mit relevanten Edge-AI-Chips, Beschleunigerplattformen, lizenzierbarer NPU-IP oder glaubwürdigen Kandidaten auf der Beobachtungsliste.

Was ist eine NPU?

Eine Neural Processing Unit ist spezialisierte Hardware für Operationen neuronaler Netze wie Faltungen und Matrixmultiplikationen. Hersteller verwenden unter anderem die Bezeichnungen NPU, AIPU, BPU, KPU, DLA, HTP, TPU und MLA. Kompilierte Modelle lassen sich in der Regel nicht zwischen Unternehmen übertragen.

Welche NPU-Unternehmen unterstützen YOLO-Modelle offiziell?

Amlogic, Hailo, Axelera AI, Rockchip, Qualcomm, MediaTek, DEEPX, D-Robotics, AXERA, SOPHGO, Huawei, Cambricon, Sony IMX500 über das offizielle AI-Camera-Repository von Raspberry Pi, STMicroelectronics, Renesas, Lattice, Himax, Microchip und mehrere weitere Unternehmen haben eigene Model-Zoo-Einträge, Tutorials oder validierte Ergebnisse für mindestens eine YOLO-Generation. Die konkrete Generation, Aufgabe, Chipziel und SDK-Version sind weiterhin entscheidend.

Lässt sich jedes ONNX-Modell auf jeder NPU ausführen?

Nein. ONNX ist ein Austauschformat und keine Garantie für Hardwarekompatibilität. Ein NPU-Compiler muss jeden Operator, jede Tensorform und jeden Datentyp im Graphen unterstützen. Statische Formen, Graph-Aufteilungen, benutzerdefinierte Operationen und ein CPU-Fallback sind häufig.

Welche NPU eignet sich am besten für YOLO?

Einen allgemeingültigen Sieger gibt es nicht. Hailo, Rockchip, Axelera AI, DEEPX und Amlogic bieten eine umfangreich dokumentierte YOLO-Unterstützung, während Qualcomm eine außergewöhnlich große Gerätebasis hat. Entscheide anhand der Accuracy nach der Quantisierung, der Latenz der gesamten Pipeline, der Dauerleistung, des Preises, der Verfügbarkeit, des SDK-Zugangs und der Betriebssystemunterstützung.

Warum lassen sich NPU-TOPS-Werte nicht direkt vergleichen?

Hersteller können unterschiedliche Präzisionen, Sparse-Operationen, Multiply-Accumulates und Annahmen zur Spitzenauslastung zählen. TOPS berücksichtigen weder Speicherverkehr noch nicht unterstützte Operatoren, Vorverarbeitung, Nachverarbeitung oder Host-Overhead. Vergleiche dasselbe Modell, dieselbe Präzision, Auflösung, Accuracy und vollständige Pipeline.

Was ist NPU-Kalibrierung?

Bei der Kalibrierung werden repräsentative, meist nicht annotierte Einsatzbilder durch das Modell geführt, damit der Compiler Aktivierungsbereiche für INT8 oder ein anderes Format mit niedriger Präzision schätzen kann. Zufällige oder nicht repräsentative Bilder können zwar ein kompiliertes Artefakt ergeben, aber die Accuracy für die Aufgabe verschlechtern.

Unterstützt LibreYOLO Edge-NPUs?

LibreYOLO exportiert ONNX und mehrere Runtime-Formate, bietet für ausgewählte Rockchip-Modelle einen direkten RKNN-Compilerpfad und dokumentiert den externen Hailo-Kompilierungsablauf. Für jedes andere herstellerspezifische Artefakt ist weiterhin das SDK des Herstellers nötig. Bis es kompiliert, validiert und auf Hardware ausgeführt wurde, sollte es als Integrationskandidat bezeichnet werden.