Self-Hosting eines LLM vs. API: Wann es sich wirklich lohnt

Self-Hosting eines LLM lohnt sich in zwei Situationen: Entweder läuft das Volumen hoch genug, dass die GPU-Kosten pro Token die API-Kosten pro Token unterbieten – oder es gibt eine Datenresidenz-Anforderung, die API-Aufrufe schlicht nicht erfüllen können, egal zu welchem Preis. Außerhalb dieser beiden Fälle ist die Nutzung der API von OpenAI, Anthropic oder Google günstiger, schneller zu deployen und einfacher zu betreiben als ein eigener Inference-Stack.

Diese Frage erreicht uns besonders häufig von Gründern aus dem Healthcare- und GovTech-Bereich – denn „darf die Information unser Netzwerk verlassen" ist oft keine Kostenfrage, sondern eine rechtliche. Das folgende Framework trennt die Entscheidung daher in Kosten und Compliance auf, weil in der Regel nur eine der beiden Antworten gebraucht wird, nicht beide.

Die Kostenrechnung im Detail

Eine einzelne NVIDIA A100 80GB kostet on-demand bei Anbietern wie Lambda oder CoreWeave rund $2 bis $3 pro Stunde. 24/7 über einen Monat betrieben sind das $1.500 bis $2.200 – unabhängig davon, ob sie eine oder eine Million Anfragen verarbeitet. Das ist das Kernproblem beim Self-Hosting: Sie zahlen für Kapazität, nicht für Nutzung.

Im Vergleich dazu zahlen Sie bei API-Pricing pro Token und nichts im Leerlauf. Für ein Workload mit beispielsweise 5 Millionen Tokens pro Tag auf einem Mid-Tier-Modell landen die API-Kosten typischerweise deutlich unter $1.500/Monat – bei null operativem Aufwand. Der Break-even-Punkt, ab dem eine dedizierte GPU zu gewinnen beginnt, liegt meist irgendwo nördlich von 20 bis 50 Millionen Tokens/Tag bei konstantem, planbarem Traffic. Und selbst dann braucht man jemanden, der den Serving-Stack pflegt (vLLM, TGI oder ähnliches) und GPU-Ausfälle, Treiber-Updates sowie Skalierung handhabt.

Wir haben diese Rechnung selbst durchgespielt. Unser Cold-Outreach-Tool scrapt die Website jedes Prospects mit einer selbst gehosteten Firecrawl-Instanz und einem lokalen Modell, um in einem einzigen Aufruf Fakten zu extrahieren und eine E-Mail zu entwerfen. Bei unserem Volumen war dieser Schritt lokal günstiger und gab uns mehr Kontrolle über Rate Limits, als jedes Scraping über eine gehostete API zu leiten. Das eigentliche Sales Copywriting hosten wir hingegen nicht selbst – das geht weiterhin an ein gehostetes Modell, weil das Volumen keine dedizierte GPU-Kapazität rechtfertigt und die Qualitätsanforderungen höher sind. Die Kombination aus beidem – Self-Hosting für günstige, deterministische Aufgaben, API für hochwertige Generierung – ist für Early-Stage-Produkte meist die richtige Form. Es ist dieselbe Logik, die wir in LLM-Kostenoptimierung beschreiben: Modell-Tier und Hosting-Modell zur Aufgabe passend wählen, nicht umgekehrt.

Wo die „versteckten" Self-Hosting-Kosten herkommen

• Serving-Infrastruktur. vLLM oder Text Generation Inference übernehmen Batching und KV-Cache-Management, aber jemand muss sie betreiben, patchen und OOM-Abstürze unter Last beheben.
• Modell-Updates. Open-Weight-Modelle entwickeln sich schnell weiter. Wer sich für Self-Hosting entscheidet, übernimmt den Fine-Tuning- und Evaluierungszyklus jedes Mal, wenn ein besseres Basismodell erscheint – statt dass ein Anbieter es still hinter einer API austauscht.
• Redundanz. Ein einzelner GPU-Node ist ein Single Point of Failure. Echter Uptime erfordert mindestens zwei Nodes, was die oben genannten Basiskosten in etwa verdoppelt.

Der Compliance-Fall – eine ganz andere Frage

Wenn der Treiber Datenresidenz, PHI oder ein Kundenvertrag ist, der die Weitergabe von Daten an Dritte untersagt, ist die Kostenrechnung oben weitgehend irrelevant. Es geht nicht um einen Vergleich in Dollar, sondern um die Frage: „Ist das für uns rechtlich überhaupt möglich?" Das ist die Situation vieler unserer Kunden aus dem Healthcare- und Government-nahen Bereich – und dasselbe Terrain, das wir in gerichtsfester Architektur für Healthcare-KI behandeln.

Einige Punkte, bei denen Präzision wichtig ist:

• Self-Hosting löst das Problem „Daten verlassen unser Netzwerk", macht Sie aber nicht automatisch HIPAA-konform. Sie benötigen weiterhin Verschlüsselung im Ruhezustand und bei der Übertragung, Zugriffs-Logging und eine dokumentierte Aufbewahrungsrichtlinie für das Modell und seine Logs.
• Managed-API-Anbieter bieten BAA-gedeckte, HIPAA-fähige Endpunkte an (sowohl OpenAI als auch Anthropic bieten diese für Enterprise-Kunden an). „Wir benötigen HIPAA-Konformität" bedeutet also nicht zwangsläufig „wir müssen selbst hosten." Prüfen Sie diese Option, bevor Sie davon ausgehen, eigene GPUs zu brauchen.
• Behörden- und Verteidigungsverträge sind ein anderes Kapitel. Viele verlangen, dass Modell und Daten in einer akkreditierten Umgebung liegen (FedRAMP, IL4/IL5 oder vollständig air-gapped) – dort scheidet eine öffentliche API unabhängig von jedem BAA aus. Hier ist Self-Hosting keine Option mehr, sondern Pflicht.

Open-Weight-Modellqualität – ehrlich bewertet

Bei klar abgegrenzten Aufgaben – Klassifikation, Extraktion, strukturierte Triage, Intent-Routing – kann ein Open-Weight-Modell, das auf Ihren Daten feinabgestimmt oder gut angeleitet wurde, mit einem Frontier-Closed-Modell mithalten, während Sie volle Kontrolle über Latenz und Datenschutz behalten. Die Llama-Familie von Meta und Alibabas Qwen-Modelle sind beide vernünftige Ausgangspunkte für Self-Hosted-Deployments.

Bei offenem Reasoning, langen Dokumenten oder allem, bei dem das Risiko „subtil falsche, aber selbstsicher klingende Antwort" ist, haben die Frontier-API-Modelle weiterhin einen Vorsprung. Lassen Sie sich nicht dazu verleiten, durch Self-Hosting eine Qualitätsregression einzugehen, um Geld bei einer Aufgabe zu sparen, bei der das Urteilsvermögen des Modells das eigentliche Produkt ist.

Ein praktischer Entscheidungspfad

1. Schätzen Sie das tatsächliche Token-Volumen, nicht die Anzahl der Anfragen. Multiplizieren Sie die durchschnittlichen Tokens pro Anfrage mit der täglichen Anfragenanzahl. Wenn Sie unter rund 10 bis 20 Mio. Tokens/Tag liegen, starten Sie mit einer API.
2. Prüfen Sie, ob ein HIPAA/BAA-fähiger Endpunkt eines großen Anbieters Ihre Compliance-Anforderung erfüllt. Falls ja, müssen Sie wahrscheinlich nicht selbst hosten.
3. Wenn weder Kosten noch Compliance Ihre Hand zwingen, hosten Sie nicht selbst. Der operative Overhead lenkt in den ersten 12 bis 18 Monaten eines Unternehmens vom Produktaufbau ab.
4. Wenn Sie doch selbst hosten, budgetieren Sie für Redundanz und eine feste On-Call-Rotation – nicht nur für den GPU-Posten.

Dieselbe Logik gilt für die Entscheidung zwischen Managed- und Bring-Your-Own-Key-Anbietern in BYOK vs. Managed LLM Keys: Die auf dem Papier günstigste Option ist selten die günstigste, sobald man die operative Last einrechnet, die sie dem Team aufbürdet.

Wenn Sie herausfinden möchten, wo Ihr Produkt auf dieser Skala tatsächlich steht, sprechen Sie uns an.