Cloud Run GPU jetzt offiziell unterstützt – AI-Workloads für alle einfacher ausführen

 (cloud.google.com)
1 Punkte von GN⁺ 2025-06-05 | 1 Kommentare | Auf WhatsApp teilen
  • Mit der offiziellen Unterstützung (GA) von GPUs in Cloud Run wird das Ausführen von AI-Workloads deutlich einfacher
  • Auch in Cloud Run jobs können nun GPUs genutzt werden, was neue Möglichkeiten für Batch-Verarbeitung und asynchrone Aufgaben eröffnet
  • Eine optimierte Umgebung für groß angelegte Batch-Jobs wie Bildverarbeitung, Analyse natürlicher Sprache und Medienkonvertierung

Cloud Run GPU: offizielle Verfügbarkeit und wichtigste Änderungen

NVIDIA-GPU-Unterstützung in Cloud Run jobs gestartet

  • Die GPU-Funktion von Cloud Run wurde bisher in anfragebasierten Services wie Echtzeit-Inferenz genutzt
  • Jetzt ist die GPU-Unterstützung auch in Cloud Run jobs offiziell verfügbar und ermöglicht neue Einsatzszenarien
    • Modell-Fine-Tuning: Vortrainierte Modelle lassen sich einfach erneut auf einen bestimmten Datensatz anpassen
    • Batch-AI-Inferenz: Geeignet für umfangreiche Aufgaben wie Bildanalyse, Verarbeitung natürlicher Sprache oder die Generierung von Empfehlungen
    • Medienverarbeitung in großem Umfang: Video-Transkodierung, Thumbnail-Erstellung und Bildkonvertierung lassen sich mit GPUs effizient ausführen
  • Ein mit GPU ausgestatteter Cloud Run job skaliert die Ressourcen nach Abschluss der Arbeit automatisch herunter und minimiert so den Verwaltungsaufwand

Reale Erfahrungen von Unternehmen aus der Frühphase

  • vivo: Cloud Run beschleunigt die iterative Entwicklung von AI-Anwendungen und spart Betriebs- und Wartungskosten erheblich. Die Auto-Scaling-Funktionen der GPUs haben die Effizienz beim AI-Einsatz in Überseemärkten deutlich gesteigert
  • Wayfair: L4-GPUs bieten gleichzeitig starke Leistung und ein vernünftiges Preisniveau. In Kombination mit dem schnellen Auto-Scaling von Cloud Run konnten die Kosten laut Erfahrung um etwa 85 % gesenkt werden
  • Midjourney: Cloud Run GPU ist für die Bildverarbeitung im großen Maßstab sehr nützlich. Dank der einfachen und klaren Entwicklungsumgebung kann man sich ohne zusätzliche Infrastrukturverwaltung auf Innovation konzentrieren. Durch die GPU-Skalierbarkeit lassen sich Millionen von Bildern leicht analysieren und verarbeiten

Einstieg und Ressourcen

  • Mit der GPU-Unterstützung in Cloud Run steht eine geeignete Umgebung für die Entwicklung von Anwendungen der nächsten Generation bereit
  • Über die offizielle Dokumentation, den Schnellstart-Leitfaden und Best Practices zur Optimierung kann jeder einfach loslegen
  • Es ist außerdem möglich, sich für die Teilnahme an der Private Preview von Cloud Run jobs mit GPU zu bewerben

Fazit

  • Die offizielle GPU-Unterstützung von Cloud Run bietet enormes Erweiterungspotenzial für verschiedene spezialisierte Workloads wie AI, groß angelegte Batch-Verarbeitung und Medienkonvertierung
  • Unternehmen belegen in der Praxis verschiedene Vorteile bei Kosten, Betriebseffizienz und Skalierbarkeit
  • Mit einfacher Konfiguration und vielfältigen Lernmaterialien kann jeder problemlos mit cloudbasierten GPU-Workloads starten

Verwandte Beiträge

1 Kommentare

 
GN⁺ 2025-06-05
Hacker-News-Kommentare

  • Ich mag Google Cloud Run wirklich sehr und empfehle es normalerweise aktiv als beste Option. Cloud Run GPU würde ich aber eher nicht empfehlen. Die instanzbasierte Abrechnung ist ineffizient, und die GPU-Optionen sind begrenzt. Wenn Modelle in den GPU-Speicher geladen und wieder entladen werden, leidet die Performance, wodurch Serverless-Umgebungen zwangsläufig langsam sind. Vergleicht man die realen Kosten, ist schon ab 30 % Auslastung pro Tag die Kombination aus VM + GPU wirtschaftlicher. (relevanter Blogpost)

    • Google-Vizepräsident hier. Danke für das Feedback. Ich stimme generell zu, dass bei der aktuellen Preisstruktur vorab bereitgestellte VMs kosteneffizienter sind, wenn die benötigte Servicekapazität nahezu konstant ist. Cloud Run GPU ist dagegen eher optimiert für neue Produkte oder AI-Apps mit plötzlichen Lastspitzen, mit minimalen Leerlaufkosten, sehr schnellem Start und seltenem, unregelmäßigem Traffic.

    • Cloud Run wirkt auf mich wie ein wirklich großartiger Service. Meiner Erfahrung nach ist es viel einfacher zu handhaben als AWS ECS/Fargate.

    • Das größte Problem ist, dass man VMs bei GCP nicht zuverlässig bekommen kann. Diese Probleme gibt es bei allen großen Clouds. Bei AWS bekommt man 80GB-GPUs ohne langfristige Reservierung praktisch nicht, und die Preise sind absurd. Bei GCP ist es genauso teuer und die Verfügbarkeit schlecht. Die großen Anbieter behaupten, startup-freundlich zu sein, aber meine tatsächliche Erfahrung ist eine andere. Neoclouds wie runpod, nebius und lambda liefern deutlich bessere Services. Große Clouds ruhen sich auf fixer Nachfrage aus und machen aus meiner Sicht einen Fehler, der ihrem langfristigen Wachstum schaden wird, weil sie Startups nicht ernsthaft berücksichtigen.

    • Ich hatte bei Cloud Run eher gegenteilige Erfahrungen. Wegen unerklärlichem Scale-out und Neustarts habe ich am Ende sogar kostenpflichtigen Support gekauft und nachgefragt, aber keine Ursache gefunden. Schließlich bin ich auf selbstverwaltete VMs umgestiegen. Ob es inzwischen besser geworden ist, weiß ich nicht.

    • Zu der Aussage, Cloud Run sei das Beste: Ich würde die Zahlen gern direkt sehen. Für Spielzeugprojekte ist es gut, aber in der Praxis ist es ein Kostensumpf. In Projekten gab es dauerhaft Autoscaling-Probleme. „Scale to zero“ sieht theoretisch gut aus, aber in der Realität starten während des Warm-ups oft mehrere Container für eine einzige Anfrage und bleiben dann lange aktiv. Es werden auch weiterhin Kosten für rätselhafte Container berechnet, obwohl keine sichtbare CPU- oder Netzwerknutzung vorliegt. Bei Java- oder Python-Projekten sind Cold Starts extrem langsam; mit Go/C++/Rust habe ich dazu keine Erfahrung.

  • Zusätzlich zur Komplexität großer Clouds gibt es noch die Sorge vor unbegrenzter YOLO-Abrechnung, bei der über Nacht die Kreditkarte leergeräumt werden kann. Ich werde deshalb wohl bei Modal und vast.ai bleiben.

    • Für Einzelpersonen und kleine Projekte ist das Fehlen einer Kostenobergrenze (CAP) eine große Schwäche von GCP. Bei Cloud Run kann man Kosten immerhin indirekt über Limits für Concurrency und Instanzanzahl begrenzen. An ein echtes CAP kommt das trotzdem nicht heran.

    • Ich habe bei AWS schon einmal hohe Kosten verursacht, weil ich vergessen hatte, eine Instanz zu beenden. Deshalb sind bei Cloud Run das scale to zero und die sekundengenaue Abrechnung ein großer Vorteil. Wenn der Start wirklich schnell ist, wäre das perfekt für meine Workloads.

    • Bei Cloud Run kann man über die maximale Instanzanzahl die maximalen Kosten indirekt begrenzen. Das frühere „harte CAP“ bei App Engine hatte den Nebeneffekt, dass der Service in dem Moment komplett stehenblieb, in dem er tatsächlich Traffic bekam, etwa nach einem HN-Post. Persönlich halte ich budgetbasierte Benachrichtigungen für die bessere Wahl.

    • Genau aus diesem Grund habe ich Datadog in Produktion wieder rausgeworfen. Ich frage mich, ob es den Plattformen den negativen Eindruck wirklich wert ist, wenn Nutzer versehentlich überhöhte Rechnungen bekommen.

    • Mir ist nicht klar, wie Modal oder vast.ai diese YOLO-Abrechnung verhindern. Sind sie prepaid, oder bieten sie ein direktes CAP?

  • Ich habe die Preise direkt verglichen und sehe ehrlich gesagt keinen klaren Vorteil. Die Stundenpreise von Google, runpod.io und vast.ai habe ich konkret in einer Tabelle zusammengefasst:

      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

    Die Google-Preise wirken auf mich, als seien sie für einen durchgehenden 24/7-Betrieb pro Monat gedacht, während runpod.io und vast.ai sekundengenau abrechnen. Einen Spot-Preis für Google-GPUs konnte ich nicht finden.

    • Unter „Compute-Instanz erstellen“ kann man die Spot-Preise direkt sehen. Zum Beispiel kostet 1xH100 Spot bei GCP $2.55 pro Stunde, und bei längerer Nutzung gibt es Rabatte. Unternehmenskunden können auf solche Preise oft noch zusätzliche Nachlässe bekommen. Nur normale Nutzer zahlen den Listenpreis.

    • Mich würde die Quelle für die vast.ai-Preise interessieren. Auf der Website scheint die 8xH200-Option meist bei mindestens $21.65 pro Stunde zu liegen.

    • Mich würde interessieren, worauf die Annahme basiert, dass Googles Preisgestaltung auf 24/7 ausgelegt ist. Auf der offiziellen Preisseite von Cloud Run steht, dass nur die tatsächliche Nutzung in 100-Millisekunden-Schritten abgerechnet wird, und beim Autoscaling wird erklärt, dass Leerlaufinstanzen nach 15 Minuten automatisch reduziert werden. (Cloud Run PM)

    • Ist es bei Cloud Run GPU nicht so, dass man nur 1xL4 auswählen kann?

    • Falls auch Google sekundengenau abrechnet, könnte Google bei weniger als 20 Minuten Nutzung sogar im Vorteil sein.

  • Ich bin ein großer Modal-Fan und nutze seit Langem serverless scale-to-zero GPUs. Man kann bei Bedarf leicht massiv hochskalieren, und gleichzeitig ist der Entwicklungsaufwand deutlich geringer. Ich finde es spannend, dass große Anbieter jetzt in diesen Markt einsteigen. Ich bin überhaupt zu Modal gewechselt, weil die bisherigen großen Clouds solche Funktionen nicht angeboten haben, etwa fehlender GPU-Support bei AWS Lambda. Ich frage mich, ob jetzt alle großen Clouds in diese Richtung gehen.

    • Modal ist wirklich großartig. Auch die tiefgehende Technik hinter dem selbst veröffentlichten LP-Solver war beeindruckend. Wenn man Python-Entwickler ist, kann ich auch Coiled empfehlen. Es ist nicht so schnell wie Modal, aber man kann GPU-VMs einfach hochfahren, und alles läuft im eigenen Cloud-Account. Dazu kommt bequemes Paketmanagement, etwa für die Abstimmung von CUDA-Treibern und Python-Bibliotheken. (Zur Einordnung: Ich arbeite bei Coiled, empfehle es aber ehrlich.)

    • Dass sogar HIPAA-konforme Workloads unterstützt werden, war ein unerwarteter Pluspunkt.

    • Modal hat bei Cold Starts mit Modellen über 10GB die höchste Geschwindigkeit.

    • Beeindruckend ist auch, wie gut die Modal-Dokumentation aufbereitet ist.

  • Der größte Vorteil von Cloud Run gegenüber anderen Services ist Autoscaling und scale to zero. Wenn es keine echte Nutzung gibt, liegen die Kosten praktisch bei null, und über die maximale Instanzanzahl lassen sich die maximalen Kosten stabil steuern. Das gilt allerdings nur für die CPU-Version; die ist sehr zuverlässig und einfach zu nutzen.

    • Allerdings hat auch normales Cloud Run oft lange Cold-Start-Zeiten beim Hochfahren, ungefähr 3 bis 30 Sekunden, wodurch bei Nutzung von scale to zero Latenzprobleme entstehen können.

  • Der kleine europäische GPU-Cloud-Anbieter DataCrunch (keine Verbindung) bietet Nvidia-GPU-VMs günstiger an als RunPod und andere

    1x A100 80GB 1.37 Euro/Stunde
    1x H100 80GB 2.19 Euro/Stunde

    • Bei lambda.ai gibt es 1x H100 80GB VM für $2.49 pro Stunde. Nach Wechselkurs sind das genau 2.19 Euro. Ich frage mich, ob das Zufall ist oder ob es in der Branche eine unsichtbare Preisobergrenze gibt.

    • Auf Vast.ai kann man im P2P-Modell 2x A100 für $0.8/Stunde nutzen, also $0.4/Stunde pro A100. Ich bin nur ein zufriedener Nutzer. Auf die Netzwerkgeschwindigkeit sollte man aber achten. Bei manchen Hosts wird die Bandbreite geteilt, sodass die tatsächliche Geschwindigkeit von der beworbenen abweichen kann. Bei großen Datenübertragungen ist Vorsicht nötig.

  • VP/GM für Cloud Run/GKE hier. Ich beantworte gern Fragen dazu. Danke für das große Interesse.

  • Ich mag Cloud Run, und die neue Funktion sieht auch interessant aus. Schade fand ich nur, dass ich dort keine self-hosted GitHub runners betreiben konnte, weil Root-Rechte ein Problem waren. Und die neu eingeführte Worker-Pool-Funktion war in der Praxis ebenfalls enttäuschend, weil man den Scaler selbst schreiben musste, statt eine eingebaute Funktion zu bekommen.

    • Eng Manager für Serverless und Worker Pools Autoscaling hier. Wir definieren die Roadmap derzeit sehr aktiv, und es wäre sehr hilfreich, wenn Sie mir per Mail konkrete Beispiele für echte Workloads schicken könnten. Ich freue mich über Feedback zu Worker Pools und Workloads, die Skalierung brauchen.

  • Nachdem ich bei vertex.ai versehentlich ein Modell für Tests weiterlaufen ließ und vergaß, es abzuschalten, bekam ich eine Rechnung über $1000. Deshalb wird Cloud Run diesmal wohl mein go to Service. Ich betreibe seit Jahren Produktiv-Microservices und Hobbyprojekte auf Cloud Run und bin sowohl mit der Einfachheit als auch mit der Kosteneffizienz zufrieden.

  • Wenn ich das richtig verstehe, könnte man also eine API bauen, die ein beliebiges Modell wie bei Hugging Face startet, ohne tokenbasierte Abrechnung, und bei geringer Nutzung dennoch recht günstig betreiben. Wenn das stimmt, wäre das ein großer Durchbruch. Bei den meisten bisherigen Anbietern braucht man für eigene Modelle ein Monatsabo.

    • Das stimmt im Wesentlichen. Allerdings können Cold Starts sehr langsam sein, etwa 30 bis 60 Sekunden. Das ist der Nachteil von scale to zero. Außerdem sollte man beachten, dass es noch einige kleine monatliche Gebühren gibt, etwa für Container-Storage.

    • Es gibt verschiedene Alternativen für serverless GPU-Inferenz, darunter Runpod, vast, coreweave und replicate.