# Combien de workers GPU lancer, et ce que coûte le pic

> Scaler, plafond de workers par endpoint et par compte, limite de dépense : dimensionner un endpoint GPU serverless et chiffrer le coût d'un pic de trafic.


*Ou : pourquoi ajouter des caisses au supermarché ne change presque rien au prix des courses, mais tout à la longueur de la file.*

La réponse courte : en serverless, le nombre de workers change l'attente bien plus que la facture. Mille requêtes de dix secondes coûtent à peu près le même prix qu'elles passent sur un worker ou sur dix, puisque vous payez des secondes de carte. Ce qui change, c'est le délai : avec les trois workers par défaut d'un endpoint Runpod, un pic de soixante requêtes par minute laisse une file de plus de deux mille requêtes au bout d'une heure. Le bon nombre se calcule avec une formule simple, le nombre de requêtes par minute multiplié par leur durée en secondes, divisé par soixante. C'est le réglage qui décide si [payer le GPU à l'appel](/guides/gpu-cloud-ia/serverless-vs-pods-gpu/) tient la charge ou la fait attendre.

Deux mécanismes décident du nombre de workers qui tournent. Le scaler d'abord, qui démarre un worker supplémentaire selon une règle au choix. Par défaut, c'est le délai d'attente : un worker de plus dès qu'une requête attend plus de quatre secondes. L'autre règle, le nombre de requêtes, calcule directement les workers nécessaires en divisant les requêtes en file et en cours par une valeur fixée, et Runpod la recommande pour les modèles de langage et les requêtes courtes et fréquentes. Les plafonds ensuite, qui arrêtent le scaler quoi qu'il décide.

Ces plafonds sont trois, et [la page des workers de Runpod](https://docs.runpod.io/serverless/workers/overview) les détaille. Par endpoint, trois workers au maximum par défaut, avec deux workers supplémentaires possibles pendant un pic quand l'image est déjà en cache sur les machines. Par compte, un total qui dépend du solde. Et une limite de dépense de 80 $ de l'heure par défaut, qui plafonne le nombre de cartes simultanées bien avant les autres limites sur les cartes chères.

> **Pour qui** : un développeur dont l'application connaît des pics de trafic et qui veut savoir combien de workers GPU autoriser, et combien le pic coûtera.
>
> **À partir de** : 0,00031 $ la seconde de RTX 4090 en serverless, 0,00133 $ pour une H100, facturés par worker actif, rien pour les workers qui ne tournent pas.
>
> **Pour démarrer** : ouvrir un compte Runpod, charger le solde qui débloque le nombre de workers voulu, puis régler le plafond et le scaler de l'endpoint.

## Autoscaling GPU serverless : les plafonds, et le calcul d'un pic

| Solde du compte | Workers au maximum sur le compte |
|---|---|
| moins de 100 $ | 5 |
| 100 $ et plus | 10 |
| 200 $ et plus | 20 |
| 300 $ et plus | 30 |
| 500 $ et plus | 40 |
| 700 $ et plus | 50 |
| 900 $ et plus | 60 |

Prenons un cas concret : un endpoint de génération d'images sur RTX 4090, dix secondes par requête, et un pic de soixante requêtes par minute pendant une heure, soit 3 600 requêtes. La formule donne soixante fois dix divisé par soixante : dix workers pour suivre le rythme. Le coût du calcul, lui, vaut 36 000 secondes de carte, soit 11,16 $, quel que soit le nombre de workers. S'y ajoute un démarrage à froid par worker lancé, qui pèse d'autant plus que les workers sont nombreux.

Avec le plafond par défaut de trois workers, le calcul coûte la même chose, mais l'expérience n'a rien à voir. Trois workers traitent dix-huit requêtes par minute ; il en arrive soixante. La file grossit de quarante-deux requêtes par minute, atteint 2 520 requêtes au bout de l'heure, et il faut encore deux heures vingt pour la vider. La dernière requête du pic attend donc plus de deux heures, ce qui n'est acceptable que pour un traitement par lots. Pour dix workers, il faut aussi que le compte ait 100 $ de solde : sous ce seuil, le compte entier est limité à cinq.

La limite de dépense joue sur les cartes chères. Dix workers RTX 4090 coûtent 11 $ de l'heure, loin des 80 $ par défaut. Mais quinze workers H100 en coûtent 72 : au-delà de seize cartes H100 simultanées, la limite de dépense bloque le scaler avant même le plafond de workers. Elle se relève sur demande au support, et elle protège surtout d'un endpoint emballé par une boucle de requêtes mal écrite.

Trois réglages de plus méritent l'attention. Un endpoint peut accepter jusqu'à trois types de cartes par ordre de priorité ; sous cinq workers, tous partent sur la carte la mieux classée qui est disponible. Runpod conseille de fixer le plafond d'environ 20 % au-dessus de la concurrence maximale attendue. Et un worker peut traiter plusieurs requêtes à la fois, grâce à un modificateur de concurrence dans le handler, utile pour des requêtes courtes qui n'occupent pas toute la carte.

Sur ce site, les endpoints tournent avec le plafond de trois workers et le scaler par défaut : pour une production par lots, où personne n'attend devant un écran, c'est suffisant. [La page de configuration des endpoints](https://docs.runpod.io/serverless/endpoints/endpoint-configurations) décrit chacun de ces réglages.

![Illustration : longue rangée d'établis dans un atelier sombre, trois éclairés avec leur machine en marche, une douzaine d'autres éteints et prêts à servir](/images/autoscaling-workers-gpu-concurrence-etablis.original.webp "Allumer d'autres établis ne change presque pas ce que coûte le travail. Cela change seulement le temps passé à attendre.")

### Si chaque nouveau worker met trop longtemps à démarrer

Plus de workers, c'est plus de démarrages à froid pendant le pic. Les réglages qui les raccourcissent sont dans [un worker qui démarre en quelques secondes](/guides/gpu-cloud-ia/serverless-vs-pods-gpu/reduire-cold-start-worker-gpu/).

### Si votre charge est constante plutôt qu'en pics

Dix workers occupés toute la journée coûtent plus cher en serverless qu'en machines louées. Le seuil de bascule est calculé dans [les cas où le pod bat le serverless](/guides/gpu-cloud-ia/serverless-vs-pods-gpu/pod-instance-gpu-dediee-quand/).

### Si vos jobs attendent longtemps en file

Une file longue n'est grave que si les jobs expirent avant d'être traités. Durée de vie, conservation des résultats et webhooks sont détaillés dans [la file d'attente et les jobs longs](/guides/gpu-cloud-ia/serverless-vs-pods-gpu/file-attente-jobs-asynchrones-webhooks/).


---

Cette page contient des liens d'affiliation. Si tu souscris via ces liens, je peux toucher une commission sans coût supplémentaire pour toi. Mon avis reste indépendant et basé sur mon usage réel des outils que je recommande.


---

**Tarifs :** prix relevés le 27 septembre 2026 sur les sites officiels des fournisseurs, dans la devise qu'ils affichent : dollars américains pour les plateformes américaines, euros hors taxes pour les européennes. Les tarifs du GPU bougent souvent, et sur une place de marché chaque hôte fixe son prix : les montants cités peuvent avoir changé depuis cette date.