Apprendre ONNX pour le trading - page 3

[MetaQuotes]

Netron est un outil permettant de visualiser les modèles de réseaux de neurones, d'apprentissage en profondeur et d'apprentissage automatique

[MetaQuotes]

Aperçu rapide de Netron

Aperçu rapide de Netron

Dans la vidéo, le présentateur donne un aperçu de Netron, un outil de visualisation et d'analyse de modèles d'apprentissage automatique . Netron prend en charge divers formats et peut être installé sur plusieurs plates-formes. Le présentateur montre comment démarrer Netron et naviguer à travers plusieurs exemples de modèles, en soulignant les capacités et les limites de l'outil. Bien que Netron soit utile pour explorer des architectures de réseau plus simples, le présentateur suggère qu'il pourrait bénéficier de fonctionnalités supplémentaires pour visualiser des modèles plus complexes. Dans l'ensemble, le présentateur recommande Netron comme un outil utile pour examiner et comprendre les modèles d'apprentissage automatique.

[MetaQuotes]

PyTorch, TensorFlow, Keras, ONNX, TensorRT, OpenVINO, Conversion de fichier de modèle AI

[Vidéo éducative] PyTorch, TensorFlow, Keras, ONNX, TensorRT, OpenVINO, conversion de fichier de modèle AI

L'orateur de la vidéo discute des avantages et des compromis de différents frameworks d'IA, tels que PyTorch, TensorFlow, Keras, ONNX, TensorRT et OpenVINO, et recommande PyTorch comme framework préféré pour la formation et la conversion de données. L'orateur explique le processus de conversion, y compris la conversion des modèles PyTorch en ONNX, puis en TensorRT ou OpenVINO, et met en garde contre l'utilisation du fichier TensorFlow PB et de Cafe. L'orateur discute également de l'importance de définir correctement le format à virgule flottante et recommande d'utiliser le FP 32 pour la plupart des modèles. La vidéo fournit des exemples de conversion de modèles et encourage les téléspectateurs à visiter le site Web officiel pour plus de vidéos éducatives.

• 00:00:00 Dans cette section, l'orateur discute des différents frameworks d'IA, y compris PyTorch, TensorFlow, Keras et Cafe, et explique la méthode préférée de leur entreprise pour utiliser PyTorch pour enregistrer le modèle en tant que fichier ONNX, qu'ils revérifient avec leur ensemble de données à l'aide d'ONNX Runtime. Si le test est réussi, ils convertissent le modèle ONNX aux formats TensorRT et OpenVINO. L'orateur met en garde contre l'utilisation du fichier TensorFlow PB et de Cafe et recommande d'utiliser plutôt Python avec les données d'origine et PyTorch pour la formation. Enfin, l'orateur mentionne que parfois les moteurs d'inférence ont besoin que la virgule flottante soit correctement définie.
  
  
• 00:05:00 Dans cette section, l'orateur explique comment le choix du format à virgule flottante affecte la vitesse et la précision de la conversion du modèle. Il explique que si l'utilisation du FP 16 peut augmenter la vitesse, cela peut conduire à moins de précision, tandis que l'utilisation du FP 64 entraîne une vitesse plus lente mais une plus grande précision. L'orateur recommande d'utiliser FP 32 pour la plupart des modèles et explique comment différents formats peuvent être utilisés pour des types spécifiques d'ensembles de données, comme FP 32 et FP 64 pour l'analyse d'images médicales. Il explique également que la conversion d'un modèle de FP 32 à FP 16 peut entraîner une perte de précision, qui peut être atténuée en utilisant l'étalonnage, la suppression ou le recyclage avec FP 16 pour améliorer la précision du modèle.
  
  
• 00:10:00 Dans cette section de la vidéo, le conférencier discute des compromis entre la vitesse, la précision et les informations de données lors de l'utilisation de différents frameworks d'IA tels que PyTorch, TensorFlow, Keras, ONNX, TensorRT et OpenVINO. L'orateur recommande d'utiliser PyTorch et de convertir les modèles de PyTorch vers ONNX à l'aide d'une solution fournie. Ensuite, ils expliquent comment convertir les modèles d'ONNX en TensorRT en utilisant une autre solution fournie. L'orateur démontre le processus de conversion en exécutant le code dans Jupiter Lab et montre comment localiser les fichiers de modèle convertis.
  
  
• 00:15:00 Dans cette section de la vidéo, l'orateur discute de la facilité de conversion des modèles d'IA de PyTorch vers ONNX puis vers TensorRT ou OpenVINO, soulignant qu'il s'agit d'un processus simple. Cependant, pour ceux qui utilisent TensorFlow ou Keras, l'orateur recommande d'utiliser PyTorch pour recycler l'ensemble de données car il sera plus facile de faire des conversions de modèles. L'orateur avertit qu'il peut y avoir des problèmes lors de l'utilisation de Keras car les données du fichier de modèle ne contiennent que des paramètres et qu'il est nécessaire de créer d'abord l'architecture du réseau avant d'importer le fichier de paramètres H5. L'orateur suggère que la solution ultime à de tels problèmes est Café, mais avec les développeurs de Café migrés vers Café 2 et personne pour le maintenir, l'orateur recommande d'utiliser PyTorch comme cadre d'IA principal.
  
  
• 00:20:00 Dans cette section, le conférencier discute des avantages de l'utilisation de PyTorch et de la facilité de migration due à sa vitesse rapide et à son architecture améliorée. Le conférencier donne également un exemple d'utilisation d'une solution pour convertir un modèle de poids v3 en un modèle OpenVINO AIA et la solution la plus puissante pour la détection d'objets, Euro v4. Pour utiliser l'exemple, deux fichiers sont requis pour la conversion, un fichier de pondérations Euro v4 CPP et un fichier de configuration de réseau Euro v4 CFG. Après la conversion, un fichier Haitatsu PTH est généré pour être utilisé dans l'image d'inférence afin de vérifier les résultats. L'orateur recommande d'utiliser Python pour effectuer la formation à l'IA, puis de convertir en ONNX, puis en TensorRT ou OpenVINO. Enfin, l'orateur encourage les téléspectateurs à visiter le site officiel pour plus de vidéos éducatives et à devenir membre gratuit pour recevoir la liste des vidéos chaque semaine.

[MetaQuotes]

Nouveautés de l'environnement d'exécution ONNX

Nouveautés de l'environnement d'exécution ONNX

Cette conférence partagera les points forts des versions ONNX Runtime 1.10-1.12, y compris des détails sur les améliorations notables des performances, les fonctionnalités et les plates-formes, y compris les mobiles et le Web. Ryan Hill fait partie de l'équipe AI Frameworks depuis 4 ans, où il a principalement travaillé sur les noyaux d'opérateurs, les API C et les fournisseurs d'exécution à chargement dynamique. Avant cela, il a travaillé dans l'équipe Office PowerPoint, où son travail le plus largement vu est la plupart des transitions de diapositives de diaporama. Pour le plaisir, il aime essayer d'utiliser les dernières fonctionnalités C++ et rencontrer des erreurs internes du compilateur.

Dans la vidéo, l'ingénieur logiciel Ryan Hill discute des différentes fonctionnalités et mises à jour d'ONNX Runtime, un runtime multiplateforme largement utilisé qui peut cibler plusieurs architectures de processeur. Il met en évidence les dernières fonctionnalités ajoutées à ONNX Runtime, telles que la possibilité d'appeler directement les noyaux opérationnels et les améliorations de performances telles que l'optimiseur de transposition et l'optimisation de petite taille. Hill parle également des fournisseurs d'exécution d'ONNX Runtime, qui permettent des performances optimales sur divers matériels, et de la sortie de packages mobiles prenant en charge la conversion NHWC au moment de l'exécution. La vidéo couvre également la prise en charge des opérateurs sensibles à la mise en page, la prise en charge de Xamarin pour les applications multiplateformes, le Web ONNX Runtime et la bibliothèque d'extensions ONNX Runtime qui se concentre sur le travail de pré-post-traitement du modèle, y compris les conversions de texte et les opérations mathématiques, et se concentre actuellement sur Domaines de la PNL, de la vision et du texte.

• 00:00:00 Dans cette section, Ryan Hill, un ingénieur logiciel travaillant sur ONNX Runtime depuis environ quatre ans, discute des fonctionnalités d'ONNX Runtime et de ses nouvelles versions. Il souligne qu'ONNX Runtime est un environnement d'exécution multiplateforme qui peut cibler plusieurs architectures de CPU et possède des liaisons de langage pour plusieurs langages de programmation. Il est largement utilisé par plusieurs industries, dont Microsoft, avec plus de 160 modèles en production. Ryan discute également des nouvelles fonctionnalités ajoutées dans les dernières versions, telles que la possibilité d'appeler des noyaux op directement depuis l'extérieur d'un appel d'exécution de modèle et la possibilité d'alimenter des initialiseurs externes sous forme de tableaux d'octets pour l'inférence de modèle. De plus, Ryan parle des améliorations de performances de la dernière version, telles qu'un optimiseur de transposition et une fonction d'optimisation de petite taille. Enfin, il met en évidence les fournisseurs d'exécution d'ONNX Runtime qui lui permettent de fonctionner de manière optimale sur divers matériels et la version de ses packages mobiles, qui prend désormais en charge la conversion NHWC au moment de l'exécution.
  
  
• 00:05:00 Dans cette section, la vidéo couvre les nouvelles fonctionnalités et mises à jour du runtime ONNX, y compris la prise en charge des opérateurs sensibles à la mise en page et la prise en charge de Xamarin pour les applications multiplateformes sur Android et iOS. De plus, le Web ONNX Runtime offre une base de code C++ unique, compilée en assemblage Web, qui est plus rapide et utilise moins de mémoire, et il existe désormais une bibliothèque d'extensions ONNX Runtime qui se concentre sur le travail de pré-post-traitement du modèle, permettant aux utilisateurs de faire ce travail entièrement à l'intérieur de l'appel d'exécution du modèle. La bibliothèque comprend des conversions de texte, des opérations mathématiques et se concentre actuellement sur les domaines de la PNL, de la vision et du texte. L'équipe Microsoft Office utilise actuellement cette bibliothèque d'extensions.

[MetaQuotes]

Comment nous utilisons ONNX dans Zetane pour réaliser des projets d'apprentissage automatique plus rapidement avec moins d'essais et d'erreurs

Comment nous utilisons ONNX dans Zetane pour réaliser des projets d'apprentissage automatique plus rapidement avec moins d'essais et d'erreurs

Patrick Saitama, co-fondateur et CTO de Zetane Systems, discute de la valeur de l'utilisation d'ONNX dans le nouveau produit de son entreprise pour résoudre les problèmes liés au problème de la boîte noire de l'IA. Le moteur de Zetane permet l'exploration et l'inspection des modèles ONNX, fournissant des informations sur l'interaction du modèle avec les données et conduisant à des stratégies plus décisives pour améliorer sa qualité. L'exemple donné montre comment le moteur de Zetane a aidé à déboguer un modèle de train autonome en inspectant la couche radio et en ajoutant plus d'images de tunnels étiquetés comme non-obstacles. Zetane comprend également des outils pour inspecter dynamiquement les tenseurs internes et prendre des instantanés du modèle pour une enquête ultérieure. De plus, le nouveau moteur de Zetane permet d'installer des modèles plus grands tels que YOLOv3.

• 00:00:00 Patrick Saitama, co-fondateur et CTO de Zetane Systems, explique comment extraire une plus grande valeur d'ONNX pour raccourcir la durée de votre cycle de développement et réduire les conjectures. Son entreprise, Zetane Systems, basée à Montréal, a récemment lancé un nouveau produit, qui est indépendant de l'industrie, et vise à résoudre certains des problèmes liés au problème de la boîte noire de l'IA. En transmettant les données d'entrée aux modèles ONNX, puis en projetant les modèles dans le moteur Zetane, les modèles peuvent être explorés et inspectés, y compris son architecture et son graphe de calcul, ainsi que tous les tenseurs contenus dans chaque nœud opérateur, afin de déboguer et optimiser le modèle.
  
  
• 00:05:00 L'orateur explique comment l'utilisation d'ONNX dans Zetane permet d'approfondir les connaissances sur le modèle et son interaction avec les données, ce qui conduit à son tour à des stratégies plus décisives pour améliorer la qualité du modèle. L'exemple donné est celui d'un modèle de train autonome et comment l'examen de la couche radio dans le moteur soutenu a montré que le modèle détectait le tunnel comme un obstacle, ce qui a conduit à l'ajout de plus d'images de tunnels étiquetés comme non-obstacles. Zetane comprend également des outils pour inspecter dynamiquement les tenseurs internes et prendre des instantanés du modèle à certains moments pour les étudier et les améliorer ultérieurement. De plus, le moteur de retenue a récemment été lancé, permettant l'installation de modèles plus grands tels que YOLOv3.

[MetaQuotes]

v1.12.0 ONNX Runtime - Examen de la version

v1.12.0 ONNX Runtime - Examen de la version

La version v1.12.0 d'ONNX Runtime (ORT) se concentre sur l'inférence, mais inclut également des investissements continus dans la formation, l'intégration avec Hugging Face Optimum entraînant l'accélération de plusieurs modèles de Hugging Face. Les nouvelles fonctionnalités incluent la possibilité d'utiliser des opérations ORT natives dans des opérations personnalisées et d'appeler directement un opérateur natif ou d'exécution sans créer de graphique. La version inclut également la prise en charge de .NET 6 et de l'interface utilisateur d'application multiplateforme (MAUI) et des fournisseurs d'exécution pour des plates-formes spécifiques telles que Neural Processing Unit sur Android et Core ML sur iOS. Des améliorations de performances ont été apportées en réduisant les allocations de mémoire pendant l'inférence et en éliminant la journalisation inutile. Des améliorations futures pour améliorer la localité du cache et l'utilisation du pool de threads sont prévues.

• 00:00:00 Dans cette section, les nouvelles fonctionnalités et mises à jour de la version 1.12 d'ONNX Runtime sont abordées. Celles-ci incluent la dépréciation de la prise en charge de la norme .net 1.1 et l'ajout de la prise en charge de l'offset ONNX 17 et de l'offset xml 3. Une nouvelle fonctionnalité est la possibilité d'invoquer des opérations individuelles sans créer de graphique séparé et la prise en charge de l'alimentation des initialiseurs externes pour l'inférence a également été ajouté. D'autres mises à jour incluent la prise en charge de python 310 et l'activation de la prise en charge de mac m1 dans les bibliothèques python et java, ainsi que l'ajout de la prise en charge de .net 6 maui dans le package c-sharp. des améliorations des performances et de la quantification ont également été apportées, et de nouveaux fournisseurs d'exécution ont été introduits, notamment Qualcomm Snappy et l'infrastructure générale pour l'ep accident pack, avec des travaux en cours pour ajouter plus de noyaux pour les scénarios mobiles et Web.
  
  
• 00:05:00 Dans cette section, l'orateur discute des mises à jour apportées à ONNX Runtime (ORT) et mentionne que l'accent a été principalement mis sur l'inférence. Cependant, il y a eu des investissements continus dans la formation ORT pour accélérer la formation de grands modèles. L'intégration récente avec Hugging Face Optimum a entraîné l'accélération de plusieurs modèles de Hugging Face. L'orateur présente ensuite Randy, qui discute d'une nouvelle fonctionnalité qui permet aux utilisateurs d'utiliser des opérations ONNX Runtime natives dans des opérations personnalisées. Randy explique que cette fonctionnalité est née des demandes des clients visant à rendre les opérateurs personnalisés plus performants et polyvalents en utilisant les puissantes capacités de calcul matriciel du runtime ONNX.
  
  
• 00:10:00 Dans cette section, l'orateur discute d'une nouvelle fonctionnalité qui permet aux clients d'appeler directement un opérateur natif ou d'exécution sans créer de graphique ou quelque chose de similaire, ce qui facilite grandement l'exécution des fonctions de calcul matriciel. Cette fonctionnalité a été proposée à la communauté car un autre groupe de clients travaillait sur le traitement audio et souhaitait réaliser une gestion des déclarations, ce qui signifie qu'ils souhaitaient mettre en cache certaines entrées ou sorties passées, les combiner avec la dernière entrée et alimenter l'opérateur avec une combinaison modifiée. saisir. Cela était auparavant difficile à réaliser, mais avec la nouvelle fonctionnalité, les clients peuvent ajouter un wrapper autour de l'opérateur natif de l'ONNX Runtime pour effectuer la gestion des relevés, ce qui leur facilite la vie et atteint leur objectif. Des exemples d'utilisation de cette fonctionnalité sont disponibles sur le site Web de la communauté.
  
  
• 00:15:00 Dans cette section, Scott McKay, responsable d'ONNX Runtime Mobile, discute des nouvelles fonctionnalités ajoutées dans la v1.12.0 d'ONNX Runtime. La version inclut la prise en charge de .NET 6 et de l'interface utilisateur d'application multiplateforme (MAUI), permettant aux développeurs de créer une application à l'aide d'une base de code partagée pouvant s'exécuter sur Android, iOS, macOS, Windows et Linux. ONNX Runtime comprend également des fournisseurs d'exécution pour des plates-formes spécifiques telles que Neural Processing Unit sur Android et Core ML sur iOS, qui peuvent optimiser la vitesse d'exécution du modèle et l'efficacité énergétique. McKay explique que les développeurs peuvent utiliser les mêmes liaisons C # pour interagir avec la bibliothèque ONNX Runtime dans tous ces frameworks, mais il peut y avoir un code spécifique à la plate-forme requis pour gérer les différences dans les tailles d'écran des appareils et le traitement des images. Pour ajouter ONNX Runtime dans un projet .NET 6, les développeurs peuvent utiliser le package microsoft.ml.onnxruntime et le package microsoft.ml.onnxruntime.managed, qui fournissent l'implémentation C++ pour exécuter le modèle et les liaisons C# pour interagir avec le natif bibliothèque.
  
  
• 00:20:00 Dans cette section, l'orateur discute de la disponibilité d'exemples pour que les utilisateurs apprennent à utiliser les nouvelles bibliothèques. Il existe un référentiel Github qui contient un exemple d'application Xamarin pour démontrer les fonctionnalités de la nouvelle version. De plus, l'équipe mettra à jour l'application pour inclure une application Maui dont la conception sera similaire. Enfin, le public exprime son intérêt pour un didacticiel approfondi, car le nouveau support Maui sera très utile et les exemples seraient excellents. L'orateur suivant explique le concept derrière l'extensibilité de l'équipe ONNX Runtime et fournit des mises à jour sur les fournisseurs d'exécution. La mise à jour de cette section se concentre sur l'intégration avec le matériel via l'interface du fournisseur d'exécution. Dans cette version, l'équipe s'est concentrée sur l'inférence des charges de travail et la collaboration avec des fournisseurs tels que Nvidia, Intel et Qualcomm a permis de nombreuses améliorations. Une amélioration est une option permettant de partager la mémoire de contexte d'exécution qui réduit la surcharge liée à l'accès à plusieurs sous-graphes avec TensorRT. Une autre optimisation concerne la prise en charge de la mise en cache du moteur, où la création de moteurs à l'avance réduit le temps de reconstruction des moteurs au moment de l'inférence.
  
  
• 00:25:00 Dans cette section, la révision de la version 1.12.0 ONNX Runtime est discutée, en particulier le fournisseur d'exécution appelé Snappy, qui signifie Snapdragon Neural Processing Engine de Qualcomm. Il s'agit du runtime de Qualcomm qui est utilisé pour accélérer les charges de travail d'IA sur les SOC mobiles Snapdragon. La prise en charge de Snappy est toute nouvelle et a été annoncée lors de la conférence Microsoft Build du mois dernier. Parallèlement à la prise en charge de Snappy, Intel a également commencé à créer des packages Python hébergés sur PyPI avec ONNX Runtime avec OpenVINO activé. Cela facilite la configuration pour les développeurs et permet une meilleure prise en charge des modèles avec des formes d'entrée dynamiques. Des liens vers la documentation et des exemples sont également fournis dans les notes de version.
  
  
• 00:30:00 Dans cette section, Dmitry Smith, ingénieur logiciel principal chez Microsoft, discute des améliorations de performances apportées à la version 1.12.0 de ONNX Runtime. Les clients avaient approché Microsoft pour demander une latence et une utilisation du processeur inférieures pour l'inférence, ce qui a entraîné les améliorations. L'équipe s'est concentrée sur la réduction des allocations de mémoire pendant l'inférence et l'élimination de la journalisation inutile, avec des modifications apportées à la façon dont le code était écrit. Les améliorations ont entraîné une réduction de la latence dans certains scénarios par un facteur de deux ou plus, et d'autres améliorations telles que l'amélioration de la localité du cache et l'utilisation du pool de threads sont prévues pour les futures versions.

[MetaQuotes]

v1.13 ONNX Runtime - Examen de la version

v1.13 ONNX Runtime - Examen de la version

La version 1.13 du runtime ONNX a été récemment publiée avec des correctifs de sécurité, des corrections de bogues et des améliorations de performances. La mise à jour se concentre sur l'optimisation des modèles Transformer pour la quantification GPU et ajoute la prise en charge des fournisseurs d'exécution directe ML qui sont indépendants des appareils et prennent en charge plus de 150 opérateurs. De plus, la version inclut des mises à jour de l'infrastructure mobile ORT pour la compatibilité avec les nouveaux EPS, tels que le pack XNN. L'utilisation de la quantification pour améliorer les performances des modèles basés sur Transformer est également abordée, avec l'optimisation du fournisseur d'exécution CUDA pour exécuter le modèle BERT quantifié et l'utilisation d'une formation consciente quantifiée pour maximiser la précision tout en optimisant le moteur d'exécution ONNX.

• 00:00:00 Dans cette section, l'orateur discute de la version 1.13 récemment publiée du runtime ONNX, qui comprend des correctifs de sécurité, des corrections de bogues et des améliorations des performances. La mise à jour s'est concentrée sur l'optimisation des modèles Transformer pour la quantification GPU et a ajouté la prise en charge des fournisseurs d'exécution directe de ML. Ce dernier est une API d'apprentissage automatique qui prend en charge plus de 150 opérateurs différents et est indépendant de l'appareil. L'orateur mentionne également le nouveau fournisseur d'exécution can EP, auquel Huawei a contribué pour prendre en charge son matériel Ascend 310. De plus, des mises à jour ont été apportées à l'infrastructure mobile ORT, ce qui a permis la compatibilité avec les nouveaux EPS tels que le pack XNN.
  
  
• 00:05:00 Dans cette section, les conférenciers discutent de la version 1.13 du runtime ONNX et de son fonctionnement avec n'importe quel GPU prenant en charge jusqu'à DirectX 12, ce qui facilite l'optimisation pour les machines Windows. Ils discutent également des nouveaux opérateurs et des mises à jour des décalages ONNX dans la version 1.12. Les conférenciers soulignent comment la nouvelle version a étendu la prise en charge de différentes architectures de modèles pour faciliter l'exploitation du fournisseur d'exécution dans le runtime ONNX. Ils discutent également du nouveau fournisseur d'exécution, Excellent Impact, et de la manière dont il comble les lacunes de performances sur les appareils mobiles où les noyaux manuscrits ne sont pas disponibles. La fonctionnalité est actuellement activée pour Android, mais l'équipe cherche à ajouter la prise en charge des versions iOS et Xamarin ou Maui dans la version suivante. Enfin, ils discutent de la nouvelle fonctionnalité de la version appelée optimisations pour la quantification du modèle BERT.
  
  
• 00:10:00 Dans cette section, l'orateur discute de l'utilisation de la quantification pour améliorer les performances des modèles basés sur Transformer tels que BERT. Ils expliquent comment ils ont optimisé le fournisseur d'exécution CUDA pour exécuter le modèle BERT quantifié et l'utilisation d'une formation consciente quantifiée pour maximiser la précision tout en optimisant le moteur d'exécution ONNX. L'orateur fournit des exemples de la façon de faire une formation consciente quantifiée du modèle BERT et d'exporter le modèle avec les outils disponibles dans l'environnement d'exécution ONNX pour une optimisation supplémentaire. En prenant mieux en charge la formation consciente quantifiée, l'environnement d'exécution ONNX peut offrir une optimisation supplémentaire des performances tout en maintenant une précision maximale. Ils mentionnent qu'après que l'utilisateur a suivi les exemples pour exporter le modèle, les outils hors ligne disponibles dans la nouvelle version du runtime ONNX peuvent optimiser le modèle pour une meilleure vitesse.

[MetaQuotes]

Discussion sur la feuille de route ONNX 2020 #1 20200903

Discussion sur la feuille de route ONNX 2020 #1 20200903

Le document de feuille de route ONNX, qui a été ouvert aux contributions du public, est un sujet clé de cette vidéo. La discussion couvre l'extension d'ONNX sur un pipeline d'apprentissage automatique, y compris l'évolution des données, le prétraitement et l'extension d'ONNX sur des pipelines horizontaux comme QFLO. Les suggestions faites par les contributeurs incluent la prise en charge des trames de données et l'adoption de nouveaux opérateurs pour le prétraitement. Les intervenants discutent également de l'adoption de la norme API de données Python pour étendre la prise en charge d'ONNX et garantir l'interopérabilité avec d'autres bibliothèques. De plus, les conférenciers discutent de l'intégration d'ONNX dans Kubernetes et Kubeflow pour rationaliser le développement ML pour les utilisateurs. Le groupe prévoit de continuer à évaluer l'impact de la proposition et accueille les commentaires via la feuille de route ou le comité de pilotage.

• 00:00:00 Dans cette section, l'orateur discute du document de feuille de route ONNX qui a été ouvert aux contributions du public et souligne l'importance de ces contributions pour la mise en œuvre des changements. L'orateur mentionne qu'il y aura six discussions sur la feuille de route, organisées chaque semaine, avec une réunion communautaire prévue pour le 14 octobre. La discussion est divisée en trois parties principales, la deuxième partie se concentrant sur l'extension d'ONNX sur un pipeline d'apprentissage automatique. Plus précisément, la discussion couvre l'évolution des données et leur prétraitement, ainsi que l'extension d'ONNX sur des pipelines horizontaux comme QFLO. L'orateur résume également certaines des suggestions faites par les contributeurs, telles que la prise en charge des trames de données et l'adoption de nouveaux opérateurs pour le prétraitement.
  
  
• 00:05:00 Dans cette section, la discussion se concentre sur la feuille de route ONNX et diverses suggestions, telles que la prise en charge du traitement du spectrogramme audio et l'extension de la prise en charge de la mise en page des données. La conversation couvre également l'extension proposée de l'influence d'ONNX sur le pipeline ML et les avantages potentiels de la prise en charge des trames de données au sein d'ONNX. Les participants expriment leurs opinions, avec un membre partageant des informations sur les efforts du Python Data API Consortium pour créer une norme d'API de données pour l'interopérabilité des tableaux et des trames de données. Le groupe semble convenir que l'expansion des capacités d'ONNX dans ces domaines est une bonne chose et s'aligne sur des initiatives plus larges de l'industrie.
  
  
• 00:10:00 Dans cette section, les intervenants discutent de l'adoption de la norme Python Data API comme moyen d'étendre la prise en charge d'ONNX et de garantir l'interopérabilité entre toutes les autres bibliothèques de la même norme. L'orateur dit que l'adoption de la norme faciliterait l'échange de modèles et que l'alignement du calendrier avec le plus grand consortium serait préférable pour les utilisateurs d'utiliser ONNX. Ils discutent également de la différence entre l'ONNX et la structure de données traditionnelle comme la trame de données, et de la nécessité d'adopter la même norme par d'autres bibliothèques.
  
  
• 00:15:00 peut intégrer ONNX dans le pipeline Kuflow pour faciliter le développement ML pour les utilisateurs finaux. Chen mentionne le concept d'un pipeline où tous les composants fonctionnent ensemble pour orchestrer le développement ML de bout en bout. Kuflow combine le modèle et le contenu des données avec l'infrastructure pour offrir une expérience transparente aux utilisateurs finaux. Chen étudie comment ONNX peut être intégré dans ce pipeline pour élargir son utilisation et faciliter la tâche des développeurs ML.
  
  
• 00:20:00 Dans cette section, les conférenciers discutent de l'idée de permettre aux utilisateurs qui utilisent Kubernetes et Kubeflow de tirer plus facilement parti d'ONNX pour leur infrastructure et leurs environnements. L'objectif est de développer une API facile d'accès pour extraire des modèles du zoo de modèles et créer un pipeline de bout en bout à l'aide d'ONNX. Les conférenciers présentent un exemple où ils utilisent ONNX pour décrire la partie inférence d'un processus d'apprentissage automatique dans Kubeflow et présentent des idées pour développer des composants ONNX afin de couvrir davantage d'étapes, y compris le traitement des données et la formation distribuée. L'idée est de tirer parti de la puissance de Kubernetes tout en couvrant davantage d'étapes du processus d'apprentissage automatique.
  
  
• 00:25:00 Dans cette section, les intervenants discutent de l'extension de QFlow pour avoir le travail ONNX pour permettre la formation distribuée et l'ajout du traitement et de la transformation des données pour accéder à la partie formation du modèle. Le runtime ONNX lui-même prend en charge la formation des modèles de transformateurs de PyTorch aujourd'hui, mais il reste encore des progrès à faire avec la formation des modèles ONNX. Les intervenants suggèrent de commencer par les modèles dans le zoo de modèles pour voir comment les données doivent être prétraitées et transformées pour les modèles, mais notez que cela n'est pas purement à l'intérieur du projet de base ONNX et nécessite un cadre de niveau supérieur pour définir les composants. comme CoolFlow.
  
  
• 00:30:00 Dans cette section, les participants discutent d'une proposition qui a été faite pour la feuille de route ONNX et suggèrent de lier les diapositives au document. Le groupe prévoit de continuer à évaluer l'impact de la proposition lors de réunions ultérieures et espère avoir plus de clôture sur la mise en œuvre. Ils accueillent également les commentaires et encouragent les utilisateurs à les soumettre via la feuille de route ou le comité de pilotage. La discussion se termine par un adieu et une invitation à de futures réunions.

[MetaQuotes]

Discussion sur la feuille de route ONNX 2020 #2 20200909

Discussion sur la feuille de route ONNX 2020 #2 20200909

Dans la vidéo "ONNX Roadmap Discussion", les conférenciers discutent de divers sujets liés à la feuille de route d'ONNX, notamment l'inférence de forme, les définitions d'opérateurs, les implémentations de référence et la spécification ONNX. Les conférenciers suggèrent de construire une infrastructure d'inférence de forme générique pour améliorer l'optimisation de l'inférence de forme, réduire le nombre d'opérateurs primitifs, ajouter des implémentations de référence pour chaque opérateur et des cas de test mieux définis pour garantir une implémentation et des tests appropriés d'ONNX. Le groupe prévoit de poursuivre les discussions au sein de l'opérateur SIG et sur le forum de discussion GitHub pour l'ajout d'un nouvel opérateur.

• 00:00:00 Dans cette section, les intervenants discutent de la feuille de route ONNX et couvrent quelques sujets suggérés, en particulier l'inférence de forme, la définition hors et l'IR, qui ont tous été précédemment mentionnés dans le document de feuille de route, avec des commentaires de diverses personnes. Les orateurs demandent si Changming ou Buchan sont disponibles pour expliquer leurs propositions. Buchan discute de ses commentaires sur les interférences de forme et comment il a eu des problèmes avec cela dans le passé. Il suggère de construire une infrastructure d'influence de forme générique qui recompile la forme chaque fois qu'il y a un changement dans l'IR pour s'assurer que l'optimisation de l'inférence de forme va de pair et améliore l'optimisation simultanément. Les conférenciers concluent que cela s'applique davantage à l'optimisation qu'à l'inférence de forme.
  
  
• 00:05:00 comprendre les capacités actuelles d'ONNX en termes d'inférence de forme et de passes d'optimisation. L'infrastructure existante prend déjà en charge l'inférence de forme basée sur des valeurs d'entrée connues et peut être utilisée pour déduire des formes de sortie. Il peut y avoir des fruits à portée de main dans la mise à jour du vérificateur de modèle, mais d'autres changements peuvent nécessiter plus de discussions. Le groupe discute si ces changements appartiennent à ONNX ou à un endroit différent. Ils envisagent également l'idée d'appeler des méthodes d'inférence de forme pour chaque opérateur dans des boucles consécutives pour obtenir les résultats souhaités. En fin de compte, l'infrastructure existante permet déjà des passes d'optimisation et l'inférence de forme, mais des changements et des améliorations pourraient améliorer ces capacités.
  
  
• 00:10:00 Dans cette section, les intervenants discutent des définitions des opérateurs et suggèrent de réduire le nombre d'opérateurs primitifs car d'autres opérateurs peuvent être rendus composables avec des opérateurs de niveau inférieur. Ils abordent également le thème de l'implémentation de référence et la nécessité pour l'infrastructure d'évaluer une séquence d'opérateurs. L'implémentation de référence actuelle existe sous la forme d'une implémentation Python dans le générateur de cas de test mais n'est pas organisée de manière à faciliter l'évaluation d'une séquence d'opérateurs. Les conférenciers suggèrent d'ajouter un temps d'exécution comme le temps d'exécution ONNX aux CI pour vérifier les sous-graphes de fonction, qui peuvent être utilisés pour la validation.
  
  
• 00:15:00 Dans cette section, les conférenciers discutent de la nécessité d'implémentations de référence pour chaque opérateur afin de garantir que les temps d'exécution ne divergent pas des attentes de l'auteur. Ils suggèrent d'utiliser l'implémentation de référence comme test unitaire pour valider la parité avec le runtime et également comme mode interpréteur pour vérifier l'interopérabilité et la validation. Les orateurs notent que l'utilisation de l'environnement d'exécution ONNX pour valider la fonction est possible en supposant que la fonction est composée d'opérations primitives qui existent dans ONNX. Cependant, l'utilisation du runtime ONNX pour les nouveaux opérateurs dans un sous-graphe qui inclut de nouvelles opérations primitives n'est pas possible car aucun autre runtime n'aurait cette implémentation. Ils reconnaissent que la création d'une implémentation de référence nécessite beaucoup de travail, mais elle est obligatoire pour chaque opération. Ils soulignent également la nécessité d'une conformité ONNX pour garantir que le temps d'exécution ne s'écarte pas des attentes de l'auteur.
  
  
• 00:20:00 Dans cette section, les intervenants discutent de l'utilisation d'implémentations de référence dans la spécification ONNX et de l'importance d'un langage clair et concis dans la spécification. Alors que certains préconisent l'utilisation d'implémentations de référence pour lever l'ambiguïté dans le texte anglais de la spécification, d'autres soutiennent que la spécification doit être suffisamment claire pour que les implémentations de référence ne soient pas nécessaires. Les conférenciers discutent également de l'importance de tests de conformité rigoureux pour s'assurer que tous les cas critiques possibles sont testés. En fin de compte, le consensus semble être que si les implémentations de référence peuvent être utiles, elles ne devraient pas être requises dans la spécification ONNX.
  
  
• 00:25:00 Dans cette section, il y a une discussion sur les exigences pour la mise en œuvre d'un opérateur dans ONNX, en particulier en ce qui concerne la nécessité d'une mise en œuvre de référence et de procédures de test. Alors que certains soutiennent qu'une implémentation de référence pour l'opérateur devrait être obligatoire pour générer des données de test, d'autres ne sont pas d'accord, affirmant qu'il suffit de fournir soit une fonction Python pour générer des données de test, soit un ensemble de données fixe. Cependant, il est à noter qu'avoir une implémentation de référence est crucial pour quelqu'un qui implémente l'opérateur dans un environnement d'exécution afin de tester correctement son implémentation, en particulier pour les opérateurs compliqués avec de nombreux attributs différents. La discussion précise également que bien qu'un runtime de référence pour ONNX ne soit pas nécessaire, une implémentation de référence pour chaque opérateur est requise.
  
  
• 00:30:00 Dans cette section de la vidéo, les conférenciers ont discuté de l'importance d'avoir une implémentation de référence et des cas de test mieux définis pour assurer une implémentation et des tests appropriés d'ONNX. Ils ont noté que s'appuyer sur les données de test générées peut être insuffisant et qu'avoir un code simple disponible résout le problème pour tout le monde. La conversation a également abordé la nécessité d'une spécification complète et la liberté du runtime pour déterminer ce qu'il faut faire dans les cas de comportement indéfini. Certains orateurs se sont dits préoccupés par le fait d'alourdir la charge de ceux qui proposent des opérateurs en ajoutant une mise en œuvre de référence. Ils ont suggéré de minimiser l'effort d'ingénierie et de revoir les exigences actuelles pour ajouter des opérations au système.
  
  
• 00:35:00 Dans cette section de la vidéo, les intervenants discutent de l'importance d'avoir une spécification complète et sans ambiguïté pour ONNX et des moyens de l'appliquer. Ils conviennent qu'une implémentation de référence en Python serait utile pour garantir que les personnes implémentant des opérateurs dans les runtimes puissent vérifier tous les cas de test. Cependant, ils reconnaissent également que la mise en œuvre d'une spécification n'est pas simple et qu'il reste encore des problèmes à résoudre. Ils discutent des moyens de clarifier la manière dont la spécification peut être utilisée et proposent que la pratique et les commentaires guident la proposition de nouveaux opérateurs, plutôt que de proposer un opérateur puis de le mettre en œuvre dans un environnement d'exécution. Ils notent également que l'une des conditions requises pour l'ajout d'une nouvelle opération est qu'elle doit être implémentée dans un cadre bien connu.
  
  
• 00:40:00 Dans cette section de la discussion sur la feuille de route ONNX, le groupe discute du processus d'ajout de nouveaux opérateurs à la spécification ONNX. La proposition est de changer la politique d'ajout d'un nouvel opérateur, qui nécessite déjà une implémentation de référence en Python. Leur discussion porte sur les implémentations de référence et les tests de conformité, et ils prévoient de poursuivre la conversation au sein de l'opérateur SIG et sur le forum de discussion GitHub. Le groupe prévoit de poursuivre les discussions lors de sa prochaine réunion prévue la semaine prochaine.

[MetaQuotes]

Qu'est-ce qu'ONNX Runtime (ORT) ?

Qu'est-ce qu'ONNX Runtime (ORT) ?

ONNX Runtime (ORT) est une bibliothèque qui optimise et accélère l'inférence d'apprentissage automatique, permettant aux utilisateurs de former leurs modèles dans n'importe quelle bibliothèque d'apprentissage automatique prise en charge, d'exporter au format ONNX et d'effectuer l'inférence dans leur langue préférée. L'orateur met en évidence un exemple d'inférence effectuée à l'aide de PyTorch avec ONNX Runtime et souligne que les utilisateurs peuvent visiter ONNXRuntime.ai pour explorer les différentes API et outils requis pour leur configuration préférée.