Cloud-GPU-Anbieter mit serverlosem GPU-Inferenz

Was “serverless” wirklich für Cloud-GPU-Inferenz bedeutet

Wenn ein Anbieter in der obigen Vergleichstabelle mit serverless: yes gekennzeichnet ist, bedeutet das, dass Sie GPU-Workloads ausführen können, ohne eine langlaufende Instanz mieten und verwalten zu müssen. Statt einen Knoten bereitzustellen, ihn warm zu halten und für jede Sekunde zu bezahlen, in der er untätig ist, setzen Sie einen Container oder einen Modell-Endpunkt ein, und die Plattform weist GPU-Kapazität bedarfsgerecht zu, skaliert die Anzahl der aktiven Worker je nach Traffic hoch und runter. Sie werden nur für die Zeit abgerechnet, in der Ihr Code tatsächlich auf einer GPU ausgeführt wird, oft bis auf die Sekunde oder Bruchteile davon, und häufig wird die Kapazität auf null skaliert, wenn keine Anfragen eingehen.

Dies ist ein grundlegend anderes Mietmodell als das klassische „eine virtuelle Maschine mit angehängter GPU starten“. Die serverlose Schicht abstrahiert den Host: Sie loggen sich nicht per SSH auf eine Maschine ein, wählen keinen Kernel aus und binden normalerweise keine spezifische physische Karte. Sie geben an, welche GPU-Klasse Sie benötigen, übergeben ein Image und einen Einstiegspunkt, und die Plattform übernimmt Platzierung, Autoskalierung und Abbau.

Warum serverless für echte Inferenz-Workloads wichtig ist

Serverless GPU ist auf Inferenz-Muster ausgelegt und nicht auf lange Trainingsläufe. Es zeigt seine Stärken, wenn Ihre Nachfrage sprunghaft, unvorhersehbar oder durchschnittlich niedrig, aber mit Spitzen ist – was die meisten produktiven KI-Funktionen beschreibt:

• Sprunghafter API-Traffic — ein Chatbot, Bildgenerator oder Embedding-Endpunkt, der um 3 Uhr morgens keine Anfragen erhält und zur Mittagszeit eine Flut. Sie zahlen nur für die beschäftigten Sekunden, anstatt einen GPU-Knoten rund um die Uhr laufen zu lassen.
• Viele kleine Modelle oder viele Mandanten — wenn Sie dutzende feinabgestimmte Varianten bedienen, ist es verschwenderisch, jedem eine ständig laufende GPU zu widmen; serverless lässt untätige Modelle nichts kosten.
• Ereignisgesteuerte Batch-Jobs — das Transkribieren einer hochgeladenen Datei, das Erzeugen eines Thumbnails oder das gelegentliche Ausführen eines Embedding-Jobs, bei dem eine Anfrage eingeht, Arbeit erledigt wird und der Worker verschwindet.
• Prototypen und Produkte in der frühen Phase — Sie vermeiden es, sich vorab auf reservierte Kapazitäten festzulegen, bevor Sie Ihre tatsächliche Traffic-Struktur kennen.

Die wirtschaftliche Logik ist einfach: Traditionelle Miete lässt Sie für bereitgestellte Zeit zahlen, während serverless Sie für genutzte Zeit bezahlen lässt. Wenn Ihre GPU-Auslastung im Durchschnitt deutlich unter Vollauslastung liegt, kann serverless dramatisch günstiger sein. Wenn Sie eine GPU rund um die Uhr nahe der Sättigung betreiben, ist eine dedizierte oder reservierte Instanz aus der obigen Liste meist das bessere Angebot.

Die Kompromisse: Cold Starts, Kontrolle und Grenzen

Scale-to-zero ist der Hauptvorteil und zugleich die Quelle des größten Nachteils. Wenn ein Worker abgebaut wurde, muss die nächste Anfrage auf einen Cold Start warten: Die Plattform plant eine GPU ein, lädt Ihr Container-Image, lädt Modellgewichte in den VRAM und initialisiert die Laufzeitumgebung. Bei einem mehrgigabytegroßen Modell kann dies bei der ersten Anfrage Sekunden bis zu mehreren zehn Sekunden zusätzliche Latenz bedeuten. Folgendes ist abzuwägen:

• Cold Start vs. Kosten — Das Vorhalten einer Mindestanzahl warmer Worker eliminiert Cold Starts, führt aber wieder zu Abrechnungen für Leerlaufzeiten. Viele Plattformen bieten eine Einstellung für „minimale Replikate“ oder einen Warm-Pool, mit dem Sie Latenz reduzieren können.
• Weniger Hardware-Kontrolle — Sie können typischerweise keine exakte Kartenrevision, NUMA-Layout oder benutzerdefinierten Treiber wählen. Sie fordern eine GPU-Klasse an und akzeptieren, was zugewiesen wird.
• Zustandslosigkeit — Worker können zwischen Anfragen verschwinden, daher ist lokaler Speicher flüchtig. Persistenter Zustand, Modell-Caches und große Gewichte liegen meist auf angebundenen Netzlaufwerken oder Objektspeichern, deren Unterstützung Sie bei der Plattform prüfen sollten.
• Ausführungsgrenzen — Serverless-Funktionen haben oft maximale Anfragedauern und Begrenzungen der Parallelität. Lange, mehrstündige Trainingsjobs sind ungeeignet und gehören auf dedizierte Instanzen.
• VRAM bleibt entscheidend — Serverless ändert nichts daran, dass Ihr Modell plus dessen KV-Cache in den GPU-Speicher passen müssen. Ein serverloser Worker der H100-Klasse ist immer noch ein H100; wählen Sie die Klasse entsprechend dem VRAM-Bedarf Ihres Modells.

Was man bei der serverlosen Dimension vergleichen sollte

Beim Lesen der obigen Liste sind die als serverless gekennzeichneten Anbieter nicht austauschbar. Prüfen Sie diese Details, bevor Sie sich festlegen:

1. Abrechnungsgranularität — pro Sekunde ist üblich, aber manche rechnen pro Anfrage oder pro 100 ms ab; feinere Granularität begünstigt kurze, sprunghafte Aufrufe.
2. Scale-to-zero-Verhalten — Fällt die Abrechnung wirklich auf null, wenn keine Last anliegt, und wie schnell skaliert die Plattform bei einem Traffic-Peak wieder hoch?
3. Cold-Start-Minderung — Warmpools, Snapshots, schnelle Image-Downloads oder Gewichtscaches reduzieren die Latenz bei der ersten Anfrage.
4. Angebotene GPU-Klassen — Die Bandbreite verfügbarer Karten (von Einstiegs-Inferenz-GPUs bis zu High-End-Beschleunigern) und der VRAM pro Klasse.
5. Parallelitäts- und Autoskalierungssteuerung — Maximale Workerzahl, Anfragen pro Worker und Warteschlangenverhalten unter Last.
6. Speicher und Netzwerk — Persistente Volumes für Gewichte und Egress-Kosten für das Herausbewegen von Ausgaben aus der Plattform.
7. Container vs. verwalteter Endpunkt — Ob Sie ein beliebiges Docker-Image mitbringen oder in eine eingeschränkte, vorgegebene Laufzeitumgebung deployen.

Für aktuelle Preise und die genauen GPU-Klassen, die jede serverlose Option bietet, verlassen Sie sich auf die obige Vergleichstabelle und nicht auf feste Zahlen, da sich Preis pro Sekunde und verfügbare Hardware häufig ändern.

Häufig gestellte Fragen

Ist serverless GPU immer günstiger als eine dedizierte Instanz zu mieten?

Nein. Serverless ist vorteilhaft, wenn Ihre GPU viel Zeit untätig ist, weil Sie dann nicht zahlen, wenn keine Arbeit läuft. Wenn Sie eine GPU rund um die Uhr stark auslasten, sind dedizierte On-Demand-, Spot- oder reservierte Instanzen aus der obigen Liste meist günstiger pro Recheneinheit, da Sie so den Overhead pro Anfrage und die Kosten für Warmpools vermeiden, die nötig sind, um die Latenz niedrig zu halten.

Kann ich serverless GPU auch für Training verwenden, nicht nur für Inferenz?

Im Allgemeinen ist es für vollständige Trainingsläufe ungeeignet. Serverless-Plattformen bevorzugen kurze, zustandslose Ausführungen und setzen oft maximale Anfragedauern und Parallelitätsgrenzen, während Training langlebige, zustandsbehaftete Knoten mit schnellem Multi-GPU-Interconnect benötigt. Kurze Feinabstimmungsjobs oder Batch-Inferenz sind möglich, aber großes Training ist besser für dedizierte Instanzen geeignet.

Was ist ein Cold Start und wie vermeide ich ihn?

Ein Cold Start ist die Verzögerung vor der ersten Anfrage, wenn die Plattform eine GPU zuweisen, Ihr Image laden und Modellgewichte in den VRAM laden muss. Sie reduzieren ihn, indem Sie eine Mindestanzahl warmer Worker vorhalten, kleinere oder quantisierte Modelle verwenden, Gewichte auf einem persistenten Volume cachen und einen Anbieter wählen, der schnelle Image-Downloads oder Snapshots unterstützt. Der Kompromiss ist, dass warme Worker wieder einige Leerlaufkosten verursachen.

Erlaubt serverless mir, das genaue GPU-Modell auszuwählen?

Normalerweise wählen Sie eine GPU-Klasse oder Kategorie statt einer spezifischen Kartenrevision. Die Plattform weist passende Hardware zu, daher prüfen Sie im obigen Vergleich, ob die von Ihnen gewählte serverlose Option eine Klasse mit ausreichend VRAM und der von Ihrem Modell benötigten Präzisionsunterstützung (wie FP16, BF16, FP8 oder INT8) bietet.