Comment marche un GPU serverless, et ce que vous payez vraiment
Ou : une carte graphique qui ne se réveille que lorsqu’on l’appelle, et qui facture aussi le temps de se lever.
La réponse courte : un GPU serverless est un point d’accès qui reçoit vos requêtes, les range dans une file d’attente et ne démarre une carte graphique que lorsqu’il y a du travail. Chez Runpod, ce worker est facturé à la seconde, de son démarrage à son arrêt complet : le chargement du modèle, le calcul, puis cinq secondes d’inactivité par défaut. Une RTX 4090 coûte ainsi 0,00031 $ la seconde, 1,10 $ de l’heure, et rien du tout quand aucune requête n’arrive. Ce que vous payez vraiment, c’est le temps de worker allumé, pas le temps de calcul. C’est la brique de base pour payer le GPU à l’appel, et son fonctionnement explique toute la facture.
Le mécanisme tient en quatre pièces. L’endpoint reçoit les requêtes sur une adresse HTTPS et renvoie un identifiant de job. La file d’attente garde les jobs jusqu’à ce qu’un worker soit libre. Le scaler décide quand démarrer un worker supplémentaire : par défaut, dès qu’une requête attend plus de quatre secondes. Enfin le worker, un conteneur Docker posé sur une carte graphique, exécute votre code Python, renvoie le résultat, puis s’arrête s’il ne reçoit rien d’autre pendant le délai d’inactivité. Le résultat reste disponible trente minutes.
La page des workers de Runpod décrit les états par lesquels passe un worker, et ce qui est facturé dans chacun. L’initialisation, c’est-à-dire le téléchargement de l’image et du code, n’est pas facturée. Le fonctionnement l’est, y compris le chargement du modèle en mémoire graphique. L’inactivité l’est aussi, jusqu’à l’arrêt. Un worker bridé faute de carte disponible, lui, ne coûte rien, mais il ne calcule pas non plus.
Pour qui : un développeur dont l’application appelle un modèle de façon irrégulière et qui veut payer zéro quand personne ne s’en sert.
À partir de : 0,00031 $ la seconde de RTX 4090, soit 1,10 $ de l’heure, 0,00034 $ pour une A40 de 48 Go, facturés du démarrage du worker à son arrêt.
Pour démarrer : ouvrir un compte Runpod, déployer un worker serverless, depuis le Hub ou une image Docker, et envoyer une première requête sur sa route asynchrone.
GPU serverless : ce que vous payez à la seconde, carte par carte
| Carte | Mémoire | Prix à la seconde | Prix à l’heure |
|---|---|---|---|
| RTX 4090 | 24 Go | 0,00031 $ | 1,10 $ |
| A40 ou RTX A6000 | 48 Go | 0,00034 $ | 1,22 $ |
| RTX 5090 | 32 Go | 0,00044 $ | 1,58 $ |
| L40S, L40 ou RTX 6000 Ada | 48 Go | 0,00049 $ | 1,75 $ |
| A100 | 80 Go | 0,00076 $ | 2,72 $ |
| H100 | 80 Go | 0,00133 $ | 4,79 $ |
| H200 | 141 Go | 0,00165 $ | 5,93 $ |
| B200 | 180 Go | 0,00240 $ | 8,64 $ |
Ces prix sont ceux des workers « flex », qui descendent à zéro, relevés sur la grille de Runpod le 27 septembre 2026. Les workers actifs, allumés en permanence pour supprimer le démarrage à froid, étaient affichés jusqu’au printemps 2026 avec une remise allant jusqu’à 30 %. Leur prix n’est plus publié : il se négocie désormais avec le service commercial, et ils sont facturés en continu, inactivité comprise.
Les réglages par défaut d’un endpoint neuf disent beaucoup de la façon dont Runpod voit le serverless. Trois workers au maximum. Cinq secondes d’inactivité avant l’arrêt. Dix minutes de calcul au plus par job, extensibles jusqu’à sept jours. Une requête de 10 Mo au plus sur la route asynchrone. Et au niveau du compte, cinq workers en tout tant que le solde reste sous 100 $, dix au-delà, jusqu’à soixante à partir de 900 $ chargés, avec un plafond de dépense de 80 $ de l’heure. Un endpoint oublié se réduit tout seul : deux workers au maximum après trois jours sans requête, zéro après sept.
Sur ce site, quatre endpoints tournent avec ces réglages presque inchangés, zéro worker minimum et cinq secondes d’inactivité : un pour la transcription, un pour la vidéo WAN 2.2, deux pour les images. Tout leur usage depuis mars 2026 tient en 13,74 $. Ce chiffre dit l’essentiel du modèle : quand le travail est ponctuel, le serverless coûte exactement ce qu’on utilise, plus le prix des réveils.
Si le réveil coûte plus cher que le calcul
Sur un appel isolé, le démarrage à froid pèse souvent plus que le calcul lui-même. Les leviers pour le raccourcir, dans l’ordre que recommande Runpod, sont dans réduire le démarrage d’un worker.
Si vous voulez déployer votre propre modèle
Le Hub propose des workers prêts à l’emploi, mais un modèle maison demande son propre conteneur. Le handler, le Dockerfile et le déploiement sont détaillés dans un worker GPU avec Docker.
Si le trafic arrive par pics
Trois workers par endpoint et cinq par compte, c’est vite court. Le nombre de workers à prévoir, et ce qu’il change à la facture, se calcule dans l’autoscaling des workers.