Verarbeite ich dauerhaft mehr als ~1 Milliarde Tokens pro Monat, mit genug Gleichzeitigkeit, um einen Batch gefüllt zu halten?

Wenn mein Traffic stoßartig ist oder ich rate, ist die Antwort nein, und die Leerlaufzeit wird mich begraben. 2. Gibt es einen Nicht-Kosten-Grund — Datenschutz, Residenz, ein Modell, das niemand hostet? Wenn ja, kann Self-Hosting unabhängig von der Mathematik obligatorisch sein, also höre ich auf, für Dollar zu optimieren. 3. Ist meine Zeit weniger wert als die API-Rechnung, die ich sparen würde? Normalerweise nicht. Der Ops-Overhead ist der wahre Preis, und er wird in der knappsten Ressource, die ich habe, bezahlt. Für mich, bei einem Solo-Produkt mit stoßartigem Traffic, zeigen alle drei neuerdings in dieselbe Richtung: Pro Token bezahlen, Frontier-Qualität behalten und meine Stunden damit verbringen, das zu bauen, wofür die Leute wirklich bezahlen. Ich werde die H100 wieder mieten, wenn meine Batch-Warteschlange voll ist und voll bleibt. Bis dahin war die Leerlauf-GPU das teuerste Nichts, das ich je gekauft habe.

Wann Self-Hosting eines Open-Weight-Modells die API wirklich schlägt

Letzten Monat startete ich eine H100 auf RunPod, lud ein 70B Open-Weight-Modell und ließ mein eigenes Produkt darauf zugreifen. Ich hatte mich selbst überzeugt, dass die Rechnung für die gehostete API langsam absurd wurde und dass der Besitz eigener Inferenz der erwachsene Schritt war. Der Pod lief neun Tage, bevor ich ihn abschaltete.

Dann öffnete ich die Abrechnungsseite. Ich hatte neun Tage GPU bezahlt. Mein tatsächlicher Traffic hatte vielleicht vierzig Minuten davon genutzt. Den Rest verbrachte die GPU im Leerlauf, mit drehenden Lüftern, und rechnete mir per Millisekunde für das Nichtstun ab.

Das ist die gesamte Falle in einem Screenshot. Die GPU kümmert sich nicht darum, ob du Tokens verarbeitest oder nur ein Dashboard anstarrst. Sie rechnet gleich ab. Und die Per-Token-API, der ich entkommen wollte, berechnet nur dann etwas, wenn tatsächlich Arbeit stattfindet.

Also setzte ich mich hin und rechnete die Mathematik ordentlich durch. Das habe ich gefunden, mit echten Zahlen aus 2026.

Die Kurzversion

Self-Hosting eines Open-Weight-Modells schlägt eine gehostete API bei den Kosten nur, wenn du die GPU wirklich ausgelastet hältst — ungefähr 40–60% Auslastung oder höher, dauerhaft, über Wochen. Darunter frisst die Leerlaufzeit jeden Dollar, den du zu sparen glaubst, und du zahlst auch noch mit deiner eigenen Ops-Zeit dafür. Für die meisten Solo-Builder gewinnt die Per-Token-API die meiste Zeit sowohl bei den Kosten als auch beim geringeren Aufwand. Der Schnittpunkt ist real, liegt aber bei einem Traffic-Volumen, das die meisten von uns noch nicht erreicht haben.

Was das GPU-Mieten wirklich kostet

Lass mich die Zahlen verankern, denn das gesamte Argument dreht sich darum. Stand Mitte 2026 liegt die On-Demand-Miete einer H100 80GB bei rund $2,89/Stunde auf RunPod und $2,99/Stunde auf Lambda. Auf einem Marketplace wie Vast.ai findet man H100 ab ungefähr $1,47/Stunde, und Consumer-Karten wie die RTX 4090 kosten ab etwa $0,29–0,69/Stunde je nach Host und Tier. Die A100 80GB liegt bei rund $1,39/Stunde auf RunPod.

Nehmen wir den günstigen, aber ehrlichen Fall: eine H100 für $2,89/Stunde bei einem zuverlässigen Host. Rund um die Uhr für einen Monat betrieben, sind das etwa $2.080. Diese Zahl ändert sich nicht, egal ob du zehn Anfragen oder zehn Millionen bedienst. Es ist ein Fixkostenblock, sobald der Pod läuft.

Das ist die Zahl, die jede Gewinnschwellen-Berechnung übertreffen muss.

Tokens pro Sekunde ist der Punkt, wo der Traum auf die Bandbreitenmauer trifft

Der Verkaufspitch für Self-Hosting lautet "kostenlose Tokens nach der GPU." Aber die GPU produziert nur so schnell Tokens, wie ihre Speicherbandbreite es erlaubt, und ein Modell der 70B-Klasse ist schwer.

Realistische Durchsatzzahlen, nicht Marketing-Zahlen: Eine einzelne H100, die ein 70B-Modell bei moderaten Batch-Größen bedient, kommt im Zehner-Bereich von Tokens pro Sekunde pro Anfrage. Über einen kleinen Cluster verteilt geht es besser — ein 4×A6000 vLLM-Benchmark zeigt einen aggregierten Durchsatz von etwa 420–470 Token/Sek für ein 70B-Modell unter Batch-Last (Qwen2.5 erreichte dort 449 Tok/s). Kleinere Modelle auf einer einzelnen Consumer-Karte sind schneller: Eine RTX 4090 schafft ungefähr 104 Tok/s bei einem 8B-Modell und 69 Tok/s bei einem 14B bei niedriger Gleichzeitigkeit.

Das Wichtigste zum Verinnerlichen: Der Durchsatz steigt mit Batching. Eine H100, die eine Anfrage nach der anderen bedient, ist extrem ineffizient. Dieselbe H100, die sechzehn gleichzeitige Anfragen bedient, produziert ein Vielfaches an Tokens für dieselben stündlichen Kosten. Die Wirtschaftlichkeit von Self-Hosting steht und fällt damit, ob du genug gleichzeitigen Traffic hast, um diesen Batch gefüllt zu halten.

Das konkrete Beispiel

Lass mich es mit einem 70B Open-Weight-Modell konkretisieren, denn das ist die Größe, bei der Menschen tatsächlich Self-Hosting in Betracht ziehen, um Frontier-API-Preisen auszuweichen.

Die API-Seite. Gehostete Anbieter bedienen Llama 3.3 70B jetzt günstig. Artificial Analysis zeigt gemischte Preise von etwa $0,12/Mio. Token am unteren Ende (DeepInfra Turbo FP8) bis über $1/Mio. am oberen Ende, mit DeepInfra bei rund $0,35/Mio., Fireworks bei knapp $0,70/Mio. und Together bei rund $0,88/Mio.. Nehmen wir einen mittleren Wert von $0,40 pro Million Tokens, Input und Output zusammen. Und wenn du nicht ausdrücklich auf Open Weights bestehst, ist DeepSeek V4 Flash für $0,14 Eingang / $0,28 Ausgang pro Million — Frontier-Qualität für weniger als den Rundungsfehler einer GPU-Rechnung.

Die Self-Host-Seite. Diese H100 für $2,89/Stunde kostet $2.080/Monat, wenn sie immer läuft. Um bei der API mit $0,40/Mio. die Gewinnschwelle zu erreichen, müsstest du folgendes leisten:

$2.080 ÷ $0,40 pro Million = 5,2 Milliarden Token pro Monat.

Fünf Milliarden Token. Bei einem realistischen, dauerhaften aggregierten Durchsatz von 400 Token/Sek produziert eine einzelne gut gebatchte H100 ungefähr 400 × 3600 × 24 × 30 ≈ 1,0 Milliarden Token pro Monat, wenn sie niemals stoppt. Eine H100 auf Hochtouren, jede Sekunde jeden Tag, reicht also nicht einmal, um bei einer mittelmäßig bepreisten API die Gewinnschwelle zu erreichen. Du bräuchtest die Maschine nahe der Kapazitätsgrenze und das günstigere Ende des Mietmarkts und nahezu null Leerlauf, um die Nase vorn zu haben.

Vergleiche nun mit DeepSeek V4 Flash bei rund $0,21/Mio. gemischt. Die API wurde gerade halb so teuer. Der Self-Host-Fall wird schlechter, nicht besser, jedes Mal wenn gehostete Preise sinken — und sie sinken weiter.

Das Vierzig-Minuten-von-Neun-Tagen-Problem

Mein Pod lief neun Tage. Mein Traffic nutzte vierzig Minuten. Das ist ein extremer Fall, aber es ist die normale Form des Solo-Builder-Traffics: stoßartig, sprunghaft, meistens nichts.

Hier ist die Mathematik, die wirklich zählt. Die Auslastung ist das ganze Spiel:

Bei 100% Auslastung (GPU immer gebatcht, immer beschäftigt): Self-Hosting kann gewinnen, wenn das Volumen wirklich enorm ist, wie im obigen Beispiel.
Bei ~50% Auslastung: Deine effektiven Kosten pro Token verdoppeln sich, weil du die Hälfte im Leerlauf bezahlt hast. Jetzt brauchst du das 2-fache Volumen, um die Gewinnschwelle zu erreichen.
Bei 5% Auslastung (meine vierzig Minuten): Deine effektiven Kosten pro Token sind ~20-mal so hoch wie die Aufkleberpreis-Mathematik. Die API gewinnt haushoch, und es ist nicht einmal knapp.

Per-Token-APIs sind reines Pay-per-Use. Sie haben dein Leerlaufproblem bereits gelöst — indem sie die GPU über Tausende anderer Kundenstöße amortisieren. Dieses Pooling ist das eigentliche Produkt, für das du bezahlst. Wenn du selbst hostest, nimmst du das Leerlauf-Risiko wieder auf deine eigene Kreditkarte.

Du kannst dem Leerlauf mit serverlosem GPU (scale-to-zero, sekundenbasierte Abrechnung) oder Spot-Instances zu 50–80% Rabatt begegnen. Beides hilft. Beides bringt auch wieder Cold Starts, Eviction und genau die Zuverlässigkeitsprobleme mit sich, die du hinter dir lassen wolltest.

Die Kosten, die nie im Kalkulator auftauchen

Der Stundensatz ist der ehrliche Teil der Rechnung. Der unehrliche Teil ist alles drum herum, und es landet alles bei dir, wenn du solo arbeitest:

Setup- und Ops-Zeit. vLLM aufsetzen, Quantisierung wählen, Batch-Größe abstimmen, Health Checks verdrahten, OOMs behandeln. Das sind Stunden, und du bist der einzige Ingenieur. Bei jedem vernünftigen Wert deiner Zeit ist der erste Monat Self-Hosting teurer als ein Jahr API-Aufrufe.
Zuverlässigkeit. Wenn eine gehostete API einen schlechten Node hat, ist das deren Pager. Wenn dein Pod um 2 Uhr nachts stirbt, ist das deiner. Es gibt kein Failover, es sei denn, du baust es.
Die Qualitätslücke. Das überspringen die Leute. Das beste Open-Weight-70B ist gut, aber die günstigen Frontier-APIs sind besser bei anspruchsvollen Überlegungen und Code — und sie kosten weniger als deine GPU. Du zahlst möglicherweise mehr, um eine schlechtere Antwort zu liefern.
Die Quantisierungssteuer. Die günstigen Durchsatzzahlen gehen in der Regel von FP8- oder 4-Bit-Quantisierung aus. Das ist ein echter Qualitätsabzug on top der Open-vs-Frontier-Lücke. Mit voller Präzision sinkt dein Durchsatz und dein VRAM-Bedarf steigt.

Nichts davon erscheint auf der RunPod-Preisseite. Alles davon ist real.

Wann Self-Hosting wirklich gewinnt

Ich möchte dich nicht kategorisch davon abbringen, denn es gibt Fälle, in denen es die richtige Wahl ist — sie sind nur enger als der Hype vermuten lässt:

Dauerhaftes, hohes, vorhersehbares Volumen. Wenn du zuverlässig Milliarden von Tokens pro Monat mit einer gefüllten Batch-Warteschlange verarbeitest, amortisieren sich die fixen GPU-Kosten und du gewinnst. Das ist ein echtes Unternehmen mit echtem Traffic, kein Nebenprojekt.
Datenschutz- oder Datenresidenzanforderungen, die das Senden von Tokens an Dritte verbieten. Hier ist Kosten ohnehin nicht die entscheidende Variable.
Stark fine-getunte oder Nischen-Modelle, die kein Host anbietet, bei denen die API-Option zu keinem Preis existiert.
Ein kleines Modell, das auf eine günstige Karte passt. Ein 8B-Modell auf einer 4090 für $0,40/Stunde ist eine völlig andere Gleichung als ein 70B auf einer H100. Wenn deine Aufgabe tatsächlich auf einem kleinen Modell läuft, wird Self-Hosting schnell erschwinglich — aber dann auch die gehostete API für dasselbe kleine Modell.

Das Muster fällt auf: Die Gewinne betreffen Volumen, Kontrolle oder Einschränkungen — nicht einen Solo-Builder, der eine moderate API-Rechnung senkt.

Die Entscheidungsregel, die ich jetzt verwende

Bevor ich eine GPU miete, stelle ich drei Fragen in dieser Reihenfolge. Wenn eine Antwort "nein" ist, bleibe ich bei der API.

Verarbeite ich dauerhaft mehr als ~1 Milliarde Tokens pro Monat, mit genug Gleichzeitigkeit, um einen Batch gefüllt zu halten? Wenn mein Traffic stoßartig ist oder ich rate, ist die Antwort nein, und die Leerlaufzeit wird mich begraben.
Gibt es einen Nicht-Kosten-Grund — Datenschutz, Residenz, ein Modell, das niemand hostet? Wenn ja, kann Self-Hosting unabhängig von der Mathematik obligatorisch sein, also höre ich auf, für Dollar zu optimieren.
Ist meine Zeit weniger wert als die API-Rechnung, die ich sparen würde? Normalerweise nicht. Der Ops-Overhead ist der wahre Preis, und er wird in der knappsten Ressource, die ich habe, bezahlt.

Für mich, bei einem Solo-Produkt mit stoßartigem Traffic, zeigen alle drei neuerdings in dieselbe Richtung: Pro Token bezahlen, Frontier-Qualität behalten und meine Stunden damit verbringen, das zu bauen, wofür die Leute wirklich bezahlen. Ich werde die H100 wieder mieten, wenn meine Batch-Warteschlange voll ist und voll bleibt. Bis dahin war die Leerlauf-GPU das teuerste Nichts, das ich je gekauft habe.