Encaisser le trafic sur une API LLM
Quand une API qui appelle un LLM passe de dix requêtes à dix mille, elle tombe si l'architecture n'a pas été pensée pour ça. Sept briques reviennent toujours : une passerelle d'API (point d'entrée unique qui gère l'authentification et la limitation), la limitation de débit (protège les endpoints d'inférence), le cache (ne pas rejouer deux fois la même requête d'embedding, ce serait brûler de l'argent), les files de messages (traiter les appels LLM en asynchrone, sans réponse instantanée), les disjoncteurs (un appel modèle qui échoue ne fait pas tomber tout le pipeline), l'autoscaling (ne pas payer du GPU au repos) et la répartition de charge (étaler le trafic sur les nœuds GPU).
Forces
- Chaque brique a une raison d'être unique : coût, panne, latence ou pic de charge, jamais « au cas où »
- Donne un vocabulaire pour parler dimensionnement avec l'infra sans tout réinventer à chaque incident
- Le cache et l'autoscaling seuls suffisent souvent à diviser la facture d'inférence par un facteur visible
Limites
- Tout brancher d'un coup produit un pipeline lourd et opaque : chaque brique ajoutée est un point de panne de plus
- Sujet d'infra avancée : sans une charge réelle qui fait mal, ces patterns restent théoriques et prématurés
Pour qui
- Devs qui mettent une fonctionnalité LLM en production et voient le trafic monter plus vite que prévu
- Leads techniques qui doivent arbitrer quelles briques de dimensionnement méritent le coût maintenant