LLM-Inference selbst hosten: Wann sich eigene GPUs wirklich lohnen

LLM-Inference selbst hosten: Wann sich eigene GPUs wirklich lohnen
Deine Reaktion:

Du hast eine Funktion mit einer gehosteten LLM-API gebaut. Sie funktioniert einwandfrei, bis die Rechnung der Finanzabteilung auf deinem Tisch landet. Sie hat sich innerhalb eines Quartals verdreifacht, weil jeder neue Nutzer zusätzliche Token verbraucht. Gleichzeitig weist dein Security-Team darauf hin, dass Kundendaten in jedem Prompt an den API-Anbieter übertragen werden. Im nächsten Standup kommt die Frage: Sollten wir nicht einfach unsere eigenen GPUs kaufen? Die intuitive Antwort „Own-Hardware ist immer günstiger“ ist meistens falsch. Denn das Selbsthosten von LLM-Inference bringt nicht nur Einsparungen, sondern auch versteckte Kosten und neue Verantwortung.

Drei Wege, ein Modell zu betreiben

Bevor wir über Kosten sprechen, müssen wir die drei Betriebsmodelle klar voneinander trennen. Die Hosted-API ist wie ein Restaurant: du bestellst ein Gericht, bekommst es serviert und zahlst pro Portion. Der Managed Deployment ist ein privater Koch, der in deiner Küche arbeitet und die Zutaten von dir bekommt. Das Self-Hosting ist die komplette eigene Küche mit eigenem Herd, Kühlschrank und Personal – du kontrollierst alles, musst aber auch alles selbst organisieren.

Bei einer Hosted-API sendest du Text an einen Anbieter wie OpenAI oder Anthropic und bekommst Text zurück; du zahlst pro Token, ohne dich um Infrastruktur zu kümmern. Der Managed Deployment läuft in deiner eigenen Cloud-Tenancy, aber der Anbieter betreibt GPUs und Serving-Software – deine Daten bleiben bei dir, aber du mietest weiterhin Rechenleistung. Beim Full Self-Hosting besitzt du die GPUs, betreibst die Serving-Engine und übernimmst jede Schicht des Stacks – maximale Kontrolle, aber auch maximale Verantwortung. Die Wahl zwischen diesen Optionen wird von vier Faktoren bestimmt: Volumen, Datenhoheit, verfügbarer Expertise und dem Zugang zu den Modellen selbst.

Die vier Kräfte, die deine Entscheidung bestimmen

Der erste Faktor ist das Datenvolumen. Wie viele Tokens verarbeitest du täglich? Unter einer Million Tokens pro Tag ist die API fast immer die günstigste Lösung – du zahlst nur für die tatsächliche Nutzung und musst keine teuren GPUs anschaffen. Der zweite Faktor ist die Datenhoheit. Wenn deine Daten gesetzlich nicht dein Netzwerk verlassen dürfen – etwa im Gesundheitswesen oder bei Finanzdiensten –, fällt die Hosted-API sofort aus. Dann ist entweder Managed Deployment oder Self-Hosting Pflicht, unabhängig von den Kosten. Der dritte Faktor sind deine Mitarbeiter: Hast du jemanden, der sich um GPUs kümmert, CUDA-Fehler nachts um 2 Uhr fixt und die Latenz überwacht? Ein einzelner MLOps-Ingenieur kostet laut Glassdoor im Schnitt 160.000 Dollar pro Jahr – mehr als die Hardware selbst. Der vierte Faktor ist der Modellzugang: Nur wenige Modelle werden als offene Gewichte veröffentlicht. Die stärksten Modelle wie GPT-5 oder Claude Opus sind Closed-Weights – sie existieren nur als API. Das bedeutet: Die beste Leistung, die du auf eigener Hardware erreichen kannst, ist die eines Open-Weight-Modells. Für Aufgaben, die die Intelligenz eines Frontier-Modells erfordern, wirst du also immer eine API brauchen, egal wie viel du selbst hostest.

Die vier Faktoren wirken in einer festen Reihenfolge. Zuerst prüfst du die Datenhoheit – ein Compliance-Verbot überschreibt jedes Kostenargument. Dann schaust du, ob du ein Ops-Team hast: Wenn nicht, bleibt nur Managed Deployment. Erst danach stellt sich die Volumenfrage: Ab etwa zwei Millionen Tokens pro Tag kann sich die eigene Hardware amortisieren. Zuletzt kommt die Modellzugangs-Beschränkung, die jeden Plan ändern kann. Diese Reihenfolge führt die meisten Unternehmen zu einem Kompromiss: einer hybriden Strategie.

Der Krossover-Punkt: Wann lohnt sich die eigene Hardware?

Zahlen helfen, das Bild zu konkretisieren. Unter einer Million Tokens pro Tag ist die API kostentechnisch klar überlegen. Zwischen einer und zwei Millionen ist es ein echtes Kopf-an-Kopf-Rennen. Ab zwei Millionen Tokens pro Tag beginnt sich der Kauf eigener GPUs zu rechnen – vorausgesetzt, deine Workloads benötigen tatsächlich Frontier-Modelle. Ein Beispiel: Wenn du 10 Millionen Tokens pro Tag durch die günstigste OpenAI-Stufe (!gpt-5.4-nano) jagst, landest du bei einer API-Rechnung von nur ein paar hundert Dollar pro Monat. Dagegen kostet eine ständig laufende, gemietete H100 mit vier Dollar pro Stunde fast 2.900 Dollar monatlich – plus Personalkosten. Der Krossover-Punkt von zwei Millionen gilt also nur für teure, hochwertige Modelle. Arbeitest du mit kleinen, schlanken Modellen, wird sich Self-Hosting womöglich nie amortisieren, weil die API so günstig bleibt.

Der Trick liegt oft in der Bündelung: Drei interne Anwendungen mit jeweils 700.000 Tokens pro Tag ergeben zusammen 2,1 Millionen – damit wird die eigene Hardware profitabel, obwohl keine einzelne Anwendung es wäre. Die Fixkosten der GPU werden über mehrere Abteilungen verteilt. Wer über die Zehn-Millionen-Marke kommt, amortisiert die Hardware in der Regel innerhalb von sechs bis zwölf Monaten. Aber Vorsicht: Diese Rechnung funktioniert nur, wenn du die genannten Kosten der Menschen und des Betriebs nicht vergisst.

Die versteckten Kosten: MLOps, Strom und Hardware

Die offensichtlichen Kosten sind die GPUs selbst – sagen wir 30.000 Dollar für einen H100 oder ein Paar RTX 3090er. Doch die eigentlichen Kostentreiber liegen woanders. Da ist der MLOps-Ingenieur, der das System wartet, denn selbst erfahrene Teams verbringen Monate damit, Serving-Engines wie vLLM zu konfigurieren und Latenzspitzen zu bekämpfen. Sein Gehalt übersteigt den Hardwarepreis um ein Vielfaches. Dazu kommen Stromkosten: Eine High-End-GPU zieht unter Last 450 bis 575 Watt – das macht etwa 50 bis 65 Euro pro Monat pro Karte, selbst wenn sie nur im Leerlauf läuft. Und ein Modell muss in den VRAM passen. Grob brauchst du 0,5 Gigabyte pro Milliarde Parameter bei 4-Bit-Quantisierung; ein 70B-Modell benötigt also 35 bis 40 Gigabyte – mehr, als eine Consumer-Karte bietet. Wenn das Modell auf die CPU ausweicht, wird die Generierung 10 bis 100 Mal langsamer, was wiederum die Antwortzeiten ruiniert.

Hinzu kommt die Frage der Serving-Kapazität. Ein einzelner Server mit vLLM kann laut Forschern rund 19-mal mehr Durchsatz als eine naive Einrichtung schaffen und hält dabei P99-Latenzen unter 100 Millisekunden bei 128 parallelen Anfragen. Das erfordert jedoch Fachkenntnis. Wer nur eine handvoll interner Nutzer bedient, kommt mit einfacheren Tools aus, aber das ist selten der Fall. Die meisten Teams unterschätzen, wie viel Engineering-Zeit in den Betrieb fließt – und diese Zeit ist das teuerste Gut im ganzen Projekt.

Die Hybrid-Strategie: das Beste aus beiden Welten

Wegen dieser Komplexität landen die erfolgreichsten Implementierungen fast immer auf einem Hybridmodell. Die Idee ist simpel: Jede Anfrage wird danach beurteilt, wie sensibel ihre Daten sind und wie viel Rechenleistung sie benötigt. Einfache, repetitive und datenkritische Aufgaben – Klassifikation, Datenextraktion, Verarbeitung von personenbezogenen Dokumenten – erledigt ein lokal gehostetes Open-Weight-Modell. Seltene, aber intellektuell anspruchsvolle Aufgaben, bei denen die Antwortqualität über Leben und Tod des Geschäfts entscheidet, gehen an eine Frontier-API. Diese Aufteilung spart Teams, die sie umgesetzt haben, 40 bis 70 Prozent der Kosten im Vergleich zu einem reinen API-Setup – manchmal sogar mehr.

Der Vorteil der Hybridstrategie ist, dass sie keine Entweder-oder-Entscheidung erzwingt. Du kannst mit der API starten, dann schrittweise eigene Hardware hinzufügen und die Verteilung im Laufe der Zeit optimieren. Die beiden Systeme ergänzen sich: Die API deckt die Spitzen ab, wenn das lokale System überlastet ist, und das lokale System schützt sensible Daten vor externen Zugriffen. So bleibt die Compliance gewahrt, ohne dass du auf die beste Modellqualität verzichten musst.

Einordnung: Wann welche Entscheidung richtig ist

Zusammengefasst ergibt sich eine klare Faustregel. Hosted APIs sind für den Einstieg ideal: Sie sind schnell implementiert, skalieren automatisch und bieten Zugang zu den stärksten Modellen. Managed Deployments sind die Lösung für regulierte Branchen, die Datenkontrolle brauchen, aber keine eigene Ops-Kompetenz aufbauen wollen. Full Self-Hosting lohnt sich nur, wenn dein Volumen konstant hoch ist – über zwei Millionen Tokens täglich – und du die Rechenleistung über mehrere Anwendungen verteilen kannst. Wenn du jedoch nur gelegentlich intelligente Textverarbeitung brauchst und keine strengen Datenschutzauflagen hast, wirst du mit einer API auch langfristig günstiger fahren.

Entscheidend ist, die Kosten nicht nur anhand der Rechnung zu beurteilen. Die Modelle werden immer besser, die API-Preise fallen tendenziell, und die eigene Hardware wird von Software-Updates überholt. Der Reiz des Selbsthostens liegt nicht im Sparen – es liegt in der Unabhängigkeit und Kontrolle. Aber Kontrolle hat ihren Preis, und der ist bei LLMs besonders hoch. Deshalb lautet die Empfehlung: Starte mit einer API, überwache deine Token-Nutzung, und wenn dein Volumen die zwei Millionen pro Tag überschreitet, prüfe die Hybridstrategie. So bleibst du flexibel und zahlst nie mehr als nötig – und du vermeidest die 2-Uhr-CUDA-Fehler, die dein Team unnötig beschäftigen würden.

Quelle: theaiengineer.substack.com

Deine Reaktion:
Artikel teilen:
Krötzsch-Check0 — 100
Fakten 75
Relevanz 80
Hype 15
Einschätzung 75
Redaktion 50 Stand 50 · noch keine Stimmen
Ist das Hype?
Sebastian Krötzsch
Autor

Sebastian Krötzsch

Sebastian Krötzsch schreibt auf sebask.de über Künstliche Intelligenz, Automatisierung, digitale Systeme und die Frage, was davon im Alltag wirklich nützlich ist. Ohne Buzzword-Nebel, dafür mit klarem Blick auf Praxis, Tools und echte Wirkung.