RunPod explique comment déployer Stable Diffusion A1111 en API serverless

RunPod a publié sur son blog un tutoriel vidéo du studio generativelabs.co consacré au déploiement de Stable Diffusion A1111 en API sur la plateforme RunPod Serverless. Il ne s'agit ni d'une sortie ni d'un nouveau produit : c'est un guide pratique. Le sujet n'en est pas moins recherché, car de nombreux petits services de génération d'images reposent sur ce schéma. Tant qu'aucun worker n'est actif, le GPU n'est pas occupé et la facture n'augmente pas.

Ce que montre le tutoriel

A1111, c'est-à-dire AUTOMATIC1111 Stable Diffusion web UI, reste l'une des interfaces les plus répandues pour exécuter Stable Diffusion. Elle dispose aussi d'un mode programmatique : lancée avec l'option `--api`, elle expose des endpoints HTTP comme `/sdapi/v1/txt2img`. C'est ce mode qui transforme une interface web pour passionnés en backend auquel on peut connecter une application, un bot ou un outil interne.

RunPod Serverless ajoute à cela une couche d'orchestration. Vous empaquetez l'environnement dans une image Docker, vous créez un endpoint, et la plateforme se charge de lancer les workers sur GPU, de placer les requêtes en file d'attente et d'éteindre les workers lorsqu'il n'y a plus de travail. Les auteurs du tutoriel détaillent ce parcours étape par étape. La note d'origine de RunPod ne donne presque aucun détail : ni cartes graphiques précises, ni tarifs, ni mesures de latence. Ces paramètres, il faudra les établir soi-même.

Les composants du dispositif

• Image : un conteneur Docker avec A1111, ses dépendances et un gestionnaire de requêtes pour RunPod.
• Endpoint : un point d'entrée doté d'une file d'attente. L'application envoie un JSON contenant le prompt et les paramètres de génération, et reçoit une image en retour.
• Workers : des instances GPU que la plateforme lance à mesure que les requêtes arrivent et arrête en cas d'inactivité.
• Modèles : les poids des checkpoints, LoRA et VAE sont soit intégrés à l'image, soit stockés sur un volume réseau.
• Facturation : au temps de fonctionnement des workers, et non à la durée calendaire de location d'une machine. Consultez les tarifs à jour sur le site de RunPod.

Où se trouvent les pièges

Le principal prix de l'approche serverless s'appelle le démarrage à froid. Si le worker était éteint, la première requête doit attendre le lancement du conteneur et le chargement des poids du modèle dans la mémoire du GPU. Avec Stable Diffusion et ses checkpoints de plusieurs gigaoctets, ce délai peut être sensible. Pour un chatbot ou un éditeur interactif, une telle latence est critique. Pour la génération en arrière-plan, les tâches par lots et les services recevant peu de requêtes, elle reste tolérable.

Il faut aussi arbitrer entre la taille de l'image et la flexibilité. Intégrer le modèle au conteneur rend le démarrage plus prévisible, mais alourdit l'image, et chaque changement de checkpoint impose de la reconstruire. Garder les modèles sur un volume réseau permet de les changer facilement, mais la lecture depuis ce volume allonge le temps de démarrage. Il n'existe pas de réponse universelle : tout dépend du nombre de modèles et de la fréquence des requêtes.

Un autre point concerne A1111 lui-même. C'est avant tout une interface pensée pour des humains, et non un serveur d'inférence de production. Les extensions, les versions et les dépendances peuvent entrer en conflit ; il vaut donc mieux figer les versions dans l'image. Pour les fortes charges, de nombreuses équipes passent ensuite à ComfyUI, à diffusers ou à leurs propres gestionnaires.

Par où commencer en pratique

Commencez par définir le profil de charge. Si les requêtes sont rares et irrégulières, le serverless permet une réelle économie par rapport à un GPU loué en continu. Si la charge est stable et élevée, une instance dédiée est généralement plus prévisible côté prix.

Construisez ensuite une image minimale avec un seul modèle et mesurez deux valeurs : le temps de démarrage à froid et le temps de génération d'une image. Ce n'est qu'après que vous pourrez ajouter des LoRA, des extensions et des checkpoints supplémentaires. Activez des limites sur le nombre de workers et sur la durée d'exécution d'une tâche, afin qu'une erreur dans le code client ne se transforme pas en facture inattendue. Et vérifiez les licences des modèles : l'usage commercial est loin d'être autorisé pour tous les poids disponibles sur les hubs publics.

Le tutoriel vidéo est utile comme point de départ pour qui veut obtenir une API fonctionnelle en une soirée. Mais les conclusions sur le coût et la vitesse devront s'appuyer sur vos propres mesures.