Eine Open-Weight-LLM selbst hosten vs. eine API: Die echte Kostenrechnung

Dein Produkt geht live, es ruft eine LLM-API auf, und die Rechnung ist Monat für Monat gestiegen. Also machst du das, was jeder Entwickler irgendwann macht: Du öffnest einen neuen Tab und fragst dich, ob eine GPU zu mieten und Llama selbst auszuführen billiger wäre.

Die Frage nach den Kosten für selbst gehostete LLM hat eine Antwort, aber es ist nicht die eine Zahl, die die obersten Suchergebnisse und AI Overviews immer wiederholen. Es hängt von drei Dingen ab, die diese Artikel platttreten: gegen welche API du vergleichst, wie ausgelastet deine GPU ist und die Betriebskosten, die niemand in die Tabelle einträgt.

Hier die Kurzfassung vor den Details: Für die meisten Solo-Entwickler gewinnt Selbst-Hosting im Moment nicht bei den Kosten. Aber es gibt eine bestimmte Linie, an der es kippt, und du kannst sie an deiner eigenen Rechnung in etwa zwei Minuten berechnen. Unten steht die Rechnung für 2026 (aktuelle Preise, VRAM-Zahlen nach Modell und eine Formel, die du durchrechnen kannst).

Die Kurzfassung

• Der Break-even ist nicht eine Zahl. Es sind drei, je nachdem, gegen welche API du vergleichst. Gegen eine Frontier-API (GPT-5.x, Claude Sonnet 5 / Opus 4.8, Gemini Pro) erreicht Selbst-Hosting den Break-even am schnellsten. Gegen eine günstige Open-Weight-API (DeepSeek, DeepInfra, Together bei rund $0.14–$0.50 pro Million Tokens) gewinnt es fast nie allein bei den Kosten.
• Die Auslastung ist der Multiplikator, der den Solo-Fall killt. Eine gemietete GPU kostet im Leerlauf dasselbe wie unter Volllast, sodass eine GPU, die bei 10% Auslastung läuft, pro Token rund 10× von dem kostet, was sie unter Volllast kostet. Stoßweise Solo-Workloads liegen standardmäßig bei niedriger Auslastung.
• Unterhalb des Break-even ist der Kostenvorteil meist der Wechsel zu einer günstigen Open-Weight-API, nicht das Selbst-Hosting. Selbst-Hosting verdient sich seinen Platz, wenn anhaltendes Volumen gegen Frontier-Preise die Linie bei 60%+ Auslastung überschreitet, oder wenn du einen Grund jenseits der Kosten hast (Datenschutz, Latenz, Fine-Tuning-Kontrolle).
• Rechne die Formel an deinen eigenen Zahlen durch, bevor du irgendetwas mietest. Break-even-Tokens ≈ monatliche GPU-VPS-Kosten ÷ dein gemischter API-Preis pro Token.

Was das nicht abdeckt

• GPU-Cluster im Multi-Node- oder Rechenzentrums-Maßstab. Das ist eine Solo-Kostenentscheidung, keine Flotte.
• Fine-Tuning-Ökonomie in irgendeiner Tiefe (eine separate Rechnung mit eigenen Kompromissen).
• Ein Schritt-für-Schritt-Tutorial zur Ollama-vs-vLLM-Einrichtung. Der Umfang hier ist die Geldfrage, nicht die Installation.
• Eigene Hardware als dein primäres Vehikel. Die Annahme durchgängig ist eine gemietete GPU, da das der realistische Weg für einen Entwickler ist, der nicht bereits eine GPU auf dem Schreibtisch stehen hat.

Was die Kosten treibt (und wo die populären Zahlen danebenliegen)

Suche „self host LLM vs API cost“ und du landest bei einer sauberen Break-even-Zahl: so etwas wie 11 Milliarden Tokens pro Monat oder rund $4.200 an monatlichen API-Ausgaben, zitiert von Braincubers Kostenanalyse und fast wortgleich in der AI Overview oben auf der Seite wiedergegeben. Es ist eine saubere Zahl. Sie ist für sich genommen auch nahezu nutzlos, weil sie die zwei Variablen verbirgt, die deine Antwort bestimmen.

Der Grund, warum das rutschig ist: Die zwei Seiten des Vergleichs haben unterschiedliche Kostenformen. Eine API-Rechnung ist ein variabler Kostenblock: Du zahlst pro Token, also skaliert die Rechnung mit deiner Nutzung nach oben und unten. Eine gemietete GPU ist ein fixer Kostenblock: Du zahlst denselben Monatssatz, egal ob du eine Milliarde Tokens durchschickst oder sie im Leerlauf sitzen lässt. Einen variablen Kostenblock mit einer Zahl gegen einen fixen zu vergleichen erfordert so zu tun, als wüsstest du genau, wie viele Tokens fließen werden, und im Solo-Maßstab weißt du das meist nicht.

Bleiben drei Hebel, die den Break-even bewegen:

• Gegen welche API du vergleichst. Eine Frontier-API und eine günstige Open-Weight-API trennen im Preis rund zwei Größenordnungen. Der Break-even gegen jede ist völlig unterschiedlich.
• Deine GPU-Auslastung. Der fixe Kostenblock zahlt sich nur aus, wenn die GPU beschäftigt ist. Leerlaufzeit ist Geld, das du für nichts ausgegeben hast.
• Die versteckten Betriebskosten. Deine Stunden, das Auf-und-Ab der Modell-Updates und die VRAM-Überraschungen, die erst auftauchen, wenn du in Produktion bist.

Beziffere jeden dieser Punkte und der Nebel lichtet sich. Das ist der Rest dieses Artikels.

Abschnitts-Fazit: Der Break-even ist keine einzelne Zahl. Es sind drei Zahlen, eine pro API-Stufe, und die falsche Stufe zum Vergleich zu wählen ist genau dort, wo die meisten Kostenschätzungen danebengehen.

Der dreifache Break-even: Frontier vs. Mid-Tier vs. Budget-API

Eine Open-Weight-LLM auf einem GPU-VPS selbst zu hosten schlägt eine Frontier-API (GPT-5-Klasse, Claude Sonnet 5 / Opus 4.8, Gemini Pro) bei rund ein paar Millionen Tokens pro Tag, vorausgesetzt du hältst die GPU auf gesunder Auslastung (sagen wir 60% oder höher). Gegen eine günstige Open-Weight-API bei rund $0.14–$0.50 pro Million Tokens gewinnt es bei den Kosten kaum jemals. Dieser Unterschied ist die ganze Geschichte, und deshalb kann eine einzelne Break-even-Zahl nicht richtig sein.

So sieht es über die drei Stufen aus. Behandle diese Schwellen als richtungsweisende Bereiche, nicht als harte Linien. Sie stammen aus Community-Schätzungen und Preisen von 2026, die sich beide schnell bewegen.

Preise von den OpenAI, Anthropic, Google, DeepInfra, Together, und DeepSeek Preisseiten, Stand July 2026. Jede dieser Zahlen hat eine in Monaten gemessene Haltbarkeit, also prüfe die aktuellen Seiten, bevor du dich festlegst.

Nun der konträre Punkt, denn er ist der, der Entscheidungen ändert. Es kursiert ein lautes und richtiges Argument, dass günstige APIs den Selbst-Hosting-Break-even getötet haben. Open-Weight-APIs wie DeepInfra und Together servieren jetzt Llama- und Qwen-Modelle zu einem Bruchteil der Frontier-Preise, und die Frontier-Preise selbst sind seit 2025 stark gefallen. Gegen diese günstigen Raten läuft der Break-even pro Token in die Milliarden von Tokens pro Monat. Ein Solopreneur schickt keine Milliarden Tokens pro Monat durch. Wenn dein einziges Ziel also eine niedrigere Rechnung ist, ist der erste Schritt meist nicht „miete eine GPU“, sondern „wechsle zu einer günstigen Open-Weight-API und behalte null Betrieb“.

Das Kosten-Argument fürs Selbst-Hosting überlebt an zwei Stellen: im Vergleich gegen teure Frontier-Preise bei wirklich hohem, anhaltendem Volumen, und bei den Gründen jenseits der Kosten (Datenschutz, Latenz, Fine-Tuning-Kontrolle), die weiter unten behandelt werden. Überall sonst gewinnt die Budget-API das Geld-Argument.

Die Break-even-Formel

break-even tokens per month ≈ GPU VPS monthly cost ÷ your blended API price per token

Durchgerechnetes Beispiel, Solopreneur-Maßstab: Angenommen, ein einzelner High-End-GPU-VPS läuft bei etwa $1.000/Monat (Katalog-Bereich 2026 für eine Top-Single-GPU-Stufe), und du bist auf einer Frontier-API mit einer gemischten Rate von rund $6 pro Million Tokens (grob $0.000006 pro Token). Das sind ~$1.000 ÷ $0.000006 ≈ 167 Millionen Tokens/Monat, bevor sich die GPU auf dem Papier bezahlt macht. Jetzt rechne es gegen eine günstige Open-Weight-API bei $0.40 pro Million ($0.0000004/Token) neu: ~$1.000 ÷ $0.0000004 = 2,5 Milliarden Tokens/Monat. Dieselbe GPU, derselbe fixe Kostenblock, und der Break-even bewegt sich um mehr als 10×, rein abhängig davon, welche API du in den Nenner setzt. Das ist vor der Auslastung, die die Zahl schlechter macht.

Abschnitts-Fazit: Die API, gegen die du vergleichst, kann deinen Break-even um 10× oder mehr verschieben, also bedeutet „die Zahlen durchrechnen“, sie gegen die konkrete API durchzurechnen, die du tatsächlich ersetzen würdest.

Was die Auslastung mit den Kosten pro Token macht

Nimm diesen ~167-Millionen-Token-Frontier-Break-even und füge die Variable hinzu, die die Formel stillschweigend wegannimmt: Deine GPU ist die ganze Zeit beschäftigt. Ist sie nicht. Eine gemietete GPU stellt gleich in Rechnung, ob sie ausgelastet oder im Leerlauf ist, sodass deine effektiven GPU-VPS-LLM-Kosten pro Token umgekehrt zur Auslastung skalieren. Laufe bei 10% Last und jeder Token, den du bedienst, trägt rund 10× der Kosten, die er unter Volllast hätte, weil du für die 90% Kapazität zahlst, die du nicht genutzt hast. Community-Schätzungen und Praktiker-Berichte setzen die praktische Untergrenze bei rund 50–60% anhaltender Auslastung an, bevor die Zahlen aufhören, dich zu blamieren (richtungsweisende Werte, keine Laborkonstanten).

Für einen stoßweisen Solo-Workload (Traffic, der tagsüber hochschießt und über Nacht flach abfällt) ist anhaltende 60%-Auslastung schwer zu erreichen. Das ist die Falle. Hier ist, was das mit den Kosten pro Million Tokens über ein paar konkrete Punkte macht, mithilfe von Katalog-GPU-Preisen 2026 geteilt durch groben monatlichen Durchsatz auf jeder Auslastungsstufe:

Die absoluten Cents pro Token hängen von deinem Modell, der Quantisierung und davon ab, wie viele gleichzeitige Anfragen du auf die Karte packen kannst, also behandle die Spalten so, dass sie die Form der Strafe zeigen, nicht ein Angebot. Der Punkt ist der Multiplikator: Falle von Volllast auf Viertel-Last und deine Kosten pro Token vervierfachen sich ungefähr. Das ist meist, was den Solo-Selbst-Hosting-Fall killt, nicht der GPU-Listenpreis.

Es gibt eine strukturelle Notluke, und sie ist der Grund, warum Mieten für stoßweise Nachfrage das Besitzen schlagen kann: Du kannst eine gemietete Instanz stoppen, wenn sie im Leerlauf ist. Besitze die Hardware und sie schreibt sich ab und zieht Strom, ob du sie nutzt oder nicht. Bei stündlichen oder On-Demand-Mieten kannst du die Instanz stoppen oder abbauen, wenn der Job erledigt ist, und das Zahlen für Leerlaufstunden vermeiden. Bei festen Monatsplänen ist die Rechnung für den Abrechnungszeitraum weiterhin fix, sodass die Auslastung das Hauptkostenproblem bleibt. Es behebt keinen Workload, der den ganzen Tag über wirklich niedrig ausgelastet ist, aber für Nachfrage, die in Schüben beschäftigt und dazwischen tot ist, ist die Fähigkeit, den Zähler abzuschalten, der eine Hebel, der Miete-vs-Besitz Richtung Miete kippen lässt.

Abschnitts-Fazit: Die Auslastung, nicht der monatliche GPU-Preis, ist meist, was entscheidet, ob sich Selbst-Hosting rechnet, und es ist die Variable, die die populären Break-even-Zahlen komplett auslassen.

Welches Modell auf welche GPU passt: die VRAM-Realität

Der Plan, der zuerst platzt, ist „ich lasse einfach ein 70B auf einem 4090 laufen“. Kannst du nicht. Ein 70B-Modell bei Q4_K_M-Quantisierung braucht rund 40–46 GB VRAM, und ein 24 GB RTX 4090 oder ein 32 GB RTX 5090 hat schlicht nicht den Platz. Zwinge es auf eine 24 GB-Karte und du bist auf Q2_K-Quantisierung (rund 21 GB) mit sichtbarem Qualitätsverlust herunter, oder das Modell läuft in den System-RAM über und die Generierungsgeschwindigkeit bricht zusammen. VRAM ist die harte Wand, die entscheidet, welche Modelle für eine gegebene GPU überhaupt in Frage kommen.

Hier ist, was wohin passt. VRAM-Zahlen sind ungefähr: Sie sind aus der Standard-Bytes-pro-Parameter-Arithmetik abgeleitet (FP16 ≈ Params × 2 mit ~15% Overhead; Q4_K_M ≈ Params × ~0.55 mit Overhead), also behandle sie als Dimensionierungs-Orientierung, keine Garantien.

VRAM-Zahlen sind gegen NVIDIAs offizielle GPU-Spec-Seiten für jede Karte gegengeprüft. Die A100 gibt einem quantisierten 70B komfortableren Spielraum; RTX 6000 Ada kann für engere Q4-Setups funktionieren, während 24 GB- und 32 GB-Consumer-Karten nicht genug VRAM für ein normales 70B-Q4-Deployment haben. Wenn du die vollständige Aufschlüsselung willst, wie GGUF-, GPTQ-, AWQ- und EXL2-Formate Speicher verbrauchen, ist das ein Kaninchenbau, der seine eigene Lektüre wert ist: GGUF, GPTQ, AWQ, EXL2: Wie LLM-Quantisierungsformate den Speicher tatsächlich nutzen.

Der Community-Sweetspot für eine einzelne 24 GB-Karte ist ein 24B-bis-32B-Modell (Mistral Small 3.1 oder Qwen 3 32B bei Q4). Das ist die Größe, die einem Solo-Entwickler ein brauchbares Modell auf der günstigsten GPU-Stufe gibt, ohne die ganze Zeit gegen VRAM zu kämpfen. Wenn du überhaupt abwägst, welche Karte du mieten sollst, vergleicht unser H100 vs RTX 4090 Benchmark für KI-Workloads die Stufen beim Durchsatz.

Profi-Tipp: Kalkuliere für den KV cache, nicht nur die Gewichte. Die mit Abstand häufigste Überraschung beim ersten Deployment: Du dimensionierst die GPU für die Modellgewichte, lädst es und es passt. Dann kommen Anfragen herein, der KV cache wächst mit Kontextlänge und Parallelität, und dir geht der VRAM aus, während du deine ersten paar Nutzer bedienst. Wenn der VRAM überläuft und das Modell auf die CPU überschwappt, fällt die Generierungsgeschwindigkeit um 10–100×. Lass Spielraum über den Gewichtszahlen in der Tabelle für den Cache, besonders wenn du lange Kontexte oder mehrere Nutzer gleichzeitig bedienst.

Die versteckten Kosten, die die naiven Ersparnisse auslöschen

Die Tabelle, die sagt, Selbst-Hosting sei billiger, hat fast immer eine Zeile: den monatlichen GPU-Preis. Die Rechnung, die du zahlst, hat mehr Zeilen. Da ist deine Zeit (jede Stunde, die du mit Patchen, dem Neustarten eines hängenden Inferenzservers oder dem Jagen eines Out-of-Memory-Crashes verbringst, ist eine Stunde, die du nicht am Produkt verbracht hast). Da ist das Auf-und-Ab der Modell-Updates: Das Open-Weight-Modell, das du bereitgestellt hast, wird abgelöst, und Re-Benchmarking und Re-Deployment sind wiederkehrende Arbeit, kein einmaliges Setup. Da ist die VRAM- und KV-cache-Überraschung aus dem letzten Abschnitt. Und da ist die Leerlaufverschwendung, die Stunden, in denen die GPU abrechnend dasitzt, während nichts läuft.

Praktiker, die das gezählt haben, setzen die wahren Kosten auf rund 1,3–2× des rohen GPU-Preises an, sobald die Betriebszeit einbezogen ist, und einige gehen höher, auf 3–5×, bei chaotischeren Setups. Das sind richtungsweisende Multiplikatoren aus Community-Berichten, keine geprüften Zahlen, aber die Richtung ist der Punkt. Wie es eine viel zitierte Formulierung ausdrückt: Eine leerlaufende GPU ist kein Vermögenswert, sie ist eine stündlich abgerechnete Verbindlichkeit. Für einen Solo-Entwickler ist der richtige Weg, das zu bepreisen, keine MLOps-Gehaltszeile, es sind deine eigenen Stunden, die das Knappste sind, was du hast. Wenn dir Selbst-Hosting auf dem Papier $200 im Monat spart, dich aber sechs Stunden Betrieb kostet, die du sonst mit Ausliefern verbringen würdest, ist das nicht offensichtlich ein Gewinn.

Wann Selbst-Hosting trotzdem gewinnt: Datenschutz, Latenz und Fine-Tuning

Kosten sind nicht der einzige Grund, dein eigenes Modell zu betreiben, und für manche Entwickler nicht einmal der wichtigste. Unterhalb des Kosten-Break-even, wo das Geld sagt „bleib bei der API“, gibt es drei Gründe, trotzdem selbst zu hosten. Datensouveränität: die Prompts und Daten deiner Nutzer aus der Pipeline eines externen KI-Anbieters herauszuhalten, was für manche Produkte zählt, egal was die Zahlen sagen. Vorhersagbare Latenz: keine Shared-Tenant-Warteschlange, keine Rate-Limits, die du nicht gesetzt hast, keine überraschenden Verlangsamungen während des Traffic-Spikes von jemand anderem. Und volle Kontrolle: die Freiheit, zu fine-tunen, zu quantisieren, Modelle zu tauschen und Versionen festzupinnen, ohne auf einen Anbieter zu warten.

Es gibt einen Vorbehalt beim Datenschutz-Punkt, und ihn zu überspringen wäre unehrlich. Ein gemieteter GPU-VPS läuft immer noch auf der Hardware von jemand anderem in dessen Rechenzentrum. Das ist bedeutsame Souveränität gegenüber der Trainings- und Logging-Pipeline des KI-Anbieters (deine Prompts fließen nicht durch die Systeme eines Modell-Anbieters), aber es ist nicht dasselbe wie On-Premises-Ausrüstung, die du physisch kontrollierst. Wenn deine Anforderung echte On-Prem-Isolation ist, bringt dich ein gemieteter VPS nicht dorthin. Wenn deine Anforderung „unsere Daten aus den Händen eines Drittanbieter-Modell-Anbieters heraushalten“ ist, tut er es. Wisse, welche der beiden du brauchst.

Für Workloads, die in restriktiven Netzwerkumgebungen laufen, kann ein selbst gehostetes Modell auf von dir kontrollierter Infrastruktur auch Abhängigkeiten von externen Endpunkten umgehen, die möglicherweise unerreichbar sind, eine Fähigkeit, die unabhängig davon zählt, wo du es bereitstellst.

Solltest du also selbst hosten? Eine klare Antwort nach Situation

Alles oben sortiert sich in eine kurze Entscheidung. Du hast eine Rechnung, ein grobes Gefühl für dein monatliches Token-Volumen und jetzt die drei Break-even-Stufen, die Auslastungsstrafe und den Multiplikator der versteckten Kosten. Ordne deine Situation einer von diesen zu:

• Du bist unterhalb des Frontier-Break-even und Kosten sind dein einziges Anliegen. Bleib bei einer API und bepreise ernsthaft eine günstige Open-Weight-API (DeepSeek, DeepInfra, Together), bevor du irgendetwas anderes tust. Das ist meist der Kostenvorteil, nicht das Selbst-Hosting. APIs zu wechseln ist eine Konfigurationsänderung; Selbst-Hosting ist ein zweiter Job.
• Du hast anhaltendes, hohes Volumen gegen Frontier-Preise und kannst eine GPU auf 60%+ Auslastung halten. Hier zahlt sich Selbst-Hosting aus. Rechne die Formel gegen deine Frontier-Rate durch, bestätige, dass du die Schwelle mit anhaltender Auslastung überschreitest (nicht mit der Spitze), und ein gemieteter GPU-VPS beginnt zu gewinnen.
• Du hast einen Treiber jenseits der Kosten: Datenschutz, Latenz oder Fine-Tuning-Kontrolle. Hoste bewusst unterhalb des Break-even selbst, mit offenen Augen, dass du für die Kontrolle zahlst. Erzähl dir nur nicht, es sei billiger, wenn es das nicht ist.
• Du bist dazwischen. Sieh dir das Hybrid-Muster an, bei dem die meisten Praktiker 2026 landen: ein kleines selbst gehostetes Modell für einfache Aufgaben mit hohem Volumen, plus eine Frontier-API für das schwere Reasoning, an das dein lokales Modell zu 85–90% herankommt (Community-Benchmarks, nicht laborgeprüft, und die letzte Strecke ist oft dort, wo du die Qualität am meisten brauchst).

Bei der Frage „wie komme ich an die GPU“ lautet die Antwort für einen Solo-Entwickler fast immer mieten, nicht kaufen. Rechenzentrums-Hardware zu besitzen ist eine Capex-Wette, die nur bei einem Maßstab Sinn ergibt, den du noch nicht hast. Serverless-Inferenz kann die Leerlaufverschwendung reduzieren indem sie auf null skaliert und nur für aktive Compute-Zeit abrechnet, aber sie tauscht das oft gegen eine höhere Rate pro GPU-Stunde und Cold-Start-Latenz ein. Ein gemieteter GPU-VPS liegt in der Mitte: kein Capex, eine vorhersagbare Monatsrechnung, Root-Zugriff und die Fähigkeit, die Instanz zu stoppen, wenn sie im Leerlauf ist.

Wenn du die Formel durchgerechnet, den Break-even überschritten hast und einen dedizierten, privaten Inferenzserver mit Root-Zugriff willst, ohne eine Karte zu kaufen, ist genau dafür ein gemieteter GPU-Rechner da. Cloudzys GPU-VPS-Pläne decken den Bereich von einem 8B-Modell auf einer einzelnen Karte bis zu einem quantisierten 70B ab, und die Ein-Klick-Ollama-App im Marketplace wird in etwa einer Minute mit einer REST API bereitgestellt, die mit OpenAI-Clients kompatibel ist, sodass der Wechsel von einer bezahlten API zu deinem eigenen Server nahezu ein Drop-in-Wechsel in deinem Code sein kann, ohne Kosten pro Token nach der festen Monatsgebühr. Prüfe die Seite für aktuelle Preise; GPU-Raten bewegen sich.

Die eine Handlung, die sich lohnt, bevor du irgendetwas mietest: Rechne die Break-even-Formel an deiner eigenen Rechnung durch. Es dauert zwei Minuten und sagt dir, in welcher der vier Situationen oben du bist.

Häufig gestellte Fragen

Ist es billiger, eine LLM selbst zu hosten oder eine API zu nutzen?

Es hängt davon ab, welche API. Ein Open-Weight-Modell auf einem GPU-VPS selbst zu hosten kann eine Frontier-API (GPT-5-Klasse, Claude Sonnet 5 / Opus 4.8) bei hohem, anhaltendem Volumen mit guter GPU-Auslastung schlagen. Es schlägt selten eine günstige Open-Weight-API (DeepSeek, DeepInfra, Together bei rund $0.14–$0.50 pro Million Tokens, Stand July 2026) allein bei den Kosten: Dieser Break-even läuft in Milliarden von Tokens pro Monat, was die meisten Solo-Entwickler nie erreichen.

Welche GPU brauche ich, um ein 70B-Modell auszuführen?

Ein 70B-Modell bei Q4_K_M-Quantisierung braucht rund 40–46 GB VRAM allein für die quantisierten Gewichte. Eine 80 GB A100 ist die sicherere Single-GPU-Option, weil sie Platz für KV cache, Runtime-Overhead und längere Prompts lässt. Eine 48 GB RTX 6000 Ada kann für engere Q4-Setups funktionieren, aber Kontextlänge und Parallelität müssen sorgfältig gesteuert werden.

Wie wirkt sich die GPU-Auslastung auf die Kosten pro Token aus?

Eine gemietete GPU kostet gleich, ob sie im Leerlauf oder voll ausgelastet ist, sodass deine effektiven Kosten pro Token umgekehrt zur Auslastung skalieren. Bei 10% Last kostet jeder Token, den du bedienst, rund 10× dessen, was er unter Volllast täte, weil du für die ungenutzte Kapazität zahlst. Die praktische Untergrenze, damit Selbst-Hosting Sinn ergibt, liegt bei rund 50–60% anhaltender Auslastung.

Wie viele Tokens pro Monat, bevor sich Selbst-Hosting lohnt?

Gegen eine Frontier-API sind rund 160–256 Millionen Tokens pro Monat bei gesunder Auslastung die richtungsweisende Schwelle (Stand July 2026). Gegen eine günstige Open-Weight-API sind es Milliarden pro Monat, solo praktisch unerreichbar. Die genaue Zahl hängt von deinen GPU-Kosten und der gemischten API-Rate ab, also rechne die Formel durch: Break-even-Tokens ≈ monatliche GPU-VPS-Kosten ÷ dein API-Preis pro Token, dann rabattiere sie für anhaltende Auslastung.

Kann ich eine Open-Weight-LLM auf einem VPS ausführen?

Ja, auf einem GPU-VPS, der auf den VRAM des Modells dimensioniert ist. Ein Tool wie Ollama führt Open-Weight-Modelle (Llama, Qwen, Mistral und andere) mit einem Ein-Klick-Deploy und einer OpenAI-compatible REST API aus, sodass dein bestehender API-aufrufender Code mit minimalen Änderungen auf deinen eigenen Server verweisen kann. Passe die GPU-Stufe an dein Modell an: Ein 8B passt komfortabel auf eine 24 GB-Karte, ein quantisiertes 70B braucht 48–80 GB.