GPU-Server mieten: 7 Anbieter für Training und Inferenz 2026

Wer GPU-Server mieten möchte, sollte zuerst den Einsatz klären: Runpod für eigenständiges Fine-Tuning, Modal für eigene serverlose Inferenz, Together AI für eine verwaltete Modell-API und Vast.ai für wiederaufnehmbare Jobs auf einem GPU-Marktplatz. Zu den 7 Anbietern in diesem Vergleich gehören außerdem Lambda für virtuelle GPU-Maschinen, CoreWeave für planbare Cluster-Kapazität und Google Cloud, wenn die Anwendung bereits auf dessen Infrastruktur aufbaut. Entscheidend sind zunächst der Speicherbedarf des Modells und die kostenpflichtige Laufzeit, nicht der niedrigste beworbene GPU-Tarif.

Preise und Produktdokumentation geprüft am 30. Oktober 2026. Die folgenden Preise sind die USD-Beträge, die an diesem Tag auf den Preisseiten der Anbieter standen. Der Vergleich stützt sich auf die Dokumentation; eigene Leistungsbenchmarks wurden nicht durchgeführt. Verfügbarkeit, Steuern und die konkrete Bereitstellung können den tatsächlichen Rechnungsbetrag verändern.

GPU-Server mieten: Welcher Anbieter passt zu welchem Einsatz?

Runpod gehört zuerst auf die Auswahlliste, wenn ein Modell direkt angepasst werden soll. Modal und Together AI sind erste Anlaufstellen für die Bereitstellung ohne dauerhaft betriebene GPU-Maschine. Eine bestimmte Region, durchgehend verfügbare Kapazität oder eine Batch-Umgebung, in der sich Jobs gut wiederaufnehmen lassen, können die Auswahl verändern.

Cloud-GPU-Preise vergleichen: Erst die Einheit, dann den Betrag lesen

Jeder Einstiegspreis bezieht sich auf ein bestimmtes Produkt und eine bestimmte Hardware. Die Angebote eröffnen den Zugang zu unterschiedlichen Diensten; sie stehen nicht für dieselbe Leistung. Ein reiner GPU-Zusatzpreis enthält die zugehörige virtuelle Maschine nicht. Bei einer serverlosen GPU-Sekunde fehlen separat abgerechnete Ressourcen. Und ein Tarif für dedizierte Inferenz ist kein Token-Preis für eine API.

Ein Marktplatzangebot kann verschwinden; die günstigste gelistete GPU kann für das Modell zu wenig Speicher haben. Die Testspalte beschreibt das geprüfte öffentliche Angebot, nicht sämtliche individuell vereinbarten Guthabenprogramme. Together AI setzt Vorauszahlung voraus. Google nennt seine GPU-Beschränkung ausdrücklich in den Free-Trial-Bedingungen.

Serverlose Inferenz: Eigener Code oder Modell-API?

Vor der GPU-Auswahl steht die Frage, ob die Modelllaufzeit selbst kontrolliert werden muss. Inferenz bedeutet, ein trainiertes Modell eine Antwort erzeugen zu lassen. Bei einer verwalteten API wird diese Antwort angefordert. Bei eigener serverloser Rechenleistung wird der Code bereitgestellt, der sie erzeugt. Diese Unterscheidung ist wichtiger als das Wort „serverless“, das beide Produkte verwenden.

1. Modal: Eigene Python-Inferenz bei schwankender Nachfrage

Modal ist eine serverlose Rechenplattform für containerisierte Anwendungen, die über Python bereitgestellt werden. Sie passt zu Teams, deren eigener Inferenzcode zum Produkt gehört. Ein Dienst zur Dokumentverarbeitung braucht beispielsweise eine eigene Vorverarbeitung, einen Modellaufruf und eine Nachverarbeitung innerhalb derselben Bereitstellung. Modal skaliert die Anwendung nach Bedarf. Zur bezahlten Laufzeit gehören allerdings auch Initialisierung und betriebsbereite Wartezeit, nicht nur die eigentliche Modellberechnung. Modal eignet sich, wenn die Laufzeit unter eigener Kontrolle bleiben soll, ohne dafür eine dauerhaft laufende VM zu betreiben.

Geeignet für: Python-Teams, die eigene Inferenz oder GPU-Jobs aus einer Warteschlange bei wechselndem Bedarf ausführen.
Besonderheit: Bereitstellung auf Anwendungsebene und automatische Skalierung mit separat erfassten Rechenressourcen.
Preise: T4-GPU-Rechenleistung ab $0.000164/Sekunde, zuzüglich CPU und Arbeitsspeicher; geprüft am 30. Oktober 2026 auf der Preisseite von Modal.
Kostenlos testen: Starter enthält $30/Monat Rechenguthaben. Tokenbasierte Shared Endpoints fallen nicht unter dieses Guthaben.

Die praktische Grenze zeigt sich bei der Antwortzeit nach einer Ruhephase. Ein Kaltstart umfasst die Vorbereitung eines neuen Containers, bevor er antworten kann. Containerstart, Bibliotheksimporte und das Laden der Modellgewichte sind unterschiedliche Schritte. Ein schnell gestarteter Container bedeutet noch kein sofort einsatzbereites Modell.

Modal bietet Einstellungen, um Container betriebsbereit zu halten und Reservekapazität vorzuhalten. Das kann die Antwortzeit verbessern, bindet aber weiterhin Ressourcen. Bei einem Assistenten für Kunden sollte deshalb sowohl die erste Anfrage nach einer Pause als auch der Betrieb während einer aktiven Sitzung getestet werden. Bei einer nächtlichen Extraktionswarteschlange kann die Wartezeit für die Initialisierung dagegen akzeptabel sein. Der Leitfaden zu Kaltstarts von Modal erläutert diese Abwägung.

Der Starter-Tarif setzt zudem eine konkrete Skalierungsgrenze: 3 Workspace-Nutzerplätze und 10 gleichzeitig genutzte GPUs. Das reicht für einen brauchbaren Pilotbetrieb. Eine Lastspitze mit vielen unabhängigen Workern kann die Parallelitätsgrenze jedoch erreichen, lange bevor die Monatskosten hoch erscheinen. Für persistente Volumes und ausgehenden Netzwerkverkehr gibt es Freikontingente und zusätzliche Gebühren darüber hinaus. Der Datenweg gehört deshalb in die Kalkulation.

Auch die Geografie verlangt eine bewusste Konfiguration. Modal unterscheidet zwischen der Region, in der ein Container läuft, und der Region, über die seine Anfragen geleitet werden. Die feste Bindung an eine Region erhöht den Preis durch einen Multiplikator. Ein Modell nahe der Datenbank hilft nur, wenn auch der Anfrageweg die Anforderungen an Latenz und Datenresidenz erfüllt. Die Dokumentation zur Regionsauswahl beschreibt beide Einstellungen.

2. Together AI: Wenn ein Modell-Endpunkt das Ziel ist

Together AI ist eine verwaltete Plattform für Inferenz und Training. Sie passt zu Teams, die eine modellgestützte Funktion ausliefern möchten, bevor sie sich um GPU-Infrastruktur kümmern. Ist das gewünschte Modell im Katalog, bietet sich die serverlose API als Einstieg an. Dedizierte Inferenz gibt mehr Kontrolle über die Hardware für die Modellbereitstellung. Die Grenze liegt bei der Anpassbarkeit: Eine API für unterstützte Modelle ist ein anderes Produkt als eine frei gestaltbare eigene Trainingsumgebung. Together AI eignet sich, wenn ein Modell-Endpunkt benötigt wird. Dedizierte Kapazität lohnt die Prüfung, sobald Anfragenvolumen oder Kontrollbedarf sie rechtfertigen.

Geeignet für: Teams, die unterstützte Modelle bereitstellen oder verwaltetes Fine-Tuning und dedizierte Inferenz nutzen.
Besonderheit: Ein Weg von der tokenbasiert abgerechneten API zur dedizierten Modellbereitstellung.
Preise: Dedizierte Inferenz auf NVIDIA HGX H100 ab $5.49/GPU-Stunde; serverlose API-Tarife hängen vom Modell ab. Geprüft am 30. Oktober 2026 auf der Preisseite von Together AI.
Kostenlos testen: Keine kostenlose Testphase; vorab gekauftes Guthaben ist erforderlich.

Die Abrechnungsmodelle müssen getrennt betrachtet werden. Serverlose Sprachinferenz wird nach Eingabe- und Ausgabetokens berechnet, also den Textbausteinen, die ein Modell verarbeitet. Bei dedizierter Inferenz fällt für jede einsatzbereite Replik minutengenaue Abrechnung an. Eine Replik ist eine laufende Kopie des Modelldienstes. Laut Dokumentation zählen Bereitstellung und Kaltstart nicht zur abgerechneten Rechenzeit dedizierter Inferenz. Eine einsatzbereite Replik kostet jedoch auch bei wenigen Anfragen weiter Geld. Erst das Herunterskalieren auf null beendet diese Rechenkosten. Die Dokumentation zur Abrechnung dedizierter Inferenz beschreibt die Abgrenzung.

Bei einer Supportanwendung mit unregelmäßigen Gesprächen vermeidet die serverlose API den Kauf ungenutzter Modellkapazität. Bei einer stark genutzten Anwendung mit bekanntem Lastprofil lohnt ein Vergleich mit dedizierten Repliken, jeweils mit denselben Prompts und Antwortlängen. Ein niedriger wirkender GPU-Tarif allein rechtfertigt keinen Wechsel. Erst gemessener Durchsatz macht daraus Kosten pro vollständig erzeugter Antwort.

Auch verwaltetes Fine-Tuning braucht eine eigene Kalkulation. Together führt adapterbasiertes LoRA und vollständiges Fine-Tuning auf. Die tokenbasierten Gebühren berücksichtigen Trainingsdurchläufe und Evaluation. Eine Epoche ist ein vollständiger Durchlauf durch den Trainingsdatensatz. Wird er wiederholt verarbeitet, steigt die Tokenmenge. Die Größe der hochgeladenen Datei allein bestimmt die Rechnung nicht.

Das GPU-Cluster-Angebot ist wiederum ein eigenes Produkt. Es umfasst On-Demand- und reservierte Kapazität; persistenter Speicher wird separat berechnet. Cluster-Reservierungen werden im Voraus bezahlt und sind nicht erstattungsfähig. Auch nach dem Löschen eines Clusters können aufbewahrte Volumes kostenpflichtig bleiben. Laut Cluster-Dokumentation sind eingehende und ausgehende Datenübertragungen kostenlos. Diese Regeln lassen sich nicht ohne Weiteres auf alle API-Produkte übertragen. Einzelheiten stehen in der Dokumentation zur Cluster-Abrechnung.

Für die Modellbereitstellung müssen Modell und Region gemeinsam geprüft werden. Ausgewählte serverlose Modelle unterstützen ausdrücklich Inferenz in den USA. Andere regionale Anforderungen sprechen eher für dedizierte Endpunkte. Die Antwortzeiten der gemeinsam genutzten API können mit der Nachfrage schwanken; Anwendungen benötigen weiterhin eine Behandlung fehlgeschlagener Anfragen mit Wiederholungsversuchen. Die Serverless-Dokumentation benennt diese Grenzen ausdrücklich.

On-Demand-Pods und virtuelle Maschinen für Fine-Tuning

Solange Trainingsskript, Abhängigkeiten oder Modell noch verändert werden, ist eine selbst kontrollierte Mietumgebung sinnvoll. Fine-Tuning passt ein vorhandenes Modell an eigene Daten an. Ein Pod oder eine virtuelle Maschine schafft Raum, Fehler zu untersuchen und den Job erneut auszuführen. Rechenleistung rechtzeitig zu beenden und Ergebnisse zu sichern, bleibt dabei die eigene Aufgabe.

3. Runpod: Der Einstieg ins eigenständige Fine-Tuning

Runpod bietet dedizierte GPU-Pods sowie separate Serverless- und Cluster-Produkte. Damit gehört es für kleine Teams, die eigene Modellabläufe entwickeln, auf die erste Auswahlliste. Nach der Wahl von GPU und Container-Vorlage lässt sich ein Fine-Tuning-Lauf durcharbeiten. Anschließend kann eine separate Serverless-Bereitstellung für die Inferenz geprüft werden. Die Grenzen sind konkret: Die Zuverlässigkeit der Community Cloud hängt vom Host ab, persistenter Speicher hat einen eigenen Lebenszyklus, und nach dem Stoppen eines Pods ist dieselbe GPU beim Fortsetzen nicht garantiert verfügbar. Runpod überzeugt durch Kontrolle und flexible Bereitstellungsoptionen. Daraus folgt kein Versprechen, dass dort jeder Job am günstigsten läuft.

Geeignet für: Entwickler, die einen GPU-Container für Experimente, Adapter-Fine-Tuning und die Entwicklung eigener Inferenz benötigen.
Besonderheit: Separate Pod- und Serverless-Produkte für Entwicklung und Modellbereitstellung.
Preise: Die aktuelle Preisseite nennt RTX-A5000-Pods mit 24 GB VRAM ab $0.27/Stunde; geprüft am 30. Oktober 2026 auf der Preisseite von Runpod.
Kostenlos testen: Auf der geprüften Preisseite war kein kostenloser GPU-Test aufgeführt.

Der Speicherbedarf sollte die Auswahl bestimmen, nicht der eindrucksvollste Chipname. Runpod führt Karten mit 24 GB, Optionen mit 48 GB wie die A40 und RTX A6000 sowie A100- und H100-Varianten mit 80 GB auf. Ein kleines Team kann so mehrere Speicherklassen prüfen, ohne sofort einen Cluster zu planen. Eine Rangfolge beim Durchsatz ergibt sich daraus nicht: Inferenz-Engine, Rechengenauigkeit des Modells und Batch-Konfiguration beeinflussen, welche Karte sich eher lohnt.

Auch Secure Cloud und Community Cloud verlangen unterschiedliche Entscheidungen. Runpod beschreibt Secure Cloud als Rechenzentrumsinfrastruktur und Community Cloud als Peer-to-Peer-Angebot mit schwankender Zuverlässigkeit. Ein wiederholbares Experiment kann andere Ausfälle verkraften als ein Dienst, der Kundenanfragen bearbeitet. Der Ressourcenpool sollte zu den Anforderungen an Wiederherstellung und Support passen. Der Leitfaden zur Pod-Auswahl von Runpod erläutert die Unterschiede.

Am ehesten überrascht bei der ersten Bereitstellung der Speicher. Der Container-Datenträger ist temporär. Ein Volume-Datenträger übersteht das Stoppen, aber nicht das Löschen des Pods. Ein Netzwerk-Volume bleibt unabhängig davon bestehen. Es ist jedoch nur für Pods in Secure Cloud verfügbar und bindet die Hardwarewahl an seinen Standort. Checkpoints ausschließlich auf temporärem Speicher abzulegen, verfehlt den Zweck der Sicherung. Die Dokumentation zu Netzwerk-Volumes erklärt diese Standortbindung.

Pods rechnen Rechenleistung sekundengenau ab. Nach den geprüften Pod-Preisregeln fallen keine Gebühren für eingehende oder ausgehende Datenübertragungen an. Speicher kann auch bei gestoppten Pods weiter kostenpflichtig sein. Serverless folgt einem anderen Lebenszyklus: Worker verursachen während der Initialisierung, Ausführung und Wartezeit Kosten, bis sie stoppen. Flex-Worker können auf null herunterskalieren; Active-Worker bleiben aktiv. Hier geht es darum, wie lange Ressourcen kostenpflichtig vorgehalten werden. Die Unterschiede reichen über bloße Tarifbezeichnungen hinaus. Näheres steht unter Pod-Abrechnung und Serverless-Abrechnung.

Die vollständige Übersicht für Tarife und Speicherkosten bietet der Runpod-Preisleitfaden auf dieser Website. Mit dieser Kalkulationsvorlage lassen sich wiederholte Läufe und dauerhaft betriebene Inferenz durchrechnen.

1. 1

   Den Job vor der Bereitstellung festlegen

   Den genauen Modell-Checkpoint, Inferenz- oder Fine-Tuning-Modus, die Rechengenauigkeit, die maximale Eingabelänge und die erwartete Parallelität festhalten. Die GPU-Speicherklasse muss neben der Modelldatei auch Platz für die Laufzeitumgebung bieten.

2. 2

   Zuerst den Speicherstandort wählen

   Benötigt der Job ein Netzwerk-Volume, dieses vor der GPU-Auswahl im vorgesehenen Rechenzentrum erstellen oder auswählen. Dort muss passende GPU-Kapazität verfügbar sein. Von unersetzlichen Trainingsdaten und Checkpoints eine separate Kopie aufbewahren.

3. 3

   Eine kompatible Vorlage bereitstellen

   In Pods die GPU und Container-Vorlage auswählen, die GPU-Anzahl festlegen und die Instanz auf Abruf starten. Den Filter für die CUDA-Kompatibilität des Hosts mit der Vorlage abgleichen. CUDA ist die Softwareplattform, auf der viele Anwendungen für NVIDIA-GPUs aufbauen.

4. 4

   Einen kleinen Probelauf durchführen und das Beenden prüfen

   Dieselben Schritte zum Laden, Trainieren und Schreiben von Checkpoints wie beim geplanten Job durchspielen. Den maximalen GPU-Speicherbedarf und die Laufzeit erfassen. Vor dem Stoppen oder endgültigen Beenden der Rechenressourcen prüfen, ob der Checkpoint auf persistentem Speicher liegt. Anschließend die verbleibenden Speicherkosten kontrollieren.

Diese Einstellungen sind unter Pods verwalten dokumentiert. Der Probelauf sollte zugleich die Wiederherstellung prüfen: Beim nächsten Start muss sich die Arbeit fortsetzen lassen, ohne auf genau die vorherige Maschine angewiesen zu sein.

4. Lambda: Die vertraute virtuelle Maschine mit GPU

Lambda ist eine GPU-Cloud mit virtuellen Linux-Maschinen und reservierbaren Clustern. Sie passt zu Teams, die für längere Trainingsläufe eine klassische Maschine bevorzugen. Die Umgebungen enthalten NVIDIA-Werkzeuge; der Instanzkatalog reicht von einzelnen GPUs bis zu größeren Konfigurationen. Entscheidend beim Kauf ist die gebuchte Größe: Dieselbe GPU kann je nach gemieteter Anzahl einen anderen Preis pro GPU haben. Lambda eignet sich für eine kontrollierte Trainingsumgebung. Bevor ein Tarif als Rechnungsbetrag gelesen wird, muss jedoch die ausgewählte GPU-Anzahl geprüft werden.

Geeignet für: Teams für Training und Fine-Tuning, die per SSH auf eine GPU-VM zugreifen möchten.
Besonderheit: Einzel-GPU-Instanzen und ein separates Angebot für reservierte Cluster.
Preise: Einzel-GPU-Instanzen beginnen bei $0.69/GPU-Stunde für eine Quadro RTX 6000 mit 24 GB VRAM; geprüft am 30. Oktober 2026 auf der Preisseite von Lambda.
Kostenlos testen: Auf der geprüften Preisseite war kein kostenloser GPU-Test aufgeführt.

Zum GPU-Katalog gehören die A6000 mit 48 GB sowie H100-Varianten mit PCIe und SXM und jeweils 80 GB. Die Bezeichnungen sind relevant. „RTX 6000“, „A6000“ und neuere Karten mit ähnlichen Namen sind nicht austauschbar. In den Bereitstellungsnotizen sollten der vollständige GPU-Name und die Speicherausstattung stehen, damit ein späterer Lauf nicht unbemerkt andere Hardware nutzt.

Lambda gibt On-Demand-Rechenleistung mit Stundenpreisen an, rechnet aber in Minutenschritten ab: vom erfolgreichen, betriebsbereiten Start bis zur endgültigen Beendigung. Eine laufende Maschine verursacht auch ohne Arbeit Kosten. Bei einem Trainingsjob muss sich das Abschaltverfahren deshalb nach dem Beendigungsablauf des Anbieters richten. Das Ende des Python-Prozesses beendet nicht automatisch die Miete. Die Abrechnungsdokumentation von Lambda beschreibt die Erfassung.

Persistente Dateisysteme erfordern einen weiteren Planungsschritt: Sie müssen beim Erstellen der Instanz angebunden werden und in derselben Region liegen. Solange sie bestehen, werden sie weiter berechnet, auch wenn sie nicht eingehängt sind. Laut Abrechnungsdokumentation fallen für eingehende und ausgehende Datenübertragungen des Dateisystems keine Gebühren an. Bevor ein großer Datensatz bereitgestellt wird, muss feststehen, dass GPU und Dateisystem am gewünschten Standort gemeinsam nutzbar sind. Die Instanzdokumentation von Lambda nennt die Regions- und Speicherregeln.

Reservierte Cluster liegen in einer anderen Größenordnung. Die öffentliche Tabelle für 1-Click Clusters beginnt bei 16 GPUs und einer Laufzeit von zwei Wochen. Das kann zu einer konzentrierten Trainingsphase passen. Als Einstieg ist es ungeeignet, solange noch unklar ist, ob eine Modellanpassung auf einer einzelnen GPU das Problem löst. Sinnvoller ist das kleinste tragfähige Experiment. Erst wenn es den erforderlichen Durchsatz erkennen lässt, sollte die Kapazität wachsen.

GPU-Marktplätze und unterbrechbare Instanzen

Unterbrechungsrisiko sollte erst eingekauft werden, wenn die Wiederaufnahme des Jobs nachweislich funktioniert. Ein Marktplatz bündelt Angebote verschiedener Hosts. Eine unterbrechbare Instanz kann pausiert oder vom Anbieter zurückgefordert werden. Beides kann zusammenkommen, doch eine On-Demand-Miete auf einem Marktplatz ist nicht automatisch unterbrechbar.

5. Vast.ai: Wiederaufnehmbare Jobs mit flexibler Standortwahl

Vast.ai ist ein GPU-Marktplatz, auf dem Hosts ihre Preise festlegen. Er eignet sich für Entwickler, die Angebote genau prüfen können und mit einem wechselnden Maschinenangebot zurechtkommen. Ein Batch-Job zur Erzeugung von Embeddings oder ein wiederholbares Fine-Tuning-Experiment passt gut, wenn Eingabedaten und Checkpoints unabhängig von der Instanz erhalten bleiben. Die Grenze liegt in der Kostenstruktur des einzelnen Hosts: Rechenleistung, Speicher und Datenübertragungen in beide Richtungen können getrennt berechnet werden. Vast.ai eignet sich, wenn sich die technische Umsetzung an das konkrete Angebot anpassen lässt. Einheitliches Verhalten aller Angebote sollte keine Voraussetzung sein.

Geeignet für: Kostenbewusste Experimente, Batch-Jobs und Training, das sich aus Checkpoints fortsetzen lässt.
Besonderheit: Auswahl auf Host-Ebene zwischen On-Demand-, reservierten und unterbrechbaren Mietangeboten.
Preise: Vom Host festgelegte GPU-Tarife mit sekundengenauer Abrechnung, zuzüglich Speicher und Datentransfer. Den Einstiegspreis für die konkrete Konfiguration zeigt die aktuelle Preisseite von Vast.ai, geprüft am 30. Oktober 2026.
Kostenlos testen: Auf der geprüften Preisseite war kein kostenloser GPU-Test aufgeführt.

Das günstigste Angebot ist nur brauchbar, wenn die Hardware zum Job passt. Der aktuelle Katalog von Vast.ai führt RTX 3090 und RTX 4090 mit 24 GB, L40S mit 48 GB und H100 SXM mit 80 GB auf. Zuerst sollten die benötigte Speicherausstattung und Software als Filter dienen. Danach folgen CPU, Arbeitsspeicher, Datenspeicher, Übertragungsbedingungen und Standort des konkreten Hosts.

Rechenleistung wird während des Betriebs sekundengenau erfasst. Speicher bleibt kostenpflichtig, solange die Instanz existiert, auch wenn sie gestoppt ist. Die Gebühren für Uploads und Downloads unterscheiden sich je nach Host. Eine günstige GPU, die ein großes Modell oder einen Datensatz wiederholt herunterladen muss, kann sich für einen kurzen Job deshalb schlecht rechnen. In den Vergleich gehört der gesamte Datenweg, nicht nur die Grafikkarte. Die Preisdokumentation von Vast.ai erklärt die Bestandteile.

Bei einem unterbrechbaren Trainingslauf reicht eine gespeicherte Modelldatei möglicherweise nicht aus, um korrekt weiterzutrainieren. Der vom Trainingsframework benötigte Zustand muss gesichert und der Wiederanlauf getestet sein. Für eine Batch-Warteschlange helfen stabile Job-Kennungen, damit Wiederholungsversuche keine für Kunden sichtbaren Ergebnisse duplizieren. Das sind Abnahmekriterien für die Wahl unterbrechbarer Kapazität. Sie besagen nicht, dass der Anbieter die Wiederherstellung übernimmt.

Vast.ai bietet auch serverlose Infrastruktur. Damit entfallen die Fragen zu Hosts und Datenkosten jedoch nicht: Die geprüfte Dokumentation beschreibt die Serverless-Abrechnung anhand der Rechen-, Speicher- und Bandbreitenkosten der Instanz. Dieser Vergleich konzentriert sich auf Marktplatzmieten. Sie sind der klarste Anwendungsfall für ein kleines Team, das diese Abwägungen selbst handhaben kann.

Reservierte Cluster und vorhandene Cloud-Infrastruktur

Kapazität sollte erst nach der Messung eines dauerhaften Bedarfs reserviert werden. Nähe zur bestehenden Infrastruktur ist sinnvoll, wenn ein Umzug mehr Aufwand verursachen als einsparen würde. Das sind unterschiedliche Gründe für die Wahl einer größeren Plattform. Beide können auch für kleine Teams gelten, ohne dass deren Bedarf die Größenordnung eines Hyperscalers erreicht.

6. CoreWeave: Für einen klar definierten Cluster-Bedarf

CoreWeave ist eine Cloud für KI-Infrastruktur mit verwaltetem Kubernetes auf Bare-Metal-GPU-Knoten. Sie passt zu Teams, die das Experimentierstadium hinter sich haben und ihren Rechenbedarf planen können. Kubernetes koordiniert Container über mehrere Maschinen hinweg. Es hilft, wenn diese Orchestrierung gebraucht wird und jemand dafür verantwortlich ist. Kleine Teams stoßen bei Zuteilung und Betrieb an Grenzen: Auch der Kauf ganzer Knoten und ein verwalteter Cluster brauchen einen klaren Einsatzzweck, einen Speicherplan und einen Betriebsverantwortlichen. CoreWeave gehört auf die Auswahlliste, wenn Kapazitätsplanung tatsächlich erforderlich ist. Um den Bedarf eines Modells erst herauszufinden, ist es keine Standardempfehlung.

Geeignet für: Teams mit bekanntem Cluster-Bedarf und der Fähigkeit, ihre Anwendungen unter Kubernetes zu betreiben.
Besonderheit: Verwaltetes Kubernetes auf Bare-Metal-Knoten mit Cluster-Vernetzung und Isolation.
Preise: Die Tabelle für Nordamerika nennt eine GH200-Instanz mit einer GPU für $6.50/Stunde. Reservierte Kapazität erfordert ein individuelles Angebot. Geprüft am 30. Oktober 2026 auf der Preisseite von CoreWeave.
Kostenlos testen: Auf der geprüften Preisseite war kein kostenloser GPU-Test aufgeführt.

Die Spalten auf CoreWeaves Preisseite verdienen genaue Aufmerksamkeit. Mehrere aufgeführte GPU-Instanzen enthalten 8 GPUs, darunter die Einträge für H100, H200, A100, L40 und L40S. Daneben nennt die Seite Inferenzpreise für einzelne GPUs. Eine Fußnote beschränkt diese Preise jedoch auf Kunden der Inferenzplattform. Den Knotenpreis durch die GPU-Anzahl zu teilen, ist für die Kostenrechnung nützlich. Es belegt aber nicht, dass sich dieser Bruchteil eines Knotens auch für einen gewöhnlichen Cluster-Job mieten lässt.

Die Preisseite trennt Nordamerika und Europa und führt On-Demand-, Spot- und reservierte Angebote auf. Für eine Reservierung müssen genaue Knotenkonfiguration, Bereitstellungsort, Bindungszeitraum und Kapazitätsbedingungen im Angebot stehen. Auch die Abrechnungstaktung sollte bestätigt werden: Ein öffentlich genannter Stundenpreis belegt noch keine sekundengenaue Abrechnung.

CoreWeave gibt Internet- und interne Datenübertragungen als kostenlos an. Speicher und öffentliche IP-Dienste haben eigene Gebühren. Anwendungen mit umfangreichen Datenbewegungen sind deshalb einen genaueren Blick wert. Trotzdem muss die gebuchte Rechenleistung tatsächlich gebraucht werden. Günstiger Datentransfer gleicht keinen Cluster aus, der den Großteil seiner Reservierungszeit ungenutzt bleibt.

Die Dokumentation zum CoreWeave Kubernetes Service beschreibt die verwaltete Steuerungsebene, Bare-Metal-Knoten, private Netze und GPU-Vernetzung. Für ein kleines KI-Team entscheidet vor allem die Zuständigkeit: Wer paketiert Jobs, überwacht Fehler, verwaltet Secrets und stellt den Betrieb wieder her? Ist das dieselbe Person, die noch den Nutzen der Anwendung prüft, führt ein einfacherer Pod oder eine API möglicherweise schneller zu einer funktionierenden Produktfunktion.

7. Google Cloud: Wenn die GPU zur bestehenden Anwendung passen muss

Google Cloud bietet virtuelle Compute-Engine-Maschinen mit GPU-Unterstützung. Das macht den Anbieter interessant, wenn Anwendung und Daten bereits dort liegen. Die Modellausführung nahe am übrigen System zu halten, kann die Bereitstellungsentscheidung vereinfachen, selbst wenn eine spezialisierte Cloud einen attraktiven GPU-Preis nennt. Die Hürde ist der Zugang: Maschinentyp, Region, Kontingent und tatsächliche Hardwareverfügbarkeit müssen zusammenpassen. Google Cloud eignet sich, wenn die Anwendung vom Standort und den bestehenden Betriebsabläufen profitiert. Der GPU-Einstiegspreis allein ist noch kein vollständiger Serverpreis.

Geeignet für: Entwickler, die eine bereits auf Google Cloud betriebene Anwendung um GPU-Aufgaben erweitern.
Besonderheit: GPU-Maschinenfamilien mit ausdrücklich ausgewiesener regionaler Verfügbarkeit und Kontingentsteuerung.
Preise: Eine T4 als Zusatzressource in Iowa beginnt bei $0.35/Stunde nur für die GPU, zuzüglich VM. Geprüft am 30. Oktober 2026 auf Googles Preisseite für Beschleuniger.
Kostenlos testen: Während des Free Trial lassen sich keine GPUs hinzufügen. Dafür ist ein Upgrade auf ein kostenpflichtiges Konto erforderlich.

GPU-Preise bei Google Cloud: Die VM kommt hinzu

Eine zusätzlich angebundene GPU ist eine weitere Ressource, keine vollständige Maschine. Die genannte T4 hat 16 GB GPU-Speicher. Braucht eine Anwendung mehr Speicher oder einen anderen Beschleuniger, muss die Kalkulation auf einer passenden Konfiguration beruhen und nicht auf diesem Einstiegstarif.

Google führt außerdem Maschinenfamilien mit integrierten GPUs auf: darunter G2 mit L4, A2 mit A100-Varianten sowie A3-Varianten mit H100 oder H200. Der Preis einer integrierten Maschine und der Preis einer zusätzlich angebundenen GPU decken unterschiedliche Leistungen ab. Der gewählte Maschinentyp gehört deshalb zusammen mit Speicher- und Netzwerkgebühren in die Kalkulation.

Compute Engine rechnet nach einer Mindestdauer von einer Minute sekundengenau ab. Eine laufende VM im Leerlauf bleibt kostenpflichtig. Auch Reservierungen können Gebühren verursachen, wenn die Ressourcen nicht gestartet sind. Verfügbarkeit zu reservieren ist daher eine andere Entscheidung als einen Job zu starten. Die Abrechnungsregeln von Compute Engine beschreiben diese Grenzen.

GPU-Verfügbarkeit bei Google Cloud: Das Kontingent ist nur eine Hürde

Ein gelisteter GPU-Typ garantiert nicht, dass ein Konto ihn heute in der gewünschten Zone starten kann. Google dokumentiert die GPU-Unterstützung nach Zonen. Kontingente werden unabhängig von der tatsächlich vorhandenen Kapazität verwaltet. Zuerst sollte die vorgesehene Maschine in der Liste der GPU-Regionen und -Zonen geprüft werden, anschließend die erforderlichen GPU-Kontingente.

Ein Team, das Kundenanfragen nahe seiner bestehenden Datenbank bearbeiten möchte, sollte beispielsweise akzeptable Standorte in der Nähe festlegen, bevor es eine GPU-Konfiguration anfordert. Fehlt in der gewünschten Zone die Kapazität, kann ein weiter entfernter Modellserver sowohl die Antwortzeit als auch den Datenübertragungsweg verändern. Diese Ausweichlösung ist eine Änderung an der Anwendung und muss getestet werden.

Für den Free Trial gilt eine eigene Einschränkung: GPUs lassen sich dort weder hinzufügen noch können Kontingenterhöhungen beantragt werden. Auch Googles dauerhaftes Free Tier schließt GPUs aus. Ein beworbenes Startguthaben belegt daher nicht, dass ein neues Konto sofort ein GPU-Experiment starten kann. Maßgeblich sind Googles eigene Bedingungen.

GPU-Hosting für KI auswählen: So wird der Bedarf ermittelt

Zuerst scheidet Hardware aus, auf die der Job nicht passt. Erst danach lohnt der Anbietervergleich. Im GPU-Speicher, häufig VRAM genannt, liegen das Modell und der für seine Ausführung benötigte Zustand. Ein Modell, das sich gerade noch laden lässt, kann an einem längeren Prompt oder einer zusätzlichen gleichzeitigen Anfrage scheitern.

Den Anfang macht eine Schätzung allein für die Modellgewichte. Bei 16 Bit benötigt jeder Parameter 2 Bytes, bei 4 Bit braucht das reine Gewicht ein halbes Byte. Ein Modell mit 8 Milliarden Parametern hat damit etwa 16 GB Gewichte bei 16 Bit oder 4 GB reine Gewichte bei 4 Bit. Bei 32 Milliarden Parametern sind es 64 GB beziehungsweise 16 GB, bei 70 Milliarden Parametern 140 GB beziehungsweise 35 GB. Das sind unsere Berechnungen in dezimalen GB, keine gemessenen Speicheranforderungen für den Inferenzbetrieb. Der Leitfaden zur Dimensionierung von Runpod liefert die zugrunde liegende Speicherregel.

Der zusätzliche Platzbedarf ist entscheidend. Die Inferenzlaufzeit braucht Arbeitsspeicher, und der KV-Cache hält während der Generierung den Zustand der Attention-Berechnung vor. Kontextlänge und parallele Anfragen beeinflussen dessen Umfang. Ein „35-GB-Modell“ bedeutet deshalb kein Gesamtbudget von 35 GB für die Bereitstellung. Die Cache-Dokumentation von Hugging Face erklärt, warum der Cache separat eingeplant werden muss.

Karten mit 24 GB, 48 GB und 80 GB sind sinnvolle Kategorien für die Prüfung, keine Garantien. Ein kleines quantisiertes Modell kann auf einer Karte mit 24 GB ausreichend Spielraum lassen. Ein größeres Modell, längerer Kontext oder mehr parallele Anfragen können die nächste Klasse erforderlich machen. Maßgeblich sollte eine ausdrückliche Reserve über dem höchsten beobachteten Speicherverbrauch sein, nicht die kleinste erfolgreiche Anfrage.

Fine-Tuning verändert die Rechnung. Vollständiges Training benötigt zusätzlich Gradienten, Optimiererzustände und gespeicherte Aktivierungen. Adapterbasierte Verfahren aktualisieren einen kleineren Teil der Parameter und können so die Anforderungen senken. Sämtliche Speicherkosten entfallen dadurch aber nicht. Ein erfolgreicher Inferenzlauf beweist daher nicht, dass vollständiges Fine-Tuning auf dieselbe Karte passt. Näheres erläutern die Aufschlüsselung des Trainingsspeichers und die Übersicht zu parametereffizientem Fine-Tuning.

Anschließend müssen GPU-Variante und Softwarekompatibilität geprüft werden. Ein H100-Eintrag beim Anbieter besagt nicht, dass jedes H100-Angebot dieselbe Bauform, Speicherkonfiguration, CPU-Zuteilung oder Verbindung zwischen GPUs bietet. Mehrere GPUs brauchen zudem ein Framework, das die Arbeit wirksam aufteilen kann. Zusätzliche Karten lösen einen zu langsamen oder zu großen Job nicht automatisch.

Zum Schluss folgt der gesamte kostenpflichtige Lebenszyklus. Für jeden verbliebenen Anbieter sind Startphase, nutzbare Rechenzeit, betriebsbereites Warten, Beendigung und aufbewahrter Speicher getrennt zu betrachten. Die Monatskalkulation sollte den erwarteten Zeitplan einschließlich Leerlauf und Wiederholungsversuchen abbilden. Eine durchgehend gebuchte Maschine braucht ein anderes Budget als ein kurzer täglicher Batch-Lauf, auch wenn beide denselben ausgewiesenen Stundenpreis haben.

GPU mieten: Welche Lösung passt zu welchem Team?

Die Auswahl hängt zuerst davon ab, ob die Laufzeit selbst kontrolliert werden muss. Danach zählt, ob es sinnvoll ist, sie betriebsbereit zu halten. Liefert eine unterstützte API die gewünschte Funktion, sollte Together AI zuerst geprüft werden. Ist eigener Inferenzcode unverzichtbar und schwankt die Nachfrage, lohnt der Vergleich zwischen Modal und Runpod Serverless. Für eine interaktive Umgebung oder einen längeren Fine-Tuning-Lauf sind Runpod Pods und Lambda-Instanzen die ersten Kandidaten.

Für wiederaufnehmbare Batch-Jobs mit flexibler Standortwahl kommt Vast.ai hinzu. Bei bekanntem Cluster-Bedarf und klarer Betriebsverantwortung gehört CoreWeave in den Vergleich. Hängt die Anwendung bereits von einem bestimmten Google-Cloud-Standort und den dortigen Betriebsabläufen ab, sollte zuerst dessen GPU-Kapazität geprüft werden, bevor Kosten für den Umzug zu einem anderen Anbieter entstehen.

Reservierte Kapazität wird sinnvoll, wenn die Hardware über den Bindungszeitraum hinweg nachweislich gebraucht wird und Verfügbarkeit selbst einen Wert hat. Reservieren sollte nicht dazu dienen, die Auslastung erst herauszufinden. Zuerst muss der Job laufen. Dann lässt sich ermitteln, welcher Bedarf auch in ruhigen Phasen bestehen bleibt. Nur die durch diese Grundlast gerechtfertigte Kapazität sollte reserviert werden.

Ein latenzempfindlicher Dienst kann auch bei vergleichsweise wenigen Anfragen von dedizierter oder betriebsbereit gehaltener Kapazität profitieren. Kunden nach jeder Ruhephase warten zu lassen, kann teurer sein als ein ungenutzter Worker. Gemessen werden sollten die erste Antwort nach Inaktivität und die langsamsten Antworten bei Lastspitzen. Ein Durchschnittswert kann beide Probleme verbergen.

Wer noch abwägt, ob eine eigene GPU-Laufzeit überhaupt nötig ist, findet im Vergleich von Inferenzchips und GPUs die grundsätzliche Entscheidung zur Hardwarekontrolle erläutert.

Nach welchen Kriterien wurden die Anbieter ausgewählt?

Entscheidend sind die Eignung für den Job, eine nachvollziehbare Abrechnungseinheit, passender Speicher, Datenkosten, Startverhalten und regionaler Zugang. Die sieben Anbieter decken verwaltete Modell-APIs, eigene serverlose Anwendungen, direkte GPU-Mieten, Marktplätze und geplante Cluster ab. Die Einordnung empfiehlt jeweils einen Anbieter für einen Einsatzzweck; sie ist keine allgemeine Rangliste der Geschwindigkeit.

Preis- und Funktionsangaben wurden am 30. Oktober 2026 anhand der Anbieterseiten geprüft. Für diesen Vergleich wurden keine GPUs gemietet und weder Durchsatz noch Verfügbarkeit getestet. Die Schätzungen für Modellgewichte sind ausdrücklich Rechenbeispiele. Die Plattformempfehlungen beruhen auf der Analyse dokumentierten Verhaltens.

Der Vergleich konzentriert sich auf Entwickler und kleine KI-Teams. Umfassendere Cloud-Verzeichnisse, Beschaffungsvermittler und weitere Hyperscaler würden die Liste verlängern, ohne die erste Entscheidung zu ersetzen: Wird ein Modell-Endpunkt, eine Maschine oder ein Cluster gebraucht? Ein Anbieter gehört nur dann in die abschließende Prüfung, wenn er die benötigte Konfiguration an einem nutzbaren Standort liefern kann.

Welche Angebote passen hier nicht?

Zu vermeiden ist das falsche Beschaffungsmodell für den eigenen Job, selbst wenn derselbe Anbieter in einem anderen Fall gut passt.

• Unterbrechbare Kapazität von Vast.ai für Jobs, die sich weder fortsetzen noch sicher wiederholen lassen. Die Wiederherstellung muss funktionieren, bevor Unterbrechungsrisiko eingekauft wird.
• Runpod Community Cloud, wenn ein Runpod-Netzwerk-Volume angebunden werden soll. Diese Speicheroption steht für Secure-Cloud-Pods zur Verfügung.
• Modal mit Skalierung auf null, wenn jede erste Antwort ein enges Latenzziel einhalten muss und die Initialisierung noch nicht gemessen wurde. Dann muss betriebsbereite Kapazität eingeplant oder die Bereitstellung geändert werden.
• Lambda 1-Click Clusters oder eine CoreWeave-Reservierung, solange die benötigte GPU-Anzahl und Laufzeit noch geschätzt werden. Der Bedarf sollte zuerst mit einer kleineren Miete belegt werden.
• Together AI Serverless, wenn der benötigte Checkpoint oder das gewünschte Laufzeitverhalten nicht zum unterstützten API-Produkt gehört. Dann sind die dedizierten Produkte oder eine programmierbare GPU-Umgebung zu prüfen.
• Google Clouds Free Trial ohne Konto-Upgrade als Grundlage für sofortigen GPU-Zugang. Die GPU-Beschränkungen sind ausdrücklich festgelegt.

Häufige Fragen zu Cloud-GPUs

Welche GPU-Cloud-Anbieter gibt es?

Dieser Vergleich umfasst die sieben Anbieter Runpod, Lambda, CoreWeave, Vast.ai, Modal, Together AI und Google Cloud. Der Einstieg erfolgt über die benötigte Produktkategorie: eine verwaltete Modell-API, eigene serverlose Rechenleistung, eine On-Demand-Maschine, eine Marktplatzmiete oder reservierte Cluster-Kapazität. Die Anbieterabschnitte zeigen, wo sich diese Kategorien überschneiden.

Gibt es kostenlose Cloud-GPUs?

Modals Starter-Tarif enthält begrenztes monatliches Rechenguthaben, keinen unbegrenzten GPU-Zugang. Tokengebühren für Shared Endpoints werden separat berechnet. Googles Free Trial sperrt das Hinzufügen von GPUs bis zum Upgrade auf ein kostenpflichtiges Konto; das dauerhafte Free Tier schließt GPUs aus. Together AI setzt ausdrücklich vorausbezahlten Zugang voraus. Guthaben eignet sich zur Prüfung eines Jobs, nicht als Kapazitätsplan für den Produktivbetrieb.

Wie lassen sich Cloud-GPUs sinnvoll vergleichen?

Verglichen werden sollten derselbe Checkpoint, dieselbe Rechengenauigkeit, dieselben Eingabelängen und dieselbe Parallelität auf der genauen GPU-Variante und mit derselben gebuchten Größe. Kostenpflichtige Start- und Leerlaufzeit, Speicher, Datentransfer und fehlgeschlagene Arbeit gehören dazu. Aussagekräftig sind die Kosten erfolgreich abgeschlossener Arbeit, die die Anforderungen an Latenz und Wiederherstellung erfüllt, nicht der niedrigste Betrag neben „GPU-Stunde“.

In der nächsten Woche sollten zwei Kandidaten denselben kleinen Job mit denselben Abnahmekriterien erhalten. Zu erfassen sind maximaler Speicherbedarf, Zeit bis zum ersten nutzbaren Ergebnis, Durchsatz abgeschlossener Jobs, abgerechnete Ressourcenlaufzeit und verbleibende Kosten nach dem Stoppen. Beim Training wird die Wiederaufnahme aus einem gespeicherten Checkpoint geprobt; bei der Inferenz eine Anfrage nach einer Ruhephase sowie eine Lastspitze. Erst wenn diese Ergebnisse dafürsprechen, sollte die Bereitstellung wachsen.

Die Checkliste für das KI-Workflow-Audit im Unternehmen und den Newsletter für Praktiker sichern.