Selbst gehostetes LLM 2026: Datensouveränität und technische Entscheidungen

2026 ist das Self-Hosting eines großen Sprachmodells keine Laborkuriosität mehr. Es ist zu einer reifen, leistungsfähigen und wirtschaftlich verteidigbaren Option für einen wachsenden Teil der von uns gescopten Projekte geworden. Offene Modelle wie Mistral Large 2, Llama 3.3 70B, Qwen 2.5 72B oder DeepSeek V3 erreichen heute 90 bis 95 % der Leistung von GPT-4 Turbo oder Claude 3.7 Sonnet in den meisten Standardfällen: Extraktion, Klassifikation, Zusammenfassung, assistierte Generierung, RAG. Diese Qualitätslücke, die 2023 noch ein K.-o.-Kriterium war, hat sich so weit verringert, dass die Frage nicht mehr lautet „ist es gut genug?“, sondern „was ist die richtige Abwägung für unser Geschäft?“.

Dieser Artikel richtet sich an CTOs, CIOs und Lead Engineers, die das selbst gehostete LLM ernsthaft prüfen. Wir detaillieren die sechs strukturierenden Entscheidungen: Souveränitätskriterien, Modellwahl, GPU-Dimensionierung, Serving-Stack, Sicherheit und Observability, FinOps. Wir stützen uns auf das, was wir konkret in unseren Projekten sehen, ohne dem üblichen Marketing-Diskurs nachzugeben. Souveränität heißt nicht „um jeden Preis alles selbst hosten“: Die Frage ist, wo die Grenze zu ziehen ist und mit welchem Ingenieursanspruch.

Warum diese Frage 2026 mit Macht zurückkehrt

Drei Kräfte konvergieren. Erstens verschärft sich die Regulierung: DSGVO für alle personenbezogenen Daten, HDS für den Gesundheitssektor, NIS2 für essenzielle Betreiber, AI Act für risikoreiche Systeme — ganz zu schweigen von den spezifischen vertraglichen Anforderungen, die Großkunden ihren Dienstleistern inzwischen auferlegen. Viele dieser Klauseln verbieten ausdrücklich die Übertragung an eine außereuropäische KI-API oder verlangen eine vollständige Rückverfolgbarkeit, die bei einer Drittanbieter-API nicht zu garantieren ist.

Zweitens hat das Open-Weight-Ökosystem aufgeholt. Mistral Large 2 (123B Parameter), Llama 3.3 70B, Qwen 2.5 72B und DeepSeek V3 (671B in MoE, ~37B aktiv) sind heute industrielle Modelle. Gekoppelt mit Servern wie vLLM oder TensorRT-LLM und NVIDIA-Hardware H100, A100 oder L40S, oder auch AMD MI300X, liefern sie reale Durchsätze von 30 bis 80 Tokens pro Sekunde je Anfrage, mit dynamischem Batching, das auf einem korrekt dimensionierten Server mehrere Hundert gleichzeitige Nutzer absorbiert.

1. Souveränitätskriterien vor allem anderen definieren

Der häufigste Fehler besteht darin, ein Modell zu wählen und das Projekt anschließend mit einem Souveränitätsdiskurs zu bekleiden. Das rigorose Vorgehen ist umgekehrt: zunächst die Datensensibilität, die regulatorischen Pflichten und die vertraglichen Verpflichtungen qualifizieren, dann die technischen Implikationen ableiten. Eine identifizierende Gesundheitsdaten verlangt ein HDS-Hosting und schließt jede API außerhalb der EU aus. Ein durch einen Verteidigungskunden klassifiziertes Dokument verlangt eine vollständige Netzwerktrennung. Ein F&E-Geschäftsgeheimnis verlangt mindestens Verschlüsselung in Transit und im Ruhezustand und idealerweise eine Infrastruktur, deren Betreiber kein Zugriff auf das LLM hat.

In unseren Audits trennen wir systematisch drei Stufen: öffentliche oder anonymisierte Daten (proprietäre API akzeptabel), interne vertrauliche Daten (europäische API mit striktem AVV oder souveräne Cloud mit Self-Host), sensible oder regulierte Daten (Self-Host zwingend, idealerweise on-prem oder SecNumCloud-/HDS-Cloud). Dieses Raster erlaubt es, den Bedarf zu objektivieren und das „Alles oder Nichts“ zu vermeiden, das die meisten KI-Komitees lähmt.

2. Das passende Open-Weight-Modell wählen

Die Modellwahl hängt von vier Kriterien ab: Qualität auf Ihren Fällen, spezifische Qualität in der Zielsprache, Größe (also Infrastrukturkosten) und Lizenz. Mistral Large 2 bleibt unsere Referenz für anspruchsvolle frankophone Fälle: Reasoning-Qualität, Instruction Following, natürliche Generierung. Llama 3.3 70B bietet ein hervorragendes Qualitäts-/Größenverhältnis, aber seine Lizenz (Acceptable Use Policy) bleibt für bestimmte Anwendungen einschränkend und schließt sehr große Plattformen aus. Qwen 2.5 72B ist erstaunlich stark in Code und Mathematik. DeepSeek V3 als MoE bietet eine Qualität nahe an GPT-4 mit paradoxerweise moderaten Serving-Kosten dank der 37B aktiven Parameter.

Unsere Methode: Wir glauben generischen Rankings wie MMLU oder Chatbot Arena nie. Wir bauen einen internen Benchmark aus 50 bis 200 für den Kundenkontext repräsentativen Prompts und messen Faithfulness, Format, Ton, Latenz und Kosten für jedes Kandidatenmodell. Das ist die einzige Möglichkeit, ehrlich zu entscheiden.

• Mistral Large 2 (123B): exzellentes Französisch, klare MRL-Lizenz, Deployment 2-4×H100
• Llama 3.3 70B: bestes Qualitäts-/Größenverhältnis, Vorsicht bei der AUP
• Qwen 2.5 72B: stark in Code und Reasoning, teilweise Apache-2.0-Lizenz
• DeepSeek V3 (671B MoE): Top-Tier-Qualität, trotz Größe vernünftige Serving-Kosten

3. Die GPU-Infrastruktur dimensionieren

Die Dimensionierung ist nicht intuitiv. Drei Variablen zählen: verfügbarer VRAM, Ziel-Latenz (Time to First Token und Tokens/Sekunde je Nutzer) und Nebenläufigkeit (gleichzeitige Nutzer). Für ein in INT4 quantisiertes Llama 3.3 70B reicht eine einzige H100 80GB im POC, sättigt aber rasch über 5-10 gleichzeitigen Nutzern. In FP8 sind zwei H100 nötig. Für Mistral Large 2 in der Produktion starten wir typischerweise mit 2 bis 4×H100 oder einem 8×L40S-Knoten je nach Lastprofil.

Infrastrukturseitig dominieren zwei Optionen: Direktkauf (1×H100 80GB rund 30 bis 40 k€ netto, abschreibbar auf 24-36 Monate) oder Cloud-GPU-Miete bei Scaleway, OVHcloud, Lambda Labs oder RunPod, zwischen 2,5 und 4 € pro Stunde je nach Anbieter und Bindung. Die europäische GPU-Cloud bleibt relevant, wenn man Souveränität und Flexibilität verbinden möchte, vorausgesetzt, die reale Jurisdiktion des Anbieters und gegebenenfalls dessen SecNumCloud-Status werden geprüft.

4. Den Serving-Stack auswählen

Vier Optionen strukturieren den Markt. vLLM ist zur Open-Source-Referenz geworden: PagedAttention, Continuous Batching, OpenAI-kompatibler Support, riesige Community. Das ist unsere Standardwahl. TGI (text-generation-inference von Hugging Face) bleibt sehr solide, besonders gut in das HF-Ökosystem integriert, leicht weniger performant als vLLM im Durchsatz, aber sehr ausgereift in der Produktion. TensorRT-LLM von NVIDIA liefert die beste Roh-Performance auf NVIDIA-Hardware, zum Preis einer deutlich höheren Kompilier- und Wartungskomplexität — nur in großem Maßstab relevant. NVIDIA NIM bietet einen managed-on-prem-Ansatz mit einsatzbereiten containerisierten Microservices: interessant, wenn das interne Team kein erfahrenes MLOps-Profil hat, weniger flexibel und langfristig teurer.

Für Projekte mit bis zu einigen hundert nebenläufigen Nutzern ist vLLM hinter einem Reverse Proxy (Traefik, NGINX) mit einem OpenAI-kompatiblen Client auf Anwendungsseite die einfachste, leistungsfähigste und wartbarste Kombination. Genau diese deployen wir in der Mehrheit unserer Self-Hosting-Projekte.

5. Das LLM in der Produktion absichern und beobachten

Ein selbst gehostetes LLM ist nie eine einfach freizugebende API. Es ist eine kritische Komponente, die potenziell sensible Daten verarbeitet und eine neue Angriffsfläche darstellt. Wir setzen systematisch vier Verteidigungslinien durch: strikte Netzwerkisolation (privates VPC, kein direkter Internetzugriff), starke Anwendungsauthentifizierung (signierte JWTs, Rotation), vollständige Protokollierung der Prompts und Antworten mit kontrollierter Retention, und Business-Guardrails (Eingabefilter, Ausgabevalidierung, Prompt-Injection-Erkennung).

Die technische Observability zählt ebenso: GPU-Monitoring (Auslastung, Speicher, Temperatur), Serving-Metriken (TTFT, Tokens/Sek., Queue-Größe), Anwendungs-Tracing (Langfuse, OpenLLMetry oder Eigenlösung). Ohne diese Telemetrie wissen Sie weder, wann Ihre Infrastruktur saturiert, noch wann ein Modell driftet, noch woher eine Qualitätsregression kommt.

6. FinOps: Den TCO ehrlich modellieren

Die finanzielle Frage erschöpft sich nicht im GPU-Preis. Der reale TCO eines selbst gehosteten LLM integriert Hardware-Abschreibung oder Miete, Strom und Kühlung bei On-Prem, interne oder externe MLOps-Kompetenzen, Modellwartung (Updates alle 3-6 Monate bei Open-Weight), Observability, Sicherheit und Upgrade-Phasen. In unseren Projekten bauen wir immer einen 24-Monats-Vergleich zwischen drei Szenarien: reine proprietäre API, hybrid (API für Spitzen, Self-Host für das Wiederkehrende), Full Self-Host.

Zur Orientierung: Mistral Large 2 auf 1×H100 80GB im optimierten vLLM-Serving liefert rund 50 Tokens/Sekunde pro Anfrage und 1500 bis 2500 Tokens/Sekunde aggregierten Durchsatz je nach Batching. Über 30 volle Tage entspricht das einem theoretischen Volumen von mehreren Milliarden Tokens, zu vergleichen mit einer entsprechenden API-Rechnung, die sich bei diesen Volumen in Zehntausenden Euro pro Monat bemisst.

Die Fallen, die Self-Hosting-Projekte scheitern lassen

Vier Fallen kehren in unseren Rettungs-Audits wieder. Erstens, Observability unterschätzen: Ohne Telemetrie steuert das Team blind, und jede Panne wird zur Katastrophe. Zweitens, die Netzwerksicherheit vernachlässigen: Zu viele POCs gehen mit einem im Klartext exponierten vLLM-Endpunkt in die Produktion. Drittens, die wiederkehrenden Kosten der Modell-Updates vergessen: Ein Open-Weight-LLM von 2026 wird 2027 obsolet sein, der Upgrade-Rhythmus muss bereits im Scoping eingeplant werden. Viertens, das Team nicht ausbilden: Ein selbst gehostetes LLM wird nicht wie ein klassischer Microservice gesteuert, MLOps- und ML-Engineering-Kompetenzen sind unverzichtbar.

Zu diesen technischen Fallen kommt eine strategische Falle: Souveränität und Performance zu verwechseln. Self-Hosting macht einen schlechten Anwendungsfall nicht gut. Wenn der Geschäftsbedarf schlecht gescopt, das RAG vernachlässigt und die Evaluation abwesend ist, wird das Projekt mit oder ohne Souveränität scheitern. Self-Hosting ist ein Mittel, kein Zweck.

Wie geht es weiter?

Wenn Sie das Self-Hosting eines LLM ernsthaft prüfen, ist der erste Schritt, Ihren Souveränitätsbedarf, Ihr Zielvolumen und die Kritikalität des Anwendungsfalls ehrlich zu qualifizieren. Genau das tun wir in unseren Scopings bei DevHighWay: zwischen API, hybrid und Self-Host mit Zahlen entscheiden, nicht mit Slogans.

• Kontakt aufnehmen für ein Souveränitäts-Scoping (Workshop 2 Tage, entscheidungsreifer Liefergegenstand)
• Unser Audit deckt auch die Sichtbarkeitsdimension Ihrer KI-Plattform ab
• Konsultieren Sie unsere Preise für die Pakete inklusive LLM-Managed-Service

Das Self-Hosting eines LLM ist heute eine glaubwürdige, manchmal die einzige Option für Organisationen, die die Kontrolle über ihre Daten behalten müssen. Aber es ist ein ernsthaftes Ingenieursprojekt, das auch so zu behandeln ist: klare Ziele, benchmarktes Modell, dimensionierte Infrastruktur, präzise Sicherheit und Observability, dokumentierte FinOps. Genau diese Haltung nehmen wir in unseren Projekten ein, und sie trennt nachhaltige Deployments dauerhaft von POCs, die beim ersten Produktionsvorfall sterben.