RunPod Serverless (2026) : tarifs réels et quand un pod l'emporte
Tarifs RunPod Serverless vérifiés par GPU (août 2026), pourquoi le démarrage du conteneur et l'idle timeout sont facturés en plus de l'exécution, et à partir de quel taux d'utilisation un pod classique revient moins cher.
RunPod Serverless ramène votre endpoint à zéro entre deux requêtes et facture à la seconde. Le chiffre que tout le monde reprend, $0.16/h, n’est pas un tarif serverless : c’est le plancher du catalogue de pods. Le worker serverless le moins cher coûte $0.58/h, et une A100 revient à $2.72/h.
L’écart compte, car le serverless coûte environ 1,5 à 2,8 fois le tarif du pod Secure Cloud à carte identique. Ce que vous achetez, c’est la mise à l’échelle jusqu’à zéro, et elle se paie.
Tarifs serverless par GPU
| GPU | VRAM | Serverless | Pod Secure Cloud | Facteur |
|---|---|---|---|---|
| A4000 / A4500 / RTX 4000 | 16 Go | $0.58 | — | — |
| L4 / A5000 / 3090 | 24 Go | $0.69 | $0.50 (3090) | 1,38× |
| RTX 4090 | 24 Go | $1.10 | $0.69 | 1,59× |
| RTX PRO 4500 Blackwell | 32 Go | $1.15 | — | — |
| A6000 / A40 | 48 Go | $1.22 | $0.44 (A40) | 2,77× |
| RTX 5090 | 32 Go | $1.58 | — | — |
| L40 / L40S / 6000 Ada | 48 Go | $1.75 | $0.99 (L40S) | 1,77× |
| A100 | 80 Go | $2.72 | $1.49 (SXM) | 1,83× |
| RTX 6000 Pro | 96 Go | $3.49 | — | — |
| H100 | 80 Go | $4.55 | $2.99 (SXM) | 1,52× |
| H200 | 140 Go | $5.93 | — | — |
| B200 | 180 Go | $8.64 | — | — |
| B300 | 280 Go | $9.98 | — | — |
Tarifs serverless vérifiés sur runpod.io/pricing le 3 août 2026, tarifs des pods sur la même page le 31 juillet 2026.
Le seuil de rentabilité est un taux d’utilisation, pas un prix
Un pod facture en continu, que les requêtes arrivent ou non. Le serverless ne facture que tant qu’un worker tourne. La question n’est donc jamais de savoir lequel coûte le moins cher à l’heure, duel que le serverless perd systématiquement, mais quelle part de la journée votre endpoint travaille réellement.
Divisez 1 par le facteur du tableau et vous obtenez le taux d’utilisation où les deux reviennent au même :
- A40 48 Go à 2,77× : le pod l’emporte au-delà de 36 % d’utilisation
- RTX 4090 à 1,59× : au-delà de 63 %
- A100 80 Go à 1,83× : au-delà de 55 %
- H100 80 Go à 1,52× : au-delà de 66 %
Un endpoint qui sert du trafic aux heures de bureau se situe par définition autour de 33 %, et c’est précisément pourquoi le serverless lui convient. Un traitement par lots qui sature le GPU six heures par nuit tourne à 25 % et convient tout autant. Tout ce qui répond à un trafic de production constant, à toute heure, relève du pod, et l’A40 est la carte où la bascule arrive le plus tôt.
La facturation dépasse largement l’exécution
C’est le point qui surprend à la lecture de la première facture. RunPod facture du démarrage du worker jusqu’à son arrêt complet, arrondi à la seconde, sur trois phases : démarrage du conteneur, exécution de la requête, puis l’idle timeout qui suit. Par défaut, cette fenêtre dure cinq secondes.
Faites le calcul sur une requête courte. Une A100 à $2.72/h revient à $0.000756 la seconde. Une inférence de 400 ms ne vous coûte pas 400 ms :
- Exécution seule : 0,4 s × $0.000756 = $0.0003
- Exécution plus la fenêtre d’inactivité de 5 s : 5,4 s × $0.000756 = $0.0041
Vous payez donc environ 13,5 fois le temps de calcul, et ce avant tout démarrage à froid. Deux leviers corrigent cela. Regroupez davantage de travail dans chaque requête pour que l’exécution pèse plus lourd que la traîne d’inactivité, ou réduisez l’idle timeout, sachant qu’un timeout plus court augmente le risque que la requête suivante paie un démarrage à froid. FlashBoot sert justement à adoucir cet arbitrage en gardant au chaud les workers récemment utilisés.
Workers flex et actifs
Les workers flex descendent à zéro et correspondent aux tarifs ci-dessus. Les workers actifs tournent 24h/24 et ne démarrent jamais à froid ; RunPod annonce jusqu’à 40 % de remise sur ces derniers, le montant exact se négociant auprès du service commercial plutôt qu’affiché sur la page tarifaire.
Un worker actif reste un pod assorti d’étapes supplémentaires, sauf si vous avez réellement besoin du routage de requêtes du serverless. Si la machine tourne de toute façon en continu, comparez d’abord avec un pod Secure Cloud.
Déployer un endpoint
RunPod récupère votre image depuis un registre que vous contrôlez. Il n’existe pas de registre hébergé par RunPod vers lequel pousser, ce qui fait trébucher les tutoriels un peu anciens.
- Construisez un conteneur exposant un handler, pas un serveur web. Le SDK Python de RunPod enveloppe votre fonction d’inférence : ni FastAPI ni Flask ne sont nécessaires, et une application Node/Express n’a tout simplement pas la bonne forme ici.
- Poussez vers Docker Hub ou GHCR, en public ou avec des identifiants fournis à RunPod.
- Créez l’endpoint, pointez-le sur le tag de l’image et choisissez des classes de GPU. En sélectionner plusieurs permet au planificateur de se rabattre ailleurs quand votre premier choix manque.
- Fixez les bornes de workers et l’idle timeout. Le nombre maximal de workers plafonne la dépense ; l’idle timeout est le levier de la section précédente.
- Intégrez les poids du modèle à l’image ou à un volume réseau. Télécharger un checkpoint de 14 Go à chaque démarrage à froid est la raison la plus fréquente pour laquelle un endpoint bon marché devient coûteux.
Pour tester, curl sur la route /runsync suffit pour les tâches courtes, et /run pour tout ce qui dépasse le délai d’attente de la requête.
FAQ
RunPod Serverless coûte-t-il $0.16 de l’heure ?
Non. Ce chiffre correspond au pod le moins cher du catalogue, pas à un worker serverless. Le serverless démarre à $0.58/h pour la classe 16 Go et grimpe à $9.98/h pour une B300. Les comparatifs qui opposent $0.16/h à d’autres plateformes serverless confrontent deux produits différents.
Pourquoi ma facture dépasse-t-elle le temps d’inférence mesuré ?
Parce que l’exécution n’est qu’une des trois phases facturées. Vous payez aussi le démarrage du conteneur et l’idle timeout après chaque requête, cinq secondes par défaut. Sur des inférences inférieures à la seconde, cette fenêtre d’inactivité peut coûter un ordre de grandeur de plus que le travail lui-même.
Quand faut-il préférer un pod ?
Au-delà d’environ 55 à 65 % d’utilisation pour la plupart des cartes de datacenter, et dès 36 % pour une A40. Estimez la fraction de la journée pendant laquelle votre endpoint calcule vraiment, puis confrontez-la aux facteurs du tableau. Un trafic constant à toute heure relève du pod.
Ai-je besoin d’un framework web dans le conteneur ?
Non. Le modèle de handler attend une fonction qui reçoit une charge de travail et renvoie un résultat ; RunPod gère autour le HTTP, la file d’attente et la mise à l’échelle. Ajouter Flask ou FastAPI dans le worker duplique une infrastructure que vous payez déjà.
Pour le détail des tarifs des pods sous-jacents, voyez le comparatif RunPod Community vs Secure Cloud, et pour l’ensemble du marché le comparatif général des GPU cloud.