Cloud GPU : 7 fournisseurs à comparer pour l’IA en 2026

Pour choisir un fournisseur de cloud GPU, partez de votre besoin : Runpod pour piloter vous-même le fine-tuning, Modal pour une inférence serverless avec votre propre code, Together AI pour une API de modèles managée, et Vast.ai pour des traitements capables de reprendre après interruption sur une place de marché. Cette sélection de 7 fournisseurs comprend aussi Lambda pour les machines virtuelles GPU, CoreWeave pour les besoins planifiés en capacité de cluster, et Google Cloud lorsque votre application dépend déjà de son infrastructure. Commencez par la mémoire nécessaire au modèle et la durée d’exécution facturée, avant de regarder le tarif GPU le plus bas affiché.

Tarifs et documentation produit vérifiés le 30 octobre 2026. Les prix ci-dessous sont les montants en USD affichés ce jour-là sur la page tarifaire de chaque fournisseur. Ce comparatif repose sur la documentation ; il ne s’agit pas d’un test de performances réalisé sur les machines. La disponibilité, les taxes et la configuration finalement déployée peuvent modifier la facture.

Cloud GPU : quel fournisseur pour quel usage ?

Runpod est le premier fournisseur à examiner pour réaliser soi-même le fine-tuning d’un modèle ; Modal et Together AI sont les premiers à évaluer pour le mettre en service sans entretenir une machine GPU permanente. Le choix change dès qu’il faut une région précise, une capacité continue ou un environnement de traitement par lots qui facilite la reprise.

Comparatif des prix du cloud GPU : l’unité compte autant que le montant

Chaque tarif d’entrée correspond à un produit et à un matériel précis. Ces prix donnent accès à des services différents ; ils ne représentent pas des performances équivalentes. Le prix d’un GPU ajouté à une machine exclut la machine virtuelle hôte ; la seconde de GPU serverless exclut les ressources facturées séparément ; un tarif d’inférence dédiée n’est pas un prix d’API au token.

Une offre sur une place de marché peut disparaître, et la carte la moins chère du catalogue peut manquer de mémoire pour votre modèle. La colonne des essais décrit l’offre publique vérifiée, sans couvrir tous les programmes de crédits négociés. Together AI impose un accès prépayé ; Google précise sa restriction sur les GPU dans les conditions du Free Trial.

Inférence serverless : votre propre code ou une API de modèles ?

Avant de choisir un GPU, déterminez si vous devez maîtriser l’environnement d’exécution du modèle. L’inférence consiste à utiliser un modèle entraîné pour produire une réponse. Une API managée permet de demander cette réponse ; le calcul serverless personnalisé permet de fournir le code qui la produit. Cette distinction compte davantage que la présence du mot « serverless » dans les deux offres.

1. Modal : pour une inférence Python personnalisée face à un trafic irrégulier

Modal est une plateforme de calcul serverless pour les applications conteneurisées déployées via Python. Elle convient lorsque le code qui exécute le modèle fait partie intégrante du produit. Un service de traitement documentaire peut, par exemple, réunir un prétraitement spécifique, un appel au modèle et un post-traitement dans le même déploiement. Modal adapte les ressources à la demande, mais la durée facturée inclut l’initialisation et l’attente des conteneurs maintenus prêts, au-delà du calcul utile du modèle. Choisissez Modal pour garder la main sur l’environnement d’exécution sans gérer une VM qui tourne en permanence.

Pour qui : les équipes Python qui déploient une inférence personnalisée ou des traitements GPU en file d’attente, avec une demande variable.
Point fort : le déploiement à l’échelle de l’application et l’ajustement automatique de la capacité, avec des ressources de calcul facturées séparément.
Tarifs : le calcul GPU démarre à $0.000164/seconde pour un T4, plus CPU et mémoire, selon la page tarifaire de Modal, vérifiée le 30 octobre 2026.
Essai gratuit : Starter inclut $30/mois de crédits de calcul ; les Shared Endpoints facturés au token restent en dehors de cette enveloppe.

La principale difficulté est la latence après une période creuse. Un démarrage à froid correspond au travail nécessaire pour préparer un nouveau conteneur avant qu’il puisse répondre. Lancer le conteneur, importer les bibliothèques et charger les poids du modèle sont des étapes distinctes. Un conteneur qui démarre vite ne rend pas le modèle immédiatement disponible.

Modal propose des réglages pour conserver des conteneurs prêts et une capacité de réserve. Ils peuvent améliorer la réactivité, mais maintiennent aussi des ressources allouées. Pour un assistant destiné aux clients, testez la première requête après une période d’inactivité ainsi que les requêtes envoyées pendant une session chargée. Pour une file d’extraction traitée la nuit, l’attente liée à l’initialisation peut être acceptable. Le guide de Modal sur les démarrages à froid explique cet arbitrage.

L’offre Starter fixe aussi une limite concrète à la montée en charge : 3 places dans l’espace de travail et 10 GPU simultanés. C’est suffisant pour un pilote utile, mais un pic de workers indépendants peut atteindre le plafond de simultanéité bien avant que la dépense mensuelle paraisse élevée. Les volumes persistants et le trafic réseau sortant disposent de quotas inclus, puis sont facturés séparément au-delà. Intégrez donc le parcours des données à votre estimation.

La localisation constitue un autre choix de configuration. Modal distingue la région où s’exécute le conteneur de celle qui achemine ses requêtes. Fixer une région entraîne également un multiplicateur tarifaire. Exécuter un modèle près de la base de données n’a d’intérêt que si le chemin suivi par les requêtes respecte lui aussi vos contraintes de latence et de résidence des données. La documentation sur le choix des régions décrit ces deux réglages.

2. Together AI : pour disposer directement d’un endpoint de modèle

Together AI est une plateforme managée d’inférence et d’entraînement. Elle convient aux équipes qui veulent livrer une fonctionnalité fondée sur un modèle avant de gérer une infrastructure GPU. Son API serverless est le point de départ naturel lorsque le modèle recherché figure au catalogue ; l’inférence dédiée apporte davantage de contrôle sur le matériel d’exécution. La limite tient à la personnalisation : une API de modèles pris en charge ne remplace pas un environnement d’entraînement entièrement à votre main. Choisissez Together AI si le produit dont vous avez besoin est un endpoint, puis passez à une capacité dédiée lorsque le trafic ou vos exigences de contrôle le justifient.

Pour qui : les équipes qui mettent en service des modèles pris en charge, ou utilisent le fine-tuning managé et l’inférence dédiée.
Point fort : la possibilité de passer d’une API facturée au token à une infrastructure dédiée à l’exécution du modèle.
Tarifs : l’inférence dédiée NVIDIA HGX H100 démarre à $5.49/GPU-heure ; les tarifs des API serverless dépendent du modèle, selon la page tarifaire de Together AI, vérifiée le 30 octobre 2026.
Essai gratuit : aucun ; l’achat de crédits prépayés est obligatoire.

Distinguez bien les modes de facturation. L’inférence serverless des modèles de langage facture les tokens d’entrée et de sortie, ces fragments de texte que traite le modèle. L’inférence dédiée facture à la minute chaque réplique prête, c’est-à-dire chaque copie opérationnelle du service qui exécute votre modèle. Sa documentation exclut le provisionnement et le démarrage à froid de la facturation du calcul dédié. Une réplique prête continue toutefois à coûter de l’argent même si elle reçoit peu de requêtes. Ramener le nombre de répliques à zéro arrête cette facturation du calcul. La documentation tarifaire de l’inférence dédiée précise ces limites.

Pour une application d’assistance aux conversations sporadiques, le serverless évite d’acheter une capacité d’exécution inutilisée. Pour une application très sollicitée dont le profil de trafic est établi, les répliques dédiées méritent une comparaison avec les mêmes prompts et longueurs de réponse. Ne basculez pas au seul motif qu’un prix par GPU paraît inférieur : il faut mesurer le débit pour le convertir en coût par réponse terminée.

Le fine-tuning managé demande aussi une estimation distincte. Together propose le fine-tuning par adaptateurs LoRA et le fine-tuning complet, avec une facturation au token qui tient compte des passages d’entraînement et de l’évaluation. Une époque correspond à un passage sur le jeu de données d’entraînement. Répéter ce passage augmente le nombre de tokens traités ; la taille du fichier envoyé ne suffit pas à déterminer la facture.

L’offre de clusters GPU est encore un autre produit. Elle propose de la capacité à la demande et réservée, avec un stockage persistant facturé à part. Les réservations de clusters sont prépayées et non remboursables ; supprimer un cluster ne rend pas automatiquement gratuits tous les volumes conservés. La documentation des clusters indique que les transferts entrants et sortants ne sont pas facturés. N’étendez pas ces règles à l’ensemble des produits API. La documentation sur la facturation des clusters en donne le détail.

Pour l’inférence, vérifiez ensemble le modèle et la région. Certains modèles serverless permettent de limiter l’inférence aux États-Unis ; d’autres exigences régionales orientent vers les endpoints dédiés. Les délais de réponse de l’API partagée peuvent varier avec la demande, et l’application doit toujours gérer les nouvelles tentatives. La documentation serverless explicite ces limites.

Pods et VM à la demande pour le fine-tuning

Louez un environnement que vous maîtrisez tant que vous modifiez encore le script d’entraînement, les dépendances ou le modèle. Le fine-tuning adapte un modèle existant à l’aide de vos données. Un Pod ou une machine virtuelle permet d’examiner les erreurs et de relancer le traitement ; il vous laisse aussi la responsabilité d’arrêter le calcul et de conserver les résultats.

3. Runpod : un premier choix pour piloter soi-même le fine-tuning

Runpod propose des Pods GPU dédiés, ainsi que des offres Serverless et de clusters. C’est un premier fournisseur à examiner pour une petite équipe qui développe son propre workflow de modèles. On peut choisir un GPU et un modèle de conteneur, mener une session de fine-tuning, puis évaluer séparément un déploiement Serverless pour l’inférence. Les limites sont concrètes : la fiabilité de Community Cloud varie selon l’hébergeur, le stockage persistant suit son propre cycle de vie et un Pod arrêté ne garantit pas de retrouver le même GPU au redémarrage. Runpod mérite sa place pour le contrôle et la souplesse de ses déploiements, sans promettre d’être le moins cher pour tous les usages.

Pour qui : les développeurs qui ont besoin d’un conteneur GPU pour expérimenter, réaliser du fine-tuning par adaptateurs et développer leur propre inférence.
Point fort : des offres Pod et Serverless distinctes pour le développement et la mise en service.
Tarifs : la page en ligne affiche des Pods RTX A5000 avec 24 Go de VRAM à partir de $0.27/heure, selon la page tarifaire de Runpod, vérifiée le 30 octobre 2026.
Essai gratuit : aucun essai GPU gratuit n’était indiqué sur la page tarifaire consultée.

Commencez par la mémoire, pas par le nom de puce le plus impressionnant. Runpod répertorie des cartes de 24 Go, des options de 48 Go comme l’A40 et la RTX A6000, ainsi que des variantes A100 et H100 de 80 Go. Une petite équipe dispose ainsi de plusieurs capacités mémoire à évaluer sans devoir immédiatement concevoir un cluster. Cela ne constitue pas un classement par débit : le moteur d’inférence, la précision du modèle et la configuration des lots peuvent changer la carte la plus intéressante à louer.

Secure Cloud et Community Cloud répondent aussi à des choix différents. Runpod décrit Secure Cloud comme une infrastructure de centres de données et Community Cloud comme une offre pair à pair à la fiabilité variable. Une expérience que l’on peut refaire n’exige pas la même tolérance aux pannes qu’un service traitant des requêtes clients. Choisissez l’offre selon les besoins de reprise et d’assistance du traitement. Le guide de Runpod pour choisir un Pod explique cette distinction.

Le stockage est la contrainte qui risque le plus de surprendre lors d’un premier déploiement. Le disque du conteneur est temporaire. Un disque de volume survit à l’arrêt du Pod, mais pas à sa suppression. Un volume réseau persiste indépendamment ; il est toutefois disponible pour les Pods Secure Cloud et conditionne le choix du matériel à son emplacement. Conserver les checkpoints uniquement sur un stockage temporaire annule l’intérêt de les sauvegarder. La documentation des volumes réseau explique cette contrainte de localisation.

Les Pods facturent le calcul à la seconde, sans frais de transfert entrant ou sortant selon les règles tarifaires vérifiées. Le stockage peut continuer à être facturé après l’arrêt. Serverless suit un autre cycle : les workers sont facturés pendant l’initialisation, l’exécution et l’attente inactive, jusqu’à leur arrêt. Le nombre de workers Flex peut descendre à zéro ; les workers Active restent en fonctionnement. Ces choix déterminent la durée pendant laquelle vous payez des ressources allouées ; ce ne sont pas de simples variantes d’un même tarif horaire. Consultez la facturation des Pods et la facturation Serverless.

Pour la grille complète de calcul des tarifs et du stockage, consultez notre guide des prix de Runpod. Utilisez-la pour estimer les exécutions répétées et l’inférence maintenue en permanence.

1. 1

   Définissez le traitement avant de déployer

   Notez le checkpoint exact du modèle, le mode d’inférence ou de fine-tuning, la précision, la longueur maximale des entrées et le nombre d’exécutions simultanées attendu. Choisissez une capacité mémoire GPU qui laisse de la place à l’environnement d’exécution, au-delà du seul fichier du modèle.

2. 2

   Choisissez d’abord l’emplacement du stockage

   Si le traitement nécessite un volume réseau, créez-le ou sélectionnez-le dans le centre de données visé avant de choisir le GPU. Vérifiez qu’une capacité GPU adaptée y est disponible. Gardez une copie séparée des données d’entraînement et des checkpoints irremplaçables.

3. 3

   Déployez un modèle de conteneur compatible

   Dans Pods, sélectionnez le GPU, choisissez le modèle de conteneur, définissez le nombre de GPU et déployez à la demande. Vérifiez le filtre de compatibilité CUDA de l’hôte par rapport au modèle de conteneur. CUDA est la plateforme logicielle dont dépendent de nombreuses applications pour GPU NVIDIA.

4. 4

   Faites un essai réduit et vérifiez la procédure d’arrêt

   Testez le même parcours de chargement, d’entraînement et d’écriture des checkpoints que pour le traitement prévu. Relevez le pic de mémoire GPU et le temps écoulé. Vérifiez que le checkpoint se trouve sur un stockage persistant avant d’arrêter ou de supprimer les ressources de calcul, puis contrôlez les frais de stockage restants.

Ces réglages de déploiement sont décrits dans la documentation de gestion des Pods. Profitez aussi de cet essai pour tester la reprise : le prochain lancement doit pouvoir continuer sans dépendre d’une machine précédente en particulier.

4. Lambda : pour retrouver une machine virtuelle GPU familière

Lambda est un cloud GPU proposant des machines virtuelles Linux et des clusters réservés. Il convient aux équipes qui cherchent une machine classique pour une session d’entraînement prolongée. Ses environnements intègrent les outils NVIDIA, et le catalogue va des configurations à un seul GPU aux allocations plus importantes. La contrainte d’achat tient justement à cette allocation : le prix par GPU d’une même carte peut varier selon le nombre loué. Choisissez Lambda pour disposer d’un environnement d’entraînement maîtrisé, et vérifiez le sélecteur du nombre de GPU avant de prendre un tarif affiché pour votre future facture.

Pour qui : les équipes d’entraînement et de fine-tuning qui préfèrent accéder en SSH à une VM GPU.
Point fort : des instances à un seul GPU et une offre distincte de clusters réservés.
Tarifs : les instances à un seul GPU commencent à $0.69/GPU-heure pour une Quadro RTX 6000 avec 24 Go de VRAM, selon la page tarifaire de Lambda, vérifiée le 30 octobre 2026.
Essai gratuit : aucun essai GPU gratuit n’était indiqué sur la page tarifaire consultée.

Le catalogue comprend l’A6000 avec 48 Go ainsi que les variantes H100 PCIe et SXM avec 80 Go. Ces noms comptent. « RTX 6000 », « A6000 » et les cartes plus récentes aux noms proches ne sont pas interchangeables. Consignez le nom complet du GPU et sa mémoire dans vos notes de déploiement pour éviter qu’une future exécution utilise un matériel différent sans que vous le remarquiez.

Le calcul à la demande de Lambda affiche un tarif horaire, mais se facture par tranches d’une minute, depuis le démarrage opérationnel jusqu’à la suppression de l’instance. Une machine allumée qui ne travaille pas reste facturée. Pour un entraînement, organisez la procédure d’arrêt selon le cycle de suppression du fournisseur : la fin du processus Python ne met pas fin à la location. La documentation de facturation de Lambda décrit ce fonctionnement.

Les systèmes de fichiers persistants demandent une étape de préparation supplémentaire : ils doivent être rattachés lors de la création de l’instance et se trouver dans la même région. Ils restent facturés tant qu’ils existent, même démontés ; la documentation de facturation indique que leurs transferts entrants et sortants sont gratuits. Vérifiez que le GPU et le système de fichiers peuvent coexister à l’emplacement souhaité avant d’y charger un gros jeu de données. La documentation des instances Lambda précise les règles de région et de stockage.

L’offre de clusters réservés représente une autre échelle d’achat. Le tableau public des 1-Click Clusters commence à 16 GPU et à une durée de deux semaines. Cela peut convenir à une campagne d’entraînement intensive, mais constitue un mauvais point de départ tant que l’on cherche encore à savoir si une adaptation sur une seule carte résoudra le problème. Commencez par la plus petite expérience viable, puis augmentez les ressources une fois qu’elle a établi le débit nécessaire.

Location GPU sur une place de marché et instances interruptibles

N’acceptez le risque d’interruption qu’après avoir démontré que votre traitement sait reprendre. Une place de marché réunit les offres de différents hébergeurs. Une instance interruptible peut être suspendue ou récupérée. Ces notions se recoupent, mais une location à la demande sur une place de marché n’est pas automatiquement interruptible.

5. Vast.ai : pour les traitements qui savent reprendre et peuvent changer de lieu

Vast.ai est une place de marché GPU où les hébergeurs fixent leurs prix. Elle convient aux développeurs capables d’examiner chaque offre et de composer avec un parc de machines qui évolue. Un traitement d’embeddings par lots ou une expérience de fine-tuning reproductible peut y trouver sa place si les données d’entrée et les checkpoints survivent à l’instance. La difficulté réside dans les coûts propres à chaque hébergeur : le calcul, le stockage et les transferts dans les deux sens peuvent être facturés séparément. Choisissez Vast.ai si vous pouvez adapter votre mise en œuvre à l’offre, sans avoir besoin que toutes les offres se comportent de façon identique.

Pour qui : les expériences sensibles au coût, les traitements par lots et les entraînements capables de reprendre depuis un checkpoint.
Point fort : le choix de l’hébergeur pour des locations à la demande, réservées ou interruptibles.
Tarifs : prix GPU fixés par l’hébergeur et facturés à la seconde, auxquels s’ajoutent stockage et transferts ; consultez l’offre d’entrée pour votre configuration sur la page des tarifs en temps réel de Vast.ai, examinée le 30 octobre 2026.
Essai gratuit : aucun essai GPU gratuit n’était indiqué sur la page tarifaire consultée.

L’annonce la moins chère n’a d’intérêt que si son matériel convient au traitement. Le catalogue en ligne de Vast.ai répertorie des RTX 3090 et RTX 4090 de 24 Go, des L40S de 48 Go et des H100 SXM de 80 Go. Filtrez d’abord selon la mémoire et les logiciels nécessaires. Comparez ensuite le CPU, la mémoire système, le stockage, les conditions de transfert et la localisation de chaque hébergeur.

Le calcul est facturé à la seconde pendant l’exécution. Le stockage reste facturable tant que l’instance existe, y compris lorsqu’elle est arrêtée. Les frais d’envoi et de téléchargement varient selon l’hébergeur. Un GPU bon marché qui télécharge à répétition un modèle ou un jeu de données volumineux peut donc être un mauvais choix pour un traitement court. Comparez l’ensemble du parcours des données, au-delà de la seule carte graphique. La documentation tarifaire de Vast.ai explique ces composantes.

Pour un entraînement interruptible, sauvegarder uniquement le fichier du modèle ne suffit pas forcément à reprendre correctement. Conservez l’état nécessaire à votre framework d’entraînement et validez la procédure de reprise avant de compter dessus. Pour une file de traitements par lots, attribuez des identifiants stables aux tâches afin qu’une nouvelle tentative ne produise pas de doublons visibles par les clients. Ce sont des critères à remplir avant de choisir une capacité interruptible ; ils ne signifient pas que le fournisseur assure lui-même la reprise.

Vast.ai propose aussi une infrastructure serverless. Cette offre ne fait pas disparaître les questions liées à l’hébergeur et aux données : la documentation vérifiée décrit une facturation serverless fondée sur les coûts de calcul, de stockage et de bande passante de l’instance. Ce comparatif met l’accent sur la location via la place de marché, car c’est son usage le plus évident pour une petite équipe prête à gérer ces compromis.

Clusters réservés et infrastructure cloud existante

Réservez de la capacité après avoir mesuré une demande stable ; restez près de l’infrastructure existante si déplacer le traitement crée plus de travail que cela n’en économise. Ce sont deux raisons distinctes de choisir une plateforme plus importante. Une petite équipe peut avoir l’une ou l’autre sans acheter à l’échelle d’un hyperscaler.

6. CoreWeave : pour un besoin de cluster clairement défini

CoreWeave est un cloud d’infrastructure IA proposant Kubernetes managé sur des nœuds GPU bare metal. Il convient aux équipes qui ont dépassé l’expérimentation et planifié leurs besoins de calcul. Kubernetes coordonne les conteneurs entre les machines ; il est utile lorsque le déploiement exige cette orchestration et qu’une personne en assure la gestion. Pour une petite équipe, les contraintes portent sur l’allocation et l’exploitation : l’achat à l’échelle du nœud et un cluster managé exigent toujours un traitement bien défini, un plan de stockage et un responsable d’exploitation. Retenez CoreWeave lorsque la planification de capacité répond à un besoin réel, plutôt que comme point de départ pour découvrir les exigences de votre modèle.

Pour qui : les équipes dont les besoins en cluster sont connus et qui savent exploiter des traitements sous Kubernetes.
Point fort : Kubernetes managé sur des nœuds bare metal, avec réseau et isolation de cluster.
Tarifs : le tableau pour l’Amérique du Nord affiche une instance GH200 à un seul GPU à $6.50/heure ; la capacité réservée nécessite un devis, selon la page tarifaire de CoreWeave, vérifiée le 30 octobre 2026.
Essai gratuit : aucun essai GPU gratuit n’était indiqué sur la page tarifaire consultée.

Lisez attentivement les colonnes de CoreWeave. Plusieurs instances GPU publiées comprennent 8 GPU, notamment les lignes H100, H200, A100, L40 et L40S. La page présente séparément des prix d’inférence à un seul GPU, et sa note de bas de page réserve ces tarifs aux clients de la plateforme d’inférence. Diviser le prix d’un nœud par son nombre de GPU aide à analyser les coûts, mais ne prouve pas que l’on peut louer une fraction de ce nœud pour un traitement de cluster ordinaire.

La page tarifaire distingue l’Amérique du Nord de l’Europe et présente des offres à la demande, spot et réservées. Pour une réservation, demandez la configuration exacte du nœud, le lieu de déploiement, la durée d’engagement et les conditions de capacité. Faites aussi préciser la granularité de facturation dans le devis : l’affichage d’un tarif horaire ne suffit pas à établir une facturation à la seconde.

CoreWeave indique que les transferts de données internes et par Internet sont gratuits, tandis que le stockage et les services d’IP publiques ont leurs propres frais. Un traitement qui déplace beaucoup de données mérite donc d’être étudié, mais l’engagement de calcul doit rester utile. Des transferts peu coûteux ne compensent pas un cluster inactif pendant l’essentiel de sa réservation.

La documentation de CoreWeave Kubernetes Service décrit le plan de contrôle managé, les nœuds bare metal, les réseaux privés et le réseau GPU. Pour une petite équipe IA, la question décisive est celle de la responsabilité : qui préparera les traitements, surveillera les erreurs, gérera les secrets et rétablira le service ? Si cette tâche revient à la personne qui valide encore l’application, un Pod ou une API plus simple peut permettre de livrer une fonctionnalité opérationnelle plus vite.

7. Google Cloud : pour exécuter le modèle près de votre application existante

Google Cloud propose des machines virtuelles Compute Engine équipées de GPU. C’est un fournisseur à examiner lorsque votre application et vos données y résident déjà. Garder l’exécution du modèle près du reste du système peut simplifier le déploiement, même si un cloud spécialisé affiche un devis GPU attractif. La difficulté est l’accès : le type de machine, la région, le quota et la disponibilité physique doivent tous correspondre. Choisissez Google Cloud si le traitement bénéficie de cette localisation et de votre organisation d’exploitation existante, sans prendre son prix GPU d’entrée pour celui d’un serveur GPU complet.

Pour qui : les développeurs qui ajoutent des traitements GPU à une application déjà exploitée sur Google Cloud.
Point fort : des familles de machines GPU dont la disponibilité régionale et les contrôles de quotas sont explicites.
Tarifs : l’ajout d’un T4 dans l’Iowa commence à $0.35/heure pour le GPU seul, auquel s’ajoute la VM, selon la page tarifaire des accélérateurs Google, vérifiée le 30 octobre 2026.
Essai gratuit : impossible d’ajouter des GPU pendant le Free Trial ; le passage à un compte payant est obligatoire.

Prix des GPU Google Cloud : ajoutez toujours le coût de la VM

Un GPU rattaché est une ressource supplémentaire, pas une machine complète. Le T4 cité dispose de 16 Go de mémoire GPU. Si l’application exige davantage de mémoire ou un autre accélérateur, choisissez une autre configuration au lieu de construire le budget autour de ce tarif d’entrée.

Google répertorie aussi des familles de machines à GPU intégrés, dont G2 avec L4, A2 avec des variantes A100 et des variantes A3 utilisant H100 ou H200. Le prix d’une machine intégrée et celui d’un GPU ajouté ne couvrent pas les mêmes ressources. Incluez le type de machine retenu dans l’estimation, avec les frais de stockage et de réseau.

Compute Engine facture à la seconde après un minimum d’une minute. Une VM allumée mais inactive reste facturée. Les réservations peuvent aussi être facturées alors que les ressources ne sont pas démarrées : réserver une disponibilité et lancer un traitement sont deux décisions différentes. Les règles de facturation de Compute Engine précisent ces limites.

Disponibilité des GPU Google Cloud : le quota ne suffit pas

La présence d’un type de GPU au catalogue ne garantit pas que votre compte puisse le lancer aujourd’hui dans la zone souhaitée. Google documente les GPU pris en charge par zone, et les contrôles de quotas sont distincts de la capacité matérielle sous-jacente. Vérifiez la machine visée dans la liste des régions et zones GPU, puis confirmez les quotas GPU nécessaires.

Par exemple, une équipe qui sert des clients près de sa base de données existante doit identifier les emplacements proches acceptables avant de demander une configuration GPU. Si la zone souhaitée manque de capacité, éloigner uniquement le serveur du modèle peut modifier à la fois le temps de réponse et le parcours des transferts de données. Traitez cette solution de repli comme une modification de l’application à tester.

Le Free Trial impose une restriction distincte : il n’autorise ni l’ajout de GPU ni les demandes d’augmentation de quota. Le Free Tier permanent de Google exclut lui aussi les GPU. Une annonce de crédit de bienvenue ne prouve donc pas qu’un nouveau compte puisse immédiatement lancer une expérience GPU. Les conditions de Google font foi.

Comment choisir un cloud GPU pour l’IA ?

Écartez d’abord le matériel incapable d’accueillir votre traitement, puis comparez les fournisseurs qui proposent les configurations adaptées. La mémoire GPU, souvent appelée VRAM, contient le modèle et l’état nécessaire à son exécution. Un modèle qui parvient tout juste à se charger peut encore échouer avec un prompt plus long ou une requête simultanée supplémentaire.

Commencez par estimer la mémoire des poids seuls. En 16 bits, chaque paramètre occupe 2 octets ; en 4 bits, un poids brut occupe un demi-octet. Un modèle de 8 milliards de paramètres représente donc environ 16 Go de poids en 16 bits, ou 4 Go de poids bruts en 4 bits. Un modèle de 32 milliards de paramètres donne 64 Go ou 16 Go ; un modèle de 70 milliards donne 140 Go ou 35 Go. Il s’agit de nos calculs en Go décimaux, pas de besoins mesurés en conditions d’inférence. Le guide de dimensionnement de Runpod fournit la règle de mémoire utilisée.

L’espace manquant compte. L’environnement d’inférence a besoin de mémoire de travail, et le cache KV conserve l’état de l’attention au fil de la génération. La longueur du contexte et les requêtes simultanées modifient cet état. Un « modèle de 35 Go » ne signifie donc pas que 35 Go suffisent au déploiement. La documentation de Hugging Face sur le cache explique pourquoi il faut dimensionner cette mémoire séparément.

Considérez les cartes de 24 Go, 48 Go et 80 Go comme des catégories à évaluer, sans garantie de résultat. Un petit modèle quantifié peut laisser une marge utile sur une carte de 24 Go. Un modèle plus gros, un contexte plus long ou davantage de requêtes simultanées peuvent imposer de passer à la catégorie suivante. Prévoyez une marge explicite par rapport au pic de mémoire observé, au lieu de dimensionner sur la plus petite requête réussie.

Le fine-tuning change le problème. Un entraînement complet ajoute les gradients, l’état de l’optimiseur et les activations sauvegardées. Les méthodes par adaptateurs mettent à jour un sous-ensemble plus réduit de paramètres, ce qui peut diminuer les besoins, mais elles ne suppriment pas tous les coûts mémoire. Une inférence réussie ne prouve pas que le fine-tuning complet tiendra sur la même carte. Consultez la décomposition de la mémoire d’entraînement et la présentation du fine-tuning économe en paramètres.

Examinez ensuite la variante du GPU et la compatibilité logicielle. La mention H100 au catalogue ne prouve pas que toutes les offres H100 aient le même format, la même configuration mémoire, la même allocation CPU ou la même interconnexion. Plusieurs GPU exigent aussi un framework capable de répartir efficacement le travail ; louer davantage de cartes ne résout pas automatiquement un traitement trop lent ou trop volumineux.

Terminez par le cycle de facturation complet. Pour chaque finaliste, distinguez le démarrage du calcul, le travail utile, l’attente des ressources maintenues prêtes, la suppression et le stockage conservé. Estimez un mois selon votre calendrier prévu, en incluant les périodes d’inactivité et les nouvelles tentatives. Une machine allouée en continu et un court traitement quotidien par lots demandent des budgets différents, même si le tarif horaire affiché est identique.

Quel fournisseur retenir selon votre situation ?

Le choix dépend d’abord du contrôle nécessaire sur l’environnement d’exécution, puis de l’intérêt de le maintenir prêt. Si une API prise en charge suffit à fournir la fonctionnalité, commencez par évaluer Together AI. Si votre propre code d’inférence est indispensable et que le trafic est irrégulier, comparez Modal à Runpod Serverless. Si vous avez besoin d’un environnement interactif ou d’une session de fine-tuning prolongée, commencez par les Pods Runpod et les instances Lambda.

Pour un traitement par lots capable de reprendre et dont la localisation est flexible, ajoutez Vast.ai. Pour un besoin de cluster connu, avec un responsable de l’exploitation, ajoutez CoreWeave. Si l’application dépend déjà d’un emplacement Google Cloud précis et d’une organisation d’exploitation existante, évaluez sa capacité GPU avant d’assumer le coût d’une migration vers un autre fournisseur.

La capacité réservée devient pertinente lorsque vous savez que le matériel restera utile sur toute la durée d’engagement et que sa disponibilité compte en elle-même. Ne réservez pas pour découvrir votre taux d’utilisation. Exécutez d’abord le traitement, établissez la demande qui subsiste pendant les périodes creuses et ne réservez que la capacité justifiée par ce socle.

Un service sensible à la latence peut aussi privilégier une capacité dédiée ou maintenue prête avec un volume de requêtes relativement faible. Faire attendre un client après chaque période creuse peut coûter plus cher qu’un worker inactif. Mesurez la première réponse après une période d’inactivité et les réponses les plus lentes pendant les pics ; une latence moyenne peut masquer ces deux problèmes.

Si vous hésitez encore à gérer vous-même un environnement GPU, le guide des puces d’inférence face aux GPU replace ce choix dans la question plus large du contrôle du matériel.

Comment cette sélection a-t-elle été établie ?

Les critères sont l’adéquation au traitement, une unité d’achat vérifiable, la mémoire disponible, le coût des données, le comportement au démarrage et l’accès régional. Les sept fournisseurs couvrent les API de modèles managées, les applications serverless personnalisées, la location directe de GPU, les places de marché et les clusters planifiés. Leur place dans le comparatif correspond à une recommandation par usage, pas à un classement universel de vitesse.

Les tarifs et les fonctionnalités ont été vérifiés sur les pages des fournisseurs le 30 octobre 2026. Aucun GPU n’a été loué et aucun test de débit ou de disponibilité n’a été réalisé pour ce comparatif. Les estimations du poids des modèles reposent sur des calculs explicites ; les recommandations de plateformes analysent leur fonctionnement documenté.

La sélection reste centrée sur les développeurs et les petites équipes IA. Des annuaires cloud plus larges, des intermédiaires d’achat et d’autres hyperscalers ajouteraient des noms sans remplacer la première décision : avez-vous besoin d’un endpoint de modèle, d’une machine ou d’un cluster ? Un fournisseur n’a sa place dans l’évaluation finale que s’il peut fournir la configuration requise à un endroit où vous pouvez l’utiliser.

Les choix à éviter selon votre usage

Évitez un mode d’achat inadapté à votre traitement, même si le fournisseur convient très bien à d’autres besoins.

• La capacité interruptible de Vast.ai pour un traitement qui ne peut ni reprendre ni être relancé sans risque. Validez la reprise avant d’accepter le risque d’interruption.
• Runpod Community Cloud si votre déploiement dépend du rattachement d’un volume réseau Runpod. Cette option de stockage est réservée aux Pods Secure Cloud.
• Modal avec une capacité ramenée à zéro si chaque première réponse doit respecter un objectif de latence strict et que vous n’avez pas mesuré l’initialisation. Budgétez une capacité maintenue prête ou modifiez le déploiement.
• Lambda 1-Click Clusters ou une réservation CoreWeave tant que le nombre de GPU utiles et la durée du traitement restent des estimations incertaines. Établissez d’abord la demande avec une location plus petite.
• Together AI serverless si le checkpoint requis ou le comportement d’exécution attendu sort du périmètre de l’API prise en charge. Évaluez ses offres dédiées ou un environnement GPU programmable.
• Le Free Trial de Google Cloud sans passage à un compte payant pour accéder immédiatement aux GPU. Ses restrictions sont explicites.

Questions fréquentes sur le cloud GPU

Quels sont les fournisseurs de cloud GPU ?

Les sept fournisseurs comparés ici sont Runpod, Lambda, CoreWeave, Vast.ai, Modal, Together AI et Google Cloud. Commencez par la catégorie de produit nécessaire : une API de modèles managée, du calcul serverless personnalisé, une machine à la demande, une location sur une place de marché ou une capacité de cluster réservée. Les sections consacrées aux fournisseurs expliquent où ces catégories se recoupent.

Peut-on utiliser un GPU dans le cloud gratuitement ?

L’offre Starter de Modal inclut des crédits de calcul mensuels limités, pas un accès GPU illimité, et les tokens des Shared Endpoints sont facturés séparément. Le Free Trial de Google bloque l’ajout de GPU jusqu’au passage à un compte payant, tandis que le Free Tier permanent exclut les GPU. Together AI exige explicitement un accès prépayé. Utilisez les crédits pour évaluer un traitement, pas comme plan de capacité pour la production.

Comment comparer les offres de cloud GPU ?

Comparez le même checkpoint, la même précision, les mêmes longueurs d’entrée et le même niveau de simultanéité, sur la variante exacte du GPU et la même taille d’allocation. Incluez le démarrage et l’inactivité facturés, le stockage, les transferts et les traitements échoués. Le résultat utile est le coût du travail terminé qui respecte vos exigences de latence et de reprise, pas le plus petit montant affiché à côté de « GPU-heure ».

La semaine prochaine, soumettez aux deux finalistes le même petit traitement et les mêmes critères d’acceptation. Relevez le pic de mémoire, le délai jusqu’au premier résultat utile, le débit de tâches terminées, la durée d’allocation facturée et les coûts qui subsistent après l’arrêt. Pour l’entraînement, répétez une reprise depuis un checkpoint sauvegardé ; pour l’inférence, testez une requête après inactivité et un pic de trafic. N’élargissez le déploiement qu’une fois ces résultats obtenus et concluants.

Recevez la checklist d’audit des workflows IA en entreprise et la newsletter pour les équipes opérationnelles.