69 firm Edge AI NPU: układy, SDK i YOLO (2026)

Nie istnieje jeden rynek NPU. Ten niewyczerpujący przewodnik obejmuje 69 firm i ekosystemów platform: 51 dostawców układów lub platform gotowych do wdrożenia, dziewięciu dostawców IP NPU i dziewięć wyraźnie oznaczonych firm z listy obserwacyjnej. Obejmują one kilka niezgodnych ze sobą klas akceleratorów i niemal tyle samo stosów kompilatorów. Większość obiecuje podobny proces: wyeksportować model, skwantyzować go, skompilować, skopiować zastrzeżony artefakt na płytkę i wywołać środowisko uruchomieniowe dostawcy. Szczegóły decydują, czy zajmie to popołudnie, czy kwartał pracy inżynierskiej.

Ten przewodnik mapuje firmy oferujące wiarygodny sprzęt do wizji komputerowej w 2026 r. Zawiera odpowiednie układy, nazwy SDK i kompilatorów, artefakty wdrożeniowe, poziom publicznego dostępu oraz modele faktycznie opisane przez dostawcę. Szczególną uwagę poświęcono też Amlogic, którego nowszy stos ADLA istotnie różni się od starszego ekosystemu NPU A311D.

Zakres badań: Źródła sprawdzono 15 sierpnia 2026 r. Twierdzenia o nazwanych modelach pochodzą ze stron produktów, dokumentacji, katalogów modeli, repozytoriów lub samouczków dostawców, chyba że wyraźnie zaznaczono inaczej. Reklamowane wartości TOPS pochodzą od dostawców i nie są niezależnie porównywalnymi wynikami benchmarków. To przewodnik dla deweloperów, a nie porada inwestycyjna ani płatny ranking.

Szybka nawigacja: tabele firm | szczegółowo o Amlogic | profile dostawców | tabela skompilowanych artefaktów | dostęp i cykl życia | plan rozwoju LibreYOLO

Najważniejszy wniosek

Sprzęt jest rozdrobniony, ale schemat wdrażania pozostaje zaskakująco spójny:

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 jawnie dopuszcza środowiska uruchomieniowe, generatory kodu i implementacje sprzętowe, ale plik ONNX jest tylko formatem przekazania modelu. Nie oznacza to, że każdy operator ONNX zostanie obniżony do postaci obsługiwanej przez każdy akcelerator. O tym, co rzeczywiście działa na NPU, decydują statyczne kształty wejścia, ograniczenia obsługiwanych operatorów, reguły kwantyzacji i awaryjne wykonanie na hoście.

Stos programowy jest więc częścią układu. Nominalnie szybkie NPU z kompilatorem wymagającym specjalnego dostępu lub niestabilnym może być gorszym celem wdrożenia niż mniejsze urządzenie z publicznym łańcuchem narzędzi, katalogiem modeli, symulatorem i stabilnym środowiskiem uruchomieniowym.

Co oznacza „obsługa” w tym przewodniku

Materiały dostawców bardzo swobodnie posługują się słowem obsługa. W tym artykule wyróżniono cztery poziomy dowodów:

To rozróżnienie ma znaczenie. „Importuje ONNX” nie znaczy tyle samo co „obsługuje segmentację YOLO11”. Model może zostać wczytany, ale wykonywać się awaryjnie na CPU, kompilować z nieprawidłowymi wartościami wyjściowymi, przekroczyć pamięć akceleratora albo stracić dokładność podczas kwantyzacji.

Firmy i platformy NPU w skrócie

W tabelach celowo zestawiono SoC, dyskretne akceleratory, inteligentne sensory oraz powiązane cele GPU/FPGA. Konkurują o tę samą decyzję wdrożeniową, nawet jeśli dostawcy używają nazw NPU, AIPU, BPU, KPU, DLA, HTP, TPU lub MLA.

Wbudowane SoC, inteligentne sensory i procesory przemysłowe

Dedykowane akceleratory brzegowe i moduły

Powiązane platformy porównywane z NPU

Amlogic: dwie generacje NPU, a nie jedna

Amlogic wymaga dokładniejszego omówienia, ponieważ informacje w sieci często łączą niezgodne ze sobą produkty. Firma ma starszą ścieżkę opartą na VeriSilicon i nowszą, własną ścieżkę ADLA. Korzystają z innych kompilatorów, artefaktów i środowisk uruchomieniowych.

Arkusz danych A311D wskazuje pierwotne NPU INT8 o wydajności 5 TOPS. Starsza strona aplikacji Khadas VIM3 i omówienie NPU dokumentują DenseNet CTC, MTCNN, RetinaFace, YOLOFace, YOLOv2, YOLOv3, YOLOv3-tiny, YOLOv4, YOLOv7-tiny i YOLOv8n; omówienie dodatkowo dokumentuje YOLOv8n-pose i oznacza FaceNet jako przestarzały. To rzeczywiste przykłady, ale dotyczą starego ekosystemu Acuity .nb, a nie aktualnych układów ADLA. A311D to nie A311D2, a C305X to nie C305X2.

Jest też druga pułapka sprzętowa. Przewodnik po rewizjach Khadas VIM4 podaje, że pierwotna płyta V12/A311D2 w rewizji B nie ma NPU; reklamowane NPU 3.2 TOPS jest dostępne w płytach V13A i nowszych, używających układu A311D2-N0D w rewizji C. Sama nazwa produktu nie wystarcza do wyboru urządzenia testowego.

Aktualny stos AMLNN i ADLA

Aktualny AMLNN Toolkit obsługuje konwersję modeli, kwantyzację, kompilację, inferencję i profilowanie. Przypięty przewodnik użytkownika z maja 2026 r. dokumentuje import ONNX, zmiennoprzecinkowy lub skwantyzowany TFLite, TorchScript .pt i PyTorch 2 ExportedProgram/PT2. Szczegółowy przewodnik oznacza ścieżki TensorFlow, Paddle i Keras jako planowane, mimo szerszego opisu w omówieniu repozytorium. Kompilator tworzy .adla. Wdrożenie w Pythonie korzysta z AMLNN lub amlnn_edge_toolkit_lite; kod natywny C/C++ łączy libnnsdk.so przez nnsdk2.h. Programowanie po stronie hosta może wykorzystywać ADB z nnserver; środowisko uruchomieniowe działa też na Androidzie, Buildroot, Yocto i wybranych systemach Debian/Armbian.

Opublikowane identyfikatory platform toolchainu:

Pole celu nie jest kosmetyczne. Amlogic wymaga zgodności pliku .adla, nnsdk2.h, libnnsdk.so, BSP oraz generacji kompilatora/środowiska uruchomieniowego. Przypięty Quick Start wymaga sterownika ADLA 2.0.2 lub nowszego, NNSDK 3.0.0 lub nowszego i NNSDK2 1.0.0 lub nowszego; przewodnik wdrażania na Androidzie konkretnie opisuje relację biblioteki, nagłówka, sterownika i BSP. .adla należy traktować jako artefakt kompilacji związany z ABI, a nie przenośny model.

Kwantyzacja zależy też od generacji NPU. Cele ADLA2 001–006 dokumentują kompilację W8A8 i W8A16. Cele ADLA3 007 i 008 dodają kombinacje W4A8, W4A16, W8A8, W8A16 i W16A16 oraz natywną obsługę INT4, FP16 i BF16 w przewodniku operatorów. Amlogic zaleca 200–500 reprezentatywnych próbek kalibracyjnych. Opcja danych losowych jest przeznaczona wyłącznie do testów wydajności, a nie do kwantyzacji zachowującej dokładność.

Udokumentowane modele Amlogic

Przypięty model playground Amlogic jest znacznie mocniejszym dowodem niż ogólne twierdzenie o obsłudze ONNX. Opublikowana macierz obsługi/przykładów wymienia A311D2, S905X5, A311Y3, C305X2 i A123X. To, że kompilator akceptuje pozostałe identyfikatory celów, nie dowodzi, że cała ta lista modeli została na nich zweryfikowana.

To samo repozytorium publikuje poniższe wyniki W8A8 dla modelu i środowiska uruchomieniowego. Są to pomiary dostawcy dla sieci neuronowej na NPU, a nie kompletne potoki kamerowe.

Zastrzeżenia są tu wyjątkowo ważne. Przewodnik operatorów Amlogic umieszcza NMS w oprogramowaniu zarówno dla ADLA2, jak i ADLA3. README definiuje te pomiary jako wyniki natywnego modelu na NPU i pomija przetwarzanie wstępne oraz końcowe; nie ujawniono, czy uwzględniono wszystkie transfery pamięci. Wiersze dokładności YOLO wykorzystują podzbiory COCO liczące 300 obrazów, a wiersze klasyfikacji używają ImageNet val1000. Tabele podają też inną latencję YOLOv8n na A311Y3 niż tabela FPS, w warunkach, których repozytorium nie uzgadnia. Nie podano taktowania, trybu zasilania, chłodzenia, stanu ustalonego temperatury, dokładnej wersji SDK/BSP ani czasu testu. Wartości te służą do zrozumienia jednego stosu dostawcy, a nie do porównywania go z innym.

Dlaczego Amlogic jest interesujący strategicznie

Amlogic łączy cztery nietypowe cechy: szeroką obecność wbudowanych SoC, nowo upubliczniony stos kompilatora, aktualną macierz modeli mocno pokrywającą się z zadaniami LibreYOLO oraz niewielką liczbę integracji pierwszej klasy w głównych bibliotekach trenowania. Aktualne repozytoria są też młode: upubliczniono je pod koniec 2025 r. i na początku 2026 r., a obszerne instrukcje pochodzą z maja–lipca 2026 r. Oznacza to realną szansę na wczesną integrację oraz ryzyko niestabilnego API.

Dobra integracja powinna wykorzystywać deterministyczny eksport ONNX LibreYOLO jako wejście kompilatora, wymagać reprezentatywnych obrazów kalibracyjnych dla kompilacji o niskiej precyzji, tworzyć .adla wraz z manifestem metadanych i ładować model przez adapter NNSDK2. Starszy A311D powinien mieć wyraźnie odrębny cel .nb, ponieważ przedstawianie .nb i .adla jako jednego backendu powodowałoby ciche błędy zgodności. Repozytoria Amlogic mają główne licencje Apache-2.0, ale przed kopiowaniem przez LibreYOLO dołączonych pakietów wheel, bibliotek współdzielonych, nnserver i plików binarnych Android AAR należy bezpośrednio potwierdzić prawa do redystrybucji.

Najsilniejsze publiczne ekosystemy wdrożeniowe

Poniższe firmy oferują obecnie najbardziej przejrzyste połączenie dostępnego sprzętu, publicznych materiałów technicznych i dowodów dla nazwanych modeli. Nie oznacza to, że są zawsze szybsze. Ich deklaracje zgodności łatwiej ocenić przed zakupem sprzętu.

Hailo

Hailo jest przykładem dedykowanego ekosystemu akceleratorów wizji. Modele są parsowane do archiwum Hailo, optymalizowane i kwantyzowane na reprezentatywnych obrazach, a następnie kompilowane do pliku Hailo Executable Format (.hef). Aplikacje wczytują HEF przez HailoRT.

Hailo Model Zoo zawiera przepisy, wstępnie wytrenowane modele, konfiguracje postprocessingu i dane wydajnościowe dla detekcji, segmentacji, klasyfikacji, estymacji pozy i innych zadań. Obsługa YOLO obejmuje YOLOv3/v4/v5/v6/v7/v8/v9/v10/11/12 i YOLO26, a także YOLOX, DAMO-YOLO, SSD i EfficientDet. Przypięta wersją tabela detekcji obiektów Hailo-8 jest lepszym źródłem zgodności niż ogólna strona produktu, a samodzielna aplikacja opisuje wdrażalne potoki YOLO.

Istotna jest granica między wersjami. Hailo-8 i Hailo-8L korzystają ze starszej linii Model Zoo 2.x, Dataflow Compiler 3.x i HailoRT 4.x, natomiast Hailo-10 i Hailo-15 używają bieżącej generacji 5.x. Przepisy, zachowanie parsera i pliki HEF nie są wymienne tylko dlatego, że wszystkie urządzenia mają nazwę Hailo.

Hailo-15 ma też odrębną warstwę aplikacyjną. Używa Vision Processor Software Package i Hailo Media Library zamiast ścieżki hosta w stylu TAPPAS dla Hailo-8/10H. Publiczne repozytorium referencyjne hailo-camera-apps zarchiwizowano 3 maja 2026 r., a hailo-apps-core pozostaje osobnym publicznym frameworkiem aplikacji. Archiwizacja repozytorium nie dowodzi końca cyklu życia produktu, ale projekty Hailo-15 powinny potwierdzić w Developer Zone aktualny pakiet aplikacyjny.

Przewodnik wdrażania Hailo LibreYOLO celowo kończy się na statycznym przekazaniu ONNX, ponieważ zastrzeżonego kompilatora nie można dołączyć jako zależności Python. To uczciwa granica między przygotowaniem odpowiedniego grafu a deklarowaniem przetestowanego HEF.

Rockchip

Rockchip ma jeden z największych ekosystemów hobbystycznego i komercyjnego embedded Linux, zwłaszcza wokół płytek RK3588, RK3576 i RK356x. Publiczny RKNN-Toolkit2 konwertuje i kwantyzuje modele na hoście x86 z Linuxem, a RKNN Runtime lub Toolkit-Lite uruchamia wynikowy plik .rknn na płytce.

RKNN Model Zoo wyjątkowo jasno opisuje układy, rodziny modeli i precyzję. Aktualna tabela wymienia ścieżki FP16 i INT8 dla YOLOv5/6/7/8/10/11, YOLOX, PP-YOLOE, YOLO-World i wariantów segmentacji YOLOv5/v8; YOLOv8 OBB i YOLOv8 pose są wymienione wyłącznie dla INT8. Uwzględniono także OCR, twarze i inne sieci segmentacji.

LibreYOLO ma już zachowawczy, bezpośredni eksporter RKNN. Weryfikuje cztery konkretne warianty detekcji na RK3588, może porównać symulator kompilatora z ONNX Runtime i odrzuca nieweryfikowane rodziny zamiast utożsamiać udaną kompilację z poprawnymi predykcjami. To dobry wzorzec dla deklaracji obsługi w przyszłych backendach NPU.

Axelera AI

Axelera AI, często błędnie zapisywana jako „Accelera”, buduje AIPU Metis i sprzedaje go w produktach M.2, PCIe i wieloukładowych. Rodzina Metis jest dostępna w sprzedaży; Europa i Titania to zapowiedziane produkty, więc ich dostępności nie należy sprowadzać do jednego statusu. Voyager SDK jest publiczny na GitHubie i obsługuje wybór modelu, kompilację, kwantyzację, wykonanie i potoki aplikacji; wsparcie klienta nadal wymaga konta.

Publiczny Voyager Model Zoo należy do najbardziej informatywnych w branży. Wymienia wariant modelu, rozmiar wejścia, precyzję, dokładność i zmierzoną wydajność dla YOLOv3, YOLOv5, YOLOv7, YOLOv8, YOLOv9, YOLOv10, YOLO11, YOLO26 n/s/m/l/x, YOLOX, YOLO-NAS, OBB, estymacji pozy i segmentacji, a także wiele modeli klasyfikacji i predykcji gęstej. Publikowanie strat kwantyzacji i dokładności obok szybkości jest bardziej użyteczne niż podanie samego szczytowego TOPS.

Nazwy artefaktów zmieniły się wraz z generacją API. Przepływ kompilacji alpha Pipeline Builder tworzy model .axm i może spakować przenośny pipeline jako .axe. Dokumentacja klasycznego pipeline'u opisuje .axmodel wraz z metadanymi modelu i manifestem. Integracja powinna wykrywać zainstalowaną generację Voyager, zamiast na stałe zakładać jedno rozszerzenie.

Qualcomm

Qualcomm oferuje ogromny zasięg wdrożeniowy, ale określenie „NPU Qualcomm” ukrywa wiele interfejsów. Deweloperzy korzystają z Hexagon HTP przez QAIRT/QNN, starszej ścieżki SNPE, usług kompilacji Qualcomm AI Hub, LiteRT lub dostawcy wykonawczego QNN dla ONNX Runtime, zależnie od urządzenia i klasy produktu.

Oficjalne repozytorium Qualcomm AI Hub Models dostarcza mocnych dowodów na poziomie modeli. Publikuje zoptymalizowane pakiety YOLOv3, YOLOv5, YOLOv6, YOLOv7, YOLOv8, YOLOv9, YOLOv10, YOLO11, YOLO26 do detekcji/segmentacji/estymacji pozy, YOLOX, YOLO-World, YOLOR, RF-DETR oraz wiele modeli klasyfikacji, głębi i estymacji pozy. AI Hub udostępnia też profilowanie dla konkretnych urządzeń, co jest ważne, ponieważ model skompilowany dla jednej generacji HTP nie staje się automatycznie przenośny na inną.

Główny koszt integracji wynika z liczby kombinacji: Android kontra embedded Linux, części QCS kontra konsumencki Snapdragon, architektura HTP, wersja QNN/QAIRT i schemat kwantyzacji mają znaczenie. Aktualne strony Qualcomm są też sprzeczne w kwestii statusu Dragonwing IQ-9075: strona produktu określa go jako Active, a EVK jest dostępny do ewaluacji, natomiast Product Longevity Program nadal oznacza IQ-9075 jako Sampling i podaje trwałość do 2038 r. Prefiks SKU do zamówień to QCS9075; Qualcomm reklamuje konfiguracje 50 i 100 gęstych INT8 TOPS oraz obsługę Ubuntu/Yocto. Status produkcyjny trzeba potwierdzić dla konkretnego SKU, a integracja LibreYOLO powinna zapisywać ten SKU zamiast tworzyć ogólny katalog „Qualcomm”.

DEEPX

Akceleratory DX-M1/DX-M1M firmy DEEPX korzystają z DXNN SDK. DX-COM kompiluje i kwantyzuje model, DX-RT go uruchamia, a wdrażany artefakt ma format .dxnn. Firma publikuje DX-AllSuite, przykłady aplikacji w DX-APP i obszerny internetowy katalog modeli.

Podczas sprawdzania 15 sierpnia 2026 r. publiczny katalog podawał 354 wpisy dla DX-COM 2.4.0 i DX-RT 3.4.0. Udokumentowana obsługa obejmuje YOLOv3 do YOLO11 i YOLO26, YOLOX, SSD, EfficientDet, NanoDet, DAMO-YOLO, segmentację YOLO, estymację pozy i obrócone ramki. DEEPX jest szczególnie wiarygodnym kandydatem do integracji, ponieważ granice kompilatora i środowiska uruchomieniowego oraz artefakt wdrożeniowy mają jasno określone nazwy, a publiczna obsługa wizji jest szeroka.

Przemysłowe SoC to kilka ekosystemów, nie jeden

Dostawcy przemysłowi często oferują dłuższy cykl życia produktów oraz lepszą integrację kamer, bezpieczeństwa i czasu rzeczywistego niż SoC do płytek hobbystycznych. Ich stosy AI bywają bardziej złożone, bo jeden dostawca może jednocześnie oferować kilka niepowiązanych architektur NPU.

Texas Instruments

Aktualne procesory TI do Edge AI obejmują AM62A, AM67A, AM68A, AM69A i powiązane urządzenia TDA4. Ścieżka programowa łączy Processor SDK Linux, kompilator/środowisko uruchomieniowe TIDL, Edge AI TIDL Tools i Edge AI Model Zoo. TIDL może współpracować z ONNX Runtime, TensorFlow Lite i innymi środowiskami aplikacyjnymi, odciążając obsługiwane podgrafy.

TI publikuje więcej niż samo twierdzenie o imporcie frameworka: katalog zawiera przekonwertowane modele i metadane wydajności dla detekcji obiektów, segmentacji, estymacji pozy, klasyfikacji, głębi i innych zadań. TI zaznacza też, że artefakty z katalogu modeli są punktem wyjścia do prac deweloperskich, a nie automatycznie gotowymi zasobami produkcyjnymi. To cenne zastrzeżenie często pomijane w porównaniach dostawców.

TI wymienia również TDA54-Q1 jako Preview, z maksymalnie czterema NPU C7 i do 400 TOPS dla tej części; cała rodzina TDA5 jest reklamowana do 1 200 TOPS. To deklaracje dostawcy dotyczące nowej generacji, a nie podstawa do przeniesienia walidacji modeli TIDL z AM6xA/TDA4 na TDA54-Q1 przed publikacją macierzy dla konkretnego celu.

NXP

NXP wymaga co najmniej czterech opisów backendu:

eIQ Model Zoo zawiera zasoby lub przepisy dla YOLOv4-tiny, YOLOv8, NanoDet, CenterNet, FastestDet, SSD Lite, YOLACT i innych modeli; wpis YOLOv5 dodano wyłącznie jako dokumentację. Wpis zweryfikowany dla jednego backendu nie stanowi dowodu dla wszystkich czterech. Własne wskazówki NXP dotyczące eksportu YOLO dla platform i.MX pokazują problem konwersji zależnej od celu. NXP informuje, że monolityczny eIQ Toolkit przestał być aktualizowany po wersji 1.17 w Q3 2025; bieżące procesy korzystają z samodzielnych pakietów, takich jak eIQ Neutron SDK.

NXP ukończyło przejęcie Kinara w październiku 2025 r.. Arkusz informacyjny Ara240 podaje do 40 eTOPS deklarowanych przez dostawcę i wynik 313 obrazów na sekundę dla YOLOv8n. NXP wymienia Ara SDK i eIQ Toolkit na stronie produktu, ale nie dowodzi to wymienności artefaktów z odrębną ścieżką Neutron dla i.MX 95. Aktywny jest moduł M.2 16 GB, a opcja USB pozostaje przedprodukcyjna. NXP definiuje „e” w eTOPS jako „equivalent”, czyli „równoważny”, a nie „effective”; nie jest to miara gęstego INT8 TOPS innego dostawcy i nie należy jej porównywać bezpośrednio.

STMicroelectronics

Układy STM32N6x7, w tym STM32N657 i STM32N647, wprowadzają akcelerator Neural-ART 600 GOPS do produktów klasy MCU; linia uniwersalna N6x5 nie zawiera tego akceleratora. STM32Cube AI Studio i ST Edge AI Core analizują oraz optymalizują importowane modele, a STM32 AI Model Zoo Services udostępnia procesy wdrażania, optymalizacji, benchmarkowania i przykłady.

Aktualne omówienie detekcji obiektów dokumentuje Tiny YOLOv2, YOLOv5u, YOLOv8, YOLO11, YOLO26 i ST-YOLOX oraz usługi klasyfikacji, estymacji pozy i segmentacji. To inna klasa wydajności niż karta PCIe 200 TOPS. Platforma jest interesująca, ponieważ pobieranie obrazu z kamery, inferencja i sterowanie mogą działać w mocno ograniczonym budżecie mocy i pamięci.

Renesas

Procesory Renesas RZ/V integrują akceleratory DRP-AI. Oprogramowanie rozwijało się od DRP-AI Translator i DRP-AI TVM w kierunku RUHMI, opartego na technologii MERA firmy EdgeCortix. Otwarte repozytorium RZ/V DRP-AI TVM i lista walidacyjna RZ/V2H wymieniają warianty YOLOv5, YOLOv8, YOLO11 i YOLO26 n/s/m, YOLOX, estymację pozy i sieci segmentacji oraz modele klasyfikacji.

Renesas jest wiarygodnym celem dla robotyki i przemysłu, ale dla odtwarzalności trzeba zapisywać konkretną płytkę, generację DRP-AI, wersję translatora i postprocessing po stronie CPU.

Inteligentne sensory i procesory projektowane z myślą o kamerach

Sony IMX500

Sony IMX500 nie jest zwykłym procesorem aplikacyjnym. Łączy matrycę obrazową i przetwarzanie AI, dzięki czemu inferencja może odbywać się w sensorze, ograniczając ilość danych obrazu opuszczających kamerę. Raspberry Pi AI Camera sprawia, że ta architektura jest wyjątkowo dostępna.

Oficjalne repozytorium modeli Raspberry Pi IMX500 publikuje spakowane modele YOLOv8n, YOLO11n, EfficientDet Lite0, NanoDet+ i SSD MobileNetV2 FPN Lite. Dokumentacja AI Camera objaśnia konwersję, pakowanie i postprocessing w sensorze. Jednostką wdrożeniową jest pakiet RPK, a nie ogólny plik ONNX; istotnymi ograniczeniami są pamięć sensora i obsługiwane operatory. Strona produktu Raspberry Pi podaje, że kamera pozostanie w produkcji co najmniej do stycznia 2028 r.

Ambarella

Procesory CVflow firmy Ambarella są mocno ugruntowane w kamerach, dronach i wizji samochodowej. Aktualne rodziny produktów obejmują CV72/CV75 do kamer, CV5/CV52 do systemów wizji o wyższej wydajności i samochodowe układy CV3-AD. Cooper Developer Platform oraz przepływ kompilacji/środowiska uruchomieniowego CVflow tworzą nazwaną publicznie warstwę programową.

Publiczny katalog modeli dla deweloperów wymienia YOLOX, RTMDet, DeepLabV3+, TopFormer, OWL-ViT i modele multimodalne. Szczegółowa dokumentacja kompilatora i pliki do pobrania pozostają jednak skierowane do partnerów. Integrację Ambarella należy więc rozpocząć od relacji z dostawcą lub OEM, a nie od założenia, że dostępny jest publiczny pakiet pip.

Synaptics Astra

Synaptics ma trzy odpowiednie cele. Systemy Astra SL1600/SL1680 korzystają z SyNAP toolkit, który konwertuje model źródłowy wraz z opisem YAML do pakietu model.synap. Nowsze urządzenia SL2611/13/15/17/19 korzystają z platformy Torq, opartej na IREE/MLIR i tworzącej .vmfb. Seria SR100 to odrębna rodzina MCU z Cortex-M55 i Ethos-U55 oraz własnym SDK. Te artefakty i API nie są wymienne.

Oficjalny samouczek benchmarku YOLO jest wyjątkowo konkretny: eksportuje YOLOv8 do TFLite, wykonuje asymetryczną kalibrację UINT8 w SyNAP, kompiluje model dla SL1680, a następnie uruchamia synap_cli i aplikację detekcji obiektów. Potwierdza YOLOv8n/v8s na SL1680 i opisuje obsługę SyNAP do YOLO11. Osobny przewodnik detekcji obiektów SL261x uruchamia YOLOv8 z Torq .vmfb. Są to oficjalne przykłady dla konkretnych celów, a nie deklaracja, że każdy graf YOLO działa na wszystkich trzech rodzinach.

MediaTek Genio

MediaTek zasługuje na pełny wpis, ponieważ aktualny IoT AI Hub udostępnia już macierz sprzętu i oprogramowania, pakiety modeli i tabele benchmarków, które starsze przeglądy rynku trudno było zweryfikować. Genio 360/360P/420/520/720 używa NeuroPilot 8 z MDLA 5.3; Genio 510/700 używa NP6 z MDLA 3.0; Genio 1200 używa NP6 z MDLA 2.0. MediaTek informuje, że generacja NeuroPilot i MDLA, zestaw operatorów, kompilator i środowisko uruchomieniowe są powiązane wersją przez cały cykl życia danego SoC.

Ścieżka analitycznej AI opiera się na TFLite:

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

Nowsze produkty Genio udostępniają również delegowanie online LiteRT i ścieżkę ONNX Runtime CPU/NPU w obsługiwanych systemach operacyjnych. To inne tryby wykonania niż offline .dla. Przewodnik po architekturze oprogramowania i macierz zasobów wyraźnie rozróżniają te możliwości.

Oficjalna tabela modeli analitycznych publikuje wpisy benchmarków i przewodniki konwersji YOLOv5s i YOLOv8s dla wielu generacji MDLA. Jawnie nie udostępnia wstępnie przekonwertowanych artefaktów YOLO z powodu ograniczeń AGPL-3.0. Pomiary offline Quant8 przy 640 x 640 obejmują odpowiednio 5.35 ms i 8.04 ms na Genio 720. Strona modelu YOLOv8s publikuje tensory wejścia/wyjścia, czasy zależne od backendu i ostrzeżenia o niestandardowych operacjach MediaTek. Są to benchmarki dostawcy, a nie wyniki dla pełnego potoku kamery.

Ograniczeniem jest dostęp. Publiczna dokumentacja Yocto jest szczegółowa, ale aktualny pakiet NP8 all-in-one dla konwertera/kompilatora i wiele materiałów Android są oznaczone jako zasoby NDA lub dla bezpośrednich klientów. Zwykłe konto deweloperskie nie zapewnia takiego dostępu jak konto klienta MediaTek Online. LibreYOLO powinno więc traktować Genio jako platformę sprawdzoną technicznie, lecz wymagającą partnerstwa przy odtwarzalnej integracji kompilatora dla własnych modeli.

Ekosystemy Edge AI skoncentrowane na Chinach

Kilka najbardziej wydajnych i przystępnych cenowo platform wizyjnych jest słabo reprezentowanych w anglojęzycznych zestawieniach rynku.

D-Robotics i platformy BPU wywodzące się z Horizon

D-Robotics utrzymuje ekosystem płytek deweloperskich RDK wokół akceleratorów BPU stosowanych w RDK X3, X5, Ultra i nowszych produktach serii S100. Bieżąca gałąź rdk_x5 w RDK Model Zoo dokumentuje ścieżki YOLOv5/v5u, YOLOv8/9/10/11/12/13/26, YOLOE, YOLO-World, detekcję, segmentację, estymację pozy, klasyfikację, OCR i CLIP dla RDK X5. X3 korzysta z osobnej gałęzi, a bieżąca dostawa dla serii S znajduje się w gałęzi rdk_s głównego katalogu; starsze repozytorium rdk_model_zoo_s zawiera historyczne demonstracje. Nowa lista X5 nie dowodzi zatem, że każdy model zweryfikowano na X3, Ultra lub S100.

OpenExplorer/Algorithm Toolchain importuje ONNX lub Caffe do PTQ i obsługuje procesy QAT z PyTorch. Wdrożenie zależy od platformy: aktualny RDK X5 używa .bin przez hbm_runtime nad libdnn, a bieżąca podstawowa ścieżka rdk_s używa .hbm przez API o tej samej nazwie nad libhbucp; X3 zachowuje starszą gałąź i interfejsy inferencji. Starsze materiały rdk_model_zoo_s opisują też historyczne ścieżki .bin i .hbm, więc artefakty muszą pozostać powiązane z właściwą gałęzią i toolchainem. Nieobsługiwane operatory mogą być wykonywane na CPU. Publiczne przykłady są użyteczne, ale zgodność wersji RDK OS, firmware'u płytki, toolchainu i pliku modelu pozostaje częścią kontraktu.

AXERA

Rodziny AX650/AX630/AX620 firmy AXERA pojawiają się w kompaktowych kamerach AI i płytkach, takich jak linia MaixCAM firmy Sipeed. Pulsar2 importuje ONNX, wykonuje kalibrację i analizę precyzji, a następnie tworzy .axmodel; AXEngine uruchamia artefakt.

Oficjalne przykłady AXERA obejmują YOLOv5/6/7/8/9/10/11/13/26, YOLOX i YOLO-World, a obsługa zadań i układów zależy od platformy. W obsługiwanych celach aktualne przykłady YOLO26 obejmują detekcję, estymację pozy, segmentację i OBB. Przykłady konwersji Pulsar2 pokazują rzeczywistą pracę: dokładne nazwy tensorów, węzły wyjściowe, transformacje układu, archiwa kalibracyjne i ustawienia sprzętu docelowego.

SOPHGO

TPU-MLIR firmy SOPHGO to jeden z ciekawszych kompilatorów do niezależnej integracji, ponieważ sam kompilator jest open source. Importuje ONNX, PyTorch, TFLite i Caffe, obniża grafy, kwantyzuje je i tworzy .bmodel dla układów BM lub .cvimodel dla sprzętu CV18xx.

Projekt TPU-MLIR obsługuje procesy FP32, BF16, FP16 i INT8, zależnie od celu. Kolekcja demonstracji SOPHON wymienia YOLOv3/4/5/7/8/9/10/11/12/26, YOLOX, PP-YOLOE, YOLO-World, warianty OBB/segmentacji, SSD, CenterNet, RetinaFace, SAM/SAM2 i OCR. Demonstracja na BM1684X nie potwierdza działania tego samego artefaktu na BM1688 lub CV18xx.

Huawei Ascend

Linia układów brzegowych Huawei obejmuje krzem Ascend 310/310P/310B w produktach Atlas 200I i 300I. CANN udostępnia kompilator ATC, środowisko uruchomieniowe AscendCL i jądra operatorów zależne od układu; ATC przekształca ONNX i inne reprezentacje źródłowe w model offline .om.

Aktualna dokumentacja Atlas 200I DK A2 i przykłady CANN udostępniają ścieżkę YOLOv5 .om dla Ascend 310B. Szerszy, starszy Ascend ModelZoo zawiera YOLOv2/3/4/5, YOLOX, YOLOR, SSD, RetinaNet, Mask R-CNN, estymację pozy i modele segmentacji, ale nie należy przedstawiać go tak, jakby każdy wpis ponownie zweryfikowano na 310B. CANN, jądra, firmware i SoC muszą do siebie pasować. .om dla Ascend310P nie jest ogólnym artefaktem Ascend.

Cambricon

Akceleratory MLU firmy Cambricon korzystają z Neuware i silnika inferencji MagicMind. Publiczne repozytorium MagicMind Cloud jest przypięte do MagicMind 1.7 i macierzy MLU370-X4/S4; to historyczne potwierdzenie zgodności, a nie macierz aktualnego SDK lub walidacji MLU270. Repozytorium dokumentuje ścieżki PyTorch, ONNX, Caffe i Paddle; obsługę TensorFlow usunięto w wersji 1.7, choć zachowały się historyczne przykłady TensorFlow. Aktualny portal deweloperski serii 3 wymienia nowsze wydania SDK, więc publicznego repozytorium przykładów i bieżącego stosu komercyjnego nie należy łączyć w jedną wersję.

Oficjalne repozytorium modeli MagicMind Cloud publikuje wyjątkowo bezpośrednią macierz MLU370-X4/S4. Wymienia przykłady YOLOv3, Tiny-YOLOv3, YOLOv4, YOLOv5, YOLOv7, YOLOv8, PP-YOLOE, SSD, RetinaFace, RetinaNet, Mask R-CNN, DeepLab i UNet, w tym informację, czy istnieją przykłady C++ lub Python. Dowody są mocne; główną barierą pozostaje dostęp do SDK i kontenerów przez kanały Cambricon.

Canaan/Kendryte

Aktualne K230/K230D firmy Kendryte i starsze układy KPU K210/K510 są ważne w segmencie niedrogich płytek i inteligentnych kamer. Kompilator nncase importuje ONNX lub TFLite, używa danych kalibracyjnych do konwersji stałoprzecinkowej, symuluje wynik na hoście i tworzy .kmodel.

Oficjalny przewodnik deweloperski nncase dla K230 opisuje kompilację, symulację i uruchamianie YOLOv5s. Osobny katalog demonstracji AI zawiera artefakty YOLOv8n do detekcji, segmentacji i estymacji pozy, a aktualny dziennik zmian CanMV dodaje zoptymalizowane przykłady klasyfikacji, detekcji, segmentacji, OBB i estymacji pozy w YOLOv8/11/26. Wynik YOLOv5s w arkuszu danych to opublikowany benchmark; wersje kompilatora i binarnej wtyczki KPU muszą pasować do SDK płytki.

Allwinner

Allwinner V853 łączy sprzęt multimedialny przeznaczony do kamer z NPU Vivante o wydajności 1 TOPS. Oficjalny angielski przewodnik NPU opisuje import Acuity/Pegasus, kwantyzację, weryfikację i wdrożenie przez viplite. Własne strony modeli Allwinner i przewodnik YOLOv5 wymieniają YOLOv2/3/4/4-tiny/5/5s, RetinaNet, MobileNet, ResNet oraz sieci twarzy/osób.

To rzeczywista obsługa wizji komputerowej, ale nadal związana ze starszym toolchainem Tina Linux/Vivante i pobieraniem SDK zależnym od konta. Platforma należy do mapy rynku z widocznym tym ograniczeniem.

Pomijane platformy koreańskie, tajwańskie i chińskie

Anglojęzyczne listy często przechodzą od Rockchip do NVIDIA, pomijając drugą grupę rzeczywistych, udokumentowanych układów. Niektóre z tych ekosystemów mają szersze aktualne macierze YOLO niż lepiej znane zachodnie startupy.

Mobilint

Koreański dostawca akceleratorów Mobilint sprzedaje energooszczędny REGULUS i układ ARIES MLA100 o większej przepustowości. SDK qb przyjmuje dane wejściowe z PyTorch, TensorFlow, TFLite, ONNX i Keras, kwantyzuje je do INT8 i tworzy skompilowany artefakt .mxq. Publiczna macierz wizji wymienia detekcję YOLOv3/v5/v7/v8/v9/v10/11/12/26, a także warianty segmentacji, estymacji pozy i OBB. Strona ARIES publikuje nawet wyniki dla YOLO11s i YOLO26m. To mocny dowód integracji, choć dostęp do SDK/sprzętu jest komercyjny.

Sunplus

Sunplus SP7350/C3V używa stosu NPU wywodzącego się z Vivante, ale pakuje go inaczej niż Allwinner lub starszy Amlogic. Publiczny proces łączy konwersję Acuity, środowisko Docker NPU, środowisko uruchomieniowe SNNF i wynik .nb. Oficjalny przewodnik niestandardowego wdrożenia YOLOv8 opisuje konwersję i wdrożenie, zamiast tylko deklarować obsługę frameworka. Pokrewne IP nie czyni pliku .nb przenośnym między SoC opartymi na Vivante.

ESWIN Computing

Rodzina RISC-V ESWIN obejmuje EIC7700/EIC7700X i dwurdzeniowy EIC7702/EIC7702X; EIC7700 trafia do dostępnych w sprzedaży płytek takich jak Milk-V Megrez. ENNP zawiera EsQuant, aktualny kompilator EsAAC, generowanie danych referencyjnych, symulację i środowisko uruchomieniowe ESSDK, a jego skompilowanym wynikiem jest .model; starsze materiały ENNP używały nazwy ennc-compile. Aktualna strona EsAAC dokumentuje wejście ONNX, więc inne frameworki wymagają eksportu lub konwersji do obsługiwanego IR. Hostowane przez Milk-V omówienie ENNP i samouczek YOLOv3 pokazują publiczną ścieżkę od początku do końca, ale nie szeroką aktualną macierz modeli/dokładności.

Nuvoton M55M1

M55M1 firmy Nuvoton to konstrukcja klasy MCU z Cortex-M55 i Ethos-U55-256, a nie procesor aplikacyjny Linux. NuEdgeWise/NuML i Arm Vela przygotowują skwantyzowane modele TFLite Micro. Publiczne repozytorium NuEdgeWise wymienia YOLOv8-nano, YOLOX-nano, YOLO Fastest v1.1, SSD-MobileNet FPNLite i kilka klasyfikatorów. Te przykłady małych sieci są wiarygodnym dowodem dla klasy urządzeń o ograniczonej pamięci i mocy, a nie potwierdzeniem standardowych wariantów YOLO 640 pikseli.

Rebellions i FuriosaAI

Linia ATOM firmy Rebellions używa SDK RBLN i skompilowanych artefaktów .rbln. Oficjalne wydanie obsługi wymienia YOLOv3 tiny/full/SPP, YOLOv5 n–x, YOLOv6 n–l, warianty YOLOv7 i YOLOv8 n–x. Aktualna macierz obsługi kart oznacza ATOM CA02 i ATOM+ CA12 jako EoL, a ATOM+ CA22 i ATOM-Max CA25 jako Active. ATOM-Lite CA21 ma stronę produktu, ale brak go w macierzy SDK, więc status toolchainu jest niejasny. Dokumentacja jest publiczna, ale wheel kompilatora wymaga danych logowania Rebellions Portal.

FuriosaAI trzeba rozdzielić według generacji. Warboy to starszy akcelerator wizji z artefaktami INT8 .enf i oficjalnym katalogiem modeli obejmującym SSD, YOLOv5M/L i YOLOv7-w6-pose. RNGD korzysta z innego stosu .fxb, przeznaczonego głównie do obciążeń LLM/VLM. Aktualny plan rozwoju Furiosa odnotowuje ukończenie obsługi wizji YOLOv8m w 2024 Q4, ale bieżące publiczne zestawienia obsługiwanych modeli i wydajności koncentrują się na LLM/VLM i nie przedstawiają szczegółowej macierzy dokładności/wydajności YOLOv8m. To dowód dotyczący wydanej generacji, a nie potwierdzenie zgodności z Warboy.

Realtek, Telechips, T-Head i SigmaStar

Te cztery platformy są rzeczywiste, ale mają węższe, starsze lub ograniczone ścieżki dla modeli użytkownika:

Inteligentna wizja HiSilicon to nie Huawei Ascend

Układy kamerowe HiSilicon Hi3516CV610/DV500, Hi3519DV500 i Hi3403V100 udostępniają proces ATC do .om przez środowiska uruchomieniowe NNN/SVP-NNN. Oficjalny HiSpark model zoo wymienia YOLOv3/4/5/6/7/8/9/10/11, segmentację/estymację pozy YOLO11, OBB/World/segmentację YOLOv8, OCR, głębię i TinySAM w macierzy zależnej od celu, zwłaszcza dla Hi3403 i Hi3591P. Nie dowodzi to działania każdego wpisu na każdym wymienionym układzie do inteligentnej wizji. Część wpisów dotyczy planów rozwoju, więc wydane przykłady i planowaną obsługę należy rozdzielać; repozytorium podaje też, że udostępnione modele ModelZoo są przeznaczone wyłącznie do użytku niekomercyjnego. Wspólne nazwy ATC/.om nie potwierdzają zgodności artefaktów ani środowisk uruchomieniowych z linią Ascend opartą na CANN.

Nowe i wyspecjalizowane firmy akceleratorowe

MemryX

Moduły MX3 firmy MemryX używają architektury przepływu danych i mogą łączyć wiele układów. Neural Compiler przyjmuje modele ONNX, TensorFlow Lite, Keras i TensorFlow, a następnie tworzy pakiet DFP obsługiwany przez środowisko akceleratora. API środowiska uruchomieniowego obsługuje potoki wielomodelowe i streaming.

Dokumentacja i przykłady MemryX obejmują zoptymalizowane przetwarzanie wstępne i końcowe YOLO do detekcji, segmentacji i estymacji pozy. Informacje o wydaniach SDK jawnie wymieniają obsługę YOLOv10, YOLO11 i YOLO26. Publiczne materiały są technicznie użyteczne, choć nie ma jednej prostej tabeli modeli/dokładności/urządzeń porównywalnej z materiałami Axelera.

Kneron

Produkty KL520/KL530/KL630/KL720/KL730 firmy Kneron obejmują małe akceleratory USB i wbudowane. Kneron PLUS udostępnia środowisko uruchomieniowe aplikacji, a bieżący Model Toolchain 0.33.1 dokumentuje konwersję, kwantyzację, ewaluację, symulację i kompilację .nef dla tych celów. KL830 pojawia się w niektórych API środowiska uruchomieniowego PLUS, ale nie na aktualnej liście celów kompilatora; bez potwierdzenia dostawcy nie należy przypisywać ogólnej obsługi kompilacji .nef do KL830.

Oficjalny przykład YOLO pokazuje proces na Tiny-YOLOv3, a inne materiały Kneron obejmują trenowanie i wdrażanie YOLOv5. Dowody są wiarygodne, lecz węższe niż szerokie macierze współczesnych YOLO u Hailo, Axelera, Rockchip lub DEEPX.

SiMa.ai

MLSoC firmy SiMa.ai i produkcyjna platforma Modalix 50 TOPS korzystają ze środowiska Palette. ModelSDK, kompilator MLA i ModelExecutor obsługują import, kwantyzację, kompilację, profilowanie i wykonanie. Narzędzia obsługują procesy INT8, INT16 i zorientowane na BF16, zależnie od obciążenia i produktu.

Informacje o wydaniach firmy wymieniają zweryfikowane potoki YOLOv7, YOLOv8 do detekcji/estymacji pozy/segmentacji, YOLOX i segmentacji YOLOX, DETR, Mask R-CNN i EfficientDet. Nie należy ukrywać jednego aktualnego ograniczenia: informacje o Palette SDK 2.1 stwierdzają, że QAT nie działa z powodu regresji kwantyzacji Python/PT2E. Udokumentowanym obejściem jest utworzenie oznaczonego ONNX w SDK 2.0 i skompilowanie go w wersji 2.1. Dostęp i zakup są skierowane do przedsiębiorstw.

Udokumentowano też granicę wdrożenia: proces kompilacji ModelSDK tworzy skompilowany .tar.gz i może wygenerować wykonywalny ELF, a MPK Tool pakuje wdrażalny plik .mpk. Wyniki są powiązane z celem MLSoC/Modalix i wydaniem Palette.

EdgeCortix

SAKURA-II to reklamowany akcelerator 60 TOPS do wizji i generatywnej AI, kompilowany przez framework MERA. EdgeCortix dostarcza też technologię MERA do nowszego procesu RUHMI firmy Renesas.

Materiały produktu SAKURA-II potwierdzają sprzęt i kompilator, a sprzęt M.2/PCIe jest oferowany w ramach wersji próbnej lub zapytania o zakup. Nie znaleziono wystarczająco precyzyjnej, aktualnej publicznej macierzy zgodności YOLO. Ta luka jest przydatną informacją przy zakupie: przed wyborem sprzętu należy zażądać walidacji modelu.

BrainChip

Akida firmy BrainChip to neuromorficzny procesor domeny zdarzeń, a nie konwencjonalne NPU gęstych tensorów. Środowisko MetaTF składa się z instalowanych pakietów Python do tworzenia modeli, kwantyzacji niskobitowej, konwersji, symulacji i wykonywania na sprzęcie. BrainChip sprzedaje obecnie dostępny koprocesor AKD1500 w formacie M.2, obok starszego sprzętu AKD1000 i IP Akida 2.

Aktualna karta modelu Akida 2 wymienia detektor AkidaNet0.5 YOLOv2, CenterNet, AkidaUNet i sieci rozpoznawania twarzy. Inne materiały obsługi obejmują FOMO i obciążenia oparte na zdarzeniach. Akida obsługuje wyjątkowo niskobitowe wagi i aktywacje, ale wdrożenie może wymagać konwersji uwzględniającej architekturę zamiast traktowania go jak kolejnego ogólnego celu INT8 ONNX. Wyniku katalogu modeli AKD1000 lub Akida 2 nie należy przypisywać AKD1500, dopóki raport mapowania/dopasowania tego nie potwierdzi.

Blaize

Blaize sprzedaje produkty Pathfinder i Xplorer oparte na P1600; ścieżkę programową zapewniają Picasso SDK, NetDeploy i AI Studio. Strony produktów jasno wskazują wizję i Edge AI jako rynki docelowe, ale nie ma aktualnej, publicznej macierzy zgodności modeli.

Dlatego ten przewodnik klasyfikuje Blaize jako platformę komercyjną z ograniczonym dostępem, zamiast uzupełniać lukę twierdzeniami społeczności. Warunkiem wstępnym powinien być raport kompilacji i dokładności dostawcy dla planowanego modelu.

TinyML i wizja endpointów

Arm Ethos-U i Alif

Arm licencjonuje firmom układy IP NPU Ethos-U55, U65 i U85. Kompilator Vela przyjmuje skwantyzowane grafy LiteRT/TFLite i przekształca obsługiwane podgrafy w niestandardowe operacje Ethos-U. Nieobsługiwane operacje mogą pozostać na CPU, dlatego twierdzenia „aplikacja działa” i „cała sieć działa na NPU” oznaczają co innego.

Rzeczywiste implementacje obejmują Ethos-U55 w Alif Ensemble E7, Ethos-U65 w NXP i.MX 93 i Ethos-U85 w nowszych systemach. E7 AI/ML AppKit firmy Alif dokumentuje dwa akceleratory ML i pokazuje proces TFLite-do-Vela na E7; Ensemble E8 łączy jeden Ethos-U85 z dwoma NPU Ethos-U55. Alif publikuje też benchmark detektora twarzy YOLO-Fastest INT8 na poziomie rodziny, w rozdzielczości 192 na 192, dla Cortex-M55 z Ethos-U55, ale nie szeroką macierz współczesnego YOLO dla konkretnych celów. Te systemy o ograniczonej pamięci nadają się do małych sieci klasyfikacji i detekcji, a nie dowolnych detektorów 640 pikseli tylko dlatego, że da się je wyrazić w TFLite.

Infineon PSOC Edge, Himax WiseEye2 i Analog Devices MAX7800x

Rodziny PSOC Edge E83 i E84 firmy Infineon łączą Cortex-M55 z Ethos-U55 oraz dodają osobny blok NNLite po stronie energooszczędnego M33. Podręcznik architektury E84 opisuje 8-bitowe wagi, aktywacje 8- lub 16-bitowe i proces Vela, w którym obsługiwane operatory stają się strumieniem poleceń NPU, a nieobsługiwana praca pozostaje na CPU. DEEPCRAFT Model Converter przyjmuje modele TFLite oraz ścieżki Keras i PyTorch; materiały architektoniczne podają MobileNetV1/V2 jako przykładowe jądra, a nie benchmarki celów. Zestaw AI E84 zawiera kamerę i korzysta z ModusToolbox, ale publiczne materiały nie dostarczają jeszcze macierzy zgodności nazwanych modeli YOLO. To rzeczywista programowalna platforma wizyjna z rozwijającymi się dowodami na poziomie modeli, a nie zweryfikowany cel detekcji ogólnego przeznaczenia.

HX6538 WiseEye2 firmy Himax również łączy Cortex-M55 i Ethos-U55 dla wizji stale gotowej do działania. Publiczny zestaw oprogramowania jest wyjątkowo konkretny w tej klasie poboru mocy: oficjalne przykłady Grove Vision AI Module V2 obejmują detekcję obiektów YOLOv8n, estymację pozy i klasyfikację płci, detekcję YOLO11n, siatkę twarzy i PeopleNet. Wspólna ścieżka używa TFLite Micro i Vela, a następnie w razie potrzeby przechodzi na CMSIS-NN i jądra referencyjne. Są to celowo małe modele i rozdzielczości, a nie dowód, że mieści się tam standardowy graf YOLO.

Analog Devices stosuje inną metodę w akceleratorach CNN MAX78000/MAX78002. Publiczne narzędzie ai8x-synthesis kwantyzuje wytrenowaną sieć i generuje kod C zależny od celu, wagi i konfigurację akceleratora zamiast przenośnego pakietu środowiska ONNX. Dowody pierwszej strony obejmują identyfikację twarzy, wykrywanie kodów QR TinierSSD w katalogu modeli ADI i klasyfikatory obrazów. Urządzenia są istotne dla wizji endpointów, ale nie znaleziono aktualnej oficjalnej macierzy współczesnych modeli YOLO.

GreenWaves GAP9

GAP9 łączy obliczenia RISC-V z silnikiem neuronowym NE16. NNTool importuje i kwantyzuje sieci, a AutoTiler i GAP SDK generują wdrażalny kod. Publiczne menu sieci neuronowych GAP9 zawiera aplikacje MobileNet, EfficientNet, ResNet, MobileNet SSD oraz wykrywania i rozpoznawania twarzy. GreenWaves publikuje też projekt wykrywania osób YOLOX z wynikami dokładności i symulacji.

To wyjątkowo przejrzyste dowody TinyML, ale pełny SDK jest dostępny tylko dla zakwalifikowanych klientów, a modele są znacznie mniejsze niż popularne warianty YOLO 640 na 640.

Lattice sensAI

Lattice sensAI to oparta na FPGA alternatywa dla stałego NPU. sensAI Studio i Neural Network Compiler mapują obsługiwany graf na konfigurowalne IP akceleratora dla układów ECP5, iCE40 UltraPlus, CrossLink-NX, CertusPro-NX, Avant-E i Avant-X. Wynik jest związany z wybranym FPGA, trybem akceleratora, układem pamięci i bitstreamem, a nie przenośnym modelem środowiska uruchomieniowego.

Aktualny podręcznik Neural Network Compiler zawiera wyjątkowo bezpośrednią tabelę topologii. Wymienia YOLOv1 dla ECP5, YOLOv5 i YOLOv8 dla zoptymalizowanych/zaawansowanych trybów CrossLink-NX i CertusPro-NX, a YOLO11 wyłącznie z IP w trybie Advanced. Wymienia też SSD, MobileNetV2-SSD, ResNet, ENet, SqueezeDet i inne sieci wizji, pokazując nieobsługiwane komórki dla rodzin FPGA. Advanced CNN Accelerator jest przeznaczony dla Avant-E/Avant-X/CertusPro-NX i stanowi komercyjne IP. To dowód z tabeli kompilatora, a nie obietnica, że jeden bitstream obsłuży równocześnie każdą wymienioną topologię.

Microchip VectorBlox

Publiczny VectorBlox SDK 3.1 przygotowuje i kompiluje w pełni skwantyzowane sieci TFLite INT8 dla konfigurowalnego IP CoreVectorBlox w układach FPGA PolarFire SoC. tflite_preprocess i vnnx_compile tworzą zasoby wdrożeniowe .vnnx, .hex i .ucomp; repozytorium zawiera też symulator i sterownik C po stronie celu. Grafy TensorFlow, ONNX i OpenVINO nadal muszą przejść przez udokumentowany proces przygotowania TFLite/INT8.

Aktualna macierz samouczków obejmuje YOLOv5n, YOLOv8n do detekcji, klasyfikacji, OBB, estymacji pozy i segmentacji, YOLOv9t, rzadkie/skompresowane warianty YOLO, MobileNet, EfficientNet-Lite0, ResNet18, MiDaS, FFNet i QuickSRNet. Osobny przewodnik postprocessingu C wymienia YOLOv2/3/4/5 oraz dekodery detekcji, estymacji pozy i OBB Ultralytics. SDK 3.1 obsługuje obecnie PolarFire SoC Video Kit, a jawnie nie obsługuje PolarFire Video Kit bez SoC; starszych demonstracji płytek nie należy mylić z aktualnym kontraktem celu.

SDK jest publicznie dostępny na licencji właściwej dla Microchip, która ogranicza oprogramowanie i utwory pochodne do produktów Microchip. Microchip udostępnia bezpłatne, ale wymagające wniosku licencje Libero Silver i CoreVectorBlox. Wdrożenie nadal stanowi kontrakt całego systemu FPGA: konfiguracja akceleratora, bitstream, firmware, dane sieci wygenerowane przez SDK i układ pamięci muszą być zgodne. Udana kompilacja VectorBlox nie zmienia modelu w plik binarny, który można skopiować na dowolny projekt PolarFire.

Syntiant

NDP200 firmy Syntiant jest przeznaczony do inferencji wizji, audio i sensorów stale gotowej do działania, w budżecie mocy niższym niż zwykłe SoC Linux. Aktualna tabela sprzętu wymienia NDP200 jako produkowany seryjnie, a NDP250 jako próbkowany. Opis produktu NDP200 dokumentuje obsługę sieci CNN, RNN i w pełni połączonych przy poborze poniżej 1 mW; ogłoszenie NDP250 mówi natomiast o rozpoznawaniu obrazu stale gotowym do pracy przy poborze poniżej 30 mW. „Poniżej miliwata” nie powinno być uogólniane na oba układy.

Publiczne materiały nie potwierdzają szerokiej zgodności z YOLO, dlatego produkt należy oceniać pod kątem małych klasyfikatorów i detektorów stale gotowych do działania, korzystając z oceny modelu wspieranej przez dostawcę, a nie zakładając ogólną możliwość eksportu ONNX.

Google Coral: dwie niezwiązane ze sobą generacje

Starsze produkty Edge TPU używają Edge TPU Compiler, libedgetpu i PyCoral z w pełni kwantyzowanymi modelami TFLite INT8. Główne repozytoria Edge TPU i PyCoral są zarchiwizowane. To realne ryzyko utrzymania oprogramowania, ale nie formalne powiadomienie o końcu życia sprzętu.

Google utrzymuje też osobne, aktywne, otwarte Coral NPU: IP akceleratora RISC-V do integracji z energooszczędnymi SoC. Publiczny projekt udostępnia obecnie RTL, symulację sprzętu, toolchain i przykłady ELF. Nie jest to bezpośredni następca Edge TPU w formacie USB/M.2 i nie publikuje aktualnej macierzy wdrożeń YOLO.

Pułapki przy GPU, NPU klienckich i obliczeniach adaptacyjnych

NVIDIA, AMD, Intel i Apple często pojawiają się w wyszukiwaniach dotyczących NPU, ale nie udostępniają jednej, wymiennej klasy akceleratora.

NVIDIA Jetson: Jetson Orin łączy GPU CUDA z dedykowanymi rdzeniami DLA. TensorRT może zbudować serializowany silnik dla DLA, ale nieobsługiwane warstwy działają na GPU tylko wtedy, gdy jawnie włączono GPU fallback. Aktualna tabela YOLO DeepStream obejmuje YOLOv4/v7/v8/v9/11, ale większość wpisów dotyczy GPU; jedynym wymienionym jawnie celem ONNX DLA jest YOLOv8s INT8. Ograniczenia operatorów opisano w dokumentacji limitów DLA NVIDIA. Thor to odrębny przypadek: przewodnik migracji DriveOS NVIDIA podaje, że z Thor usunięto rdzenie DLA na rzecz elastycznego planowania na GPU. Informacja „działa na Jetsonie” nie wskazuje więc użytego akceleratora.

AMD Vitis AI: Starsza generacja Kria/DPU kompilowała grafy .xmodel wykonywane przez VART. Aktualny Vitis AI 6.2 ma status GA dla dwóch odrębnych ścieżek Versal AI Edge: Gen1 na VEK280/VE2802 korzysta z ONNX, AMD Quark i przepływu migawek/podgrafów związanych z celem; Gen2 na VEK385 ma własny kontrakt kompilacji i środowiska uruchomieniowego. Gen1 publikuje przykłady YOLOv5, YOLOv7, YOLOv8 i YOLOX. Ryzen AI to czwarty, osobny stos NPU klienckiego. Nie należy przenosić artefaktów ani walidacji między starszym DPU, Versal Gen1, Versal Gen2 i Ryzen AI tylko dlatego, że wszystkie używają nazwy Vitis lub AMD.

Intel OpenVINO: OpenVINO może kierować wykonanie na CPU, GPU i NPU Core Ultra przez jedno API. Dokumentacja wtyczki NPU Intel wskazuje obsługiwane generacje NPU, a macierz zweryfikowanych modeli pokazuje kolumny zależne od urządzenia. Notebook YOLO potwierdza przepis aplikacyjny, a nie walidację NPU, chyba że potwierdza ją macierz. Obsługiwane operacje, kształty, precyzja i zainstalowany sterownik NPU nadal decydują o tym, czy cały graf zostanie tam wykonany. OpenVINO IR (.xml plus .bin) jest wielokrotnego użytku na poziomie źródłowym; cache skompilowanego modelu zależy od urządzenia i oprogramowania.

Apple Core ML: coremltools konwertuje modele do .mlpackage, które Xcode kompiluje do .mlmodelc. Core ML może planować pracę na CPU, GPU i Apple Neural Engine, ale celowo ukrywa dokładny podział. Apple jest więc świetną platformą wdrożeniową, lecz nie uzasadnia twierdzenia, że „cały graf YOLO działał na NPU”, jeśli nie potwierdzają tego dane profilowania.

Firmy dostarczające IP NPU dla producentów układów

Niektóre firmy w ogóle nie sprzedają płytek ani gotowych akceleratorów. Licencjonują projekty NPU dostawcom SoC. Są istotne, bo ta sama architektura może pojawić się pod kilkoma markami układów, ale ostateczny SDK i artefakt mogą być zmodyfikowane przez licencjobiorcę.

Imagination pokazuje, dlaczego obok nazw architektur trzeba opisywać dostęp i cykl życia. Program Open Access oferuje trzy sprawdzone na krzemie konfiguracje Series3NX bez początkowej opłaty licencyjnej IP, ale dopiero po ocenie firmy oraz z płatnym wsparciem/utrzymaniem i tantiemami produkcyjnymi. Neural Compute SDK zapewnia narzędzia kompilacji, optymalizacji, kwantyzacji i środowiska uruchomieniowego; oficjalna współpraca z Baidu PaddlePaddle wymienia detekcję PP-YOLOE, klasyfikację EfficientNet i segmentację HRNet. Przykłady te nie weryfikują każdej konfiguracji Series3NX lub Series4, a aktualne indywidualne strony produktów Series4 oznaczają je jako niedostępne, więc należy traktować Series4 jako rozwiązania historyczne, chyba że dział sprzedaży potwierdzi inaczej.

Ta warstwa wyjaśnia pozorne podobieństwa rodzin. Nie zapewnia przenośności artefaktów. Dwa SoC zawierające pokrewne IP Vivante lub Ethos mogą mieć inne mapy pamięci, sterowniki, wersje kompilatora, zestawy operatorów i środowiska uruchomieniowe dostawców.

Co faktycznie się wdraża: tabela zależności artefaktów

Na końcu procesu kompilacji kończy się pozorna przenośność ONNX. Nazwy i rozszerzenia zmieniają się z czasem, ale praktyczna zasada pozostaje taka sama: należy zachować oryginalny model i dane kalibracyjne, ponieważ natywnego artefaktu zazwyczaj nie da się przenieść na inną generację NPU ani niezawodnie odtworzyć innym wydaniem SDK.

Ta tabela to więcej niż ściągawka z rozszerzeń plików. Wersja kompilatora, identyfikator celu, sterownik, firmware i BSP należą do odtwarzalnej tożsamości modelu. Przyszły eksporter LibreYOLO powinien zapisywać je w czytelnym maszynowo manifeście obok każdego artefaktu.

Dostęp do narzędzi i sygnały dotyczące cyklu życia

Dostępność sprzętu i dostęp do kompilatora to niezależne kwestie. Płytkę może być łatwo kupić, choć aktualny kompilator wymaga umowy z klientem; publiczne SDK może zaś dotyczyć trudno dostępnego krzemu. Poniższe informacje to konkretne sygnały ze źródeł dostawców, a nie uniwersalny ranking trwałości produktów.

Dlaczego TOPS nie jest przewodnikiem zakupowym

Szczytowe TOPS mogą być przydatne w ramach jednego dostawcy i architektury, ale porównania między dostawcami zwykle są nieważne, jeśli nie zgadzają się wszystkie poniższe warunki:

• Precyzja numeryczna, w tym INT8, INT4, FP16 lub tryb mieszany
• Czy jedno multiply-accumulate liczy się jako jedna, czy dwie operacje
• Obliczenia gęste czy strukturalnie rzadkie
• Rozdzielczość wejściowa, rozmiar batcha i graf modelu
• Dokładność po kwantyzacji
• Opóźnienie samego NPU czy całego potoku aplikacji
• Transfery pamięci i awaryjne wykonanie na hoście
• Stan termiczny oraz praca długotrwała, a nie krótkotrwała

Detektor działa w potoku: pobranie obrazu, zmiana rozmiaru/letterbox, normalizacja, transfer do urządzenia, inferencja sieci neuronowej, dekodowanie, NMS, skalowanie współrzędnych i logika aplikacji. Dostawcy często publikują jedynie wyniki dla środkowej części, czyli inferencji sieci. MLPerf Inference Edge jest wartościowy, ponieważ definiuje scenariusze, progi jakości i reguły pomiaru na poziomie systemu, zamiast porównywać w oderwaniu liczby z materiałów marketingowych.

Minimalny wiarygodny zapis benchmarku wdrożenia YOLO powinien zawierać:

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

Bez tych pól dwie wartości FPS zwykle mierzą różne rzeczy.

Jak wybrać NPU do wizji komputerowej

Wybór należy prowadzić w tej kolejności, a nie według największej liczby na stronie produktu.

1. Potwierdź zgodność grafu. Skompiluj dokładnie wyeksportowany model, a nie checkpoint z katalogu o podobnej nazwie.
2. Zmierz dokładność. Po kalibracji i kwantyzacji zweryfikuj skompilowany artefakt na zbiorze danych właściwym dla zadania.
3. Zmierz cały proces. Uwzględnij konwersję wejścia, transfery, dekodowanie i NMS.
4. Sprawdź dostęp do oprogramowania. Ustal, czy kompilator jest publiczny, wymaga rejestracji, czy jest dostępny tylko po zawarciu umowy komercyjnej.
5. Zamroź macierz wersji. Zapisz wersje kompilatora, runtime, sterownika, firmware i identyfikatory celów.
6. Sprawdź rzeczywistą obsługę systemów operacyjnych. Android, Debian, Yocto, Buildroot, RTOS i Windows nie są wymienne.
7. Sprawdź dostawy i cykl życia. Technicznie świetny układ to słaby wybór produkcyjny, jeśli dostępność modułów, sterowników lub długoterminowego wsparcia jest niepewna.
8. Dopiero potem porównaj koszt, moc i wydajność. Pomiary mają sens, gdy ten sam model działa poprawnie na obu celach.

Praktyczne punkty wyjścia zależnie od zastosowania

Ta tabela jest krótką listą badawczą, a nie rankingiem wydajności. Zakupy, dostępność regionalna i konkretny model mogą zmienić kolejność.

Co to oznacza dla LibreYOLO

Skalowalny projekt nie wymaga dziesiątek niezwiązanych ze sobą eksporterów. Powinien opierać się na jednym ścisłym kontrakcie wymiany oraz małych adapterach kompilatorów i środowisk uruchomieniowych dostawców:

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

Każdy natywny artefakt powinien mieć towarzyszący manifest zawierający:

• Dostawcę, cel układu i cel płytki
• Wersje kompilatora, runtime, sterownika i firmware
• Sumy kontrolne źródłowego checkpointu i ONNX
• Nazwy wejść, kształty, układ, przestrzeń kolorów, normalizację i typ danych
• Precyzję kwantyzacji, skale jeśli są dostępne, oraz hash danych kalibracyjnych
• Nazwy i kształty tensorów wyjściowych oraz ich znaczenie semantyczne
• Zadanie detekcji, nazwy klas i informację, czy dekodowanie/NMS odbywa się na układzie, czy po stronie hosta
• Zarejestrowane wyniki zgodności numerycznej i dokładności zadania

LibreYOLO udostępnia już przenośny eksport ONNX, narzędzia kwantyzacji, bezpośredni, ale celowo wąski eksport RKNN oraz uczciwy proces z zewnętrznym kompilatorem Hailo. Według kryteriów tego przewodnika mocnym kandydatem do następnej integracji jest Amlogic ADLA: toolkit jest publiczny, obsługa modeli w dużym stopniu pokrywa się z LibreYOLO, a starszą ścieżkę A311D można wyraźnie oddzielić.

Kolejny priorytet po Amlogic powinien zależeć od sprzętu użytkowników i możliwości walidacji dokładności, a nie tylko dostępności kompilatora. DEEPX, Sony IMX500, D-Robotics, AXERA, SOPHGO i Qualcomm są atrakcyjne technicznie; TI, NXP, ST i Renesas stają się szczególnie wartościowe, gdy partnerzy przemysłowi mogą zapewnić płytki i długoterminowy dostęp do CI.

Lista obserwacyjna: rzeczywisty krzem bez publicznego kontraktu integracji

Całkowite pominięcie firmy może zniekształcić mapę rynku. Oznaczenie jej jako „obsługiwanej” może być jeszcze gorsze. Ci dostawcy sprzedają, próbkują lub zapowiedzieli odpowiedni krzem, ale publiczne dowody nie potwierdzają jeszcze odtwarzalnej, aktualnej ścieżki kompilatora, artefaktu i nazwanego modelu, która nadawałaby się na backend LibreYOLO.

Lista obserwacyjna opiera się celowo na dowodach. Dostawca może trafić do tabel wdrażalnych platform, publikując aktualny toolchain lub ścieżkę ewaluacji, kontrakt artefaktu dla konkretnego celu oraz co najmniej jeden nazwany model z przepisem od początku do końca.

Czego celowo nie stwierdzono

Ten artykuł nie twierdzi, że każdy wymieniony model działa bez zmian z dowolnego repozytorium źródłowego. Modele z katalogów dostawców są często modyfikowane, dzielone w innych węzłach wyjściowych lub łączone z własnym postprocessingiem.

Poniższych stwierdzeń również nie uznano za deklaracje obsługi:

• Kompilator importuje ONNX.
• Układ reklamuje sterownik Android NNAPI.
• Dystrybutor twierdzi, że płytka jest „zgodna z YOLO”.
• Repozytorium społeczności uruchamia jedną wersję jednego forka modelu.
• Model kompiluje się bez błędu.
• Dostawca podaje FPS samego NPU bez wyniku dokładności.

Akceleratory w telefonach Google Tensor i liczne niestandardowe układy ASIC produkowane wyłącznie dla OEM także istnieją, ale Google nie udostępnia Tensor jako ogólnego celu kompilatora do samodzielnego użycia, porównywalnego z platformami powyżej. Samo istnienie firmy, schemat blokowy NPU lub akceleracja Androida nie wystarczają, aby wymyślić deklarację integracji LibreYOLO.

Podobnie akceleratory chmurowe, takie jak Google TPU, AWS Inferentia/Trainium, Microsoft Maia i karty AI przeznaczone wyłącznie do centrów danych, nie wchodzą w zakres. Ten przewodnik dotyczy sprzętu, który deweloper wizji komputerowej może realnie wdrożyć na brzegu sieci.

Licencjonowanie modelu to osobna kwestia. Opublikowanie przez dostawcę układu przepisu konwersji YOLO nie daje praw do używania ani redystrybucji źródłowych wag, kodu trenowania lub skompilowanej pochodnej. W konkretnym produkcie trzeba osobno sprawdzić obsługę sprzętu, licencję SDK i licencję modelu.

Metodyka badań i korekty

Dla każdej firmy szukano czterech typów źródeł pierwotnych:

1. Aktualnej strony produktu lub arkusza danych identyfikującego krzem.
2. Dokumentacji kompilatora i środowiska uruchomieniowego opisującej rzeczywistą ścieżkę wdrożenia.
3. Katalogu modeli, tabeli zgodności lub samouczka od początku do końca, które wymieniają modele wizji.
4. Sygnału dotyczącego cyklu życia lub dostępu, pokazującego, czy deweloperzy mogą faktycznie uzyskać narzędzia.

Oficjalne organizacje GitHub liczą się jako źródła dostawców. Dokumentację producentów płytek oznaczono jako dowody ekosystemu, gdy sam dostawca układu nie publikuje tych samych materiałów. Twierdzenia o wydajności ze źródeł zewnętrznych pominięto w tabelach porównawczych.

Następnie gotowy projekt ponownie sprawdzono w osobnych przeglądach grup dostawców i tabel przekrojowych. Ponownie zweryfikowano zakres celów, nazwy artefaktów, precyzję, dowody dla modeli kontra postprocessingu, status zapowiedzi kontra produktów dostępnych, oznaczenia cyklu życia, mianowniki benchmarków i liczbę wszystkich podmiotów. Gdy dwie strony dostawcy są sprzeczne, przewodnik pokazuje tę sprzeczność zamiast po cichu wybierać wygodniejszą wartość.

Rynek szybko się zmienia. Jeśli pracujesz w jednej z tych firm i układ, SDK, lista modeli lub status dostępu są opisane nieprawidłowo, prześlij LibreYOLO dokładny publiczny adres URL dokumentacji i wersję. Korekty poparte źródłami pierwotnymi powinny zastąpić ten tekst; nieudokumentowane twierdzenia marketingowe nie.

FAQ

Ile firm oferuje edge AI NPU?

Nie istnieje jedna uniwersalna liczba firm, ponieważ dostawcy produktów, licencjodawcy IP, inteligentne sensory, GPU i prywatne samochodowe układy ASIC nakładają się na siebie. Ten niewyczerpujący przewodnik obejmuje 69 firm i ekosystemów platform z odpowiednimi układami Edge AI, platformami akceleratorów, licencjonowanym IP NPU lub wiarygodnymi układami z listy obserwacyjnej według stanu na sierpień 2026 r.

Czym jest NPU?

Neural processing unit to wyspecjalizowany układ do operacji sieci neuronowych, takich jak sploty i mnożenie macierzy. Dostawcy używają nazw NPU, AIPU, BPU, KPU, DLA, HTP, TPU i MLA, a skompilowane modele na ogół nie są przenośne między firmami.

Które firmy oferujące NPU oficjalnie obsługują modele YOLO?

Amlogic, Hailo, Axelera AI, Rockchip, Qualcomm, MediaTek, DEEPX, D-Robotics, AXERA, SOPHGO, Huawei, Cambricon, Sony IMX500 za pośrednictwem oficjalnego repozytorium AI Camera firmy Raspberry Pi, STMicroelectronics, Renesas, Lattice, Himax, Microchip i kilka innych firm mają własne wpisy w katalogach modeli, samouczki lub zweryfikowane wyniki dla co najmniej jednej generacji YOLO. Nadal istotne są konkretna generacja, zadanie, układ docelowy i wersja SDK.

Czy dowolny model ONNX można uruchomić na dowolnym NPU?

Nie. ONNX jest formatem wymiany, a nie gwarancją zgodności ze sprzętem. Kompilator NPU musi obsługiwać każdy operator, kształt tensora i typ danych w grafie. Często stosuje się statyczne kształty, podział grafu, operacje niestandardowe i awaryjne wykonanie na CPU.

Które NPU jest najlepsze do YOLO?

Nie ma uniwersalnego zwycięzcy. Hailo, Rockchip, Axelera AI, DEEPX i Amlogic mają szeroką, udokumentowaną obsługę YOLO, a urządzenia Qualcomm są wyjątkowo rozpowszechnione. Wybór powinien uwzględniać dokładność po kwantyzacji, opóźnienie całego pipeline'u, moc przy długotrwałym obciążeniu, cenę, dostępność, dostęp do SDK i obsługę systemu operacyjnego.

Dlaczego wartości TOPS dla NPU nie są bezpośrednio porównywalne?

Dostawcy mogą inaczej liczyć precyzję, operacje rzadkie, operacje multiply-accumulate i założenia dotyczące szczytowego wykorzystania. TOPS pomija ruch danych w pamięci, nieobsługiwane operatory, przetwarzanie wstępne i końcowe oraz narzut hosta. Należy porównywać ten sam model, precyzję, rozdzielczość, dokładność i cały pipeline.

Na czym polega kalibracja NPU?

Podczas kalibracji reprezentatywne, zwykle nieoznaczone obrazy wdrożeniowe są przepuszczane przez model, aby kompilator mógł oszacować zakresy aktywacji dla INT8 lub innego formatu o niskiej precyzji. Losowe lub niereprezentatywne obrazy mogą nadal pozwolić utworzyć skompilowany artefakt, ale pogorszyć dokładność zadania.

Czy LibreYOLO obsługuje edge NPU?

LibreYOLO eksportuje ONNX i kilka formatów środowisk uruchomieniowych, ma bezpośrednią ścieżkę kompilacji RKNN dla wybranych modeli Rockchip i opisuje zewnętrzny proces kompilacji Hailo. Każdy inny natywny artefakt dostawcy nadal wymaga jego SDK i należy go traktować jako kandydata do integracji, dopóki nie zostanie skompilowany, zweryfikowany i uruchomiony na sprzęcie.