Un patrón común que hemos observado es que la creación y la implementación de un modelo de ML con fines de producción están a cargo de diferentes equipos, por lo general, un equipo de algoritmos de ML y un equipo de operaciones de dispositivos. El equipo de ML maneja el entrenamiento y la evaluación del modelo, mientras que el equipo de dispositivos es responsable de migrar el modelo al entorno de producción.

Tal separación se debe en parte al hecho de que el entrenamiento y la inferencia han divergido, tanto en las plataformas de hardware como en las pilas de software. En el pasado, usábamos Caffe en un servidor de GPU tanto para entrenamiento como para servicio. Hoy en día, las personas usan potentes herramientas y servidores para la capacitación y luego implementan modelos en tiempos de ejecución altamente optimizados y diversos dispositivos. Los problemas de implementación se encuentran con frecuencia debido a la complejidad del modelo y las limitaciones del hardware, y el equipo de ML generalmente necesita confiar en los comentarios del equipo de operación del dispositivo para resolver estos problemas.

Como resultado, los ingenieros de aprendizaje automático (MLE) a menudo carecen de conocimientos muy básicos sobre la capacidad de implementación de sus propios modelos. La implementación del modelo actual suele ser una canalización construida internamente compuesta por múltiples scripts de Bash/Python que se extienden a través de diferentes máquinas y entornos. También incluye varias bibliotecas de código abierto o kits de herramientas específicos de proveedores para la conversión de modelos, la cuantificación, el ajuste del rendimiento y la verificación de la precisión. No es una experiencia agradable, en comparación con el desarrollo de modelos en un entorno Python nativo de la nube.

Además de la complejidad de las herramientas, la falta de interpretabilidad del rendimiento es otro problema. Los informes de generación de perfiles de las cadenas de herramientas posteriores a menudo requieren conocimiento del dominio para comprender y convertir en información útil del modelo, como en el siguiente ejemplo de TensorRT. Junto con la larga canalización de conversión de modelos, es difícil para los desarrolladores de ML identificar los cuellos de botella de rendimiento reales de sus propios modelos y realizar los cambios correctos.

A pesar de estos inconvenientes, la separación del diseño y la implementación de modelos sigue siendo la norma en la industria, ya que generalmente requieren conjuntos de habilidades completamente diferentes. “Ya es difícil contratar a un experto en ML o un experto en dispositivos, y mucho menos a un experto en ambos”, eso es lo que seguimos escuchando de nuestros clientes. Pero eso no significa que debamos seguir tolerando el flujo de trabajo actual de ML.

En Software 1.0, es difícil imaginar que un programa sea escrito por un ingeniero y compilado por otro ingeniero. Los programadores pueden compilar el código ellos mismos, con poco o ningún conocimiento de las etapas subyacentes, como el ensamblaje y la vinculación, y al mismo tiempo pueden obtener información significativa para corregir sus códigos. Sin tales conocimientos, el proceso de depuración podría convertirse en un ir y venir interminable entre dos ingenieros que no hablan el idioma del otro.

Hasta ahora, los problemas más comunes que hemos visto que retrasan la implementación de modelos ML son:

1. Latencia/rendimiento intolerable
2. Operadores no admitidos
3. Desajuste de precisión

La solución es un flujo de trabajo simple y comprensible para la implementación y el diagnóstico de modelos. Una interfaz que los ingenieros de ML puedan usar y comprender por sí mismos mejorará enormemente la productividad.

La creación de un compilador de aprendizaje automático súper potente es solo parte de la solución, porque existen algunas diferencias fundamentales entre el software 2.0 y el software 1.0: primero, constantemente se implementan nuevos operadores desde la academia y muchos de ellos no pueden estar compuestos por los existentes; en segundo lugar, los modelos de ML pueden tolerar el reemplazo de operadores que no preservan la funcionalidad y aún así mantener una precisión similar, lo que proporciona una mayor flexibilidad de personalización para los desarrolladores de ML. Sin embargo, no profundizaremos en los detalles, porque probablemente valga la pena escribir un blog por separado para hablar sobre la personalización del modelo para la implementación.

En OmniML , comenzamos creando una herramienta interna para que nuestros ingenieros implementen y perfilen sus modelos de ML sin la molestia de estudiar el hardware y su cadena de herramientas de ML. Pronto nos dimos cuenta del aumento de rendimiento de dicha herramienta. Además, esta interfaz unificada y rica en información permite que tanto humanos como algoritmos descubran grandes oportunidades de optimización de modelos. Por lo tanto, esas características ahora están disponibles formalmente en los productos de OmniML: Omnimizer y Omnimizer Enterprise .

Omnimizer: una plataforma unificada de implementación y optimización de modelos

Omnimizer está diseñado principalmente para ingenieros de ML que diseñan y entrenan modelos PyTorch. Les ayuda a identificar los defectos de diseño y reducir el tiempo de producción.

Omnimizer proporciona una interfaz nativa de PyTorch y nativa de la nube para probar rápidamente un modelo en el hardware de destino. Los usuarios solo necesitan especificar una configuración de implementación de alto nivel y luego enviar la solicitud a la nube del dispositivo alojado en OmniML. La información clave de implementación, incluida la latencia general, la latencia por capas y los errores de implementación (si los hay), se informará de la manera más simple que pueda entender un experto que no sea en hardware.

Omnimizer permite a los usuarios comparar fácilmente la precisión del dispositivo con el modelo original. Elimina las molestias de transferir el modelo y los datos a un dispositivo diferente, familiarizarse con diferentes sistemas operativos y cadenas de herramientas, y mantener un montón de scripts desorganizados y llenos de errores. En el siguiente ejemplo, los usuarios pueden obtener la salida del modelo en una interfaz similar a PyTorch, mientras que la inferencia real ocurre en un dispositivo remoto, por ejemplo, una GPU de clase de servidor o un teléfono inteligente.

Omnimizer no es solo una biblioteca de software, sino también una plataforma MLOps que proporciona una interfaz fácil de usar para navegar por los detalles de rendimiento, compartir información de modelos y reproducir entornos de implementación. Los usuarios pueden ver los pasos de implementación, obtener la latencia comparativa y obtener una mejor comprensión de su modelo en el hardware.

Omnimizer Enterprise: libere todo el potencial del hardware de IA

En comparación con la versión comunitaria que ayuda a la implementación y optimización del modelo, la versión empresarial proporciona una optimización automatizada del modelo basada en años de investigación sobre la búsqueda de arquitectura neuronal (NAS) y una amplia personalización para las necesidades empresariales.

NAS siempre ha sido considerado como un proceso costoso que requiere una gran experiencia en el espacio de búsqueda y el diseño de tareas de proxy. Con Omnimizer, cada usuario puede aplicar NAS para personalizar sus modelos para el hardware de destino. Este proceso requiere solo unas pocas líneas de cambio de código, bajos costos de capacitación y, lo que es más importante, no requiere ser un experto en diseño de modelos y rendimiento de hardware.

Omnimizer puede integrarse fácilmente con repositorios de código abierto y acelerar los modelos listos para usar con poca optimización manual. Hasta ahora, OmniML y sus clientes han demostrado aumentos de velocidad de 1,2 a 6,8 veces en las plataformas NVIDIA y Qualcomm. Estos repositorios estarán abiertos a usuarios empresariales como ejemplos:

• YOLO-X (detección de objetos)
• EfficientDet (detección de objetos)
• YOLO-P (modelo multitarea para conducción autónoma)
• DDRNet (segmentación semántica)
• ResNet (clasificación de imágenes)
• DD3D (detección de objetos 3D)
• BALSA (flujo óptico)
• DistilBERT (traducción automática)

¡Prueba Omnimizer!

Omnimizer Beta acaba de ser lanzado. ¡Regístrese ahora en el sitio web de OmniML y comience a optimizar su flujo de trabajo!

Di Wu, Song Han, Lucas Liebenwein, Riyad Islam, Keval Morabia, 
Asma K.T. Beevi, Henry Guo and Shengliang Xu also contributed to this article.