Das lokale KI-Betriebssystem: DSGVO-konforme LLMs auf eigener Server-Infrastruktur

Ein selbst gehostetes "KI-Betriebssystem" ist kein einzelnes Produkt, sondern ein integrierter Open-Source-Stack aus Inference-Server, Gateway, Observability und Benutzeroberfläche auf eigener GPU-Hardware. Für technische Entscheider ist es 2026 der direkteste Weg zu DSGVO-Konformität, Datensouveränität und planbaren Kosten. Dieser Artikel zeigt, wie der Stack aussieht, wann er sich rechnet und welche Modelle auf einer 24-GB-Blackwell-GPU tatsächlich produktionsreif sind.

Was ist ein lokales KI-Betriebssystem?

Der Begriff beschreibt einen Software-Stack, der auf eigener Infrastruktur genau die Funktionen bereitstellt, die man sonst von einer Cloud-API bezieht: Modell-Serving, Routing, Zugriffskontrolle, Logging und ein Frontend für die Mitarbeitenden. Die 2025/2026 etablierte Referenzarchitektur besteht aus vier Schichten, ergänzt um eine Vektordatenbank für RAG. Laut mehreren Praxis-Guides ist sie in unter einer Stunde aufsetzbar.

Die Rollen im Einzelnen:

• vLLM (Inference): An der UC Berkeley entstanden. Die Kerninnovation PagedAttention verwaltet den KV-Cache in kleinen, dynamisch allokierten Blöcken, analog zu virtuellem Speicher in einem Betriebssystem. Dazu kommen Continuous Batching, Prefix Caching, Tensor-Parallelismus und eine OpenAI-kompatible API. Die Standard-Empfehlung für Produktion.
• LiteLLM (Gateway): Ein Open-Source-Proxy, der über 100 Modell-Anbieter auf das OpenAI-Schema vereinheitlicht. Zentrale Authentifizierung, Rate-Limiting, Spend-Tracking, Modell-Routing, automatische Fallbacks und Audit-Logging über einen einzigen Endpunkt, bei voller Datenhoheit.
• Langfuse (Observability): LLM-Traces, Evals, Prompt-Management und Metriken, self-hostbar via Docker oder Kubernetes. Langfuse wurde im Januar 2026 von ClickHouse übernommen; CEO Marc Klingen hat die Beibehaltung der MIT-Lizenz und der Self-Hosting-Option öffentlich bestätigt.
• OpenWebUI (Frontend): Eine ChatGPT-ähnliche Oberfläche mit Nutzerverwaltung und Rollen, persistenter Chat-Historie, Dokumenten-RAG und Tool-Support. Verbindet sich mit jedem OpenAI-kompatiblen Backend.

Welcher Inference-Server für welchen Zweck?

Server	Stärke	Einsatz
vLLM	PagedAttention, Continuous Batching, höchster Durchsatz	Produktion
SGLang	RadixAttention, starkes Prefix-Caching	Produktions-Alternative
Ollama	Einfachster Einstieg (ollama pull), automatische Quantisierung	Entwicklung, geringe Concurrency
llama.cpp	GGUF-Quantisierung, läuft auf CPU	Edge, ressourcenbeschränkte Umgebungen
TensorRT-LLM	Maximaler Durchsatz auf NVIDIA-Hardware	Nur bei hoher operativer Reife
TGI (Hugging Face)	Seit Dezember 2025 im Maintenance-Modus	Nicht mehr für Neuprojekte

Wichtig für Neuprojekte: Hugging Face hat TGI im Dezember 2025 in den Maintenance-Modus versetzt und empfiehlt ausdrücklich vLLM oder SGLang als Alternativen. Das GitHub-Repository wurde im März 2026 archiviert.

Der Unterschied zwischen Entwicklungs- und Produktions-Servern zeigt sich erst unter paralleler Last. Benchmarks mit Llama 3.1 8B auf einer RTX 4090 (Clore.ai): Bei einem einzelnen Nutzer liefert Ollama 65 Tokens/s, vLLM 140. Bei zehn parallelen Nutzern verarbeitet Ollama rund 150 Tokens/s gesamt, weil Anfragen weitgehend sequenziell abgearbeitet werden, während vLLM 800 Tokens/s erreicht. Eine vergleichende Studie vom November 2025 (arXiv 2511.17593) misst bei LLaMA-2-7B mit 100 gleichzeitigen Anfragen 15.243 Tokens/s für vLLM gegenüber 4.156 für TGI; unter extremer Last (rund 200 Nutzer) wächst der Vorsprung auf bis zu 24x. Die Faustregel: Ollama für den Laptop und das Prototyping, vLLM für den Server.

Warum lokal? Compliance ist das stärkste Argument

On-Premise bedeutet: keine Daten verlassen das eigene Netzwerk, "compliant by design". Cloud-APIs behalten Inputs typischerweise rund 30 Tage zur Missbrauchsüberwachung, und mehrere Anbieter trainieren standardmäßig auf Nutzereingaben, sofern kein Opt-out erfolgt.

CLOUD Act vs. DSGVO: ein struktureller Konflikt

Der US CLOUD Act von 2018 erlaubt US-Behörden den Zugriff auf Daten von US-Unternehmen unabhängig vom physischen Speicherort, auch in EU-Rechenzentren. Dass EU-Datenresidenz das Problem nicht löst, wurde 2025 öffentlich untermauert: Anton Carniaux, Director of Public and Legal Affairs bei Microsoft France, antwortete im Juni 2025 unter Eid vor dem französischen Senat auf die Frage, ob er garantieren könne, dass Daten französischer Bürger nie ohne Zustimmung an US-Behörden gelangten: "Non, je ne peux pas le garantir" ("Nein, das kann ich nicht garantieren").

Das EU-US Data Privacy Framework ist aktuell gültig, liegt aber in der Berufung beim EuGH. Zwei Vorgänger-Frameworks (Safe Harbor, Privacy Shield) sind bereits gefallen. Wer langfristig plant, setzt auf Souveränität statt auf die Haltbarkeit des jeweils aktuellen Abkommens.

Der Regulierungsdruck kompoundiert

• DSGVO: Laut DLA Piper GDPR Fines and Data Breach Survey (Januar 2026) summieren sich die kumulierten Bußgelder seit 2018 auf 7,1 Milliarden Euro. Das bislang höchste Einzelbußgeld, 1,2 Milliarden Euro gegen Meta Platforms Ireland, wurde wegen unrechtmäßiger EU-US-Datentransfers verhängt.
• EU AI Act: In Kraft seit August 2024, GPAI-Regeln seit August 2025, das Hochrisiko-Regime greift ab dem 2. August 2026. Bußgelder bis 35 Millionen Euro oder 7 % des globalen Jahresumsatzes. Hochrisiko-Systeme müssen Audit-Logs, Risikobewertung und menschliche Aufsicht nachweisen; On-Premise gibt darüber direkte Kontrolle.
• DORA (seit Januar 2025, Finanzsektor): verlangt volle Sichtbarkeit und Audit-Rechte über die gesamte IT-Lieferkette.
• NIS2: erweiterte Cybersicherheitspflichten für Energie, Gesundheit, Fertigung, Pharma und Logistik, mit Haftung auf Management-Ebene.
• EU Data Act (seit September 2025): regelt industrielle Daten und untersagt Vendor-Lock-in.

Für Unternehmen in regulierten Branchen löst lokale Infrastruktur diese Anforderungen strukturell, statt sie vertraglich einzuhegen: Es gibt schlicht keinen Drittanbieter-Auftragsverarbeiter, den man auditieren müsste.

Die Kostenfrage: streng volumenabhängig

Der Kostenvorteil von Self-Hosting ist real, aber er ist kein Automatismus. Cloud-Kosten wachsen linear mit dem Volumen; On-Prem-Kosten sind im Kern fixe Hardware-Kosten plus flache Betriebskosten.

Die wichtigsten Schwellenwerte aus aktuellen TCO-Analysen:

• Gegenüber Premium-APIs (GPT-4o-Klasse, Claude Sonnet) tritt der Break-even typischerweise bei 5-10 Millionen Tokens pro Monat ein.
• Gegenüber Budget-APIs (DeepSeek, GPT-4o-mini) erst bei 50-100 Millionen Tokens pro Monat.
• Eine Studie über 54 Deployment-Szenarien (arXiv 2509.18101) findet: Break-even kleiner Modelle oft innerhalb von 3 Monaten, mittlerer Modelle in 6-24 Monaten, großer Modelle jenseits von 2 Jahren.
• Das 36-Monats-TCO-Modell von SitePoint (Heavy-Tier) errechnet effektiv rund 7,15 USD pro Million Tokens self-hosted gegenüber 6,90 USD (OpenAI) und 9,86 USD (Anthropic). Mit vollständiger Hardware-Abschreibung kippt die Rechnung in den Jahren 2-3 zugunsten On-Prem.

Ehrlich rechnen heißt auch: die versteckten Posten einpreisen. Strom und Kühlung (in Rechenzentren 40-54 % der Gesamtleistung), Personal für ML-Infrastruktur und die Hardware-Abschreibung gehören in jede TCO-Betrachtung. Kostenmodelle variieren stark je nach Input/Output-Verhältnis, Auslastung und Strompreis. Konkrete Zahlen sollten immer mit dem eigenen Workload gegengerechnet werden.

Latenz und Unabhängigkeit als Bonus

Lokale Inferenz vermeidet Netzwerk-Round-Trips: Time-to-First-Token unter 100 ms ist möglich, während Cloud-Aufrufe mindestens rund 300 ms Netzwerk-Overhead mitbringen. Für Agenten, die mehrere Tool-Calls pro Aufgabe ausführen, summiert sich das schnell. Dazu kommen freie Modellwahl, Fine-Tuning per LoRA/QLoRA auf die eigene Domäne und Schutz vor unangekündigten Preis- oder API-Änderungen.

Welches Modell läuft auf 24 GB VRAM?

Zuerst ein Hardware-Hinweis, der in Projektgesprächen regelmäßig für Verwirrung sorgt: Die RTX Pro 4500 Blackwell führt NVIDIA offiziell mit 32 GB GDDR7 (896 GB/s, Blackwell-Architektur mit nativem FP8/FP4-Support). Die 24-GB-Karte der Reihe ist die RTX Pro 4000 Blackwell (24 GB GDDR7, 70-140 W). Wir dimensionieren hier konservativ für 24 GB; mit 32 GB entsteht zusätzlicher Spielraum für KV-Cache und längere Kontexte.

Die VRAM-Faustregel: (Parameter x Bits pro Gewicht) / 8 = GB für die Gewichte, plus KV-Cache, der linear mit Kontextlänge und Batch-Größe wächst. FP16 braucht etwa 2 Byte pro Parameter, FP8 1 Byte, INT4/AWQ 0,5 Byte. Praktische Best-Practice für vLLM: AWQ-INT4 oder FP8; FP8 wird auf Blackwell-GPUs nativ beschleunigt.

Modell	Params	Tool-Calling	Lizenz	VRAM (AWQ/Q4)	VRAM (FP8)	Kontext	BFCL (Version)
Qwen3-14B	14,8B	Nativ + MCP	Apache 2.0	~8,3 GB	~15 GB	32K, per YaRN 131K	~70 % (v3, zu verifizieren)
Qwen3-8B	8,2B	Nativ + MCP	Apache 2.0	~4,6 GB	~9,5 GB	32K, per YaRN 131K	65,9 % (v3)
Mistral NeMo 12B	12B	Nativ	Apache 2.0	~7 GB	~12 GB	128K (vLLM: 32K)	kein Gesamt-Score publiziert
Gemma 3 12B	12B	Prompt-basiert	Gemma (komm. mit Bedingungen)	~8 GB	~14 GB	128K	41,4 % (v4)
Ministral 8B	8B	Nativ	Mistral Research	~5 GB	~9 GB	128K	40,9 % (v4)
Phi-4 14B	14B	Prompt/strukturiert	MIT	~9 GB	~14 GB	16K	40,8 % (v3)

Ein Wort zu den BFCL-Werten (Berkeley Function Calling Leaderboard, der Standard-Benchmark für Tool-Calling): Werte verschiedener Versionen sind nicht direkt vergleichbar. BFCL v4 gewichtet Multi-Turn- und agentische Aufgaben deutlich stärker, wodurch Modelle mit exzellentem Single-Turn-Verhalten (Gemma 3 12B und Ministral 8B erreichen dort über 90 %) im Gesamtwert auf rund 40 % zurückfallen. Teils handelt es sich um Herstellerangaben; den Qwen3-14B-Wert sollte man vor einer Kaufentscheidung direkt auf gorilla.cs.berkeley.edu verifizieren.

Unsere Empfehlungen für Business-Einsatz (RAG, Agenten, Tool-Use)

1. Erste Wahl: Qwen3-14B (AWQ oder FP8). Das zuverlässigste native Function-Calling im Segment, MCP-kompatibel, Apache-2.0-Lizenz, umschaltbarer Thinking-Modus und starke Mehrsprachigkeit inklusive Deutsch. Mit AWQ (~8,3 GB Gewichte) bleibt auf 24 GB reichlich Platz für den KV-Cache; auf 32 GB läuft das Modell komfortabel in FP8.
2. Für maximal freie Lizenz plus Deutsch: Mistral NeMo 12B. Apache 2.0, natives Tool-Calling (vLLM-Parser mistral), explizit auf Deutsch trainiert und quantisierungsbewusst für FP8-Inferenz entwickelt. Einschränkung: vLLM begrenzt den Kontext derzeit auf 32K.
3. Für Vision und breiteste Sprachabdeckung: Gemma 3 12B. 140+ Sprachen, 128K Kontext, integrierter Vision-Encoder. Tool-Calling nur prompt-basiert, für strukturierte Agenten daher weniger zuverlässig, für RAG und multimodale Aufgaben aber stark.
4. Als Souveränitäts-Statement: Teuken-7B (OpenGPT-X/Fraunhofer). Apache 2.0, alle 24 EU-Amtssprachen, rund 50 % nicht-englische Trainingsdaten, kommerzialisiert von T-Systems und IONOS. Aber: nur 7B Parameter, 4K Kontext, kein starkes Tool-Calling. Interessant als DE-sensitiver RAG-Baustein, nicht als Agenten-Kernmodell.

Vor dem Produktionseinsatz gehört ein Lizenz-Check auf die Liste: Gemma- und GLM-Lizenzen erlauben kommerzielle Nutzung mit Bedingungen, Ministral 8B steht unter der Mistral Research License und benötigt für Produktion gegebenenfalls eine kommerzielle Lizenz. Uneingeschränkt permissiv sind Qwen3, Mistral NeMo, Phi-4 (MIT) und Teuken-7B.

Der pragmatische Fahrplan: in drei Phasen zur eigenen KI

Die Modellqualität ist 2026 kein Blocker mehr. Die Entscheidung dreht sich um Ökonomie, Kontrolle und operative Fähigkeit, und sie muss nicht binär ausfallen:

Phase	Schwelle	Empfehlung
1. Pilot	< 5 Mio. Tokens/Monat, unkritische Daten	Cloud oder Hybrid bleibt rational: schneller Einstieg, reale Nutzungsdaten sammeln
2. Umstieg	> 10 Mio. Tokens/Monat oder regulierte Daten (Finanz, Gesundheit, Recht, öffentlicher Sektor)	On-Prem klar überlegen: Single-GPU-Deployment, z. B. Qwen3-14B auf 24/32 GB
3. Skalierung	> 50 Mio. Tokens/Monat	Multi-GPU plus hybrides Routing: 70-80 % der Baseline lokal, Burst-Lasten in die Cloud

Ein Punkt gehört zur ehrlichen Beratung dazu: On-Prem verlagert operatives Risiko ins Haus. 24/7-Betrieb, GPU-Ausfälle, Monitoring und Sicherheits-Patching erfordern MLOps-Kompetenz. Genau hier entscheidet sich, ob ein lokales KI-Betriebssystem ein Souveränitätsgewinn oder eine Dauerbaustelle wird.

Fazit

Das lokale KI-Betriebssystem ist 2026 kein Experiment mehr, sondern ein beherrschbarer Stack aus reifen Open-Source-Komponenten: vLLM für die Inferenz, LiteLLM als Gateway, Langfuse für Observability, OpenWebUI als Frontend. Der CLOUD-Act-Konflikt und der EU-AI-Act-Fahrplan mit dem Hochrisiko-Regime ab August 2026 machen Datensouveränität zur Vorstandsfrage, und ab 5-10 Millionen Tokens pro Monat stimmt auch die Wirtschaftlichkeit gegenüber Premium-APIs.

Wenn Sie wissen wollen, wo Ihr Unternehmen auf dieser Kurve steht: NexPatch begleitet den gesamten Weg, von der Break-even-Analyse mit Ihren realen Nutzungsdaten über die Referenzarchitektur bis zum Managed Betrieb. Sprechen Sie uns an.