—
günstigste Plattform / Monat—RunPod / Monat
—Baseten / Monat
—Modal / Monat
Kostenspanne – gleicher nominaler GPU-Preis in Höhe von $/Stunde
—
Abrechnungsaufschlüsselung nach Plattform
Dieselben Eingaben wie oben, angewendet über die unterschiedliche Abrechnungslogik jeder Plattform. In Rechnung gestellte Einheiten/Tag stellen die Rohmenge dar, die jede Plattform tatsächlich in Rechnung stellt – Sekunden für RunPod und Modal, Minuten für Baseten.
Monatliche Kosten nach Kaltstartrate (Verkehrsstoß)
Gleiche Eingaben für Dauer, Rate und Puffer wie oben, gestrichen für die Kaltstartrate – wie verteilt Ihre Anforderungen sind. Die hervorgehobene Zeile kommt Ihrer aktuellen Kaltstartrateneingabe am nächsten. Sehen Sie, wie sich die günstigste Plattform ändern kann, wenn der Verkehr zunimmt.
| Kaltstartrate | RunPod / Monat | Baseten / Monat | Modal / Monat | Günstigstes |
|---|
Wie dies mit anderen Tools verbunden ist
Dieser Rechner stellt eine konkrete, eng gefasste Frage: Wie lässt sich für BURSTY-Inferenzverkehr mit niedrigem QPS derselbe nominelle $/GPU-Stunde-Tarif in sehr unterschiedliche tatsächliche Rechnungen umwandeln, abhängig von den Abrechnungsmechanismen einer Plattform – pro Sekunde, pro Minute gerundet oder pro Sekunde plus Warmhaltepuffer? Es handelt sich bewusst nicht um eine pauschale GPU-Vermietung mit hoher Auslastung, bei der Sie unabhängig vom Anforderungsmuster für fortlaufende Stunden bezahlen – für diesen Rahmen siehe die GPU-Cloud-Kostenrechner und die GPU-Mietkostenrechner, die beide die GPU-Kosten als $/Stunde x genutzte Stunden behandeln. Dieses Tool gibt es genau deshalb, weil diese Pauschalberechnung bei sporadischen, zu Kaltstarts neigenden Workloads nicht funktioniert – ein internes Tool, das ein paar hundert Mal am Tag aufgerufen wird, verhält sich überhaupt nicht wie eine ausgelastete API, die eine GPU bei hoher Auslastung festhält, und der Unterschied in der Abrechnungsform zwischen den Plattformen zeigt sich erst, wenn Sie Kaltstarts und Leerlaufzeiten explizit modellieren, anstatt eine Flatrate in Stunden anzunehmen.
So funktioniert dieser Rechner
Der Abrechnungsrechner für serverlose GPU-Plattformen teilt Ihren täglichen Datenverkehr mithilfe von in zwei Buckets auf Kaltstartrate: kalte Anfragen (Anfragen pro Tag × Kaltstartrate) sind solche, die eintreffen, nachdem der Container auf Null skaliert wurde und den vollen Betrag bezahlen müssen Kaltstartdauer plus die warme Inferenzdauer; herzliche Anfragen (der Rest) trifft auf einen bereits beladenen Container und zahlt nur die Inferenzdauer. Jede Plattform wendet dann ihre eigene Abrechnungslogik auf diese beiden Buckets an. RunPod Rechnungen pro Sekunde für jede Sekunde, in der der Container aktiv ist – kalt oder warm –, sodass die tägliche Rechnung einfach die gesamten aktiven Sekunden ÷ 3.600 × Ihre beträgt GPU-Stundensatz. Baseten rechnet pro Minute ab und rundet jeden einzelnen Aufruf auf die nächste volle Minute auf, sodass selbst ein 3-sekündiger Warmanruf und ein 11-sekündiger Kaltanruf jeweils eine volle abgerechnete Minute verbrauchen; Die tägliche Rechnung beträgt die gesamten abgerechneten Minuten ÷ 60 × der Stundensatz. Modal rechnet wie RunPod pro Sekunde für die tatsächliche Rechenleistung ab, fügt jedoch hinzu Warmhalte-Leerlaufpuffer als zusätzlich abgerechnete Sekunden bei jeder Warm-Anfrage – der Container bleibt am Leben und berechnet dieses Pufferfenster, sodass die nächste Anfrage ihren eigenen Kaltstart überspringen kann.
Die sehenswerte Zahl ist die monatliche Kostenverteilung zwischen der günstigsten und der teuersten Plattform – in der vom Rechner selbst bearbeiteten Standardeinstellung (200 Anfragen/Tag, 3 Sekunden Warmstart, 8 Sekunden Kaltstart, 40 % Kaltstartrate, 2,49 $/Std.) beträgt diese Spanne ungefähr 9-10x zwischen RunPod und Baseten, mit genau der gleichen nominalen stündlichen GPU-Rate. Diese Lücke ist kein Preistrick – sie entsteht, wenn die typische Anrufdauer einer Arbeitslast (einige Sekunden) mit einer Abrechnungsgranularität kollidiert, die für längere Aufträge (eine ganze Minute) entwickelt wurde. Je kürzer und sporadischer Ihre Anrufe sind, desto wichtiger ist diese Form als der auf dem Aufkleber angegebene Stundensatz. Dieses Tool modelliert die MECHANIKEN, die von solchen Plattformen öffentlich dokumentiert werden – Abrechnung pro Sekunde, Rundung pro Minute, Warmhaltepuffer – als Näherung, um die Form des Unterschieds zu zeigen; Überprüfen Sie immer die aktuellen Preisseiten der Anbieter, bevor Sie sich verpflichten, da sich die genauen Preise und Rundungsregeln ändern können.
Häufig gestellte Fragen
Warum kostet Baseten bei gleicher GPU mehr als RunPod?
Nicht, weil die zugrunde liegende GPU-Rate unterschiedlich ist – in diesem Vergleich werden beide zum gleichen Preis pro Stunde abgerechnet –, sondern weil jede Plattform rund um die Uhr arbeitet. Die serverlose Abrechnung von RunPod erfolgt pro Sekunde: Sie zahlen genau für die Sekunden, in denen der Container aktiv ist, inklusive Kaltstart-Ladezeit und nichts weiter. Baseten rechnet pro Minute ab und rundet jeden Aufruf auf die nächste volle Minute auf. Ein warmer 3-Sekunden-Inferenzanruf wird immer noch als volle 60-Sekunden-Minute abgerechnet, und ein 11-Sekunden-Kaltstartanruf wird ebenfalls als dieselbe volle Minute abgerechnet, da beide auf 1 aufgerundet werden. Bei einer stoßartigen Arbeitslast mit niedrigen QPS, bei der die meisten einzelnen Anrufe nur wenige Sekunden lang sind, ist diese Rundung brutal: Sie zahlen effektiv für 15–20x mehr Rechenzeit, als Sie tatsächlich bei jedem einzelnen Anruf verbraucht haben. Die Lücke ist kein Preistrick, sondern eine reine Minutenrundung, die auf sehr kurze Aufträge angewendet wird, und sie vergrößert sich jedes Mal, wenn die Arbeitsbelastung so kurz und so häufig ist.
Was ist ein „Kaltstart“ und warum kostet er Geld?
Eine serverlose GPU-Plattform lässt einen Container nicht laufen (und stellt Ihnen keine Rechnung), wenn nichts passiert – sie skaliert den Container nach einer Zeit der Inaktivität auf Null, um Ihnen Geld für Leerlaufzeiten zu sparen. Der Nachteil besteht darin, dass die nächste Anfrage nach einer Skalierung auf Null darauf warten muss, dass ein brandneuer Container hochgefahren wird: Ziehen Sie das Container-Image, laden Sie die Modellgewichte auf die GPU, initialisieren Sie die Laufzeit und starten Sie erst dann die eigentliche Inferenz. Dieser Ladevorgang ist der „Kaltstart“ und dauert bei GPU-gehosteten LLM- oder Inferenz-Workloads normalerweise mehrere Sekunden bis mehrere zehn Sekunden, da Modellgewichte Gigabyte betragen können und ihre Verschiebung in den GPU-Speicher nicht sofort erfolgt. Entscheidend ist, dass es sich bei dieser Ladezeit nicht um kostenlose Rechenzeit handelt, die Ihnen gespendet wird – die GPU ist auf jeder hier modellierten Plattform vollständig zugewiesen und wird währenddessen abgerechnet, genau wie es bei der tatsächlichen Inferenz der Fall wäre. Jede Kaltstart-Anfrage kostet Sie also effektiv die Kaltstart-Sekunden PLUS die tatsächlichen Inferenz-Sekunden, und je verteilter (stoßartiger) Ihr Datenverkehr ist, desto mehr Ihrer Anfragen landen in einem kalten Container statt in einem noch warmen, und desto größer ist Ihre Gesamtrechnung aus reinem Lade-Overhead und nicht aus nützlicher Rechenleistung.
Sollte ich einen Warmhaltepuffer für meine Inferenzarbeitslast verwenden?
Es hängt davon ab, ob Sie die Latenz oder die Kosten optimieren, und diese beiden Ziele wirken sich bei stoßartigem Datenverkehr in entgegengesetzte Richtungen aus. Ein Warmhaltepuffer (hier als Modals Ansatz modelliert) hält den Container nach Abschluss jeder Anfrage für ein Fenster am Leben und lädt ihn. Wenn also die nächste Anfrage in diesem Fenster eintrifft, überspringt er den Kaltstart vollständig und antwortet schnell. Das ist ein echter Gewinn für das Benutzererlebnis bei latenzempfindlichem Datenverkehr. Sie zahlen jedoch den vollen GPU-Aktivpreis für jede Leerlaufsekunde, die der Container dort wartet, unabhängig davon, ob jemals eine weitere Anfrage rechtzeitig eintrifft oder nicht – das Modalmodell des Rechners fügt den Leerlaufpuffer als abgerechnete Sekunden für jede Anfrage hinzu, die von einem warmen Container profitiert. Bei sehr sporadischem Datenverkehr – lange, unvorhersehbare Pausen zwischen Anrufen – ist diese Leerlaufzeit meist verschwendetes Geld, da der Puffer ohnehin abläuft, bevor die nächste Anfrage angezeigt wird, und Sie dafür umsonst bezahlt haben. Warmhaltepuffer sind wirtschaftlich am sinnvollsten, wenn sich Anforderungslücken direkt innerhalb des Pufferfensters häufen; Bei wirklich zufälligem oder seltenem Datenverkehr ist es in der Regel günstiger, gelegentlich einen Kaltstart in Kauf zu nehmen, als dafür zu bezahlen, eine GPU warm zu halten, für den Fall, dass der nächste Anruf bald eintrifft.
Ist eine GPU-Abrechnung pro Sekunde oder pro Minute bei hohem Datenverkehr besser?
Bei stoßartigem Datenverkehr von kurzer Dauer ist die Abrechnung pro Sekunde fast immer besser, und je kürzer Ihr typischer Inferenzanruf im Verhältnis zu einer Minute ist, desto größer ist der Vorteil. Bei der Abrechnung pro Minute, die aufgerundet wird (wie hier das Modell von Baseten), wird eine volle Minute berechnet, unabhängig davon, ob die tatsächliche Rechenleistung 3 Sekunden oder 55 Sekunden gedauert hat – die Abrechnungsgranularität ist gröber als die Arbeitslast, sodass kurze Anrufe prozentual am stärksten belastet werden. Die Abrechnung pro Sekunde (wie hier der Active-Computing-Anteil von RunPod und Modal) berechnet nahezu genau das, was tatsächlich verbraucht wurde, sodass ein 3-Sekunden-Anruf etwa ein Zwanzigstel eines 60-Sekunden-Anrufs kostet und nicht den gleichen Betrag. Die Abrechnung an einer Stelle pro Minute stellt keinen klaren Nachteil mehr dar, wenn die typische Anrufdauer bereits nahe bei oder über einer Minute liegt – die Rundungsverschwendung schrumpft gegen Null, wenn sich die Anruflänge der Abrechnungsgranularität nähert. Bei einem internen Tool oder einer sporadischen API, die einige Hundert Mal am Tag aufgerufen wird und mehrere Sekunden antwortet, kann sich eine minutengerundete Abrechnung leicht als eine Größenordnung teurer erweisen als eine sekundengenaue Abrechnung bei identischem nominalen stündlichen GPU-Tarif.