TL;DR
- Drei Trigger rechtfertigen Self-Hosting 2026: hochsensitive Daten (Pharma-Forschung, M&A-Diligence, Konstruktionspläne), Volumen ab 30–50 Mio. Tokens/Tag und Latenz-Hard-Requirements unter 200 ms.
- Sweet-Spot-Modell: Llama 3.3 70B auf 2× H100 liefert ~85 % MMLU/HumanEval bei einem Bruchteil der Cloud-API-Kosten und reicht für Standard-RAG, Klassifikation und Dokumentenextraktion.
- Break-Even zur Frontier-Cloud-API (Claude Opus 4.7, GPT-5) liegt bei ~30–50 Mio. Tokens/Tag — darüber ist Self-Hosting wirtschaftlich, darunter nicht.
Drei Trigger für Self-Hosting
Self-Hosting ist keine Glaubensfrage, sondern eine TCO-Entscheidung mit drei klaren Triggern. Wer keinen trifft, bleibt 2026 besser bei Cloud-APIs — Frontier-Qualität, kein DevOps-Overhead, Pay-per-Use. Erst wenn mindestens ein Trigger zieht, lohnt sich der Bench-Aufbau.
Self-Hosting ist 2026 die richtige Antwort auf drei Fragen — und die falsche auf alle anderen.
| Trigger | Schwelle 2026 | Beispiel-Use-Case |
|---|---|---|
| Daten-Sensitivität | Pharma-Forschung, M&A-Diligence, geheime Konstruktion | Patent-Vorprüfung, Deal-Room-Analyse |
| Volumen | > 30–50 Mio. Tokens/Tag | Dokumenten-Pipeline, Support-Klassifikation |
| Latenz | < 200 ms P95 (Cloud-API typ. 800–1.500 ms) | Voice-Bot, Echtzeit-Routing, IDE-Completion |
Open-Weight-Modell-Landschaft 2026
- Llama 3.3 70B — der Sweet-Spot: Default für Mittelstands-Self-Hosting, Meta Llama 3 Community License (kommerziell bis 700 Mio. MAU). Auf 2× H100 80GB mit FP8 läuft das Modell mit ~80 Tokens/Sek pro Request, ~6.000 Tokens/Sek im Batch. Qualität: ~85 % MMLU, ~88 % HumanEval, GSM8K stark. Reicht für RAG, Klassifikation, Extraktion, Summarization; unter Frontier bei Multi-Step-Reasoning und Tool-Use.
- Llama 3.1 405B — GPT-4-Klasse on-prem: MMLU 88,6 %, HumanEval 89 %. Hardware: 8× H100 80GB mit FP8 oder 16× H100 ohne Quantisierung. Sinnvoll nur bei sehr hohem Volumen (>100 Mio. Tokens/Tag) oder Reasoning-kritischen Use-Cases mit Daten-Sensitivität.
- Mistral Large 2 — EU-souverän: 123B Dense, Mistral Research License (kommerzielle Nutzung über Commercial License). Stärke: starker Code, Multi-Lingual inkl. nativem Deutsch. Hardware: 4× H100 80GB oder 2× H200 141GB. Sweet-Spot für DACH-Mittelstand mit Souveränitäts-Anforderung.
- Qwen2.5 72B — echtes Apache 2.0: keine MAU-Schranken, MMLU 86,1 %, stark bei Math und Tool-Use, auf 2× H100 lauffähig. Caveat: Gewichte aus China — in regulierter Industrie Vendor-Risk-Assessment vor Produktiv-Einsatz.
- DeepSeek-V3 — 671B MoE, 37B aktiv: effektive Hardware-Last wie ein 37B-Modell, Qualität nahe Frontier (MMLU ~88 %). Hardware: 8× H100. DeepSeek Open License, kommerziell mit Auflagen.
Quality-Gap Frontier vs Open
| Benchmark | Llama 3.3 70B | Llama 3.1 405B | DeepSeek-V3 | Claude Opus 4.7 | GPT-5 |
|---|---|---|---|---|---|
| MMLU | 85,1 % | 88,6 % | 88,5 % | ~92 % | ~93 % |
| HumanEval | 88,4 % | 89,0 % | 89,2 % | ~95 % | ~95 % |
| GSM8K | 95,1 % | 96,8 % | 96,5 % | ~98 % | ~98 % |
| MATH | 70,0 % | 73,8 % | 74,1 % | ~85 % | ~86 % |
| ARC-Agentic | 38,0 % | 52,0 % | 58,0 % | ~88 % | ~90 % |
Praxis-Lesart: Open-Weight liegt 2026 bei 85–90 % der Frontier-Qualität auf Standard-Benchmarks — aber 40–50 Prozentpunkte zurück bei agentischem Reasoning (ARC-Agentic). Für RAG und Klassifikation reicht das, für Multi-Step-Agenten nicht.
Stack: vLLM + LiteLLM + Langfuse
vLLM ist der De-facto-Standard für High-Throughput-Inference — PagedAttention und continuous batching liefern 5–10× höheren Durchsatz als HuggingFace Transformers, OpenAI-kompatible API out-of-the-box, Docker-Deployment mit Prometheus-Metriken. Davor sitzt LiteLLM als OpenAI-kompatibler Proxy: Rate-Limiting, Budget-Tracking pro Team, Fallback auf Cloud-API bei Outage, einheitliche API über mehrere Modelle. Migrations-Bonus: bestehende OpenAI-SDK-Calls laufen unverändert, nur die Base-URL wird umgestellt. Langfuse liefert die Observability-Schicht — Trace-Logging, Cost-Tracking, Latenz-Histogramme, Prompt-Versionierung, Eval-Pipelines, Open-Source und self-hostbar. In regulierter Industrie unverzichtbar: EU AI Act Art. 12 (Logging) und Art. 13 (Transparenz) sind ohne Tracing nicht erfüllbar.
Break-Even-Rechnung: Cloud vs Self-Hosted
| Volumen | Cloud (GPT-5, Mix In/Out) | Self-Hosted 2× H100 (Llama 3.3) | Self-Hosted 8× H100 (405B) |
|---|---|---|---|
| 10 Mio. Tokens/Tag | günstig | unwirtschaftlich | klar unwirtschaftlich |
| 50 Mio. Tokens/Tag | hoch | deutlich günstiger | vergleichbar |
| 100 Mio. Tokens/Tag | sehr hoch | am günstigsten | günstig |
Annahmen: H100-Server bei Hetzner/Equinix als monatliche Karten-Miete, Strom + Cooling pro Karte, DevOps 0,5 FTE auf das Setup, Cloud-API mit Mix 60 % Input / 40 % Output. Lesart: Der Break-Even Cloud vs. Self-Hosted Llama 3.3 70B liegt bei rund 30–50 Mio. Tokens/Tag. Darüber ist Self-Hosted in jedem Szenario günstiger. Darunter überwiegen die Cloud-Vorteile (Zero-Ops, Frontier-Qualität, Skalierung auf Knopfdruck).
Pilot: Pharma-Mittelständler, Llama 3.3 für Patent-Vorprüfung
| Dimension | Befund |
|---|---|
| Use-Case | Patent-Vorprüfung über interne Forschungsdaten + EPO-Datenbank |
| Daten-Sensitivität | Hochsensitiv — Forschungsergebnisse pre-publication, Cloud-API ausgeschlossen |
| Volumen | ~25 Mio. Tokens/Tag (unter Break-Even, aber Sensitivität dominiert) |
| Modell | Llama 3.3 70B, FP8-quantisiert |
| Hardware | 2× H100 80GB im eigenen RZ Frankfurt |
| Stack | vLLM + LiteLLM-Proxy + Langfuse + Qdrant-Vector-Store |
| Latenz P95 | 140 ms (vs. Cloud-API ~850 ms) |
| Qualität | Treffsicherheit Patent-Klassifikation 91 % (vs. 94 % mit Claude Opus, Delta akzeptiert) |
| Time-to-Production | 9 Wochen Pilot, 14 Wochen bis Roll-out |
Der Volumen-Trigger ist nicht erfüllt, aber der Sensitivitäts-Trigger ist dominant: Der Pharma-Mittelständler kann Forschungsdaten vertraglich nicht in US-Cloud schicken. Self-Hosting ist hier keine Cost-Optimization, sondern Daten-Compliance.
Wann NICHT self-hosten
Drei Konstellationen sprechen klar dagegen:
- Kleines Volumen (< 10 Mio. Tokens/Tag): Cloud-API ist günstiger, weniger Komplexität, Zugriff auf Frontier-Qualität.
- Instabile Use-Cases: Wer noch nicht weiß, ob er Klassifikation, Generation oder Reasoning braucht, kauft sich mit Self-Hosting eine Hardware-Bindung in eine Modell-Wahl ein, die in 6 Monaten überholt ist.
- Kein DevOps-Team: vLLM ist robust, aber GPU-Drift, Modell-Updates, Quantisierungs-Tuning und Incident-Response brauchen mindestens 0,5 FTE Senior-Engineer. Wer das nicht hat, baut Tech-Debt statt auszulagern.
Einordnung für den CIO-Tisch
Self-Hosting 2026 ist kein Standard, sondern Spezialfall — getrieben durch Daten-Sensitivität, Volumen oder Latenz. Wer einen der drei Trigger trifft, baut mit Llama 3.3 70B, vLLM, LiteLLM-Proxy und Langfuse einen produktionsreifen Stack in 8–12 Wochen. Die meisten Mittelständler treffen noch keinen Trigger und sind mit Cloud-APIs besser bedient — sobald aber ein Use-Case mit Pharma-Sensitivität, Voice-Latenz oder ≥50 Mio. Tokens/Tag entsteht, wird Self-Hosting wirtschaftlich oder regulatorisch zwingend.
Praxis-Schritt: Ein kurzer Self-Hosting-Readiness-Check klärt, welche Use-Cases im Haus die drei Trigger treffen, welche Hardware-Option (Kauf, Colocation, Cloud-GPU-Reservierung) am besten passt und ob ein 12-Wochen-Pilot mit Llama 3.3 70B den TCO-Beweis liefert. Erstgespräch anfragen → /anfrage
Stand Mai 2026. Modell-Landschaft, Hardware-Preise und Cloud-Tarife ändern sich quartalsweise — Aktualisierung dieser Übersicht durch Azena Editorial.
Nächster Schritt
Passt das auf Ihren Fall?
30-Min-Erstgespräch, kostenfrei und unverbindlich. Wir gehen Ihren konkreten Fall durch — und sagen ehrlich, wenn nichts passt.