Serving : exposer un modèle en production

Les trois modes de serving

Le réflexe économique : si le batch suffit, prends le batch — pas de latence à tenir, pas de service à astreindre, un simple job. L'API temps réel est un choix qui se justifie, pas un défaut.

L'API de modèle : ton métier, trois pièges en plus

Un service d'inférence FastAPI ressemble à tes services — avec ces spécificités :

1. charger le modèle UNE fois au démarrage (lifespan/startup), jamais par requête — et prévoir le healthcheck « modèle chargé » séparé du « process vivant » (readiness vs liveness, tu connais) ;
2. valider les features en entrée (Pydantic) : le contrat de features est ton contrat d'API — un champ manquant silencieusement rempli de zéros fait des prédictions fausses sans erreur ;
3. versionner la route ou l'en-tête (/v2/predict ou header) : le modèle change de comportement à chaque version — tes clients doivent pouvoir s'accrocher.

Le serving LLM : une discipline à part

Servir un LLM efficacement est devenu un métier d'infrastructure, et vLLM en est le standard open-source :

• continuous batching : les requêtes rejoignent/quittent le batch à chaque token généré (pas d'attente de fin de batch) — débit ×3-10 ;
• PagedAttention : le KV-cache (leçon 7.2) géré comme la mémoire virtuelle d'un OS, par pages — fini la fragmentation VRAM ;
• les métriques à mettre sur ton dashboard : TTFT (time to first token), tokens/s, taux d'occupation KV-cache, requêtes préemptées.

Tu n'écriras probablement jamais ce moteur — ton job de MLE : le déployer, le dimensionner et le monitorer correctement, exactement tes compétences.