Machine learning : Databricks renforce son support de l’inférence en temps réel

Accélérer le déploiement de petits modèles appelés en temps réel

Prem Prakash donne l’exemple de Hipages, une startup australienne spécialisée dans l’établissement de devis et la comparaison de devis entre artisans du BTP pour les particuliers. Hipages se sert de Model Serving afin d’enclencher par appel API ses modèles de matchmaking, de recommandation, d’indexation, de calcul tarifaire pour proposer en temps réel une sélection de devis et d’entreprises capables de réaliser des travaux.

« Nous avons aussi de gros clients comme Electrolux, Hitachi et d'autres », note le responsable.

Electrolux, lui, s’en sert pour trier automatiquement les demandes effectuées par les clients au support. Model Serving peut également exécuter les prédictions qui seront affichées dans un tableau de bord d’un outil comme Power BI.

« Nous assistons à une évolution vers l'inférence en temps réel », confirme Matt Aslett, analyste chez Vantana Research auprès de nos confrères de Techtarget [propriétaire du MagIT]. « Les organisations ressentent le besoin de réduire le coût, la complexité et le temps nécessaire pour calculer des indicateurs clés de performance dans les applications opérationnelles, telles que la personnalisation et les recommandations basées sur l'intelligence artificielle ». 

Databricks propose trois tailles d’instances (Small, Medium, Large) reposant sur des CPU et, pour le moment, un type d’instance GPU. La tarification à l'usage dépend d’un certain nombre de DBU (Databricks Unit).

« Nous nous assurons que nous sommes en mesure d'augmenter et de diminuer [l’instance] jusqu'à son arrêt total, ce qui vous permet de faire des économies », affirme Prem Prakash. L’arrêt total, nommé « Scale to zero » dans la console, est une option à cocher.

Le responsable explique que le système peut réaliser une phase d’autoscaling, mais que les utilisateurs peuvent configurer une notification au moment de changer de taille d’instances.

Selon Prem Prakash, Model Serving permettrait de s’éviter en grande partie les tâches de gestion complexes. Aussi, un seul point de terminaison permet de répartir le trafic lié aux requêtes vers plusieurs modèles, éviter les goulets d’étranglement, à des fins de tests A/B, suivant le type de charges de travail à traiter.

Avant tout, il faudra provisionner le modèle, l’environnement et le point de terminaison du modèle lui-même. Cela prend environ 10 minutes. Par défaut, si le modèle n’a pas été exécuté dans les 60 secondes après l’appel API, la plateforme affichera une erreur. Cette limite n’est toutefois pas figée. « Si vous pensez que le temps de calcul prendra plus de 60 secondes, contactez le support de Databricks » prévient la documentation.

Pour le moment, le service affiche une limite de 3 000 requêtes par seconde. Cette valeur pourrait évoluer.

« Nous allons voir comment les clients réagissent et l’utilisent », déclare Prem Prakash.

Pour le responsable, le « plus gros bénéfice » de cette fonctionnalité est la simplicité. « Alors qu’habituellement, vous avez besoin d’utiliser et de connecter plusieurs outils entre eux, vous pouvez désormais depuis une même plateforme ».

Cela ne veut pas dire que cela forcément moins cher pour une entreprise. Cependant, Databricks signale qu’il garantit un SLA pour le service, donc un certain niveau de résilience et de performance. Pour ce faire, l’éditeur maintient un pool d’instances « au chaud » qui lui permettent de réaliser des économies d’échelle et d’assurer les performances attendues pour les charges de travail.

Pour autant, cette expérience intégrée ne convient pas à tous les utilisateurs de Databricks. Preuve en est, l’éditeur a récemment annoncé une extension Visual Code pour les data engineers et les data scientists qui ne se seraient pas habitués aux notebooks Jupyter.