Ml Model Deployer

ML Model Deployer

Critères de décision — quelle stack choisir ?

Workflow en étapes

1. Préparer et sérialiser le modèle

Choisir le format selon le framework :

# scikit-learn → joblib (préféré à pickle)
import joblib
joblib.dump(model, "model.joblib")

# PyTorch → TorchScript (portable, pas besoin du code source)
scripted = torch.jit.script(model)
scripted.save("model.pt")

# TensorFlow → SavedModel
model.save("saved_model/")

# Convertir en ONNX (interopérabilité max)
import torch.onnx
torch.onnx.export(model, dummy_input, "model.onnx", opset_version=17)

Créer une model card minimale (YAML dans le registre) :

model_name: churn-predictor-v2
framework: scikit-learn 1.4.2
python: "3.11"
metrics:
  auc_roc: 0.887
  precision: 0.81
dataset_hash: sha256:abc123...
trained_at: 2026-05-10
known_limitations: "Biais sous-représentation < 25 ans"

2. Enregistrer dans le Model Registry

# MLflow — enregistrement depuis le training run
mlflow models register \
  --model-uri "runs:/RUN_ID/model" \
  --name "churn-predictor"

# Passer en Staging puis Production via API
mlflow models transition-version-stage \
  --name "churn-predictor" --version 3 --stage Production

Alternatives : W&B Artifacts (wandb.log_artifact), Azure ML Registry (az ml model create), SageMaker (create_model).

3. Containeriser de façon reproductible

FROM python:3.11-slim

WORKDIR /app
COPY requirements.txt .
RUN pip install --no-cache-dir -r requirements.txt

COPY model.joblib .
COPY app.py .

# Health check obligatoire
HEALTHCHECK --interval=30s --timeout=5s CMD curl -f http://localhost:8000/health || exit 1

EXPOSE 8000
CMD ["uvicorn", "app:app", "--host", "0.0.0.0", "--port", "8000"]

# Tagging sémantique : image = version du modèle
docker build -t myregistry/churn-predictor:v2.3.1 .
docker push myregistry/churn-predictor:v2.3.1

4. Exposer via FastAPI (serving custom)

from fastapi import FastAPI
from pydantic import BaseModel
import joblib, numpy as np

app = FastAPI()
model = joblib.load("model.joblib")

class PredictRequest(BaseModel):
    features: list[float]

@app.get("/health")
def health(): return {"status": "ok"}

@app.post("/predict")
def predict(req: PredictRequest):
    arr = np.array(req.features).reshape(1, -1)
    proba = model.predict_proba(arr)[0, 1]
    return {"churn_proba": round(float(proba), 4)}

Pour TorchServe ou Triton, exporter en TorchScript / ONNX puis déclarer le model config.

5. CI/CD ML — gates de qualité

# .github/workflows/ml-deploy.yml (extrait)
- name: Run model quality gate
  run: |
    python scripts/eval_gate.py \
      --model model.joblib \
      --min-auc 0.85 \
      --max-latency-ms 120

- name: Build & push image
  if: success()
  run: |
    docker build -t $IMAGE_TAG .
    docker push $IMAGE_TAG

- name: Deploy canary (5%)
  run: kubectl set image deployment/churn-api churn-api=$IMAGE_TAG

Gate minimal : AUC/F1 ≥ baseline − 1 %, latence p99 < seuil, fairness check sur sous-groupes sensibles.

6. Déploiement progressif (canary / shadow)

# Canary K8s — 5 % du trafic sur la nouvelle version
kubectl apply -f - <<EOF
apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
spec:
  http:
  - route:
    - destination: {host: churn-api, subset: v2}
      weight: 5
    - destination: {host: churn-api, subset: v1}
      weight: 95
EOF

Shadow mode : dupliquer le trafic vers le nouveau modèle sans retourner sa réponse aux clients — idéal pour valider avant tout impact.

7. Monitoring en production

Métriques à surveiller :

# Evidently — rapport drift hebdomadaire
from evidently.report import Report
from evidently.metric_preset import DataDriftPreset

report = Report(metrics=[DataDriftPreset()])
report.run(reference_data=ref_df, current_data=prod_df)
report.save_html("drift_report.html")

8. Rollback automatique

# Pseudo-code — watcher de métriques
if current_auc < baseline_auc * 0.97:
    mlflow.models.transition_version_stage(
        name="churn-predictor",
        version=current_version,
        stage="Archived"
    )
    mlflow.models.transition_version_stage(
        name="churn-predictor",
        version=previous_version,
        stage="Production"
    )
    alert("Rollback automatique déclenché — v{} → v{}".format(
        current_version, previous_version))

Anti-patterns / pièges

• Pickle sans version : un modèle pickle ne se recharge pas si la version scikit-learn change. Toujours épingler la version dans requirements.txt et préférer joblib ou ONNX.
• Pas de health check : un pod K8s sans /health peut router du trafic vers une instance cassée pendant des minutes.
• Monitoring absent au lancement : le data drift peut dégrader silencieusement le modèle pendant des semaines. Instrumenter avant le go-live.
• Feature store absent : différence entre features d'entraînement et features runtime (training-serving skew) = première cause de régression en production.
• Over-engineering dès le MVP : ne pas déployer Kubeflow + Feast + Seldon dès le premier modèle. Partir de FastAPI + MLflow, migrer quand le besoin est prouvé.
• Pas de reproductibilité du dataset : versionner le hash du dataset d'évaluation avec le modèle pour pouvoir rejouer les métriques à tout moment.
• Retraining sans gate : un retraining automatique sur données driftées sans quality gate peut dégrader le modèle en production en boucle.

Bonnes pratiques 2026

• ONNX comme format pivot entre frameworks (PyTorch → ONNX → TensorRT pour GPU).
• Model cards standardisées (Hugging Face format) pour auditabilité et conformité IA Act.
• Feature store (Feast, Tecton, Redis) pour éviter le training-serving skew dès que plusieurs modèles partagent des features.
• Quantization (INT8 / FP16) pour réduire la latence et les coûts GPU sans perte significative de qualité.
• LLM serving : vLLM ou TGI (Text Generation Inference) pour les modèles de langage ; ne pas utiliser un endpoint FastAPI naïf pour des LLM (pas de batching continu).