Le contexte
Un éditeur SaaS d’IA générative permet à ses utilisateurs d’exécuter des modèles spécialisés, entraînés pour leur domaine. Le problème de ce type de produit est économique avant d’être technique : les GPU coûtent cher, la demande est très irrégulière, et une infrastructure dimensionnée pour le pic est intenable financièrement quand elle tourne à vide la nuit.
Il fallait absorber des rafales d’inférence, redescendre réellement quand la demande retombe, rester prévisible côté latence — et rendre exploitable la masse de résultats produits, qui se compte en millions d’images et n’a aucune valeur si elle n’est pas retrouvable.
Ce que nous avons fait
Nous avons développé la plateforme d’exécution et le plan de contrôle qui la dimensionne.
- Une réception de requêtes dimensionnée indépendamment des GPU. Les requêtes d’inférence arrivent par API Gateway et sont mises en file par Lambda : accepter le travail et l’exécuter ne suivent pas la même courbe. Une rafale qui arrive plus vite que la flotte ne peut grandir est absorbée par la file, au lieu d’être refusée à l’entrée.
- La capacité GPU en Spot, en priorité. C’est le seul levier qui change l’ordre de grandeur du coût sur ce type de charge. Le prix à payer est que la capacité peut être reprise à tout moment : l’interruption est traitée comme un événement normal du cycle de vie, pas comme une panne.
- Plusieurs groupes d’autoscaling plutôt qu’un seul. La capacité Spot n’est pas fongible : un type de GPU indisponible dans une zone ne dit rien de sa disponibilité ailleurs. Répartir la demande sur plusieurs groupes, par type de GPU et par zone, avec un groupe à la demande en secours, est ce qui rend le Spot tenable en production plutôt qu’opportuniste.
- Un dimensionnement recalculé toutes les 10 secondes. L’autoscaling managé raisonne en minutes et sur des métriques d’infrastructure ; or le besoin réel en GPU se déduit de métriques métier et applicatives — requêtes en attente, débit par modèle, profil des travaux en cours. La boucle calcule donc directement la capacité nécessaire, groupe par groupe, et ajuste.
- La gestion des modèles préchauffés. La même boucle décide combien d’exemplaires de chaque modèle rester prêts à servir, en fonction de la demande observée. C’est ce qui évite de payer un temps de chargement de modèle sur la requête d’un utilisateur, sans pour autant maintenir tout le catalogue en mémoire.
- L’indexation à grande échelle des résultats d’inférence, répartie entre S3 pour les artefacts, DynamoDB pour les métadonnées et OpenSearch pour l’index, avec un enrichissement automatique des contenus produits via Rekognition. L’indexation est sur le chemin d’inférence, pas dans un traitement par lots nocturne.
- La recherche KNN dans des millions d’images, sur des vecteurs produits par les modèles d’embedding servis depuis SageMaker et indexés dans OpenSearch.
Le résultat
L’éditeur ouvre son produit à davantage d’utilisateurs sans que la facture suive la même courbe, et la reprise d’une instance Spot ne se voit plus dans le service rendu. La masse de résultats accumulés est devenue un actif interrogeable au lieu d’un entrepôt de fichiers.
L’enseignement principal porte sur la boucle de dimensionnement. Nous avons commencé avec l’autoscaling managé, sur des métriques d’infrastructure : il arrive toujours trop tard, parce que le taux d’occupation d’un GPU décrit ce qui s’est déjà passé. Le besoin, lui, est connu en amont — il est écrit dans la file de travaux. Une boucle de dix secondes qui lit cette information vaut mieux qu’une politique managée qui l’ignore.
Le second enseignement est moins flatteur : le Spot n’apporte rien tant qu’on ne l’a pas assumé jusqu’au bout. Un seul groupe d’autoscaling en Spot, c’est un incident de production qui attend son heure.