Un modèle courant que nous avons observé est que la création et le déploiement d'un modèle ML à des fins de production sont effectués par différentes équipes, généralement une équipe d'algorithmes ML et une équipe d'exploitation de l'appareil. L'équipe ML gère la formation et l'évaluation du modèle, tandis que l'équipe de l'appareil est responsable de la migration du modèle vers l'environnement de production.

Une telle séparation est en partie due au fait que la formation et l'inférence ont divergé, concernant à la fois les plates-formes matérielles et les piles logicielles. Dans le passé, nous utilisions Caffe sur un serveur GPU pour la formation et le service. De nos jours, les gens utilisent des outils et des serveurs puissants pour la formation, puis déploient des modèles sur des environnements d'exécution hautement optimisés et divers appareils. Les problèmes de déploiement sont fréquemment rencontrés en raison de la complexité du modèle et des limitations matérielles, et l'équipe ML doit généralement s'appuyer sur les commentaires de l'équipe d'exploitation de l'appareil pour résoudre ces problèmes.

Par conséquent, les ingénieurs en apprentissage automatique (MLE) manquent souvent d'informations très élémentaires sur la capacité de déploiement de leurs propres modèles. Le déploiement de modèles d'aujourd'hui est souvent un pipeline construit en interne composé de plusieurs scripts Bash/Python couvrant différentes machines et environnements. Cela implique également plusieurs bibliothèques open source ou des kits d'outils spécifiques au fournisseur pour la conversion de modèles, la quantification, le réglage des performances et la vérification de la précision. Ce n'est pas une expérience agréable, comparée au développement de modèles dans un environnement Python natif du cloud.

En plus de la complexité de l'outillage, le manque d'interprétabilité des performances est un autre problème. Les rapports de profilage des chaînes d'outils en aval nécessitent souvent des connaissances du domaine pour être compris et convertis en informations de modèle exploitables, comme dans l'exemple TensorRT suivant. Parallèlement au long pipeline de conversion de modèles, il est difficile pour les développeurs ML d'identifier les goulots d'étranglement réels des performances de leurs propres modèles et d'apporter les modifications appropriées.

Malgré ces inconvénients, la séparation de la conception et du déploiement de modèles reste la norme dans l'industrie, car ils nécessitent généralement des compétences complètement différentes. "Il est déjà difficile d'embaucher un expert en ML ou un expert en appareils, et encore moins un expert des deux", c'est ce que nous entendons sans cesse de nos clients. Mais cela ne signifie pas que nous devons continuer à tolérer le flux de travail ML actuel.

Dans Software 1.0, il est difficile d'imaginer qu'un programme soit écrit par un ingénieur et compilé par un autre ingénieur. Les programmeurs peuvent compiler le code eux-mêmes, avec peu ou pas de connaissances sur les étapes sous-jacentes telles que l'assemblage et la liaison, tout en étant en mesure d'obtenir des informations significatives pour corriger leurs codes. Sans de telles informations, le processus de débogage pourrait devenir un va-et-vient sans fin entre deux ingénieurs qui ne parlent pas la langue de l'autre.

Jusqu'à présent, les problèmes les plus courants que nous avons constatés et qui retardent le déploiement des modèles de ML sont :

1. Latence/débit intolérable
2. Opérateurs non pris en charge
3. Inadéquation de la précision

Un flux de travail simple et compréhensible pour le déploiement et le diagnostic des modèles est la solution. Une interface que les ingénieurs ML peuvent utiliser et comprendre par eux-mêmes améliorera considérablement la productivité.

Construire un compilateur ML super puissant n'est qu'une partie de la solution, car il existe des différences fondamentales entre le logiciel 2.0 et le logiciel 1.0 : premièrement, de nouveaux opérateurs sont constamment déployés par le milieu universitaire et nombre d'entre eux ne peuvent pas être composés d'opérateurs existants ; deuxièmement, les modèles ML peuvent tolérer un remplacement d'opérateur non fonctionnel tout en conservant une précision similaire, ce qui offre une plus grande flexibilité de personnalisation aux développeurs ML. Nous n'entrerons pas dans les détails cependant, car cela vaut probablement la peine d'avoir un blog séparé pour parler de la personnalisation du modèle pour le déploiement.

Chez OmniML , nous avons commencé par créer un outil interne permettant à nos ingénieurs de déployer et de profiler leurs modèles ML sans avoir à étudier le matériel et sa chaîne d'outils ML. On s'est vite rendu compte du gain de performances d'un tel outil. De plus, cette interface unifiée et riche en informations permet aux humains et aux algorithmes de débloquer de grandes opportunités d'optimisation de modèles. Par conséquent, ces fonctionnalités sont désormais officiellement disponibles dans les produits d'OmniML : Omnimizer et Omnimizer Enterprise .

Omnimizer — une plateforme unifiée d'optimisation et de déploiement de modèles

Omnimizer est principalement conçu pour les ingénieurs ML qui conçoivent et forment des modèles PyTorch. Cela les aide à identifier les défauts de conception et à réduire les délais de production.

Omnimizer fournit une interface native PyTorch et cloud pour tester rapidement un modèle sur le matériel cible. Les utilisateurs n'ont qu'à spécifier une configuration de déploiement de haut niveau, puis envoyer la demande au cloud d'appareils hébergé par OmniML. Les informations de déploiement clés, y compris la latence globale, la latence par couche et les erreurs de déploiement (le cas échéant), seront signalées de la manière la plus simple qu'un expert non-matériel puisse comprendre.

Omnimizer permet aux utilisateurs de comparer facilement la précision de l'appareil avec le modèle d'origine. Il élimine les tracas liés au transfert du modèle et des données vers un autre appareil, se familiarise avec différents systèmes d'exploitation et chaînes d'outils, et maintient un tas de scripts désorganisés et bourrés de bogues. Dans l'exemple suivant, les utilisateurs peuvent obtenir la sortie du modèle dans une interface de type PyTorch, tandis que l'inférence réelle se produit sur un appareil distant, par exemple, un GPU de classe serveur ou un smartphone.

Omnimizer n'est pas seulement une bibliothèque de logiciels, mais également une plate-forme MLOps qui fournit une interface conviviale pour naviguer dans les détails des performances, partager des informations sur les modèles et reproduire les environnements de déploiement. Les utilisateurs peuvent visualiser les étapes de déploiement, obtenir la latence de référence et mieux comprendre leur modèle sur le matériel.

Omnimizer Enterprise — Libérez tout le potentiel du matériel d'IA

Par rapport à la version communautaire qui assiste le déploiement et l'optimisation des modèles, la version entreprise fournit une optimisation automatisée des modèles basée sur des années de recherche sur la recherche d'architecture neuronale (NAS) et une personnalisation étendue pour les besoins de l'entreprise.

NAS a toujours été considéré comme un processus coûteux qui nécessite une expertise approfondie dans l'espace de recherche et la conception de tâches proxy. Avec Omnimizer, chaque utilisateur peut appliquer un NAS pour personnaliser ses modèles pour le matériel cible. Ce processus ne nécessite que quelques lignes de changement de code, de faibles coûts de formation et, surtout, aucune obligation d'être un expert en conception de modèles et en performances matérielles.

Omnimizer peut facilement s'intégrer aux référentiels open source et accélérer les modèles prêts à l'emploi avec peu d'optimisation manuelle. Jusqu'à présent, OmniML et ses clients ont démontré des accélérations de 1,2 à 6,8 fois sur les plates-formes NVIDIA et Qualcomm. Ces référentiels seront ouverts aux utilisateurs d'entreprise à titre d'exemple :

• YOLO-X (détection d'objet)
• EfficientDet (détection d'objets)
• YOLO-P (modèle multitâche pour la conduite autonome)
• DDRNet (segmentation sémantique)
• ResNet (classification d'images)
• DD3D (détection d'objets 3D)
• RAFT (flux optique)
• DistilBERT (traduction automatique)

Essayez Omnimizer !

Omnimizer Beta vient de sortir. Inscrivez-vous maintenant sur le site Web d'OmniML et commencez à optimiser votre flux de travail !

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