Éviter les dangers cachés : naviguer dans les pièges non évidents de ML sur iOS

Avez-vous besoin de ML ?

L’apprentissage automatique est excellent pour repérer les modèles. Si vous parvenez à collecter un jeu de données propre pour votre tâche, il s’agit généralement de peu de temps avant de pouvoir construire un modèle ML avec des performances supérieures à celles de l’homme. C’est particulièrement vrai dans les tâches classiques comme la classification, la régression et la détection d’anomalies.

Lorsque vous êtes prêt à résoudre certains de vos problèmes commerciaux avec ML, vous devez considérer où vos modèles ML seront exécutés. Pour certains, il est logique d’exécuter une infrastructure de serveur. Cela présente l’avantage de garder vos modèles ML privés, ce qui rend plus difficile pour les concurrents de rattraper leur retard. En outre, les serveurs peuvent exécuter une plus grande variété de modèles. Par exemple, les modèles GPT (rendus célèbres avec ChatGPT) nécessitent actuellement des GPU modernes, les appareils grand public sont donc hors de question. D’un autre côté, la maintenance de votre infrastructure est assez coûteuse, et si un appareil grand public peut exécuter votre modèle, pourquoi payer plus ? De plus, il peut y avoir des problèmes de confidentialité où vous ne pouvez pas envoyer les données des utilisateurs à un serveur distant pour le traitement.

Cependant, supposons qu’il soit logique d’utiliser les appareils iOS de vos clients pour exécuter un modèle ML. Que pourrait mal se passer ?

Limitations de la plate-forme

Limites de mémoire

Les appareils iOS ont beaucoup moins de mémoire vidéo disponible que leurs homologues de bureau. Par exemple, le récent Nvidia RTX 4080 Ti dispose de 20 Go de mémoire disponible. Les iPhones, en revanche, ont une mémoire vidéo partagée avec le reste de la RAM dans ce qu’ils appellent « mémoire unifiée ». Pour référence, l’iPhone 14 Pro dispose de 6 Go de RAM. De plus, si vous allouez plus de la moitié de la mémoire, iOS est très susceptible de tuer l’application pour s’assurer que le système d’exploitation reste réactif. Cela signifie que vous ne pouvez compter que sur 2-3 Go de mémoire disponible pour l’inférence de réseau neuronal.

Les chercheurs forment généralement leurs modèles pour optimiser la précision sur l’utilisation de la mémoire. Cependant, il existe également des recherches sur les moyens d’optimiser la vitesse et l’empreinte mémoire, vous pouvez donc soit rechercher des modèles moins exigeants, soit en former un vous-même.

Couches de réseau (opérations) prises en charge

La plupart des ML et des réseaux de neurones proviennent de frameworks d’apprentissage profond bien connus, puis sont convertis en CoreML modèles avec Core ML Tools. CoreML est un moteur d’inférence écrit par Apple qui peut exécuter divers modèles sur les appareils Apple. Les couches sont bien optimisées pour le matériel et la liste des couches prises en charge est assez longue, il s’agit donc d’un excellent point de départ. Cependant, d’autres options comme Tensorflow Lite sont également disponibles.

La meilleure façon de voir ce qui est possible avec CoreML est de regarder certains modèles déjà convertis à l’aide de visionneuses comme Netron. Apple répertorie certains des modèles officiellement pris en charge, mais il existe également des zoos de modèles à l’initiative de la communauté. La liste complète des opérations prises en charge change constamment, il est donc utile de regarder le code source de Core ML Tools comme point de départ. Par exemple, si vous souhaitez convertir un modèle PyTorch, vous pouvez essayer de trouver la couche nécessaire ici.

En outre, certaines nouvelles architectures peuvent contenir du code CUDA manuscrit pour certaines des couches. Dans de telles situations, vous ne pouvez pas vous attendre à ce que CoreML fournisse une couche prédéfinie. Néanmoins, vous pouvez fournir votre propre implémentation si vous avez un ingénieur qualifié familiarisé avec l’écriture de code GPU.

Dans l’ensemble, le meilleur conseil ici est d’essayer de convertir votre modèle en CoreML tôt, même avant de le former. Si vous avez un modèle qui n’a pas été converti immédiatement, il est possible de modifier la définition du réseau neuronal dans votre framework DL ou le code source du convertisseur Core ML Tools pour générer un modèle CoreML valide sans avoir besoin d’écrire une couche personnalisée pour l’inférence CoreML.

Validation

Bogues du moteur d’inférence

Il n’y a pas de moyen de tester toutes les combinaisons possibles de couches, le moteur d’inférence aura donc toujours certains bogues. Par exemple, il est courant de voir les convolutions dilatées utiliser beaucoup trop de mémoire avec CoreML, ce qui indique probablement une implémentation mal écrite avec un noyau grand et garni de zéros. Un autre bogue courant est une sortie de modèle incorrecte pour certaines architectures de modèles.

Dans ce cas, l’ordre des opérations peut être un facteur. Il est possible d’obtenir des résultats incorrects en fonction de savoir si l’activation avec convolution ou la connexion résiduelle vient en premier. La seule façon réelle de garantir que tout fonctionne correctement est de prendre votre modèle, de l’exécuter sur l’appareil prévu et de comparer le résultat avec une version de bureau. Pour ce test, il est utile d’avoir au moins un modèle semi-formé disponible, sinon l’erreur numérique peut s’accumuler pour les modèles mal initialisés au hasard. Même si le modèle formé final fonctionnera correctement, les résultats peuvent être très différents entre l’appareil et le bureau pour un modèle initialisé au hasard.

Perte de précision

L’iPhone utilise une précision à demi-précision de manière extensive pour l’inférence. Alors que certains modèles n’ont pas de dégradation d’exactitude notable due à un nombre réduit de bits dans la représentation à virgule flottante, d’autres modèles peuvent souffrir. Vous pouvez approximer la perte de précision en évaluant votre modèle sur le bureau avec une demi-précision et en calculant une métrique de test pour votre modèle. Une méthode encore meilleure est de l’exécuter sur un appareil réel pour découvrir si le modèle est aussi précis que prévu.

Profiling

Les différents modèles d’iPhone ont des capacités matérielles variées. Les derniers ont amélioré les unités de traitement du Neural Engine qui peuvent élever considérablement les performances globales. Ils sont optimisés pour certaines opérations, et CoreML est capable de distribuer intelligemment le travail entre CPU, GPU et Neural Engine. Les GPU d’Apple ont également été améliorés avec le temps, il est donc normal de voir des performances fluctuantes entre les différents modèles d’iPhone. Il est une bonne idée de tester vos modèles sur les appareils pris en charge minimal pour garantir une compatibilité maximale et des performances acceptables pour les anciens appareils.

Il vaut également la peine de mentionner que CoreML peut optimiser certaines des couches intermédiaires et des calculs à la place, ce qui peut améliorer considérablement les performances. Un autre facteur à considérer est que parfois, un modèle qui se comporte moins bien sur un bureau peut en fait effectuer une inférence plus rapide sur iOS. Cela signifie qu’il vaut la peine de passer du temps à expérimenter avec différentes architectures.

Pour une optimisation encore plus poussée, Xcode a un outil Instruments agréable avec un modèle spécialement conçu pour les modèles CoreML qui peut fournir une idée plus approfondie de ce qui ralentit votre inférence de modèle.

Conclusion

Personne ne peut prévoir tous les pièges possibles lors du développement de modèles ML pour iOS. Cependant, il existe certaines erreurs qui peuvent être évitées si vous savez ce que vous cherchez. Commencez à convertir, valider et profiler vos modèles ML tôt pour vous assurer que votre modèle fonctionnera correctement et répondra à vos exigences commerciales, et suivez les conseils ci-dessus pour garantir le succès le plus rapidement possible.