Model Serving
Le Model Serving est la couche d'infrastructure qui déploie un modèle ML entraîné pour traiter les demandes de prédiction en temps réel ou par batch, gérant la mise à l'échelle, l'équilibrage de charge, le versioning et la fiabilité en production. Il comble l'écart entre un artefact de modèle entraîné hors ligne et un endpoint API en direct et interrogeable.
Le Model Serving englobe le matériel, le logiciel et les processus opérationnels nécessaires pour exposer la capacité d'inférence d'un modèle entraîné comme un service fiable et scalable. Les composants fondamentaux sont le serving runtime (le processus qui charge les poids et exécute les passages avant), la couche API (endpoints HTTP/REST ou gRPC), une queue de demandes et un planificateur, la logique d'autoscaling, et un registre de modèles pour le versioning et le rollback. Pour les LLM, le serving runtime gère également le KV cache — les clés d'attention stockées et les valeurs pour les séquences en cours — qui peut consommer la majorité de la mémoire GPU.
Un artefact de modèle est chargé sur les accélérateurs par un serving runtime tel que NVIDIA Triton Inference Server, TensorRT-LLM, vLLM, ou la stack propriétaire d'un fournisseur. Le runtime gère le batching, l'allocation mémoire et l'exécution des kernels. Une passerelle API en avant route le trafic, applique les limites de débit et authentifie les demandes. Kubernetes ou une orchestration équivalente gère la mise à l'échelle horizontale — lancer des réplicas supplémentaires sous charge et les arrêter quand le trafic diminue — et gère les mises à jour progressives quand une nouvelle version de modèle est déployée sans downtime. L'observabilité (percentiles de latence, taux d'erreur, utilisation GPU, profondeur de queue) alimente les décisions d'autoscaling et les alertes.
Le serving est souvent le centre de coûts dominant pour un produit AI en production relativement aux coûts d'entraînement amortis sur la durée de vie du produit. Les décisions sur la sélection du matériel, la profondeur de quantification, la stratégie de batching, le facteur de réplication et si on utilise des instances spot ou à la demande déterminent directement les coûts opérationnels et les SLA de latence. Un modèle qui ne peut pas être servi de manière fiable et économique à l'échelle n'a aucune valeur pratique de produit indépendamment de sa performance de benchmark.
Depuis 2026, le paysage inclut les plateformes générales de ML serving en cloud (AWS SageMaker, Google Vertex AI, Azure ML), les runtimes open-source spécialisés LLM (vLLM, Ollama, LMDeploy) et les APIs propriétaires complètement gérées (OpenAI, Anthropic Claude API, Google Gemini API). Le multi-LoRA serving — héberger un seul modèle de base avec des centaines de couches d'adaptateur fine-tuned échangées par demande — a mûri, permettant aux entreprises de servir de nombreuses variantes spécialisées au coût matériel d'un déploiement de base.