Autor: Prpf. Dr. Maurits Kaptein 
 

Consideremos el subconjunto de aplicaciones de IA en el borde que llamamos "Video+IA": son aplicaciones de IA que utilizan una cámara de vídeo mejorada por un modelo de IA. La combinación de vídeo e IA en el borde crea un sensor prácticamente multipropósito. Este segmento del mercado de la IA en el borde está a punto de experimentar un crecimiento explosivo. Ya existen aplicaciones de Video+IA a gran escala, especialmente en el sector de seguridad, donde el Video+IA impulsa millones de cámaras. Este hecho es evidente, ya que estas aplicaciones a menudo se desarrollan utilizando la plataforma de video empresarial Nx Enterprise Video Platform/Nx Meta Developer Tools). 

Sin embargo, las oportunidades son mucho mayores: Las cámaras que actualmente monitorean obras de construcción para detección de intrusos, también podrían utilizarse para controlar situaciones peligrosas y alertar a los trabajadores a tiempo. O bien, las cámaras que se utilizan actualmente para capturar a los ladrones en una cafetería podrían monitorear qué clientes necesitan atención y qué artículos del inventario están casi agotados. 

La verdad es que las oportunidades de Visión+IA son prácticamente infinitas: cualquier proceso de negocio que pueda ser mejorado por un humano capacitado, bien motivado y que tenga injerencia con el sistema puede beneficiarse de Visión+IA.

Por tanto, las oportunidades futuras del mercado parecen infinitas. Dicho esto, conquistar el mercado es más fácil de decir que de hacer. Uno de los actuales inhibidores del crecimiento del mercado es el hecho de que todavía es excesivamente difícil escalar las ideas de IA en el borde desde una primera prueba de concepto (PoC) hasta una solución completa.

En particular, es difícil combinar de manera eficiente nuevos avances en software (diseño de modelos, algoritmos) y hardware (nuevos aceleradores de hardware específicos de IA). Si realmente queremos expandir nuestro mercado, debemos facilitar la implementación de una aplicación de IA en el borde en el hardware que sea más adecuado para la aplicación en cuestión. Es este problema que abordamos con la creación del Open AI Accelerator Standard (OAXS.org).

Las innovaciones en hardware y software están ampliando nuestra industria

La expansión del mercado de la IA en el borde está impulsada por nuevas innovaciones tanto en hardware como en software. En cuanto al software, vemos aparecer rápidamente nuevos modelos de arquitecturas. Hemos visto el surgimiento de la IA generativa, que facilita el entrenamiento de modelos robustos al contexto con datos de entrenamiento limitados. Hemos visto arquitecturas de redes neuronales cada vez más efectivas, que son más pequeñas que antes, pero que aún tienen una alta precisión. Y, en los últimos años, hemos visto una explosión de herramientas y esquemas de trabajo que facilitan cada vez más la selección de datos de entrenamiento de modelos de IA, en donde ya no se necesita ser experto para entrenar modelos de IA de alta precisión. 

En lo que respecta al hardware, hemos visto una explosión de lo que llamaremos a lo largo de este documento técnico, aceleradores (o XPU). Con este término nos referiremos a piezas específicas de silicio que están diseñadas para sobresalir en un conjunto limitado de tareas. En comparación con las CPU de uso general, estas “XPU” (usando X aquí para denotar la gran cantidad de GPU, NPU, TPU, AIPU y otras PU que existen) pueden llevar a cabo un conjunto específico de tareas computacionales de manera muy eficiente. Algunas XPU se centran en la eficiencia energética, otras en la velocidad computacional bruta. Sin embargo, todos comparten una propiedad: para un conjunto específico de operaciones, superan a las CPU existentes en alguna métrica de eficiencia.   

Necesitamos trabajar juntos para que crezca el mercado de IA en el borde

En la actualidad, estamos muy preocupados por la facilidad en que los avances de software (nuevos algoritmos) pueden utilizarse sobre hardware emergente (nuevos aceleradores). Esto, a su vez, influye en gran medida en la facilidad con la que las nuevas aplicaciones de IA en el borde pueden avanzar más allá de su primera etapa de prueba de concepto (PoC) y convertirse verdaderamente en productos de escala global.¹  Hoy en día, los avances en software y hardware no están bien alineados. 

El “nuevo silicio” a menudo requiere tipos muy específicos de modelos de IA, entrenados de maneras particulares. Por lo tanto, para beneficiarse de los avances del hardware los desarrolladores de aplicaciones de IA deben rediseñar su software e incorporar el software proporcionado por el fabricante de productos de última generación. El software proporcionado por los fabricantes en cuestión, con demasiada frecuencia, está en pañales. Para ellos el desarrollo de software es algo que está en los últimos procesos dado que se especializan en la fabricación de nuevo hardware. Como resultado, el actual software XPU suele ser difícil de usar, cuando es de tipo propietario (o parcialmente) incluso aún no está listo para escalar a una fase operativa. 

Por otro lado, para el creador de hardware de última generación, es difícil acceder al vasto ecosistema de desarrolladores de aplicaciones de IA en el borde: tiene que proporcionar software para que los desarrolladores de aplicaciones de IA utilicen su hardware, pero ¿por dónde empezar? El ecosistema de software se mueve tan rápidamente que todos los proveedores de hardware terminan creando su propio software, difícil de usar y parcialmente propietario.

Los desafíos que enfrentan tanto los desarrolladores de aplicaciones de IA en el borde, como los fabricantes de hardware para aprovechar los beneficios de nuestro mercado a punto de explotar, deben superarse para que juntos podamos beneficiarnos del potencial de mercado que tenemos ante nosotros. Si no proporcionamos una forma fácil de usar los nuevos avances de software en nuevo hardware y, de manera fundamental, se integren en el ecosistema mucho más amplio de software, hardware, ISV, licencias, soporte, etc., necesarios para brindar una solución al mercado, todos perderemos. 

El riesgo de no actuar unidos como industria fue recientemente expresado muy bien por Jeff Bier, fundador de Embedded Vision Summit: "Tal como vamos actualmente, los desarrolladores están atados a un ecosistema y no pueden pasar a un hardware más barato, aunque éste esté disponible. Como comunidad, corremos el riesgo de crear el 'microondas de 3.000 dólares'. Los modelos de IA en el microondas son excelentes y ofrecen valor, pero el costo del hardware impone un precio que nunca funcionará".

 1 Es cierto que la ampliación de una solución conlleva muchos otros aspectos desafiantes; sin embargo, en este documento técnico nos centramos únicamente en la cuestión de la adopción de nuevas XPU.

Estandarización para garantizar la adopción y el rápido crecimiento

En este documento técnico, proponemos el Open AI Accelerator Standard (OAXS, ver https://oaxs.org). Primero describiremos cómo se implementan las fuentes de IA (es decir, el proceso de pasar de los datos de los sensores a una aplicación significativa) y qué significa acelerar partes de esa fuente. A continuación, presentamos nuestro estándar abierto propuesto para facilitar la aceleración. Finalmente, discutiremos los compromisos de Network Optix con este estándar abierto: después de habernos beneficiado en los últimos 10 años de estándares en la industria del video (como ONVIF) y haber escalado aplicaciones de video a millones de canales en todo el mundo, estamos comprometidos a contribuir según la especificación de OAXS para permitir que el mercado de Visión+IA crezca.

Aceleración de las fuentes de IA

¿Qué significa utilizar una XPU (un acelerador) para mejorar una fuente de IA? Por razones de simplicidad, centrémonos en las aplicaciones Visión+IA. 

Explicación de la fuente VISIÓN+IA

Una fuente, en nuestra jerga, es el proceso completo desde el sensor (la cámara) hasta la aplicación de alto nivel; por ejemplo, un camarero recibe un mensaje en su teléfono indicando que es necesario atender la mesa. La fuente de IA consta de varias operaciones;²  las operaciones son simplemente procesos que toman una forma específica de datos como entrada y los transforman en un formato³ más significativo. 

Fig 1. Representación abstracta de una fuente de Visión+IA.

Siguiendo con el ejemplo del camarero descrito brevemente en la introducción, consideremos la siguiente fuente (ver Fig.1) y sus cuatro operaciones:

• Una cámara monitorea 4 mesas en la cafetería; la cámara produce una secuencia RTSP que se envía a un dispositivo en el borde que implementa la aplicación.
• Operación 1: El flujo RTSP se decodifica en tensores de imagen RGB individuales de 640x480, a una velocidad de 7 fotogramas por segundo.
• Operación 2: Un modelo de IA (M1) toma como entrada los tensores de imagen individuales y produce una lista de coordenadas de cuadros delimitadores que indican las ubicaciones de las personas en la imagen.
• Operación 3: El contenido de cada cuadro delimitador se envía como entrada a un segundo modelo de IA (M2) que genera una identificación única para cada persona (por ejemplo, ReID).
• Operación 4: Este conjunto de ID únicos, su ubicación y sus marcas de tiempo se procesa mediante un conjunto de reglas de nivel superior para generar una alarma cuando una mesa está ocupada, pero no ha sido atendida por ningún miembro del personal del café durante un período de tiempo determinado.

En el ejemplo anterior, cada una de las cuatro operaciones, decodificación, M1, M2 y el algoritmo basado en reglas descrito en el último paso, podrían beneficiarse potencialmente de la implementación en una XPU. 

2 El término operaciones es muy genérico y podría referirse a operaciones bit a bit como AND u OR, o podría referirse a funciones grandes, de caja negra (o modelos de IA). En este punto del texto, la naturaleza genérica es deliberada: especificaremos más nuestro uso del término a medida que avancemos.

3 La fuente puede considerarse de manera abstracta como el proceso que gobierna qué datos se “alimentan” a qué proceso y a qué ritmo.

CPU y GPU que implementan una fuente de IA

La mayoría de las modernas XPU permiten acelerar una o varias de las operaciones descritas anteriormente. Aunque la fuente general se rige por un proceso que se ejecuta en la CPU, las operaciones específicas se "subcontratan" a la XPU. 

En teoría, el proceso de subcontratar operaciones a la XPU es fácil: simplemente hay que determinar qué operaciones se benefician de las fortalezas de la XPU y transferir esas operaciones⁴ a ese chip (ver Fig.  2). Siempre que las operaciones estén claramente definidas y el movimiento de datos “dentro” de la fuente (y por lo tanto entre CPU y XPU sea eficiente), en teoría se puede seleccionar cualquier XPU para cosechar sus beneficios sin tener que pasar por una reingeniería significativa de la fuente y las operaciones en el mismo.

Fig 2. Representación esquemática de "mover" una única operación (que puede ser un DNN completo) a la XPU.

4 Tengamos en cuenta que aquí un conjunto de operaciones se encadena fácilmente en una operación única y más elaborada. Si la operación 1 transforma datos de X a Y, mientras que la operación 2 transforma datos de Y a Z, también podríamos "encadenar" las operaciones 1 y 2 para crear la operación 3 que transforma datos de X a Z.

Los desafíos al "subcontratar" operaciones

Sin embargo, en la práctica, trasladar las operaciones a una XPU suele ser un desafío. Los desarrolladores de aplicaciones de IA necesitarán saber exactamente qué operaciones son compatibles con la XPU seleccionada y, a menudo, las operaciones deberán volver a implementarse para que puedan ejecutarse en la XPU. En segundo lugar, los datos que “fluyen” entre la CPU y la XPU deben seleccionarse sabiamente: la subcontratación de operaciones muy pequeñas (es decir, AND y OR bit a bit) a la XPU incurrirá en altos costos (de memoria) para mover datos, mientras que la subcontratación de operaciones excesivamente grandes corre el riesgo de tener que reconstruir la fuente completa utilizando instrucciones XPU. 

Actualmente, estamos atrapados en un ecosistema de software que funciona bien en CPU y un ecosistema propietario para GPU específicas. Mover operaciones seleccionadas en una fuente a XPU recién agregadas es un desafío que ralentiza la adopción de nuevo hardware, lo cual obstaculiza la expansión del mercado de los fabricantes de hardware. Además, los desafíos que supone la adopción de nuevas XPU privan a los desarrolladores de aplicaciones de las características únicas del nuevo hardware (y esto nos lleva al ‘microondas de 3.000 dólares’).

Especificación de operaciones: Elegir el nivel correcto de abstracción

Antes de profundizar en la especificación del Open AI Accelerator Standard (OAXS) para abordar el problema de "portabilidad de XPU" mencionado anteriormente, queremos abordar brevemente nuestro uso del término operaciones. En efecto, definimos una operación simplemente como una función (mapeo) de un tipo de datos a otro. Esto es extremadamente general, pero en tal generalidad también es muy difícil trabajar con él: en este nivel de abstracción, incluso los AND y OR pequeños, a nivel de bits, se consideran operaciones. Por otro lado, la fuente completa descrita anteriormente también puede considerarse una sola operación. 

Para que una especificación de operación genérica sea útil, debemos elegir el nivel correcto de abstracción. En nuestro estándar propuesto nos centramos en que cada modelo de IA sea una operación⁵ única que potencialmente se subcontrata a la XPU.

5 Tengamos en cuenta que esta noción de operación es diferente del uso de operaciones en el estándar Open Neural Network Exchange (ONNX, ver https://onnx.ai ). El estándar ONNX, que sugerimos adoptar como punto de partida para OAXS, tiene un propósito diferente y, por lo tanto, se beneficia de un nivel diferente de abstracción.

La especificación OAXS

En esta sección, proporcionamos un primer boceto de la especificación de OAXS. Nos centramos en acelerar los modelos de IA individuales(es decir, M1y M2 de más arriba). Al bosquejo de la especificación le faltan, consciente y deliberadamente, varios detalles: este documento técnico tiene como objetivo reunir a una comunidad en torno a OAXS y la especificación final del estándar debe ser un esfuerzo de la comunidad.

Descripción general de alto nivel

Según nuestra experiencia en el soporte de fuentes de IA en el borde en una gran variedad de combinaciones de CPU/XPU, la especificación OAXS debe constar de dos partes:

1. La primera parte de la especificación es un mecanismo estandarizado para transformar (compilar, compilar de forma cruzada, reformular, cualquier nombre que deseemos darle) una descripción genérica e independiente del objetivo de una operación en una especificación dependiente de XPU. A este primer paso lo denominamos cadena de herramientas de conversión de operaciones.
2. La segunda parte de la especificación consiste en un método estandarizado para ejecutar la especificación específica del objetivo de la operación dentro de una fuente mayor. Es decir, este paso consiste en un mecanismo para (para el proceso que se ejecuta en la CPU) "cargar" la especificación y "ejecutarla" teniendo en cuenta datos de entrada específicos. A este segundo paso lo llamamos tiempo de ejecución de la XPU.

En conjunto, la cadena de herramientas de conversión de operaciones y el tiempo de ejecución de la XPU conforman la especificación OAXS. 

Este estándar está diseñado de manera que cada vez que un fabricante de productos de hardware proporcione ambas partes del estándar al público, sea instantáneamente posible implementar cualquier número de operaciones admitidas en la XPU. Desde la perspectiva del proveedor de hardware, esto significa que al comprometerse con el estándar OAXS, los desarrolladores de aplicaciones de IA pueden utilizar su XPU al instante. Desde la perspectiva del desarrollador, OAXS garantiza que cualquier combinación de CPU/XPU pueda, durante la etapa de implementación, ser abordada sin ninguna reingeniería.

En nuestra primera implementación de OAXS, recomendaremos el uso de ONNX, el formato Open Neural Network Exchange que se encuentra en https://onnx.ai, como punto de partida para especificar una operación (es decir, consideramos un gráfico ONNX completo como una operación). El OAXS no depende fundamentalmente de ONNX, pero necesitamos un punto de partida genérico para proporcionar la portabilidad buscada: en este punto, ONNX parece el estándar más universalmente aceptado para una especificación tan genérica de una operación.

Cadenas de herramientas de conversión de operaciones

De manera abstracta, las cadenas de herramientas de conversión de operaciones son funciones que toman como entrada una descripción genérica de una operación y generan como salida una descripción específica de esa misma operación que se puede ejecutar en la XPU de destino. Para que dicha conversión sea genéricamente útil, necesitamos tener 

1. una descripción genérica de la operación bien respaldada, y
2. un ecosistema bien respaldado para implementar y distribuir las funciones de la cadena de herramientas de conversión.

Para resolver el primer punto, sugerimos adoptar ONNX como método para especificar (de forma genérica y de forma independiente del dispositivo) las operaciones que deben subcontratarse a la XPU. Para resolver el segundo problema, sugerimos adoptar contenedores Docker. Los contenedores Docker se pueden utilizar para ejecutar fácilmente un único proceso desde la línea de comandos en prácticamente cualquier máquina, y los contenedores se distribuyen con extrema facilidad. 

Detalles de la instalación

Una cadena de herramientas de conversión de operaciones es un contenedor Docker que puede contener cualquier código (es una caja negra para el usuario) y se puede ejecutar usando:
 

docker run -i --rm boot python convert.py < /path/to/model-file.onnx

 
El contenedor Docker puede contener prácticamente cualquier código que el fabricante de productos de hardware desee utilizar para implementar el proceso de conversión específico de XPU de ONNX genérico a salida específica de XPU.

Sugerimos que el contenedor genere por defecto un triplete que consta de:

1. operations-file.ai. Un archivo que contiene las operaciones especificadas en un formato tal que pueda ejecutarse (utilizando el tiempo de ejecución, ver más abajo) en la XPU. El archivo debe tener un tipo MIME coincidente para el tiempo de ejecución.
2. vignet.json. Un objeto json que contiene comentarios sobre el proceso de conversión (exitoso). La viñeta contiene una descripción estructurada de los tiempos de ejecución adecuados para ejecutar el archivo Operations-file.ai y cualquier nota de conversión que el usuario debe tener en cuenta.⁶
3. errors.json. Un objeto json que contiene los errores. Esto sólo debe generarse si no se genera el archivo operations-file.ai. El archivo errors.json debe contener información específica que detalle por qué falló el proceso de conversión (por ejemplo, el gráfico ONNX contiene el operador ONNX relativamente reciente GridSample, para el cual no hay soporte en la XPU).

6 A menudo vemos que los tipos de datos deben ajustarse para adaptarse a una XPU específica; por ejemplo, los INT32 se convierten a INT8 o INT16. Estas optimizaciones deben comunicarse al usuario en la viñeta.

Tiempo de ejecución de operación de XPU

El tiempo de ejecución de la operación XPU es simplemente un proceso que permite que el proceso que se ejecuta en la CPU haga dos cosas:

1. "Cargue" la especificación de operación específica de la XPU “en” la XPU, y
2. "Ejecute" la operación con los datos de entrada proporcionados.

En resumen, si el tiempo de ejecución de la operación implementa las dos funciones anteriores, puede integrarse fácilmente en una fuente de IA mayor y usarse para ejecutar la operación. Al mover la fuente a una combinación diferente de CPU/XPU, simplemente se ejecuta la cadena de herramientas de conversión de la XPU de destino y posteriormente "intercambia" el tiempo de ejecución específico de la XPU dentro de la fuente; no se necesitan otros cambios.

Detalles de la instalación

Para la primera especificación del tiempo de ejecución, sugerimos proporcionar tiempos de ejecución en forma de una biblioteca compilada (que se puede integrar fácilmente en una fuente C/C++ mayor) que proporciona una ABI que revela las operaciones de carga y ejecución.

Para E/S genéricas a la biblioteca, sugerimos usar tensores binarios enviados a través de msgpack;⁷  según nuestra experiencia, esto es muy genérico (y por lo tanto se puede usar para una variedad de tipos de datos de entrada y salida) y de alto rendimiento.⁸

7 Para más información, ver https://msgpack.org/index.html 

8 Actualmente tenemos varias implementaciones experimentales de tiempos de ejecución de XPU para una variedad de XPU que utilizamos en aplicaciones Nx Vision+IA. Con nuestro apoyo al estándar OAXS, documentaremos nuestras implementaciones actuales y las haremos públicas.

El tiempo de ejecución de ONNX

Aunque este documento técnico simplemente describe los esquemas de alto nivel del estándar OAXS, es significativo reflexionar brevemente sobre la relación entre OAXS y el tiempo de ejecución de ONNX. El tiempo de ejecución de ONNX, reducido a su núcleo, es simplemente un caso específico de nuestro tiempo de ejecución de operación XPU sugerido. Esto es fácil de ver cuando se observa el código Python para cargar y ejecutar un modelo ONNX en ONNX Runtime:

# Load the operation:
 

session = onnxruntime.InferenceSession('resnet50v2/resnet50v2.onnx', None)

 
# Run the Operation:
 

output = session.run([data])

 
Entonces, usar un archivo ONNX para la implementación e inferencia del modelo de IA usando el tiempo de ejecución de ONNX es simplemente una implementación del estándar OAXS: 

• Toolchain simplemente asigna ONNX a ONNX.
• Runtime carga Operations-file.onnx y permite su ejecución.

En el estándar OAXS, generalizamos esta implementación para proporcionar más flexibilidad para combinaciones de XPU/CPU con recursos limitados: debido a la naturaleza de caja negra de las cadenas de herramientas en OAX, una cadena de herramientas podría producir ONNX, pero también podría producir, por ejemplo, una descripción binaria de una combinación de múltiples operaciones específicas de XPU. Esta generalidad garantiza que se puedan agregar XPU manteniendo el rendimiento nativo.⁹ 

9 Debido a su naturaleza "interpretativa", el tiempo de ejecución de ONNX es, por defecto, relativamente grande (contiene implementaciones para todos los operadores de ONNX) y relativamente lento (o necesita compilación en el dispositivo). Por lo tanto, aunque es adecuado para algunas aplicaciones, hemos diseñado OAXS como un superconjunto para la implementación del Tiempo de ejecución de ONNX/ONNX.

Abriendo el acelerador

A estas alturas ya hemos explicado por qué creemos que la especificación OAXS es tan necesaria: abre nuestro mercado y facilita el uso del hardware adecuado. También hemos delineado los componentes principales del estándar: en este momento estamos desarrollando activamente el estándar y estamos invitando a los fabricantes de XPU y a los creadores de aplicaciones de IA a que colaboren en su posterior especificación e implementación. Sin embargo, es bueno comprender adecuadamente el poder de OAXS. 

Obviamente, OAXS puede ser utilizado por desarrolladores individuales. Si un desarrollador desea mover una parte de una fuente de IA, especificado genéricamente en ONNX, a una XPU específica, sólo necesita descargar el contenedor acoplable de la cadena de herramientas OAXS suministrado y ejecutarlo localmente para convertir la operación. 

A continuación, la simple inclusión del tiempo de ejecución en la fuente garantiza que se haya integrado la XPU. Por lo tanto, hacer que las cadenas de herramientas de conversión y los tiempos de ejecución estén disponibles abiertamente hace que la migración a una nueva XPU sea extremadamente fácil de realizar, mientras que el estándar OAXS proporciona a los fabricantes de XPU toda la flexibilidad que necesitan para garantizar el rendimiento nativo.

Sin embargo, el estándar realmente cobra vida cuando se integra en un ecosistema más grande. Esto es exactamente lo que hemos hecho en Network Optix (hablaremos más adelante sobre Nx). La Fig. 3 nos proporciona una descripción esquemática de cómo utilizamos el estándar OAXS para crear fuentes de IA totalmente portátiles e independientes del dispositivo:

1. Especificamos una fuente genérica. Para las fuentes de Visión+IA, Nx proporciona abiertamente todas las herramientas para capturar fácilmente flujos de video, decodificarlas, cambiar su tamaño, etc. Asimismo, Nx proporciona las herramientas para aumentar fácilmente los flujos con metadatos (por ejemplo, detecciones de objetos de IA) y visualizarlos para una gran cantidad de flujos simultáneos.
2. Una vez que la fuente ha sido especificada genéricamente, los modelos de IA que contiene (las operaciones que potencialmente se benefician de la aceleración) pueden pasar automáticamente a través de todas las cadenas de herramientas disponibles; por lo tanto, en Nx Cloud, nos aseguramos de que el mismo modelo esté disponible para una gran cantidad de XPU.
3. Al instalar el servidor Nx en un dispositivo de borde y habilitar el administrador Nx AI en ese dispositivo, instalaremos automáticamente el tiempo de ejecución adecuado para dicho dispositivo. Por lo tanto, si el dispositivo contiene una XPU específica, instalaremos el tiempo de ejecución que se haya aportado para esa XPU.
4. Desde la nube de Nx podremos posteriormente, de forma automática, implementar la versión de la operación que aproveche la XPU objetivo.

La configuración anterior permite "intercambiar" efectivamente un dispositivo de borde y beneficiarse automáticamente de su combinación CPU/XPU.

Fig 3. Descripción general del proceso de implementación masiva en una flota diversa de dispositivos de borde utilizando el estándar OAXS (tal como se implementa en Nx AI Manager y Nx Cloud).