Lokale LLMs privat betreiben: On-Prem-KI ohne Datenabfluss

Jeder Prompt, den Ihr Team an eine gehostete KI-API sendet, ist eine Kopie Ihrer Daten, die Ihr Netzwerk verlässt. Für die meisten Unternehmen ist das ein kalkuliertes Risiko. Für eine Bank, ein Krankenhaus, eine Anwaltskanzlei oder jede Organisation, die personenbezogene Daten unter der DSGVO verarbeitet, ist es eine Haftung, die nur darauf wartet, in einem Audit aufzutauchen.

Large Language Models lokal zu betreiben beseitigt diese Haftung an der Quelle. Keine Prompts überschreiten Ihren Perimeter, keine Dokumente landen im Log eines Drittanbieters, und keine fremde Jurisdiktion kann Zugriff auf Daten erzwingen, die sie nie erhalten hat. Dieser Leitfaden behandelt, wie On-Premise-KI funktioniert, das offene Ökosystem, aus dem Sie sie aufbauen, und die Trade-offs. Der rote Faden durchgehend: Wählen Sie für jede Ebene das richtige Werkzeug, setzen Sie auf offene Standards und behalten Sie die Kontrolle über Ihre Modelle, Ihre Schlüssel und Ihre Daten.

Warum “lokal” für sensible Daten besser ist als “EU-Region”

Die EU-Region eines Anbieters zu wählen löst das Compliance-Problem nicht vollständig. Datenresidenz sagt Ihnen, wo Bytes liegen. Datensouveränität sagt Ihnen, wessen Gesetze den Zugriff auf sie regeln. Ein in den USA ansässiger Anbieter kann nach dem US CLOUD Act gezwungen werden, Daten herauszugeben, unabhängig davon, in welchem Rechenzentrum sie liegen.

Das Modell auf Infrastruktur zu betreiben, die Sie kontrollieren, lässt diese Unterscheidung in sich zusammenfallen. Wenn die GPU in Ihrem Rack steht oder auf einem dedizierten Server läuft, den Sie betreiben, und die Schlüssel Ihnen gehören, gibt es keinen Dritten, dem eine Vorladung zugestellt werden könnte, und keinen Datenabfluss, den man inspizieren müsste.

Die praktischen Vorteile:

• Kein Datenabfluss. Prompts und Dokumente verlassen niemals Ihr Netzwerk.
• Kein Training-Leak. Ihre Daten werden niemals genutzt, um das Modell eines anderen zu verbessern.
• Vorhersehbare Kosten. Keine Abrechnung pro Token, die mit der Nutzung skaliert.
• DSGVO- und EU-AI-Act-Konformität by design, nicht per Vertragsklausel.

Das offene Ökosystem, das das möglich macht

Sie müssen kein Modell trainieren. Das Open-Weight-Ökosystem ist ausgereift genug, dass der schwierige Teil der Betrieb ist, nicht die KI selbst. Der tiefere Vorteil: Fast jede Ebene spricht inzwischen einen offenen Standard, sodass Sie einen Stack zusammenstellen, statt einen zu kaufen.

Modelle, die Sie tatsächlich betreiben können

Leistungsfähige Open-Weight-Modelle decken die meisten Enterprise-Anwendungsfälle ab, mit Familien wie Llama, Mistral und Mixtral, Qwen, Gemma, Phi und DeepSeek, die allgemeines Reasoning, mehrsprachige Arbeit und Code abdecken. Gewichte werden als Safetensors über Hugging Face Transformers ausgeliefert, das GGUF-Format (aus llama.cpp) ist das De-facto-Packaging für quantisierte Modelle, und ONNX bietet einen portablen Weg zwischen Runtimes.

Faustregel zur Dimensionierung: Ein quantisiertes 7B-8B-Modell läuft auf einer einzelnen 24-GB-GPU; ein Modell der 70B-Klasse benötigt Multi-GPU (typischerweise 2x bis 4x A100/H100 oder äquivalent). Quantisierung (GGUF, AWQ, GPTQ) tauscht ein wenig Genauigkeit gegen einen großen Rückgang beim VRAM-Verbrauch, und für die meisten internen Aufgaben ist der Qualitätsunterschied kaum wahrnehmbar.

Serving-Runtimes: das Ökosystem, in dem wir arbeiten

Es gibt keine einzelne “richtige” Inferenz-Engine. Wir arbeiten im gesamten offenen Serving-Ökosystem und stimmen die Runtime auf Ihre Nebenläufigkeit, Hardware und Ihr Betriebsprofil ab:

• vLLM - ein Produktions-Arbeitstier; PagedAttention und Continuous Batching bringen hohen Durchsatz und niedrige Latenz unter gleichzeitiger Last.
• SGLang - hochperformantes Serving, stark bei strukturierter Ausgabe und agentischen Multi-Call-Pipelines.
• Hugging Face Text Generation Inference (TGI) - ein solider Produktionsserver, besonders in Hugging-Face-zentrierten Umgebungen.
• Ollama - der schnellste Weg, ein Modell auf einer Workstation oder einem einzelnen Server zum Laufen zu bringen. Ideal für Prototyping und kleine Teams.
• llama.cpp - die Engine hinter vielen leichtgewichtigen Tools und die erste Wahl für CPU-only oder eingeschränkte Hardware.
• LocalAI - ein OpenAI-kompatibles Gateway als Drop-in, das mehrere Backends vorschaltet.

Der verbindende rote Faden ist die OpenAI-kompatible API, die vLLM, SGLang, TGI, Ollama und LocalAI allesamt bereitstellen. Da diese Schnittstelle der De-facto-Standard für selbst gehostete Inferenz ist, ändert sich Ihr Anwendungscode kaum, wenn Sie die Engine darunter austauschen. Ein gängiges Muster: mit Ollama prototypisieren, dann hinter vLLM oder SGLang ziehen, sobald Sie echte Nebenläufigkeit brauchen.

Retrieval, Agenten und der Rest der Pipeline

Der größte geschäftliche Mehrwert entsteht dadurch, das Modell über Retrieval-Augmented Generation (RAG) in Ihren eigenen Daten zu verankern. Ein lokaler RAG-Stack koppelt ein selbst gehostetes Embedding-Modell mit einem Vector Store und darüber eine Orchestrierungsebene, die Retrieval, Prompting und Tool-Calls zusammenführt. Das Ökosystem ist hier breit, und wir passen uns an Ihren Stack an:

• Vektordatenbanken - pgvector (Postgres-nativ), Qdrant, Weaviate, Milvus und Chroma. Wenn Sie bereits Postgres betreiben, erspart pgvector oft eine neue bewegliche Komponente.
• Orchestrierungs-Frameworks - LangChain und LlamaIndex für die Verdrahtung von Retrieval, Agenten und Tool-Nutzung.
• Tool- und Datenanbindung - das Model Context Protocol (MCP), das jetzt unter der Agentic AI Foundation der Linux Foundation verwaltet wird, etabliert sich als offener Standard, um Modelle ohne maßgeschneiderten Klebecode mit internen Tools und Daten zu verbinden.

Alles läuft innerhalb Ihres Perimeters, sodass auch die Wissensbasis und der Tool-Zugriff des Agenten ihn niemals verlassen.

Eine Referenzarchitektur

Ein funktionierendes On-Premise-Setup sieht so aus:

1. GPU-Server, die Ihre gewählte Inferenz-Engine betreiben und eine interne OpenAI-kompatible API bereitstellen.
2. Vektordatenbank, die Embeddings Ihrer internen Dokumente vorhält.
3. Eine Datenschutz- / PII-Ebene, die personenbezogene Daten erkennt und schwärzt, bevor sie das Modell erreichen. Offene Tools wie Microsoft Presidio übernehmen Erkennung und Anonymisierung, optional mit reversibler Tokenisierung, damit Antworten personalisiert bleiben.
4. Eine Anwendungsebene - ein Chat-Copilot, ein interner Such-Assistent oder Agenten, die interne Tools über MCP aufrufen.
5. Observability - Prompt-Logging (innerhalb Ihres Netzwerks), Latenz- und Token-Metriken sowie Zugriffskontrollen, zunehmend über OpenTelemetry nachverfolgt, damit LLM-Telemetrie portabel bleibt.

Für strengere Umgebungen kann der gesamte Stack air-gapped laufen, wobei die Modellgewichte einmalig eingespielt werden und danach keine ausgehende Konnektivität mehr besteht.

Kosten: wann sich On-Prem tatsächlich rechnet

On-Prem ist nicht automatisch günstiger; der ehrliche Break-even hängt vom Volumen ab. Bei geringer oder sporadischer Nutzung gewinnen Cloud-APIs - Sie zahlen nur für das, was Sie nutzen, ohne Kapitaleinsatz. Bei dauerhaft hoher Nutzung gewinnt On-Prem typischerweise über einen Horizont von zwei bis drei Jahren: Ein einzelner GPU-Server, amortisiert über Tausende täglicher Anfragen, unterbietet die Preisgestaltung pro Token, und Sie entkommen den Egress-Gebühren vollständig. Der Fehler besteht darin, Hardware zu kaufen, bevor Sie Ihr reales Token-Volumen kennen. Dimensionieren Sie die Architektur nach gemessener Nutzung, nicht nach dem Datenblatt eines Anbieters.

Häufige Fallstricke

• VRAM unterdimensionieren und dann überrascht sein, dass das 70B-Modell nicht lädt. Stimmen Sie die Modellgröße auf die Hardware ab, bevor Sie sich festlegen.
• Nebenläufigkeit ignorieren. Ein für einen Entwickler abgestimmtes Single-GPU-Setup bricht bei fünfzig zusammen. Planen Sie die Serving-Ebene für Spitzenlast und wählen Sie eine Engine, die für Batching gebaut ist.
• Die PII-Ebene überspringen. On-Prem-Hosting blockiert externen Datenabfluss, doch Schwärzung und Zugriffskontrolle für intern minimal vergebene Rechte wollen Sie trotzdem.
• RAG als gelöst betrachten. Retrieval-Qualität, Chunking und die Wahl des Embeddings treiben die Antwortqualität weit stärker als die Modellgröße.
• Sich zu früh auf ein Tool festlegen. Weil die OpenAI-kompatible API, GGUF und ONNX offene Standards sind, können Sie sich Optionen über Engines und Vector Stores hinweg offenhalten, statt die Plattform auf einen einzigen Anbieter zu verwetten.

FAQ

Ist ChatGPT für den geschäftlichen Einsatz DSGVO-konform?

Die Consumer-Version von ChatGPT ist im Allgemeinen nicht DSGVO-konform, weil Konversationen ohne Auftragsverarbeitungsvertrag oder EU-Datenresidenz-Garantie gespeichert und für das Training verwendet werden können. Ein selbst gehostetes oder privates LLM vermeidet das vollständig, indem es jeden Prompt und jedes Dokument innerhalb Ihrer eigenen Infrastruktur hält, sodass keine personenbezogenen Daten die EU-Jurisdiktion verlassen.

Was ist private KI?

Private KI bedeutet, Sprachmodelle und KI-Agenten auf Infrastruktur zu betreiben, die Sie kontrollieren - on-premise oder in einer dedizierten EU-Umgebung - statt Daten an externe Cloud-APIs zu senden. Ihre Daten werden niemals genutzt, um Modelle Dritter zu trainieren, was Ihnen Datensouveränität und by design Konformität mit DSGVO und EU AI Act verschafft.

Welche Inferenz-Engine sollte ich verwenden, um ein lokales LLM bereitzustellen?

Das hängt von Ihrer Workload ab. vLLM und SGLang glänzen beim Produktions-Serving mit hoher Nebenläufigkeit, TGI passt zu Hugging-Face-zentrierten Teams, Ollama und llama.cpp eignen sich am besten für Prototyping oder eingeschränkte Hardware, und LocalAI bietet ein einheitliches Gateway. Sie alle stellen eine OpenAI-kompatible API bereit, sodass Sie einfach starten und später die Engine wechseln können, ohne Ihre Anwendung neu zu schreiben.

Welche Open-Source-Modelle lassen sich on-premise betreiben?

Leistungsfähige offene Modelle wie Llama, Mistral, Mixtral, Qwen, Gemma, Phi und DeepSeek laufen gut auf Ihren eigenen GPU-Servern. Kleinere quantisierte Modelle passen auf eine einzelne 24-GB-GPU; Modelle der 70B-Klasse benötigen ein Multi-GPU-Setup. Die richtige Wahl balanciert Genauigkeit, Latenz und Budget.

Wie verhindert man, dass sensible Daten und PII in ein LLM gelangen?

Fügen Sie eine Datenschutzebene hinzu, die PII - Namen, E-Mail-Adressen, Finanz- und Gesundheitsdaten - erkennt und schwärzt, bevor Prompts das Modell erreichen, mit offenem Tooling wie Microsoft Presidio und optional reversibler Tokenisierung, damit Antworten personalisiert bleiben. In Kombination mit On-Premise-Hosting und lokalem RAG verlassen niemals sensible Informationen Ihr Netzwerk.

Bauen Sie es mit einem Team, das souveräne KI ausliefert

Eine Single-Server-Demo aufzusetzen ist eine Sache von einem Nachmittag. Eine private LLM-Plattform zu betreiben, die eine ganze Organisation bedient, DSGVO-konform bleibt und einen Security-Review übersteht, ist Engineering-Arbeit.

Rapid Solutions konzipiert und betreibt private KI für regulierte europäische Unternehmen: selbst gehostete LLMs, RAG-Copilots, KI-Agenten und PII-Schutz, alles auf Infrastruktur und Schlüsseln, die Sie kontrollieren. Wir sind Open-Source-first und tool-agnostisch - wir kombinieren die passende Inferenz-Engine, den passenden Vector Store und das passende Orchestrierungs-Framework für Ihre Workload, statt Sie in einen einzigen Stack einzusperren. Wir entwickeln aus Amsterdam und Dubai und bieten EU-Datenresidenz als Standardleistung.

Ihre Daten, Ihre Schlüssel, Ihre Kontrolle. Kontaktieren Sie Rapid Solutions, um ein privates KI-Deployment für Ihr Team zu skizzieren.