Déployer un LLM sur GPU serverless : 5 plateformes, vrais prix, démarrages à froid honnêtes

Déployer un LLM sur GPU serverless : 5 plateformes, vrais prix, démarrages à froid honnêtes

RunPod facture 2,72 $/h pour une A100 80GB. Votre endpoint reçoit douze requêtes avant midi. Le GPU reste inactif les 23 autres heures, et la facturation tourne pendant tout ce temps. Déployez un LLM sur GPU serverless et vous ne payez que lorsqu'une requête s'exécute. Cinq plateformes le font. Elles facturent dans cinq unités différentes. Personne ne les normalise.

Un GPU inactif coûte exactement le même prix qu'un GPU occupé.

Points clés

• Un GPU serverless ne facture que les requêtes en cours et retombe à zéro entre elles.
• Cloud Run limite à un GPU par instance ; les modèles 70B ont besoin de plusieurs GPU, donc le serverless ne peut généralement pas les héberger.
• Les poids du modèle vivent dans l'image, sur un volume réseau, ou sont retéléchargés à chaque démarrage à froid.
• Un démarrage à froid, c'est trois choses : boot du conteneur, chargement des poids, initialisation du moteur. Seul le premier est rapide.
• En dessous d'environ 47 000 requêtes par jour, le scale-to-zero coûte moins cher qu'un GPU loué 24/7.

Que signifie vraiment « GPU serverless » pour un LLM ?

Une plateforme de GPU serverless exécute votre conteneur d'inférence sur du matériel GPU partagé, le démarre quand une requête arrive et retombe à zéro quand le trafic s'arrête. Vous payez à la seconde (ou à la minute, ou à l'heure, selon le fournisseur) uniquement tant que le conteneur est actif. Pas de facture d'inactivité. Pas d'instance réservée.

L'unité de facturation varie selon les fournisseurs, c'est pourquoi la section suivante normalise tout en $/GPU-heure.

Deux contraintes surprennent. D'abord, Google Cloud Run autorise un seul GPU par instance, au maximum. Votre plafond de VRAM se limite donc à une seule carte. Ensuite, « serverless » ne veut pas dire état persistant. Aucun processus de longue durée ne conserve vos poids en RAM entre les requêtes. Quand le conteneur meurt, tout ce qui était en mémoire meurt avec lui. Ce seul fait commande la décision de stockage dans la section sur les poids du modèle ci-dessous.

Serverless ne veut pas dire sans serveur. Cela veut dire aucun serveur entre vos requêtes, et c'est exactement là que vos poids de modèle disparaissent.

Quelle plateforme GPU serverless choisir ? (prix 2026, côte à côte)

Nous ne vendons aucune de ces plateformes et ne touchons aucun revenu d'affiliation. Sur les sept articles en concurrence sur cette requête et ses variantes, quatre sont publiés par une entreprise qui vend du GPU serverless. Ce tableau, non.

Tous les tarifs sont relevés sur les pages tarifaires des fournisseurs eux-mêmes, le 30 juillet 2026. Les prix changent ; revérifiez avant de vous engager.

Le calcul de normalisation, montré une fois pour que vous puissiez le vérifier : l'A100 80GB de Modal à 0,000694 $/s multiplié par 3600 secondes donne 2,4984 $/h. Beam : 0,000625 fois 3600 donne 2,25 $/h. Baseten : 0,06667 $/min fois 60 donne 4,00 $/h. Cet écart de 1,8x entre Beam et Baseten pour la même A100 est réel, et il se cache en plein jour parce que personne ne publie la même unité.

Trois réserves. La page tarifaire de Beam indique explicitement qu'il ne facture ni le démarrage du serveur ni le chargement de l'image conteneur. La FAQ tarifaire de Baseten répond à « Do I pay for idle time on Baseten? » par « No, you do not pay for idle time », puis précise que le temps facturable est « the time your model is actively deploying, scaling up or down, or making predictions » ; le compteur couvre donc plus que le temps de prédiction, et c'est la partie à budgéter. RunPod publie des tarifs horaires et aucun chiffre de démarrage à froid sur sa page tarifaire.

Si Modal est votre choix, nous avons rédigé le guide Modal complet séparément.

Votre modèle tiendra-t-il ? VRAM, limite d'un GPU et quotas

Peut-on faire tourner un modèle 70B sur un GPU serverless ? En général, non. En FP16, un 70B demande environ 140 Go de VRAM. Cloud Run plafonne à un GPU par instance (96 Go max sur RTX PRO 6000). Le calcul ne passe pas sans quantification (FP8/GGUF) ni plateforme multi-GPU.

Le quota par défaut de Cloud Run est de 3 GPU L4 par région et par projet (la RTX PRO 6000 est accordée séparément, sous forme de 3 000 milliGPU), répartis sur six régions L4 : asia-southeast1, asia-south1, europe-west1, europe-west4, us-central1, us-east4. C'est la moitié Cloud Run de la réponse sur la résidence des données pour quiconque cherche un GPU serverless en Europe ; Modal et RunPod documentent leurs propres régions UE, et la FAQ contient le reste.

Le guide Cloud Run d'Ismaili Simba sur dev.to (avril 2025) rapporte que la demande de quota « can take some time (up to 5 working days) to be approved » et que « the L4 GPUs available on Cloud Run have a limit of 16GB RAM ». Prévoyez ce délai.

Pour dimensionner la VRAM modèle par modèle, consultez notre guide des besoins VRAM.

Où vivent les poids de votre modèle (et combien cela coûte-t-il) ?

Un fil Reddit de novembre 2024 qui figurait encore en 5e position sur Google pour cette requête exacte quand nous avons vérifié le 30 juillet 2026 demande, mot pour mot :

« I have been unable to find rate for storing the 80 gb model… What's an alternative if I don't want to download the model at every api calls (pod provisioned at call then closed)? … Why do these platforms not list model storage cost? »

Trois réponses à faible score, aucune ne répond. Quand nous avons lancé cette recherche le 30 juillet 2026, le top dix incluait toujours ce fil vieux de deux ans demandant combien coûte le stockage du modèle. Personne dans le fil n'a répondu. Les deux plateformes publient le tarif. Chez Modal, c'est 0,09 $ par GiB et par mois, le premier TiB étant gratuit, donc ce checkpoint de 80 Go est facturé 0,00 $. Chez RunPod, c'est 0,07 $ par Go et par mois pour le stockage réseau sous 1 To, ce qui place le même checkpoint à environ 5,60 $ par mois.

La troisième ligne, c'est le scénario d'échec. Une analyse 2024 de ServerlessLLM par la TU München (arXiv 2411.15664) rapporte que LLaMA-2-70B (130 Go) demande plus de 26 secondes de téléchargement à 5 Go/s, plus environ 84 secondes de chargement sur 8 GPU, face à une génération de token d'environ 100 ms. Ces chiffres sont cités dans cette analyse, pas mesurés par elle.

La page tarifaire de RunPod comporte une section Storage : disque conteneur 0,10 $/Go/mois, disque de volume 0,10 $/Go/mois en activité et 0,20 $/Go/mois au repos, stockage réseau 0,07 $/Go/mois sous 1 To et 0,05 $/Go/mois au-delà, stockage réseau haute performance 0,14 $/Go/mois. Le chiffre existe. Il ne figure simplement pas à côté des tarifs serverless par GPU que le lecteur compare au moment où la question se pose, ni dans le flux de configuration de l'endpoint. Un problème de visibilité, pas de secret, et de quoi maintenir la question en vie deux ans plus tard.

# Point the Hugging Face cache at a mounted network volume
# so weights persist across cold starts (RunPod / Modal pattern)
export HF_HOME=/workspace/hf-cache
export TRANSFORMERS_CACHE=/workspace/hf-cache
export HF_HUB_ENABLE_HF_TRANSFER=1

# Alternative: bake weights into the image at build time
FROM vllm/vllm-openai:latest
COPY ./model-weights /models/qwen3-27b-fp8
ENV MODEL_NAME=/models/qwen3-27b-fp8
# Downside: 30+ GB image, full rebuild to change models

Si vous n'avez pas encore choisi de modèle, notre comparatif 2026 des modèles open-weights dimensionne chaque option pour le déploiement.

Déploiement : vLLM sur RunPod Serverless, de bout en bout

Six étapes, de zéro à un endpoint appelable. Vérifiez chacune en suivant la procédure vLLM de RunPod (mise à jour le 22 juin 2026), qui ne publie aucun prix.

1. Choisissez votre modèle. Prenez un modèle open-weights dimensionné pour votre GPU (voir le tableau VRAM ci-dessus). S'il est soumis à accès restreint sur Hugging Face, générez d'abord un token d'accès.

2. Créez l'endpoint serverless. Dans la console RunPod, sélectionnez Serverless, choisissez le template worker vLLM, puis votre niveau de GPU.

3. Définissez les variables d'environnement qui comptent.

MODEL_NAME=Qwen/Qwen3.6-27B-FP8
MAX_MODEL_LEN=32768
GPU_MEMORY_UTILIZATION=0.90
DTYPE=auto

Un MODEL_NAME erroné donne une 404 au boot. Un MAX_MODEL_LEN trop haut pour votre VRAM provoque un OOM avant le premier token. Un GPU_MEMORY_UTILIZATION au-dessus de 0,95 ne laisse aucune marge pour les pics de KV-cache.

1. Réglez les workers min/max et le délai d'inactivité. Workers min à 0 : vous obtenez le scale-to-zero (et les démarrages à froid). Workers min à 1 : plus de démarrages à froid, mais une facturation continue. La section sur les démarrages à froid ci-dessous détaille ce compromis.

2. Attachez le volume réseau choisi dans la section sur les poids du modèle, ou acceptez l'intégration dans l'image. Si vous sautez cette étape, chaque démarrage à froid retélécharge le checkpoint.

3. Envoyez la première requête. Lisez l'ID d'endpoint dans la console et confirmez que des tokens reviennent.

curl -X POST "https://api.runpod.ai/v2/${ENDPOINT_ID}/runsync" \
  -H "Authorization: Bearer ${RUNPOD_API_KEY}" \
  -H "Content-Type: application/json" \
  -d '{
    "input": {
      "messages": [{"role": "user", "content": "Explain cold starts in one sentence."}],
      "max_tokens": 60
    }
  }'

Si vous hésitez sur le moteur de serving lui-même, nous avons comparé vLLM et SGLang en débit et latence.

Comment appeler l'endpoint depuis votre application ?

Toutes les plateformes de la sélection parlent une API compatible OpenAI. Un seul snippet Python fonctionne partout. Changer de fournisseur se résume à modifier la base_url, pas à réécrire le code. Cela fait passer « quel fournisseur » d'une décision d'enfermement à une décision de configuration.

import os

from openai import OpenAI

ENDPOINT_ID = os.environ["RUNPOD_ENDPOINT_ID"]

client = OpenAI(
    base_url=f"https://api.runpod.ai/v2/{ENDPOINT_ID}/openai/v1",
    api_key=os.environ["RUNPOD_API_KEY"],
)

response = client.chat.completions.create(
    model="Qwen/Qwen3.6-27B-FP8",
    messages=[{"role": "user", "content": "What is scale to zero?"}],
    max_tokens=120,
)
print(response.choices[0].message.content)

# Same code, different provider. One line changes.
ENDPOINT_ID = os.environ["RUNPOD_ENDPOINT_ID"]

PROVIDERS = {
    "runpod": f"https://api.runpod.ai/v2/{ENDPOINT_ID}/openai/v1",
    "modal": "https://your-app--your-func.modal.run/v1",
    "beam": "https://your-beam-endpoint/v1",
}

client = OpenAI(base_url=PROVIDERS["modal"], api_key="your-key")

Si chaque fournisseur parle le dialecte d'OpenAI, « quel fournisseur de GPU serverless » cesse d'être une décision d'architecture et devient une ligne de configuration.

Une fois que vous avez plusieurs endpoints, notre comparatif de passerelles LLM couvre le routage et le failover. Pour une installation plus légère, un proxy LiteLLM ajoute retries et journalisation.

Quel démarrage à froid observerez-vous vraiment ?

Pour un modèle 7B sur GPU serverless, comptez 10 à 30 secondes pour un vrai démarrage à froid (boot du conteneur, chargement des poids, initialisation du moteur), d'après les retours de praticiens. Les documentations fournisseurs annoncent 1 à 5 secondes pour le boot du conteneur seul. L'écart entre ces chiffres, c'est votre checkpoint qui traverse un réseau.

La page produit de RunPod affirme des démarrages à froid FlashBoot sous 200 ms (affirmation fournisseur, pas une mesure). Un praticien sur r/LLMDevs rapporte : « cold starts in my experience aren't great … I would say ~ 10 - 30 s », en ajoutant « most of my experience revolves around diffusion models though. » Les deux sont vrais. Ils ne mesurent pas la même chose.

Le chiffre du démarrage à froid, c'est trois chiffres empilés :

1. Boot du conteneur. Documentation Modal : « Containers boot in about one second. » Cloud Run : les instances avec pilotes préinstallés « start in approximately 5 seconds. »

2. Chargement des poids. La partie que personne ne met en avant. Une analyse 2024 de ServerlessLLM par la TU München (arXiv 2411.15664) situe LLaMA-2-70B à plus de 26 secondes de téléchargement, plus environ 84 secondes de chargement sur 8 GPU.

3. Initialisation du moteur. Capture de graphe et échauffement de vLLM. Logesh Umapathi a mesuré Qwen3.6-27B-FP8 sur A100-80GB passant d'une base de 460 s à 219 s en mode eager, puis à environ 70 s avec le mode veille de vLLM plus les snapshots GPU de Modal. Soit 6,5x, publié le 17 mai 2026.

Notre lecture des données publiées : les chiffres fournisseurs chronomètrent le conteneur. Les chiffres des praticiens chronomètrent la requête entière. Entre ces deux chronomètres se trouvent 80 Go de poids qui traversent un réseau. La colonne Type est là pour ça.

Que faire : mode veille de vLLM, snapshots GPU et réglage de la fenêtre de scale-down. L'inactivité par défaut de Modal est de 60 secondes (configurable de 2 s à 20 min). Un worker chaud supprime les démarrages à froid, mais facture en permanence.

# Modal scaledown config (illustrative)
# A 60s window means you pay for 60 idle seconds per burst.
# A warm worker (min_containers=1) costs ~$2.50/hr on A100 80GB, 24/7.
@app.function(
    gpu="A100",
    scaledown_window=60,  # seconds idle before shutdown
    # min_containers=1,   # uncomment to kill cold starts; costs $60/day
)

Le GPU serverless coûte-t-il moins cher qu'un GPU toujours allumé ?

Le GPU serverless coûte moins cher quand votre GPU reste inactif l'essentiel de la journée. À 3 000 requêtes/jour de 2 secondes en moyenne sur une A100 80GB, le serverless coûte environ 4,17 $/jour contre 65,28 $/jour pour un GPU loué tournant 24/7. Le point de bascule est une question de taux d'utilisation, pas de volume.

Hypothèses (les nôtres, énoncées pour que vous puissiez les refaire) : A100 80GB à 2,50 $/h chez Modal, 2 secondes de temps GPU moyen par requête, GPU loué à 2,72 $/h chez RunPod en continu, API de tokens hébergée à 0,40 $/1M de tokens (tarif publié de milieu de gamme) et environ 1 000 tokens par requête.

Le point de bascule se situe autour de 47 000 requêtes/jour. En dessous, le serverless gagne. Une API de tokens hébergée bat les deux à faible volume avec un modèle standard. Le seuil de rentabilité ne dépend pas du nombre de requêtes que vous recevez, mais du nombre d'heures que votre GPU passe à ne rien faire.

L'analyse d'août 2024 de BentoML cadre bien ce compromis, même si ses exemples tarifaires datent de l'ère GPT-3.5-turbo et ont deux ans de retard.

Pour le coût d'une API de tokens hébergée à votre volume, consultez notre comparatif de prix d'API LLM. Pour réduire le coût par requête côté inférence, la mise en cache des prompts économise en général 30 à 60 % sur les contextes répétés.

# Break-even calculator: adjust these and re-run
REQUESTS_PER_DAY = 3000
SECONDS_PER_REQUEST = 2
SERVERLESS_RATE_HR = 2.50   # Modal A100 80GB
RENTED_RATE_HR = 2.72       # RunPod A100 80GB, 24/7

serverless_daily = REQUESTS_PER_DAY * SECONDS_PER_REQUEST / 3600 * SERVERLESS_RATE_HR
rented_daily = RENTED_RATE_HR * 24

print(f"Serverless: ${serverless_daily:.2f}/day")
print(f"Rented 24/7: ${rented_daily:.2f}/day")
print(f"Crossover: {int(RENTED_RATE_HR * 24 / (SECONDS_PER_REQUEST / 3600 * SERVERLESS_RATE_HR))} req/day")

Quand le GPU serverless est le mauvais choix

• Trafic élevé et soutenu. Au-delà d'environ 47 000 requêtes/jour à ces tarifs, le cycle d'activité s'inverse et un GPU loué coûte moins cher par requête.
• SLO sous la seconde sur un chemin froid. Aucune astuce de snapshot ne rend une première requête instantanée. Gardez un worker chaud ou louez la machine.
• Modèles 70B et plus nécessitant plusieurs GPU. Un GPU par instance sur Cloud Run met fin à la conversation.
• Résidence des données stricte. Six régions L4, c'est tout le menu sur Cloud Run.
• Une économie par requête perdante face à un slot worker déjà payé. Si vous avez de la marge GPU inutilisée, ajouter de l'inférence ne coûte rien de plus.

Si votre GPU est occupé seize heures par jour, le serverless est l'option chère, et quiconque vous dit le contraire vend du serverless.

Pour l'approche locale, consultez notre guide des outils LLM en local.

Questions fréquemment posées

Qu'est-ce qu'un GPU serverless ?

Une plateforme de GPU serverless exécute le conteneur de votre modèle sur du matériel partagé, retombe à zéro entre les requêtes et ne facture que le calcul actif. Vous obtenez un endpoint d'inférence sans gérer d'instance GPU persistante. En contrepartie : un délai de démarrage à froid à chaque réveil.

Combien coûte l'exécution d'un LLM sur GPU serverless ?

Une A100 80GB coûte 2,25 $/h chez Beam, 2,50 $/h chez Modal, 2,72 $/h chez RunPod (vérifié le 30 juillet 2026). Votre facture dépend du taux d'utilisation : 3 000 requêtes/jour à 2 s chacune coûtent environ 4 $/jour chez Modal. Le stockage ajoute 0,09 $/GiB/mois, avec 1 TiB gratuit.

Le stockage des poids du modèle est-il payant ?

Oui, mais c'est bon marché. Modal facture 0,09 $/GiB/mois avec 1 TiB/mois gratuit, donc un checkpoint de 80 Go ne coûte rien. La page tarifaire de RunPod liste le stockage réseau à 0,07 $/Go/mois sous 1 To, soit environ 5,60 $/mois pour les mêmes 80 Go.

Mon modèle est-il retéléchargé à chaque requête ?

Seulement si rien n'est mis en cache. Les poids sur un volume persistant ou intégrés à l'image survivent aux démarrages à froid. Pointez le cache Hugging Face vers un stockage éphémère et un modèle de 130 Go se retélécharge à chaque réveil. C'est le scénario d'échec à éviter.

Quelle est la durée du démarrage à froid pour un modèle 7B ?

Comptez 10 à 30 secondes pour un vrai démarrage à froid, d'après les retours de praticiens (r/LLMDevs, décembre 2024). Le conteneur démarre en 1 à 5 s (docs Modal, Cloud Run). Le reste, c'est le chargement des poids et l'initialisation du moteur. Avec snapshots et mode veille, Umapathi a mesuré environ 70 s pour un modèle 27B, contre 460 s au départ.

Peut-on faire tourner un modèle 70B sur GPU serverless ?

En général, non. Un modèle 70B en FP16 demande environ 140 Go de VRAM. Cloud Run autorise un GPU par instance (96 Go max). Il vous faudrait une quantification FP8 pour tenir sur une seule carte de 80 Go, ou une plateforme multi-GPU. La plupart des offres serverless plafonnent à un GPU.

Le GPU serverless est-il moins cher qu'une location de GPU 24/7 ?

En dessous d'environ 47 000 requêtes/jour (à 2 s/requête sur A100 80GB), oui. Le serverless ne facture que les secondes actives ; un GPU loué facture 24 heures quoi qu'il arrive. Au-dessus, le GPU loué gagne. Une API de tokens hébergée bat les deux à faible volume. Voir le tableau de rentabilité ci-dessus.

Peut-on déployer un LLM sur GPU serverless gratuitement ?

Modal offre 30 $/mois de crédits gratuits (Starter). Beam offre 30 $/mois. Le crédit de 300 $ pour nouveau compte GCP couvre l'usage GPU de Cloud Run. Assez pour prototyper, pas pour faire tourner du trafic de production. Aucune plateforme n'offre de tier gratuit permanent pour l'inférence GPU.

Quels fournisseurs de GPU serverless sont disponibles en Europe ?

Cloud Run sert des GPU L4 dans europe-west1 (Belgique) et europe-west4 (Pays-Bas). Modal documente la sélection de région UE (eu-west, eu-north, eu-south), facturée 1,5 à 1,75x les tarifs de base. RunPod nomme des data centers européens dont EU-NL-1 et EU-FR-1. Fixez la région explicitement ; aucun ne choisit l'UE par défaut.

Faut-il Docker pour déployer un LLM sur GPU serverless ?

Pas toujours. RunPod propose des templates worker vLLM préconstruits qui évitent Docker. Modal construit les conteneurs à partir d'une définition d'image Python dans le code. Pour des dépendances personnalisées, vous écrirez un Dockerfile. Pour un serving vLLM standard, le chemin préconstruit fonctionne en quelques minutes.

Conclusion

Cinq plateformes, cinq unités de facturation, un tableau normalisé. La décision est plus simple que les pages fournisseurs ne le laissent paraître :

• Choisissez votre GPU selon la VRAM, pas selon la marque.
• Placez vos poids sur un volume, pas dans l'image, sauf si vous ne changez jamais de modèle.
• Comptez sur des démarrages à froid de 10 à 30 secondes et organisez-vous autour.
• En dessous d'environ 47 000 requêtes/jour, le scale-to-zero gagne sur le coût.
• Le moteur de serving derrière l'endpoint est interchangeable ; la base_url tient en une ligne.

Vous avez un endpoint appelable. Et ensuite : que placer devant quand vous avez besoin de routage et de failover ? Notre comparatif de passerelles LLM y répond. Ou parlez-nous de votre installation.