Inférence de machine learning : comment les modèles entraînés créent de la valeur en production

Lorsqu’une nouvelle requête atteint une application de production, un modèle de machine learning peut n’avoir que quelques secondes pour évaluer le contexte le plus récent, produire un résultat et le renvoyer au système qui décide de la suite.

Ce moment, c’est l’inférence : appliquer un modèle entraîné à des données actualisées pour que l’application puisse agir. En production, l’inférence dépend de tout le parcours d’exécution qui l’entoure. Si un maillon de cette chaîne est défaillant, ralentit ou s’écarte de la logique utilisée lors de l’entraînement, la prédiction risque d’arriver trop tard ou de ne plus être suffisamment en phase avec la réalité pour être utile.

Trace Smith, Senior IA/ML Architect, Applied Field Engineering chez Snowflake, explique pourquoi ce défi de fiabilité ne se résume pas à la vitesse : « Dans les applications de ML en temps réel, comme la détection des fraudes et la maintenance prédictive, la latence et la capacité de mise à l’échelle retiennent l’attention, mais c’est souvent la concordance qui met la production en difficulté. Unifier les transformations, la logique de feature et la mise en production permet d’éviter les écarts entre entraînement et mise en production, et de garder des prédictions fiables à mesure que vous mettez à l’échelle. »

L’inférence de machine learning consiste à utiliser un modèle entraîné pour générer une sortie à partir de nouvelles données d’entrée inédites. Selon le modèle et la tâche, cette sortie peut être une prédiction, un score de probabilité, une classification, un embedding, une réponse générée ou un champ extrait.

Un pipeline d’inférence se situe généralement entre les données sources et le système de machine learning qui consomme le résultat. Il récupère les features requises, transforme l’entrée au format attendu par le modèle, calcule les scores du modèle, convertit la sortie brute en format exploitable et livre cette sortie à une table, une application, un point de terminaison d’inférence ou un processus en aval.

La séquence paraît simple, mais le pipeline d’inférence doit préserver les attentes du modèle définies lors de l’entraînement. Par exemple, si une feature est calculée différemment au moment de l’inférence, une même colonne peut représenter un concept business différent de celui utilisé pendant l’entraînement. Ou si le prétraitement est appliqué de façon incohérente, le modèle peut recevoir des valeurs dans un format, à une échelle ou selon une distribution différents de ceux sur lesquels il a appris. En production, l’inférence doit maintenir le pipeline de données environnant suffisamment homogène pour que la sortie reste fiable.

L’entraînement est la phase où le modèle apprend : il ajuste ses paramètres internes, ou poids, afin de capturer des schémas à partir des données d’entraînement, généralement des données historiques étiquetées pour l’apprentissage supervisé. Il mobilise généralement beaucoup de calcul et s’exécute souvent périodiquement : lorsque de nouvelles données deviennent disponibles, lorsque la performance se dégrade ou lorsque la cible de prédiction change.

L’inférence vient ensuite, lorsque le modèle est appliqué à de nouvelles entrées. En production, l’inférence se répète sur des requêtes, des lignes, des événements, des fichiers ou des prompts.

Les exigences d’infrastructure diffèrent fortement entre les deux. L’entraînement est généralement intensif en calcul, mais limité dans le temps : une tâche démarre, peut s’exécuter pendant des heures, puis se termine. L’inférence est continue et sensible à la latence. Dans le cas d’un modèle de détection de fraude, par exemple, la fenêtre entre le lancement d’une transaction et son autorisation peut se mesurer en millisecondes.

Le coût suit une asymétrie similaire. L’entraînement d’un grand modèle peut nécessiter une capacité de calcul importante, mais il s’agit d’une dépense ponctuelle ou périodique. L’inférence s’exécute pendant toute la durée de vie du modèle, souvent à fort volume.

Un modèle performant lors d’une évaluation hors ligne peut tout de même mal fonctionner en production si le pipeline d’inférence fournit des entrées obsolètes, dépasse les budgets de latence ou produit des sorties dans un format que les systèmes en aval ne peuvent pas analyser. La qualité du modèle et la qualité de l’inférence sont liées, mais relèvent de problématiques distinctes.

Les principaux types d’inférence de machine learning répondent à des exigences différentes en matière de timing et de déploiement. Pour choisir le type le plus adapté, les équipes doivent tenir compte non seulement de la façon dont le modèle génère une prédiction, mais aussi du moment où la sortie est nécessaire et de l’endroit où le modèle peut s’exécuter.

Inférence par batch

L’inférence par batch applique un calcul de scores à de nombreux enregistrements à la fois, généralement selon un planning ou dans le cadre d’un pipeline de données défini. Elle est particulièrement utile lorsque les prédictions peuvent être générées avant d’être nécessaires, par exemple pour actualiser des scores clients pendant la nuit, enrichir des données produit avant une mise à jour de catalogue ou générer des prévisions avant le démarrage des workflows de planification.

Les principales exigences portent sur le débit, la fiabilité du traitement et la gestion des sorties. Le système doit être capable de traiter le volume de données attendu, d’achever le traitement dans le délai imparti et de produire les résultats là où les outils d’analyse, les applications ou les équipes opérationnelles en aval pourront les exploiter.

L’inférence par batch convient souvent aux workflows dans lesquels la sortie de prédiction constitue elle-même un actif de données. Il peut être nécessaire de stocker un score d’attrition, une table de recommandations, une prévision de la demande ou le résultat d’une classification de documents, de les associer à d’autres données, puis de les réutiliser dans des processus de reporting, de planification ou des applications métier.

Inférence en temps réel ou en ligne

L’inférence en temps réel, également appelée inférence en ligne, génère une prédiction en réponse à une requête. Une application envoie une entrée à un point de terminaison d’inférence, le modèle applique un calcul de scores à cette entrée et l’application reçoit une réponse.

L’inférence en ligne est généralement utilisée lorsque la prédiction influence une interaction ou une décision immédiate. Détection de fraude lors de l’autorisation d’un paiement, classement de contenu pendant une session active, prompts de meilleure action suivante dans une conversation en direct : tous ces cas dépendent de prédictions qui doivent arriver avant que l’instant décisif ne soit passé.

L’inférence en temps réel dépend d’une infrastructure de mise en production de modèles capable de maintenir un modèle chargé, d’accepter les requêtes, d’exécuter le calcul des scores et de renvoyer les réponses dans le budget de latence de l’application. Elle doit gérer la latence par requête, la concurrence, le comportement au démarrage à froid et les objectifs de niveau de service, car le système consommateur attend le résultat.

Ce type d’inférence met aussi davantage de pression sur la disponibilité des features. Si le modèle dépend du comportement récent des utilisateurs, de l’état des stocks ou du contexte de transaction, le pipeline d’inférence doit disposer d’un chemin fiable pour récupérer ces entrées rapidement et de manière cohérente.

Inférence en flux

L’inférence en flux applique en continu un calcul de scores aux données, à mesure que les événements arrivent, sans attendre un batch planifié ni une requête synchrone. Le modèle traite un flux d’entrées, comme des relevés de capteurs, des événements de log ou des données de parcours de navigation, et produit des sorties qui alimentent les systèmes en aval en temps quasi réel.

L’inférence en flux intervient souvent au plus près des workflows de supervision opérationnelle, de calcul du score des risques et d’alerte. Le résultat produit par le modèle peut servir à acheminer un événement, à mettre à jour un score, à déclencher une révision ou à enrichir le contexte d’un système en aval qui traite déjà le flux de données. Le pipeline d’inférence en flux doit coordonner le traitement des événements, l’actualisation des features et la transmission des sorties.

Inférence en périphérie

L’inférence en périphérie exécute le modèle sur un appareil ou un système local, plutôt que dans un environnement centralisé. Ce type d’inférence s’impose lorsque des contraintes de latence, de connectivité, de confidentialité ou de transfert de données rendent l’inférence centralisée peu pratique. L’inférence en périphérie est fréquente dans les environnements où la prédiction doit être produite au plus près de la source des données, par exemple dans des applications mobiles, des capteurs, des véhicules, des caméras ou des systèmes industriels.

La contrainte, c’est que les environnements en périphérie disposent de capacités limitées en calcul, en mémoire et en alimentation. Les modèles doivent généralement être compressés, via la quantification, l’élagage ou la distillation des connaissances, avant de pouvoir s’exécuter de manière fiable dans les limites de l’appareil.

Une fois le modèle passé en production, les équipes ont besoin d’indicateurs qui décrivent à la fois le comportement du modèle et son comportement à l’exécution. L’exactitude, la précision, le rappel et les autres mesures de qualité d’un modèle sont importantes, mais elles ne permettent pas de déterminer si le pipeline d’inférence respecte son objectif de latence, traite le volume de données requis ou produit des résultats à un coût soutenable.

Les indicateurs à mesurer dépendent du schéma d’inférence. Les traitements par batch mettent généralement l’accent sur le débit, le temps d’exécution et le coût par prédiction. L’inférence en ligne privilégie la latence, le taux d’erreur et le comportement au démarrage à froid. L’inférence LLM ajoute des mesures au niveau des tokens, car la longueur de sortie, la vitesse de génération et la taille du contexte influencent directement la latence comme le coût.

L’optimisation de l’inférence a deux points de départ : le modèle et le pipeline.

Côté modèle, la taille et la précision sont les principales variables. La quantification réduit la précision numérique des poids et des activations. Le passage de FP32 à INT8 réduit l’empreinte mémoire et améliore souvent le débit sur du matériel compatible, avec un risque pour la précision que les équipes valident sur des données proches de la production. L’élagage supprime les paramètres qui contribuent peu à la qualité de sortie, ce qui réduit les besoins en calcul et en mémoire pour un modèle qui atteint toujours le seuil d’exactitude exigé. La distillation des connaissances entraîne un modèle plus petit à reproduire approximativement le comportement d’un modèle plus grand. C’est utile lorsque le modèle complet est précis, mais trop coûteux ou trop lent pour l’environnement de mise en production cible.

Côté pipeline, le fonctionnement par batch est le levier le plus accessible. Regrouper les requêtes améliore l’utilisation du matériel et le débit, même si cela introduit une latence que les charges de travail par batch peuvent absorber plus facilement que les points de terminaison en temps réel. Le fonctionnement par batch dynamique ajuste la taille des groupes en fonction du trafic entrant, ce qui aide à équilibrer ces exigences concurrentes.

Le choix du matériel influence les coûts et la performance. Les CPU conviennent aux charges de travail à faible volume ou moins intensifs en calcul, tandis que les GPU offrent des avantages considérables en matière de débit pour l’inférence de deep learning lorsque les tailles de batch et de modèle permettent de bien les exploiter.

Le format du modèle et l’environnement d’exécution influencent la portabilité et la vitesse d’exécution. ONNX donne aux équipes un moyen de représenter les modèles dans différents frameworks et environnements d’exécution. TensorRT peut optimiser l’inférence de deep learning sur les GPU grâce à des techniques comme la fusion de couches, le calibrage de la précision, la sélection de noyaux et l’optimisation de graphes.

L’inférence LLM implique d’autres considérations de réglage. La longueur du prompt, l’utilisation de la fenêtre de contexte et les limites maximales de tokens de sortie influencent toutes le coût de calcul par requête. Un cache KV stocke les calculs clé-valeur d’attention issus du contexte précédent, afin que le modèle ne les recalcule pas à chaque token. Le décodage spéculatif utilise un modèle d’ébauche plus petit pour proposer des tokens qu’un modèle plus grand vérifie, ce qui améliore le débit lorsque le processus de vérification accepte suffisamment de tokens d’ébauche. Les variantes approximatives peuvent privilégier la vitesse au détriment de la qualité.

Important à retenir : pour optimiser, vous devez savoir ce que vous cherchez à optimiser. Réduire la latence et améliorer le débit exigent souvent des approches différentes, et ces deux objectifs peuvent entrer en conflit avec les cibles de coût. Les équipes qui mesurent avant d’optimiser évitent de remplacer un problème par un autre.

L’inférence ML utilise des données, des modèles et des sorties qui peuvent tous être soumis à des exigences de gouvernance. Par exemple, les données d’entrée peuvent contenir des champs sensibles, ou le modèle peut être approuvé pour certains cas d’usage, mais pas pour d’autres. Les équipes doivent donc savoir quelles données ont été utilisées, quelle version du modèle a généré la sortie, qui peut accéder au résultat et si la prédiction convient au workflow qui la consomme. La traçabilité, les contrôles d’accès, les métadonnées de modèle et la surveillance des modèles contribuent tous à établir ce contexte.

La gouvernance est particulièrement importante lorsque les sorties d’inférence deviennent des actifs de données réutilisables. Sans responsables clairement désignés, sans gestion des versions ni politiques d’accès, ces sorties peuvent être difficiles à auditer, à expliquer ou à réutiliser en toute sécurité.

Les workflows d’inférence en production sont des workflows de données. Le modèle a besoin d’entrées issues des systèmes de données de l’entreprise, et les sorties doivent généralement retourner dans ces mêmes systèmes : jointes aux enregistrements client, écrites dans une table lue par un outil de BI, ou transmises à un pipeline en aval.

Snowflake prend en charge l’inférence de modèles avec deux moteurs de calcul : le moteur SQL du warehouse et Snowpark Container Services. Le Snowflake Model Registry fournit une interface unifiée pour les deux.

Pour les charges de travail par batch à haut débit, les Snowflake Batch Inference Jobs utilisent Snowpark Container Services pour fournir du calcul distribué au calcul de scores à grande échelle de jeux de données statiques ou mis à jour périodiquement. Cela inclut les données non structurées stockées dans les zones de préparation Snowflake. Pour la mise en production en temps réel, Snowflake prend en charge le déploiement de modèles sous forme de points de terminaison HTTP managés via Snowpark Container Services, afin de maintenir le déploiement des modèles connecté à l’environnement même où résident les données sous-jacentes.

Les Cortex AI Functions étendent l’inférence à l’analyse basée sur les LLM appliquée aux données gouvernées : complétion, embedding, extraction, analyse des opinions, résumé, traduction et traitement multimodal de documents grâce à des fonctions comme AI_PARSE_DOCUMENT. Ces fonctions s’exécutent sur des données déjà présentes dans Snowflake, sans les déplacer vers un système externe.

La valeur tient à l’homogénéité architecturale. Différentes charges de travail d’inférence exigent toujours des schémas d’exécution différents, mais elles peuvent rester connectés aux données, à la gestion des modèles et aux workflows de sortie que les équipes de production utilisent déjà. Snowflake permet aux équipes de choisir le modèle le mieux adapté à la charge de travail, tout en gardant l’inférence au plus près des données d’entreprise dont elle dépend.

L’architecture d’inférence doit suivre le parcours de données. Le modèle a besoin d’entrées alignées sur la logique utilisée lors de l’entraînement, le pipeline doit disposer d’une puissance de calcul suffisante pour respecter les exigences de délai du workflow, et la sortie doit arriver là où les analyses, les applications ou les systèmes en aval peuvent l’exploiter. Séparer ces différents éléments entraîne des déplacements de données, des duplications et multiplie les risques de divergence dans la logique de calcul des features ou dans le traitement des résultats.

Exécuter l’inférence au plus près des données d’entreprise aide les équipes à traiter les sorties de modèle comme des données de production, et non comme des réponses de modèle isolées. Le résultat est un parcours plus fiable, depuis les données sources jusqu’à la prise de décision métier, en passant par le calcul des scores du modèle, avec moins de transferts entre les systèmes chargés de préparer les données, d’exécuter le modèle et d’exploiter les résultats.