69 empresas de Edge AI com NPU: chips, SDKs e YOLO (2026)

Não existe um único mercado de NPU. Este guia não exaustivo acompanha 69 empresas e ecossistemas de plataforma: 51 fornecedores com chips ou plataformas para deploy, nove fornecedores de IP de NPU e nove empresas claramente identificadas em uma lista de observação. Eles abrangem várias classes incompatíveis de aceleradores e quase o mesmo número de pilhas de compilação. A maioria promete o mesmo caminho: exportar um modelo, quantizá-lo, compilá-lo, copiar um artefato proprietário para uma placa e chamar um runtime do fornecedor. Os detalhes determinam se esse caminho leva uma tarde ou um trimestre de engenharia.

Este guia mapeia as empresas que oferecem hardware de visão computacional confiável em 2026. Ele registra os chips relevantes, nomes de SDKs e compiladores, artefatos de deploy, nível de acesso público e modelos documentados pelo próprio fornecedor. Também dá atenção especial à Amlogic, cuja nova pilha ADLA difere bastante do ecossistema NPU mais antigo do A311D.

Escopo da pesquisa: as fontes foram verificadas em 15 de agosto de 2026. As afirmações sobre modelos específicos vêm de páginas de produtos, documentação, model zoos, repositórios ou tutoriais dos próprios fornecedores, salvo indicação explícita em contrário. Os valores de TOPS anunciados são números dos fornecedores, não resultados de benchmark comparáveis de forma independente. Este é um guia para desenvolvedores, não uma recomendação de investimento nem um ranking pago.

Navegação rápida: tabelas de empresas | análise aprofundada da Amlogic | perfis dos fornecedores | tabela de artefatos compilados | acesso e ciclo de vida | roteiro do LibreYOLO

A descoberta mais importante

O hardware é fragmentado, mas o padrão de deploy é surpreendentemente consistente:

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

O ONNX permite explicitamente runtimes, geradores de código e implementações de hardware, mas um arquivo ONNX é apenas o ponto de transferência. Isso não significa que todo operador ONNX possa ser mapeado para qualquer acelerador. Formatos estáticos de entrada, restrições de operadores suportados, regras de quantização e fallback no host determinam o que realmente roda na NPU.

Por isso, a pilha de software faz parte do chip. Uma NPU nominalmente rápida com um compilador restrito ou frágil pode ser um alvo de deploy pior do que um dispositivo menor com toolchain público, model zoo, simulador e runtime estável.

O que significa "com suporte" neste guia

A literatura dos fornecedores usa a palavra suporte de forma bastante vaga. Este artigo separa quatro níveis de evidência:

Essa distinção importa. "Importa ONNX" não equivale a "oferece suporte à segmentação do YOLO11". Um modelo pode ser analisado, mas cair para CPU, compilar com valores numéricos de saída incorretos, exceder a memória do acelerador ou perder acurácia durante a quantização.

Empresas e plataformas de NPU em resumo

As tabelas misturam intencionalmente SoCs, aceleradores discretos, sensores inteligentes e alvos próximos de GPU/FPGA. Eles concorrem na mesma decisão de deploy, mesmo quando os fornecedores usam nomes como NPU, AIPU, BPU, KPU, DLA, HTP, TPU ou MLA.

SoCs embarcados, sensores inteligentes e processadores industriais

Aceleradores e módulos edge dedicados

Plataformas adjacentes que desenvolvedores comparam com NPUs

Amlogic: duas gerações de NPU, não uma

A Amlogic merece uma explicação mais detalhada porque informações na web frequentemente misturam produtos incompatíveis. A empresa tem um caminho mais antigo baseado em VeriSilicon e um caminho proprietário ADLA mais recente. Eles não usam o mesmo compilador, artefato ou runtime.

A ficha técnica do A311D identifica a NPU original de 5-TOPS INT8. A antiga página de aplicações Khadas VIM3 e a visão geral da NPU documentam DenseNet CTC, MTCNN, RetinaFace, YOLOFace, YOLOv2, YOLOv3, YOLOv3-tiny, YOLOv4, YOLOv7-tiny e YOLOv8n; a visão geral também documenta YOLOv8n-pose e marca FaceNet como obsoleto. Esses exemplos são reais, mas evidenciam o antigo ecossistema Acuity .nb, não os chips ADLA atuais. A311D não é A311D2, e C305X não é C305X2.

Há também uma segunda armadilha de hardware. O guia de revisão da Khadas VIM4 diz que a placa original V12/A311D2 revisão B não tem NPU; a NPU anunciada de 3.2-TOPS aparece na V13A e nas placas posteriores que usam a peça A311D2-N0D revisão C. O nome de um produto, por si só, não basta para escolher um dispositivo de teste.

A pilha AMLNN e ADLA atual

O AMLNN Toolkit atual abrange conversão de modelos, quantização, compilação, inferência e profiling. Seu guia do usuário de maio de 2026, fixado em uma versão específica, documenta importadores para ONNX, TFLite de ponto flutuante ou quantizado, TorchScript .pt e PyTorch 2 ExportedProgram/PT2. Os caminhos TensorFlow, Paddle e Keras aparecem como planejados no guia detalhado, embora a visão geral do repositório use termos mais amplos. O compilador gera .adla. O deploy Python usa AMLNN ou amlnn_edge_toolkit_lite; o C/C++ nativo se vincula a libnnsdk.so por meio de nnsdk2.h. O desenvolvimento no host pode usar ADB com nnserver; o runtime também tem como alvo Android, Buildroot, Yocto e alguns ambientes Debian/Armbian.

Os identificadores de plataforma publicados pelo toolkit atualmente incluem:

Esse campo de alvo não é decorativo. A Amlogic exige correspondência entre .adla, nnsdk2.h, libnnsdk.so, BSP e geração do compilador/runtime. O Quick Start fixado em uma versão específica exige driver ADLA 2.0.2 ou superior, NNSDK 3.0.0 ou superior e NNSDK2 1.0.0 ou superior; o guia de deploy Android concretiza a relação entre biblioteca, header, driver e BSP. Trate .adla como um artefato de build vinculado à ABI, não como um modelo portável.

A quantização também depende da geração da NPU. Os alvos ADLA2 001 a 006 documentam compilação W8A8 e W8A16. Os alvos ADLA3 007 e 008 adicionam as combinações W4A8, W4A16, W8A8, W8A16 e W16A16, com suporte nativo a INT4, FP16 e BF16 no guia de operadores. A Amlogic recomenda de 200 a 500 amostras representativas para calibração. A opção de dados aleatórios é explicitamente voltada a testes de desempenho, não a uma quantização que preserve a acurácia.

Cobertura de modelos documentada pela Amlogic

O model playground Amlogic fixado em uma versão é uma evidência muito mais forte do que uma afirmação genérica de suporte a ONNX. Sua matriz publicada de suporte/exemplos cita A311D2, S905X5, A311Y3, C305X2 e A123X. A aceitação pelo compilador dos outros IDs de alvo não comprova que toda essa lista de modelos tenha sido validada neles.

O mesmo repositório publica os seguintes números de runtime de modelo W8A8. São medições do fornecedor da rede neural na NPU, não de pipelines completos de câmera.

As ressalvas são especialmente importantes. O guia de operadores da Amlogic posiciona NMS em software tanto no ADLA2 quanto no ADLA3. O README define esses resultados como medições nativas de runtime de modelo na NPU e exclui pré-processamento e pós-processamento; não informa se todas as transferências de memória estão incluídas. As linhas de acurácia YOLO usam subconjuntos COCO de 300 imagens, em vez do conjunto de validação completo, enquanto as linhas de classificação usam ImageNet val1000. As tabelas também mostram uma latência YOLOv8n no A311Y3 diferente da tabela de FPS, sob condições que o repositório não reconcilia. Clock, modo de potência, refrigeração, estado térmico estável, versão exata do SDK/BSP e duração do teste não são informados. Use os números para entender uma pilha de fornecedor, não para classificá-la frente a outra.

Por que a Amlogic é estrategicamente interessante

A Amlogic combina quatro características incomuns: uma grande presença em SoCs embarcados, uma pilha de compilação que se tornou pública recentemente, uma matriz atual de modelos que se sobrepõe bastante às tarefas do LibreYOLO e pouca integração de primeira classe em bibliotecas de treinamento populares. Os repositórios atuais também são novos: apareceram publicamente no fim de 2025 e em 2026, com manuais substanciais datados de maio a julho de 2026. Isso cria uma oportunidade real para chegar primeiro e também um risco correspondente de instabilidade da API.

Uma integração limpa deve usar a exportação ONNX determinística do LibreYOLO como entrada do compilador, exigir imagens de calibração representativas para builds de baixa precisão, produzir .adla com um manifesto de metadados e carregar o modelo por um adaptador NNSDK2. O A311D legado deve usar um alvo .nb claramente diferente, pois apresentar .nb e .adla como um único backend causaria falhas silenciosas de compatibilidade. Os repositórios da Amlogic têm licenças Apache-2.0 no nível superior, mas os direitos de redistribuição dos wheels, bibliotecas compartilhadas, nnserver e binários Android AAR incluídos devem ser confirmados diretamente antes de o LibreYOLO espelhá-los.

Os ecossistemas públicos de deploy mais fortes

Atualmente, as empresas a seguir oferecem a combinação mais clara de hardware disponível, material técnico público e evidências de modelos identificados. Isso não significa que sejam sempre mais rápidas. Significa que é mais fácil avaliar suas afirmações de compatibilidade antes de comprar hardware.

Hailo

A Hailo é um exemplo de referência de ecossistema dedicado a aceleradores de visão. Os modelos são analisados em um Hailo Archive, otimizados e quantizados com imagens representativas e então compilados em um arquivo Hailo Executable Format (.hef). As aplicações carregam esse HEF pelo HailoRT.

O Hailo Model Zoo contém receitas, modelos pré-treinados, configurações de pós-processamento e dados de desempenho para detecção, segmentação, classificação, pose e outras tarefas. A cobertura YOLO inclui YOLOv3/v4/v5/v6/v7/v8/v9/v10/11/12 e YOLO26, além de YOLOX, DAMO-YOLO, SSD e EfficientDet. A tabela de detecção de objetos Hailo-8, fixada em uma versão, é uma fonte de compatibilidade melhor do que uma página genérica de produto, enquanto a aplicação independente documenta pipelines YOLO implantáveis.

Há uma fronteira importante entre versões. Hailo-8 e Hailo-8L usam a linha antiga Model Zoo 2.x, Dataflow Compiler 3.x e HailoRT 4.x, enquanto Hailo-10 e Hailo-15 usam a geração atual 5.x. Receitas, comportamento do parser e HEFs não são intercambiáveis só porque os dispositivos têm o nome Hailo.

O Hailo-15 também tem uma camada de aplicação distinta. Ele usa o Vision Processor Software Package e Hailo Media Library, em vez do caminho de host no estilo TAPPAS do Hailo-8/10H. O repositório de referência público hailo-camera-apps foi arquivado em 3 de maio de 2026, enquanto hailo-apps-core continua sendo um framework de aplicação público separado. O arquivamento de um repositório não comprova o fim de vida do produto, mas projetos Hailo-15 devem confirmar o pacote de aplicação atual no Developer Zone.

O guia de deploy Hailo do LibreYOLO termina intencionalmente na transferência de um ONNX estático, pois o compilador proprietário não pode ser incluído como dependência Python. Esse é o limite honesto entre produzir um grafo adequado e afirmar que existe um HEF testado.

Rockchip

A Rockchip tem uma das maiores presenças em Linux embarcado entre makers e no setor comercial, especialmente por meio de placas RK3588, RK3576 e RK356x. O RKNN-Toolkit2 público converte e quantiza modelos em um host x86 Linux, e o RKNN Runtime ou Toolkit-Lite executa o arquivo .rknn resultante na placa.

O RKNN Model Zoo é excepcionalmente explícito sobre chips, famílias de modelos e precisão. Sua tabela atual lista caminhos FP16 e INT8 para YOLOv5/6/7/8/10/11, YOLOX, PP-YOLOE, YOLO-World e variantes de segmentação YOLOv5/v8; YOLOv8 OBB e YOLOv8 pose aparecem somente como INT8. Também cobre OCR, face e outras redes de segmentação.

O LibreYOLO já tem um exportador RKNN direto e conservador. Ele valida quatro variantes exatas de detecção no RK3588, pode comparar o simulador do compilador com o ONNX Runtime e rejeita famílias não validadas, em vez de equiparar uma compilação bem-sucedida a previsões corretas. Essa afirmação de suporte restrita é um bom modelo para todo futuro backend de NPU.

Axelera AI

A Axelera AI, cujo nome é frequentemente escrito errado como "Accelera", desenvolve o AIPU Metis e o vende em produtos M.2, PCIe e com vários chips. Metis é a família que pode ser encomendada publicamente; Europa e Titania são produtos anunciados para o portfólio, então sua disponibilidade não deve ser reduzida a um único status. O Voyager SDK está disponível publicamente no GitHub e gerencia seleção de modelos, compilação, quantização, execução e pipelines de aplicação; o suporte ao cliente ainda exige conta.

O Voyager Model Zoo público está entre os mais informativos do mercado. Ele lista variante do modelo, tamanho de entrada, precisão, acurácia e desempenho medido para YOLOv3, YOLOv5, YOLOv7, YOLOv8, YOLOv9, YOLOv10, YOLO11, YOLO26 n/s/m/l/x, YOLOX, YOLO-NAS, OBB, pose e segmentação, além de muitos modelos de classificação e predição densa. Publicar a perda de quantização e a acurácia ao lado da velocidade é mais útil do que publicar apenas um valor de TOPS de pico.

Os nomes dos artefatos mudaram com a geração da API. O fluxo de compilação alfa do Pipeline Builder gera um modelo .axm e pode empacotar um pipeline portável como .axe. A documentação do pipeline clássico descreve .axmodel com metadados e manifesto do modelo. Uma integração precisa detectar a geração instalada do Voyager, em vez de fixar uma única extensão.

Qualcomm

A Qualcomm oferece enorme alcance de deploy, mas "NPU Qualcomm" esconde várias interfaces. Desenvolvedores encontram o Hexagon HTP por meio de QAIRT/QNN, o fluxo SNPE mais antigo, serviços de compilação Qualcomm AI Hub, LiteRT ou o provedor de execução QNN do ONNX Runtime, dependendo do dispositivo e da categoria do produto.

O repositório oficial Qualcomm AI Hub Models é uma forte evidência no nível do modelo. Ele publica pacotes otimizados de detecção/segmentação/pose YOLOv3, YOLOv5, YOLOv6, YOLOv7, YOLOv8, YOLOv9, YOLOv10, YOLO11, YOLO26, além de YOLOX, YOLO-World, YOLOR, RF-DETR e muitos modelos de classificação, profundidade e pose. O AI Hub também oferece profiling específico por dispositivo, importante porque um modelo compilado para uma geração HTP não é automaticamente portável para outra.

O principal custo de integração é o tamanho da matriz: Android versus Linux embarcado, SKUs QCS sob encomenda versus Snapdragon de consumo, arquitetura HTP, versão QNN/QAIRT e esquema de quantização importam. As páginas atuais da própria Qualcomm também divergem sobre o status do Dragonwing IQ-9075: a página do produto marca Active e seu EVK pode ser avaliado, enquanto o Product Longevity Program ainda marca IQ-9075 como Sampling e lista longevidade até 2038. O prefixo do SKU para pedido é QCS9075; a Qualcomm anuncia configurações de 50 e 100 dense-INT8-TOPS e suporte Ubuntu/Yocto. Confirme o status de produção para o SKU exato e registre esse SKU em uma integração LibreYOLO, em vez de gerar uma pasta genérica chamada "Qualcomm".

DEEPX

Os aceleradores DX-M1/DX-M1M da DEEPX usam o DXNN SDK. O DX-COM compila e quantiza o modelo, o DX-RT o executa e o artefato de deploy usa o formato .dxnn. A empresa publica o DX-AllSuite, exemplos de aplicação no DX-APP e um grande Model Zoo online.

O catálogo público informava 354 entradas com DX-COM 2.4.0 e DX-RT 3.4.0 quando verificado em 15 de agosto de 2026. A cobertura documentada inclui YOLOv3 a YOLO11 e YOLO26, YOLOX, SSD, EfficientDet, NanoDet, DAMO-YOLO, segmentação YOLO, pose e caixas orientadas. A DEEPX é um alvo de integração especialmente plausível porque os limites entre compilador/runtime e o artefato de deploy têm nomes claros, e a cobertura pública de visão é ampla.

SoCs industriais são vários ecossistemas, não um só

Fornecedores industriais costumam ter ciclos de vida de produto mais longos e melhor integração de câmera, segurança e tempo real do que fabricantes de placas maker. Suas pilhas de IA podem ser mais complicadas porque um fornecedor pode disponibilizar simultaneamente várias arquiteturas NPU sem relação entre si.

Texas Instruments

Os processadores atuais da TI para edge AI incluem AM62A, AM67A, AM68A, AM69A e dispositivos TDA4 relacionados. O caminho de software combina Processor SDK Linux, compilador/runtime TIDL, Edge AI TIDL Tools e Edge AI Model Zoo. O TIDL pode se integrar ao ONNX Runtime, TensorFlow Lite e outros runtimes de aplicação, enquanto delega subgrafos compatíveis.

A TI publica bem mais do que uma afirmação de importação de framework: o zoo contém modelos convertidos e metadados de desempenho para detecção de objetos, segmentação, pose, classificação, profundidade e outras tarefas. A TI também alerta que os artefatos do model zoo servem como pontos de partida para desenvolvimento, não como assets automaticamente prontos para produção. Essa ressalva valiosa costuma faltar nas comparações entre fornecedores.

A TI também lista o TDA54-Q1 como Preview, com até quatro NPUs C7 e até 400 TOPS nesse componente; a família TDA5 mais ampla é anunciada com até 1,200 TOPS. Esses são números de produtos de uma nova geração divulgados pelo fornecedor, não autorização para transferir a validação de modelos TIDL AM6xA/TDA4 para o TDA54-Q1 antes que a TI publique uma matriz específica para esse alvo.

NXP

A NXP exige pelo menos quatro descrições de backend:

O eIQ Model Zoo contém assets ou receitas para YOLOv4-tiny, YOLOv8, NanoDet, CenterNet, FastestDet, SSD Lite, YOLACT e outros modelos; a entrada YOLOv5 foi adicionada somente como documentação. Uma entrada validada para um backend não comprova os outros três. As orientações de exportação YOLO para plataformas i.MX da própria NXP ilustram esse problema de conversão específica por alvo. A NXP informa que o eIQ Toolkit monolítico parou de receber atualizações após a versão 1.17 no terceiro trimestre de 2025; os fluxos atuais usam pacotes independentes, como eIQ Neutron SDK.

A NXP concluiu a aquisição da Kinara em outubro de 2025. A ficha técnica Ara240 anuncia até 40 eTOPS do fornecedor e relata 313 imagens por segundo para YOLOv8n. A NXP lista Ara SDK e eIQ Toolkit na página do produto, mas isso não estabelece intercâmbio de artefatos com o caminho separado i.MX 95 Neutron. O módulo M.2 de 16 GB está ativo, enquanto a opção USB está em pré-produção. A NXP define o "e" em eTOPS como "equivalent" (equivalente), não "effective" (efetivo); essa métrica não corresponde à de TOPS dense-INT8 de outro fornecedor e não deve ser comparada diretamente.

STMicroelectronics

Os dispositivos STM32N6x7, incluindo STM32N657 e STM32N647, levam um acelerador Neural-ART de 600-GOPS a um produto da classe MCU; a linha de uso geral N6x5 não inclui esse acelerador. O STM32Cube AI Studio e o ST Edge AI Core analisam e otimizam modelos importados, enquanto o STM32 AI Model Zoo Services oferece fluxos de deploy, otimização, benchmark e exemplos.

A visão geral atual de detecção de objetos documenta Tiny YOLOv2, YOLOv5u, YOLOv8, YOLO11, YOLO26 e ST-YOLOX, além de serviços de classificação, pose e segmentação. Essa não é a mesma classe de desempenho de uma placa PCIe de 200-TOPS. O interesse está em colocar entrada de câmera, inferência e controle em limites profundamente embarcados de potência e memória.

Renesas

Os processadores RZ/V da Renesas integram aceleradores DRP-AI. O software evoluiu de DRP-AI Translator e DRP-AI TVM para RUHMI, com tecnologia MERA da EdgeCortix. O repositório aberto RZ/V DRP-AI TVM e a lista de validação RZ/V2H citam variantes YOLOv5, YOLOv8, YOLO11 e YOLO26 n/s/m, YOLOX, pose e redes de segmentação, além de modelos de classificação.

A Renesas é um alvo confiável para robótica e indústria, mas a placa exata, geração DRP-AI, versão do translator e pós-processamento na CPU precisam ser registrados para garantir reprodutibilidade.

Sensores inteligentes e processadores voltados a câmeras

Sony IMX500

O IMX500 da Sony não é um processador de aplicação comum. Ele empilha processamento de imagem e IA para que a inferência ocorra no sensor, reduzindo a quantidade de dados de imagem que precisa sair da câmera. A Raspberry Pi AI Camera torna essa arquitetura especialmente acessível.

O repositório oficial de modelos Raspberry Pi IMX500 publica modelos empacotados YOLOv8n, YOLO11n, EfficientDet Lite0, NanoDet+ e SSD MobileNetV2 FPN Lite. A documentação AI Camera explica conversão, empacotamento e pós-processamento no sensor. A unidade de deploy é um pacote RPK, não um arquivo ONNX genérico, e a memória do sensor e as restrições de operadores são limites centrais do projeto. A página de produto da Raspberry Pi diz que esta câmera continuará em produção até pelo menos janeiro de 2028.

Ambarella

Os processadores CVflow da Ambarella estão consolidados em câmeras, drones e visão automotiva. As famílias atuais incluem CV72/CV75 para câmeras, CV5/CV52 para sistemas de visão de maior desempenho e dispositivos automotivos CV3-AD. A plataforma de desenvolvedor Cooper e o fluxo de compilação/runtime CVflow formam a pilha de software identificada publicamente.

O model garden público para desenvolvedores cita YOLOX, RTMDet, DeepLabV3+, TopFormer, OWL-ViT e modelos multimodais. Porém, a documentação detalhada do compilador e os downloads continuam voltados a parceiros. Uma integração Ambarella deve começar por uma relação com fornecedor ou OEM, não pela suposição de que existe um pacote pip público.

Synaptics Astra

A Synaptics tem três alvos relevantes. Os sistemas Astra SL1600/SL1680 usam o toolkit SyNAP, que converte um modelo de origem e uma descrição YAML em um pacote model.synap. Os dispositivos SL2611/13/15/17/19 mais novos usam a plataforma Torq, um fluxo baseado em IREE/MLIR que produz .vmfb. A série SR100 é uma família MCU separada, baseada em Cortex-M55 e Ethos-U55, com SDK próprio. Esses artefatos e APIs não são intercambiáveis.

O tutorial oficial de benchmark YOLO é especialmente concreto: exporta YOLOv8 para TFLite, faz calibração UINT8 assimétrica no SyNAP, compila para SL1680 e então executa synap_cli e a aplicação de detecção de objetos. Ele comprova YOLOv8n/v8s no SL1680 e descreve suporte SyNAP até YOLO11. Um guia separado de detecção de objetos SL261x executa YOLOv8 com Torq .vmfb. São exemplos oficiais específicos para cada alvo, não uma afirmação de que todos os grafos YOLO têm suporte nas três famílias.

MediaTek Genio

A MediaTek merece uma entrada completa porque seu IoT AI Hub atual agora expõe a matriz de hardware/software, pacotes de modelos e tabelas de benchmark que pesquisas antigas de mercado não conseguiam auditar. Genio 360/360P/420/520/720 usa NeuroPilot 8 com MDLA 5.3; Genio 510/700 usa NP6 com MDLA 3.0; Genio 1200 usa NP6 com MDLA 2.0. A MediaTek afirma que a geração NeuroPilot e MDLA, conjunto de operadores, compilador e runtime ficam vinculados por versão durante a vida útil de cada SoC.

O caminho de IA analítica é centrado em TFLite:

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

Os produtos Genio mais novos também oferecem delegação online LiteRT e um caminho ONNX Runtime CPU/NPU em sistemas operacionais compatíveis. Esses modos de execução são diferentes do .dla offline. O guia de arquitetura de software e a matriz de recursos deixam a distinção explícita.

A tabela oficial de modelos analíticos publica entradas de benchmark e guias de conversão para YOLOv5s e YOLOv8s em várias gerações MDLA. Ela declara explicitamente que não distribui artefatos YOLO pré-convertidos por causa das restrições AGPL-3.0. Suas medições offline Quant8, 640 x 640, incluem 5.35 ms e 8.04 ms, respectivamente, no Genio 720. A página do modelo YOLOv8s publica tensores de entrada/saída, tempos específicos por backend e alertas sobre operações personalizadas da MediaTek. Esses são benchmarks do fornecedor, não resultados de câmera de ponta a ponta.

O acesso é o fator limitante. A documentação pública Yocto é detalhada, mas o bundle atual NP8 all-in-one do conversor/compilador e boa parte do material Android aparecem como recursos NDA ou para clientes diretos. Uma conta normal de desenvolvedor não concede o mesmo acesso que uma conta MediaTek Online de cliente. Portanto, o LibreYOLO deve tratar Genio como tecnicamente comprovado, mas dependente de parceria para uma integração reproduzível de compilador com modelos próprios.

Ecossistemas de edge AI com foco na China

Várias das plataformas de visão mais capazes e acessíveis de baixo custo são pouco representadas em listas de mercado em inglês.

D-Robotics e plataformas BPU derivadas da Horizon

A D-Robotics mantém o ecossistema de placas de desenvolvedor RDK em torno de aceleradores BPU usados em produtos RDK X3, X5, Ultra e da série S100 mais recente. O branch rdk_x5 atual do RDK Model Zoo documenta caminhos de YOLOv5/v5u, YOLOv8/9/10/11/12/13/26, YOLOE, YOLO-World, detecção, segmentação, pose, classificação, OCR e CLIP para RDK X5. O X3 usa um branch separado, enquanto a entrega atual da série S está no branch rdk_s do zoo principal; o repositório antigo rdk_model_zoo_s contém demos históricas. Portanto, a lista moderna do X5 não comprova que todos os modelos foram validados no X3, Ultra ou S100.

OpenExplorer/Algorithm Toolchain importa ONNX ou Caffe para PTQ e oferece fluxos QAT voltados a PyTorch. O deploy varia por plataforma: o RDK X5 atual usa .bin via hbm_runtime sobre libdnn, enquanto o fluxo principal atual rdk_s usa .hbm via uma API hbm_runtime de mesmo nome sobre libhbucp; o X3 mantém seu branch e interfaces de inferência antigos. Materiais antigos de rdk_model_zoo_s também descrevem caminhos históricos .bin e .hbm, então esses artefatos precisam continuar associados ao branch e toolchain correspondentes. Operadores sem suporte podem cair para CPU. Os exemplos públicos são bons, mas o pareamento de versões entre RDK OS, firmware da placa, toolchain e binário do modelo continua fazendo parte do contrato de compatibilidade.

AXERA

As famílias AX650/AX630/AX620 da AXERA aparecem em câmeras de IA compactas e placas como a linha MaixCAM da Sipeed. O Pulsar2 importa ONNX, faz calibração e análise de precisão e gera .axmodel; o AXEngine executa o artefato.

Os exemplos oficiais AXERA cobrem YOLOv5/6/7/8/9/10/11/13/26, YOLOX e YOLO-World, com suporte a tarefas e chips variando por plataforma. Nos alvos compatíveis, os exemplos atuais de YOLO26 incluem detecção, pose, segmentação e OBB. Os exemplos de conversão Pulsar2 mostram o trabalho real: nomes exatos de tensores, cortes de saída, transformações de layout, arquivos de calibração e configurações do hardware alvo.

SOPHGO

O TPU-MLIR da SOPHGO é uma das pilhas de compilador mais atraentes para integração independente porque o próprio compilador é de código aberto. Ele importa ONNX, PyTorch, TFLite e Caffe, reduz e quantiza grafos e produz .bmodel para alvos BM ou .cvimodel para hardware CV18xx.

O projeto TPU-MLIR oferece fluxos FP32, BF16, FP16 e INT8 conforme o alvo. A coleção de demos SOPHON cita YOLOv3/4/5/7/8/9/10/11/12/26, YOLOX, PP-YOLOE, YOLO-World, variantes OBB/segmentação, SSD, CenterNet, RetinaFace, SAM/SAM2 e OCR. Como sempre, uma demo em BM1684X não valida o mesmo artefato em BM1688 ou CV18xx.

Huawei Ascend

A linha de inferência edge da Huawei inclui silício Ascend 310/310P/310B nos produtos Atlas 200I e 300I. O CANN fornece compilador ATC, runtime AscendCL e kernels de operadores específicos por chip; o ATC transforma ONNX e outras representações de origem em um modelo offline .om.

A documentação atual do Atlas 200I DK A2 e os exemplos CANN oferecem um caminho YOLOv5 .om para Ascend 310B. O Ascend ModelZoo mais amplo e antigo contém YOLOv2/3/4/5, YOLOX, YOLOR, SSD, RetinaNet, Mask R-CNN, pose e modelos de segmentação, mas não deve ser apresentado como se cada entrada tivesse sido revalidada no 310B. CANN, kernels, firmware e SoC precisam corresponder. Um .om para Ascend310P não é um artefato Ascend genérico.

Cambricon

Os aceleradores MLU da Cambricon usam Neuware e o engine de inferência MagicMind. O repositório público MagicMind Cloud está fixado em MagicMind 1.7 e em uma matriz MLU370-X4/S4; é evidência histórica de compatibilidade, não uma matriz do SDK atual ou validação MLU270. Esse repositório documenta caminhos PyTorch, ONNX, Caffe e Paddle; o suporte ao framework TensorFlow foi removido na versão 1.7, embora exemplos TensorFlow históricos continuem lá. O portal atual para desenvolvedores da série 3 lista versões gerais posteriores de SDK, portanto o repositório de exemplos público e a pilha comercial atual não devem ser apresentados como uma única versão.

O repositório oficial de modelos na nuvem MagicMind publica uma matriz MLU370-X4/S4 especialmente direta. Ela identifica exemplos YOLOv3, Tiny-YOLOv3, YOLOv4, YOLOv5, YOLOv7, YOLOv8, PP-YOLOE, SSD, RetinaFace, RetinaNet, Mask R-CNN, DeepLab e UNet, incluindo se existem exemplos C++ ou Python. A evidência é forte; a principal barreira é o acesso ao SDK e container pelos canais da Cambricon.

Canaan/Kendryte

Os chips KPU atuais K230/K230D e legados K210/K510 da Kendryte são importantes na faixa de placas e câmeras inteligentes de baixo custo. O compilador nncase importa ONNX ou TFLite, usa dados de calibração para conversão em ponto fixo, simula o resultado no host e gera .kmodel.

O guia de desenvolvimento nncase K230 oficial explica a compilação, simulação e execução de YOLOv5s. O catálogo separado de demos de IA inclui artefatos de detecção, segmentação e pose YOLOv8n, enquanto o changelog atual do CanMV adiciona exemplos otimizados YOLOv8/11/26 de classificação, detecção, segmentação, OBB e pose. O resultado YOLOv5s da ficha técnica é o benchmark publicado real; as versões do compilador e do plug-in KPU binário precisam corresponder ao SDK da placa.

Allwinner

O V853 da Allwinner combina hardware multimídia voltado a câmeras com uma NPU Vivante de 1-TOPS. O guia NPU oficial em inglês descreve importação Acuity/Pegasus, quantização, verificação e deploy por viplite. As páginas de modelos da Allwinner e o guia YOLOv5 citam YOLOv2/3/4/4-tiny/5/5s, RetinaNet, MobileNet, ResNet e redes de face/pessoa.

Isso é suporte real a visão computacional, mas continua vinculado à toolchain Vivante/Tina Linux mais antiga e a downloads do SDK que dependem de conta. Ele pertence ao panorama de mercado com essa limitação explícita.

Plataformas coreanas, taiwanesas e chinesas pouco conhecidas

Listas em inglês frequentemente passam direto de Rockchip para NVIDIA e deixam de fora uma segunda categoria de silício real e documentado. Alguns desses ecossistemas têm matrizes YOLO atuais mais amplas do que startups ocidentais mais conhecidas.

Mobilint

A Mobilint, fornecedora coreana de aceleradores, vende REGULUS de baixo consumo e ARIES MLA100 de maior throughput. Seu qb SDK aceita entradas PyTorch, TensorFlow, TFLite, ONNX e orientadas a Keras, quantiza para INT8 e gera o artefato compilado .mxq. A matriz de visão pública cita detecção YOLOv3/v5/v7/v8/v9/v10/11/12/26, além de variantes de segmentação, pose e OBB YOLO. A página ARIES também publica resultados específicos de YOLO11s e YOLO26m. É uma forte evidência de integração, embora o acesso ao SDK/hardware continue comercial.

Sunplus

O SP7350/C3V da Sunplus usa uma pilha NPU derivada de Vivante, mas empacota-a de forma diferente da Allwinner ou da Amlogic legada. O fluxo público combina conversão Acuity, ambiente Docker NPU, runtime SNNF e saída .nb. O guia oficial personalizado de YOLOv8 percorre conversão e deploy, em vez de apenas afirmar suporte ao framework. IP relacionado não torna o .nb portável para outro SoC baseado em Vivante.

ESWIN Computing

A família RISC-V da ESWIN inclui EIC7700/EIC7700X e EIC7702/EIC7702X de dois dies, sendo que o EIC7700 aparece em placas disponíveis como Milk-V Megrez. ENNP contém EsQuant, o compilador EsAAC atual, geração de dados de referência, simulação e runtime ESSDK, com saída .model; materiais antigos de ENNP usavam o nome ennc-compile. A página atual do EsAAC documenta entrada ONNX, então outros frameworks precisam ser exportados ou convertidos para essa IR suportada. A visão geral do ENNP hospedada pela Milk-V e o tutorial YOLOv3 estabelecem um caminho público completo, mas não uma matriz ampla e atual de modelos/acurácia.

Nuvoton M55M1

O M55M1 da Nuvoton é um projeto da classe MCU Cortex-M55 e Ethos-U55-256, não um processador de aplicação Linux. NuEdgeWise/NuML e Arm Vela preparam modelos TFLite Micro quantizados. O repositório público NuEdgeWise cita YOLOv8-nano, YOLOX-nano, YOLO Fastest v1.1, SSD-MobileNet FPNLite e vários classificadores. Esses exemplos de redes pequenas são evidências confiáveis para a classe de memória/potência do dispositivo, não para variantes YOLO padrão de 640 pixels.

Rebellions e FuriosaAI

A linha ATOM da Rebellions usa o RBLN SDK e artefatos compilados .rbln. Sua versão oficial de suporte cita YOLOv3 tiny/full/SPP, YOLOv5 n a x, YOLOv6 n a l, variantes YOLOv7 e YOLOv8 n a x. A matriz atual de suporte de placas marca ATOM CA02 e ATOM+ CA12 como fim de vida, enquanto ATOM+ CA22 e ATOM-Max CA25 estão ativos. ATOM-Lite CA21 tem página de produto, mas não aparece nessa matriz do SDK, então sua situação atual na toolchain não está clara. A documentação é pública, mas o wheel do compilador exige credenciais do Rebellions Portal.

A FuriosaAI precisa ser separada por geração. Warboy é o acelerador mais antigo para visão, com artefatos INT8 .enf e um model zoo oficial que contém SSD, YOLOv5M/L e YOLOv7-w6-pose. RNGD usa uma pilha .fxb diferente, voltada principalmente a cargas de trabalho LLM/VLM. O roadmap atual da Furiosa registra suporte a visão YOLOv8m concluído no quarto trimestre de 2024, mas suas superfícies públicas atuais de modelos suportados e desempenho continuam centradas em LLM/VLM e não expõem uma matriz detalhada de acurácia/desempenho para YOLOv8m. Isso é evidência de uma geração lançada, não uma afirmação de compatibilidade com Warboy.

Realtek, Telechips, T-Head e SigmaStar

Essas quatro plataformas são reais, mas oferecem superfícies mais estreitas, antigas ou restritas para usar modelos próprios:

Visão inteligente HiSilicon não é Huawei Ascend

Os SoCs de câmera Hi3516CV610/DV500, Hi3519DV500 e Hi3403V100 da HiSilicon expõem um fluxo ATC para .om por runtimes NNN/SVP-NNN. O model zoo oficial HiSpark cita YOLOv3/4/5/6/7/8/9/10/11, segmentação/pose YOLO11, OBB/World/segmentação YOLOv8, OCR, profundidade e TinySAM em uma matriz específica por alvo, especialmente para Hi3403 e Hi3591P. Isso não comprova que cada entrada rode em todos os SoCs de visão inteligente listados acima. Algumas entradas são itens do roadmap, então exemplos lançados e suporte planejado precisam continuar separados, e o repositório informa que seus modelos ModelZoo fornecidos são somente para uso não comercial. O vocabulário comum ATC/.om não comprova compatibilidade de artefato ou runtime com a linha Ascend baseada em CANN.

Empresas emergentes e especializadas em aceleradores

MemryX

Os módulos MX3 da MemryX usam uma arquitetura dataflow e podem combinar vários chips. O Neural Compiler aceita modelos ONNX, TensorFlow Lite, Keras e TensorFlow e gera um pacote DFP consumido pelo runtime do acelerador. Suas APIs de runtime oferecem suporte a pipelines com vários modelos e streaming.

A documentação e os exemplos MemryX incluem pré-processamento e pós-processamento YOLO otimizados para detecção, segmentação e pose. As notas de versão do SDK citam explicitamente suporte a YOLOv10, YOLO11 e YOLO26. O material público é tecnicamente útil, embora não tenha uma única tabela simples de modelo/acurácia/dispositivo comparável à da Axelera.

Kneron

Os produtos KL520/KL530/KL630/KL720/KL730 da Kneron abrangem pequenos aceleradores USB e embarcados. Kneron PLUS cobre o runtime de aplicação, enquanto a versão atual 0.33.1 do Model Toolchain documenta conversão, quantização, avaliação, simulação e compilação .nef para esses alvos. KL830 aparece em algumas APIs de runtime PLUS, mas não na lista atual de alvos do compilador; não transfira uma afirmação genérica de compilação .nef ao KL830 sem confirmação do fornecedor.

O exemplo YOLO oficial demonstra o processo com Tiny-YOLOv3, e outros materiais Kneron cobrem treinamento e deploy de YOLOv5. A evidência é confiável, mas mais restrita do que as matrizes modernas amplas de YOLO da Hailo, Axelera, Rockchip ou DEEPX.

SiMa.ai

O MLSoC da SiMa.ai e a plataforma Modalix de produção de 50-TOPS usam o ambiente de software Palette. ModelSDK, compilador MLA e ModelExecutor cobrem importação, quantização, compilação, profiling e execução. As ferramentas oferecem fluxos voltados a INT8, INT16 e BF16, conforme a carga de trabalho e o produto.

As notas de versão da empresa citam pipelines validados YOLOv7, detecção/pose/segmentação YOLOv8, YOLOX e segmentação YOLOX, DETR, Mask R-CNN e EfficientDet. Uma limitação atual não deve ser omitida: as notas da Palette SDK 2.1 dizem que QAT não funciona por causa de uma regressão de quantização Python/PT2E. A solução alternativa documentada é criar o ONNX anotado no SDK 2.0 e compilá-lo com 2.1. Acesso e aquisição continuam voltados a empresas.

O limite de deploy também está documentado: o fluxo de compilação ModelSDK gera um .tar.gz compilado e pode produzir um ELF executável, enquanto o MPK Tool empacota um .mpk implantável. Essas saídas continuam vinculadas ao alvo MLSoC/Modalix e à versão Palette.

EdgeCortix

SAKURA-II é um acelerador anunciado em 60-TOPS para visão e IA generativa, compilado pelo framework de software MERA. A EdgeCortix também fornece a tecnologia MERA para o fluxo RUHMI mais recente da Renesas.

O material do produto SAKURA-II estabelece o hardware e o compilador, e o hardware M.2/PCIe é oferecido por consulta de teste ou pedido. Não foi encontrada uma matriz pública atual de compatibilidade YOLO suficientemente precisa. Essa ausência é informação útil para a compra: deve-se solicitar validação do modelo antes de se comprometer com o hardware.

BrainChip

O Akida da BrainChip é um processador neuromórfico de domínio de eventos, não uma NPU convencional de tensores densos. O ambiente MetaTF consiste em pacotes Python instaláveis para criação de modelos, quantização de baixa precisão, conversão, simulação e execução no hardware. A BrainChip agora vende um coprocessador AKD1500 em formato M.2 disponível para envio, além do hardware AKD1000 legado e IP Akida 2.

O cartão de modelo Akida 2 atual cita um detector YOLOv2 AkidaNet0.5, CenterNet, AkidaUNet e redes de reconhecimento facial. Outros materiais de suporte incluem FOMO e cargas de trabalho baseadas em eventos. O Akida oferece suporte a pesos e ativações de precisão excepcionalmente baixa, mas um deploy bem-sucedido pode exigir conversão ciente da arquitetura, em vez de tratá-lo como mais um alvo genérico ONNX INT8. Um resultado de model zoo para AKD1000 ou Akida 2 não deve ser atribuído ao AKD1500 até que um relatório explícito de mapeamento/ajuste o valide.

Blaize

A Blaize vende produtos Pathfinder e Xplorer baseados em P1600, com Picasso SDK, NetDeploy e AI Studio oferecendo o caminho de software. As páginas de produtos visam claramente visão e edge AI, mas não há uma matriz pública atual de compatibilidade modelo a modelo.

Por isso, este guia classifica a Blaize como comercial e restrita, em vez de preencher a lacuna com afirmações da comunidade. Um relatório de compilação e acurácia fornecido pelo fornecedor para o modelo pretendido deve ser um pré-requisito.

TinyML e visão em dispositivos de endpoint

Arm Ethos-U e Alif

A Arm licencia IP NPU Ethos-U55, U65 e U85 para empresas de chips. O compilador Vela recebe grafos LiteRT/TFLite quantizados e reescreve subgrafos suportados em operações personalizadas Ethos-U. Operações sem suporte podem permanecer na CPU; portanto, "a aplicação executa" e "a rede inteira executa na NPU" são afirmações diferentes.

Implementações reais incluem Ethos-U55 no Alif Ensemble E7, Ethos-U65 no NXP i.MX 93 e Ethos-U85 em sistemas mais novos. O E7 AI/ML AppKit da Alif documenta dois aceleradores de ML e demonstra o fluxo E7 de TFLite para Vela; o Ensemble E8 combina um Ethos-U85 com duas NPUs Ethos-U55. A Alif também publica um benchmark de detector de faces YOLO-Fastest INT8 no nível da família, em 192 por 192 no Cortex-M55 mais Ethos-U55, mas não uma matriz ampla de YOLO moderno por alvo. Esses sistemas com memória limitada servem para redes pequenas de classificação e detecção, não para detectores arbitrários de 640 pixels só porque podem ser expressos em TFLite.

Infineon PSOC Edge, Himax WiseEye2 e Analog Devices MAX7800x

As famílias PSOC Edge E83 e E84 da Infineon combinam Cortex-M55 e Ethos-U55 e acrescentam um bloco NNLite separado no lado M33 de baixo consumo. O manual de arquitetura E84 documenta pesos de 8 bits, ativações de 8 ou 16 bits e um fluxo Vela no qual operadores suportados viram um fluxo de comandos da NPU, enquanto operações sem suporte continuam na CPU. O DEEPCRAFT Model Converter aceita TFLite e caminhos Keras e PyTorch, enquanto o material de arquitetura cita MobileNetV1/V2 como kernels representativos, não benchmarks para o alvo. O E84 AI Kit inclui uma câmera e usa ModusToolbox, mas o material público ainda não fornece uma matriz de compatibilidade YOLO identificada por modelo. É uma plataforma programável real para visão com evidências de modelo em desenvolvimento, não um alvo validado para detectores de uso geral.

O HX6538 WiseEye2 da Himax também combina Cortex-M55 e Ethos-U55 para visão sempre ativa. Sua oferta pública de software é especialmente concreta para essa classe de potência: os exemplos oficiais Grove Vision AI Module V2 incluem detecção de objetos, pose e classificação de gênero YOLOv8n, detecção YOLO11n, face mesh e PeopleNet. O caminho unificado usa TFLite Micro e Vela, com fallback para CMSIS-NN e kernels de referência quando necessário. São modelos e resoluções deliberadamente pequenos, não evidência de que um grafo YOLO convencional de tamanho de servidor caiba.

A Analog Devices segue outro caminho com os aceleradores CNN MAX78000/MAX78002. A ferramenta pública ai8x-synthesis quantiza uma rede treinada e gera código C específico do alvo, pesos e configuração do acelerador, em vez de um pacote portável de runtime ONNX. A evidência própria inclui identificação facial, detecção QR TinierSSD no model zoo da ADI e classificadores de imagem. Os dispositivos são relevantes para visão de endpoint, mas não foi encontrada uma matriz oficial atual de YOLO moderno.

GreenWaves GAP9

O GAP9 combina processamento RISC-V com o engine neural NE16. O NNTool importa e quantiza redes, enquanto AutoTiler e GAP SDK geram código implantável. O menu de redes neurais GAP9 público contém MobileNet, EfficientNet, ResNet, MobileNet SSD, face e aplicações de reconhecimento. A GreenWaves também publica um projeto de detecção de pessoas YOLOX com resultados de acurácia e simulação.

Essa é uma evidência TinyML excepcionalmente transparente, mas o SDK completo só está disponível para clientes qualificados e os modelos são bem menores que as variantes YOLO populares de 640 por 640.

Lattice sensAI

O Lattice sensAI é uma alternativa baseada em FPGA a uma NPU fixa. O sensAI Studio e o Neural Network Compiler mapeiam um grafo suportado para IP acelerador configurável nos dispositivos ECP5, iCE40 UltraPlus, CrossLink-NX, CertusPro-NX, Avant-E e Avant-X. A saída depende do FPGA selecionado, modo do acelerador, layout de memória e bitstream, em vez de ser um modelo de runtime portável.

O manual atual do Neural Network Compiler inclui uma tabela de topologias especialmente direta. Ela lista YOLOv1 para ECP5, YOLOv5 e YOLOv8 nos modos otimizado/avançado de CrossLink-NX e CertusPro-NX e YOLO11 somente com IP Advanced. Também lista SSD, MobileNetV2-SSD, ResNet, ENet, SqueezeDet e outras redes de visão, com células sem suporte visíveis por família FPGA. O Advanced CNN Accelerator tem como alvo Avant-E/Avant-X/CertusPro-NX e é IP comercial. Essa é evidência da tabela do compilador, não uma promessa de que um bitstream suporte simultaneamente todas as topologias listadas.

Microchip VectorBlox

O VectorBlox SDK 3.1 público da Microchip pré-processa e compila redes TFLite INT8 totalmente quantizadas para IP CoreVectorBlox configurável em FPGAs PolarFire SoC. tflite_preprocess e vnnx_compile produzem assets de deploy .vnnx, .hex e .ucomp, e o repositório inclui um simulador e driver C para o alvo. Grafos TensorFlow, ONNX e OpenVINO de origem ainda precisam passar pelo caminho documentado de preparação TFLite/INT8.

A matriz atual de tutoriais inclui YOLOv5n, detecção/classificação/OBB/pose/segmentação YOLOv8n, YOLOv9t, variantes YOLO esparsas/comprimidas, MobileNet, EfficientNet-Lite0, ResNet18, MiDaS, FFNet e QuickSRNet. O guia de pós-processamento C cita separadamente YOLOv2/3/4/5 e decodificadores de detecção, pose e OBB Ultralytics. O SDK 3.1 atualmente oferece suporte ao PolarFire SoC Video Kit e explicitamente não ao PolarFire Video Kit sem SoC; portanto, demos de placas antigas não devem ser confundidas com o contrato atual do alvo.

O SDK pode ser baixado publicamente sob uma licença específica da Microchip que restringe o software e derivados a produtos Microchip. A Microchip oferece licenças Libero Silver e CoreVectorBlox gratuitas, mas mediante solicitação. O deploy continua sendo um contrato de sistema FPGA: configuração do acelerador, bitstream, firmware, dados de rede gerados pelo SDK e layout de memória precisam corresponder. Uma compilação VectorBlox bem-sucedida não transforma o modelo em um binário que possa ser copiado para um PolarFire qualquer.

Syntiant

O NDP200 da Syntiant tem como alvo inferência sempre ativa de visão, áudio e sensores abaixo do envelope de potência de SoCs Linux normais. A tabela atual de hardware lista o NDP200 em produção em massa e o NDP250 em amostragem. O resumo de produto NDP200 documenta suporte a redes CNN, RNN e totalmente conectadas abaixo de 1 mW; o anúncio NDP250 descreve, em vez disso, reconhecimento de imagem sempre ativo abaixo de 30 mW. "Sub-miliwatt" não deve ser generalizado entre as duas peças.

O material público não comprova ampla compatibilidade YOLO, portanto o produto deve ser avaliado para classificadores e detectores pequenos sempre ativos por meio de uma análise de modelos apoiada pelo fornecedor, não por uma suposição genérica de exportação ONNX.

Google Coral: duas gerações sem relação entre si

Os produtos Edge TPU legados usam Edge TPU Compiler, libedgetpu e PyCoral com modelos TFLite totalmente INT8. Seus principais repositórios Edge TPU e PyCoral estão arquivados. Isso representa um risco real de manutenção, mas não é um aviso formal de fim de vida do hardware.

O Google também mantém um Coral NPU de código aberto separado, ativo: IP acelerador RISC-V para integração em SoCs de baixo consumo. Atualmente, o projeto público expõe RTL, simulação de hardware, toolchain e exemplos ELF. Ele não é um substituto direto para Edge TPU USB/M.2 e não publica uma matriz atual de deploy YOLO.

Armadilhas com GPU adjacente, NPU client e computação adaptativa

NVIDIA, AMD, Intel e Apple aparecem frequentemente em buscas por NPU, mas não expõem uma classe única e intercambiável de aceleradores.

NVIDIA Jetson: Jetson Orin combina GPU CUDA com núcleos DLA dedicados. O TensorRT pode construir um engine serializado para DLA, mas camadas sem suporte só rodam na GPU se o fallback para GPU estiver explicitamente habilitado. A tabela YOLO DeepStream atual cobre YOLOv4/v7/v8/v9/11, mas a maioria das entradas tem como alvo a GPU; a entrada ONNX explícita para DLA é YOLOv8s INT8. As restrições DLA da NVIDIA explicam os limites de operadores. Thor é outra distinção: o guia de migração DriveOS da NVIDIA diz que os núcleos DLA foram removidos do Thor em favor da flexibilidade de escalonamento na GPU. Portanto, "roda no Jetson" não identifica o acelerador.

AMD Vitis AI: a geração antiga Kria/DPU compilava grafos .xmodel executados pelo VART. O Vitis AI 6.2 atual é GA para dois caminhos distintos Versal AI Edge: Gen1 em VEK280/VE2802 usa ONNX, AMD Quark e um fluxo de snapshot/subgrafo vinculado ao alvo; Gen2 em VEK385 tem contrato próprio de compilação e runtime. Gen1 publica exemplos YOLOv5, YOLOv7, YOLOv8 e YOLOX. Ryzen AI é uma quarta pilha NPU client separada. Não transfira artefatos ou validação entre DPU legado, Versal Gen1, Versal Gen2 e Ryzen AI só porque todos usam o nome Vitis ou AMD.

Intel OpenVINO: o OpenVINO pode ter como alvo CPU, GPU e NPU Core Ultra pela mesma API. A documentação do plug-in NPU Intel identifica gerações NPU compatíveis, enquanto a matriz de modelos verificados mostra colunas específicas do dispositivo. Um notebook YOLO comprova uma receita de aplicação, não validação em NPU, a menos que a matriz diga isso. Operações, formatos, precisão e driver NPU instalado ainda determinam se o grafo completo roda ali. OpenVINO IR (.xml mais .bin) é uma IR reutilizável de origem; um cache de modelo compilado é específico do dispositivo e do software.

Apple Core ML: coremltools converte modelos para .mlpackage, que o Xcode compila em .mlmodelc. Core ML pode distribuir o trabalho entre CPU, GPU e Apple Neural Engine, mas abstrai intencionalmente a partição exata. Isso faz da Apple uma excelente plataforma de deploy e uma opção ruim para afirmações como "o grafo YOLO inteiro rodou na NPU", a menos que o profiling comprove isso.

As empresas de IP de NPU por trás das empresas de chips

Algumas empresas não vendem uma placa nem um acelerador empacotado. Elas licenciam designs de NPU para fornecedores de SoC. Importam porque a mesma arquitetura subjacente pode aparecer em várias marcas de chips, mas o SDK e o artefato finais ainda podem ser personalizados pelo licenciado.

A Imagination mostra por que rótulos de acesso e ciclo de vida devem aparecer ao lado dos nomes de arquitetura. Seu programa Open Access oferece três configurações Series3NX comprovadas em silício sem taxa inicial de licença de IP, mas somente após avaliação da empresa, com suporte/manutenção pagos e royalties de produção. O Neural Compute SDK fornece ferramentas de compilação, otimização, quantização e runtime; uma colaboração oficial Baidu PaddlePaddle cita detecção PP-YOLOE, classificação EfficientNet e segmentação HRNet. Esses exemplos não validam todas as configurações Series3NX ou Series4, e as páginas atuais de produtos Series4 marcam os produtos como indisponíveis; portanto, Series4 deve ser considerada histórica, a menos que a equipe de vendas confirme o contrário.

Essa camada explica semelhanças aparentes entre famílias. Ela não cria portabilidade de artefatos. Dois SoCs que contenham IP Vivante ou Ethos relacionado podem ter mapas de memória, drivers, versões de compilador, conjuntos de operadores e runtimes do fornecedor diferentes.

O que você realmente implanta: a tabela de dependência dos artefatos

O último arquivo no pipeline do compilador é onde a aparente portabilidade ONNX termina. Nomes e extensões mudam com o tempo, mas a regra prática permanece: mantenha o modelo original e os dados de calibração, porque o artefato nativo geralmente não pode ser movido para outra geração de NPU nem recompilado com segurança usando outra versão do SDK.

Esta tabela não é apenas uma lista de extensões. A versão do compilador, identificador do alvo, driver, firmware e BSP fazem parte da identidade reprodutível do modelo. Um exportador LibreYOLO futuro deve gravá-los em um manifesto legível por máquina junto de cada artefato.

Sinais de acesso às ferramentas e ciclo de vida

A disponibilidade de hardware e o acesso ao compilador são independentes. Uma placa pode ser fácil de comprar enquanto o compilador atual exige um acordo com o cliente; um SDK público pode ter como alvo silício difícil de obter. Os itens a seguir são sinais concretos de primeira parte, não um ranking universal de longevidade.

Por que TOPS não serve como guia de compra

TOPS de pico pode ser útil dentro de um fornecedor e arquitetura, mas comparações entre fornecedores geralmente são inválidas, a menos que todos os itens abaixo correspondam:

• Precisão numérica, incluindo INT8, INT4, FP16 ou modo misto
• Se uma multiplicação-acumulação conta como uma ou duas operações
• Aritmética densa ou esparsa estruturada
• Resolução de entrada, tamanho de batch e grafo do modelo
• Acurácia depois da quantização
• Latência somente da NPU ou do pipeline completo da aplicação
• Transferências de memória e fallback no host
• Estado térmico e operação sustentada, não em pico

Um detector faz parte de um pipeline: aquisição de imagem, resize/letterbox, normalização, transferência ao dispositivo, inferência neural, decode, NMS, ajuste de coordenadas e lógica da aplicação. Os fornecedores frequentemente publicam apenas a parte central da inferência neural. O MLPerf Inference Edge é valioso porque define cenários, metas de qualidade e regras de sistema medidas, em vez de comparar isoladamente aritmética de marketing.

Para deploys YOLO, o registro mínimo de benchmark confiável é:

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

Sem esses campos, dois números de FPS geralmente medem coisas diferentes.

Como escolher uma NPU para visão computacional

Escolha nesta ordem, não pelo maior número impresso na página do produto.

1. Comprove a compatibilidade do grafo. Compile o modelo exportado exato, não um checkpoint de zoo com nome parecido.
2. Meça a acurácia. Valide o artefato compilado no dataset real da tarefa após calibração e quantização.
3. Meça de ponta a ponta. Inclua conversão de entrada, transferências, decode e NMS.
4. Verifique o acesso ao software. Determine se o compilador é público, exige cadastro ou só está disponível após acordo comercial.
5. Congele a matriz de versões. Registre compilador, runtime, driver, firmware e identificadores do alvo.
6. Verifique a realidade do sistema operacional. Suporte Android, Debian, Yocto, Buildroot, RTOS e Windows não é intercambiável.
7. Confira fornecimento e ciclo de vida. Um chip tecnicamente excelente é uma escolha ruim para produção se houver incerteza sobre módulos, drivers ou suporte de longo prazo.
8. Só então compare custo, potência e desempenho. Essas medições só fazem sentido depois que o mesmo modelo estiver correto nos dois alvos.

Pontos de partida práticos por caso de uso

Esta tabela é uma lista de pesquisa, não um ranking de desempenho. Aquisição, disponibilidade regional e o modelo exato podem inverter a ordem.

O que isso significa para o LibreYOLO

O design escalável não consiste em dezenas de exportadores sem relação. É um único contrato estrito de intercâmbio mais pequenos adaptadores de compilador e runtime do fornecedor:

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

Todo artefato nativo deve ter um manifesto complementar com:

• Fornecedor, alvo do chip e alvo da placa
• Versões de compilador, runtime, driver e firmware
• Checksum do checkpoint de origem e do ONNX
• Nomes e formatos de entrada, layout, espaço de cores, normalização e dtype
• Precisão de quantização, escalas quando expostas e hash dos dados de calibração
• Nomes e formatos dos tensores de saída e significado semântico
• Tarefa de detecção, nomes das classes e indicação de decode/NMS no chip ou no host
• Resultados registrados de paridade numérica e acurácia da tarefa

O LibreYOLO já oferece exportação ONNX portável, ferramentas de quantização, uma exportação RKNN direta, mas deliberadamente restrita e um fluxo Hailo honesto com compilador externo. Segundo os critérios usados neste guia, Amlogic ADLA é um forte próximo candidato a integração: o toolkit é público, a cobertura de modelos se sobrepõe muito ao LibreYOLO e o caminho A311D antigo pode ser mantido separado explicitamente.

A prioridade depois da Amlogic deve se basear no hardware dos usuários e na capacidade de executar validação de acurácia, não apenas na disponibilidade do compilador. DEEPX, Sony IMX500, D-Robotics, AXERA, SOPHGO e Qualcomm são tecnicamente atraentes; TI, NXP, ST e Renesas tornam-se especialmente valiosas quando parceiros industriais podem fornecer placas e acesso prolongado a CI.

Lista de observação: silício real sem contrato público de integração

Excluir completamente uma empresa pode tornar enganoso um panorama de mercado. Incluí-la como "compatível" pode ser pior. Esses fornecedores vendem, estão testando ou anunciaram silício relevante, mas as evidências públicas ainda não estabelecem um caminho reproduzível e atual de compilador, artefato e modelo identificado, adequado a um backend LibreYOLO.

Esta lista de observação se baseia intencionalmente em evidências. Um fornecedor pode passar às tabelas de deploy ao publicar uma toolchain atual ou caminho de avaliação, um contrato de artefato específico para o alvo e pelo menos um modelo identificado com uma receita de ponta a ponta.

O que deliberadamente não foi afirmado

Este artigo não diz que todo modelo identificado funciona a partir de qualquer repositório upstream. Modelos de vendor zoo são frequentemente modificados, divididos em outros nós de saída ou associados a pós-processamento personalizado.

Também não transforma estas afirmações em alegações de suporte:

• Um compilador importa ONNX.
• Um chip anuncia um driver Android NNAPI.
• Um distribuidor diz que a placa é "compatível com YOLO".
• Um repositório comunitário executa uma bifurcação de um modelo.
• Um modelo compila sem erro.
• Um fornecedor relata FPS somente na NPU sem resultado de acurácia.

Aceleradores de telefone Google Tensor e diversos ASICs personalizados exclusivos de OEM também existem, mas o Google não expõe Tensor como alvo geral de compilador para autoatendimento, comparável às plataformas acima. A existência de uma empresa, um diagrama de blocos NPU ou aceleração Android não basta para inventar uma alegação de integração com LibreYOLO.

Da mesma forma, aceleradores de nuvem como Google TPU, AWS Inferentia/Trainium, Microsoft Maia e placas de IA exclusivas de data center estão fora do escopo. Este guia trata de hardware que um desenvolvedor de visão computacional poderia plausivelmente implantar na borda.

O licenciamento do modelo é uma camada separada. A publicação de uma receita de conversão YOLO por um fornecedor de chips não concede direitos para usar ou redistribuir os pesos upstream, o código de treinamento ou um derivado compilado. É preciso verificar o suporte de hardware, as licenças do SDK e as licenças do modelo para o produto pretendido.

Metodologia da pesquisa e correções

Para cada empresa, a pesquisa procurou quatro tipos de fonte primária:

1. Uma página de produto atual ou ficha técnica que identificasse o silício.
2. Documentação de compilador e runtime explicando o caminho real de deploy.
3. Um model zoo, tabela de compatibilidade ou tutorial completo que citasse modelos de visão.
4. Um sinal de ciclo de vida ou acesso indicando se desenvolvedores conseguem obter as ferramentas.

Organizações GitHub próprias contam como fontes dos fornecedores. A documentação de fabricantes de placas é identificada como evidência do ecossistema quando a própria empresa de chips não publica o mesmo material. Alegações de desempenho de terceiros foram excluídas das tabelas comparativas.

A versão final foi então auditada novamente em rodadas separadas por grupo de fornecedores e em verificações cruzadas entre tabelas. Essas verificações revalidaram escopo dos alvos, nomes dos artefatos, precisão, evidências de modelos versus pós-processadores, status anunciado versus disponível, rótulos de ciclo de vida, denominadores de benchmark e a contagem de cada entidade. Quando duas páginas de primeira parte entram em conflito, este guia expõe o conflito em vez de escolher silenciosamente o valor mais conveniente.

Este mercado muda rapidamente. Se você trabalha em uma dessas empresas e um chip, SDK, lista de modelos ou status de acesso estiver incorreto, envie ao LibreYOLO a URL pública exata da documentação e sua versão. Correções apoiadas por evidências primárias devem substituir este texto; afirmações de marketing sem documentação não devem.

FAQ

Quantas empresas de NPU para edge AI existem?

Não existe um total universal de empresas porque fornecedores de produtos, licenciadores de IP, sensores inteligentes, GPUs e ASICs automotivos privados se sobrepõem. Este guia não exaustivo acompanha 69 empresas e ecossistemas de plataforma com chips de edge AI, plataformas aceleradoras, IP de NPU licenciável ou silício relevante em uma lista de observação, em agosto de 2026.

O que é uma NPU?

Uma unidade de processamento neural é um hardware especializado em operações de redes neurais, como convoluções e multiplicação de matrizes. Os termos dos fornecedores incluem NPU, AIPU, BPU, KPU, DLA, HTP, TPU e MLA, e os modelos compilados geralmente não são portáveis entre empresas.

Quais empresas de NPU oferecem suporte oficial a modelos YOLO?

Amlogic, Hailo, Axelera AI, Rockchip, Qualcomm, MediaTek, DEEPX, D-Robotics, AXERA, SOPHGO, Huawei, Cambricon, Sony IMX500 por meio do repositório oficial da AI Camera da Raspberry Pi, STMicroelectronics, Renesas, Lattice, Himax, Microchip e várias outras têm entradas em model zoos próprios, tutoriais ou resultados validados para pelo menos uma geração do YOLO. A geração, a tarefa, o chip alvo e a versão do SDK ainda importam.

Qualquer modelo ONNX pode rodar em qualquer NPU?

Não. ONNX é um formato de intercâmbio, não uma garantia de compatibilidade com o hardware. O compilador da NPU precisa oferecer suporte a cada operador, formato de tensor e tipo de dado do grafo. Formatos estáticos, cortes no grafo, operações personalizadas e fallback para CPU são comuns.

Qual é a melhor NPU para YOLO?

Não há uma vencedora universal. Hailo, Rockchip, Axelera AI, DEEPX e Amlogic têm ampla cobertura documentada de YOLO, enquanto a Qualcomm tem um alcance excepcional de dispositivos. Escolha considerando a acurácia após a quantização, a latência do pipeline completo, a potência sustentada, o preço, a disponibilidade, o acesso ao SDK e o suporte ao sistema operacional.

Por que não dá para comparar diretamente os valores de TOPS das NPUs?

Os fornecedores podem contar precisões, operações esparsas, multiplicações-acumulações e hipóteses de utilização de pico diferentes. TOPS não inclui tráfego de memória, operadores sem suporte, pré-processamento, pós-processamento nem a sobrecarga do host. Compare o mesmo modelo, precisão, resolução, acurácia e pipeline completo.

O que é calibração de NPU?

A calibração executa imagens representativas, geralmente sem rótulos, do ambiente de deploy pelo modelo para que o compilador estime os intervalos de ativação para INT8 ou outro formato de baixa precisão. Imagens aleatórias ou pouco representativas ainda podem gerar um artefato compilado, mas prejudicar a acurácia da tarefa.

O LibreYOLO oferece suporte a NPUs de edge?

O LibreYOLO exporta ONNX e vários formatos de runtime, tem um caminho direto de compilação RKNN para modelos Rockchip selecionados e documenta o fluxo externo de compilação Hailo. Todo outro artefato nativo do fornecedor ainda exige o SDK correspondente e deve ser descrito como candidato a integração até ser compilado, validado e executado no hardware.