GPU spot vs on-demand : 4,00 $/h au lieu de 7,99 $/h, si ton job survit à l’interruption

La capacité spot est souvent vue comme un petit coupon que les achats négocieront peut-être un jour. Chez Verda, c’est une grille tarifaire à part. Le 2026-10-18, un B200 SXM coûtait 4,00 $/h en spot et 7,99 $/h en on-demand : même modèle de GPU, même fournisseur, même jour.

Le tarif réduit vient avec une condition : le fournisseur peut reprendre le GPU. Si ton job encaisse ça à peu de frais, le spot est une vraie économie. Sinon, le prix spot est un mode de défaillance qui a juste l’air bon marché.

La grille tarifaire au 2026-10-18

Verda affiche des tarifs spot et on-demand pour les mêmes modèles de GPU. Prix au 2026-10-18, par GPU-heure :

L’écart apparaît sur chaque ligne, de la toute dernière puce Blackwell jusqu’au V100. Nos données enregistrent le prix, pas les conditions. Avant de miser sur le spot, vérifie dans la documentation de Verda comment et quand les interruptions sont signalées, ce qu’il advient du stockage attaché ou local quand une instance est reprise, à quelle vitesse la capacité revient en général, et quelle configuration matérielle reçoit chaque voie.

Ce ne sont que les prix de Verda. La même puce peut coûter des montants très différents ailleurs, comme nous l’avons montré dans notre analyse de l’écart de prix entre fournisseurs. Compare les fournisseurs avant de comparer les voies.

Les deux voies ont augmenté entre nos deux relevés

On pourrait s’attendre à ce que le spot réagisse autrement que l’on-demand quand les prix catalogue changent. En comparant notre relevé du 2026-09-16 à celui du 2026-10-18, les hausses en pourcentage étaient identiques ou presque dans les deux voies :

Le B200 SXM a augmenté de +26 % dans les deux voies. Le H100 SXM de +30 % dans les deux.

Ce sont deux instantanés comparés. Ça ne dit rien de la trajectoire des prix entre ces deux dates, ça n’établit pas de formule de tarification, et ça ne prédit pas le prochain mouvement. La conclusion étroite : entre ces deux relevés, être sur du spot n’a protégé personne de la hausse. Choisis le spot parce que ta charge de travail tolère l’interruption, pas comme couverture contre une révision des prix.

Conséquence pratique : un job spot sur B200 SXM budgété à 3,18 $/h le 2026-09-16 était facturé 4,00 $/h le 2026-10-18. Consulte la page de chaque GPU quand tu dimensionnes un run, pas quand la facture arrive.

Ce que le spot te vend vraiment

En spot, tu loues le même modèle de GPU à un tarif plus bas et tu acceptes que le fournisseur puisse le reprendre. Quand ça arrive, le job qui tourne dessus s’arrête. Selon les conditions du fournisseur, tu peux aussi devoir attendre avant que de la capacité spot soit de nouveau disponible.

La remise paie ta tolérance à l’interruption, et construire cette tolérance a ses propres coûts. La comparaison utile n’est donc pas tarif horaire contre tarif horaire. C’est le coût d’un job terminé dans chaque voie, mesuré avec le même périmètre des deux côtés.

Note qu’un job reprenable profite aussi à l’on-demand : les crashs et pannes de nœuds y arrivent aussi, donc une partie du travail de checkpointing n’est pas un coût propre au spot. Ne compte que l’effort supplémentaire exigé par le spot.

Le spot gagne quand la deuxième ligne est la plus basse. Un écart horaire large comme 4,00 $/h contre 7,99 $/h pour un B200 SXM laisse de la marge pour absorber le surcoût, mais ne garantit pas une économie : un job souvent interrompu qui perd beaucoup à chaque fois peut finir par coûter plus cher qu’en on-demand.

Une seule question te fait faire l’essentiel du chemin :

Si ce process était tué maintenant, qu’est-ce que je perdrais, et combien de temps faudrait-il pour revenir où j’en étais ?

Les jobs qui vont sur du spot

Ces jobs survivent à l’interruption de manières différentes. Il te faut le mécanisme qui convient à ton job, pas tous à la fois.

Fine-tuning avec checkpoints fréquents. Si les poids, l’état de l’optimiseur, la position du data loader et les seeds aléatoires sont écrits sur un stockage durable à cadence régulière, et que leur restauration reproduit réellement l’état du run, une interruption te coûte à peu près les steps depuis le dernier checkpoint plus le temps de redémarrage. Ce chemin de restauration est la partie à tester, pas à supposer. L’intervalle fixe ta perte dans le pire cas, et des intervalles plus courts ajoutent du surcoût d’écriture : ajuste-le selon la fréquence réelle de tes interruptions.

Inférence batch. Scorer un dataset, générer des embeddings ou étiqueter un backlog se découpe naturellement en shards indépendants. Si chaque shard écrit sa sortie et se marque comme terminé, un worker tué ne refait que son shard en cours.

Balayages d’évaluation. Une suite de benchmarks sur plusieurs checkpoints ou réglages d’hyperparamètres, c’est beaucoup de petits jobs indépendants. Un scheduler qui remet en file les éléments en échec transforme une interruption en retard plutôt qu’en résultat perdu.

Ce qu’ils ont en commun : la progression est persistée quelque part qui survit à l’instance, et l’échéance se mesure en heures, pas en millisecondes.

Les jobs qui demandent plus d’attention

Serving temps réel sur une seule instance. Un endpoint d’inférence qui tourne sur une seule instance spot tombe quand cette instance est reprise, et les utilisateurs voient des erreurs, pas un GPU moins cher. Le spot peut quand même porter une partie d’une flotte de serving si tu as assez de réplicas redondants, un failover qui détourne le trafic des nœuds repris, et un objectif de disponibilité qui tolère la capacité réduite le temps que les remplaçants démarrent et chargent les poids. Que ce soit acceptable dépend de tes exigences, pas du prix.

API sensibles à la latence avec des objectifs stricts. Démarrer une instance de remplacement et charger les poids prend un temps qu’une requête synchrone n’a pas. Si tu as un engagement de disponibilité ou de latence, vérifie ce que chaque voie promet réellement dans les conditions du fournisseur avant de décider laquelle le soutient. L’on-demand n’est pas repris comme le spot, mais ce n’est pas automatiquement un SLA non plus.

Longs runs sans chemin de reprise. Un job d’entraînement qui ne sauvegarde qu’à la fin, ou un pipeline qui garde tout en mémoire, cumule le pire des deux voies. Une seule interruption tardive jette toutes les heures qui précèdent, et la facture totale peut dépasser ce qu’aurait coûté l’on-demand.

Une répartition courante : garder une base de capacité de serving en on-demand et envoyer autour d’elle le travail hors ligne (ré-embedding, évals, fine-tunes nocturnes) sur du spot.

Le parallèle LLM : l’API Batch

Si tu utilises des API LLM, tu as déjà vu un compromis similaire. Dans L’API Batch : moitié prix pour tout ce qui peut attendre, nous avons décrit la voie asynchrone proposée par OpenAI, Anthropic, Google, Mistral et plusieurs agrégateurs ; la remise est de 50 % chez les trois grands. Tu abandonnes la basse latence et tu obtiens une remise de ~50 % et des limites de débit bien plus hautes. Le fournisseur exécute ton fichier quand il a de la capacité libre, avec un délai de complétion en général de 24 heures.

L’économie est du même ordre : un fournisseur facture la capacité moins cher aux clients qui acceptent des garanties plus faibles. L’ingénierie, elle, ne se transpose pas entièrement.

Une charge de travail adaptée à l’API Batch a passé le premier test : elle peut attendre. Sa version self-hosted ne convient au spot que si elle peut aussi reprendre après un arrêt, et cette partie, tu la construis toi-même. Pour d’autres économies côté API, vois Six leviers pour réduire ta facture d’API LLM.

Avant de basculer

• Lis les conditions du spot. Confirme auprès de Verda (ou du fournisseur que tu utilises) comment les interruptions sont signalées, ce qui arrive au stockage et comment la capacité revient.
• Tue-le volontairement. Arrête un run de test manuellement et vérifie qu’il reprend depuis la progression sauvegardée, avec l’état attendu, sans intervention.
• Sors l’état de l’instance. Checkpoints, sorties et marqueurs de progression doivent vivre sur un stockage dont tu as confirmé qu’il survit à une reprise.
• Chiffre le job terminé. Utilise la formule ci-dessus avec le même périmètre des deux côtés.
• Dimensionne le serving selon les besoins de disponibilité. Ne mets du serving sur du spot qu’avec une redondance et un failover qui respectent ton objectif.
• Compare les fournisseurs, pas seulement les voies. Un prix spot chez un fournisseur peut encore perdre face à un prix on-demand ailleurs. Consulte les prix en direct pour le B200, le H200 et le H100.

Si tu hésites encore à louer des GPU, commence par Est-ce moins cher de self-host, ou d’utiliser simplement une API ?. Les heures d’inactivité peuvent peser plus que la voie que tu choisis.

À retenir

Chez Verda au 2026-10-18, un B200 SXM était à 4,00 $/h en spot contre 7,99 $/h en on-demand, et entre nos relevés du 2026-09-16 et du 2026-10-18 les deux voies ont augmenté de +26 %. Le tarif spot remise des heures, pas du travail terminé : décide sur le coût du job complété, et ne déplace que le travail dont tu as déjà vu qu’il survit à un kill.