AI / MLOps

Cycle de vie d’un modèle ML

Données brutes
    ↓ feature engineering
Feature store
    ↓ entraînement
Modèle enregistré (Vertex AI Model Registry)
    ↓ validation (métriques + tests)
Endpoint de serving
    ↓ monitoring
Dérive détectée → réentraînement automatique

Vertex AI Pipelines

Les pipelines Vertex AI permettent d’orchestrer chaque étape de manière reproductible et traçable.

from kfp import dsl
from google.cloud import aiplatform

@dsl.component(base_image="python:3.11")
def train(dataset_uri: str, model_output: dsl.Output[dsl.Model]):
    # entraînement...
    pass

@dsl.pipeline(name="kertusia-training-pipeline")
def pipeline(dataset_uri: str):
    train_task = train(dataset_uri=dataset_uri)

Chaque exécution est versionnée et liée aux données d’entrée, garantissant la traçabilité complète.

Feature Store

Pour les projets avec plusieurs modèles consommant les mêmes features, Vertex AI Feature Store centralise le stockage et évite la duplication de calculs.

Principes clés :

• Point-in-time correctness — évite le data leakage lors de l’entraînement
• Serving en ligne (< 10ms p99) et batch pour l’entraînement
• Monitoring de dérive intégré

Monitoring de modèles

Un modèle déployé se dégrade naturellement (concept drift, data drift). Le monitoring surveille :

Signal	Outil	Seuil d’alerte
Data drift (features)	Evidently AI	PSI > 0.2
Concept drift (cible)	Vertex Monitoring	% erreur +15% vs baseline
Latence serving	Cloud Monitoring	p99 > SLA

Infrastructure GPU

Pour les entraînements intensifs, les options GCP :

• Vertex AI Training — managed, facturation à la minute, pas de gestion de cluster
• GKE + GPU nodes — plus de contrôle, amortissable sur des charges continues
• Cloud Run GPU (preview) — serving de modèles sans gestion de serveur

Pour les LLM, l’inférence sur des modèles open-source (Llama, Mistral) est souvent plus économique que les API propriétaires dès que le volume dépasse quelques millions de tokens/jour.