Estudiamos ONNX para aplicarlo al trading - página 4

[MetaQuotes]

Discusión n.º 1 de la hoja de ruta de ONNX 2020 20200903

Discusión n.º 1 de la hoja de ruta de ONNX 2020 20200903

El documento de hoja de ruta de ONNX, que ha estado abierto a contribuciones del público, es un tema clave en este video. La discusión cubre la extensión de ONNX en una canalización de aprendizaje automático, incluida la evolución de datos, el preprocesamiento y la extensión de ONNX en canalizaciones horizontales como QFLO. Las sugerencias hechas por los contribuyentes incluyen marcos de datos compatibles y la adopción de nuevos operadores para el preprocesamiento. Los oradores también analizan la adopción del estándar API de datos de Python para expandir el soporte de ONNX y garantizar la interoperabilidad entre otras bibliotecas. Además, los oradores analizan la integración de ONNX en Kubernetes y Kubeflow para optimizar el desarrollo de ML para los usuarios. El grupo planea continuar evaluando el impacto de la propuesta y agradece los comentarios a través de la hoja de ruta o el comité directivo.

• 00:00:00 En esta sección, el orador analiza el documento de hoja de ruta de ONNX que ha estado abierto a contribuciones del público y destaca la importancia de estas contribuciones para implementar cambios. El orador menciona que habrá seis debates sobre la hoja de ruta, organizados semanalmente, con una reunión comunitaria prevista para el 14 de octubre. La discusión se divide en tres partes principales, y la segunda parte se enfoca en extender ONNX en una canalización de aprendizaje automático. Específicamente, la discusión cubre la evolución de los datos y su preprocesamiento, y la extensión de ONNX a canalizaciones horizontales como QFLO. El orador también resume algunas de las sugerencias hechas por los colaboradores, como admitir marcos de datos y adoptar nuevos operadores para el preprocesamiento.
  
  
• 00:05:00 En esta sección, la discusión se centra en la hoja de ruta de ONNX y varias sugerencias, como la compatibilidad con el procesamiento de espectrogramas de audio y la expansión de la compatibilidad con el diseño de datos. La conversación también cubre la extensión propuesta de la influencia de ONNX en la canalización de ML y los beneficios potenciales de admitir marcos de datos dentro de ONNX. Los participantes expresan sus opiniones, y un miembro comparte información sobre los esfuerzos del Consorcio de API de datos de Python para crear un estándar de API de datos para la interoperabilidad de arreglos y marcos de datos. El grupo parece estar de acuerdo en que expandir las capacidades de ONNX en estas áreas es algo bueno y se alinea con iniciativas más amplias de la industria.
  
  
• 00:10:00 En esta sección, los oradores analizan la adopción del estándar API de datos de Python como una forma de expandir el soporte de ONNX y garantizar la interoperabilidad entre todas las demás bibliotecas del mismo estándar. El orador dice que la adopción del estándar facilitaría el intercambio de modelos y que alinear el cronograma con el consorcio más grande sería mejor para que los usuarios usen ONNX. También analizan la diferencia entre ONNX y la estructura de datos tradicional como marco de datos, y la necesidad de que otras bibliotecas adopten el mismo estándar.
  
  
• 00:15:00 puede integrar ONNX en la canalización de Kuflow para facilitar el desarrollo de ML para los usuarios finales. Chen menciona el concepto de una tubería donde todos los componentes trabajan juntos para orquestar el desarrollo de ML de extremo a extremo. Kuflow combina contenido de modelo y datos con infraestructura para brindar una experiencia perfecta para los usuarios finales. Chen está explorando cómo se puede integrar ONNX en esta canalización para ampliar su uso y hacerlo más fácil para los desarrolladores de ML.
  
  
• 00:20:00 En esta sección, los ponentes analizan la idea de facilitar a los usuarios que utilizan Kubernetes y Kubeflow el aprovechamiento de ONNX para su infraestructura y entornos. El objetivo es desarrollar una API de fácil acceso para tomar modelos del zoológico de modelos y crear una canalización de un extremo a otro utilizando ONNX. Los oradores muestran un ejemplo en el que usan ONNX para describir la parte de inferencia de un proceso de aprendizaje automático en Kubeflow y describen ideas para desarrollar componentes de ONNX para cubrir más pasos, incluido el procesamiento de datos y la capacitación distribuida. La idea es aprovechar el poder de Kubernetes y, al mismo tiempo, cubrir más pasos en el proceso de aprendizaje automático.
  
  
• 00:25:00 En esta sección, los oradores discuten la expansión de QFlow para tener trabajo ONNX para habilitar el entrenamiento distribuido y agregar procesamiento y transformación de datos para llegar a la parte de entrenamiento del modelo. El propio tiempo de ejecución de ONNX es compatible con los modelos de transformadores de entrenamiento de PyTorch en la actualidad, pero aún queda mucho por hacer con el entrenamiento de modelos de ONNX. Los oradores sugieren comenzar con los modelos en el zoológico de modelos para ver cómo se deben preprocesar y transformar los datos para los modelos, pero tenga en cuenta que esto no está puramente dentro del proyecto principal de ONNX y requiere un marco de trabajo de nivel superior para definir los componentes. como CoolFlow.
  
  
• 00:30:00 En esta sección, los participantes discuten una propuesta que se hizo para la hoja de ruta de ONNX y sugieren vincular las diapositivas al documento. El grupo planea continuar evaluando el impacto de la propuesta en reuniones posteriores y espera tener más detalles sobre la implementación. También agradecen los comentarios y alientan a los usuarios a enviarlos a través de la hoja de ruta o el comité directivo. La discusión concluye con una despedida e invitación a futuras reuniones.

[MetaQuotes]

Discusión n.° 2 de la hoja de ruta de ONNX 2020 20200909

Discusión n.° 2 de la hoja de ruta de ONNX 2020 20200909

En el video "Discusión de la hoja de ruta de ONNX", los oradores discuten varios temas relacionados con la hoja de ruta de ONNX, incluida la inferencia de formas, definiciones de operadores, implementaciones de referencia y la especificación de ONNX. Los oradores sugieren construir una infraestructura de inferencia de forma genérica para mejorar la optimización de la inferencia de forma, reduciendo la cantidad de operadores primitivos, agregando implementaciones de referencia para cada operador y casos de prueba mejor definidos para garantizar una implementación y prueba adecuadas de ONNX. El grupo planea continuar las discusiones dentro del operador SIG y en el foro de discusión de GitHub para agregar un nuevo operador.

• 00:00:00 En esta sección, los oradores analizan la hoja de ruta de ONNX y cubren algunos temas sugeridos, específicamente la inferencia de formas, la definición y el IR, todos los cuales se mencionaron anteriormente en el documento de la hoja de ruta, con comentarios de varias personas. Los oradores preguntan si Changming o Buchan están disponibles para explicar sus propuestas. Buchan habla sobre sus comentarios sobre la interferencia de forma y cómo tuvo problemas con ella en el pasado. Sugiere construir una infraestructura de influencia de forma genérica que vuelva a compilar la forma cada vez que haya un cambio en IR para garantizar que la optimización de inferencia de forma vaya de la mano y mejore la optimización simultáneamente. Los oradores concluyen que esto se aplica más a la optimización que directamente a la inferencia de formas.
  
  
• 00:05:00 entender las capacidades actuales de ONNX en términos de inferencia de forma y pases de optimización. La infraestructura existente ya admite la inferencia de formas basada en valores de entrada conocidos y se puede utilizar para inferir formas de salida. Puede haber frutos al alcance de la mano en la actualización del verificador de modelos, pero otros cambios pueden requerir más discusión. El grupo discute si estos cambios pertenecen a ONNX o en un lugar diferente. También consideran la idea de llamar a métodos de inferencia de forma para cada operador en bucles consecutivos para lograr los resultados deseados. En última instancia, la infraestructura existente ya permite pases de optimización e inferencia de formas, pero los cambios y las mejoras podrían mejorar estas capacidades.
  
  
• 00:10:00 En esta sección, los oradores analizan las definiciones de los operadores y sugieren reducir el número de operadores primitivos, ya que otros operadores pueden combinarse con operadores de nivel inferior. También discuten el tema de la implementación de referencia y la necesidad de la infraestructura para evaluar una secuencia de operadores. La implementación de referencia actual existe en forma de una implementación de Python en el generador de casos de prueba, pero no está organizada de una manera que facilite la evaluación de una secuencia de operadores. Los oradores sugieren agregar algún tiempo de ejecución como el tiempo de ejecución ONNX a los CI para verificar los subgráficos de función, que se pueden usar para la validación.
  
  
• 00:15:00 En esta sección, los oradores discuten la necesidad de implementaciones de referencia para cada operador para garantizar que los tiempos de ejecución no se aparten de las expectativas del autor. Sugieren usar la implementación de referencia como una prueba unitaria para validar la paridad con el tiempo de ejecución y también como un modo de intérprete para verificar la interoperabilidad y la validación. Los oradores señalan que es posible usar el tiempo de ejecución de ONNX para validar la función bajo el supuesto de que la función se compone de operaciones primitivas que existen en ONNX. Sin embargo, no es posible usar el tiempo de ejecución de ONNX para nuevos operadores en un subgrafo que incluye operaciones primitivas nuevas, ya que ningún otro tiempo de ejecución tendría esa implementación. Reconocen que crear una implementación de referencia requiere mucho trabajo, pero es obligatorio para cada operación. También enfatizan la necesidad de cumplir con ONNX para garantizar que el tiempo de ejecución no se aparte de las expectativas del autor.
  
  
• 00:20:00 En esta sección, los oradores analizan el uso de implementaciones de referencia en la especificación ONNX y la importancia de un lenguaje claro y conciso en la especificación. Mientras que algunos abogan por el uso de implementaciones de referencia para eliminar la ambigüedad en el texto en inglés de la especificación, otros argumentan que la especificación debe ser lo suficientemente clara como para que las implementaciones de referencia sean innecesarias. Los oradores también discuten la importancia de las pruebas de cumplimiento rigurosas para garantizar que se prueben todos los casos de esquina posibles. En última instancia, el consenso parece ser que, si bien las implementaciones de referencia pueden ser útiles, no deberían ser necesarias en la especificación ONNX.
  
  
• 00:25:00 En esta sección, hay una discusión sobre los requisitos para implementar un operador en ONNX, específicamente con respecto a la necesidad de una implementación de referencia y procedimientos de prueba. Mientras que algunos argumentan que una implementación de referencia para el operador debería ser obligatoria para generar datos de prueba, otros no están de acuerdo y afirman que es suficiente proporcionar una función de Python para generar datos de prueba o un conjunto de datos fijo. Sin embargo, se observa que tener una implementación de referencia es crucial para que alguien implemente el operador en tiempo de ejecución para probar adecuadamente su implementación, especialmente para operadores complicados con muchos atributos diferentes. La discusión también aclara que si bien no es necesario un tiempo de ejecución de referencia para ONNX, se requiere una implementación de referencia para cada operador.
  
  
• 00:30:00 En esta sección del video, los oradores discutieron la importancia de tener una implementación de referencia y casos de prueba mejor definidos para garantizar una implementación y prueba adecuadas de ONNX. Señalaron que confiar en los datos de prueba generados puede ser insuficiente y que tener un código simple disponible resuelve el problema para todos. La conversación también abordó la necesidad de una especificación completa y la libertad del tiempo de ejecución para determinar qué hacer en casos de comportamiento indefinido. Algunos oradores expresaron su preocupación por agregar una carga a los operadores que proponen al agregar una implementación de referencia. Sugirieron minimizar el esfuerzo de ingeniería y revisar los requisitos actuales para agregar operaciones al sistema.
  
  
• 00:35:00 En esta sección del video, los oradores discuten la importancia de tener una especificación completa e inequívoca para ONNX y las formas de hacerla cumplir. Están de acuerdo en que una implementación de referencia en Python sería útil para garantizar que las personas que implementan operadores en los tiempos de ejecución puedan verificar todos los casos de prueba. Sin embargo, también reconocen que la implementación de una especificación no es simple y que todavía hay problemas que abordar. Discuten formas de aclarar cómo se puede usar la especificación y proponen que la práctica y los comentarios guíen la propuesta de nuevos operadores, en lugar de proponer un operador y luego implementarlo en un tiempo de ejecución. También señalan que un requisito para agregar una nueva operación es que debe implementarse en un marco conocido.
  
  
• 00:40:00 En esta sección de la discusión de la hoja de ruta de ONNX, el grupo analiza el proceso para agregar nuevos operadores a la especificación de ONNX. La propuesta es cambiar la política para agregar un nuevo operador, que ya requiere una implementación de referencia en Python. Su discusión se centra en las implementaciones de referencia y las pruebas de cumplimiento, y planean continuar la conversación dentro del operador SIG y en el foro de discusión de GitHub. El grupo planea continuar las discusiones en su próxima reunión programada para la próxima semana.

[MetaQuotes]

Discusión n.º 3 de la hoja de ruta de ONNX 2020 20200916

Discusión n.º 3 de la hoja de ruta de ONNX 2020 20200916

La discusión en este video se centra en varios temas relacionados con ONNX, incluida la mejora del manejo de errores, la adición de un campo de esquema de metadatos predefinido para indicar la creación del modelo, la necesidad de optimización física de cuantificación y la posibilidad de actualizar modelos ONNX de Model Zoo a las versiones más recientes. El equipo planea priorizar estos temas en función de su impacto y costo y trabajar en ellos después del lanzamiento de 1.8. Además, el grupo considera la idea de crear diferentes enlaces de lenguaje para el conjunto de herramientas ONNX, con un interés particular en Java, para admitir diferentes plataformas como Spark. Los oradores también discuten la posibilidad de crear un envoltorio de Java alrededor de ONNX Runtime.

• 00:00:00 En esta sección, el orador sugiere discutir tres temas con la comunidad: manejo de errores, mejorar el zoológico modelo e implementar más operaciones u operadores para la cuantificación. Planean utilizar las próximas tres sesiones para hablar sobre el costo y el impacto de estos temas y determinar la priorización en función de los elementos con el mayor impacto y bajo costo. También abordan una pregunta sobre el impacto de estos temas en la versión 1.8 y explican que la mayoría de estos cambios se realizarán después de la 1.8. Un miembro de la comunidad sugiere mejorar el manejo de errores para que, si el tiempo de ejecución encuentra protobufs con formato incorrecto, no finalice y, en su lugar, devuelva un código de error o genere una excepción para garantizar una mejor experiencia de usuario.
  
  
• 00:05:00 En esta sección, la discusión se centra en mejorar el manejo de errores del código de carga en ONNX para evitar bloqueos y mejorar la funcionalidad. El equipo realizó una revisión del código y descubrió que los modelos que no son de confianza tienen el potencial de acabar con todo el proceso, por lo que es una prioridad para abordar. El tiempo de ejecución de ONNX tiene un proceso de verificación diferente al verificador de ONNX y aún no está claro si pueden compartir el mismo verificador. Además, se plantea el tema de un mejor manejo de errores durante las auditorías, y el equipo planea dar seguimiento a esta sugerencia.
  
  
• 00:10:00 En esta sección, el orador analiza su biblioteca llamada Trivial que interactúa con el ecosistema ONNX y sirve modelos ONNX. Proponen agregar un campo de esquema de metadatos predefinido en ONNX para indicar la marca de tiempo cuando se creó el modelo, el algoritmo de entrenamiento utilizado para el modelo y qué biblioteca de origen se utilizó para generarlo. Sugieren definir nombres clave estándar para el campo de metadatos y escribirlos también. El orador cree que tener un esquema para el campo de metadatos sería útil para las bibliotecas y otros usuarios que sirven modelos ONNX. Luego, la conversación cambia a la necesidad de ampliar las pruebas de modelos para cubrir todos los modelos en Model Zoo y proporcionar buenos ejemplos con alta calidad.
  
  
• 00:15:00 En esta sección, la discusión se centra en la necesidad de una optimización física de cuantificación, así como en la expansión del zoológico de modelos de ONNX para incluir modelos cuantificados. Ha habido varias solicitudes para incluir modelos cuantificados en el zoológico modelo, y el equipo espera encontrar colaboradores. Mencionan un blog donde el modelo ONNX cuantificado de Hugging Face ha funcionado bien, pero necesitarían el permiso de Hugging Face para publicarlo. También se sugirió que el modelo superior de la biblioteca de transformadores podría ser un ejemplo para la cuantificación, y tanto Microsoft como Space trabajan en él. Además, hubo una discusión sobre la optimización y algunos acordaron que es mejor dejar la optimización para el tiempo de ejecución, ya que está más allá del alcance de la especificación de ONNX.
  
  
• 00:20:00 En esta sección, los participantes discuten la posibilidad de actualizar los modelos ONNX de Model Zoo a las versiones más recientes utilizando la herramienta Version Converter. Sin embargo, señalan que Version Converter no está completamente actualizado y existe cierta incertidumbre sobre si la conversión es necesaria, ya que ONNX es compatible con todas las versiones anteriores. El grupo también considera la idea de diferentes enlaces de lenguaje para el conjunto de herramientas ONNX, con un interés particular en Java, para admitir diferentes plataformas como Spark. La adición de una API de Java o enlaces facilitaría la carga y validación de archivos modelo y la realización de un convertidor de otras bibliotecas al formato ONNX.
  
  
• 00:25:00 En esta sección, los oradores analizan la posibilidad de crear un envoltorio de Java alrededor de ONNX Runtime, lo que facilitaría las cosas para los proyectos de aprendizaje automático basados en JVM, como Spark. Aunque no es una tarea trivial, el uso de los ajustes preestablecidos de Java CPP para generar automáticamente stubs podría ser un buen punto de partida. La compatibilidad con versiones anteriores es crucial para proyectos grandes como Spark, y apuntar a Java 8 requeriría un trabajo significativo. Sin embargo, si hay suficiente interés y disposición de la comunidad para contribuir, podría ser bueno explorarlo.

[MetaQuotes]

Discusión n.° 4 de la hoja de ruta de ONNX 2020 20200923

Discusión n.° 4 de la hoja de ruta de ONNX 2020 20200923

La cuarta parte de la discusión de la hoja de ruta de ONNX cubre los temas de soporte de marcos de datos, preprocesamiento, estandarización, canalización de aprendizaje automático de extremo a extremo y recomendaciones de herramientas. El soporte de marcos de datos se evalúa como valioso para los modelos clásicos de aprendizaje automático y podría eliminar la necesidad de preprocesamiento. Se destaca la necesidad de capturar el procesamiento previo dentro del modelo ONNX para mejorar el rendimiento, con un enfoque en la estandarización de categorías de alto nivel como el procesamiento de imágenes. La canalización de un extremo a otro tiene una prioridad baja, pero se sugiere agregar gradualmente componentes a la canalización. La discusión concluye con una recomendación de usar una herramienta para ayudar a una mayor discusión y análisis de los puntos de la agenda.

• 00:00:00 En esta sección, los oradores analizan la hoja de ruta de ONNX y las funciones sugeridas por la comunidad. Han cubierto tres secciones hasta ahora, incluida la canalización de ML y el procesamiento de datos, la definición de operaciones o IRS y la robótica central. El documento de hoja de ruta incluye una tabla de las características sugeridas, que se clasifican como de prioridad alta, media y baja. Sin embargo, algunos de los temas son demasiado genéricos, lo que dificulta evaluar su importancia. Los oradores planean pasar los próximos 30 minutos discutiendo por qué algunas de estas funciones recibieron una calificación alta y recopilando comentarios de la comunidad sobre qué funciones son las más importantes.
  
  
• 00:05:00 me preguntaba cómo se está priorizando la hoja de ruta de ONNX, esta sección del video analiza la importancia de una función de soporte de marco de datos y cómo podría resolver otros problemas dentro de la plataforma. El orador explica que esta función sería valiosa para los científicos de datos y podría anular la necesidad de una función de preprocesamiento. También mencionan la necesidad de obtener una estimación de costos de ingeniería para cada elemento en la hoja de ruta para priorizar las tareas de manera efectiva. Se agradecen las sugerencias ya que es la primera vez que se presenta la hoja de ruta de esta manera.
  
  
• 00:10:00 En esta sección de la discusión de la hoja de ruta de ONNX, se analiza la importancia del soporte de tramas de datos para los modelos de aprendizaje automático. Se cree que la compatibilidad con marcos de datos es principalmente para modelos clásicos de aprendizaje automático, en lugar de DNN u otros modelos. El marco de datos se diferencia de la secuencia en que es una colección heterogénea de tensores o una tabla relacional con columnas que pueden tener diferentes tipos. La importancia de cada característica se evalúa en función del impacto que tendrá, y se tendrán en cuenta los costos de ingeniería. Se sugiere que se proporcione un comentario por cuadro para resaltar por qué una característica tiene una importancia alta o baja.
  
  
• 00:15:00 En esta sección, se analiza la importancia del procesamiento previo dentro de un modelo ONNX. La conversación destaca la necesidad de capturar todos los pasos necesarios dentro del modelo ONNX en lugar de depender de bibliotecas externas, especialmente en el contexto de la capacitación, donde el preprocesamiento puede tener un impacto significativo en el rendimiento. Además, el preprocesamiento puede ser útil en el lado de la inferencia, particularmente si no es en un entorno basado en Python. La discusión también toca los desafíos de estandarizar el procesamiento previo debido a la naturaleza heterogénea de los tipos de datos. Aunque el preprocesamiento es un tema amplio y complejo, la conversación concluye que es necesario considerar los operadores y tipos faltantes dentro de ONNX para estandarizar el preprocesamiento.
  
  
• 00:20:00 En esta sección, los oradores analizan el amplio alcance del preprocesamiento y cómo podría incluir no solo el procesamiento relacionado con la visión, sino también los datos de audio. Si bien es importante tener en cuenta el procesamiento previo, los oradores señalan que puede no ser necesario admitir todos los tipos de datos y, en cambio, la estandarización en categorías de alto nivel, como el procesamiento de imágenes, podría ser más beneficiosa para los desarrolladores. Sin embargo, los oradores advierten que incluso las tareas de preprocesamiento aparentemente simples, como el cambio de tamaño de la imagen, pueden tener sutiles diferencias entre bibliotecas, lo que hace que la estandarización sea un desafío de ingeniería. No obstante, la estandarización de las tareas de preprocesamiento puede ser útil, y los oradores sugieren recopilar pasos comunes de preprocesamiento para considerarlos en el futuro.
  
  
• 00:25:00 En esta sección, los oradores discuten la prioridad de incluir la tubería de aprendizaje automático de extremo a extremo en ONNX, y algunos afirman que es una prioridad baja debido a los otros elementos que deben abordarse. Sin embargo, reconocen la utilidad de tener un ejemplo e ilustración de extremo a extremo de cómo se puede aplicar ONNX, particularmente cuando ONNX Runtime se incorpora a la mezcla. Se sugiere la idea de agregar gradualmente componentes a la canalización, con un enfoque en la parte de capacitación, afinar ONNX y, finalmente, agregar preprocesamiento a la mezcla. La discusión finaliza con la recomendación de utilizar una herramienta para facilitar la discusión y el análisis de impacto de los puntos de la agenda.
  
  
• 00:30:00 En esta sección, el orador agradece a todos por unirse e informa a la audiencia que intentarán publicar la discusión en las redes sociales y en el sitio web de ONNX.

[MetaQuotes]

Discusión n.º 5 de la hoja de ruta de ONNX 2020 20201001

Discusión n.º 5 de la hoja de ruta de ONNX 2020 20201001

Durante la discusión de la hoja de ruta de ONNX, el equipo de ONNX discutió varias características sugeridas por miembros de la comunidad y calificadas por diferentes personas, incluido el comité directivo. Si bien algunas características se acordaron por unanimidad, otras dividieron a la comunidad. El equipo discutió la posibilidad de cambiar ONNX IR a múltiples IR y bibliotecas de optimización de IR centralizadas. También discutieron la idea de centralizar las bibliotecas de optimización dentro de ONNX y el requisito de que las operaciones implementen una interfaz estándar y un estilo de codificación. El equipo también debatió la posibilidad de tener un tiempo de ejecución simple para los modelos ONNX y el uso de operaciones de Python personalizadas para los casos en los que el tiempo de ejecución de ONNX no está disponible. Además, el equipo exploró la relación entre las operaciones de preprocesamiento y el uso de marcos de datos, planeando convertir sus ideas en propuestas procesables para el trabajo futuro.

• 00:00:00 En esta sección, el equipo de ONNX analiza la hoja de cálculo de análisis de impacto que se creó para capturar los pensamientos de diferentes personas sobre lo que es importante para el proyecto. Hicieron una lista de todas las diferentes características que se sugirieron y obtuvieron puntajes de diferentes personas, incluido el comité directivo y otros miembros de la comunidad. Se dieron cuenta de que había algunas funciones en las que todo el mundo parecía estar de acuerdo en que eran realmente importantes o no lo eran en absoluto, y otras en las que la comunidad estaba dividida. Discutieron los que estaban divididos y los próximos pasos para los que acordaron que eran importantes. También hablaron sobre establecer criterios para lo que se considera de alta prioridad y cómo eso depende de quién esté dispuesto a dedicar tiempo a implementar una función.
  
  
• 00:05:00 En esta sección de la discusión de la hoja de ruta de ONNX, los participantes discuten la idea de cambiar ONNX IR a múltiples IR y bibliotecas de optimización de IR centralizadas. Existe cierto debate sobre si estas dos ideas deben agruparse, ya que la optimización y el IR son temas separados. El objetivo de tener múltiples IR es simplificar y concatenar operaciones más simples, mientras que las bibliotecas de optimización mejorarían el núcleo de ONNX. Hay más discusión sobre lo que significa ONNX IR y se necesita una aclaración. Los participantes también discuten cómo estos cambios potenciales podrían afectar sus puntajes actuales en la hoja de ruta de ONNX.
  
  
• 00:10:00 En esta sección, el equipo analiza la posibilidad de centralizar las bibliotecas de optimización en ONNX, pero finalmente acepta que la optimización debe ser parte del tiempo de ejecución y que tiene menor prioridad en comparación con otros problemas. También discuten el requisito de que las operaciones se implementen de una manera específica, con una interfaz estándar y un estilo de codificación, que ya es un requisito pero que puede necesitar ajustes. Sugieren que si alguien propone un estilo específico, se puede aceptar si parece aceptable.
  
  
• 00:15:00 En esta sección, los oradores discuten la idea de tener un tiempo de ejecución simple para los modelos ONNX, lo que plantea preocupaciones sobre la complejidad de requerir un flujo de ejecución e IR interno para procesar el modelo. Sin embargo, es valioso poder ejecutar y evaluar modelos ONNX para probar y establecer la corrección, especialmente al revelar cualquier brecha en las pruebas unitarias para los operadores. Si bien puede ser discutible cuánto esfuerzo y costo llevaría implementar un tiempo de ejecución simple, el tiempo de ejecución de ONNX tiene la capacidad de conectar las operaciones de Python, que podrían usarse para este propósito.
  
  
• 00:20:00 En esta sección, los participantes de la discusión de la hoja de ruta de ONNX hablaron sobre la posibilidad de usar una operación de Python personalizada para casos específicos donde el tiempo de ejecución de ONNX no está disponible . Discutieron las limitaciones de Python op y la necesidad de una interfaz estándar para garantizar la viabilidad. Además, el grupo discutió la necesidad de más capacidades de preprocesamiento dentro del gráfico ONNX para hacer que los modelos sean más autónomos y portátiles, especialmente para el preprocesamiento basado en imágenes, como el escalado y el manejo de cuadros delimitadores. El grupo señaló que el preprocesamiento de texto, específicamente la tokenización, es un tema más complicado y completo, pero es posible que puedan abstraer algunos escenarios comunes de preprocesamiento.
  
  
• 00:25:00 En esta sección, los participantes discuten la relación entre las operaciones de preprocesamiento y el uso de tramas de datos. Si bien están de acuerdo en que el preprocesamiento y los marcos de datos están vinculados, los ven como entidades separadas que requieren diferentes tipos de trabajo. El preprocesamiento se ve como un operador que funciona por filas en una columna de un marco de datos, mientras que la propia extracción del marco de datos asigna el operador de preprocesamiento en las filas de una columna. El grupo ve a los dos como estrechamente vinculados y planea convertir sus ideas en propuestas procesables para el trabajo futuro.

[MetaQuotes]

Discusión n.º 1 de la hoja de ruta de ONNX 2021 20210908

Discusión n.º 1 de la hoja de ruta de ONNX 2021 20210908

Durante la discusión de la hoja de ruta de ONNX, IBM Research presentó su propuesta para un nuevo marco de canalización de aprendizaje automático que convierte los patrones típicos de preprocesamiento de datos en Pandas Dataframe al formato ONNX. El marco, denominado Data Frame Pipeline, es de código abierto en GitHub y se puede definir mediante la API proporcionada, que se ejecuta en Python durante la fase de capacitación. Los disertantes también discutieron la necesidad de hacer visible ONNX en lenguajes distintos a Python, como Java, C# y C++, y la exportación de modelos ONNX y su emisión desde otros lenguajes. Además, discutieron las funcionalidades actuales de los convertidores ONNX Python y C++ y la necesidad de funcionalidades de alcance, nombres y parches al escribir modelos ONNX.

• 00:00:00 En esta sección, Takuya de IBM Research presenta su propuesta para un nuevo marco de canalización de aprendizaje automático con nuevos operadores ONNX. La motivación de la propuesta se debió a la incapacidad de los marcos de canalización existentes para representar un patrón típico de preprocesamiento de datos. Crearon un prototipo de un nuevo marco de canalización llamado Data Frame Pipeline en Python, que convierte los patrones típicos de preprocesamiento de datos en Pandas Dataframe al formato ONNX. Protegieron tres nuevos operadores ONNX, incluido un operador de fecha y dos operadores simples, concatenadores de cadenas y divisores de cadenas. El marco de canalización es de código abierto en GitHub y se puede definir mediante la API proporcionada, que se ejecuta en Python durante la fase de capacitación. El modelo se entrena con los datos que se generan desde la canalización del marco de datos, y su marco puede consumir modelos de aprendizaje automático ONNX ya convertidos.
  
  
• 00:05:00 En esta sección, el orador analiza el formato ONNX y cómo se puede usar con el tiempo de ejecución ONNX, proporcionado por Microsoft. Mencionan que en su prototipo, implementaron 11 transformadores de marcos de datos en Python y los mapearon a operadores ONNX, siendo la mayoría mapeos simples, pero algunos requirieron análisis y conversión, como el transformador de funciones. También analizan su enfoque para generar operadores ONNX con propiedades de cuerpo cargadas, en lugar de realizar operadores de agregación en ONNX. El orador comparte resultados experimentales preliminares que muestran una aceleración significativa al aprender el preprocesamiento en ONNX, con una mejora del rendimiento de 300 veces para la codificación categórica. También comparan la precisión de la predicción y mencionan su propuesta, abriendo el turno de preguntas y comentarios sobre los operadores presentados.
  
  
• 00:10:00 En esta sección, Adam Pogba de Oracle Labs sugiere que ONNX debería hacerse visible en otros lenguajes además de Python, ya que la funcionalidad actual está toda encapsulada en Python y no está claro si C++ es un destino válido para el enlace. Pogba explica que el verificador de modelos debe ser visible en otros idiomas para que los usuarios puedan interactuar con él sin necesidad de un entorno de Python válido. Además, Pogba menciona que ONNX Runtime ocasionalmente falla en la segmentación cuando consume modelos debido a problemas de análisis, y el verificador de modelos podría usarse para validar y solucionar fácilmente este problema.
  
  
• 00:15:00 En esta sección, el orador analiza la funcionalidad central de la verificación de modelos y cómo sería útil exponerla en otros idiomas. Si bien les gustaría tenerlo en Java, entienden que no todos escribirían una API de Java, por lo que una API de C es una mejor opción para que la mayoría de los lenguajes se enlacen fácilmente. Sin embargo, debe haber un objetivo estable y apropiado para que las personas se vinculen, y no está claro de inmediato si la API de C++ de cualquiera de estas herramientas se considera un objetivo apropiado para el enlace. El orador está dispuesto a participar en este esfuerzo, pero no vale la pena tratar de impulsar un gran esfuerzo a menos que haya interés por parte de la comunidad.
  
  
• 00:20:00 En esta sección, el ponente analiza la exportación de modelos ONNX y su emisión desde otros lenguajes además de Python, como C# y Java, con un enfoque específico en ML.NET y Trivial Library. El orador insta a la necesidad de una API común que todos los proyectos puedan usar para generar modelos ONNX, especialmente considerando las tres implementaciones diferentes actualmente presentes sin código compartido que son propensas a errores. La API común garantizaría un solo lugar para actualizar y validar los nodos y los gráficos, brindando la oportunidad de compartir fortalezas y facilitar que otras bibliotecas de aprendizaje automático emitan modelos ONNX. El orador reconoce que, aunque esto podría ser mucho trabajo, el esfuerzo compartido podría hacer crecer el ecosistema ONNX más allá de Python.
  
  
• 00:25:00 En esta sección, los oradores discuten los convertidores ONNX Python y C++ y sus funcionalidades actuales. Señalan que la documentación de ONNX no es lo suficientemente específica, lo que dificulta la comprensión de ciertas funciones. Sin embargo, afirman que muchas de las funcionalidades necesarias para la exportación ONNX ya existen en estos convertidores, pero deben exponerse de la manera correcta a otros proyectos. Además, discuten la necesidad de funcionalidades de alcance, nombres y parches al escribir modelos ONNX. Finalmente, sugieren que los convertidores podrían beneficiarse de estar vinculados a la infraestructura de arquitectura sig para que puedan ser utilizados fácilmente por diferentes personas.

[MetaQuotes]

Discusión n.° 2 de la hoja de ruta de ONNX 2021 20210917

Discusión n.° 2 de la hoja de ruta de ONNX 2021 20210917

En el debate n.º 2 de la hoja de ruta de ONNX 20210917, varios oradores discutieron varias áreas clave en las que ONNX necesita mejoras, incluida la cuantización y la facilidad de fusión, la optimización de kernels para plataformas de hardware específicas y la adición de funciones locales modelo a ONNX. Otros temas incluyeron comentarios sobre el soporte de tubería de extremo a extremo, desafíos que enfrentan los clientes en diferentes plataformas y problemas con la conversión de gráficos GRU y LSTM. Algunas soluciones sugeridas incluyeron proporcionar más información para que los backends ejecuten gráficos precuantificados, mejorar la interoperabilidad de diferentes marcos e incluir un espacio de nombres relacionado con el gráfico original para permitir una solución general y optimizada. Además, los oradores discutieron la necesidad de una mejor implementación de paquetes para una adopción más amplia y el potencial para desarrollar más convertidores para admitir modelos multimodales.

• 00:00:00 En esta sección, Martin de Green Waves Technologies analiza las dos áreas en las que ONNX necesita mejoras, la cuantificación y la facilidad de fusión. Para la cuantificación, Martin sugiere proporcionar más información para que los backends ejecuten gráficos precuantificados, ya que es imposible que ONNX siga todas las diferentes formas en que los clientes quieren implementar cosas especializadas. Para ayudar en esto, Martin sugiere agregar min max, desviación estándar e información media a los tensores, con información adicional como estadísticas de valores atípicos, información de canal por canal e información de distribución como posibles complementos. Para facilitar la fusión, Martin sugiere mejorar la interoperabilidad de diferentes marcos al proporcionar mejores funciones de importación/exportación, lo que facilitaría que ONNX identifique los convertidores correctos para usar al importar/exportar diferentes gráficos.
  
  
• 00:05:00 En esta sección, el orador analiza el uso actual de funciones para operadores compuestos y la dificultad de optimizar kernels para plataformas de hardware específicas cuando los operadores están divididos. Se sugiere la idea de agrupar las funciones exportadas en un contenedor de nivel superior, posiblemente una función, y asignar ese contenedor a un kernel optimizado en un backend específico. El orador también sugiere incluir un espacio de nombres relacionado con el gráfico original, lo que permite tanto una solución general como una solución optimizada. También se menciona la adición de la capacidad de importar funciones locales modelo en la última versión de ONNX.
  
  
• 00:10:00 En esta sección, los oradores analizan la adición de funciones locales modelo a ONNX, lo que permite a los operadores de convertidores incluir un cuerpo de función en el prototipo del módulo como marcador de posición para operadores que no están definidos en el estándar ONNX. Sin embargo, los oradores también señalan que debería ser una buena práctica que los convertidores etiqueten y comenten lo que están exportando de una manera que sea legible por máquina. También mencionan cómo la optimización puede afectar las convenciones de nomenclatura y sugieren continuar la discusión sobre el tema en el canal de Slack o en una reunión adicional. Se presenta la siguiente presentación, que trata sobre la creación de perfiles ONNX.
  
  
• 00:15:00 En esta sección, se analizan los comentarios sobre el soporte de canalización de extremo a extremo, y ONNX se considera una excelente opción para implementaciones livianas en diferentes sistemas operativos que no exigen requisitos de ecosistema pesados. Los oradores expresan su esperanza en la dirección de permitir que los operadores de ONNX en ONNX y ONNX ML ejecuten no solo modelos sino también etapas de preparación de datos, incluida la cobertura de otros tipos de operaciones de producción de datos. Afirman que un artefacto o modelo de implementación simplificado o común podría agregar valor, junto con la capacidad de ahorrar esfuerzo y coherencia al centrarse en las conversiones estándar.
  
  
• 00:20:00 En esta sección, el orador analiza algunos de los desafíos que enfrentan los clientes en diferentes plataformas y señala el valor potencial de continuar desarrollando y ampliando la plataforma ONNX. Abordan el problema de los silos y la necesidad de simplificar la implementación de paquetes para una mejor adopción. La conversación también incluye comentarios de un participante que confirma que enfrenta problemas similares y propone opciones para fusionar el servidor Linux ONNX o encontrar mejores formas de ayudar a los usuarios a convertir código personalizado en ONNX. El orador también aborda el tema del soporte multimodal y la necesidad de que un conjunto de modelos se represente como un solo gráfico ONNX. Discuten la necesidad potencial de más convertidores y sugieren un movimiento general en la dirección correcta.
  
  
• 00:25:00 En esta sección de la discusión de la hoja de ruta de ONNX, el equipo analiza ejemplos de proxies para modelos de proxy para mostrar los tipos de cosas que los clientes usan en entornos empresariales para tipos de casos de uso que no son de imagen. Un miembro del equipo menciona un ejemplo de un proxy para un modelo de detección de fraude que usa algunos datos abiertos y es un modelo LSTM de dos capas relativamente simple. El equipo está investigando el asunto más a fondo y tratando de obtener más ejemplos de modelos proxy para presentar. También discuten problemas con GRU y LSTM que no se convierten correctamente y mencionan que les gustaría agregar soporte para todos los casos.
  
  
• 00:30:00 En esta sección, los oradores analizan los desafíos de convertir gráficos GRU (unidad recurrente cerrada) en un formato que pueda leer el convertidor de un back-end. Mencionan que hay ciertos casos en los que la falla ya ocurre en TensorFlow, pero es un desafío volver a convertirlo en GRU. Sugieren usar el indicador `--custom ops` y crear un kernel que funcione para él, antes de pasar a la idea de convertirlo en una función o preservarlo en términos de semántica. Señalan que la mejor opción es indicar explícitamente si el usuario quiere que se desglose o no, y que usar operaciones personalizadas podría ser la única forma de hacerlo de manera sólida.
  
  
• 00:35:00 En esta sección, los oradores discuten si es mejor tener el cuerpo de funciones completo tanto en ONNX como en un nivel alto o solo tener una base TF. Para ellos, la base TF sería suficiente ya que el ONNX podría usarse como prueba de resultado a lo largo de la cadena. Sin embargo, advierten que no se debe hacer que ONNX esté centrado en TensorFlow, ya que ONNX debería poder provenir de diferentes lugares. También mencionaron el atractivo de tener un subgrafo con nombre con un significado semántico, pensando en él casi como un operador, que debe ser definido y generado por varios front-end diferentes. Finalmente, acordaron tener presentaciones más profundas para continuar la discusión con personas más informadas.

[MetaQuotes]

Discusión n.º 3 de la hoja de ruta de ONNX 2021 20210922

Discusión n.º 3 de la hoja de ruta de ONNX 2021 20210922

Durante la discusión de la hoja de ruta de ONNX, los oradores abordaron la necesidad de solucionar problemas con la herramienta de conversión de compensación de ONNX para mejorar la adopción de ONNX con la última pila optimizada para ciertos casos de uso. Los oradores propusieron una mejor cobertura de los modelos para probar la conversión de compensación y la resolución de los pasos intermedios que actualmente faltan en las pruebas de operadores o capas. También discutieron la importancia de los metadatos y la infraestructura de aprendizaje federado, incluida la necesidad de incluir metadatos en la especificación ONNX para transferir anotaciones de aprendizaje y el concepto de aprendizaje federado para permitir la privacidad, la eficiencia y el uso de recursos computacionales. Los oradores alentaron la colaboración de la comunidad y solicitaron comentarios para seguir discutiendo e implementando estas ideas. La próxima sesión está prevista para el 1 de octubre.

• 00:00:00 En esta sección, Manoj de Intel aborda las brechas en las conversiones de compensación para los modelos ONNX que han causado problemas a muchos clientes. El problema básico radica en la conversión de compensación, ya que muchos clientes no van y siguen actualizando la compensación una vez que implementan un modelo en producción. Los clientes se enfrentan a múltiples problemas con la conversión de compensaciones, como pasar de 7 a 10 a 13 para la cuantificación o no poder convertir compensaciones más antiguas en nuevas para aprovechar el rendimiento y la buena precisión. Además, la prueba unitaria o todas las pruebas relacionadas con cada operador o capa no están a la altura del punto en el que los ISV están contentos y, por lo tanto, la mayoría de los clientes todavía tienen una compensación de 10 o 9.
  
  
• 00:05:00 En esta sección, los oradores discuten la necesidad de resolver problemas con la herramienta de conversión de compensación de ONNX, ya que está obstaculizando la adopción de ONNX con la última pila optimizada para ciertos casos de uso. Los desarrolladores que integran IA y la envían a sus aplicaciones brindan comentarios sobre la necesidad de corregir las herramientas de conversión y asegurarse de que funcionen sin problemas. Comparten ejemplos de problemas que enfrentaron, como la falta de pasos intermedios y la falta de implementaciones de adaptadores, que impiden la transición a modelos de rendimiento cuantificados. Los oradores enfatizan la necesidad de una mejor cobertura y más modelos para ser probados para garantizar una mejor adopción de ONNX.
  
  
• 00:10:00 En esta sección del video, los oradores analizan la necesidad de aprobar al menos un modelo fallido de una de las principales empresas creadoras para lograr mejoras adicionales en ONNX. La discusión pasa a la mejora en la conversión fp16, que era una de las brechas entre los diferentes ecosistemas como el móvil y Windows, y cómo se solucionó últimamente con las herramientas de conversión de Microsoft. La responsabilidad de la conversión no está clara, pero la discusión pasa a la próxima presentación sobre el zoológico modelo, donde la inclusión de operadores de fonética para la capacitación ayudará a cubrir todos los modelos en todas las categorías. Proponen comenzar con muestras de capacitación de transformador o NLP y pasar a más modelos para mostrar la infraestructura de capacitación distribuida y las técnicas aplicables a ONNX.
  
  
• 00:15:00 En esta sección, los oradores analizan la participación de los modelos ONNX en el entrenamiento, incluida la importancia del entrenamiento consciente de la cuantificación y el uso de precisión mixta. Solicitan el modelo fp32 original para comparar mejor la precisión y mostrar el uso de precisión mixta para el entrenamiento con modelos ONNX. Priorizan contribuir con muestras de transformadores, pero solicitan ayuda de la comunidad para contribuir con otras categorías populares. También discuten propuestas futuras para reflejar mejor el uso de precisión mixta dentro de un modelo como parte de los metadatos. Finalmente, Gabe Stevens presenta una configuración de implementación que Intel está comenzando a analizar.
  
  
• 00:20:00 En esta sección, el ponente discute el concepto de aprendizaje distribuido y federado y sus ventajas en términos de privacidad, latencia, eficiencia y uso de recursos computacionales. La idea es implementar modelos en una flota de dispositivos, donde algunos de los dispositivos tienen un grupo de entrenamiento que enriquece el modelo utilizando los datos que ven. Las modificaciones propuestas a ONNX le permitirían facilitar el aprendizaje federado, lo que haría más probable que los desarrolladores usen ONNX. El conjunto mínimo de adiciones a la API incluye una forma de consultar la pieza para obtener los parámetros del modelo local, actualizar esos parámetros y notificar al servidor cómo ha cambiado el modelo para consolidarse en un nuevo modelo que incluye los resultados de la dispositivos.
  
  
• 00:25:00 En esta sección del video, el orador analiza la idea de incluir metadatos en la especificación ONNX para permitir la transferencia de anotaciones de aprendizaje y facilitar el entrenamiento de un conjunto de datos más pequeño con un modelo entrenado en un conjunto de datos más grande. Sin embargo, la implementación de un sistema de este tipo implica múltiples decisiones de diseño que deben dejarse en manos de los implementadores. El orador sugiere tres elementos que podrían facilitar la infraestructura básica de dicho sistema sin limitar la flexibilidad necesaria para los desarrolladores de aplicaciones. También mencionan la necesidad de coherencia en la implementación de la versión del modelo en una flota de dispositivos y la importancia de no exigir que solo los modelos ONNX puedan participar en un sistema de aprendizaje federado. El orador solicita comentarios sobre si los diseñadores de especificaciones están interesados en prestar atención a este tipo de configuración de aprendizaje y si estarían abiertos a más debates. Otro orador sugiere tratar de hacer esto con el tiempo de ejecución de ONNX, ya que admite la capacitación y se han creado algunas pruebas de conceptos para realizar el aprendizaje federado usándolo.
  
  
• 00:30:00 En esta sección, el orador expresa su agradecimiento por el tremendo esfuerzo puesto en la presentación y agradece a la comunidad por sus preguntas. El objetivo de la presentación es presentar ideas al SIG correspondiente para su posterior discusión y eventual implementación. La última sesión se llevará a cabo el 1 de octubre y el orador espera seguir participando en estas ideas.

[MetaQuotes]

Reunión virtual de la comunidad ONNX: marzo de 2021

000 ONNX 20211021 ONNX SC Bienvenido Progreso Hoja de ruta Lanzamiento

El taller ONNX comenzó con una introducción, donde los organizadores enfatizaron la importancia de la participación comunitaria en el crecimiento del ecosistema ONNX. También brindaron una descripción general de la agenda, que incluyó actualizaciones sobre las estadísticas de ONNX, presentaciones de la comunidad y las discusiones sobre la hoja de ruta del Comité Directivo de ONNX. Las propuestas de hoja de ruta tienen como objetivo mejorar el soporte, la solidez y la usabilidad del marco ONNX e incluyen operadores de preprocesamiento, API de C, aprendizaje federado y una mejor integración del procesamiento de datos y la inferencia. También se discutió el lanzamiento reciente de la versión 1.10 de las especificaciones de ONNX y se alentó a los asistentes a hacer preguntas y participar en el canal ONNX Slack para continuar la conversación.

• 00:00:00 En esta sección del taller, los organizadores brindan una descripción general y dan la bienvenida a todos los asistentes. Mencionan la amplia gama de productos disponibles para la IA e instan a los asistentes a comprobarlo. Los objetivos generales del taller son obtener las últimas actualizaciones sobre ONNX, sus procesos, hoja de ruta y lanzamientos, así como aprender de los participantes de la comunidad sobre cómo se está utilizando ONNX. Animan a los asistentes a compartir sus comentarios, a involucrarse más con el Comité Directivo de ONNX, los SIG y los Grupos de Trabajo. Brindan una descripción general de la agenda, que incluye la logística del Grupo de Trabajo ONNX, la presentación del Estado del Estado a cargo de Wenming Yi, seguido de Alex, y presentaciones de la comunidad. Finalmente, presentan emocionantes actualizaciones sobre las estadísticas de ONNX, incluido un aumento de casi el 400 % en las descargas mensuales a 1,6 millones por mes, lo que muestra un crecimiento saludable en el ecosistema.
  
  
• 00:05:00 En esta sección, el disertante analiza el progreso y crecimiento del ecosistema ONNX, enfatizando la importancia de las contribuciones de las empresas en la comunidad. El orador menciona el proyecto de la biblioteca java profunda de Amazon, que ha creado una buena experiencia para la comunidad Java y ha experimentado un gran crecimiento. Varias empresas comerciales, como IBM, AMD y Sony, brindan soporte para el ecosistema y ayudan a que ONNX se convierta en el estándar de la industria. El orador también habla sobre la gobernanza de la comunidad y los nuevos miembros del comité directivo, e invita a participar en las discusiones de la hoja de ruta, el canal de Slack, las preguntas y respuestas en GitHub y la contribución a la documentación y los blogs. El siguiente orador continúa con la hoja de ruta, que es crucial para avanzar en la dirección correcta y reducir los modelos ONNX a baterías para CPU y aceleradores.
  
  
• 00:10:00 En esta sección, el orador analiza las discusiones sobre la hoja de ruta del Comité Directivo de ONNX, que tuvo lugar durante el verano. Las propuestas recibidas de los diferentes miembros se dividen en cuatro grupos de tres propuestas cada uno, y cada grupo se presenta a los respectivos Sigs para su aprobación e implementación. Las propuestas van desde operadores de preprocesamiento, C API, verificación de modelos, soporte para emitir modelos en otros lenguajes, agregar información de metadatos en tensores, integrar mejor el procesamiento e inferencia de datos, definir conceptos para el aprendizaje federado, definir propiedades de procesamiento de metadatos para mejorar la integridad. de datos, modelos y más. El objetivo es permitir un mejor soporte, robustez y facilidad de uso del marco ONNX para todos los usuarios.
  
  
• 00:15:00 En esta sección, el orador analiza el reciente lanzamiento de la versión 1.10 de las especificaciones de ONNX y agradece a los colaboradores por su arduo trabajo. Habrá más discusiones y detalles sobre este último cambio en el sitio web next.ai. El orador invita a la audiencia a publicar cualquier pregunta en el chat o en el canal general de Slack de ONNX para continuar la conversación.

[MetaQuotes]

¡Día de la comunidad ONNX! Transmitido en vivo el 24 de junio de 2022

Este evento se realizará en persona en el nuevo campus de Microsoft Silicon Valley el viernes 24 de junio.

El evento cubrirá actualizaciones de la comunidad ONNX, historias de socios y usuarios, y muchas redes comunitarias.

¡Día de la comunidad ONNX!

Breve resumen:

• 00:00:00 - 01:00:00 El video de YouTube "¡Día de la comunidad ONNX!" analiza las actualizaciones y mejoras del trabajo de la comunidad ONNX sobre interoperabilidad y flexibilidad para los desarrolladores que trabajan con modelos de aprendizaje automático. La comunidad ONNX trabaja bajo un gobierno abierto, y las tres categorías de herramientas, creación, ejecución y visualización, respaldan la participación y el uso de ONNX por parte de la comunidad. El video proporciona informes de progreso sobre diferentes aspectos, como actualizaciones de las especificaciones de ONNX, nuevos operadores y mejoras en los convertidores. El orador también destaca los beneficios de ONNX, incluida la gama más amplia de clientes para los proveedores de hardware y el acceso a múltiples marcos y aceleradores de hardware para los usuarios. El futuro de ONNX incluye la noción de funciones de ONNX para proporcionar una especificación ejecutable.
  
  
• 01:00:00 - 02:00:00 El evento del Día de la comunidad de ONNX analiza varios temas relacionados con ONNX, incluidos ONNX Model Zoo y ONNX Tutorials, que proporcionan modelos de aprendizaje automático preentrenados y demostraciones para usar con modelos ONNX. El video destaca el trabajo del Grupo de trabajo de preprocesamiento de ONNX, cuyo objetivo es estandarizar las operaciones de preprocesamiento de datos para mejorar la implementación del modelo. Los oradores también analizan los conceptos básicos de la cuantificación de redes neuronales y cómo TensorRT admite redes cuantificadas a través de varias fusiones, incluida la cuantificación posterior al entrenamiento y el entrenamiento consciente de la cuantificación. También profundizan en las limitaciones de ONNX para representar la cuantificación de baja precisión y sugieren una estrategia para ampliar su poder de representación mediante el recorte para inducir precisión entre los nodos cuantificados y descuantificados. Finalmente, el video profundiza en un estudio de caso sobre la precisión de un modelo guardado de TensorFlow cuantificado y ajustado.
  
  
• 02:00:00 - 03:00:00 El día de la comunidad de ONNX mostró numerosos oradores que discutieron la importancia de los metadatos en los modelos de aprendizaje automático y el soporte de Java Virtual Machine (JVM) en ONNX. Los oradores enfatizaron el uso de tecnologías basadas en hardware para proteger los datos y destacaron la compatibilidad de ONNX con varias bibliotecas de aprendizaje automático, incluidas DeepJ y Deep Java Library. Demostraron el uso de búferes de bytes para una mayor eficiencia y discutieron la importancia de estandarizar los metadatos para una IA responsable y explicable. Las presentaciones también incluyeron historias de éxito, incluido el tiempo de ejecución de un banco chino mejorado con ONNX y el tiempo de ejecución de ONNX. La comunidad ONNX está trabajando en la creación, consulta y filtrado de metadatos desde el flujo de trabajo de los centros con soporte para metadatos legibles por máquina en ONNX. En general, las presentaciones destacaron las fortalezas de la plataforma ONNX y el compromiso de la comunidad con su desarrollo.
  
  
• 03:00:00 - 04:00:00 ¡El "Día de la comunidad ONNX!" El video cubre varias actualizaciones y funciones relacionadas con el ecosistema ONNX. Esto incluye una discusión sobre la simulación de la cuantificación para reducir la caída de la precisión entre los modelos cuantificados y preentrenados, la implementación de modelos TensorFlow entrenados con el kit de herramientas de NVIDIA en un gráfico ONNX usando TensorRT y las mejoras realizadas en ONNX Runtime, como la forma optimizada del tensor, los proveedores de ejecución y Soporte para plataformas móviles. Además, se discutieron las actualizaciones de ONNX, incluida la compatibilidad con la biblioteca XNNpack y la creación de extensiones de tiempo de ejecución de ONNX para tareas de procesamiento previo y posterior. El video también presenta la biblioteca Optimum, que se enfoca en acelerar los modelos de transformadores desde el entrenamiento hasta la inferencia.
  
  
• 04:00:00 - 05:00:00 El día de la comunidad de ONNX incluyó discusiones sobre varios temas relacionados con el tiempo de ejecución de ONNX y sus casos de uso. Los oradores describieron las características del paquete de tiempo de ejecución ONNX, el convertidor PiTorch ONNX y operaciones personalizadas en PyTorch. También discutieron casos de uso como el monitoreo de procesos y la digitalización del comercio, así como los desafíos asociados con la implementación de modelos y las pruebas de compatibilidad. A lo largo del evento, se enfatizó que el tiempo de ejecución de ONNX puede ayudar a mejorar el rendimiento y reducir el tamaño de la implementación, pero la compatibilidad y la selección son esenciales para garantizar una calidad y velocidad constantes.
  
  
• 05:00:00 - 06:00:00 El día de la comunidad ONNX contó con varios oradores que discutieron varias herramientas y técnicas utilizadas para optimizar e implementar modelos de aprendizaje automático utilizando el marco ONNX. NVIDIA habló sobre su enfoque para mejorar la calidad de imagen y la compatibilidad de modelos mediante la división de bloques para la inferencia, así como sus herramientas específicas de ONNX para depurar y modificar modelos. Qualcomm explicó cómo han integrado aceleradores de IA en sus diseños utilizando ONNX como formato de intercambio y presentó su pila de software que incluye el tiempo de ejecución de ONNX y varias herramientas para la optimización y la implementación. Además, varios oradores hablaron sobre la optimización de los modelos ONNX mediante técnicas como la optimización de módulos, los puntos de control y la inferencia de formas. El evento destacó la versatilidad y escalabilidad de ONNX para varios casos de uso de dispositivos y alentó las contribuciones para continuar con el crecimiento del proyecto ONNX. La última parte se centra en simplificar el proceso de implementación de modelos de aprendizaje automático en Spark utilizando la propuesta SPIP, que tiene como objetivo ocultar las complejidades de la conversión de procesamiento de pestañas y la inicialización del modelo para los desarrolladores. Se presentó el ecosistema Ascend AI y sus procesadores, incluida la capa de software "Kung" que proporciona API para crear aplicaciones y servicios de IA. Se discutió la pila de software de Khan y se presentó la hoja de ruta para agregarlo como un nuevo proveedor de ejecución para el tiempo de ejecución de ONNX. El evento finalizó con mesas redondas sobre temas como ONNX para dispositivos móviles y Edge, implementación de modelos, capacitación y operaciones, conversiones y operadores, seguidas de una hora feliz y comentarios de encuestas.

El resumen detallado de la línea de tiempo:

• 00:15:00 Cree el modo en el marco que prefiera y luego exporte su modelo a un formato común que puedan usar otros marcos y herramientas. Esto permite una mayor interoperabilidad y flexibilidad para los desarrolladores que trabajan con modelos de aprendizaje automático. Además, ONNX es beneficioso para los proveedores de hardware que desean crear tiempos de ejecución optimizados para modelos de aprendizaje automático, ya que ahora pueden concentrarse en admitir el conjunto común de operadores definidos por ONNX en lugar de tener que admitir múltiples marcos diferentes.
  
  
• 00:20:00 En esta sección, el orador analiza los beneficios de usar ONNX, que permite el acceso a múltiples marcos y aceleradores de hardware para los usuarios, así como una gama más amplia de clientes para los proveedores de hardware. El desarrollo de ONNX lo realiza la comunidad bajo un gobierno abierto, lo que significa que no hay una sola empresa que lo controle. El ponente también destaca los grupos de trabajo que incluyen arquitectura e infraestructura, convertidores de operadores, la zona de modelos, tutoriales y un nuevo grupo de trabajo de preprocesamiento. El orador continúa describiendo las tres categorías de herramientas, creación, ejecución y visualización de modelos ONNX, y proporciona algunas estadísticas de los últimos seis meses, como un aumento en el número de PR, colaboradores, estrellas y descargas mensuales. reforzar el compromiso de la comunidad y el uso de ONNX.
  
  
• 00:25:00 En esta sección, el orador analiza los lanzamientos y las actualizaciones que se han producido en la comunidad ONNX desde la última actualización de la comunidad. ONNX 1.11 se lanzó a principios de este año, lo que introdujo nuevos operadores y actualizó algunos operadores, incluido el centro de modelos ONNX, que permite a los usuarios extraer modelos previamente entrenados de diferentes zoológicos modelo. Además, se introdujeron utilidades como la utilidad de redacción y el generador de funciones, junto con correcciones de errores y mejoras de infraestructura. ONNX 1.12 se presentó recientemente con más operadores nuevos, mejoras de forma e inferencia y compatibilidad con python 3.10. El orador también analiza el proceso de hoja de ruta de ONNX y 12 solicitudes de hoja de ruta que se seleccionaron para seguir avanzando y se asignaron a los grupos de trabajo. Estas solicitudes incluyen la implementación de nuevos operadores para el preprocesamiento de datos, una API C para ONNX y más.
  
  
• 00:30:00 En esta sección del video, el orador analiza el progreso realizado para abordar la necesidad de que la información cuantificada más estructurada fluya a través del modelo y los tensores. La propuesta para el gasoducto de extremo a extremo con operadores ONNX se está perfeccionando aún más, ya que se identifica como una intercepción a largo plazo. Ha habido algunos avances con los convertidores hasta ahora, con operaciones de mayor funcionamiento recibiendo soporte. El orador también toca diferentes áreas, como la necesidad de más voluntarios ya que este es un proyecto comunitario y una solicitud para que las empresas tengan más personas que se unan al esfuerzo. El orador enumera diferentes recursos, como el sitio web, GitHub, los canales de Slack y el calendario ONNX.
  
  
• 00:35:00 En esta sección, el orador analiza las actualizaciones y mejoras recientes de ONNX. Ha habido dos lanzamientos recientes con varias actualizaciones, como una mejor influencia del chip para los operadores y un manejo más estable de entradas incorrectas y opcionales. Además, el ponente destaca la incorporación de dos lanzamientos importantes: Model Composer y Function Builder. Model Converter también se ha vuelto más estable y el equipo planea brindar un mejor soporte para versiones mixtas en el futuro. En general, es imposible enumerar todas las mejoras realizadas por los colaboradores, pero continúan trabajando para mejorar ONNX.
  
  
• 00:40:00 Rama del operador SIG dio un resumen de los cambios y actualizaciones recientes a la especificación ONNX. El enfoque de Operator SIG es hacer evolucionar el conjunto de operadores que conforman la especificación ONNX, agregando nuevos operadores y aclarando sus especificaciones. En las últimas dos versiones, se introdujeron nuevos operadores, como la muestra de cuadrícula y la normalización de capas. Los operadores existentes, como scatter op, se actualizaron para admitir índices duplicados, mientras que algunos operadores se ampliaron para admitir tipos como b float 16 y tipos opcionales. Rama también mencionó planes para promover que algunos de los nuevos operadores se conviertan en funciones pronto.
  
  
• 00:45:00 En esta sección, el orador analiza los planes para el futuro de ONNX y el equilibrio entre tener una especificación compacta y admitir nuevos tipos de modelos que requieren más operaciones en la especificación. La solución a este desafío es la noción de funciones ONNX, que proporcionan una especificación ejecutable para una operación y permiten un equilibrio entre los requisitos en conflicto. El orador menciona planes para reducir el conjunto de operadores primitivos promoviéndolos en funciones y permitiendo la creación en Python usando un subconjunto llamado ONNX-Crypt. Se dan ejemplos de funciones, como la función de activación de Jello y la operación de abandono, para ilustrar cómo el uso del flujo de control facilita la especificación natural y compacta de su semántica.
  
  
• 00:50:00 En esta sección, Kevin Chen brinda una actualización sobre la firma del convertidor y el trabajo realizado desde la última reunión. Habla sobre las actualizaciones del convertidor front-end, incluidos los convertidores PyTorch, TensorFlow y sk-learn a ONNX. Para el convertidor PyTorch, la última versión admite exportaciones de ONNX hasta ONNX offset 16, y se han agregado nuevas características, como la capacidad de exportar módulos de redes neuronales específicamente como funciones locales de ONNX. Chen también repasa las actualizaciones del convertidor de back-end, como la centralidad de ONNX y el convertidor ONNX TensorFlow. Finalmente, Chen presenta la hoja de ruta para la firma del convertidor y alienta a las personas a involucrarse.
  
  
• 00:55:00 En esta sección, el orador analiza las actualizaciones y mejoras para el convertidor SK learn to ONNX, el convertidor de clave de detector ONNX y el convertidor ONNX TensorFlow. Se recomienda a los usuarios que actualicen a las últimas versiones para mejorar la experiencia del usuario al convertir modelos. La hoja de ruta para el convertidor de palo incluye objetivos como mejorar las herramientas impulsadas por la comunidad, estandarizar las funciones de servicios públicos y mejorar el soporte del operador y la compensación. Se alienta a los usuarios a unirse al canal de convertidores ONNX en Slack o suscribirse a la lista de correo ONNX Converter SIG para involucrarse con la comunidad y brindar comentarios.

• 01:00:00 Jackie de Microsoft presenta ONNX Model Zoo y ONNX Tutorials. ONNX Model Zoo es una colección de modelos de aprendizaje automático de última generación preentrenados, en su mayoría aportados por la comunidad de ONNX. Actualmente hay 168 modelos en el zoológico, incluidos 40 modelos ONNX y 35 modelos ONNX basados en visión para clasificación de imágenes y detección de objetos. Los tutoriales de ONNX proporcionan documentos y cuadernos que demuestran ONNX en la práctica para diferentes escenarios y plataformas. Model Zoo ha visto varias mejoras desde el último taller, incluidos nuevos modelos cuantificados de Intel y una mayor cobertura de prueba con pruebas de CI de rutina, reparación de conjuntos de datos de prueba rotos y colaboración con el equipo Hugging Face para crear una interfaz web para modelos de demostración.
  
  
• 01:05:00 Los oradores discuten la disponibilidad de tutoriales y demostraciones para usar ONNX, incluido un sitio web que permite procesar fácilmente imágenes y modelos ONNX escribiendo solo unas pocas líneas de código Python. También discuten la hoja de ruta futura para el ONNX Model Zoo, con planes para permitir que ORT ejecute más modelos e incorporar más contribuciones, incluidos modelos cuantificados y modelos de ejemplo de capacitación. Además, destacan el trabajo del Grupo de trabajo de preprocesamiento de ONNX, que se centra en facilitar el preprocesamiento de datos para su uso con los modelos ONNX.
  
  
• 01:10:00 En esta sección del video, el orador analiza la falta de estandarización en las canalizaciones de preprocesamiento de datos y destaca las diferencias entre bibliotecas populares como Pillow y OpenCV en el preprocesamiento de imágenes. Estas disparidades pueden generar problemas de precisión al implementar modelos en diferentes plataformas. El orador presenta el objetivo del grupo ONNX de estandarizar las operaciones de procesamiento previo de datos para evitar la ambigüedad y mejorar la implementación del modelo. El grupo ha estado trabajando para desarrollar una infraestructura que incluya el preprocesamiento de datos en los modelos, como el desarrollo de utilidades de composición y el operador de mapas de secuencia para el procesamiento por lotes. El grupo ONNX también está investigando formas de etiquetar la parte de preprocesamiento de un modelo para su identificación por parte de los back-ends. Además, el grupo propone extensiones para el operador de cambio de tamaño, incluido un filtro anti-aliasing opcional y una política de relación de aspecto.
  
  
• 01:15:00 Los oradores discuten la implementación de una operación de ruta o recorte central propuesta, que ofrece un mayor nivel de abstracción y se basa en los operadores de almohadilla y corte existentes. Animan a los espectadores a unirse a su canal de Slack y reuniones mensuales para compartir ideas. La siguiente presentación está a cargo de Joaquin Anton, quien resume el objetivo del grupo de trabajo de preprocesamiento de ONNX y comparte el trabajo reciente que han estado realizando. Marvin de Italia también se presenta a sí mismo y su trabajo como desarrollador y científico de datos en el campo del procesamiento del lenguaje natural.
  
  
• 01:20:00 El ponente comenta la importancia de consultar la documentación de ONNX antes de empezar a trabajar en un proyecto. Explican que no todos los modelos se pueden convertir u optimizar fácilmente para ONNX, y es importante asegurarse de que las funciones operativas requeridas para el proyecto se implementen en el marco que se utiliza. Además, el orador desaconseja la suposición de que las mejores opciones de rendimiento siempre optimizarán un modelo, ya que a veces estas opciones pueden reducir la precisión. En general, es importante considerar detenidamente la arquitectura del proyecto y consultar la documentación y las herramientas de ONNX, como el optimizador de ONNX, para evitar errores y garantizar una implementación exitosa en la nube o en los dispositivos.
  
  
• 01:25:00 En esta sección, Jiraj Perry de Nvidia analiza los conceptos básicos de la cuantificación de redes neuronales y cómo TensorRT admite redes cuantificadas a través de varias fusiones. Él explica que la cuantificación es el proceso de convertir valores continuos en un conjunto discreto de valores utilizando técnicas de escalado lineales o no lineales, que pueden ofrecer una inferencia más rápida y una huella de memoria más baja. Sin embargo, puede haber compensaciones con la precisión. Jiraj también menciona los diferentes esquemas de cuantificación y la importancia de los parámetros de cuantificación o q params. Luego presenta la cuantificación posterior al entrenamiento (PTQ) y el entrenamiento consciente de la cuantificación (QAT) y cómo pueden determinar q params.
  
  
• 01:30:00 En esta sección, el video analiza la cuantificación posterior al entrenamiento (PTQ) y el entrenamiento consciente de la cuantificación (QAT). PTQ implica ejecutar un modelo previamente entrenado en un conjunto de datos de calibración y recopilar estadísticas por capas para determinar el rango dinámico de cada capa para calcular los parámetros de cuantificación. QAT introduce nodos qdq en las capas deseadas y ajusta el gráfico para una pequeña cantidad de épocas para aprender el modelo o los parámetros de cuantificación. PTQ es generalmente más rápido y tiene menos control sobre la precisión final, mientras que QAT es más lento pero proporciona más control de precisión. El video también destaca las diferencias en los enfoques entre el kit de herramientas TF Mod de Google y el kit de herramientas de cuantificación TF2 de NVIDIA construido sobre TF Mod.
  
  
• 01:35:00 En esta sección, el orador discute las diferencias entre el kit de herramientas de cuantización de Nvidia y el mod tf en términos de dónde se colocan los nodos qdq. El kit de herramientas de Nvidia coloca los nodos qdq en las entradas y los pesos de una capa en la red, mientras que tf mod recomienda colocarlos en los pesos y las salidas de una capa. El orador también describe cómo TensorRT optimiza los modelos a través de fusiones de capas, como la convolución de fusión puntual y la fusión de agrupación, junto con fusiones dedicadas para nodos qdq. Además, el optimizador de gráficos de TensorRT realiza la propagación qdq para mover los nodos q y dq para garantizar que la porción máxima del gráfico se ejecute en la entrada. Los ejemplos de fusión presentados incluyen la cuantificación del grupo promedio y la fusión por adición de elementos. Finalmente, el ponente examina la fusión de cuantización en un bloque residual.
  
  
• 01:40:00 En esta sección, el orador explica la importancia de agregar nodos qdq en la rama de identidad para obtener el mejor rendimiento de Tensor RT al recargar operaciones. Las fusiones resultantes parecen nodos dq de los pesos y las entradas que se propagan más allá del anuncio y se fusionan con nodos q después de la capa de adición. El orador enfatiza la necesidad de nodos qdq en el gráfico original para obtener el mejor rendimiento para su modelo y advierte que no usarlos correctamente puede conducir a un rendimiento deficiente en el modelo. El ponente concluye invitando a un debate sobre cómo insertar nodos qdq en el kit de herramientas de TensorFlow.
  
  
• 01:45:00 En esta sección, el orador reconoce una dificultad técnica para navegar por las diapositivas y asegura a la audiencia que se solucionará en breve. Luego pasan a discutir un estudio de caso sobre la precisión después de obtener un modelo guardado de TensorFlow cuantificado y ajustado. Se invita a la audiencia a hacer cualquier pregunta antes de tomar un breve descanso.
  
  
• 01:50:00 En esta sección, el orador analiza el concepto de cuantificación y cómo se puede utilizar para representar la baja precisión en la cuantificación de redes neuronales. La cuantificación es una combinación de dos funciones: la función cuantificada que asigna valores de punto flotante a valores enteros y la función cuantificada que asigna valores enteros a una representación de punto flotante. La combinación de estas dos funciones se conoce como cuantificación falsa. Este proceso permite la asignación de representaciones a una representación de solo números enteros. El uso de cuantificación uniforme, particularmente con precisión reducida, permitió 1700 millones de muestras por segundo con menos de tres microsegundos de latencia en la plataforma de fútbol de radiofrecuencia.
  
  
• 01:55:00 En esta sección, el orador analiza las limitaciones de ONNX para representar la cuantificación de baja precisión, especialmente por debajo de los ocho bits, y sugiere una estrategia para extender el poder de representación de ONNX aprovechando el recorte para inducir precisión entre los nodos cuantificados y descuantificados. . Esta estrategia agrega una función de recorte adicional que se admite en los límites de enteros y no afecta la retrocompatibilidad con las bibliotecas y herramientas existentes. Sin embargo, esta estrategia se extiende solo hasta donde el lineal cuantificado permite ir como operador, y tiene algunas limitaciones con respecto a los diferentes tipos de redondeo. El orador también menciona sus esfuerzos con la cuantificación en dialecto de exponenciación (tuonex), que representa una cuantificación falsa en un solo nodo mientras se extiende a un conjunto más amplio de escenarios con transmisiones de entrada, opciones de cuantificación binaria y más. Este formato se aprovecha como parte de sus esfuerzos de implementación en fpgas, y sus herramientas, como q ONNX y nqcdq, se integran con las bibliotecas de cuantificación existentes y han ganado adopción en la comunidad fpga.
  
  

• 02:00:00 En esta sección, Daniel de Mithril explica cómo han desarrollado una solución llamada "IA ciega" que permite la implementación de modelos ONNX dentro de enclaves seguros que aprovechan el hardware para proteger los datos. Mediante el uso de tecnologías basadas en hardware, esta solución proporciona aislamiento y cifrado del contenido de la memoria del enclave, lo que evita cualquier intento de volcado desde el exterior. Los datos se descifran dentro del enclave, y cualquier interno malicioso no puede acceder a los datos, lo que es una gran ventaja para el propietario de los datos cuando se trata de privacidad y seguridad. Blind AI es una solución de código abierto que es fácil de incorporar y es fácil para el proveedor de IA mantener y vender esta solución.
  
  
• 02:05:00 En esta sección, el orador analiza la capacidad de implementar modelos de IA con garantías de progreso, utilizando el SDK de Python para cargar de forma segura los modelos y enviar datos para su análisis sin dar acceso a terceros a los datos. También se destaca la expresividad de ONNX, que le permite cubrir varios casos de uso, incluida la inspección de equipaje, el análisis de documentos médicos y el reconocimiento facial. El altavoz también presenta diferentes modelos utilizados en la práctica y su velocidad dentro y fuera del enclave, con una latencia añadida razonable por la protección que proporciona. Además, ONNX requiere una base de código mínima, lo que lo hace mejor por razones de seguridad y puede reforzar a cada operador, lo que garantiza un uso seguro del enclave. La presentación concluye con información sobre su GitHub y cómo pueden cubrir varios escenarios, y la oportunidad de profundizar en los detalles técnicos de seguridad.
  
  
• 02:10:00 En esta sección, el orador analiza la propuesta para habilitar metadatos de IA legibles por máquina en ONNX, lo que implica rastrear la procedencia y otras características relevantes de un modelo para identificar cómo se mueve con el tiempo y evoluciona dado un caso de uso específico. La propuesta se presentó inicialmente al comité directivo de ONNX en octubre de 2020, y ahora el equipo quiere extenderla aún más para incluir la creación, consulta y visualización de metadatos como parte de un diseño integral para centros de modelos y zoológicos. El orador enfatiza la importancia de los metadatos como un habilitador clave de la IA responsable y explicable y destaca su utilidad para reducir los modos de falla e identificar los puntos débiles para los sistemas de IA.
  
  
• 02:15:00 En esta sección de la presentación del Día de la comunidad de ONNX, los oradores analizan la importancia de los metadatos en los modelos y el potencial del uso de RDF para un enfoque estandarizado y más legible por máquina para representar los metadatos. Explican cómo este enfoque puede ayudar a establecer relaciones entre entidades, mantener la transparencia y rastrear la procedencia, respondiendo preguntas sobre qué causó que un modelo tuviera una precisión más baja de lo esperado. Los oradores también discuten el poder de consultar metadatos usando SPARQL y explican cómo los modelos con metadatos en formato RDF pueden proporcionar información más allá de lo que puede ofrecer una tarjeta de modelo simple.
  
  
• 02:20:00 En esta sección, el orador analiza el vocabulario de control de Furnace, un conjunto de principios rectores para hacer que los datos y los activos digitales sean accesibles, interoperables y reutilizables. Los principios de Furnace fueron identificados por la comunidad de la web semántica e incluyen equidad, confiabilidad y sostenibilidad. Los metadatos codificados en RDF se pueden consultar utilizando la ontología Furnace para descubrir modelos adecuados para tareas de NLP, identificar a los creadores y el tamaño de los modelos, y rastrear la huella de carbono de los modelos para clasificarlos y clasificarlos. La extensibilidad de RDF y su lenguaje de consulta, Sparkle, permiten una extensibilidad infinita más allá del vocabulario seleccionado por las autoridades del examen. Esto puede permitir el seguimiento de la IA responsable y la corriente de precisión mixta.
  
  
• 02:25:00 En esta sección, los presentadores analizan las capacidades de consulta y filtrado del Día de la comunidad ONNX. Muestran cómo el autor de los metadatos puede identificar modelos entrenados con conjuntos de datos que contienen información privada o personal mediante el uso de etiquetas de metadatos. Los presentadores también demuestran cómo las capacidades de filtrado extendidas permiten a los usuarios consultar modelos con precisión mixta. Destacan la visualización de perfiles de modelos y técnicas de inteligencia artificial explicables para mostrar metadatos de manera eficiente. Los presentadores hacen un llamado a la acción para considerar un diseño concreto en torno a la creación y el consumo de modelos que cubra toda la creación, consulta y filtrado de metadatos desde el flujo de trabajo de los centros con soporte para metadatos legibles por máquina en ONNX. Actualmente están preparando una implementación testimonial y explorando tecnologías para la creación de metadatos.
  
  
• 02:30:00 En esta sección, Adam Pocock de Oracle Labs analiza la importancia de admitir Java Virtual Machine (JVM) con ONNX. Si bien la mayoría de las aplicaciones de ML están escritas en lenguajes distintos de Python, como Java, es crucial llevar el aprendizaje automático a estos lenguajes. La API de Java en tiempo de ejecución de ONNX fue desarrollada por Oracle Labs para incorporar el aprendizaje automático en Java y otros lenguajes, con características como un impacto mínimo en el rendimiento y facilidad de implementación. Adam también proporciona un ejemplo de código para demostrar las similitudes entre la API de Java y otras API.
  
  
• 02:35:00 En esta sección, el orador analiza cómo alimentar datos y ejecutar un modelo usando el tensor ONNX, una representación de búfer de bytes para un flujo de bytes. Aunque es posible usar matrices regulares en Java, el orador recomienda usar búferes de bytes debido a su ruta de copia cero, lo que permite una mayor eficiencia en el manejo de datos. El orador también señala que las matrices multidimensionales de Java no son óptimas para el aprendizaje automático porque no son planas e implican una gran cantidad de seguimiento de punteros. El orador analiza además los planes para actualizar a una versión más nueva de Java, agregar nuevas funciones y desarrollar para que coincida con el árbol de tiempo de ejecución de ONNX. Además, el orador presenta una biblioteca de código abierto que escribe modelos ONNX desde Java, que está disponible en cualquier lugar de la JVM.
  
  
• 02:40:00 En esta sección, los oradores analizan la compatibilidad del conjunto de herramientas ONNX con las nuevas bibliotecas de aprendizaje automático, como DeepJ, y cómo se integra con el tiempo de ejecución de ONNX para brindar un rendimiento de primer nivel. DeepJ crea una capa de abstracción sobre varias bibliotecas de aprendizaje profundo, abstrayendo todas las bibliotecas necesarias y proporcionando varios backends de operador para que los utilicen los motores de aprendizaje automático, como Apache MixTape, Tensorflow, PyTorch, ONNX, Pedal y más. También están explorando formas de estandarizar los metadatos en este conjunto de herramientas para emitir formatos de metadatos estándar mientras continúan expandiendo la enumeración de operadores.
  
  
• 02:45:00 En esta sección, el orador analiza los beneficios de Deep Java Library, que incluye un conjunto de modelos preentrenados que cubren tareas como clasificación de imágenes, detección de objetos, análisis de sentimientos y reconocimiento de acciones. La biblioteca está lista para el servicio y ha pasado por pruebas rigurosas para funcionar con la mejor velocidad y control de memoria posibles, como lo demuestra su uso exitoso con DHL durante más de medio año sin ningún error. Además, el orador comparte varios casos de uso en los que se usaron ONNX y el tiempo de ejecución de ONNX para lograr mejoras significativas en el rendimiento y reducir la latencia. Una historia de éxito presenta a un banco chino que pudo reducir el tiempo de ejecución de sus modelos OCR de un segundo a menos de 400 milisegundos en una sola imagen. Además, el orador presenta el concepto Hybrid Engine, que permite cargar dos motores al mismo tiempo y proporciona una transición suave entre ellos.
  
  
• 02:50:00 En esta sección, el orador explica un método que utiliza el búfer directo para enviar punteros desde Python directamente al tiempo de ejecución de ONNX, lo que evita la copia de datos y proporciona un aumento del rendimiento. También presentan ND Manager, una arquitectura en forma de árbol implementada en la biblioteca DeepDraw para proporcionar colecciones de memoria más rentables. El orador analiza cómo los clientes pueden hacer la transición del uso de PyTorch al tiempo de ejecución de ONNX sin cambiar una sola línea de código. Más tarde, el orador de Hype Factors habla sobre su empresa de inteligencia de medios y cómo eligieron basar su infraestructura en la JVM por su experiencia de desarrollador, ecosistema de componentes reutilizables y alta escalabilidad.
  
  
• 02:55:00 En esta sección, el orador analiza los aspectos técnicos de su sitio web de análisis de medios, incluido el uso de JVM para potenciar la mayor parte de la funcionalidad del sitio web y la migración a un sistema que principalmente enriquece todos los datos que ingresan. Con unos pocos miles de millones de inferencias de GPU por día, las funciones del producto dependen en gran medida del aprendizaje automático y la gestión de modelos, que se ha convertido en una parte esencial para mantener todo en funcionamiento, lo que lleva a la criticidad del proceso. Los datos abarcan todo tipo de formatos, incluidos HTML y PDF, y rastrean su tiempo de ejecución para enriquecer los datos sobre la marcha, incluido el reconocimiento de entidades nombradas, la prominencia, el sentimiento y más. Ha habido muchos desafíos a lo largo del camino, incluidos errores de conversión y una pérdida de memoria rara en DTL, que tomó un tiempo para resolver.