¿Qué pasos se requieren para migrar los algoritmos de visión de ensamblaje a una NPU Ascend?

Artículo técnico

Migrar el algoritmo de visión de ensamblaje a Ascend NPU no significa copiar los archivos del modelo original al dispositivo Atlas, sino completar la adaptación del sistema del formato del modelo, operadores, entrada y salida, interfaz de tiempo de ejecución y criterios de aceptación. La ruta típica es: corregir la línea de base del modelo original, exportar ONNX, verificar la estructura del gráfico y los operadores, usar ATC para generar el modelo OM para el procesador Ascend de destino, acceder a la inferencia a través de AscendCL y luego completar la verificación de la coherencia del procesamiento previo y posterior, los resultados de la detección, el rendimiento de ejecución y la entrega de la versión.

El software de inspección visual de ensamblaje y las aplicaciones de algoritmos de Winge Technology ya se están ejecutando en Huawei Ascend Atlas 200I DK A2. Para proyectos que utilizan modelos de clasificación, detección de objetos o segmentación, se pueden agregar enlaces de inferencia del modelo Ascend NPU según el acceso a la cámara existente, la configuración ROI, la grabación de resultados y la implementación local.

¿Qué insumos deben corregirse antes de la migración?

Antes de iniciar la migración, se debe formar un paquete de referencia reproducible, que incluya al menos:

Marco de formación original, estructura del modelo, pesos y scripts de exportación;
Nombre de entrada, tamaño de entrada, tipo de datos y requisitos de dimensión dinámica para los modelos ONNX;
Métodos de ordenación, escalado, recorte, normalización y disposición de tensores de colores de imágenes;
Etiquetas de clasificación, decodificación de cuadros de detección, umbrales de confianza, NMS o reglas de procesamiento post-segmentación;
Un conjunto fijo de muestras OK, NG y de límites y sus resultados esperados;
Dispositivo Target Atlas, modelo de procesador Ascend, sistema operativo, CANN y versión del paquete del operador;
Indicadores de aceptación del proyecto como precisión, detecciones perdidas, falsas alarmas, consumo de tiempo único, rendimiento y memoria.

Si estas entradas no se corrigen, incluso si la conversión del modelo es exitosa, no será posible determinar si la diferencia antes y después de la migración proviene del modelo, el preprocesamiento, el posprocesamiento o el entorno de versión.

Paso 1: Establecer una línea de base de los resultados del modelo original

Utilice el mismo conjunto de imágenes de aceptación para ejecutar el modelo original y guardar los tensores de entrada, la salida original, los resultados del posprocesamiento y las decisiones comerciales finales. El proyecto de detección de objetos también debe guardar el marco de detección, la categoría, la confianza y los resultados de NMS; el proyecto de segmentación debe guardar el tamaño de la máscara, el mapeo de categorías y los resultados del contorno.

La función de la línea de base no es proporcionar una tasa de precisión unificada, sino proporcionar una base de comparación muestra por muestra para resultados posteriores de ONNX y OM. Los indicadores del proyecto deben determinarse basándose en muestras de clientes, definiciones de defectos y condiciones de la estación de trabajo.

Paso 2: exportar e inspeccionar el modelo ONNX

Después de exportar ONNX desde el marco de capacitación, debe verificar:

¿Son estables los nombres de los nodos de entrada y salida?
Si el tamaño de entrada es un tamaño fijo o un tamaño dinámico;
Si la versión del operador y la estructura del gráfico se ajustan al entorno de conversión de destino;
Si incluir nodos que solo se utilizan durante la fase de entrenamiento;
Si los resultados de ejecución de ONNX y los resultados del modelo original están dentro del rango de error acordado.

En este paso, primero debe resolver el problema de exportación del modelo en sí y luego ingresar a la conversión del lado de Ascend para evitar llevar las diferencias del modelo de origen al lado del dispositivo.

Paso 3: Verifique la compatibilidad del operador y la estructura del gráfico

Antes de la conversión ATC, se deben verificar los operadores, atributos, tipos de datos y restricciones de forma utilizados por el modelo. Si hay operadores o combinaciones no admitidos, puede elegir la reescritura de gráficos, el reemplazo de operadores equivalentes, la división y el posprocesamiento, u operadores personalizados según la estructura del modelo. No debe utilizar simplemente "ejecución del comando de conversión completada" como criterio de finalización de la adaptación.

Para lotes dinámicos, tamaño de imagen dinámico o dimensiones dinámicas, los engranajes correspondientes deben configurarse de acuerdo con la entrada real de la estación de trabajo. Las estaciones de ensamblaje con cámaras fijas y dimensiones de detección fijas generalmente pueden usar formas fijas primero para reducir el tiempo de ejecución de las ramas y facilitar la aceptación.

Paso 4: use ATC para generar el modelo OM

La documentación oficial de Ascend de Huawei indica que ATC se utiliza para convertir modelos de marco de código abierto como ONNX en modelos fuera de línea OM que pueden ser reconocidos por el procesador Ascend AI. Una estructura de comando típica es la siguiente:

atc --model=model.onnx 
--marco=5
--salida=model_atlas 
--input_shape="imágenes:1,3,H,W" 
--soc_version=<modelo de procesador Ascend de destino>

Los parámetros reales deben ser consistentes con la entrada del modelo, el procesador de destino y el entorno del proyecto. Durante la conversión, se deben guardar el SHA-256 del comando ATC, la versión del entorno, el registro de conversión, el informe de inspección y el archivo generado para rastrear y reproducir el proceso de construcción del modelo OM.

Paso 5: Conéctese al enlace de inferencia de AscendCL

Una vez generado el modelo OM, la inicialización de recursos, la selección de dispositivos, la carga del modelo, la gestión de la memoria de entrada y salida, la ejecución del modelo, la lectura de resultados y la liberación de recursos deben completarse en la aplicación del lado del dispositivo. La ruta de datos completa para un sistema de visión de ensamblaje suele ser:

Cámara industrial o archivos de imagen.
-> Decodificación, recorte y control de calidad de imagen.
-> cambio de tamaño, conversión de color, normalización y disposición de tensores
-> razonamiento del modelo OM
-> Clasificación, cuadro de detección o decodificación de resultados de segmentación
-> ROI con reglas de negocio de ensamblaje
-> PASS / FAIL / UNKNOWN
-> Diagrama de evidencia, registro de resultados e interfaz de estación de trabajo.

La interfaz de inferencia solo es responsable del cálculo del modelo, y la determinación final de la estación de trabajo también maneja la deduplicación de activación, la calidad de la imagen, la evidencia de resultados, el estado anormal, la interfaz PLC o I/O y el seguimiento de datos.

Paso 6: verificar la coherencia del preprocesamiento y el posprocesamiento

Las diferencias comunes en los proyectos migratorios no necesariamente provienen del modelo en sí. El orden de los colores, el método de interpolación, el coeficiente de normalización, el método de cuantificación, el diseño del tensor, el escalado de coordenadas y los parámetros NMS pueden cambiar la salida.

Se recomienda comparar según los siguientes niveles:

Capa de entrada: compare los tensores que ingresan al modelo original y al modelo OM;
Capa de salida: compare la forma, el rango de valores y el orden de los nodos de la salida original del modelo;
Capa de algoritmo: compare categorías, cuadros de detección, máscaras y confianza;
Capa empresarial: compare los resultados PASS, FAIL o UNKNOWN de cada muestra;
Capa de evidencia: compare ubicaciones de defectos, mapas de anotaciones y registros de resultados para ver si corresponden a la misma pieza de trabajo.

Sólo localizando las diferencias capa por capa podemos juzgar si es necesario ajustar la conversión del modelo, el procesamiento de datos o las reglas comerciales.

Paso 7: Verificación completa del rendimiento y la estabilidad del dispositivo

Las pruebas de rendimiento deben realizarse en dispositivos Atlas de destino, tamaños de imagen formales y enlaces de procesamiento reales, distinguiendo entre:

Tiempo de adquisición o decodificación de imágenes;
Tiempo de preprocesamiento;
Tiempo de inferencia de modelo único;
Tiempo de posprocesamiento y reglas comerciales;
tiempo de redacción del archivo de resultados e imágenes de evidencia;
Tiempo de respuesta de la estación de trabajo de un extremo a otro.

Los resultados de la prueba también deben registrar la versión del modelo, el hash del archivo OM, la versión CANN, el modelo del procesador, el tamaño de entrada, el lote, el modo de precisión, el número de calentamientos y el número de muestras. La precisión, el tiempo del ciclo de producción y la estabilidad a largo plazo se confirman mediante inspecciones independientes de proyectos específicos y condiciones de operación continua.

Paso 8: Forme una entrega de versión enrollable

La entrega formal deberá contener al menos:

Modelo original o archivos fuente del modelo dentro del alcance acordado;
Modelo ONNX e instrucciones de exportación;
Modelo OM, comando ATC, registro de conversión y valor de verificación;
Código de preprocesamiento, inferencia, posprocesamiento y interfaz comercial;
Sistema operativo, CANN, paquete de operador y lista de versiones dependientes;
Resultados de verificación de muestras, registros de diferencias e informes de pruebas de rendimiento;
Instrucciones de configuración, inicio del servicio, registro, actualización, copia de seguridad y reversión.

Winge Technology puede implementar el trabajo de migración de modelos junto con cámaras, ópticas, ROI, I/O, interfaces, trazabilidad de resultados e implementación local, haciendo que la inferencia de modelos forme parte de un sistema completo de inspección de ensamblajes en lugar de una demostración de modelo aislada.

¿Qué cuestiones tienen más probabilidades de afectar los resultados de la migración?

pregunta	Síntomas comunes	dirección de procesamiento
Las definiciones de entrada son inconsistentes	Cambio general en los resultados o nivel de confianza anormal	Color fijo, tamaño, normalización y diseño tensor.
El operador o la forma es incompatible	La conversión del ATC falla o la estructura de salida cambia	Reescritura de gráficos, reemplazo de operadores, engranajes dinámicos u operadores personalizados
Postprocesamiento inconsistente	El número, ubicación o categoría de los cuadros de detección son diferentes.	Decodificación unificada, umbralización, NMS y restauración de coordenadas
La combinación de versiones no es fija.	El mismo modelo funciona de manera diferente en diferentes entornos.	Sistema fijo, CANN, paquete de operador y registro de construcción OM
Sólo probar el modelo lleva tiempo.	El ritmo en vivo aún no cumple con los requisitos.	Enlace completo desde la adquisición de mediciones hasta la salida de resultados
Falta de recopilación de validación independiente.	No se puede determinar si la migración mantiene los resultados comerciales	Utilice muestras OK, NG y de límites que no estén involucradas en el ajuste de parámetros

Preguntas frecuentes

¿Pueden los modelos ONNX ejecutarse directamente en Ascend NPU?

Por lo general, es necesario utilizar ATC para convertir el modelo ONNX en un modelo fuera de línea OM basado en el procesador Ascend de destino y el entorno CANN, y luego cargarlo y ejecutarlo a través de interfaces del lado del dispositivo como AscendCL.

¿La conversión para generar archivos OM significa que la migración está completa?

No es igual a. También es necesario completar el acoplamiento de entrada y salida, la coherencia del procesamiento previo y posterior, la comparación de resultados muestra por muestra, las pruebas de rendimiento del lado del dispositivo, el manejo de excepciones y la verificación de entrega de versiones.

¿Es necesario cambiar todas las reglas de visión tradicionales a redes neuronales?

No es necesario. Se pueden seguir manteniendo reglas ROI con posiciones fijas y límites claros; Los modelos de clasificación, detección de objetos o segmentación se utilizan para manejar cambios de categoría, fondos complejos y tareas de reconocimiento semántico, y los dos se pueden combinar en la misma aplicación Atlas.

¿Se puede utilizar el mismo modelo de OM directamente para todos los dispositivos Atlas?

Los parámetros de conversión del modelo OM están relacionados con el procesador Ascend de destino y el entorno de software. Al implementar el proyecto, se debe confirmar el modelo del procesador, CANN y la versión del paquete del operador de acuerdo con el dispositivo de destino, y se deben conservar los registros de compilación correspondientes.

¿Cómo juzgar si los resultados antes y después de la migración son consistentes?

Se deben utilizar muestras fijas para comparar el tensor de entrada, la salida original del modelo, los resultados del algoritmo y el juicio comercial final capa por capa, y la aceptación debe basarse en el error, la precisión y las reglas de la estación de trabajo confirmadas por ambas partes. No se puede comparar sólo una pequeña cantidad de imágenes de demostración.

fuentes oficiales

Huawei Ascend: modelo ONNX convertido al modelo OM

https://www.hiascend.com/document/detail/zh/CANNCommunityEdition/81RC1beta1/quickstart/quickstart/quickstart_18_0010.html

Huawei Ascend: parámetros de línea de comando ATC y restricciones del operador

https://www.hiascend.com/document/detail/en/canncommercial/850/devaids/atctool/atlasatc_16_0039.html

Huawei Ascend: construcción del modelo AscendCL y desarrollo de aplicaciones

https://www.hiascend.com/document/detail/zh/canncommercial/850/appdevg/acldevg/aclcppdevg_000027.html

Atlas, Ascend, CANN, AscendCL y nombres relacionados pertenecen a sus titulares de derechos. Este artículo explica los métodos de adaptación proporcionados por Winge Technology para proyectos de visión de ensamblaje y no significa que los titulares de derechos relevantes participen o respalden el proyecto específico. Las capacidades de los equipos y herramientas están sujetas a los documentos de la versión oficial correspondiente, y los resultados del proyecto están sujetos al modelo, las muestras, el equipo y las condiciones de aceptación reales.