Model serving : la couche d'exécution qui maintient le ML en production

En machine learning en production, le modèle n'est souvent que la plus petite composante du système. Les chercheurs David Sculley et al. ont souligné ce point dans leur article Hidden Technical Debt in Machine Learning Systems, en affirmant que seule une petite fraction de nombreux systèmes de ML du monde réel est consacrée à l'apprentissage ou à la prédiction. Le reste constitue le système de production environnant : collecte de données, extraction de caractéristiques, vérification, configuration, supervision, gestion des ressources, gestion des processus, infrastructure de serving et le code de liaison qui connecte un composant à un autre. Dans les systèmes matures, selon les auteurs, l'équilibre peut aller jusqu'à 5 % de code d'apprentissage automatique pour 95 % de code de support du système.

Le model serving se situe directement au sein de cette architecture de production. Il ne s'agit pas seulement d'exposer un modèle via un point de terminaison. C'est la couche d'exécution qui maintient les prédictions disponibles, fiables et gouvernées à travers l'inférence en ligne, l'évaluation par lots et les flux de traitement en continu. En pratique, le model serving doit également gérer l'acheminement, la latence, la montée en charge, le versionnement, la cohérence des caractéristiques et la gouvernance, les préoccupations opérationnelles qui déterminent si un modèle peut soutenir de manière fiable des décisions en production.

Sans l'architecture de mise à disposition appropriée, les déploiements de modèles peuvent commencer à accumuler une infrastructure sur mesure. Les ingénieurs doivent alors gérer des points de terminaison distincts, des pipelines de caractéristiques, des registres, des identifiants, des systèmes de supervision et des environnements de calcul. Avec le temps, la chaîne de mise à disposition devient un lieu supplémentaire où les systèmes d'apprentissage automatique accumulent une dette opérationnelle.

Le model serving (ou mise en service des modèles) est la couche d'exécution qui rend un modèle entraîné disponible pour l'inférence en production. Elle reçoit les données de production, envoie ces données à la bonne version du modèle et renvoie la prédiction résultante à une application, un flux de travail ou un système en aval.

Un modèle déployé sans chaîne de mise à disposition fiable laisse une équipe avec des questions de production non résolues : comment les requêtes atteindront-elles le modèle ? Que se passe-t-il en cas de pic de demande ? Quelle version doit recevoir le trafic de production ? Comment le système effectuera-t-il un retour arrière si un modèle challenger sous-performe ? Où réside la logique des caractéristiques, et est-elle concordante entre l'entraînement et l'inférence ?

L'objectif du model serving est de répondre à ces questions, de rendre un modèle entraîné exploitable en production. Pour ce faire, la couche de mise à disposition prend en charge le travail opérationnel lié à l'inférence : acheminer les requêtes vers la bonne version du modèle, ajuster la capacité par montée en charge pour répondre à la demande, renvoyer les prédictions dans les délais de latence requis, et connecter le modèle aux données et à la logique de caractéristiques dont il a besoin au moment de l'exécution.

Pour les systèmes de production, la couche de mise à disposition doit également tenir compte des SLA de latence, des objectifs de débit et de l'efficacité d'exécution. Cela peut impliquer de réduire les temps de démarrage à froid afin qu'un modèle puisse répondre rapidement après une période d'inactivité, de maintenir des pools de calcul préchauffés disponibles pour les charges de travail à haute priorité, ou de prendre en charge la mise à disposition multi-modèles lorsque plusieurs modèles ou versions partagent la même infrastructure.

Le déploiement de modèles et le model serving sont étroitement liés, mais ils décrivent différentes parties du cycle de vie de production.

• Le déploiement de modèles est l'action de déplacer un modèle entraîné vers un environnement de production. Cela peut impliquer d'empaqueter le modèle, de l'enregistrer, de l'approuver pour la mise en production et de le rendre disponible pour une application ou un flux de travail d'évaluation.
• Le model serving est l'infrastructure d'exécution qui maintient le modèle disponible après le déploiement.

En ce sens, le déploiement est une transition. Le model serving est le modèle d'exploitation qui suit.

Le bon mode de mise en service dépend de la façon dont les prédictions sont consommées. Certaines charges de travail nécessitent des réponses à faible latence pour des requêtes individuelles. D'autres nécessitent une évaluation à haut débit sur de grands jeux de données. Dans certaines applications, la couche de mise à disposition consomme un flux continu d'événements ; dans d'autres, le modèle s'exécute sur un appareil ou en périphérie du réseau.

L'inférence en ligne est le mode le plus souvent associé à un point de terminaison de modèle. Une application envoie une requête, généralement via REST ou gRPC, et le modèle renvoie une prédiction suffisamment rapidement pour l'utilisateur ou le système qui attend la réponse. La détection de fraude, la recommandation, la personnalisation et le classement des résultats de recherche utilisent couramment cette approche, car la prédiction influe sur une décision immédiate.

L’évaluation par lots fonctionne différemment. Au lieu de répondre à une requête à la fois, le modèle exécute l'inférence sur un jeu de données selon une planification. Par exemple, un modèle d'attrition client peut évaluer les comptes chaque nuit, ou un modèle de prévision de la demande peut actualiser ses projections chaque matin. Étant donné qu'aucun utilisateur n'attend de réponse, le débit et la rentabilité importent généralement plus qu'une latence inférieure à la seconde.

Avec l'inférence en flux, le modèle consomme les événements d'un flux et renvoie des prédictions à mesure que de nouvelles données arrivent. Un modèle de détection d'anomalies IoT, par exemple, peut évaluer les mesures des capteurs au fur et à mesure de leur arrivée plutôt que d'attendre une tâche par lots nocturne.

Le déploiement en périphérie rapproche le modèle de la source de l'activité. Lorsqu'un appareil doit fonctionner hors ligne, éviter la latence d'aller-retour ou conserver les données localement, la mise à disposition depuis un point de terminaison centralisé est mal adaptée. Dans ces cas, le modèle s'exécute sur l'appareil ou en périphérie du réseau, avec un processus distinct pour l'empaquetage, la distribution, les mises à jour et la supervision.

Ces modes coexistent souvent. Une entreprise peut utiliser l'évaluation par lots pour une segmentation client à grande échelle, l'inférence en ligne pour des offres en temps réel et l'inférence en continu pour des alertes opérationnelles. Le choix de l'architecture de mise en service est important car chacune comporte une combinaison différente d'exigences en matière de latence, de calcul, de gouvernance et d'opérations.

L'un des problèmes de mise en service les plus difficiles commence avant même que le modèle ne soit confronté au trafic de production. Le décalage entre l'entraînement et la mise en service se produit lorsque la logique de caractéristique utilisée pendant l'entraînement diffère de la logique appliquée pendant l'inférence. Le modèle a été évalué sur une représentation des données, puis mis en service avec une autre. Le point de terminaison continue de répondre comme si le modèle recevait le même type de données que celles observées durant l'entraînement. La prédiction, cependant, est produite à partir d'entrées que le modèle n'a jamais été entraîné à comprendre.

Le document Rules of Machine Learning de Google identifie le décalage entraînement/mise à disposition comme un véritable problème de production, incluant les écarts entre les pipelines d'entraînement et de mise à disposition, les changements de données entre l'entraînement et la mise à disposition, ainsi que les boucles de rétroaction introduites par le système lui-même. La recommandation est sans détour : mesurez le décalage afin que les changements de système et de données ne l'introduisent pas de manière imperceptible.

Dans de nombreuses piles technologiques, la cause profonde est architecturale. L'entraînement utilise souvent un pipeline par lots, tandis que la mise à disposition utilise souvent un pipeline en temps réel. Des équipes différentes les maintiennent, et un code différent exprime les transformations de caractéristiques. Avec le temps, même de petits changements créent une dérive entre l'environnement de développement de modèles hors ligne et le chemin d'inférence en ligne.

Un feature store résout cette scission en rendant la logique de caractéristiques réutilisable entre l'entraînement et l'inférence. Plutôt que de définir une version d'une caractéristique dans un pipeline d'entraînement et une autre dans une application de mise à disposition, les équipes définissent la caractéristique une seule fois et l'utilisent dans les deux contextes.

Pour le model serving, il s'agit de bien plus qu'une simple question de data engineering. La cohérence des caractéristiques déterminera si la couche de mise à disposition renvoie des prédictions provenant du modèle que l'équipe a évalué, ou d'une variation accidentelle créée par le pipeline de production.

Une fois qu'un modèle est prêt pour la production, la couche de mise à disposition doit savoir quelle version utiliser, d'où elle provient et dans quelles conditions elle doit être promue ou faire l'objet d'un retour arrière.

Un registre de modèles fournit ce point de contrôle. Il stocke les artefacts de modèles entraînés ainsi que l'historique des versions, les métriques d'évaluation, le statut de déploiement et le lignage. Plutôt que de traiter les modèles comme de simples fichiers copiés en production, le registre les traite comme des actifs gouvernés disposant d'états de cycle de vie définis.

Cette distinction compte lorsque plusieurs versions sont actives ou éligibles à la mise en production. Un modèle peut d'abord être enregistré, passer en préproduction après validation, puis n'avancer en production qu'une fois qu'il atteint les seuils d'exactitude, de latence, d'équité ou de coût. Ces portes de promotion rendent le déploiement moins dépendant d'un transfert manuel et davantage dépendant de politiques définies.

Le lignage ajoute une autre couche de contrôle. Pour une version de modèle déployée, le registre doit indiquer quelles données d'entraînement, quel code, quels paramètres et quels résultats d'évaluation l'ont produite. Lorsque les performances évoluent, qu'une demande d'audit arrive ou qu'un retour arrière devient nécessaire, cet historique devient opérationnellement utile plutôt que simplement administratif.

Le registre prend également en charge les schémas de mise en service champion-challenger. Un modèle en production peut continuer à traiter la majorité du trafic tandis qu'un modèle challenger en reçoit une part plus restreinte. Si le challenger est plus performant, le trafic peut changer. S'il sous-performe, le retour arrière est simple, car la couche de mise à disposition est connectée au versionnement et à l'état de déploiement.

Les grands modèles de langage (LLM) ajoutent un ensemble différent de contraintes de mise en service. L'idée de base reste l'inférence : le modèle reçoit une entrée et renvoie une sortie. Les mécanismes d'exécution, cependant, diffèrent de manière importante de la mise à disposition traditionnelle des modèles de ML.

Une couche de mise à disposition pour LLM doit tenir compte du débit de tokens, de la longueur du contexte, de la mémoire GPU, des stratégies de traitement par lots, de la gestion du cache KV et du comportement de décodage. Dans les applications à grand volume, la performance dépend de l'efficacité avec laquelle le système planifie les requêtes et réutilise les calculs. Des techniques telles que le décodage spéculatif, le traitement par lots continu et la quantification de modèles existent parce que la mise à disposition de grands modèles à un coût et une latence exploitables constitue autant un problème de systèmes qu'un problème de modélisation.

Les nouvelles piles de mise en service de LLM se concentrent de plus en plus sur l'optimisation de l'inférence : comment utiliser efficacement la mémoire GPU, planifier les requêtes, réutiliser les calculs mis en cache et améliorer le débit sans que la latence ou le coût ne dépassent les limites de production.

Le contrôle de version des prompts fait également partie de la discipline de mise en service. Dans le ML traditionnel, modifier le comportement d'un modèle implique généralement un réentraînement, un fine-tuning ou un changement de version de modèle. Dans les applications LLM, un changement de prompt peut modifier le comportement sans modifier les poids du modèle. Les prompts, les instructions système et les modèles de récupération doivent donc faire l'objet de pratiques de versionnement, de test et de retour arrière similaires à celles des autres artefacts de production.

Les pipelines RAG rendent le chemin de mise en service encore plus complexe. Une requête utilisateur peut déclencher une récupération depuis un index vectoriel, un assemblage du contexte, une génération par le modèle et une évaluation de la sortie avant qu'une réponse n'atteigne l'application. Si la récupération et la génération sont trop éloignées l'une de l'autre, sur le plan opérationnel ou physique, la latence augmente. Si la logique de récupération change sans versionnement, le comportement de sortie change même lorsque le modèle reste identique.

Les modèles fine-tunés et à base d'adaptateurs ajoutent une couche supplémentaire. Avec la mise à disposition par LoRA, plusieurs adaptateurs spécifiques à une tâche peuvent s'exécuter sur un modèle de base partagé, ce qui permet aux équipes de prendre en charge un comportement spécialisé sans avoir à charger un modèle complet distinct pour chaque cas d'usage. La quantification, par exemple en INT4 ou INT8, réduit les besoins en mémoire et en calcul, rendant les modèles plus volumineux plus pratiques à mettre à disposition sous contraintes de coût et de latence.

Pour le LLMOps, la mise à disposition n'est plus une simple question de point de terminaison. Elle englobe la gestion des prompts, l'architecture de récupération, l'efficacité GPU, l'évaluation à l'exécution et la gestion des variantes de modèles. Considérer le déploiement des LLM comme une version plus vaste d'un flux de travail scikit-learn revient à ignorer les primitives de mise à disposition qui permettent aux applications d'IA générative de fonctionner en production.

Les piles MLOps traditionnelles répartissent souvent les responsabilités de mise à disposition entre plusieurs systèmes. Une équipe peut utiliser un outil pour le registre de modèles, un autre pour la mise à disposition, un autre encore pour la supervision, et un environnement Kubernetes distinct pour le calcul. Chaque système apporte ses propres identifiants, sa propre configuration, ses propres contrôles d'accès et ses propres pratiques opérationnelles.

Cette organisation peut fonctionner, mais elle ajoute généralement de la surface opérationnelle et de la complexité. Le modèle entraîné ne devient alors qu'un composant parmi d'autres dans un environnement de mise à disposition plus vaste, que les ingénieurs doivent assembler et maintenir. Dans les termes de l'article sur la dette technique cité précédemment, le risque est davantage de code de liaison : plus de connecteurs, plus de logique dupliquée, plus de chemins de configuration et plus d'endroits où le comportement en production peut diverger des hypothèses de développement.

L'approche de Snowflake prend en charge les flux de travail IA/ML de bout en bout en réunissant le registre de modèles, le feature store, les pools de calcul GPU avec Snowpark Container Services, l'inférence batch et en ligne, et la surveillance des modèles dans une seule plateforme gouvernée. Cela peut réduire le besoin d'assembler des outils distincts pour le registre, la mise à disposition et la supervision, permettant aux ingénieurs de travailler directement en Python et en SQL pour les flux de travail pris en charge.

Grâce aux pools de calcul GPU de Snowpark Container Services, les équipes peuvent utiliser des conteneurs personnalisés pour l'inférence accélérée par GPU sans avoir à déplacer des données gouvernées hors de Snowflake pour de nombreux flux de travail d'inférence pris en charge, ni à gérer un environnement Kubernetes distinct. Ces charges de travail peuvent s'exécuter au sein de l'environnement gouverné de Snowflake, en utilisant des contrôles d'accès basés sur les rôles pour la gestion des accès.

Pour l'inférence par lots, les équipes peuvent appeler un modèle enregistré depuis un DataFrame Snowpark avec une configuration de mise à disposition minimale. Pour l'inférence en ligne, les équipes peuvent déployer des modèles via des points de terminaison REST SPCS.

Le résultat est une chaîne de mise à disposition plus épurée.ropre. Les ingénieurs continuent de choisir l'approche adaptée à la charge de travail, d'ajuster les performances et de gérer les versions des modèles. Ils passent moins de temps à assembler une infrastructure qui n'existe que pour déplacer des données et des prédictions entre des systèmes déconnectés.

Le model serving fait entrer les modèles entraînés dans la réalité opérationnelle des systèmes de production. Il détermine comment les prédictions sont demandées, où le calcul s'exécute, quelle version répond, comment les caractéristiques sont appliquées, et si les exigences de latence, de coût et de gouvernance sont respectées sous des charges de travail réelles.

Une couche de model serving solide maintient ces éléments plus étroitement liés. L'inférence en ligne, l'évaluation par lots, les flux de traitement en continu et le déploiement en périphérie imposent chacun des exigences différentes, mais le besoin sous-jacent reste le même : un chemin de production qui relie les modèles, les données, les caractéristiques, le calcul et la gouvernance, sans transformer chaque déploiement en projet d'infrastructure sur mesure.

En Europe, le règlement sur l'intelligence artificielle (EU AI Act) impose des obligations spécifiques pour les systèmes d'IA à haut risque déployés en production, notamment en matière de traçabilité, de supervision humaine et de documentation technique (art. 9, 15 et 72). En parallèle, l'article 22 du Règlement Général sur la Protection des Données (RGPD) encadre les décisions fondées exclusivement sur un traitement automatisé, y compris le profilage. En France, la Commission Nationale de l'Informatique et des Libertés (CNIL) veille au respect de ces dispositions.

La couche de model serving joue un rôle central dans le respect de ces exigences : c'est elle qui assure le versionnement des modèles, le lignage des prédictions et la gouvernance des accès en conditions réelles. Pour les organisations traitant des données sensibles, la qualification SecNumCloud, délivrée par l'Agence Nationale de la Sécurité des Systèmes d'Information (ANSSI), constitue un critère de confiance supplémentaire pour les infrastructures cloud hébergeant des systèmes d'inférence.