.png)
Avec une tarification à l’utilisation, ce mode Serverless permet ainsi une réduction significative des coûts pour bon nombre de cas d’usage, au prix de quelques compromis. Dans quel cas ce nouveau mode est-il le plus adapté ?
L’inférence en Machine Learning
En Machine Learning, l’inférence est la phase qui suit l'entraînement et la validation du modèle. Celle-ci consiste à déployer le modèle et à l’appliquer sur de nouvelles données “live” afin d’obtenir des prédictions.
Sur AWS, Amazon SageMaker est un service de Machine Learning entièrement managé. Celui-ci permet de développer, entraîner et déployer facilement des modèles, sans avoir à se préoccuper de la gestion de l'infrastructure. Concernant le déploiement, on distingue différents modes d’inférence pour répondre à différents cas d’usage :
- Mode batch : pour effectuer des prédictions sur un jeu de données en une fois. Le mode batch applique le modèle entraîné au travers d’un script d’inférence sur un jeu de données stocké sous S3. Ce mode est idéal pour les grands volumes de données et cas d’usage hors temps réel. Par exemple, pour une exécution quotidienne sur les nouvelles observations de la veille ;
- Inférence temps réel : déploie le modèle sur un point de terminaison (endpoint) afin de traiter rapidement des requêtes par web service. Les requêtes “live” sont traitées au fil de l’eau et les latences sont en millisecondes. Ce mode d’inférence peut traiter des requêtes allant jusqu’à 6 MO de données. Revers de la médaille, le endpoint doit rester la plupart du temps allumé, ce qui coûte cher. En ordre de grandeur, un endpoint AWS allumé 24h/24 sur une machine ml.t2.medium (4GB de RAM, 4 vCPU - la moins chère) coûte la modique somme de 45 USD par mois ;
- Inférence asynchrone : sorti en août 2021, le mode asynchrone permet une inférence live pour les requêtes dont les données sont particulièrement volumineuses (jusqu’à 1 GO) ou longues à calculer (jusqu’à 15 minutes). Pour cela, le mode asynchrone va stockerles différentes requêtes dans une file d’attente avec des données chargées depuis S3. Les latences sont plus élevées qu’avec le mode temps réel (> 1 seconde) ;
- Inférence serverless, avec déploiement serverless au travers d’AWS lambda. Le tarif est bien moins élevé qu’en inférence temps réel avec une tarification au temps à partie de 0,00002 USD par seconde pour une petite instance + une tarification au volume traité de 0,016 USD par Go entrant ou sortant (zone Paris, août 2022). Cela étant, ce mode comprend un cold start, c’est-à-dire un temps de préparation du modèle. Un modèle suffisamment léger sera plus avantagé. Ainsi, ce mode est idéal pour des données peu fréquentes, un trafic peu prédictible, ou des besoins de latences peu critiques.
Avantages et limites
L’inférence serverless permet ainsi de grandement réduire les coûts par rapport au mode temps réel. Revers de la médaille, le problème du cold start qui pénalise les modèles volumineux. Ainsi, le mode serverless se révèle particulièrement utile dans les cas suivants :
- Réalisation d’un POC, afin de réduire au maximum les coûts. Les temps de latence liés à l’inférence y sont généralement peu importants ;
- Trafic intermittent ou imprévisible, pour lequel le endpoint doit pouvoir être disponible en permanence. Dans le cas d’une inférence en temps réel, laisser le endpoint allumé en permanence coûte relativement plus cher ;
- Modèles légers, afin de permettre un chargement suffisamment rapide du modèle pour éviter les latences liées au cold start. Avec ce type de modèle, il est possible d’obtenir des prédictions en quelques millisecondes.
Exemple d’utilisation
Dans l’exemple ci-dessous (disponible sur Github), nous allons comparer le mode “temps réel” et le mode “serverless” sur le jeu de données fashion MNIST. Ces données, publiées par Zalando, contiennent 70 000 images de vêtements. Chaque image est en niveaux de gris et de taille 28x28 pixels. A chacune d’entre elles est associé un des 10 labels existants (trouser, pullover, dress, coat...). L’objectif est ainsi de pouvoir entraîner un modèle de Machine Learning à classer des images dans la bonne catégorie de vêtement.
Notre exemple comprend le chargement des données, l'entraînement d’un réseau de neurones avec Tensorflow, puis le déploiement de deux endpoints : l’un en mode temps réel et l’autre en mode serverless.
Pour démarrer, nous chargeons les images. Comme ce jeu de données fait partie des jeux de données par défaut de TensorFlow, nous pouvons le charger simplement avec :
Pour visualiser les images :
Nous avons ensuite écrit un script train.py afin de pouvoir définir, entrainer et sauvegarder le modèle. Dans notre exemple, celui-ci est un simple réseau de neurones contenant une couche d’entrée, une couche cachée de 128 neurones, puis une couche de sortie. En fin de script, le modèle est sauvegardé sur Amazon S3.
train.py : définition, entraînement et sauvegarde du modèle. La variable d’environnement ‘SM_MODEL-DIR’ est définie par défaut sur la machine distante AWS où est exécuté le script
Avec Amazon SageMaker, les utilisateurs développent sur une petite instance avec un environnement Jupyter déjà prête (appelée SageMaker Studio). Les tâches (jobs) plus conséquentes sont exécutées à la demande sur une machine distante plus grande.
Pour ce faire, nous appelons la classe sagemaker.tensorflow.TensorFlow qui agit comme un wrapper afin de configurer l'exécution à distance.
notebook serverless.ipynb : la classe TensorFlow est un wrapper. Celle-ci permet de configurer l'exécution sur une machine distante en définissant un point d’entrée (train.py), le rôle IAM associé, le type de machine et la version de Tensorflow.
Une fois l’estimateur entraîné, il est alors possible de déployer facilement le endpoint. Pour le mode inférence en temps réel, il suffit d'exécuter les instructions suivantes :
notebook serverless.ipynb : déploiement en mode temps réel. On spécifie le nom du endpoint et le type d’instance (ici ml.t2.medium)
Après quelques minutes, le endpoint devient opérationnel. Dans le cas du mode serverless, on ajoute une classe de configuration ServerlessInferenceConfig. Celle-ci prend deux paramètres :
- MemorySize, la RAM allouée au endpoint. Elle peut aller de 1024 MO à 6144 MO. Les ressources de calcul sont allouées proportionnellement à la mémoire. Un endpoint avec une grande RAM aura plus de vCPU ;
- MaxConcurrency, le nombre maximum d’invocations possibles en même temps. Celui-ci peut aller de 1 à 200 pour un même endpoint.
Après quelques minutes, le endpoint devient opérationnel. Dans le cas du mode serverless, on ajoute une classe de configuration ServerlessInferenceConfig. Celle-ci prend deux paramètres :
- MemorySize la RAM allouée au endpoint. Elle peut aller de 1024 MO à 6144 MO. Les ressources de calcul sont allouées proportionnellement à la mémoire. Un endpoint avec une grande RAM aura plus de vCPU ;
- MaxConcurrency, le nombre maximum d’invocations possibles en même temps. Celui-ci peut aller de 1 à 200 pour un même endpoint.
notebook serverless.ipynb : déploiement en mode serverless
Une fois les endpoints activés, il est alors possible de les requêter. Pour les deux endpoints, nous pouvons par exemple utiliser les instructions suivantes. Celles-ci vont invoquer le endpoint choisi, puis afficher la prédiction et le label (variable à prédire) associés :
serverless.ipynb : on invoque le endpoint au travers de la classe Predictor. La méthode .predict() permet ensuite d’obtenir une prédiction
Nous pouvons aussi mesurer des temps de latences avec un chronomètre et une boucle for... in.
Ce qui donne, pour le endpoint en temps réel, des latences de l’ordre de 15 ms.
Pour le endpoint en mode serverless, des latences de l’ordre de 45 ms dû à l’effet cold start.
Au niveau de la tarification, le endpoint serverless permet de fortes économies par rapport au endpoint temps-réel. En effet, 1 million d’appels au endpoint serverless coûtent 3,68 USD, tarif dû aux 1M x 45 millisecondes de temps de calcul (soit 3,6 USD, facturé 0,00008 USD par seconde de calcul) et au volume de données entrant 1M x 0,5 Ko par image (soit 0,008 USD, facturé 0,016 SD par GO entrant ou sortant).
En comparaison, le endpoint temps-réel est un instance ml.t2.medium est facturé à 0,063 USD par heure, soit 1,51 USD par jour, le endpoint serverless reste ainsi avantageux jusqu’à 410k appels par jour.
Note : Bien entendu, ce calcul est effectué sur un cas d’usage relativement modeste (petit modèle et images comprenant 784 pixels). Pour des images plus conséquentes ou un modèle plus volumineux / plus complexe, les temps de calcul et chargement s’allongerait, ce qui augmenterait le prix de l’inférence serverless. Ce sont ainsi des critères importants à prendre en compte dans le choix de ce type de endpoint.
Conclusion
L'inférence serverless apporte une flexibilité supplémentaire pour le déploiement de modèles de Machine Learning. Par rapport à l’inférence en temps réel, celle-ci permet de réduire grandement les coûts pour la plupart des cas d'usage. En contrepartie, le mode serverless peut souffrir de latences plus importantes au démarrage (cold start).
C’est donc un mode de déploiement particulièrement adapté aux projets en phase de POC, avec un trafic intermittent ou bien faisant intervenir des modèles suffisamment légers pour répondre aux temps de latences demandés.
