Link to this sectionExportación a Hailo para modelos YOLO de Ultralytics#

Los aceleradores de IA Hailo ejecutan modelos compilados en formato Hailo Executable Format (HEF) en dispositivos de borde como el Raspberry Pi AI Kit y el AI HAT+. Ultralytics exporta modelos de detección, segmentación, pose, OBB, clasificación, segmentación semántica y estimación de profundidad de YOLO directamente a HEF con el compilador Hailo Dataflow Compiler (DFC).

El despliegue de Hailo está diseñado para visión artificial en el borde (edge): cámaras, robots, sistemas industriales, pasarelas y otros dispositivos que necesiten detección de objetos local sin enviar cada fotograma a la nube. Un HEF compilado contiene la red cuantizada, la asignación de hardware, la programación y el post-procesamiento de HailoRT opcional necesario para el acelerador seleccionado.

Link to this section¿Por qué implementar Ultralytics YOLO en Hailo?#

Combinar Ultralytics YOLO con una unidad de procesamiento neuronal (NPU) de Hailo proporciona una ruta práctica desde el entrenamiento del modelo hasta la inferencia de IA en el borde (edge) de bajo consumo. Los casos de uso comunes incluyen:

• Cámaras inteligentes y analítica de vídeo: Ejecuta detección de objetos en tiempo real cerca de la cámara para aplicaciones de seguridad, venta al por menor, tráfico y ocupación.
• Robótica y sistemas autónomos: Detecta personas, vehículos, paquetes, herramientas u obstáculos sin depender de una conexión constante a la nube.
• Visión artificial industrial: Implementa modelos YOLO personalizados para inspección, recuento, monitorización de seguridad y control de calidad.
• Proyectos de Raspberry Pi AI: Añade inferencia de visión acelerada a sistemas Raspberry Pi usando el AI Kit o el AI HAT+.
• Pasarelas de borde (edge) y PCs con IA: Procesa múltiples flujos de vídeo o sensores localmente mientras reduces los requisitos de ancho de banda y computación en la nube.

La inferencia local puede mejorar la privacidad y el tiempo de respuesta porque las imágenes permanecen en el dispositivo de despliegue. El rendimiento, la latencia y el consumo de energía reales dependen del tamaño del modelo YOLO, la resolución de entrada, la arquitectura de Hailo, el sistema anfitrión y la canalización de la aplicación.

Link to this sectionCómo funciona la exportación a Hailo#

Ultralytics posee el flujo de trabajo de exportación completo detrás de format="hailo":

YOLO (.pt) -> ONNX -> Hailo parse -> INT8 optimization -> HEF compile

El exportador realiza estas etapas automáticamente:

1. Exporta un gráfico ONNX estático con ajustes compatibles con el compilador.
2. Selecciona las salidas de las cabeceras para la arquitectura del modelo.
3. Genera directivas de normalización, activación y post-procesamiento.
4. Construye un flujo de calibración representativo y cuantiza el modelo a INT8.
5. Compila el gráfico optimizado para el acelerador Hailo seleccionado.
6. Guarda el HEF con metadatos de Ultralytics y elimina el archivo ONNX intermedio.

Los modelos de detección YOLOv8 y YOLO11 utilizan HailoRT YOLO NMS en el pipeline compilado. Los modelos de detección YOLO26 emplean sus salidas uno a uno sin NMS, por lo que el exportador selecciona de forma automática otra ruta de salida y cuantización. La segmentación, la pose y el OBB de YOLOv8/YOLO11 compilan los tensores de la cabecera original, los cuales Ultralytics decodifica en la inferencia, y la clasificación de YOLOv8/YOLO11/YOLO26 ejecuta la función softmax en el chip para que el archivo HEF devuelva las probabilidades de las clases directamente. Para la segmentación semántica de YOLO26, el exportador sigue al acelerador: Hailo-8/8L (DFC v3.x) devuelven logits de clasificador para el muestreo ascendente y la reducción en el host, mientras que Hailo-10/15 (DFC v5.x) compilan cabeceras ArgMax multiclase en el chip y devuelven un mapa de clases compacto. Las cabeceras monoclase utilizan la ruta de logits del host en todos los objetivos porque requieren un umbral en lugar de ArgMax. Los modelos de profundidad de YOLO26 compilan la convolución densa de logits en a16 y reconstruyen el mapa de profundidad métrica en el host (la sujeción/exponenciación y la calibración log-afín aprendida que siguen a la cabecera), por lo que el cuantizador mantiene su rango más amplio en el logit original. Los usuarios no necesitan buscar nodos finales de ONNX, escribir un script de modelo de Hailo (.alls) ni crear un JSON de NMS de forma manual.

Link to this sectionInstalación#

Instala Ultralytics y descarga el archivo wheel del DFC para tu hardware objetivo desde la Hailo Developer Zone (se requiere registro gratuito):

pip install ultralytics
pip install /path/to/hailo_dataflow_compiler-*.whl

Hailo-8 y Hailo-8L utilizan DFC v3.x. Hailo-10 y Hailo-15 utilizan DFC v5.x. Instala la generación del compilador que coincida con el acelerador de destino.

Link to this sectionExportar un modelo HEF de Hailo#

Usa format="hailo" y selecciona el acelerador de destino con name:

from ultralytics import YOLO

model = YOLO("yolo11n.pt")
output = model.export(format="hailo", name="hailo8l")
print(output)  # yolo11n_hailo_model/

El comando CLI equivalente es:

yolo export model=yolo11n.pt format=hailo name=hailo8l

La exportación a Hailo es solo INT8. Ultralytics descarga automáticamente un conjunto de datos de calibración específico para la tarea cuando no se proporciona data. Para modelos personalizados, utiliza imágenes representativas de entrenamiento o validación:

model.export(format="hailo", name="hailo8l", data="path/to/dataset.yaml")

La compilación utiliza una forma de entrada fija. Ajusta imgsz a la resolución utilizada en el dispositivo:

model.export(format="hailo", name="hailo8l", imgsz=640)

Link to this sectionModelos y hardware compatibles#

El ecosistema de Hailo abarca una amplia gama de cargas de trabajo de visión artificial, pero el exportador format="hailo" de Ultralytics valida actualmente cabeceras estándar de YOLO para detección, segmentación, pose, OBB, clasificación, segmentación semántica y estimación de profundidad. La tabla de tareas describe las rutas de exportación disponibles; la validación de hardware se enumera por separado a continuación.

Familias de detección especializadas como YOLOv10, YOLO-World, YOLOE y RT-DETR también están ❌ no soportadas. Ultralytics rechaza estas tareas y familias de modelos antes de la compilación en lugar de producir un HEF no validado.

Pose, OBB, clasificación, segmentación semántica de YOLO26 y estimación de profundidad de YOLO26 (ruta Hailo-8/8L) fueron validadas en Hailo-8L con HailoRT 4.23 y DFC 3.33. El exportador acepta los demás objetivos enumerados, pero esas nuevas rutas de tareas requieren validación con el compilador y el dispositivo correspondientes antes de su uso en producción.

Selecciona uno de estos valores de name:

hailo8l es el valor por defecto. Instala la generación del DFC que coincida con el objetivo seleccionado.

Link to this sectionGeneraciones de hardware y SDK de Hailo#

Las familias de aceleradores de Hailo utilizan diferentes generaciones de compiladores. El HEF generado debe coincidir con el hardware de destino, así que elige el name para el dispositivo que ejecutará la inferencia, no para la máquina que realiza la exportación.

El compilador se ejecuta en Linux x86_64, mientras que el HEF resultante se ejecuta en el dispositivo Hailo a través de HailoRT. Esta separación te permite compilar en una estación de trabajo o en Ultralytics Platform y desplegar el pequeño artefacto de tiempo de ejecución en un host de borde (edge) ARM o x86.

Link to this sectionNotas de compatibilidad#

La compilación en Hailo es específica del hardware y utiliza una forma de entrada fija. Ten en cuenta estas restricciones:

• El name seleccionado debe coincidir con el acelerador de despliegue.
• Las imágenes de calibración deben representar la iluminación, los puntos de vista, los objetos y los fondos esperados en producción.
• Un HEF compilado con un imgsz no se vuelve redimensionable dinámicamente en tiempo de ejecución.
• Los recuentos de clases personalizados son compatibles porque Ultralytics genera la configuración de post-procesamiento a partir de los metadatos del modelo.
• Se admiten modelos de detección con cabeceras Detect estándar de Ultralytics, modelos de segmentación, pose y OBB de YOLOv8/YOLO11, modelos de clasificación de YOLOv8/YOLO11/YOLO26, y modelos de segmentación semántica y estimación de profundidad de YOLO26; la segmentación de instancias, la pose y el cuadro delimitador orientado (OBB) de YOLO26, junto con las exportaciones de YOLO-World, YOLOE, YOLOv10 y RT-DETR, no son compatibles actualmente.
• Los artefactos Hailo-8/8L y Hailo-10/15 son compilados por diferentes generaciones de DFC y no son intercambiables.

Link to this sectionCalibración y cuantización INT8#

La exportación a HEF de Hailo utiliza cuantización INT8 para mapear la red YOLO eficientemente sobre el acelerador. El conjunto de datos de calibración estima los rangos de activación; no reentrena el modelo ni requiere etiquetas durante la compilación.

Cuando se omite data, Ultralytics utiliza un conjunto de datos de calibración ligero específico para la tarea, como COCO128 para detección, cityscapes8 para segmentación semántica o depth8 para estimación de profundidad. La cabecera de profundidad densa es especialmente sensible al dominio de calibración: calibrar un modelo de profundidad con imágenes de detección no relacionadas aplana el mapa predicho, y los conjuntos en el dominio más grandes mejoran la fidelidad. Para un modelo de visión artificial personalizado, apunta data al YAML de su conjunto de datos para que el compilador observe imágenes representativas del dominio de implantación real:

model.export(format="hailo", name="hailo8l", data="my_dataset.yaml")

fraction selecciona la porción del conjunto de datos utilizada para la calibración. Más imágenes solo ayudan cuando representan el dominio de despliegue; las imágenes fuera de dominio pueden reducir la precisión cuantizada y aumentar el tiempo de optimización. Si el HEF INT8 pierde precisión en relación con el modelo original de PyTorch, primero mejora los datos de calibración antes de cambiar los ajustes del modelo o del entorno de ejecución.

Link to this sectionExpectativas de precisión por familia de modelo#

Medido en un Hailo-8L con calibración en dominio (COCO128, 128 imágenes), las exportaciones HEF en INT8 retienen la siguiente proporción de su mAP50 de PyTorch bajo el mismo protocolo de evaluación:

La retención compara ambos modelos al mismo umbral de confianza. Los HEF de YOLOv8 y YOLO11 incorporan el conf de tiempo de exportación (predeterminado 0.25) en el NMS en chip, por lo que validar frente a una línea base de PyTorch en su umbral bajo predeterminado integra una mayor parte de la curva precisión-exhaustividad y sobreestima la brecha de cuantización.

Más allá de la detección, las rutas de exportación de segmentación, pose, OBB y clasificación se validaron en el mismo Hailo-8L (DFC 3.33, HailoRT 4.23). Cada HEF INT8 se comparó con su checkpoint de PyTorch en la misma partición de validación, utilizando calibración in-domain:

La segmentación, la pose y el OBB se calibraron con el conjunto in-domain predeterminado de cada tarea (COCO128-seg, COCO8-pose, DOTA128); la clasificación se calibró con ImageNet100. De estos valores predeterminados se derivan dos advertencias: COCO8-pose solo tiene 8 imágenes, por lo que debes tratar la pose como algo indicativo y pasar un data= más grande para producción, y DOTA8 satura el mAP50 cerca del 100 % para ambos modelos, razón por la cual el OBB se lee en DOTA128. La clasificación es también la única tarea en la que YOLO11 retiene más que YOLOv8; para las otras, el backbone de atención de YOLO11 es más sensible a INT8.

De las mediciones del dispositivo se derivan tres reglas prácticas:

1. Calibra siempre en dominio. El ajuste fino con imágenes fuera de dominio es equivalente a desactivar el ajuste fino por completo: un YOLO26n calibrado con 1,238 imágenes fuera de dominio retiene la misma precisión (85.7%) que uno compilado sin ajuste fino. Un conjunto pequeño en dominio supera a uno grande fuera de dominio.
2. Reduce conf aproximadamente 0,05 para despliegues de YOLO26. La cuantización desplaza las puntuaciones de YOLO26 hacia abajo aproximadamente 0,05 de media, por lo que un umbral ajustado en PyTorch descarta detecciones válidas en el HEF. Usar conf=0.20 en el dispositivo iguala el recuento de detecciones de PyTorch a conf=0.25, y bajarlo un poco más (alrededor de conf=0.15) recupera esencialmente toda la brecha de mAP50 restante a costa de más detecciones de baja confianza. La cuantización también reordena aproximadamente el 20 % de las detecciones —un efecto de ordenación permanente que ningún umbral deshace—, pero ese reajuste no bloquea la recuperación del mAP50 en el umbral más bajo.
3. La penalización por atención es estructural en Hailo-8/8L (DFC 3.33). Los bloques de atención se compilan como operaciones matmul que mantienen las entradas de activación INT8 en todos los modos que ofrece el compilador para ellas; el modo de salida de 16 bits falla en la asignación para este gráfico, y aumentar la precisión de las capas circundantes no ayuda porque la matmul requantiza sus entradas a INT8 de todos modos (proteger las convoluciones de profundidad y salida a 16 bits dejó el mAP sin cambios en nuestras pruebas). Cuando la prioridad es la precisión y el modelo es intercambiable, YOLO11 cuantiza actualmente mejor que YOLO26 aquí; las generaciones más nuevas de Hailo (DFC 5.x) exponen más opciones de precisión mixta y pueden diferir.

Link to this sectionArtefactos exportados#

La exportación crea un directorio que contiene el HEF desplegable y los metadatos de Ultralytics:

yolo11n_hailo_model/
├── yolo11n.hef
├── metadata.yaml
└── nms_config.json

• *.hef es el modelo compilado cargado por HailoRT.
• metadata.yaml conserva los nombres del modelo, la tarea, el tamaño de entrada, el stride y la información del objetivo de Hailo.
• nms_config.json registra la configuración de HailoRT NMS generada para modelos de detección YOLOv8 y YOLO11. La detección de YOLO26 y todas las tareas que no sean de detección (segmentación, pose, OBB, clasificación, semántica) no utilizan este archivo.

El gráfico ONNX intermedio se elimina tras la compilación.

Link to this sectionEjecutar inferencia en hardware Hailo#

Instala HailoRT en el dispositivo de destino. Los usuarios de Raspberry Pi AI Kit y AI HAT+ pueden seguir la guía de software de Raspberry Pi AI:

sudo apt install hailo-all
hailortcli fw-control identify

Copia el directorio de exportación completo al dispositivo para que metadata.yaml permanezca junto al HEF. Ultralytics utiliza HailoRT para ejecutar predict y val directamente en el directorio exportado:

from ultralytics import YOLO

model = YOLO("yolo11n_hailo_model")
results = model.predict("path/to/image.jpg")

Para modelos de detección, el backend convierte la salida de HailoRT NMS de YOLOv8 y YOLO11 y decodifica automáticamente las salidas uno a uno de YOLO26. Decodifica tensores brutos de segmentación, pose y OBB, devuelve probabilidades de clasificación en el chip y produce mapas de clases semánticas a través de la reducción del host en Hailo-8/8L y todas las cabeceras de clase única, o un ArgMax en el chip para cabeceras multiclase de Hailo-10/15. TAPPAS, GStreamer y el asistente picamera2.devices.Hailo de Raspberry Pi permanecen disponibles para canalizaciones específicas de aplicaciones.

Para un despliegue en GStreamer, pasa el HEF a hailonet:

gst-launch-1.0 filesrc location=video.mp4 ! decodebin ! videoconvert ! \
  hailonet hef-path=yolo11n_hailo_model/yolo11n.hef ! \
  hailofilter function-name=yolov8 ! hailooverlay ! autovideosink

Link to this sectionOpciones de despliegue en Hailo#

El HEF es el mismo artefacto de modelo desplegable a través de varias interfaces de tiempo de ejecución de Hailo. Elige la interfaz que se ajuste a la aplicación:

Conserva metadata.yaml junto al HEF cuando la aplicación necesite nombres de clase, tamaño de entrada, stride u otra información del modelo de Ultralytics. El HEF en sí no reemplaza la lógica a nivel de aplicación para captura de cámara, visualización, seguimiento, alertas o almacenamiento.

Link to this sectionVerifica el dispositivo Hailo y el HEF#

Antes de integrar una cámara o una tubería de vídeo, verifica de forma independiente el tiempo de ejecución y el acelerador:

hailortcli fw-control identify
hailortcli parse-hef yolo11n_hailo_model/yolo11n.hef

Las mediciones de rendimiento solo del dispositivo aíslan la inferencia de Hailo de la decodificación de vídeo, el redimensionamiento de imágenes, el dibujo y la E/S de la aplicación. Mide la aplicación completa por separado al estimar la latencia de extremo a extremo o los fotogramas por segundo.

Link to this sectionHailo en comparación con otros formatos de exportación de YOLO#

Elige un formato de exportación basado en el hardware que ejecutará el modelo:

HEF es la elección correcta cuando el dispositivo final contiene un acelerador Hailo. ONNX sigue siendo útil como formato de intercambio portátil, pero HailoRT ejecuta el HEF específico de hardware producido por el DFC en lugar del modelo ONNX original.

Link to this sectionOptimiza el rendimiento de la visión artificial de Hailo#

Las elecciones de modelo y tubería a menudo importan más que las banderas del compilador:

• Comienza con un modelo YOLO pequeño y aumenta el tamaño del modelo solo cuando la precisión lo requiera.
• Elige el imgsz fijo más bajo que aún conserve los objetos importantes para la aplicación.
• Usa imágenes de calibración de la cámara y el entorno reales cuando sea posible.
• Mantén activa la red de Hailo a través de los fotogramas en lugar de volver a abrir el HEF para cada inferencia.
• Separa el tiempo de inferencia del dispositivo del preprocesamiento, la decodificación de vídeo, el posprocesamiento, la visualización y la E/S de red.
• Usa una tubería de streaming como GStreamer para cargas de trabajo de vídeo sostenidas.
• Valida el HEF exportado en el acelerador exacto y la versión de HailoRT utilizada en producción.

Link to this sectionArgumentos de exportación#

Para la exportación de detección, YOLOv8 y YOLO11 reciben HailoRT NMS, mientras que YOLO26 mantiene sus salidas uno a uno sin NMS. La segmentación, la pose y el OBB utilizan tensores de cabecera originales, la clasificación devuelve probabilidades en el chip y la segmentación semántica devuelve logits originales en Hailo-8/8L y todas las cabeceras monoclase o mapas de clases integrados para las cabeceras multiclase de Hailo-10/15. La estimación de profundidad devuelve el logit de profundidad original, que Ultralytics decodifica en un mapa de profundidad métrica en la inferencia. No pases end2end; las anulaciones explícitas se rechazan. Las formas dinámicas, los lotes superiores a uno, el NMS de Ultralytics integrado, FP16 y FP32 tampoco son compatibles.

Link to this sectionSolución de problemas de exportación de Hailo#

Link to this sectionError de importación del compilador Hailo Dataflow#

Si la exportación informa que falta hailo_sdk_client, instala el wheel del DFC para la generación de hardware de destino en el mismo entorno de Python que Ultralytics. Hailo-8/8L y Hailo-10/15 requieren diferentes generaciones de compilador.

Link to this sectionSistema operativo o arquitectura no compatible#

La compilación de HEF es compatible con Linux x86_64. Exporta a través de Ultralytics Platform o utiliza una estación de trabajo compatible si el ordenador local es macOS, Windows, Raspberry Pi u otro sistema ARM.

Link to this sectionLa exportación tarda mucho tiempo#

La optimización del DFC es la etapa más costosa. El tiempo de compilación aumenta con el tamaño del modelo, la resolución de entrada y los datos de calibración. Una GPU compatible puede acelerar la optimización, mientras que la compilación solo con CPU puede ser sustancialmente más lenta.

Link to this sectionLa precisión del modelo cuantizado cae#

Usa imágenes de calibración que se parezcan a las entradas de producción e incluyan los objetos, escalas, condiciones de iluminación y fondos importantes. Compara el modelo original de PyTorch y el HEF exportado en el mismo conjunto de validación antes del despliegue. Permanece una brecha moderada dependiente de la familia incluso con una buena calibración; consulta Expectativas de precisión por familia de modelo para ver las líneas base medidas.

Link to this sectionEl HEF no se carga en el dispositivo#

Confirma que name coincide con la arquitectura física de Hailo y que el controlador del dispositivo, el firmware y los paquetes de HailoRT son mutuamente compatibles. Inspecciona el artefacto con hailortcli parse-hef y verifica el acelerador con hailortcli fw-control identify.

Link to this sectionEl análisis de salida parece incorrecto#

Mantén metadata.yaml junto al HEF para que Ultralytics pueda seleccionar la ruta de posprocesamiento correspondiente para YOLOv8, YOLO11 o YOLO26. Las aplicaciones personalizadas de HailoRT deben, del mismo modo, hacer coincidir el posprocesamiento con la familia del modelo exportado.

Link to this sectionFAQ#

Link to this section¿Puedo compilar un HEF en una Raspberry Pi?#

No. Ejecuta el DFC en un sistema Linux x86_64 compatible y despliega el HEF resultante en la Raspberry Pi.

Link to this section¿Necesito una GPU NVIDIA?#

Una GPU compatible reduce en gran medida el tiempo de optimización del DFC. La compilación con CPU es posible, pero puede tardar sustancialmente más.

Link to this section¿Qué modelos YOLO admiten la exportación a Hailo?#

La exportación directa es compatible con modelos de detección con la cabecera de detección estándar de YOLOv8, YOLO11 o YOLO26, modelos de segmentación, pose y OBB de YOLOv8/YOLO11, y modelos de clasificación de YOLOv8/YOLO11/YOLO26. Esto incluye modelos entrenados a medida creados a partir de esas arquitecturas estándar. Los modelos de segmentación semántica y estimación de profundidad de YOLO26 también son compatibles. La segmentación de instancias, la pose y el OBB de YOLO26, junto con YOLOv10, YOLO-World, YOLOE y RT-DETR, se rechazan en lugar de producir un HEF no validado.

Link to this section¿Puedo exportar un modelo YOLO entrenado a medida?#

Sí. Utiliza el mismo comando format="hailo" con los pesos .pt personalizados y pasa el YAML del conjunto de datos de entrenamiento a través de data para una calibración INT8 representativa. Los nombres de clase y el recuento de clases se leen de los metadatos del modelo.

Link to this section¿Admite la exportación de Hailo tamaños de imagen dinámicos?#

No. El DFC compila una forma de entrada fija en el HEF. Elige imgsz durante la exportación para que coincida con la resolución utilizada por la tubería de despliegue.

Link to this section¿Por qué YOLO26 produce salidas de Hailo diferentes?#

YOLO26 utiliza un cabezal de detección uno a uno sin NMS. Ultralytics compila esos tensores de salida directamente en lugar de adjuntar el NMS estilo YOLOv8 de HailoRT utilizado para YOLOv8 y YOLO11.

Link to this section¿Cuál es la diferencia entre el DFC y HailoRT?#

El compilador Hailo Dataflow convierte y cuantiza el modelo en un HEF específico de hardware en una máquina de construcción Linux x86_64. HailoRT carga y ejecuta ese HEF en el dispositivo de destino.

Link to this section¿Debo desplegar el archivo ONNX o el HEF?#

Despliega el HEF compilado en el tiempo de ejecución de Hailo. ONNX es una representación intermedia utilizada durante la exportación y se elimina después de una compilación exitosa.

Link to this section¿Dónde puedo obtener el DFC de Hailo?#

Descarga el wheel del compilador para tu generación de hardware desde la zona de desarrolladores de Hailo. El compilador es necesario solo para crear el HEF; HailoRT lo ejecuta en el acelerador de destino.

Link to this sectionResumen#

La exportación a Hailo de Ultralytics proporciona una ruta directa desde un modelo YOLO entrenado hasta un HEF desplegable:

1. Carga un modelo de detección o clasificación de YOLOv8, YOLO11 o YOLO26, un modelo de segmentación, pose u OBB de YOLOv8/YOLO11, o un modelo de segmentación semántica o estimación de profundidad de YOLO26.
2. Exporta con format="hailo" y selecciona la arquitectura de destino.
3. Calibra y compila localmente con el DFC correspondiente, o utiliza la exportación gestionada en Ultralytics Platform.
4. Copia el HEF y metadata.yaml al dispositivo de borde impulsado por Hailo.
5. Ejecuta la inferencia con HailoRT, Raspberry Pi Picamera2 o una pipeline de vídeo de GStreamer.

Para otros objetivos de despliegue de visión artificial, consulta el modo Exportación, el modo Benchmark y la guía de integraciones. Las guías de hardware relacionadas incluyen ONNX, OpenVINO, TensorRT, NCNN, RKNN, Sony IMX500 y Qualcomm QNN.