69 empresas de NPU para Edge AI: chips, SDK y YOLO en visión artificial (2026)

No existe un único mercado de NPU. Esta guía no exhaustiva sigue a 69 empresas y ecosistemas de plataforma: 51 proveedores con chips o plataformas desplegables, nueve proveedores de IP de NPU y nueve empresas claramente identificadas como candidatas en observación. Abarcan varias clases incompatibles de aceleradores y casi tantos stacks de compilador. La mayoría promete el mismo flujo: exportar un modelo, cuantizarlo, compilarlo, copiar un artefacto propietario a una placa y llamar al runtime del proveedor. Los detalles determinan si ese proceso lleva una tarde o un trimestre de ingeniería.

Esta guía cartografía las empresas que ofrecen hardware creíble para visión artificial en 2026. Registra los chips pertinentes, los nombres de SDK y compiladores, los artefactos de despliegue, el nivel de acceso público y los modelos que el proveedor documenta realmente. También presta especial atención a Amlogic, cuyo stack ADLA más reciente difiere sustancialmente del antiguo ecosistema NPU A311D.

Alcance de la investigación: Las fuentes se revisaron el 15 de agosto de 2026. Las afirmaciones sobre modelos concretos proceden de páginas de producto, documentación, model zoos, repositorios o tutoriales del propio proveedor, salvo que se indique expresamente lo contrario. Los TOPS anunciados son cifras de los proveedores, no resultados de benchmarks comparables e independientes. Esta es una guía para desarrolladores, no asesoramiento de inversión ni una clasificación de pago.

Navegación rápida: tablas de empresas | análisis de Amlogic | perfiles de proveedores | tabla de artefactos compilados | acceso y ciclo de vida | hoja de ruta de LibreYOLO

El hallazgo más importante

El hardware está fragmentado, pero el patrón de despliegue es sorprendentemente uniforme:

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

ONNX permite expresamente runtimes, generadores de código e implementaciones de hardware, pero un archivo ONNX solo es el punto de entrega. No significa que todos los operadores ONNX puedan traducirse para todos los aceleradores. Las formas de entrada estáticas, las restricciones de operadores compatibles, las reglas de cuantización y la ejecución alternativa en el host determinan qué se ejecuta realmente en la NPU.

Por tanto, el stack de software forma parte del chip. Una NPU nominalmente rápida con un compilador restringido o poco fiable puede ser un destino de despliegue peor que un dispositivo más pequeño con una cadena de herramientas pública, un model zoo, un simulador y un runtime estable.

Qué significa «compatible» en esta guía

La documentación de los proveedores usa la palabra compatibilidad de forma muy imprecisa. Este artículo distingue cuatro niveles de evidencia:

La distinción importa. «Importa ONNX» no equivale a «es compatible con la segmentación de YOLO11». Un modelo puede analizarse y luego ejecutarse en CPU, compilarse con valores numéricos de salida incorrectos, desbordar la memoria del acelerador o perder precisión durante la cuantización.

Empresas y plataformas NPU de un vistazo

Las tablas mezclan deliberadamente SoC, aceleradores discretos, sensores inteligentes y plataformas adyacentes de GPU/FPGA. Compiten por la misma decisión de despliegue aunque los proveedores utilicen términos como NPU, AIPU, BPU, KPU, DLA, HTP, TPU o MLA.

SoC embebidos, sensores inteligentes y procesadores industriales

Aceleradores edge dedicados y módulos

Plataformas adyacentes que se comparan con las NPU

Amlogic: dos generaciones de NPU, no una

Amlogic merece una explicación detallada porque la información web suele mezclar productos incompatibles. La empresa tiene una ruta antigua basada en VeriSilicon y una ruta ADLA propietaria más reciente. No usan el mismo compilador, artefacto ni runtime.

La ficha técnica A311D identifica la NPU original de 5-TOPS INT8. La antigua página de aplicaciones Khadas VIM3 y el resumen de NPU documentan DenseNet CTC, MTCNN, RetinaFace, YOLOFace, YOLOv2, YOLOv3, YOLOv3-tiny, YOLOv4, YOLOv7-tiny y YOLOv8n; el resumen también documenta YOLOv8n-pose y marca FaceNet como obsoleto. Son ejemplos reales, pero evidencian el antiguo ecosistema Acuity .nb, no los chips ADLA actuales. A311D no es A311D2, y C305X no es C305X2.

Hay otra trampa de hardware. La guía de revisiones Khadas VIM4 indica que la placa original V12/A311D2 revisión B no tiene NPU; la NPU anunciada de 3.2-TOPS aparece en las placas V13A y posteriores con el componente A311D2-N0D revisión C. El nombre del producto no basta para elegir un dispositivo de prueba.

El stack AMLNN y ADLA actual

El AMLNN Toolkit actual cubre conversión de modelos, cuantización, compilación, inferencia y profiling. Su guía de usuario fijada en mayo de 2026 documenta importadores para ONNX, TFLite de punto flotante o cuantizado, TorchScript .pt y PyTorch 2 ExportedProgram/PT2. La guía detallada marca TensorFlow, Paddle y Keras como previstos, aunque el resumen del repositorio use términos más amplios. El compilador genera .adla. El despliegue Python usa AMLNN o amlnn_edge_toolkit_lite; el código C/C++ nativo enlaza libnnsdk.so mediante nnsdk2.h. El desarrollo en host puede usar ADB con nnserver; el runtime también tiene como destino Android, Buildroot, Yocto y algunos entornos Debian/Armbian.

Los identificadores de plataforma publicados actualmente por el toolkit incluyen:

Ese campo de destino no es decorativo. Amlogic exige que .adla, nnsdk2.h, libnnsdk.so, BSP y generación del compilador/runtime coincidan. El Inicio rápido fijado requiere el controlador ADLA 2.0.2 o posterior, NNSDK 3.0.0 o posterior y NNSDK2 1.0.0 o posterior; la guía de despliegue Android concreta la relación entre biblioteca, cabecera, controlador y BSP. Trata .adla como un artefacto de compilación ligado a una ABI, no como un modelo portable.

La cuantización también depende de la generación de NPU. Los destinos ADLA2 001 a 006 documentan compilación W8A8 y W8A16. Los destinos ADLA3 007 y 008 añaden combinaciones W4A8, W4A16, W8A8, W8A16 y W16A16, con compatibilidad nativa con INT4, FP16 y BF16 en la guía de operadores. Amlogic recomienda entre 200 y 500 muestras de calibración representativas. La opción de datos aleatorios es explícitamente para pruebas de rendimiento, no para una cuantización que preserve la precisión.

Compatibilidad de modelos documentada por Amlogic

El entorno de pruebas de modelos Amlogic fijado es una evidencia mucho más sólida que una afirmación genérica de compatibilidad con ONNX. Su matriz publicada de compatibilidad/ejemplos menciona A311D2, S905X5, A311Y3, C305X2 y A123X. Que el compilador acepte los demás ID de destino no demuestra que se hayan validado en ellos todos estos modelos.

El mismo repositorio publica las siguientes cifras W8A8 de runtime de modelos. Son mediciones del proveedor de la red neuronal en la NPU, no de canalizaciones de cámara completas.

Las salvedades son especialmente importantes. La guía de operadores de Amlogic sitúa NMS en software tanto en ADLA2 como en ADLA3. El README define estas cifras como resultados de runtime del modelo en la NPU nativa y excluye preprocesamiento y postprocesamiento; no especifica si incluye todas las transferencias de memoria. Las filas de precisión YOLO usan subconjuntos COCO de 300 imágenes, no el conjunto completo de validación, mientras que las filas de clasificación usan ImageNet val1000. Las tablas también ofrecen una latencia YOLOv8n de A311Y3 distinta de la tabla FPS, en condiciones que el repositorio no concilia. No se especifican relojes, modo de potencia, refrigeración, estado térmico estable, versiones exactas de SDK/BSP ni duración de las pruebas. Usa las cifras para entender un stack de proveedor, no para compararlo con otro.

Por qué Amlogic es estratégicamente interesante

Amlogic combina cuatro características poco habituales: una amplia presencia de SoC embebidos, un compilador recién hecho público, una matriz actual de modelos que coincide mucho con las tareas de LibreYOLO y una integración de primera clase relativamente escasa en las bibliotecas de entrenamiento más conocidas. Los repositorios actuales también son recientes: aparecieron públicamente a finales de 2025 y principios de 2026, con manuales sustanciales fechados entre mayo y julio de 2026. Esto abre una oportunidad real para ser pioneros y conlleva un riesgo de estabilidad de API.

Una integración limpia debería usar la exportación ONNX determinista de LibreYOLO como entrada del compilador, exigir imágenes de calibración representativas para compilaciones de baja precisión, generar .adla junto con un manifiesto de metadatos y cargarlo mediante un adaptador NNSDK2. A311D heredado debería usar un destino .nb claramente distinto, porque presentar .nb y .adla como un único backend produciría fallos de compatibilidad silenciosos. Los repositorios de Amlogic tienen licencias Apache-2.0 en su nivel superior, pero conviene confirmar directamente los derechos de redistribución de wheels, bibliotecas compartidas, nnserver y binarios Android AAR incluidos antes de que LibreYOLO los replique.

Los ecosistemas públicos de despliegue más sólidos

Las siguientes empresas ofrecen actualmente la combinación más clara de hardware obtenible, material técnico público y evidencia de modelos concretos. Eso no las convierte en las más rápidas para todos los casos. Significa que sus afirmaciones de compatibilidad son más fáciles de evaluar antes de comprar hardware.

Hailo

Hailo es el ejemplo de referencia de un ecosistema dedicado a aceleradores de visión. Los modelos se analizan en un Hailo Archive, se optimizan y cuantizan con imágenes representativas y luego se compilan en un archivo Hailo Executable Format (.hef). Las aplicaciones cargan ese HEF mediante HailoRT.

El Hailo Model Zoo contiene recetas, modelos preentrenados, configuraciones de postprocesamiento y datos de rendimiento para detección, segmentación, clasificación, pose y otras tareas. Su compatibilidad YOLO incluye YOLOv3/v4/v5/v6/v7/v8/v9/v10/11/12 y YOLO26, además de YOLOX, DAMO-YOLO, SSD y EfficientDet. La tabla de detección de objetos Hailo-8 fijada a una versión es una fuente de compatibilidad mejor que una página de producto genérica, mientras que la aplicación independiente documenta canalizaciones YOLO desplegables.

Hay un límite importante entre versiones. Hailo-8 y Hailo-8L usan las ramas anteriores Model Zoo 2.x, Dataflow Compiler 3.x y HailoRT 4.x, mientras que Hailo-10 y Hailo-15 usan la generación actual 5.x. Las recetas, el comportamiento del analizador y los HEF no son intercambiables solo porque todos los dispositivos lleven el nombre Hailo.

Hailo-15 también tiene una capa de aplicación distinta. Usa Vision Processor Software Package y Hailo Media Library en lugar de la ruta de host tipo TAPPAS de Hailo-8/10H. El repositorio de referencia público hailo-camera-apps se archivó el 3 de mayo de 2026, mientras que hailo-apps-core sigue siendo un framework de aplicaciones público aparte. El archivo de un repositorio no demuestra el fin de vida del producto, pero los proyectos Hailo-15 deberían confirmar el paquete de aplicaciones actual en Developer Zone.

La guía de despliegue Hailo de LibreYOLO se detiene deliberadamente en la entrega de un ONNX estático, porque el compilador propietario no puede incluirse como dependencia Python. Ese es el límite honesto entre producir un grafo adecuado y afirmar que un HEF está probado.

Rockchip

Rockchip tiene una de las mayores presencias de Linux embebido comercial y para aficionados, especialmente mediante placas RK3588, RK3576 y RK356x. El RKNN-Toolkit2 público convierte y cuantiza modelos en un host Linux x86, y RKNN Runtime o Toolkit-Lite ejecuta el archivo .rknn resultante en la placa.

El RKNN Model Zoo es excepcionalmente explícito sobre chips, familias de modelos y precisión. Su tabla actual enumera rutas FP16 e INT8 para YOLOv5/6/7/8/10/11, YOLOX, PP-YOLOE, YOLO-World y variantes de segmentación YOLOv5/v8; YOLOv8 OBB y YOLOv8 pose figuran solo como INT8. También cubre OCR, rostros y otras redes de segmentación.

LibreYOLO ya tiene un exportador RKNN directo y prudente. Valida cuatro variantes exactas de detección en RK3588, puede comparar el simulador del compilador con ONNX Runtime y rechaza familias no validadas, en vez de equiparar una compilación correcta con predicciones correctas. Esa afirmación limitada de compatibilidad es un buen modelo para todos los futuros backends NPU.

Axelera AI

Axelera AI, que suele escribirse mal como «Accelera», desarrolla la AIPU Metis y la vende en productos M.2, PCIe y multichip. Metis es la familia que se puede pedir públicamente; Europa y Titania son productos de cartera anunciados, así que no conviene reducirlos a un único estado de disponibilidad. El Voyager SDK es público en GitHub y gestiona selección de modelos, compilación, cuantización, ejecución y canalizaciones de aplicación; el soporte a clientes sigue restringido a cuentas.

El Voyager Model Zoo público es uno de los más informativos del mercado. Enumera variante del modelo, tamaño de entrada, precisión, exactitud y rendimiento medido para YOLOv3, YOLOv5, YOLOv7, YOLOv8, YOLOv9, YOLOv10, YOLO11, YOLO26 n/s/m/l/x, YOLOX, YOLO-NAS, OBB, pose y segmentación, junto con muchos modelos de clasificación y predicción densa. Publicar la pérdida por cuantización y la precisión junto a la velocidad aporta más que publicar solo los TOPS máximos.

La nomenclatura de artefactos cambió con la generación de la API. El flujo alfa de compilación Pipeline Builder genera un modelo .axm y puede empaquetar una canalización portable como .axe. La documentación de la canalización clásica describe .axmodel junto con metadatos del modelo y un manifiesto. La integración debe detectar la generación Voyager instalada, en vez de fijar una única extensión.

Qualcomm

Qualcomm ofrece un alcance de despliegue enorme, pero «NPU Qualcomm» esconde varias interfaces. Según el dispositivo y la categoría del producto, los desarrolladores se encuentran con Hexagon HTP mediante QAIRT/QNN, el flujo SNPE anterior, los servicios de compilación Qualcomm AI Hub, LiteRT o el proveedor de ejecución QNN de ONNX Runtime.

El repositorio oficial Qualcomm AI Hub Models ofrece evidencia sólida a nivel de modelo. Publica paquetes optimizados para YOLOv3, YOLOv5, YOLOv6, YOLOv7, YOLOv8, YOLOv9, YOLOv10, YOLO11, YOLO26 para detección/segmentación/pose, YOLOX, YOLO-World, YOLOR, RF-DETR y muchos modelos de clasificación, profundidad y pose. AI Hub también expone profiling específico por dispositivo, importante porque un modelo compilado para una generación HTP no es automáticamente portable a otra.

El principal coste de integración es el tamaño de la matriz: Android frente a Linux embebido, componentes de pedido QCS frente a Snapdragon de consumo, arquitectura HTP, versión QNN/QAIRT y esquema de cuantización, todo importa. Las páginas actuales de Qualcomm discrepan sobre el estado de Dragonwing IQ-9075: la página del producto lo marca como Active y su EVK se puede evaluar, mientras que el Product Longevity Program sigue marcando IQ-9075 como Sampling y enumera longevidad hasta 2038. El prefijo de pedido/SKU es QCS9075; Qualcomm anuncia configuraciones de 50 y 100 TOPS densos INT8, además de compatibilidad con Ubuntu/Yocto. Hay que confirmar el estado de producción para el SKU exacto de pedido, y una integración LibreYOLO debería registrar ese SKU en vez de crear una carpeta genérica llamada «Qualcomm».

DEEPX

Los aceleradores DX-M1/DX-M1M de DEEPX usan el DXNN SDK. DX-COM compila y cuantiza el modelo, DX-RT lo ejecuta y el artefacto desplegado usa el formato .dxnn. La empresa publica DX-AllSuite, ejemplos de aplicación en DX-APP y un amplio Model Zoo en línea.

El catálogo público informaba 354 entradas con DX-COM 2.4.0 y DX-RT 3.4.0 al revisarlo el 15 de agosto de 2026. La cobertura documentada incluye YOLOv3 a YOLO11 y YOLO26, YOLOX, SSD, EfficientDet, NanoDet, DAMO-YOLO, segmentación YOLO, pose y cajas orientadas. DEEPX es un objetivo de integración especialmente plausible porque los límites entre compilador/runtime y el artefacto de despliegue están claramente definidos, y la cobertura pública de visión es amplia.

Los SoC industriales son varios ecosistemas, no uno

Los proveedores industriales suelen ofrecer ciclos de producto más largos y mejor integración con cámaras, seguridad y tiempo real que los SoC de placas para aficionados. Sus stacks de IA pueden ser más complejos porque un proveedor puede ofrecer simultáneamente varias arquitecturas de NPU no relacionadas.

Texas Instruments

Los procesadores Edge AI actuales de TI incluyen AM62A, AM67A, AM68A, AM69A y dispositivos TDA4 relacionados. La ruta de software combina Processor SDK Linux, compilador/runtime TIDL, Edge AI TIDL Tools y Edge AI Model Zoo. TIDL puede integrarse con ONNX Runtime, TensorFlow Lite y otros runtimes de aplicación, y delegar subgrafos compatibles.

TI publica mucho más que una afirmación de importación de framework: el zoo contiene modelos convertidos y metadatos de rendimiento para detección de objetos, segmentación, pose, clasificación, profundidad y otras tareas. TI también advierte que los artefactos del model zoo son puntos de partida para desarrollo, no recursos listos automáticamente para producción. Es una salvedad valiosa que suele faltar en las comparativas de proveedores.

TI también incluye TDA54-Q1 como Preview, con hasta cuatro NPU C7 y hasta 400 TOPS para ese componente; la familia TDA5 más amplia se anuncia hasta 1,200 TOPS. Son afirmaciones del proveedor para una nueva generación, no permiso para atribuir la validación de modelos TIDL AM6xA/TDA4 al TDA54-Q1 antes de que TI publique una matriz específica para ese destino.

NXP

NXP requiere al menos cuatro descripciones de backend:

El eIQ Model Zoo contiene recursos o recetas para YOLOv4-tiny, YOLOv8, NanoDet, CenterNet, FastestDet, SSD Lite, YOLACT y otros modelos; la entrada YOLOv5 se añadió solo como documentación. Una entrada validada para un backend no es evidencia para los otros tres. La propia guía de exportación YOLO para plataformas NXP i.MX ilustra este problema de conversión específica del destino. NXP afirma que el monolítico eIQ Toolkit dejó de recibir actualizaciones después de la versión 1.17 en Q3 de 2025; los flujos actuales usan paquetes independientes como eIQ Neutron SDK.

NXP completó la adquisición de Kinara en octubre de 2025. La ficha Ara240 llega a 40 eTOPS anunciados por el proveedor e informa 313 imágenes por segundo para YOLOv8n. NXP incluye Ara SDK y eIQ Toolkit en la página del producto, pero eso no establece el intercambio de artefactos con la ruta Neutron separada de i.MX 95. El módulo M.2 de 16 GB está activo, mientras que la opción USB está en preproducción. NXP define la «e» de eTOPS como «equivalent» (equivalente), no «effective» (efectivo); no es la métrica TOPS INT8 densa de otro proveedor y no debe compararse directamente.

STMicroelectronics

Los dispositivos STM32N6x7, incluidos STM32N657 y STM32N647, incorporan un acelerador Neural-ART de 600-GOPS en un producto de clase MCU; la línea de uso general N6x5 no incluye ese acelerador. STM32Cube AI Studio y ST Edge AI Core analizan y optimizan los modelos importados, mientras que STM32 AI Model Zoo Services ofrece flujos de despliegue, optimización, benchmarking y ejemplos.

La descripción general actual de detección de objetos documenta Tiny YOLOv2, YOLOv5u, YOLOv8, YOLO11, YOLO26 y ST-YOLOX, junto con servicios de clasificación, pose y segmentación. No es la misma clase de rendimiento que una tarjeta PCIe de 200-TOPS. Es interesante porque la captura de cámara, la inferencia y el control pueden convivir con límites muy estrictos de potencia y memoria.

Renesas

Los procesadores RZ/V de Renesas integran aceleradores DRP-AI. El software ha evolucionado desde DRP-AI Translator y DRP-AI TVM hacia RUHMI, impulsado por la tecnología MERA de EdgeCortix. El repositorio abierto RZ/V DRP-AI TVM y la lista de validación RZ/V2H mencionan variantes n/s/m de YOLOv5, YOLOv8, YOLO11 y YOLO26, YOLOX, redes de pose y segmentación, además de modelos de clasificación.

Renesas es un objetivo viable para robótica e industria, pero hay que registrar la placa exacta, la generación DRP-AI, la versión del traductor y el postprocesamiento en CPU para que los resultados sean reproducibles.

Sensores inteligentes y procesadores orientados a cámaras

Sony IMX500

Sony IMX500 no es un procesador de aplicaciones normal. Apila la captura de imagen y el procesamiento de IA para que la inferencia pueda realizarse en el sensor, reduciendo la cantidad de datos de imagen que debe salir de la cámara. Raspberry Pi AI Camera hace que esta arquitectura sea excepcionalmente accesible.

El repositorio oficial de modelos Raspberry Pi IMX500 publica modelos empaquetados YOLOv8n, YOLO11n, EfficientDet Lite0, NanoDet+ y SSD MobileNetV2 FPN Lite. La documentación AI Camera explica la conversión, el empaquetado y el postprocesamiento en el sensor. La unidad de despliegue es un paquete RPK, no un archivo ONNX genérico, y la memoria del sensor y las restricciones de operadores son límites de diseño fundamentales. La página del producto de Raspberry Pi indica que esta cámara seguirá en producción al menos hasta enero de 2028.

Ambarella

Los procesadores CVflow de Ambarella están muy establecidos en cámaras, drones y visión automotriz. Las familias de productos actuales incluyen CV72/CV75 para cámaras, CV5/CV52 para sistemas de visión de mayor rendimiento y dispositivos automotrices CV3-AD. La plataforma de desarrollo Cooper y el flujo de compilación/runtime CVflow constituyen el stack de software identificado públicamente.

El model garden público para desarrolladores menciona YOLOX, RTMDet, DeepLabV3+, TopFormer, OWL-ViT y modelos multimodales. Sin embargo, la documentación detallada del compilador y las descargas siguen orientadas a socios. Por tanto, una integración Ambarella debería comenzar con una relación con el proveedor o el OEM, no con la suposición de que hay disponible un paquete pip público.

Synaptics Astra

Synaptics tiene tres destinos pertinentes. Los sistemas Astra SL1600/SL1680 usan el toolkit SyNAP, que convierte un modelo de origen y una descripción YAML en un paquete model.synap. Los dispositivos SL2611/13/15/17/19 más recientes usan la plataforma Torq, un flujo basado en IREE/MLIR que genera .vmfb. La serie SR100 es una familia MCU independiente basada en Cortex-M55 y Ethos-U55 con su propio SDK. Estos artefactos y API no son intercambiables.

El tutorial oficial de benchmark YOLO es excepcionalmente concreto: exporta YOLOv8 a TFLite, realiza calibración asimétrica UINT8 en SyNAP, compila para SL1680 y luego ejecuta synap_cli y la aplicación de detección de objetos. Demuestra YOLOv8n/v8s en SL1680 y describe compatibilidad SyNAP hasta YOLO11. Una guía independiente de detección de objetos SL261x ejecuta YOLOv8 desde un .vmfb Torq. Son ejemplos oficiales específicos de destinos, no una afirmación de que los tres grupos sean compatibles con cualquier grafo YOLO.

MediaTek Genio

MediaTek merece una entrada completa porque su IoT AI Hub actual expone la matriz de hardware/software, paquetes de modelos y tablas de benchmarks que los análisis de mercado anteriores no podían auditar. Genio 360/360P/420/520/720 usan NeuroPilot 8 con MDLA 5.3; Genio 510/700 usan NP6 con MDLA 3.0; Genio 1200 usa NP6 con MDLA 2.0. MediaTek indica que la generación NeuroPilot/MDLA, el conjunto de operadores, el compilador y el runtime quedan vinculados por versión durante la vida de cada SoC.

La ruta de IA analítica se centra en TFLite:

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

Los productos Genio más recientes también ofrecen delegación LiteRT en línea y una ruta ONNX Runtime CPU/NPU en sistemas operativos compatibles. Son modos de ejecución distintos de .dla fuera de línea. La guía de arquitectura de software y la matriz de recursos dejan clara la distinción.

La tabla oficial de modelos analíticos publica entradas de benchmark YOLOv5s y YOLOv8s y guías de conversión para varias generaciones MDLA. Indica expresamente que no distribuye artefactos YOLO preconvertidos por las restricciones AGPL-3.0. Sus mediciones offline Quant8, 640 x 640, incluyen 5.35 ms y 8.04 ms respectivamente en Genio 720. La página del modelo YOLOv8s publica tensores de entrada/salida, tiempos específicos del backend y advertencias sobre operaciones personalizadas MediaTek. Son benchmarks del proveedor, no resultados integrales de cámara.

El acceso es el factor limitante. La documentación Yocto pública es detallada, pero el paquete actual todo en uno de conversor/compilador NP8 y gran parte del material Android figuran como recursos bajo NDA o para clientes directos. Una cuenta normal de desarrollador no otorga el mismo acceso que una cuenta MediaTek Online de cliente. Por eso LibreYOLO debería tratar Genio como técnicamente demostrado, pero dependiente de una asociación para una integración reproducible del compilador para modelos propios.

Ecosistemas Edge AI centrados en China

Algunas de las plataformas de visión más capaces y accesibles a bajo coste están poco representadas en las listas de mercado en inglés.

D-Robotics y plataformas BPU derivadas de Horizon

D-Robotics mantiene el ecosistema de placas de desarrollo RDK alrededor de aceleradores BPU usados en RDK X3, X5, Ultra y productos nuevos de la serie S100. La rama actual rdk_x5 de RDK Model Zoo documenta rutas YOLOv5/v5u, YOLOv8/9/10/11/12/13/26, YOLOE, YOLO-World, detección, segmentación, pose, clasificación, OCR y CLIP para RDK X5. X3 usa una rama independiente, mientras que la entrega actual de la serie S está en la rama rdk_s del zoo principal; el antiguo repositorio rdk_model_zoo_s contiene demostraciones históricas. Por tanto, la lista moderna de X5 no demuestra que todos esos modelos se validaran en X3, Ultra o S100.

OpenExplorer/Algorithm Toolchain importa ONNX o Caffe para PTQ y admite flujos QAT orientados a PyTorch. El despliegue depende de la plataforma: RDK X5 actual usa .bin mediante hbm_runtime sobre libdnn, mientras que el flujo principal actual rdk_s usa .hbm mediante una API hbm_runtime homónima sobre libhbucp; X3 conserva su rama e interfaces de inferencia anteriores. El material previo de rdk_model_zoo_s también describe rutas históricas .bin y .hbm, así que esos artefactos deben emparejarse con su rama y cadena de herramientas correspondientes. Los operadores no compatibles pueden ejecutarse en CPU como alternativa. Los ejemplos públicos son útiles, pero la combinación de versión de RDK OS, firmware de placa, cadena de herramientas y binario del modelo forma parte del contrato de compatibilidad.

AXERA

Las familias AX650/AX630/AX620 de AXERA aparecen en cámaras y placas de IA compactas como la línea MaixCAM de Sipeed. Pulsar2 importa ONNX, realiza calibración y análisis de precisión, y genera .axmodel; AXEngine ejecuta el artefacto.

Los ejemplos oficiales AXERA cubren YOLOv5/6/7/8/9/10/11/13/26, YOLOX y YOLO-World, con compatibilidad de tarea y chip que varía según la plataforma. En destinos compatibles, los ejemplos YOLO26 actuales incluyen detección, pose, segmentación y OBB. Los ejemplos de conversión Pulsar2 muestran el trabajo real: nombres exactos de tensores, cortes de salida, transformaciones de layout, archivos de calibración y ajustes del hardware de destino.

SOPHGO

TPU-MLIR de SOPHGO es uno de los stacks de compilador más atractivos para una integración independiente porque el compilador es de código abierto. Importa ONNX, PyTorch, TFLite y Caffe, reduce y cuantiza grafos, y genera .bmodel para destinos BM o .cvimodel para hardware CV18xx.

El proyecto TPU-MLIR admite flujos FP32, BF16, FP16 e INT8 según el destino. La colección de demostraciones SOPHON menciona YOLOv3/4/5/7/8/9/10/11/12/26, YOLOX, PP-YOLOE, YOLO-World, variantes OBB/segmentación, SSD, CenterNet, RetinaFace, SAM/SAM2 y OCR. Como siempre, una demostración en BM1684X no valida el mismo artefacto en BM1688 o CV18xx.

Huawei Ascend

La línea de inferencia edge de Huawei incluye silicio Ascend 310/310P/310B en productos Atlas 200I y 300I. CANN proporciona el compilador ATC, runtime AscendCL y kernels de operadores específicos del chip; ATC convierte ONNX y otras representaciones fuente en un modelo offline .om.

La documentación actual Atlas 200I DK A2 y los ejemplos CANN proporcionan una ruta YOLOv5 .om para Ascend 310B. El Ascend ModelZoo más amplio y antiguo contiene YOLOv2/3/4/5, YOLOX, YOLOR, SSD, RetinaNet, Mask R-CNN, pose y modelos de segmentación, pero no debe presentarse como si cada entrada se hubiera revalidado en 310B. CANN, kernels, firmware y SoC deben coincidir. Un .om para Ascend310P no es un artefacto Ascend genérico.

Cambricon

Los aceleradores MLU de Cambricon usan Neuware y el motor de inferencia MagicMind. El repositorio público MagicMind Cloud está fijado a MagicMind 1.7 y una matriz MLU370-X4/S4; es evidencia histórica de compatibilidad, no una matriz del SDK actual ni de validación MLU270. El repositorio documenta rutas PyTorch, ONNX, Caffe y Paddle; en 1.7 se eliminó la compatibilidad con TensorFlow aunque se conservan ejemplos históricos de TensorFlow. El portal actual para desarrolladores serie 3 de Cambricon enumera lanzamientos posteriores del SDK general, así que no deben presentarse como una misma versión el repositorio de ejemplos público y el stack comercial actual.

El repositorio oficial de modelos MagicMind Cloud publica una matriz MLU370-X4/S4 excepcionalmente directa. Enumera ejemplos YOLOv3, Tiny-YOLOv3, YOLOv4, YOLOv5, YOLOv7, YOLOv8, PP-YOLOE, SSD, RetinaFace, RetinaNet, Mask R-CNN, DeepLab y UNet, e indica si hay ejemplos C++ o Python. La evidencia es sólida; la principal barrera es el acceso al SDK y los contenedores mediante los canales de Cambricon.

Canaan/Kendryte

Los KPU K230/K230D actuales y K210/K510 heredados de Kendryte son importantes en el extremo de placas económicas y cámaras inteligentes. El compilador nncase importa ONNX o TFLite, usa datos de calibración para conversión de punto fijo, simula el resultado en un host y genera .kmodel.

La guía oficial de desarrollo nncase K230 describe la compilación, simulación y ejecución de YOLOv5s. El catálogo de demostraciones de IA separado incluye artefactos YOLOv8n de detección, segmentación y pose, mientras que el registro de cambios actual de CanMV añade ejemplos optimizados YOLOv8/11/26 de clasificación, detección, segmentación, OBB y pose. El resultado YOLOv5s de la ficha técnica es el benchmark publicado real; las versiones del compilador y del complemento binario KPU deben coincidir con el SDK de la placa.

Allwinner

V853 de Allwinner combina hardware multimedia orientado a cámaras con una NPU Vivante de 1-TOPS. La guía oficial de NPU en inglés describe la importación Acuity/Pegasus, cuantización, verificación y despliegue mediante viplite. Las páginas de modelos de Allwinner y la guía YOLOv5 mencionan YOLOv2/3/4/4-tiny/5/5s, RetinaNet, MobileNet, ResNet y redes de rostros/personas.

Es compatibilidad real con visión artificial, pero sigue ligada a la cadena Tina Linux/Vivante anterior y a descargas de SDK que dependen de una cuenta. Debe figurar en el mapa de mercado con esa limitación explícita.

Plataformas coreanas, taiwanesas y chinas poco conocidas

Las listas en inglés suelen pasar de Rockchip a NVIDIA y omitir una segunda categoría de silicio real y documentado. Algunos de estos ecosistemas tienen matrices YOLO actuales más amplias que startups occidentales más conocidas.

Mobilint

El proveedor coreano de aceleradores Mobilint vende REGULUS de bajo consumo y ARIES MLA100 de mayor rendimiento. Su qb SDK acepta entradas PyTorch, TensorFlow, TFLite, ONNX y orientadas a Keras, cuantiza a INT8 y genera un artefacto compilado .mxq. La matriz pública de visión menciona detección YOLOv3/v5/v7/v8/v9/v10/11/12/26, además de variantes YOLO de segmentación, pose y OBB. La página ARIES incluso publica resultados específicos de YOLO11s y YOLO26m. Es una evidencia sólida de integración, aunque el acceso al SDK/hardware sigue siendo comercial.

Sunplus

SP7350/C3V de Sunplus usa un stack NPU derivado de Vivante, pero lo empaqueta de forma distinta a Allwinner o al Amlogic heredado. Su flujo público combina conversión Acuity, un entorno Docker NPU, runtime SNNF y salida .nb. La guía oficial personalizada de YOLOv8 describe la conversión y el despliegue, en vez de limitarse a afirmar compatibilidad con el framework. Compartir IP relacionada no hace que su .nb sea portable a otro SoC basado en Vivante.

ESWIN Computing

La familia RISC-V de ESWIN incluye EIC7700/EIC7700X y EIC7702/EIC7702X de doble chip, con EIC7700 en placas disponibles como Milk-V Megrez. ENNP contiene EsQuant, el compilador EsAAC actual, generación de datos de referencia, simulación y runtime ESSDK, con salida compilada .model; el material ENNP anterior usaba el nombre ennc-compile. La página actual de EsAAC documenta entrada ONNX, así que otros frameworks deben exportarse o convertirse a esa IR compatible. El resumen ENNP alojado en Milk-V y el tutorial YOLOv3 establecen una ruta pública integral, pero no una matriz amplia y actual de modelos/precisión.

Nuvoton M55M1

M55M1 de Nuvoton es un diseño de clase MCU Cortex-M55 más Ethos-U55-256, no un procesador de aplicaciones Linux. NuEdgeWise/NuML y Arm Vela preparan modelos TFLite Micro cuantizados. El repositorio público NuEdgeWise menciona YOLOv8-nano, YOLOX-nano, YOLO Fastest v1.1, SSD-MobileNet FPNLite y varios clasificadores. Estos ejemplos pequeños son evidencia creíble para la clase de memoria/potencia del dispositivo, no para variantes YOLO estándar de 640 píxeles.

Rebellions y FuriosaAI

La línea ATOM de Rebellions usa el SDK RBLN y artefactos compilados .rbln. Su lanzamiento oficial de compatibilidad menciona YOLOv3 tiny/full/SPP, YOLOv5 n a x, YOLOv6 n a l, variantes YOLOv7 y YOLOv8 n a x. La matriz actual de compatibilidad de tarjetas marca ATOM CA02 y ATOM+ CA12 como EoL, mientras que ATOM+ CA22 y ATOM-Max CA25 están activos. ATOM-Lite CA21 tiene página de producto, pero no aparece en esa matriz del SDK, así que el estado actual de su cadena de herramientas no está claro. La documentación es pública, pero el wheel del compilador requiere credenciales de Rebellions Portal.

FuriosaAI debe dividirse por generación. Warboy es el acelerador de visión anterior, con artefactos INT8 .enf y un zoo oficial de modelos que incluye SSD, YOLOv5M/L y YOLOv7-w6-pose. RNGD usa un stack .fxb distinto, orientado principalmente a cargas LLM/VLM. La hoja de ruta actual de Furiosa registra que la compatibilidad de visión YOLOv8m se completó en 2024 Q4, pero las páginas públicas actuales de modelos compatibles y rendimiento se centran en LLM/VLM y no exponen una matriz detallada de precisión/rendimiento YOLOv8m. Eso evidencia una generación lanzada, no compatibilidad con Warboy.

Realtek, Telechips, T-Head y SigmaStar

Estas cuatro plataformas son reales, pero sus superficies públicas para integrar modelos propios son más limitadas, antiguas o restringidas:

La visión inteligente HiSilicon no es Huawei Ascend

Los SoC de cámara Hi3516CV610/DV500, Hi3519DV500 y Hi3403V100 de HiSilicon exponen un flujo ATC a .om mediante runtimes NNN/SVP-NNN. El zoo oficial de modelos HiSpark menciona YOLOv3/4/5/6/7/8/9/10/11, segmentación/pose YOLO11, OBB/World/segmentación YOLOv8, OCR, profundidad y TinySAM en una matriz específica de destinos, especialmente para Hi3403 y Hi3591P. No demuestra que cada entrada se ejecute en todos los SoC de visión inteligente indicados arriba. Algunas entradas están en la hoja de ruta, así que deben separarse los ejemplos publicados del soporte previsto; el repositorio indica que los modelos ModelZoo suministrados son solo para uso no comercial. Compartir los términos ATC/.om no demuestra compatibilidad de artefactos ni runtime con la línea de productos Ascend basada en CANN.

Empresas de aceleradores emergentes y especializados

MemryX

Los módulos MX3 de MemryX usan una arquitectura de flujo de datos y pueden combinar varios chips. El Neural Compiler acepta modelos ONNX, TensorFlow Lite, Keras y TensorFlow, y genera un paquete DFP que consume el runtime del acelerador. Sus API de runtime admiten canalizaciones mult modelo y de streaming.

La documentación y los ejemplos de MemryX incluyen preprocesamiento y postprocesamiento YOLO optimizados para detección, segmentación y pose. Las notas de versión del SDK mencionan expresamente compatibilidad con YOLOv10, YOLO11 y YOLO26. El material público es útil desde el punto de vista técnico, aunque no presenta una tabla sencilla de modelos/precisión/dispositivo comparable a la de Axelera.

Kneron

Los productos KL520/KL530/KL630/KL720/KL730 de Kneron abarcan aceleradores USB y embebidos pequeños. Kneron PLUS cubre el runtime de aplicación, mientras que Model Toolchain 0.33.1 actual documenta conversión, cuantización, evaluación, simulación y compilación .nef para esos destinos. KL830 aparece en algunas API de runtime PLUS, pero no en la lista actual de destinos del compilador; no debe extenderse a KL830 una afirmación genérica de compilación .nef sin confirmación del proveedor.

El ejemplo YOLO oficial demuestra el proceso con Tiny-YOLOv3, y otros materiales Kneron cubren entrenamiento y despliegue de YOLOv5. La evidencia es creíble, pero más limitada que las matrices YOLO modernas amplias de Hailo, Axelera, Rockchip o DEEPX.

SiMa.ai

MLSoC de SiMa.ai y la plataforma Modalix de 50-TOPS en producción usan el entorno de software Palette. ModelSDK, el compilador MLA y ModelExecutor cubren importación, cuantización, compilación, profiling y ejecución. Según la carga y el producto, las herramientas admiten flujos orientados a INT8, INT16 y BF16.

Las notas de lanzamiento de la empresa mencionan canalizaciones validadas YOLOv7, YOLOv8 para detección/pose/segmentación, YOLOX y segmentación YOLOX, DETR, Mask R-CNN y EfficientDet. No debe ocultarse una limitación actual: las notas Palette SDK 2.1 indican que QAT no funciona debido a una regresión de cuantización Python/PT2E. La solución documentada es crear el ONNX anotado en SDK 2.0 y compilarlo con 2.1. El acceso y la compra siguen orientados a empresas.

También está documentado el límite de despliegue: el flujo de compilación ModelSDK genera un .tar.gz compilado y puede producir un ELF ejecutable, mientras que MPK Tool empaqueta un .mpk desplegable. Estas salidas siguen ligadas al destino MLSoC/Modalix y a la versión Palette.

EdgeCortix

SAKURA-II es un acelerador anunciado de 60-TOPS para visión e IA generativa, compilado mediante el framework de software MERA. EdgeCortix también proporciona tecnología MERA al flujo RUHMI más reciente de Renesas.

El material de producto SAKURA-II establece el hardware y el compilador, y el hardware M.2/PCIe se ofrece mediante solicitud de prueba o pedido. No se encontró una matriz pública actual de compatibilidad YOLO lo bastante precisa. Esa ausencia es información de compra útil: hay que solicitar validación del modelo antes de comprometerse con el hardware.

BrainChip

Akida de BrainChip es un procesador neuromórfico de dominio de eventos, no una NPU convencional de tensores densos. Su entorno MetaTF consta de paquetes Python instalables para creación de modelos, cuantización de pocos bits, conversión, simulación y ejecución en hardware. BrainChip vende ahora un coprocesador AKD1500 disponible en formato M.2, junto con hardware AKD1000 heredado e IP Akida 2.

La ficha actual de modelos Akida 2 menciona un detector YOLOv2 AkidaNet0.5, CenterNet, AkidaUNet y redes de reconocimiento facial. Otro material de compatibilidad incluye FOMO y cargas basadas en eventos. Akida admite pesos y activaciones de muy pocos bits, pero para desplegarlo correctamente puede ser necesaria una conversión consciente de la arquitectura, en vez de tratarlo como otro destino ONNX INT8 genérico. Un resultado del zoo de modelos AKD1000 o Akida 2 no debe atribuirse a AKD1500 hasta que un informe explícito de ajuste/compatibilidad lo valide.

Blaize

Blaize vende productos Pathfinder y Xplorer basados en P1600, con Picasso SDK, NetDeploy y AI Studio como ruta de software. Las páginas de producto tienen claramente como objetivo la visión y Edge AI, pero no hay una matriz de compatibilidad modelo por modelo actual y pública.

Por tanto, esta guía clasifica Blaize como comercial y restringido, en vez de llenar el vacío con afirmaciones comunitarias. Debería exigirse como requisito un informe de compilación y precisión del proveedor para el modelo previsto.

TinyML y visión en dispositivos endpoint

Arm Ethos-U y Alif

Arm licencia IP de NPU Ethos-U55, U65 y U85 a empresas de chips. El compilador Vela toma grafos LiteRT/TFLite cuantizados y reescribe subgrafos compatibles en operaciones personalizadas Ethos-U. Los operadores no compatibles pueden permanecer en CPU, así que «la aplicación se ejecuta» y «toda la red se ejecuta en la NPU» son afirmaciones distintas.

Las implementaciones reales incluyen Ethos-U55 en Alif Ensemble E7, Ethos-U65 en NXP i.MX 93 y Ethos-U85 en sistemas más recientes. El E7 AI/ML AppKit de Alif documenta dos aceleradores ML y demuestra la ruta TFLite a Vela de E7; Ensemble E8 combina un Ethos-U85 y dos NPU Ethos-U55. Alif también publica un benchmark INT8 para detector facial YOLO-Fastest a nivel de familia, a 192 por 192 en Cortex-M55 más Ethos-U55, pero no una matriz amplia de YOLO moderno por destino. Estos sistemas con memoria restringida encajan con redes pequeñas de clasificación y detección, no con cualquier detector de 640 píxeles solo porque pueda expresarse en TFLite.

Infineon PSOC Edge, Himax WiseEye2 y Analog Devices MAX7800x

Las familias PSOC Edge E83 y E84 de Infineon combinan Cortex-M55 con Ethos-U55 y añaden un bloque NNLite separado en el lado M33 de bajo consumo. El manual de arquitectura E84 documenta pesos de 8 bits, activaciones de 8 o 16 bits y un flujo Vela donde los operadores compatibles se convierten en un flujo de comandos de NPU y el trabajo no compatible permanece en CPU. DEEPCRAFT Model Converter acepta rutas TFLite, Keras y PyTorch, mientras que la documentación de arquitectura menciona MobileNetV1/V2 como kernels representativos, no como benchmarks de destino. El E84 AI Kit incluye cámara y usa ModusToolbox, pero el material público aún no ofrece una matriz de compatibilidad YOLO por modelo. Es una plataforma de visión programable real cuya evidencia por modelo está madurando, no un destino de detección general validado.

HX6538 WiseEye2 de Himax también combina Cortex-M55 y Ethos-U55 para visión siempre activa. Su oferta pública de software es excepcionalmente concreta para esta clase de potencia: los ejemplos oficiales de Grove Vision AI Module V2 incluyen detección de objetos YOLOv8n, pose y clasificación de género, detección YOLO11n, face mesh y PeopleNet. La ruta unificada usa TFLite Micro y Vela, y luego CMSIS-NN y kernels de referencia como alternativa cuando es necesario. Son modelos y resoluciones deliberadamente pequeños, no evidencia de que quepa un grafo YOLO convencional de tamaño servidor.

Analog Devices sigue una ruta distinta con los aceleradores CNN MAX78000/MAX78002. La herramienta pública ai8x-synthesis cuantiza una red entrenada y genera código C, pesos y configuración del acelerador específicos del destino, en lugar de un paquete runtime ONNX portable. La evidencia de primera parte incluye identificación facial, detección de códigos QR TinyERSSD en el zoo de modelos ADI y clasificadores de imágenes. Los dispositivos son relevantes para visión en endpoints, pero no se encontró una matriz oficial actual de YOLO moderno.

GreenWaves GAP9

GAP9 combina cómputo RISC-V con el motor neuronal NE16. NNTool importa y cuantiza redes, mientras que AutoTiler y GAP SDK generan código desplegable. El menú de redes neuronales GAP9 público contiene aplicaciones MobileNet, EfficientNet, ResNet, MobileNet SSD, rostro y reconocimiento. GreenWaves también publica un proyecto de detección de personas YOLOX con resultados de precisión y simulación.

Es evidencia TinyML inusualmente transparente, pero el SDK completo solo está disponible para clientes cualificados y los modelos son considerablemente más pequeños que las variantes YOLO convencionales de 640 por 640.

Lattice sensAI

Lattice sensAI es una alternativa FPGA a una NPU fija. sensAI Studio y Neural Network Compiler mapean un grafo compatible a IP aceleradora configurable para dispositivos ECP5, iCE40 UltraPlus, CrossLink-NX, CertusPro-NX, Avant-E y Avant-X. La salida está ligada a la FPGA seleccionada, el modo acelerador, el layout de memoria y el bitstream, no es un modelo runtime portable.

El manual actual de Neural Network Compiler incluye una tabla topológica excepcionalmente directa. Enumera YOLOv1 para ECP5, YOLOv5 y YOLOv8 para modos optimizado/avanzado en CrossLink-NX y CertusPro-NX, y YOLO11 solo con IP en modo Advanced. También incluye SSD, MobileNetV2-SSD, ResNet, ENet, SqueezeDet y otras redes de visión, con las combinaciones no compatibles visibles por familia FPGA. El Advanced CNN Accelerator está dirigido a Avant-E/Avant-X/CertusPro-NX y es IP comercial. Esta es evidencia de la tabla del compilador, no una promesa de que un bitstream admita simultáneamente todas las topologías listadas.

Microchip VectorBlox

El VectorBlox SDK 3.1 público preprocesa y compila redes TFLite INT8 totalmente cuantizadas para IP CoreVectorBlox configurable en FPGA PolarFire SoC. tflite_preprocess y vnnx_compile generan recursos de despliegue .vnnx, .hex y .ucomp, y el repositorio incluye un simulador y un controlador C para el destino. Los grafos TensorFlow, ONNX y OpenVINO deben pasar antes por la ruta documentada de preparación TFLite/INT8.

La matriz actual de tutoriales incluye YOLOv5n, detección, clasificación, OBB, pose y segmentación YOLOv8n, YOLOv9t, variantes YOLO dispersas/comprimidas, MobileNet, EfficientNet-Lite0, ResNet18, MiDaS, FFNet y QuickSRNet. La guía de postprocesamiento C menciona por separado YOLOv2/3/4/5 y decodificadores Ultralytics para detección, pose y OBB. SDK 3.1 actualmente es compatible con PolarFire SoC Video Kit y explícitamente no con el PolarFire Video Kit sin SoC, así que no deben confundirse las demostraciones antiguas de placas con el contrato de destino actual.

El SDK se puede descargar públicamente bajo una licencia específica de Microchip que restringe el software y sus derivados a productos Microchip. Microchip ofrece licencias Libero Silver y CoreVectorBlox gratuitas, pero sujetas a solicitud. El despliegue sigue dependiendo del sistema FPGA: la configuración del acelerador, el bitstream, el firmware, los datos de red generados por SDK y el layout de memoria deben coincidir. Una compilación VectorBlox correcta no convierte el modelo en un binario que se pueda copiar a cualquier diseño PolarFire.

Syntiant

NDP200 de Syntiant está dirigido a inferencia siempre activa de visión, audio y sensores, por debajo del consumo de los SoC Linux normales. La tabla de hardware actual indica que NDP200 está en producción masiva y NDP250 en fase de muestras. La ficha NDP200 documenta compatibilidad con redes CNN, RNN y totalmente conectadas por debajo de 1 mW; el anuncio NDP250 describe, en cambio, reconocimiento de imágenes siempre activo por debajo de 30 mW. «Menos de un milivatio» no debe generalizarse a ambos componentes.

El material público no establece compatibilidad amplia con YOLO, así que el producto debería evaluarse para clasificadores y detectores pequeños siempre activos mediante una evaluación de modelos respaldada por el proveedor, no suponiendo una exportación ONNX genérica.

Google Coral: dos generaciones sin relación directa

Los productos heredados Edge TPU usan Edge TPU Compiler, libedgetpu y PyCoral con modelos TFLite totalmente INT8. Sus repositorios principales Edge TPU y PyCoral están archivados. Es un riesgo real de mantenimiento, pero no un aviso formal de fin de vida del hardware.

Google también mantiene una Coral NPU separada, activa y de código abierto: IP aceleradora RISC-V para integrarla en SoC de bajo consumo. El proyecto público ofrece actualmente RTL, simulación de hardware, una cadena de herramientas y ejemplos ELF. No es una sucesora USB/M.2 directa de Edge TPU y no publica una matriz actual de despliegue YOLO.

Trampas de GPU adyacentes, NPU cliente y cómputo adaptativo

NVIDIA, AMD, Intel y Apple suelen aparecer en búsquedas de NPU, pero no exponen una clase intercambiable de acelerador.

NVIDIA Jetson: Jetson Orin combina una GPU CUDA con núcleos DLA dedicados. TensorRT puede compilar un motor serializado para DLA, pero las capas no compatibles se ejecutan en GPU solo si se habilita explícitamente la alternativa de GPU. La tabla actual YOLO DeepStream cubre YOLOv4/v7/v8/v9/11, pero la mayoría de las entradas son destinos GPU; su entrada explícita ONNX DLA es YOLOv8s INT8. Las restricciones DLA de NVIDIA explican los límites de operadores. Thor marca otra diferencia: la guía de migración DriveOS de NVIDIA indica que se eliminaron los núcleos DLA de Thor en favor de flexibilidad para planificar en GPU. Por tanto, «se ejecuta en Jetson» no identifica el acelerador.

AMD Vitis AI: La antigua generación Kria/DPU compilaba grafos .xmodel ejecutados mediante VART. La versión actual Vitis AI 6.2 es GA para dos rutas independientes Versal AI Edge: Gen1 en VEK280/VE2802 usa ONNX, AMD Quark y un flujo snapshot/subgrafo ligado al destino; Gen2 en VEK385 tiene su propio contrato de compilación y runtime. Gen1 publica ejemplos YOLOv5, YOLOv7, YOLOv8 y YOLOX. Ryzen AI es un cuarto stack de NPU cliente independiente. No traslades artefactos ni validaciones entre DPU heredada, Versal Gen1, Versal Gen2 y Ryzen AI solo porque todos usen el nombre Vitis o AMD.

Intel OpenVINO: OpenVINO puede dirigirse a CPU, GPU y NPU Core Ultra con una API. La documentación del plugin Intel NPU identifica generaciones de NPU compatibles, mientras que la matriz de modelos verificados expone columnas específicas del dispositivo. Un notebook YOLO demuestra una receta de aplicación, no validación NPU salvo que lo indique la matriz. Los operadores, las formas, la precisión y el controlador NPU instalado determinan si el grafo completo se ejecuta allí. OpenVINO IR (.xml más .bin) es una IR fuente reutilizable; una caché de modelo compilado depende del dispositivo y del software.

Apple Core ML: coremltools convierte modelos a .mlpackage, que Xcode compila como .mlmodelc. Core ML puede planificar trabajo entre CPU, GPU y Apple Neural Engine, pero abstrae deliberadamente el particionado exacto. Eso convierte Apple en una plataforma de despliegue excelente y en una mala candidata para afirmar que «todo el grafo YOLO se ejecutó en la NPU» sin que lo demuestre el profiling.

Las empresas de IP NPU que están detrás de las empresas de chips

Algunas empresas no venden placas ni aceleradores empaquetados. Licencian diseños NPU a fabricantes de SoC. Importan porque una misma arquitectura subyacente puede aparecer bajo varias marcas de chips, aunque el SDK y el artefacto finales sigan personalizados por el licenciatario.

Imagination ilustra por qué las etiquetas de acceso y ciclo de vida deben acompañar a los nombres de arquitectura. Su programa Open Access ofrece tres configuraciones Series3NX probadas en silicio sin cuota inicial de licencia IP, pero solo después de evaluar la empresa y con soporte/mantenimiento de pago y royalties de producción. El Neural Compute SDK proporciona herramientas de compilación, optimización, cuantización y runtime; una colaboración oficial con Baidu PaddlePaddle menciona detección PP-YOLOE, clasificación EfficientNet y segmentación HRNet. Esos ejemplos no validan cada configuración Series3NX o Series4, y las páginas individuales actuales de productos Series4 indican que no están disponibles, así que Series4 debe considerarse histórica salvo que ventas confirme lo contrario.

Esta capa explica parecidos aparentes entre familias. No hace portables los artefactos. Dos SoC con IP Vivante o Ethos relacionada pueden tener mapas de memoria, controladores, versiones de compilador, conjuntos de operadores y runtimes del proveedor distintos.

Lo que se despliega realmente: tabla de dependencia del artefacto

El último archivo de la canalización del compilador es donde termina la aparente portabilidad de ONNX. Los nombres y las extensiones cambian con el tiempo, pero la regla práctica se mantiene: conserva el modelo original y los datos de calibración porque, por lo general, el artefacto nativo no se puede trasladar a otra generación de NPU ni reconstruir de forma fiable con otra versión del SDK.

Esta tabla no es solo una chuleta de extensiones. La versión del compilador, el identificador de destino, el controlador, el firmware y el BSP forman parte de la identidad reproducible del modelo. Un futuro exportador LibreYOLO debería escribirlos en un manifiesto legible por máquina junto a cada artefacto.

Acceso a las herramientas y señales de ciclo de vida

La disponibilidad del hardware y el acceso al compilador son independientes. Puede ser fácil comprar una placa mientras que su compilador actual exige un acuerdo de cliente; un SDK público puede estar dirigido a silicio difícil de conseguir. Las siguientes son señales concretas de primera parte, no una clasificación universal de longevidad.

Por qué TOPS no es una guía de compra

Los TOPS máximos pueden servir dentro de un proveedor y una arquitectura, pero las comparaciones entre proveedores suelen ser inválidas salvo que coincidan todos estos factores:

• Precisión numérica, incluidas INT8, INT4, FP16 o un modo mixto
• Si una operación multiply-accumulate cuenta como una o dos operaciones
• Aritmética densa frente a dispersa estructurada
• Resolución de entrada, tamaño del batch y grafo del modelo
• Precisión después de la cuantización
• Latencia solo de NPU frente a toda la canalización de la aplicación
• Transferencias de memoria y ejecución alternativa en host
• Estado térmico y funcionamiento sostenido, no de ráfaga

Un detector es una canalización: captura de imagen, redimensionamiento/letterbox, normalización, transferencia al dispositivo, inferencia neuronal, decodificación, NMS, escalado de coordenadas y lógica de aplicación. Los proveedores suelen publicar solo la parte central de inferencia neuronal. MLPerf Inference Edge resulta valioso porque define escenarios, objetivos de calidad y reglas de medición a nivel de sistema, en vez de comparar por separado cifras de marketing.

Para despliegues YOLO, el registro mínimo creíble de benchmark es:

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

Sin esos campos, dos cifras FPS normalmente miden cosas distintas.

Cómo elegir una NPU para visión artificial

Elige en este orden, no por la cifra más grande impresa en una página de producto.

1. Demuestra la compatibilidad del grafo. Compila el modelo exportado exacto, no un checkpoint del zoo con nombre parecido.
2. Mide la precisión. Valida el artefacto compilado en el dataset real de la tarea después de calibrar y cuantizar.
3. Mide de principio a fin. Incluye conversión de entrada, transferencias, decodificación y NMS.
4. Comprueba el acceso al software. Averigua si el compilador es público, requiere registro o solo está disponible mediante un acuerdo comercial.
5. Fija la matriz de versiones. Registra compilador, runtime, controlador, firmware e identificadores del destino.
6. Comprueba la realidad del sistema operativo. La compatibilidad con Android, Debian, Yocto, Buildroot, RTOS y Windows no es intercambiable.
7. Comprueba suministro y ciclo de vida. Un chip técnicamente excelente es una mala elección para producción si los módulos, controladores o soporte a largo plazo son inciertos.
8. Después compara coste, potencia y rendimiento. Esas mediciones solo tienen sentido cuando el mismo modelo funciona correctamente en ambos destinos.

Puntos de partida prácticos según el caso de uso

Esta tabla es una lista de candidatos de investigación, no una clasificación de rendimiento. La compra, la disponibilidad regional y el modelo concreto pueden invertir el orden.

Qué significa esto para LibreYOLO

El diseño escalable no consiste en decenas de exportadores distintos. Consiste en un contrato de intercambio estricto y adaptadores pequeños de compilador/runtime de cada proveedor:

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

Cada artefacto nativo debería tener un manifiesto complementario con:

• Proveedor, destino de chip y destino de placa
• Versiones de compilador, runtime, controlador y firmware
• Checksum del checkpoint fuente y de ONNX
• Nombres, formas, layout, espacio de color, normalización y dtype de entrada
• Precisión de cuantización, escalas si se exponen y hash de los datos de calibración
• Nombres y formas de tensores de salida y su significado semántico
• Tarea de detección, nombres de clases y si la decodificación/NMS se ejecuta en chip o en host
• Resultados registrados de paridad numérica y precisión de tarea

LibreYOLO ya ofrece exportación ONNX portable, herramientas de cuantización, una exportación RKNN directa pero deliberadamente acotada y un flujo Hailo honesto que utiliza el compilador externo. Según los criterios de esta guía, Amlogic ADLA es un candidato sólido para la siguiente integración: el toolkit es público, la cobertura de modelos se solapa mucho con LibreYOLO y la ruta A311D anterior puede mantenerse explícitamente separada.

La prioridad después de Amlogic debería basarse en el hardware de los usuarios y en la posibilidad de validar la precisión, no solo en la disponibilidad del compilador. DEEPX, Sony IMX500, D-Robotics, AXERA, SOPHGO y Qualcomm son técnicamente atractivos; TI, NXP, ST y Renesas adquieren especial valor cuando socios industriales pueden proporcionar placas y acceso a CI a largo plazo.

En observación: silicio real sin contrato público de integración

Excluir por completo a una empresa puede hacer engañoso un mapa de mercado. Incluirla como «compatible» puede ser peor. Estos proveedores venden, muestrean o han anunciado silicio pertinente, pero la evidencia pública aún no establece una ruta reproducible actual de compilador, artefacto y modelo concreto adecuada para un backend LibreYOLO.

Esta lista de observación se basa deliberadamente en la evidencia. Un proveedor puede pasar a las tablas de despliegue publicando una cadena de herramientas o una ruta de evaluación actuales, un contrato de artefacto específico del destino y al menos un modelo concreto con una receta integral.

Lo que deliberadamente no se ha afirmado

Este artículo no afirma que todos los modelos mencionados funcionen desde cualquier repositorio upstream. Los modelos de los vendor zoos suelen estar modificados, divididos en diferentes nodos de salida o emparejados con postprocesamiento personalizado.

Tampoco convierte estas afirmaciones en declaraciones de compatibilidad:

• Un compilador importa ONNX.
• Un chip anuncia un controlador Android NNAPI.
• Un distribuidor dice que la placa es «compatible con YOLO».
• Un repositorio comunitario ejecuta una variante de un único modelo.
• Un modelo se compila sin errores.
• Un proveedor informa FPS solo de NPU sin un resultado de precisión.

Los aceleradores de los teléfonos Google Tensor y numerosos ASIC personalizados solo para OEM también existen, pero Google no ofrece Tensor como destino de compilador autoservicio general comparable a las plataformas anteriores. La existencia de una empresa, un diagrama de bloques NPU o la aceleración Android no bastan para inventar una afirmación de integración LibreYOLO.

Asimismo, quedan fuera de alcance los aceleradores de nube como Google TPU, AWS Inferentia/Trainium, Microsoft Maia y las tarjetas IA solo para centros de datos. Esta guía trata de hardware que un desarrollador de visión artificial puede desplegar razonablemente en el edge.

Las licencias de modelos son otra capa. Que un proveedor de chips publique una receta de conversión YOLO no concede derechos para usar o redistribuir los pesos upstream, el código de entrenamiento ni el derivado compilado. Hay que comprobar por separado la compatibilidad del hardware, la licencia del SDK y la licencia del modelo para el producto previsto.

Metodología de investigación y correcciones

Para cada empresa, la investigación buscó cuatro tipos de fuentes primarias:

1. Una página de producto o ficha técnica actual que identificara el silicio.
2. Documentación del compilador y runtime que explicara la ruta real de despliegue.
3. Un model zoo, una tabla de compatibilidad o un tutorial integral que nombrara modelos de visión.
4. Una señal de ciclo de vida o acceso que mostrara si los desarrolladores podían obtener realmente las herramientas.

Las organizaciones GitHub de primera parte cuentan como fuentes del proveedor. La documentación de fabricantes de placas se etiqueta como evidencia del ecosistema cuando el fabricante del chip no publica el mismo material. Las afirmaciones de rendimiento de terceros se excluyeron de las tablas comparativas.

Después se volvió a auditar el borrador en pasadas separadas por grupos de proveedores y entre tablas. Esas revisiones volvieron a validar el alcance de destinos, nombres de artefactos, precisión, evidencia del modelo frente al postprocesador, estado de anunciado frente a disponible, etiquetas de ciclo de vida, denominadores de benchmarks y todos los recuentos de entidades. Cuando dos páginas de primera parte entran en conflicto, esta guía lo hace explícito en vez de escoger en silencio el valor más conveniente.

Este mercado cambia rápidamente. Si trabajas para una de estas empresas y un chip, SDK, lista de modelos o estado de acceso es incorrecto, envía a LibreYOLO la URL pública exacta de documentación y su versión. Las correcciones respaldadas por evidencia primaria deberían reemplazar este texto; no deberían hacerlo las afirmaciones de marketing sin documentación.

Preguntas frecuentes

¿Cuántas empresas de NPU para Edge AI existen?

No hay un total universal de empresas porque se solapan los proveedores de productos, los licenciantes de IP, los sensores inteligentes, las GPU y los ASIC automotrices privados. Esta guía no exhaustiva sigue a 69 empresas y ecosistemas de plataforma con chips Edge AI pertinentes, plataformas aceleradoras, IP de NPU licenciable o silicio relevante en observación, a fecha de agosto de 2026.

¿Qué es una NPU?

Una unidad de procesamiento neuronal es hardware especializado para operaciones de redes neuronales, como convoluciones y multiplicación de matrices. Los proveedores usan términos como NPU, AIPU, BPU, KPU, DLA, HTP, TPU y MLA, y los modelos compilados generalmente no son portables entre empresas.

¿Qué empresas de NPU ofrecen compatibilidad oficial con modelos YOLO?

Amlogic, Hailo, Axelera AI, Rockchip, Qualcomm, MediaTek, DEEPX, D-Robotics, AXERA, SOPHGO, Huawei, Cambricon, Sony IMX500 mediante el repositorio oficial de Raspberry Pi AI Camera, STMicroelectronics, Renesas, Lattice, Himax, Microchip y otras empresas tienen entradas de primera parte en model zoos, tutoriales o resultados validados para al menos una generación de YOLO. La generación, tarea, chip de destino y versión del SDK concretos siguen siendo importantes.

¿Se puede ejecutar cualquier modelo ONNX en cualquier NPU?

No. ONNX es un formato de intercambio, no una garantía de compatibilidad con el hardware. El compilador de NPU debe admitir todos los operadores, las formas de tensores y los tipos de datos del grafo. Son habituales las formas estáticas, los cortes de grafo, las operaciones personalizadas y la ejecución alternativa en CPU.

¿Cuál es la mejor NPU para YOLO?

No hay un ganador universal. Hailo, Rockchip, Axelera AI, DEEPX y Amlogic tienen una amplia compatibilidad documentada con YOLO, mientras que Qualcomm ofrece un alcance excepcional de dispositivos. Elige según la precisión tras la cuantización, la latencia de toda la canalización, la potencia sostenida, el precio, la disponibilidad, el acceso al SDK y la compatibilidad con el sistema operativo.

¿Por qué no se pueden comparar directamente las cifras TOPS de las NPU?

Los proveedores pueden contabilizar precisiones, operaciones dispersas, operaciones multiply-accumulate y supuestos de utilización máxima distintos. TOPS no refleja el tráfico de memoria, los operadores no compatibles, el preprocesamiento, el postprocesamiento ni la carga del host. Compara el mismo modelo, precisión, resolución, precisión y canalización completa.

¿Qué es la calibración de una NPU?

La calibración ejecuta imágenes representativas, normalmente sin etiquetar, del despliegue a través del modelo para que el compilador estime los rangos de activación de INT8 u otro formato de baja precisión. Las imágenes aleatorias o poco representativas pueden generar un artefacto compilado y, aun así, perjudicar la precisión de la tarea.

¿LibreYOLO es compatible con NPU edge?

LibreYOLO exporta a ONNX y varios formatos de runtime, tiene una ruta directa al compilador RKNN para algunos modelos Rockchip y documenta el flujo externo de compilación para Hailo. Cualquier otro artefacto nativo de proveedor sigue necesitando su SDK y debe describirse como candidato a integración hasta que se compile, valide y ejecute en hardware.