Cloud Run GPU est désormais officiellement disponible et facilite l’exécution des workloads IA pour tous

 (cloud.google.com)
1 points par GN⁺ 2025-06-05 | 1 commentaires | Partager sur WhatsApp
  • La prise en charge des GPU est désormais officiellement disponible (GA) dans Cloud Run, ce qui facilite encore davantage l’exécution des workloads IA
  • Les GPU sont désormais aussi utilisables dans les Cloud Run jobs, ouvrant de nouvelles possibilités pour le traitement par lots et les tâches asynchrones
  • Un environnement optimisé pour les travaux par lots à grande échelle comme le traitement d’images, l’analyse du langage naturel et la conversion de médias

Cloud Run GPU : disponibilité générale et principaux changements

Début de la prise en charge des GPU NVIDIA dans Cloud Run jobs

  • La fonctionnalité GPU de Cloud Run était jusqu’à présent utilisée dans des services pilotés par les requêtes, comme l’inférence en temps réel
  • Désormais, la prise en charge des GPU dans les Cloud Run jobs est officialisée, ce qui permet de nouveaux cas d’usage
    • Affinage de modèle : réentraîner facilement un modèle préentraîné sur un jeu de données spécifique
    • Inférence IA par lots : adaptée aux travaux à grande échelle comme l’analyse d’images, le traitement du langage naturel ou la génération de recommandations
    • Traitement massif de médias : le transcodage vidéo, la génération de miniatures et la conversion d’images peuvent être réalisés efficacement à l’aide des GPU
  • Un Cloud Run job équipé d’un GPU réduit automatiquement ses ressources une fois le travail terminé, ce qui limite au minimum la charge de gestion

Retours d’expérience concrets des premières entreprises utilisatrices

  • vivo : Cloud Run accélère les cycles de développement itératif des applications IA et permet de réaliser d’importantes économies sur les coûts d’exploitation et de maintenance. Les capacités d’autoscaling des GPU ont considérablement amélioré l’efficacité du déploiement de l’IA sur les marchés internationaux
  • Wayfair : les GPU L4 offrent à la fois de fortes performances et un niveau de prix raisonnable. Combinés à l’autoscaling rapide de Cloud Run, ils ont permis de réduire les coûts d’environ 85 %
  • Midjourney : Cloud Run GPU est très utile pour le traitement d’images à grande échelle et, grâce à un environnement de développement simple et clair, permet de se concentrer sur l’innovation sans charge de gestion d’infrastructure. La scalabilité des GPU facilite l’analyse et le traitement de millions d’images

Démarrage et ressources

Conclusion

  • La disponibilité générale des GPU dans Cloud Run offre un potentiel d’extension majeur pour divers workloads spécialisés comme l’IA, le traitement par lots à grande échelle et la conversion de médias
  • De vraies entreprises ont déjà démontré les avantages en matière de coûts, d’efficacité opérationnelle et de scalabilité
  • Grâce à une configuration simple et à diverses ressources d’apprentissage, chacun peut facilement démarrer des workloads GPU dans le cloud

À lire aussi

1 commentaires

 
GN⁺ 2025-06-05
Avis Hacker News

  • J’aime vraiment beaucoup Google Cloud Run, au point de le recommander activement comme meilleur choix. En revanche, j’ai du mal à recommander Cloud Run GPU. La facturation par instance est inefficace, et les options GPU sont limitées. Le chargement/déchargement des modèles dans la mémoire GPU dégrade les performances, ce qui rend l’environnement serverless lent par nature. En comparant les coûts réels, dès 30 % d’utilisation par jour, la combinaison VM+GPU devient déjà plus économique. (lien de blog connexe)

    • VP chez Google. Merci pour le retour. Avec la structure tarifaire actuelle, je suis généralement d’accord sur le fait que lorsqu’un service a besoin d’une capacité quasiment fixe, préprovisionner des VM est plus rentable. En revanche, Cloud Run GPU me semble optimisé pour des environnements comme les nouveaux produits ou les applis d’IA qui connaissent soudainement une demande de pointe, avec un coût d’inactivité minimal, un démarrage très rapide et un trafic rare et irrégulier

    • Cloud Run donne vraiment l’impression d’être un excellent service. D’après mon expérience, c’est bien plus simple à utiliser qu’ECS/Fargate d’AWS

    • Le plus gros problème, c’est qu’on ne peut pas vraiment compter sur les VM dans GCP. Tous les grands clouds ont ce genre de souci. Sur AWS, impossible d’obtenir des GPU 80GB sans réservation longue durée, et les prix sont absurdes. GCP est pareil : cher et avec peu de disponibilité. Les grandes entreprises disent être startup-friendly, mais l’expérience réelle ne l’est pas. Les néo-clouds comme runpod, nebius, lambda, etc. offrent un bien meilleur service. J’ai l’impression que les grands clouds se reposent sur une demande captive et ne prennent pas les startups en compte, une erreur qui risque de nuire fortement à leur croissance à long terme

    • J’ai eu une expérience opposée avec Cloud Run. À cause de scale-out/redémarrages d’origine inconnue, j’ai fini par souscrire au support payant pour poser la question, mais je n’ai pas obtenu de réponse. J’ai finalement basculé vers des VM autogérées. Je ne sais pas si ça s’est amélioré depuis

    • À propos de l’idée que Cloud Run serait le meilleur, j’aimerais voir les chiffres par moi-même. C’est bien pour des projets jouets, mais en production c’est un gouffre financier. Sur l’un de mes projets, il y avait en permanence des problèmes d’autoscaling. Le scale to zero a l’air séduisant en théorie, mais en pratique plusieurs conteneurs se lancent souvent pour une seule requête pendant la phase de warm-up et restent actifs longtemps. On continue aussi à être facturé pour des conteneurs mystérieux sans usage CPU ou réseau visible. Les projets Java ou Python ont des cold starts terriblement lents ; je ne sais pas ce qu’il en est pour Go/C++/Rust, je n’ai pas d’expérience dessus

  • En plus de la complexité des grands clouds, il y a l’inquiétude d’une facturation YOLO illimitée qui peut vider la carte bancaire pendant la nuit. Conclusion : je vais continuer à rester chez Modal et vast.ai

    • Du point de vue des utilisateurs individuels ou de petits projets, le fait de ne pas proposer de plafond de coût (CAP) est une grosse faiblesse de GCP. Pour Cloud Run, on peut au moins limiter indirectement les coûts via des plafonds de concurrence et de nombre d’instances. Mais ça ne vaut toujours pas un vrai CAP

    • Je me souviens avoir payé très cher sur AWS après avoir oublié d’éteindre des instances, donc le scale to zero et la facturation à la seconde de Cloud Run sont de gros avantages. Si le démarrage est vraiment rapide, j’ai la conviction que ce serait parfait pour ma charge de travail

    • Sur Cloud Run, on peut indirectement plafonner le coût maximal via le paramètre de nombre maximal d’instances. Le hard cap de l’époque App Engine avait en pratique l’effet secondaire de faire s’arrêter totalement le service au moment même où il devenait populaire (par exemple quand il passait sur HN). Personnellement, je pense qu’une gestion budgétaire basée sur des alertes est un meilleur choix

    • C’est précisément pour cette raison que j’ai effectivement abandonné Datadog en production. Je me demande si cela vaut vraiment la peine, pour les plateformes, d’accepter l’impression négative créée quand les utilisateurs se retrouvent accidentellement surfacturés

    • Je ne vois pas clairement comment Modal ou vast.ai empêchent la facturation YOLO. Je me demande si c’est un modèle prépayé ou s’ils proposent un CAP explicite

  • En comparant directement les prix, je n’ai clairement pas l’impression qu’il y ait un vrai avantage. J’ai récapitulé dans un tableau les tarifs horaires de Google, runpod.io et vast.ai :

      1x L4 24GB:  google: $0.71, runpod.io: $0.43, 스팟: $0.22  
  4x L4 24GB:  google: $4.00, runpod.io: $1.72, 스팟: $0.88  
  1x A100 80GB: google: $5.07, runpod.io: $1.64, 스팟: $0.82, vast.ai $0.880, 스팟: $0.501  
  1x H100 80GB: google: $11.06, runpod.io: $2.79, 스팟: $1.65, vast.ai $1.535, 스팟: $0.473  
  8x H200 141GB: google: $88.08, runpod.io: $31.92, vast.ai $15.470, 스팟: $14.563

    Les prix de Google donnent l’impression d’être calculés pour une utilisation 24/7 sur un mois, alors que runpod.io et vast.ai facturent à la seconde. Je n’ai pas trouvé les tarifs spot des GPU de Google

    • On peut voir immédiatement les tarifs spot dans « créer une instance de calcul ». Par exemple, sur GCP, un 1xH100 spot est à $2.55 de l’heure, avec des remises qui s’appliquent en cas d’usage prolongé. En pratique, les clients entreprises peuvent aussi négocier des remises sur ces prix. Seuls les utilisateurs ordinaires paient ce tarif catalogue

    • Je me demande d’où viennent les tarifs vast.ai. Sur leur site, l’option 8xH200 semble plutôt être à partir de $21.65/h dans la plupart des cas

    • Je me demande sur quoi repose l’idée que les prix de Google seraient pensés pour du 24/7. D’après la page tarifaire officielle de Cloud Run, seule l’utilisation réelle est facturée par tranches de 100 ms, et l’autoscaling est aussi décrit comme réduisant automatiquement les instances inactives après 15 minutes d’attente (PM Cloud Run)

    • Je me demande si Cloud Run GPU ne permet pas seulement de choisir 1xL4

    • Si les prix de Google sont eux aussi facturés à la seconde, alors pour moins de 20 minutes d’utilisation Google pourrait au contraire être plus avantageux

  • Je suis un grand fan de Modal et j’utilise depuis longtemps des GPU serverless avec scale-to-zero. Il est facile de monter en charge à grande échelle quand c’est nécessaire, tout en réduisant nettement la charge de développement. C’est intéressant de voir un grand fournisseur entrer sur ce marché. Si je suis passé à Modal, c’est aussi parce que les grands clouds historiques n’offraient pas ce type de fonctionnalité (pas de GPU sur AWS Lambda). Je me demande si tous les grands clouds vont maintenant évoluer dans cette direction

    • Modal est vraiment excellent. J’ai aussi été impressionné par leur publication technique détaillée sur leur solveur LP (programmation linéaire). Pour les développeurs Python, je recommande aussi Coiled. Ce n’est pas aussi rapide que Modal, mais on peut lancer facilement des VM GPU, et tout s’exécute dans son propre compte cloud. Ils proposent une gestion de packages pratique, notamment pour synchroniser les drivers CUDA et les bibliothèques Python. (À noter : je travaille chez Coiled, mais je le recommande sincèrement)

    • Le fait qu’ils prennent aussi en charge des workloads conformes HIPAA est un avantage inattendu

    • Modal a les cold starts les plus rapides pour les modèles de plus de 10GB

    • J’ai aussi été impressionné par la qualité de la documentation de Modal

  • La principale raison pour laquelle Cloud Run est meilleur que les autres services, c’est l’autoscaling et le scale-to-zero. Quand il n’y a pas d’utilisation réelle, la facturation est pratiquement nulle, et on peut gérer de façon fiable le coût maximal en définissant un nombre maximum d’instances. En revanche, je parle ici uniquement de la version CPU ; elle est très fiable et très simple à utiliser

    • Cela dit, même Cloud Run classique a souvent des temps de démarrage à froid longs (environ 3 à 30 secondes), donc il y a des problèmes de latence lorsqu’on exploite le scale-to-zero

  • Le petit fournisseur européen de cloud GPU DataCrunch (sans lien avec moi) propose des VM GPU Nvidia moins chères que RunPod et consorts

    1x A100 80GB 1.37 euro/heure
    1x H100 80GB 2.19 euro/heure

    • Chez lambda.ai, une VM 1x H100 80GB est proposée à $2.49/h. Avec le taux de change, cela fait exactement 2.19 euros. Je me demande si c’est une coïncidence ou s’il existe une sorte de plafond invisible dans le secteur

    • Sur Vast.ai, on peut utiliser en P2P 2x A100 pour $0.8/h (soit $0.4/h par A100). Je ne suis qu’un utilisateur satisfait, rien de plus. Il faut toutefois faire attention à la vitesse réseau. Chez certains hôtes, la bande passante est partagée, donc la vitesse réelle peut différer de la promesse. Prudence si vous déplacez de gros volumes de données

  • VP/GM en charge de Cloud Run/GKE. Je suis prêt à répondre aux questions à ce sujet. Merci pour tout l’intérêt porté

  • J’aime Cloud Run et cette nouvelle fonctionnalité me semble intéressante. En revanche, un point frustrant était l’impossibilité d’exécuter des self hosted GitHub runners à cause des problèmes de privilèges root. Et la fonctionnalité plus récente de worker pool demandait aussi, en pratique, d’écrire soi-même le scaler au lieu de fournir une capacité intégrée

    • Eng Manager en charge de l’autoscaling serverless et des Worker Pools. Nous sommes en train de définir activement la roadmap, et ce serait très utile si vous pouviez nous envoyer par mail des exemples concrets de workloads. Nous sommes preneurs de retours sur les worker pools et les charges de travail qui nécessitent du scaling

  • Après avoir laissé tourner des modèles de test sur vertex.ai et oublié de les éteindre, ce qui m’a valu une facture de $1000, je pense que Cloud Run va devenir mon service de référence. J’exploite depuis des années des microservices de production et des projets perso sur Cloud Run, et je suis satisfait à la fois de sa simplicité et de son efficacité en termes de coût

  • Si j’ai bien compris, on peut créer une API qui expose n’importe quel modèle comme sur Hugging Face, sans tarification au token, tout en gardant un coût assez faible si la charge d’usage est modeste. Si c’est bien ça, c’est une vraie révolution. La plupart des fournisseurs existants imposent un abonnement mensuel pour exploiter des modèles personnalisés

    • C’est globalement exact. En revanche, les cold starts peuvent être très lents (30 à 60 secondes). C’est le revers du scale to zero. Il faut aussi noter qu’il existe quelques petits frais mensuels fixes, par exemple pour le stockage des conteneurs

    • Il existe aussi diverses alternatives prenant en charge l’inférence GPU serverless, comme Runpod, vast, coreweave, replicate, etc.