RunPod Serverless vs Dedicated GPU 2026 – Was lohnt sich?

Inhaltsverzeichnis

Überblick: Der GPU-Markt 2026 im Wandel

Der Markt für Cloud-GPUs hat sich 2026 deutlich konsolidiert. NVIDIA H200, B200 und die neue B300-Generation dominieren die Rechenzentren, während ältere A100-Instanzen massiv im Preis gefallen sind. RunPod gehört zu den Anbietern, die diesen Hardware-Shift konsequent mitgehen und sowohl Serverless-Endpoints als auch dedizierte GPU-Container anbieten.

Die zentrale Frage 2026 lautet nicht mehr „Cloud oder On-Prem?", sondern „Serverless oder Dedicated?". Beide Optionen laufen in derselben Infrastruktur, unterscheiden sich aber fundamental im Abrechnungsmodell, in der Kontrolle und im operativen Overhead. Wer 2026 ein LLM hostet, ein Fine-Tuning durchführt oder Stable Diffusion in Produktion betreibt, muss diese Differenz verstehen.

Hinzu kommt: Mit dem Aufkommen von Spot-GPUs, Community Cloud und autoskalierenden Endpoints ist die Grenze zwischen „Serverless" und „Dedicated" fließender geworden. Genau hier setzt dieser Vergleich an – mit klaren Kriterien statt Marketing-Versprechen.

Im Kern gilt: Serverless maximiert die Kosteneffizienz bei sporadischen Workloads, Dedicated maximiert Kontrolle, Performance und Vorhersagbarkeit bei konstant hoher Last. Die Wahl ist eine Funktion Ihrer Traffic-Muster, Latenz-Anforderungen und Teamgröße.

Was ist RunPod Serverless?

RunPod Serverless ist ein ereignisgesteuerter GPU-Compute-Service. Sie stellen Ihren Code als Container-Image bereit, definieren einen Endpoint, und RunPod skaliert die Worker dynamisch zwischen null und einem konfigurierbaren Maximum. Sie zahlen nur für die tatsächliche Rechenzeit, gemessen in GB-Sekunden und CPU-Sekunden.

Das Modell ist inspiriert von AWS Lambda, bringt aber GPUs ins Spiel. Ein typischer Endpoint wird mit einem handler.py definiert, der Eingaben über eine HTTP-Schnittstelle entgegennimmt. RunPod übernimmt das Cold-Start-Management, das Image-Caching und das Autoscaling. Der Entwickler konzentriert sich ausschließlich auf die Inferenz-Logik.

Wichtig zu wissen: Serverless-Endpoints haben eine konfigurierbare Idle-Timeout (Standard 5 Sekunden). Wird dieser überschritten, fährt der Worker herunter. Bei einem neuen Request startet ein neuer Worker – das ist der sogenannte Cold Start. Für LLM-Inferenz mit kleinen Modellen ist das oft akzeptabel, für latenzkritische Echtzeit-Workflows kann es zum Problem werden.

RunPod bietet 2026 drei Serverless-Tiers: Standard, FlashBoot (optimierte Cold-Starts) und Priority (garantierte Worker-Verfügbarkeit). Letzterer ist neu und richtet sich an Produktionsworkloads mit SLA-Anforderungen. Die Preise variieren je nach GPU-Klasse zwischen 0,0002 USD und 0,004 USD pro GB-Sekunde.

Was ist RunPod Dedicated GPU?

Dedicated GPU (auch „Pods" genannt) bedeutet: Sie mieten eine physische oder virtuelle Maschine mit garantierten GPU-Ressourcen – stundenweise, täglich oder monatlich. Die Maschine läuft solange Sie buchen, unabhängig davon, ob sie ausgelastet ist. RunPod bietet eine riesige Auswahl: von der günstigen RTX 3090 bis zur H200 mit 141 GB VRAM.

Der Zugriff erfolgt per SSH, JupyterLab oder über das RunPod-Webterminal. Sie haben Root-Rechte, können eigene Docker-Container starten, Treiber anpassen, Volumes mounten und beliebige Software installieren. Das macht Dedicated GPUs zur ersten Wahl für Fine-Tuning, Distributed Training und Langzeit-Inferenz mit hohem Durchsatz.

2026 neu im Programm: Multi-GPU-Pods mit NVLink-Bridge sowie Cluster-Modi für verteiltes Training mit Horovod oder DeepSpeed. Auch Spot-Dedicated ist verfügbar – das sind dedizierte Instanzen mit bis zu 70 % Rabatt, die aber bei Kapazitätsengpässen abgeschaltet werden können. Ideal für Batch-Jobs und nicht-kritische Workloads.

Im Gegensatz zu Serverless zahlen Sie hier auch im Leerlauf. Das ist der größte Nachteil, aber auch der größte Vorteil: keine Cold Starts, keine Worker-Limits, keine Ratenbegrenzung. Wer eine konstante Auslastung von mehr als 60–70 % hat, fährt mit Dedicated GPUs fast immer günstiger.

Architektur-Unterschiede im Detail

Architektonisch sind die beiden Modelle grundverschieden. Serverless ist zustandslos, request-basiert und horizontal skalierend. Jeder Request wird an einen freien Worker geleitet; gibt es keinen, wird einer gestartet. Das System ist hochgradig elastisch, opfert aber Zustand und Latenzgarantien.

Dedicated GPU ist zustandsbehaftet, immer verfügbar und vertikal konfigurierbar. Sie haben eine Maschine, eine IP, ein Dateisystem. Wenn der Pod aus ist, ist er aus – Sie zahlen nicht. Aber wenn er an ist, kostet er. Diese Einfachheit ist gleichzeitig Stärke und Schwäche.

Ein weiterer Unterschied liegt im Networking. Serverless-Endpoints haben eine öffentliche HTTPS-URL, die von RunPods Edge geroutet wird. Dedicated Pods haben eine private IP innerhalb des RunPod-Netzwerks, das per WireGuard-Tunnel oder über einen Reverse-Proxy erreichbar gemacht werden kann. Für komplexe Multi-Service-Architekturen ist Dedicated die flexiblere Wahl.

Schließlich: Sicherheit. Serverless-Container laufen in einer Sandbox, der Code wird in einer eingeschränkten Umgebung ausgeführt. Bei Dedicated haben Sie vollen Systemzugriff – was einerseits mehr Flexibilität, andererseits mehr Verantwortung bedeutet. Für sensible Daten (Medizin, Finanzen) ist Dedicated oft die bevorzugte Option, ergänzt um VPC-Peering und Private Networking.

Tabelle 1: Architektur-Vergleich RunPod Serverless vs Dedicated GPU
Kriterium RunPod Serverless RunPod Dedicated GPU
Zustandsmodell Zustandslos (stateless) Zustandsbehaftet (stateful)
Skalierung Automatisch, 0–N Worker Manuell, 1 Pod = 1 Maschine
Zugriff HTTP-Endpoint SSH / Jupyter / Web
Root-Rechte Nein (Sandbox) Ja
Persistenz Container-Ephemer Volumes persistent
Netzwerk RunPod Edge / Public URL WireGuard / Private VPC
Cold Start Ja (2–30 s) Nein

Preismodelle 2026 im Vergleich

Die Preise auf RunPod haben sich 2026 erneut verändert. Mit der Markteinführung der B200-Generation sind die Preise für ältere Karten weiter gesunken, während neue GPUs anfangs Premium-Preise haben. Hier eine Übersicht der gängigsten Instanzen (Stand: Q1 2026, On-Demand):

Tabelle 2: Preisübersicht RunPod 2026 (On-Demand, USD/h)
GPU VRAM Dedicated / h Serverless (pro GB·s, ca.)
RTX 3090 24 GB 0,22 USD 0,00022 USD
RTX 4090 24 GB 0,44 USD 0,00040 USD
A100 80GB 80 GB 1,64 USD 0,00120 USD
H100 80GB 80 GB 2,49 USD 0,00190 USD
H200 141GB 141 GB 3,10 USD 0,00240 USD
B200 192GB 192 GB 4,99 USD 0,00380 USD

Die Serverless-Preise werden pro GB-Sekunde berechnet. Eine H100 hat 80 GB VRAM – ein Worker, der 10 Sekunden aktiv ist und 60 GB VRAM allokiert hat, kostet also 60 × 10 × 0,00190 = 1,14 USD. Hinzu kommen CPU-Sekunden und ggf. Storage-Kosten.

Spot-Preise sind deutlich günstiger: Dedizierte H100-Spots gibt es ab 0,89 USD/h, was ca. 65 % Rabatt entspricht. Allerdings können diese Instanzen mit kurzer Vorlaufzeit beendet werden. Für Training-Jobs mit Checkpointing ist das ein exzellenter Kompromiss.

Die Priority-Tier bei Serverless kostet ca. 40 % mehr pro Sekunde, garantiert aber eine Mindestanzahl warmer Worker und reduziert Cold-Starts auf unter 1 Sekunde. Für produktive LLM-APIs mit SLA ist dieser Aufschlag in den meisten Fällen gerechtfertigt.

Performance & Latenz im Vergleich

Performance ist der Bereich, in dem Dedicated GPUs klar dominieren. Ohne Cold Starts und mit garantierter Bandbreite zum Speicher (NVMe, NVLink) erreichen dedizierte Instanzen stabile Token-Raten und deterministische Antwortzeiten. Bei einem 70B-Parameter-LLM auf einer H100 ist eine Time-to-First-Token (TTFT) von 80–120 ms realistisch.

Serverless-Worker haben denselben GPU-Typ, aber die System-Latenz ist höher. Ein typischer Cold Start dauert je nach Containergröße 5–30 Sekunden. Mit FlashBoot und vorgewärmten Images lässt sich das auf 1–3 Sekunden reduzieren, was für viele Anwendungsfälle akzeptabel ist. Warme Worker liefern identische Performance wie Dedicated Pods.

Die Token-Durchsatz selbst ist vergleichbar. Eine H100 rendert 70B-Llama-Modelle mit ca. 80 Tokens/s im Streaming-Betrieb – unabhängig davon, ob sie in einem Pod oder einem Serverless-Worker läuft. Der Unterschied liegt nicht in der GPU, sondern im Wrapping: Serverless hat einen HTTP-Edge-Proxy, einen Job-Dispatcher und Container-Isolation, die je nach Konfiguration 5–20 ms Overhead pro Request verursachen.

Wer Echtzeit-Anwendungen mit Antwortzeiten unter 200 ms baut (z. B. Voice-Agents, interaktive Copilots), sollte Dedicated verwenden. Für asynchrone Verarbeitung, Batch-Jobs und APIs mit moderater Latenztoleranz ist Serverless die wirtschaftlichere Wahl.

Skalierbarkeit & Cold Starts

Skalierbarkeit ist die Kernstärke von Serverless. Ein Endpoint kann von 0 auf 100 gleichzeitige Worker skalieren – RunPod managt die Warteschlange, verteilt Last und beendet ungenutzte Worker automatisch. Das ist ideal für Workloads mit stark schwankendem Traffic: ChatGPT-ähnliche Tools, Bildgenerierung auf Abruf, On-Demand-Transkription.

Allerdings gibt es Grenzen. Standard-Endpoints sind auf 50 gleichzeitige Worker pro Endpoint limitiert;

Mistral Large & Mixtral 8x22B lokal hosten – MoE-Modelle selbst betreiben 2026
KI & LLM 07. June 2026 9 Min

Mistral Large & Mixtral 8x22B lokal hosten – MoE-Modelle selbst betreiben 2026

Mistral Large, Mixtral 8x7B & 8x22B selbst hosten: MoE-Architektur, GPU-RAM-Anforderungen, Quantisierung für Consumer-Hardware, Vergleichstabelle und Hardware-Leitfaden 2026.