Self-Hosted LLM vs API Kosten: Break-Even-Analyse (2026)

Alle paar Monate stellt mir ein Klient dieselbe Frage. “Wir verbrennen 8k Dollar pro Monat bei Claude. Sollten wir Llama selbst hosten?” Die Antwort ist fast immer Nein, und der Grund hat nichts damit zu tun, ob das Modell gut genug ist. Er hat damit zu tun, was eine GPU im Leerlauf kostet, und wie viel Engineering-Zeit nötig ist, um einen Serving-Stack um 3 Uhr morgens gesund zu halten.

Diese Anleitung schlüsselt Self-Hosted LLM vs API Kosten mit realen Zahlen auf. Hetzner-GPU-Preise, RunPod- und Lambda-Stundensätze, Token-Preise für Claude Sonnet 4.6 und Haiku 4.5 sowie die Break-Even-Punkte, die tatsächlich zählen. Ziel ist es, Ihnen einen Entscheidungsrahmen zu geben, nicht einen Marketingpitch für eine der beiden Seiten.

Wenn Sie die reinen Pro-Token-Preise für gehostete Modelle wollen, habe ich das im LLM API Kostenvergleich aufgeschrieben. Diese Anleitung ist die andere Hälfte: was sich ändert, wenn Sie das Modell auf Ihre eigene GPU legen.

Fazit vorweg

APIs gewinnen für 95 Prozent der produktiven Workloads im Jahr 2026. Diese Zahl ist keine Absicherung. Für die meisten Teams, die Agents, Chat-Features, Extraktions-Pipelines und interne Tools bauen, sieht der Listenpreis von Claude Sonnet 4.6 mit 3/15 Dollar pro Million Token auf der Tabellenkalkulation teuer aus und entpuppt sich als mit Abstand günstigster Weg, sobald Sie Engineering-Zeit, Leerlaufkosten der GPU und den Ops-Aufwand für den Betrieb der eigenen Inferenz berücksichtigen.

Self-Hosting gewinnt in fünf Fällen, und nur in diesen fünf:

1. Sehr hohes Volumen. Ab etwa 50M Token/Tag an stetiger Last beginnt sich die Rechnung in Richtung Self-Hosted zu kippen, und ab 100M Token/Tag liegt es klar vorne, wenn ein offenes Modell Ihre Qualitätsanforderungen erfüllt.
2. Strenge Datenresidenz, die kein API-Anbieter erfüllen kann. Claude, OpenAI und die großen Hyperscaler haben alle EU- und US-Optionen, BAA, Zero-Retention-Endpoints und Region-Pinning. “Daten dürfen unser Netzwerk niemals verlassen” ist eine engere Forderung als noch vor zwei Jahren.
3. Fein abgestimmte eigene Modelle. Wenn Sie auf Ihren Daten trainierte Gewichte brauchen, die Ihnen tatsächlich gehören und die Sie neu deployen können, hosten Sie per Definition selbst.
4. Kostensensitiver Bulk-Betrieb mit vorhersehbarer Last. Hochvolumige Klassifikation, Extraktion, Embeddings und Zusammenfassungen, bei denen Sie eine GPU rund um die Uhr auf 70 Prozent oder mehr Auslastung halten können.
5. Modelle, die die API-Anbieter nicht anbieten. Kleine spezialisierte Modelle, ältere Modellversionen, die für eine Legacy-Integration eingefroren wurden, domänenspezifisch getunte offene Gewichte von Hugging Face ohne gehostetes Pendant.

Wenn Ihr Workload keiner dieser fünf Fälle ist, hören Sie auf zu lesen und wählen Sie das richtige gehostete LLM für die Produktion. Alles Weitere unten gilt für Fälle, in denen Self-Hosting ernsthaft auf dem Tisch liegt.

Das Kostenmodell für APIs

Das Kostenmodell für die Claude API besteht aus drei Zahlen: Input-Preis, Output-Preis und null Infrastruktur.

Für 2026:

Das ist das komplette Preisblatt. Keine Leerlaufkosten, keine reservierte Kapazität, keine GPU, die Sie bezahlen, wenn niemand sie nutzt. Wenn Sie diesen Monat null Anfragen senden, zahlen Sie null Dollar. Die Skalierung ist in beide Richtungen elastisch.

Darüber hinaus bekommen Sie Prompt Caching (90 Prozent Rabatt auf gecachten Input), Batch-Verarbeitung (50 Prozent Rabatt für nicht-realtime Jobs) sowie ein globales SDK, das Retries, Rate Limits und Streaming ohne Aufwand auf Ihrer Seite handhabt. Der effektive Pro-Token-Satz bei einem gut abgestimmten Workload mit aktiviertem Prompt Caching liegt oft 30 bis 50 Prozent unter dem Listenpreis.

Die Ausfallmodi: Pro-Token-Kosten summieren sich bei Skalierung, Ihre Latenz hängt von der Queue-Tiefe des Anbieters ab, und Sie unterliegen dessen Rate Limits (die Sie auf Anfrage erhöhen, aber nicht eliminieren können).

Das Kostenmodell für Self-Hosting

Self-Hosting hat vier Kostenblöcke, und die meisten Leute sehen nur den ersten.

Hardware oder Miete. Sie kaufen entweder eine GPU und racken sie ein, oder Sie mieten eine. Bei Hetzner kostet ein GEX44 mit einer RTX 4000 Ada (20GB VRAM) 184 Euro pro Monat. Das reicht aus, um quantisiertes Llama 3.3 70B zu servieren oder kleinere Modelle in voller Präzision zu betreiben. Eine dedizierte H100 bei RunPod kostet on-demand etwa 2,50 Dollar pro Stunde, bei Lambda Labs rund 2,80 Dollar pro Stunde. Eine H100 24/7 einen Monat lang zu betreiben kostet 1.800 bis 2.000 Dollar.

Zum Vergleich auf der Cloud-GPU-Seite habe ich einen separaten Beitrag zu GPU Cloud Vergleich für AI-Inferenz, der Spot-Preise und reservierte Instanzen abdeckt. Und Hetzner vs AWS für AI-Workloads behandelt den Tradeoff zwischen Bare-Metal und Hyperscaler für alles, was im Steady-State läuft.

Leerlaufzeit. Eine GPU im Ruhezustand kostet genauso viel wie eine GPU bei 100 Prozent. Wenn Ihre Last stoßweise ist (Peak um 9 Uhr, nichts um 2 Uhr morgens), zahlen Sie für Kapazität, die Sie nicht nutzen. Die Claude API berechnet Ihnen null, wenn Sie im Leerlauf sind. Das ist der größte einzelne Kostenunterschied bei niedrigem bis mittlerem Volumen.

Engineering-Zeit. Ein produktionstaugliches Inferenz-Setup zum Laufen zu bringen sind 2 bis 4 Wochen fokussierter Arbeit für jemanden, der das schon einmal gemacht hat, länger, wenn es das erste Mal ist. Das umfasst vLLM-Deployment, Modell-Download und Validierung, Lasttests, Autoscaling, Observability und eine Deployment-Pipeline. Danach geht es laufend weiter: Modell-Updates, Upgrades des Serving-Stacks, Incident Response. Kalkulieren Sie dauerhaft 10 bis 20 Prozent der Zeit eines Engineers ein, wenn es gesund bleiben soll.

Der unsichtbare Stack. API-Queueing, Retries, Backoff bei Rate Limits, Streaming, Multi-Region-Failover, Kostenüberwachung, Request-Logging, Latenz-SLOs, Security-Hardening des Inferenz-Endpoints. Das Anthropic SDK erledigt das alles. Sie dürfen es nachbauen.

Break-Even-Rechnung bei realistischen Volumina

Hier kommt der Moment der Wahrheit. Vier Szenarien, alle mit Claude Sonnet 4.6 als API-Baseline und einem vernünftigen offenen Modell (Llama 3.3 70B oder Qwen 2.5 72B) als Self-Hosted-Alternative. Nehmen Sie der Einfachheit halber einen 50/50 Input/Output-Split an.

Szenario: 1M Token/Tag

Claude Sonnet 4.6: 500k Input @ 3 Dollar/M + 500k Output @ 15 Dollar/M = 1,50 + 7,50 = 9 Dollar/Tag, also etwa 270 Dollar/Monat.

Ein Hetzner GEX44 für 184 Euro/Monat schafft das locker, aber die GPU ist 95 Prozent der Zeit im Leerlauf. Selbst bei 184 Euro/Monat sind die Pro-Token-Kosten in Ordnung, aber Sie haben 3 bis 4 Wochen Engineering-Zeit investiert, um 86 Dollar pro Monat zu sparen. Das ist eine Amortisationszeit von 3 bis 5 Jahren allein für die Einrichtungskosten, bevor laufender Ops-Aufwand einbezogen ist.

Fazit: API gewinnt, nicht knapp.

Szenario: 10M Token/Tag

Claude Sonnet 4.6: 5M Input + 5M Output = 15 + 75 = 90 Dollar/Tag, ungefähr 2.700 Dollar/Monat.

Auf einem Hetzner GEX44, der ein quantisiertes 70B-Open-Modell mit vLLM serviert, liegen 10M Token/Tag deutlich innerhalb der Kapazität. Der Durchsatz auf einer A4000-Klasse-GPU mit vLLM beträgt 200 bis 500 Token/Sekunde für ein quantisiertes 70B-Modell, also lassen 10M Token/Tag (etwa 115 Token/Sekunde im Schnitt) erheblichen Spielraum. Hardwarekosten: 184 Euro/Monat. Engineering-Zeit: weiterhin 2 bis 4 Wochen vorab plus laufend.

Break-Even gegenüber Sonnet: ja, wenn die Qualität akzeptabel ist. Break-Even gegenüber Haiku 4.5 (0,80/4 Dollar, also 24 Dollar/Tag, 720 Dollar/Monat) ist schwieriger. Haiku bewältigt viele der Workloads, für die Leute zu Self-Hosting greifen.

Fazit: hängt davon ab, gegen welches API-Modell Sie tatsächlich antreten. Gegen Sonnet ist Self-Hosting bei diesem Volumen günstiger. Gegen Haiku ist es ein Unentschieden.

Szenario: 100M Token/Tag

Claude Sonnet 4.6: 900 Dollar/Tag, 27k Dollar/Monat. Haiku 4.5: 240 Dollar/Tag, 7,2k Dollar/Monat.

Bei 100M Token/Tag (1.150 Token/Sekunde im Schnitt) ist ein einzelner GEX44 ausgelastet. Sie brauchen 2 bis 4 GPUs, wahrscheinlich H100-Klasse, wenn Sie Spielraum wollen, also 4 bis 8k Dollar/Monat für Cloud-GPUs. Self-Hosted gewinnt klar gegen Sonnet und ist gegen Haiku konkurrenzfähig, wenn Sie die Durchsatzvorteile bei Bulk-Workloads einrechnen.

Hier kommt auch Fine-Tuning ins Spiel. Wenn Sie ein 7B- bis 13B-Modell auf Ihre spezifische Aufgabe feintunen und auf einer einzelnen A4000 servieren können, werden die Stückkosten noch besser.

Fazit: Self-Hosted gewinnt, wenn ein offenes Modell Ihre Qualitätshürde nimmt.

Szenario: 1B Token/Tag

In dieser Größenordnung betreiben Sie einen kleinen Cluster. 4 bis 8 H100s, dediziertes Ops-Team, Custom-Routing. Claude Sonnet läge bei 9k Dollar/Tag (270k Dollar/Monat). Self-Hosted mit feingetunten Modellen liegt im Bereich von 30 bis 80k Dollar/Monat all-in inklusive Engineering-Overhead. Der Break-Even ist offensichtlich, aber es ist kein Nebenprojekt mehr. Sie brauchen ein Team.

Grobe Faustregel: Break-Even für Self-Hosting gegen Claude Sonnet 4.6 liegt bei 2 bis 5M Token/Tag, wenn ein offenes 70B-Modell Ihre Qualitätsanforderungen erfüllt. Gegen Haiku 4.5 eher bei 15 bis 25M Token/Tag. Gegen Opus 4.7 beginnt der Break-Even bei rund 500k Token/Tag, aber Sie akzeptieren dann auch einen Qualitätsverlust, der selten gerechtfertigt ist für die Art von Workload, die Opus überhaupt rechtfertigt.

Was Sie beim Self-Hosting aufgeben

Das ist die Liste, die die meisten Self-Hosting-Pläne erledigt, sobald Teams ihr tatsächlich gegenüberstehen.

Modellqualität an der Spitze. Claude Opus 4.7 ist bei Reasoning, Code und agentischen Aufgaben deutlich vor den besten offenen Gewichten. Der Abstand bei Alltagsaufgaben hat sich stark verringert, aber der Abstand bei schwierigen Aufgaben (mehrstufiges Reasoning, komplexes Tool Use, lange Generierung mit starker Kohärenz) ist weiterhin real.

Zuverlässigkeit von Tool Use. Claudes tool_use ist auf eine Weise produktionsreif, zu der offene Modelle noch aufholen. Wenn Ihr Agent fünf Tools nacheinander aufruft und das JSON-Schema jedes Mal stimmen muss, liefert Claudes First-Party Tool Use das. Offene Modelle mit über Prompt-Templates nachgerüstetem Function Calling scheitern häufiger, und die Fehler sind schwerer zu debuggen. Ich habe mehr dazu im Claude API Tool Use Guide geschrieben.

Long-Context-Recall. Offene Modelle mit 128k Context Windows fallen jenseits von 32k oft stark ab, besonders beim Needle-in-Haystack-Recall. Claude hält Kohärenz über 200k+ Token in Produktion auf eine Weise, die das offene Ökosystem nicht erreicht hat.

Vision und Multimodal. Claude akzeptiert Bilder nativ, verarbeitet PDFs und generiert strukturierte Ausgaben zu visuellen Inhalten im selben API-Aufruf. Self-Hosted-Vision-Modelle existieren, erfordern aber eine separate Pipeline.

Prompt Caching. Das Prompt Caching von Anthropic gibt Ihnen 90 Prozent Rabatt auf gecachte Input-Token und ist eine einzeilige Codeänderung. Self-Hosted erfordert, dass Sie Ihren eigenen Caching-Layer bauen, was machbar, aber nicht trivial ist.

Ökosystem. SDK in jeder Sprache, Dokumentation, Community-Beispiele, Debugging-Tools, Drittanbieter-Integrationen. Das Ökosystem gehosteter APIs ist dem offenen Self-Hosted-Tooling Jahre voraus.

Was Sie beim Self-Hosting gewinnen

Daten verlassen niemals Ihr Netzwerk. Das zählt für regulierte Branchen, klassifizierte Workloads und alles, wo Ihre Rechtsabteilung entschieden hat, dass keine externe API akzeptabel ist.

Keine Rate Limits. Sie werden durch Ihre eigene GPU begrenzt, nicht durch die Rate-Limit-Policy eines Anbieters. Für Workloads, die dauerhaft hohen Durchsatz brauchen, ist das ein echter Vorteil.

Gewichte, die Ihnen gehören. Feingetunte Checkpoints, die Sie überall neu deployen können. Kein Vendor-Lock-in beim Modell selbst.

Vorhersehbare Pauschalkosten. Sobald die GPU bezahlt ist, sind die Grenzkosten pro Token praktisch null. Das macht Budgetierung trivial und beseitigt die Überraschung “Wir haben diesen Monat 30k Dollar in API-Aufrufen verbrannt”.

Vorhersagbarkeit der Latenz. Keine Queue-Varianz der API. Ihr p99 ist, was Ihre GPU liefert, Punkt.

Modelle, die sonst niemand hostet. Kleinere spezialisierte Modelle, ältere Versionen, eingefroren für eine Legacy-Pipeline, domänenspezifische Tunes von Hugging Face ohne gehostetes Pendant.

Welche offenen Modelle sind realistisch für Self-Hosting?

Nicht jedes offene Modell ist produktionsreif. Das würde ich 2026 tatsächlich in einen Serving-Stack stecken.

Llama 3.3 70B. Stark als Allzweckmodell, breite Tooling-Unterstützung, vLLM serviert es gut. In fp16 braucht es rund 140GB VRAM, also 2x A100 80GB oder eine H100 plus Spielraum. Auf 4-Bit quantisiert (AWQ oder GPTQ) passt es in 40GB, also funktioniert ein Setup mit einer einzelnen A100 40GB oder RTX 4090 48GB.

Qwen 2.5 72B. Konkurrenzfähig mit Llama 3.3 bei den meisten Benchmarks, oft besser bei Multilingualität. Gleiches VRAM-Profil. Starke Option, wenn Sie eine Nicht-Meta-Alternative wollen.

DeepSeek V3. Mixture-of-Experts-Architektur, starkes Reasoning, wird mit vLLM serviert. Interessant für Teams, die im Open-Modell-Bereich Performance nahe Sonnet bei Reasoning-Aufgaben wollen. Höhere Gesamt-Parameterzahl, aber aktive Parameter pro Token sind niedriger.

Mistral. Ältere Versionen mit offenen Gewichten (Mixtral, Mistral Large vor der Schließung) sind für viele Workloads weiterhin solide.

Phi-4. Microsofts kleineres Modell, überraschend stark bei schmalen Aufgaben, läuft auf Consumer-GPUs (24GB VRAM reichen locker). Gute Wahl für Klassifikation, Extraktion, strukturierte Ausgabe, wenn Sie kein Frontier-Reasoning brauchen.

7B bis 13B Modelle. Für Embedding, Klassifikation, einfache Extraktion und Routing ist ein 7B- bis 13B-Modell auf einer einzelnen 20GB-GPU oft alles, was Sie brauchen. Hier beginnt die Hetzner-GEX44-Ökonomie exzellent auszusehen.

Wenn Sie eines dieser Modelle auf Kubernetes deployen, habe ich einen längeren Beitrag zu Self-Hosted LLM auf Kubernetes, der vLLM-Deployment, Autoscaling und Observability abdeckt.

Die Optionen beim Serving-Stack

Der Inferenzserver zählt fast so viel wie das Modell.

vLLM. Mein Standard. Am schnellsten, produktionsreif, PagedAttention macht die Speichernutzung für gebatchte Inferenz effizient. Starke OpenAI-kompatible API. Aktive Weiterentwicklung. Wenn Sie im großen Stil servieren, ist das der Ausgangspunkt.

Text Generation Inference (TGI). Der Inferenzserver von Hugging Face. Solide, weit verbreitet, gute Integration mit dem HF Model Hub. Bei reinem Durchsatz in den meisten von mir gemessenen Benchmarks leicht hinter vLLM, aber absolut produktionstauglich.

Ollama. Exzellent für Entwicklung und lokales Experimentieren. Nicht produktionsreif für Multi-Tenant-Serving. Ich nutze es auf meinem Dev-Rechner, würde es aber nicht hinter einem Produktions-Endpoint einsetzen.

llama.cpp. CPU-freundlich, läuft auf Edge-Geräten, gut für Mac-Deployments. Langsamer als GPU-basierte Stacks, aber nützlich, wenn GPU keine Option ist.

SGLang. Neuer, konkurrenzfähig mit vLLM beim Durchsatz, besonders stark bei strukturierter Ausgabe und Constrained Decoding. Lohnt sich zu beobachten.

Für die Produktion: vLLM oder TGI. Alles andere ist Dev-Tooling.

Die realen Kostenkategorien, die Leute vergessen

Die Tabelle sieht meistens aus wie “GPU-Kosten + Strom = Gesamt”. So ist es nicht.

GPU-Capex oder laufende Miete. Der offensichtliche Posten.

Leerlaufzeit. GPU im Ruhezustand kostet genauso viel wie GPU bei 100 Prozent. Wenn Sie die Auslastung nicht über 60 Prozent halten können, sieht die Pro-Token-Ökonomie schlechter aus als die Broschüre suggeriert. Der API-Anbieter verteilt Leerlauf über Tausende von Kunden; Sie verteilen ihn über Ihren eigenen Traffic allein.

Engineering-Zeit, initial. 2 bis 4 Wochen fokussiertes Senior-Engineering, um einen produktiven Serving-Stack aufzubauen: Deployment, Autoscaling, Monitoring, Lasttests, Security.

Engineering-Zeit, laufend. 10 bis 20 Prozent der Zeit eines Senior-Engineers dauerhaft: Modell-Updates, Upgrades des Serving-Stacks, Incident Response, Kostenoptimierung, Nachverfolgung von Qualitätsregressionen beim Modellwechsel.

Observability. Kosten pro Request, Latenzperzentile, Quality Drift, Token-Accounting. Die API liefert Ihnen das meiste davon out of the box. Sie bauen es.

Modell-Updates. Wenn Anthropic Sonnet 4.7 oder Haiku 5.0 ausliefert, bekommen Sie es mit einer Änderung am Modellstring. Wenn ein neues offenes Modell erscheint, laden Sie es herunter, benchmarken es, re-validieren es auf Ihrer Eval-Suite, testen die Serving-Performance und deployen neu. Planen Sie eine Woche pro großem Modellwechsel ein.

Security Surface. Ihr Inferenz-Endpoint ist nun eine Angriffsfläche, die Ihnen gehört. Authentifizierung, Autorisierung, Rate Limiting, DDoS-Schutz, Input-Validierung, um Prompt Injection daran zu hindern, zur Modellebene durchzusickern.

Redundanz. Die API hat Multi-Region-Failover eingebaut. Sie bauen es nach. Ein Single-GPU-Deployment hat eine einzige Fehlerdomäne, was für Batch in Ordnung ist, aber nicht für Echtzeit.

Wenn Sie das ehrlich addieren, verschiebt sich die Self-Hosting-Ökonomie deutlich. Ein Setup, das auf Hardware-Ebene 2k Dollar/Monat günstiger aussieht, kostet oft 4 bis 6k Dollar/Monat mehr, sobald Sie die Engineering-Amortisation einrechnen.

Das hybride Muster

So machen es die meisten produktiven Teams, mit denen ich arbeite, am Ende tatsächlich. Weder rein Self-Hosted noch rein API. Beides.

Self-Hosting für:

• Bulk-Klassifikation (Millionen von Datensätzen, einfaches Schema)
• Extraktion aus strukturierten oder halbstrukturierten Daten
• Embeddings (ein kleines Modell auf einer günstigen GPU erledigt das für Cents)
• Einfache Zusammenfassungen, wenn die Qualitätshürde “gut genug” lautet
• Jeder Workload, bei dem das p95-Volumen vorhersehbar und dauerhaft ist

Claude API für:

• Reasoning, mehrstufige Agents, komplexes Tool Use
• Mehrsprachige Content-Generierung
• Long-Context-Aufgaben (komplette Verträge, lange Codebases analysieren)
• Vision und Multimodal
• Alles Kundenseitige, bei dem Qualitätsvarianz zählt
• Burst-Traffic, der Ihre Self-Hosted-GPU über die Kapazität hinaus treiben würde

Ein einfacher Routing-Layer entscheidet pro Request. Klassifikations-Input? Self-Host. Kundensupport-Agent? Claude. Ein Dokumenten-Batch einbetten? Self-Host. Einen 50-seitigen Vertrag analysieren? Claude.

Dieses Muster nutzt die Kostenersparnis von Self-Hosting bei den Workloads, die es rechtfertigen, und behält gleichzeitig die Qualität und die Ops-Einfachheit der API für die Workloads, die sie brauchen. Fast niemand landet bei 100 Prozent Self-Host. Teams, die das behaupten, haben meist eine zweite gehostete Pipeline, die sie zu erwähnen vergessen haben.

Sechs Fragen vor dem Self-Hosting

Gehen Sie diese ehrlich durch. Welche davon Sie wegrationalisieren wollen, geht auf Ihr eigenes Risiko.

1. Wie hoch ist mein p95-Token-Volumen in den nächsten 12 Monaten? Wenn es unter 5M Token/Tag gegen Sonnet liegt, unter 20M Token/Tag gegen Haiku, funktioniert die Rechnung mit ziemlicher Sicherheit nicht. Bezahlen Sie die API.

2. Ist mein Workload einfach genug, dass ein offenes 70B- oder kleineres Modell gut abschneidet? Machen Sie eine Eval. Wirklich durchführen. “Ich glaube, Llama wird reichen” ist kein Beleg. Nehmen Sie Ihre Top 200 Prompts, schicken Sie sie durch Sonnet und Llama, bewerten Sie die Ausgaben. Wenn Llama auf Ihrer Metrik innerhalb von 10 Prozent liegt, gut. Wenn es 30 Prozent schlechter ist, wird kein Self-Hosting das beheben.

3. Brauche ich Fine-Tuning? Falls ja, ist Self-Host der Weg. Falls nein, wird das Argument für Self-Host schwächer.

4. Habe ich GPU-Ops-Kompetenz oder Budget, um sie einzustellen? Wenn Ihr Team noch nie eine GPU in Produktion betrieben hat, sind das versteckte 3 bis 6 Monate Kosten, die Sie nicht einrechnen. Wenn Sie einstellen können, planen Sie 90 bis 130k Euro/Jahr für jemanden ein, der das tatsächlich gemacht hat.

5. MUSS meine Daten niemals meine Infrastruktur verlassen? Nicht “wir würden bevorzugen”, sondern tatsächlich, rechtlich, vertraglich erforderlich. Prüfen Sie zuerst, ob Zero-Retention-Endpoints von API-Anbietern Ihre Rechtsabteilung zufriedenstellen, denn zunehmend tun sie das.

6. Bin ich bereit, alle 6 Monate neu zu benchmarken, während offene Modelle und Frontier-Modelle sich weiterentwickeln? Self-Hosting ist keine einmalige Entscheidung. Der Abstand zwischen offen und geschlossen verschiebt sich. Ihre Entscheidung muss sich mit verschieben.

Wenn Sie 4 oder mehr mit Ja beantwortet haben, ist Self-Hosting möglicherweise eine ernsthafte Evaluierung wert. Wenn Sie weniger als 4 mit Ja beantwortet haben, bleiben Sie standardmäßig bei der API. Das ist keine Ausflucht, es ist die richtige Entscheidung für das Volumen- und Workload-Muster, das die meisten Teams tatsächlich haben.

Was sollten Sie wählen?

Für die meisten Teams ist 2026 die Antwort die API. Claude Sonnet 4.6 für qualitätssensitive Arbeit, Haiku 4.5 für kostensensitiven Bulk-Betrieb, beide mit Prompt Caching, um den effektiven Satz um weitere 30 bis 50 Prozent zu drücken. Die Engineering-Zeit, die Sie sparen, bezahlt eine Menge Token.

Self-Host, wenn das Volumen wirklich im Bereich von 10M+/Tag auf einem Workload liegt, bei dem ein offenes Modell Ihre Qualitätsanforderungen erfüllt, oder wenn Sie harte Datenresidenz-Anforderungen haben, die keine API erfüllen kann, oder wenn Sie feingetunte Gewichte brauchen, die Ihnen gehören. In diesen Fällen starten Sie mit vLLM auf einem Hetzner GEX44 oder einer einzelnen H100-Miete, belegen die Stückkosten mit 30 Tagen echtem Traffic und skalieren dann.

Das hybride Muster ist der Ort, an dem die meisten ernsthaften Produktions-Setups landen. Hosten Sie den vorhersehbaren Bulk selbst, nutzen Sie Claude für hochwertige und stoßweise Arbeit. Ein Router dazwischen. Das ist die Architektur, die tatsächlich ausgeliefert wird.

Weiterführende Lektüre

• LLM API Kostenvergleich: Pro-Token-Preise
• Self-Hosted LLM auf Kubernetes
• GPU Cloud Vergleich für AI-Inferenz
• Hetzner vs AWS für AI-Workloads
• Wie Sie ein LLM für die Produktion auswählen