Docker pour le ML

Tes Dockerfiles, en plus lourd

Tout ce que tu sais de Docker reste vrai. Les spécificités ML tiennent en trois points :

1. Les images sont énormes — et c'est (en partie) normal

Une image d'inférence typique : base CUDA (~3 Go) + PyTorch (~2 Go) + tes dépendances. Les réflexes qui sauvent :

• multi-stage : compiler/télécharger dans un stage, ne copier que le nécessaire ;
• ordre des layers : les dépendances (stables) avant le code (volatile) — tu le fais déjà ;
• les poids du modèle HORS de l'image : montés en volume ou téléchargés au démarrage depuis un object storage. Une image de 40 Go parce qu'elle embarque le modèle, c'est l'anti-pattern n°1 (chaque déploiement re-pousse tout, le registry pleure).

2. La chaîne CUDA : le « ça marche sur ma machine » du ML

Pour qu'un conteneur utilise le GPU, trois versions doivent s'accorder : driver NVIDIA de l'hôte ≥ version CUDA de l'image ≥ celle attendue par PyTorch. Le driver vit sur l'hôte, le runtime CUDA dans l'image : c'est le contrat de compatibilité à vérifier avant tout debug.

3. La reproductibilité est une exigence métier

En backend, une image reproductible c'est de l'hygiène. En ML, c'est une exigence réglementaire et scientifique : pouvoir réentraîner exactement le même modèle suppose de figer le code, les dépendances (lockfiles), l'image de base (digest, pas de :latest), les données (versionnées — on verra DVC) et même les seeds aléatoires.

Le pattern standard d'un service d'inférence

FROM nvidia/cuda:12.4.0-runtime-ubuntu22.04 AS base
RUN pip install --no-cache-dir torch==2.4.* vllm==0.6.*   # versions ÉPINGLÉES
COPY app/ ./app
# Le modèle n'est PAS ici : téléchargé au démarrage depuis S3/GCS,
# ou monté en volume — l'image reste déployable en minutes.
CMD ["python", "-m", "app.server"]