# Un worker qui démarre en trois secondes au lieu de quarante

> Modèles en cache, modèle intégré à l'image, volume réseau, FlashBoot et workers actifs : les leviers pour raccourcir le démarrage à froid d'un worker GPU serverless.


*Ou : l'art de réveiller une carte graphique sans lui faire relire toute sa bibliothèque.*

La réponse courte : un démarrage à froid se raccourcit surtout en changeant l'endroit où dort le modèle. Runpod recommande, dans l'ordre, ses modèles en cache, qui placent le worker sur une machine où le modèle est déjà présent, puis le modèle intégré à l'image Docker, et seulement en dernier le volume réseau, lu après le début de la facturation. S'y ajoutent FlashBoot, qui conserve l'état d'un worker récemment arrêté, et les workers actifs, qui suppriment le démarrage à froid en facturant chaque seconde. Un réveil de quarante secondes qui retombe à quelques secondes, c'est d'abord un modèle qu'on ne retélécharge plus. C'est le réglage le plus rentable de [l'architecture serverless sur GPU](/guides/gpu-cloud-ia/serverless-vs-pods-gpu/), parce qu'il réduit la facture et l'attente à la fois.

Un démarrage à froid se décompose en trois temps. Le téléchargement de l'image Docker et du code, que Runpod ne facture pas. Le chargement du modèle en mémoire graphique, facturé. Puis le premier calcul, facturé lui aussi, souvent plus lent que les suivants. Sur le pipeline de ce site, un worker faster-whisper a mis 9,3 secondes à démarrer pour 2,6 secondes de transcription : le réveil représentait presque quatre fois le travail utile.

Tout l'enjeu est donc de raccourcir la partie facturée, et elle dépend d'une question simple : où se trouvent les poids du modèle quand le worker démarre ? [La page des workers de Runpod](https://docs.runpod.io/serverless/workers/overview) y répond par un ordre de préférence explicite, repris ici levier par levier.

> **Pour qui** : un développeur dont l'endpoint serverless met plusieurs dizaines de secondes à répondre au premier appel, et qui paie ces secondes.
>
> **À partir de** : 0,00031 $ la seconde de RTX 4090 en serverless, chaque seconde de démarrage comprise, 0,07 $ par gigaoctet et par mois pour un volume réseau.
>
> **Pour démarrer** : ouvrir un compte Runpod, activer le modèle en cache de l'endpoint s'il vient de Hugging Face, sinon l'intégrer à l'image Docker.

## Cold start GPU : les cinq leviers, du plus efficace au plus cher

| Levier | Ce qu'il fait | Ce qu'il coûte | Limite |
|---|---|---|---|
| Modèle en cache | démarre le worker sur une machine qui a déjà le modèle | rien de plus, le téléchargement n'est pas facturé | un seul modèle par endpoint, Hugging Face uniquement |
| Modèle dans l'image Docker | le modèle est sur le disque de la machine avant le démarrage | une image plus lourde, plus longue à construire | image de 80 Go au plus via GitHub |
| FlashBoot | conserve l'état d'un worker arrêté pour le ranimer plus vite | rien de plus | efficace surtout avec un trafic régulier |
| Délai d'inactivité allongé | garde le worker chaud entre deux requêtes rapprochées | chaque seconde d'attente est facturée | ne sert à rien si les requêtes sont espacées |
| Workers actifs | au moins un worker toujours allumé, zéro démarrage à froid | facturé en continu, remise sur demande | le coût d'un pod, sans ses avantages |

Les modèles en cache sont le levier le plus récent et le plus efficace. [Leur documentation](https://docs.runpod.io/serverless/endpoints/model-caching) explique le principe : vous indiquez un modèle Hugging Face, public, soumis à conditions ou privé, et Runpod démarre vos workers en priorité sur des machines qui l'ont déjà. Sinon, le worker attend la fin du téléchargement, sans que ce temps soit facturé. Deux limites : un seul modèle en cache par endpoint, et toutes les quantifications du dépôt sont téléchargées.

Le modèle intégré à l'image est la solution classique pour tout ce qui ne vient pas de Hugging Face, ou pour un workflow ComfyUI qui combine plusieurs fichiers. L'image grossit, parfois de plusieurs dizaines de gigaoctets, mais elle est mise en cache sur les machines de Runpod, et le modèle est sur disque local avant même que la facturation commence. Le volume réseau, à l'inverse, se lit une fois le worker lancé et facturé, à 200 à 400 Mo par seconde selon Runpod : quarante gigaoctets de modèle, c'est entre une minute quarante et plus de trois minutes de lecture payée à chaque démarrage à froid. Runpod le réserve au développement et aux modèles de plus de 500 Go.

FlashBoot est activé par défaut sur les endpoints créés depuis la console. Il garde l'état d'un worker après son arrêt pour le ranimer plus vite qu'un démarrage complet, et Runpod le présente sur sa page commerciale comme capable de démarrages sous les 200 millisecondes. La documentation, plus prudente, ne donne aucun chiffre et précise qu'il est surtout efficace quand le trafic est régulier : un worker arrêté depuis longtemps n'a plus d'état à ranimer.

Restent deux leviers qui achètent la vitesse au lieu de la gagner. Allonger le délai d'inactivité, cinq secondes par défaut, garde le worker chaud entre deux requêtes rapprochées, mais chaque seconde d'attente se paie. Les workers actifs suppriment le problème, en facturant la carte en permanence. La documentation propose une formule pour les dimensionner : le nombre de requêtes par minute multiplié par la durée d'une requête en secondes, divisé par 60. Si le résultat approche d'un worker plein, un pod coûte souvent moins cher.

![Illustration : poêle de fonte dans un atelier sombre dont les braises rougeoient encore, une machine voisine prête à repartir dans la chaleur](/images/reduire-cold-start-worker-gpu-braises.original.webp "Un worker qu'on ranime sur ses braises repart plus vite qu'un worker qu'il faut rallumer à froid.")

### Si vous voulez intégrer le modèle à l'image

Un modèle intégré demande un Dockerfile propre, un handler et un déploiement qui supporte une image de plusieurs dizaines de gigaoctets. La marche à suivre est dans [construire son worker avec Docker](/guides/gpu-cloud-ia/serverless-vs-pods-gpu/worker-serverless-personnalise-docker/).

### Si vos modèles doivent rester sur un volume

Pour un modèle de développement ou plusieurs fichiers qui changent souvent, le volume réseau reste utile, à condition d'en connaître le prix et les contraintes, détaillés dans [les volumes réseau pour vos modèles](/guides/gpu-cloud-ia/serverless-vs-pods-gpu/stockage-persistant-volumes-reseau-modeles/).

### Si vous hésitez à payer des workers actifs

Un worker toujours allumé ressemble beaucoup à une machine louée. Le taux d'occupation à partir duquel un pod devient moins cher est calculé dans [quand louer la machine plutôt que le worker](/guides/gpu-cloud-ia/serverless-vs-pods-gpu/pod-instance-gpu-dediee-quand/).


---

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.