Infrastructure IA : MLOps et déploiement de modèles en production

Le gap entre PoC et Production

87% des modèles ML ne passent jamais en production. Le problème n'est pas le modèle — c'est l'infrastructure. MLOps est la discipline qui applique les pratiques DevOps au machine learning : CI/CD pour les modèles, versioning des données, monitoring de la drift, et orchestration des pipelines d'entraînement.

Pipeline MLOps

Un pipeline MLOps mature automatise tout le cycle de vie du modèle.

Data Collection → Feature Engineering → Training → Evaluation
       │                                                    │
       ▼                                                    ▼
  Data Versioning                                    Model Registry
  (DVC, LakeFS)                                    (MLflow, Weights&Biases)
                                                         │
                                                         ▼
                                                   Model Serving
                                                (TorchServe, Triton, vLLM)
                                                         │
                                                         ▼
                                                    Monitoring
                                              (data drift, latence, accuracy)

Model Serving en production

Le serving est le moment critique : le modèle reçoit des requêtes en temps réel et doit répondre en millisecondes. Les contraintes sont différentes de l'entraînement — optimisation de la latence, batching des requêtes, gestion de la mémoire GPU.

• vLLM : serving optimisé pour les LLMs avec PagedAttention, throughput 24x supérieur à HuggingFace
• NVIDIA Triton : serving multi-framework (PyTorch, TensorFlow, ONNX) avec batching dynamique
• TorchServe : serving PyTorch natif avec auto-scaling et logging
• Quantization : réduire la précision (FP32 → INT8) pour 2-4x plus de throughput avec <1% de perte de qualité

GPU Management avec Kubernetes

Les GPUs sont chères et rares. Les partager efficacement entre les workloads est un défi. Kubernetes avec le NVIDIA GPU Operator permet de scheduler des pods sur des nœuds GPU, mais le partage d'un GPU entre plusieurs pods (MIG, time-slicing) reste complexe.

• NVIDIA MIG (Multi-Instance GPU) : partitionner un A100 en 7 instances indépendantes
• Time-slicing : partager un GPU en alternant les workloads, simple mais moins isolé
• Spot instances : utiliser les GPUs spot AWS/GCP pour l'entraînement (70% moins cher, interruptible)
• Serverless GPU : Modal, RunPod, Lambda Labs — pay-per-second pour l'inférence