RunPod Serverless (2026): Echte Preise & wann ein Pod günstiger ist

RunPod Serverless skaliert Ihren Endpunkt zwischen zwei Anfragen auf null und rechnet sekundengenau ab. Die Zahl, die dafür überall zitiert wird, $0.16/h, ist überhaupt kein Serverless-Preis: Das ist die Untergrenze des Pod-Katalogs. Der günstigste Serverless-Worker kostet $0.58/h, eine A100 liegt bei $2.72/h.

Dieser Unterschied ist erheblich, denn Serverless kostet für dieselbe Karte etwa das 1,5- bis 2,8-Fache des Secure-Cloud-Pod-Preises. Sie kaufen damit die Skalierung auf null, und die ist nicht umsonst.

Serverless-Preise nach GPU

Serverless-Preise geprüft gegen runpod.io/pricing am 3. August 2026, Pod-Preise gegen dieselbe Seite am 31. Juli 2026.

Entscheidend ist die Auslastung, nicht der Stundenpreis

Ein Pod läuft auf der Rechnung weiter, ob Anfragen eintreffen oder nicht. Serverless kostet nur, solange ein Worker aktiv ist. Die Frage lautet also nie, was pro Stunde günstiger ist, denn dieses Duell verliert Serverless immer, sondern wie viel vom Tag Ihr Endpunkt tatsächlich arbeitet.

Teilen Sie 1 durch den Faktor aus der Tabelle, und Sie erhalten die Auslastung, bei der beide gleich viel kosten:

• A40 48 GB bei 2,77×: ab 36 % Auslastung gewinnt der Pod
• RTX 4090 bei 1,59×: ab 63 %
• A100 80 GB bei 1,83×: ab 55 %
• H100 80 GB bei 1,52×: ab 66 %

Ein Endpunkt, der Anfragen zu Geschäftszeiten bedient, liegt schon per Definition bei rund 33 %, und genau deshalb passt Serverless dazu. Ein Batch-Job, der die GPU sechs Nachtstunden lang auslastet, liegt bei 25 % und passt ebenfalls. Alles, was rund um die Uhr konstanten Produktionsverkehr beantwortet, gehört auf einen Pod, und bei der A40 kippt das am frühesten.

Abgerechnet wird mehr als die Ausführung

Das ist der Punkt, der bei der ersten Rechnung überrascht. RunPod rechnet vom Start des Workers bis zu seinem vollständigen Stopp ab, aufgerundet auf die Sekunde, und zwar über drei Phasen: Container-Start, Ausführung der Anfrage und das anschließende Idle-Timeout. Standardmäßig sind das fünf Sekunden.

Rechnen Sie das für eine kurze Anfrage durch. Eine A100 kostet bei $2.72/h genau $0.000756 pro Sekunde. Eine Inferenz von 400 ms kostet Sie eben nicht 400 ms:

• Nur Ausführung: 0,4 s × $0.000756 = $0.0003
• Ausführung plus die voreingestellten 5 s Idle-Fenster: 5,4 s × $0.000756 = $0.0041

Sie zahlen also rund das 13,5-Fache der reinen Rechenzeit, und zwar noch vor jedem Cold Start. Dagegen helfen zwei Hebel. Bündeln Sie mehr Arbeit in eine Anfrage, damit die Ausführung den Leerlauf überwiegt, oder verkürzen Sie das Idle-Timeout. Letzteres erhöht allerdings die Wahrscheinlichkeit, dass die nächste Anfrage stattdessen einen Cold Start bezahlt. FlashBoot soll diesen Zielkonflikt entschärfen, indem kürzlich genutzte Worker warm gehalten werden.

Flex- und Active-Worker

Flex-Worker skalieren auf null, und auf sie beziehen sich die Preise oben. Active-Worker laufen rund um die Uhr und starten nie kalt. RunPod wirbt für sie mit bis zu 40 % Rabatt, wobei der konkrete Nachlass über den Vertrieb läuft und nicht auf der Preisseite steht.

Ein Active-Worker ist letztlich ein Pod mit Zusatzschritten, sofern Sie nicht wirklich das Request-Routing von Serverless brauchen. Wenn die Maschine ohnehin durchläuft, vergleichen Sie den Preis vorher mit einem Secure-Cloud-Pod.

Einen Endpunkt bereitstellen

RunPod zieht Ihr Image aus einer Registry, die Sie selbst kontrollieren. Es gibt keine RunPod-eigene Registry zum Hochladen, worüber Anleitungen älteren Datums regelmäßig stolpern.

1. Container mit Handler bauen, nicht mit Webserver. Das Python-SDK von RunPod umschließt Ihre Inferenzfunktion; FastAPI oder Flask brauchen Sie dafür nicht, und eine Node/Express-Anwendung hat hier grundsätzlich das falsche Format.
2. Zu Docker Hub oder GHCR pushen, öffentlich oder mit Zugangsdaten, die Sie RunPod hinterlegen.
3. Endpunkt anlegen, auf das Image-Tag zeigen und GPU-Klassen auswählen. Mehrere Klassen erlauben dem Scheduler ein Ausweichen, wenn Ihre erste Wahl gerade nicht verfügbar ist.
4. Worker-Grenzen und Idle-Timeout setzen. Die maximale Worker-Zahl deckelt die Kosten, das Idle-Timeout ist der Hebel aus dem Abschnitt oben.
5. Modellgewichte ins Image oder auf ein Network Volume legen. Ein 14-GB-Checkpoint, der bei jedem Cold Start neu geladen wird, ist der häufigste Grund, warum ein günstiger Endpunkt teuer wird.

Zum Testen genügt curl gegen die Route /runsync für kurze Jobs und /run für alles, was das Anfrage-Timeout überdauert.

FAQ

Kostet RunPod Serverless $0.16 pro Stunde?

Nein. Dieser Wert ist der günstigste Pod im Katalog und kein Serverless-Worker. Serverless beginnt bei $0.58/h für die 16-GB-Klasse und reicht bis $9.98/h für eine B300. Vergleiche, die $0.16/h gegen andere Serverless-Plattformen stellen, vergleichen zwei verschiedene Produkte.

Warum ist meine Rechnung höher als die gemessene Inferenzzeit?

Weil die Ausführung nur eine von drei abgerechneten Phasen ist. Bezahlt werden außerdem der Container-Start und das Idle-Timeout nach jeder Anfrage, standardmäßig fünf Sekunden. Bei Inferenzen im Subsekundenbereich kann dieses Leerlauffenster eine Größenordnung teurer sein als die eigentliche Arbeit.

Wann sollte ich stattdessen einen Pod nehmen?

Bei den meisten Rechenzentrumskarten oberhalb von etwa 55 bis 65 % Auslastung, bei einer A40 bereits ab 36 %. Ermitteln Sie, welchen Anteil des Tages Ihr Endpunkt tatsächlich rechnet, und halten Sie das gegen die Faktoren in der Tabelle. Konstanter Verkehr rund um die Uhr gehört auf einen Pod.

Brauche ich ein Web-Framework im Container?

Nein. Das Handler-Modell erwartet eine Funktion, die ein Job-Payload entgegennimmt und ein Ergebnis zurückgibt; HTTP, Warteschlange und Skalierung übernimmt RunPod darum herum. Flask oder FastAPI im Worker doppeln Infrastruktur, für die Sie ohnehin schon bezahlen.

Wie sich die zugrunde liegenden Pod-Tarife aufschlüsseln, zeigt der Vergleich RunPod Community vs. Secure Cloud, das gesamte Feld der große GPU-Cloud-Vergleich.