BlogInfrastruktur

Was ein Unternehmen für ein On-Premise-LLM braucht, von der Hardware bis zu geprüften Antworten

Ein On-Premise-LLM hält Unternehmensdaten nur dann im Haus, wenn jede Schicht auf Infrastruktur läuft, die Sie selbst kontrollieren. Dazu gehören GPU-Server, eine Serving-Engine wie vLLM mit lokal gespeicherten Modellgewichten, ein LLM-Gateway für Schlüssel und Logs, eine Suche, die Dokumentberechtigungen prüft, und ein Monitoring, das keine Prompts an externe Dienste schickt. Das Modell wählen Sie anhand von Tests mit Ihren eigenen deutschen Fällen aus. Die Hardware dimensionieren Sie mit Messungen auf gemieteten GPUs, bevor Sie kaufen, und Sie benennen die Personen, die nach dem Go-live Updates und Regressionstests verantworten. Reicht Ihnen eine Verarbeitung in der EU unter Vertrag, ist ein privates Deployment von Azure OpenAI oder Amazon Bedrock in der EU meist weniger Aufwand.

Von Mickey GrafAktualisiert am 7. November 2026

Wann On-Premise die richtige Wahl ist und wann ein privates Cloud-Konto reicht

On-Premise ist die richtige Wahl, wenn eine Vorgabe oder eine Risikobewertung sagt, dass kein externer Anbieter die Daten verarbeiten darf, oder wenn die Systeme, die der Assistent lesen muss, nur im eigenen Netz erreichbar sind. Lautet die Anforderung dagegen, dass die Daten in der EU von einem vertraglich gebundenen Auftragsverarbeiter verarbeitet und nicht zum Training genutzt werden, erfüllt ein Modell-Deployment im eigenen Cloud-Konto sie meist mit deutlich weniger Betriebsaufwand. Halten Sie die Anforderung in einem Satz fest, bevor Sie entscheiden. Nach unserer Erfahrung gehen die meisten späteren Streitfragen auf eine Anforderung zurück, die nie jemand aufgeschrieben hat.

Stand 7. November 2026 dokumentieren beide großen Clouds EU-Optionen. Laut Microsoft verarbeiten Data-Zone-Deployments in der EU Daten innerhalb der Azure EU Data Boundary. Bei direkt von Azure verkauften Modellen sind Prompts und Antworten Modellanbietern nicht zugänglich und werden ohne Ihre Erlaubnis nicht zum Training von Foundation-Modellen genutzt. Bei Amazon Bedrock halten Inference-Profile, die an eine Geografie wie die EU gebunden sind, regionsübergreifende Anfragen innerhalb dieser Geografie, und eine Aufbewahrungseinstellung legt fest, ob AWS Prompts und Ausgaben zur Missbrauchsabwehr speichern darf.

On-Premise oder privates Cloud-Konto: was den Ausschlag gibt

Anforderung	On-Premise	Privates Cloud-Konto in der EU
Keine Verarbeitung durch externe Anbieter	Erfüllt	Nicht erfüllt
Verarbeitung in der EU mit Auftragsverarbeitungsvertrag	Erfüllt	Erfüllt mit passendem Deployment-Typ und passender Region
Zugriff auf Systeme, die nur im internen Netz erreichbar sind	Direkt	Braucht eine private Netzanbindung
Modellauswahl	Modelle, deren Gewichte Sie herunterladen und betreiben dürfen	Der Katalog des Anbieters in dieser Region
Wenig Personal für GPUs und Modell-Updates	Schwierig: Sie betreiben jede Schicht	Der Anbieter betreibt das Modell, Sie den Rest

KI selbst betreiben oder Managed API: die ganze Entscheidung EU-Datenresidenz mit Azure OpenAI und Amazon Bedrock

Die Schichten eines funktionierenden Systems, von GPU-Servern bis zu Agenten

Ein funktionierendes System hat sechs Schichten, und Daten bleiben nur im Haus, wenn keine davon nach außen funkt: GPU-Server, eine Serving-Engine, ein LLM-Gateway, Datenzugriff und Suche, der Assistent oder Agent sowie Tests und Monitoring.

Die sechs Schichten eines On-Premise-LLM-Systems

Schicht	Aufgabe	Was Sie entscheiden
GPU-Server	Halten Modellgewichte und KV-Cache im GPU-Speicher	GPU-Typ und Speicher, Anzahl der Server, Reserve für einen Ausfall
Serving-Engine, etwa vLLM	Lädt das Modell und stellt es über eine API bereit	Modelle, Präzision, Kontextlänge, Replikate
LLM-Gateway, etwa LiteLLM	Ein Endpunkt für alle Anwendungen, mit Schlüsseln, Budgets, Logs und Routing	Wer welches Modell nutzen darf, was wie lange protokolliert wird
Datenzugriff und Suche	Bindet Dokumentquellen an, indexiert sie und filtert Treffer nach Berechtigung	Welche Quellen, wie Berechtigungen synchronisiert werden
Assistent oder Agent	Oberfläche, Prompts und Werkzeuge, die Geschäftssysteme lesen oder ändern	Welche Aktionen eine menschliche Freigabe brauchen
Tests und Monitoring	Abnahme- und Regressionstests, Metriken und Alarme	Geforderte Erfolgsquoten, wer alarmiert wird

Zwei Details machen den Stack später leichter änderbar. vLLM stellt OpenAI-kompatible APIs bereit, darunter Chat Completions und Embeddings, und LiteLLM kann über seinen Provider hosted_vllm an einen vLLM-Server routen. Anwendungen sprechen so mit dem Gateway und nicht mit einem bestimmten Modell. Die virtuellen Schlüssel von LiteLLM sowie Budgets und Rate Limits pro Schlüssel, Nutzer oder Team brauchen eine Postgres-Datenbank. Ohne sie werden Budgets nicht durchgesetzt (Dokumentation von vLLM und LiteLLM, Stand 7. November 2026).

„Keine Daten verlassen das Unternehmen“ ist eine Eigenschaft des Netzes, also testen Sie es auch so. Listen Sie jede ausgehende Verbindung des Stacks auf: Modell-Downloads, Container-Registries, Paketspiegel, Telemetrie und Fehlerberichte jeder Komponente sowie jeden gehosteten Monitoring-Dienst. Sperren Sie dann ausgehenden Verkehr von Serving- und Gateway-Hosts standardmäßig und erlauben Sie nur, was auf der Liste steht. Für uns ist das ein Prüfpunkt vor dem Go-live. Ein Satz im Architekturdokument reicht nicht. Die Suche braucht dieselbe Sorgfalt nach innen: Ein Assistent, der jede Datei lesen kann, beantwortet jedem jede Frage. Treffer müssen deshalb nach den Berechtigungen der fragenden Person gefiltert werden, bevor das Modell sie sieht.

Was ein LLM-Gateway leistet LiteLLM sicher in Produktion betreiben Dokumentberechtigungen in RAG

Welche Open-Weight-Modelle auf Deutsch gut genug sind und wie Sie das prüfen

Ein Modell ist auf Deutsch gut genug, wenn es Ihre Abnahmetests mit Ihren eigenen Dokumenten und Fragen besteht. Öffentliche Ranglisten sagen aus unserer Sicht wenig über deutsche Geschäftstexte aus, taugen also höchstens für eine Vorauswahl. Zwei Filter liefert die Model Card direkt. Der erste ist die Sprachunterstützung: Metas Card für Llama 3.3 70B Instruct nennt acht unterstützte Sprachen, darunter Deutsch, und Mistrals Card für Mistral Small 3.1 führt Deutsch unter ihren Sprachen. Der zweite ist die Lizenz: Llama 3.3 steht unter dem Llama 3.3 Community License Agreement, Mistral Small 3.1 unter Apache 2.0, mit unterschiedlichen Bedingungen. Lassen Sie die Lizenz prüfen, bevor Sie in Tests investieren. Die beiden Modelle nennen wir nur als Beispiele dafür, was Model Cards angeben. Prüfen Sie zu Projektbeginn die aktuellen Cards.

Testen Sie die Vorauswahl dann so, wie Sie später das System abnehmen:

Sammeln Sie echte Anfragen der künftigen Nutzer zusammen mit den Dokumenten, die sie bräuchten, auch lange und schlecht formatierte
Benennen Sie die relevanten Fehlertypen und ihren Schweregrad: falsche Zahl, erfundene Quelle, Antwort auf Englisch, falsche Anrede, kaputtes JSON in einem Tool-Aufruf
Testen Sie jeden Kandidaten in der Präzision, die Sie später im Betrieb verwenden, denn ein quantisiertes Modell kann sich anders verhalten als das volle
Lassen Sie deutschsprachige Fachleute die Antworten bewerten, ohne dass sie wissen, welches Modell sie geschrieben hat
Führen Sie jeden Fall mehrmals aus, denn derselbe Prompt kann unterschiedliche Antworten liefern
Bewahren Sie die Fälle auf: Dasselbe Set entscheidet über jeden späteren Modellwechsel

Nach unserer Erfahrung zeigen sich die Unterschiede zwischen Kandidaten eher in einigen bestimmten Fehlertypen, etwa bei Zahlen aus Tabellen oder Antworten zu langen Dokumenten, als in einem Durchschnittswert. Berichten Sie deshalb eine Erfolgsquote je Fehlertyp statt einer einzigen Zahl.

Modellqualität nach der Quantisierung prüfen Abnahmekriterien für KI-Systeme

Hardware dimensionieren, ohne das Falsche zu kaufen

Dimensionieren Sie die Hardware anhand von Messungen Ihrer eigenen Last auf dem gewählten Modell. Die Nutzerzahl allein sagt wenig: Dieselbe Zahl an Nutzern kann sehr unterschiedliche Hardware brauchen, je nachdem, wie lang ihre Anfragen sind und wie viele gleichzeitig eintreffen. Das sind die Treiber für Speicher und Kosten:

Modellgröße und Präzision. Die Gewichte belegen grob Parameterzahl mal Bytes pro Parameter. Mistrals Card etwa gibt für Mistral Small 3.1 mit 24 Milliarden Parametern rund 55 GB GPU-Speicher in bf16 oder fp16 an und nennt eine einzelne RTX 4090 als ausreichend, sobald das Modell quantisiert ist
Kontextlänge und Parallelität. Der KV-Cache wächst mit den Token jeder Anfrage und der Zahl gleichzeitig laufender Anfragen. Lange Dokumente und Agenten, die ihren Verlauf mitführen, belegen deshalb den Großteil des Speichers
Spitzenparallelität statt Gesamtnutzerzahl: Zählen Sie die gleichzeitig laufenden Anfragen in der stärksten Stunde
Redundanz: genug Kapazität, um mit einem ausgefallenen Server weiterzuarbeiten
Weitere Modelle: Auch Embedding- und Reranking-Modelle für die Suche brauchen Speicher
Strom, Kühlung, Rackplatz und die Menschen, die die Maschinen warten

Messen Sie, bevor Sie bestellen. Mieten Sie den GPU-Typ, den Sie in Betracht ziehen, betreiben Sie das gewählte Modell mit vLLM in der geplanten Präzision und Kontextlänge und spielen Sie realistische Anfragen ein. Stand 7. November 2026 bringt vLLM mit vllm bench serve einen Benchmark für den Durchsatz im Online-Betrieb mit, und der Endpunkt /metrics meldet vllm:num_requests_waiting, vllm:kv_cache_usage_perc und vllm:num_preemptions. Der Tuning-Leitfaden von vLLM erklärt, dass Anfragen bei knappem KV-Cache verdrängt und später neu berechnet werden, was die Latenz verschlechtert. Als Abhilfe nennt er mehr Speicher für den Cache oder weniger parallele Sequenzen pro Server. Ermitteln Sie die Last, die ein Server bei Ihrem Latenzziel trägt, teilen Sie Ihre Spitze dadurch und planen Sie einen Reserveserver ein.

GPU-Kapazität planen, mit Rechenbeispiel

Was der Betrieb nach dem Go-live verlangt

Nach dem Go-live betreiben Sie einen Dienst. Jemand muss also für Updates, Monitoring, Regressionstests und den Dokumentenindex verantwortlich sein und dafür Zeit haben. On-Premise heißt: All das liegt bei Ihnen, niemand sonst patcht die Serving-Engine oder beobachtet die GPUs.

Wiederkehrende Arbeit nach dem Go-live

Aufgabe	Was dazugehört	Wann
Updates	GPU-Treiber, Serving-Engine, Gateway, Suchkomponenten; feste Versionen, ein Durchlauf in Staging, ein Weg zurück	Neues Release oder Sicherheitshinweis
Modellwechsel	Abnahmeset vor dem Wechsel erneut ausführen, je Fehlertyp vergleichen	Neues Modell, neue Quantisierung oder geänderter Prompt
Monitoring	Warteschlange, KV-Cache-Auslastung, Latenz, Fehler, Nutzung je Team; Alarme an eine benannte Person	Laufend
Dokumentenindex	Läufe der Konnektoren, Abgleich der Berechtigungen, Entfernen gelöschter Dokumente	Bei jedem Abgleich, geprüft durch einen Test
Kapazität	Gemessene Spitzenlast mit der Tragfähigkeit eines Servers vergleichen	Regelmäßig und bevor ein neues Team dazukommt

Drei Betriebsmodelle funktionieren: ein internes Plattformteam, das bereits Kubernetes betreibt, der IT-Betrieb mit einer benannten verantwortlichen Person für den KI-Dienst oder ein externer Partner mit schriftlicher Betriebsvereinbarung. Nach unserer Erfahrung scheitern Systeme, für die niemand zuständig ist, sobald das Projektteam weitergezogen ist.

Regressionstests für LLM-Anwendungen Wer nach dem Piloten für ein KI-System verantwortlich ist

Datenschutz, Betriebsrat und KI-Verordnung (AI Act)

Wer das Modell selbst betreibt, braucht dafür keinen externen Auftragsverarbeiter. Datenschutzbeauftragte, Betriebsrat und KI-Verordnung fragen trotzdem, was das System mit personenbezogenen Daten macht. Die folgende Checkliste hilft bei diesen Gesprächen. Sie ist keine Rechtsberatung, prüfen Sie deshalb den aktuellen Wortlaut in den unten verlinkten amtlichen Quellen.

Datenschutz

Art. 35 DSGVO verlangt vor einer Verarbeitung, insbesondere beim Einsatz neuer Technologien, die voraussichtlich ein hohes Risiko für die Rechte und Freiheiten von Personen mit sich bringt, eine Datenschutz-Folgenabschätzung. Rechnen Sie mit diesen Fragen des Datenschutzbeauftragten: Welche personenbezogenen Daten landen in Prompts, indexierten Dokumenten und Logs? Wie lange werden Logs aufbewahrt, und wer darf sie lesen? Wie erreicht ein Löschantrag sowohl den Index als auch die Logs?

Betriebsrat

Nach § 87 Abs. 1 Nr. 6 BetrVG bestimmt der Betriebsrat bei der Einführung technischer Einrichtungen mit, die dazu bestimmt sind, Verhalten oder Leistung der Beschäftigten zu überwachen. Das Bundesarbeitsgericht hat in seinem Beschluss vom 16. Juli 2024 (1 ABR 16/23) bekräftigt, dass eine Einrichtung zur Überwachung bestimmt ist, wenn sie objektiv dazu geeignet ist; auf die Absicht des Arbeitgebers kommt es nicht an. Ein Gateway, das Prompts pro Nutzer protokolliert, ist nach unserem Verständnis in diesem Sinne geeignet. Planen Sie früh eine Betriebsvereinbarung und gestalten Sie die Logs passend dazu: pseudonymisierte Nutzerkennungen, kurze Aufbewahrung, benannte Personen mit Zugriff und eine schriftliche Regel, dass Logs nicht zur Leistungsbewertung dienen.

KI-Verordnung (AI Act)

Stand 7. November 2026 ist der AI Act, Verordnung (EU) 2024/1689, durch den Digital Omnibus zur KI geändert, die Verordnung (EU) 2026/1744 vom 8. Juli 2026. Laut der Zeitleiste des Rates gelten die Pflichten für eigenständige Hochrisiko-Systeme nun ab dem 2. Dezember 2027 und die für in Produkte eingebettete Hochrisiko-Systeme ab dem 2. August 2028. Der geänderte Art. 4 verlangt von Anbietern und Betreibern Maßnahmen zur Förderung der KI-Kompetenz, ohne dass sie ein bestimmtes Niveau für jede Person garantieren müssen. Ein interner Assistent für Dokumente ist nach unserem Verständnis meist kein Hochrisiko-System. Soll er aber Entscheidungen über Beschäftigte oder Bewerber vorbereiten, lassen Sie ihn vor dem Bau rechtlich gegen die Hochrisiko-Liste in Anhang III prüfen.

Vom ersten Anwendungsfall in die Produktion, Schritt für Schritt

Bringen Sie einen Anwendungsfall in fester Reihenfolge in die Produktion. Jeder Schritt liefert, was der nächste braucht: eine schriftliche Anforderung, ein Testset, ein gemessenes Modell, eine dimensionierte Plattform und ein geprüftes System.

1
Einen Anwendungsfall wählen und die Datenanforderung festhalten
Wählen Sie eine Aufgabe mit klaren Nutzern und Dokumenten und halten Sie in einem Satz fest, wo ihre Daten verarbeitet werden dürfen. Dieser Satz entscheidet zwischen On-Premise und privatem Cloud-Konto.
2
Zuerst das Testset bauen
Sammeln Sie echte Anfragen, das erwartete Verhalten und die Fehlertypen mit Schweregrad und geforderter Erfolgsquote, abgestimmt mit den Personen, die abnehmen.
3
Modelle vorauswählen und testen
Filtern Sie nach Lizenz und Deutschunterstützung und testen Sie die Kandidaten dann in der geplanten Präzision auf gemieteten GPUs gegen das Testset.
4
Kapazität messen und Hardware dimensionieren
Messen Sie das gewählte Modell mit realistischem Verkehr bei Ihrem Latenzziel und dimensionieren Sie für die Spitzenlast plus einen Reserveserver.
5
Plattform mit gesperrtem ausgehendem Verkehr aufbauen
Richten Sie Serving-Engine, Gateway, Suche mit Berechtigungsfiltern und Monitoring ein, sperren Sie dann ausgehenden Verkehr und erlauben Sie nur, was Sie aufgelistet haben.
6
Datenschutz und Betriebsrat klären
Schließen Sie die Folgenabschätzung ab, stimmen Sie Log-Design und Betriebsvereinbarung ab und planen Sie Maßnahmen zur KI-Kompetenz, bevor echte Nutzer kommen.
7
Abnahmetests ausführen, dann begrenzt ausrollen
Geben Sie erst frei, wenn jedes Kriterium erfüllt ist. Beginnen Sie mit einer Nutzergruppe und beobachten Sie Metriken und gemeldete Fehler.
8
Betrieb übergeben
Benennen Sie die verantwortliche Person, schreiben Sie Runbooks und legen Sie die Routine für Updates, Regressionstests und Kapazitätsprüfungen fest.

Wir bauen und betreiben solche Systeme auf den eigenen Servern unserer Kunden oder in deren eigenem Cloud-Konto, von der GPU-Serving-Schicht bis zu den Abnahmetests vor dem Go-live.

On-Premise-KI vLLM auf Kubernetes LLM- und Agenten-Plattform

Fragen

Können wir mit Ollama auf einem Server anfangen?

Zum Ausprobieren von Modellen auf einer Maschine: ja. Bevor viele Menschen davon abhängen, testen Sie es wie jede Serving-Engine: parallele Last mit Ihren eigenen Anfragen, Latenz in der Spitze, Metriken und wie Neustarts und Updates ablaufen. Für den gemeinsamen Produktivbetrieb setzen wir meist vLLM ein, weil es OpenAI-kompatible APIs bereitstellt und seine Metriken unter /metrics ausgibt (Stand 7. November 2026).

Ist ein LLM On-Premise automatisch DSGVO-konform?

Nein. Wenn das Modell im Haus bleibt, entfällt ein externer Auftragsverarbeiter für das Modell. Sie brauchen trotzdem eine Rechtsgrundlage, bei hohem Risiko eine Folgenabschätzung, Grenzen dafür, was wie lange protokolliert wird, und einen Weg, Daten aus Index und Logs zu löschen. Eine Suche ohne Berechtigungsfilter kann Kollegen zudem Dokumente zeigen, die sie nicht sehen dürfen, und das ist ein Datenschutzproblem innerhalb des Unternehmens.

Ist ein Open-Weight-Modell so gut wie die gehosteten Modelle der großen Anbieter?

Das hängt von der Aufgabe ab, und nur Ihr Testset kann es beantworten. Nach unserer Erfahrung liegen Extraktion, Klassifikation und Antworten auf Basis gefundener Dokumente oft in Reichweite selbst betriebener Modelle, während sich Lücken eher bei langen, mehrstufigen Aufgaben zeigen. Wenn Ihre Datenregeln es erlauben, lassen Sie ein gehostetes Modell als Vergleichspunkt über dieselben Fälle laufen.

Wie viele GPUs brauchen wir für 50 Nutzer?

Das hängt davon ab, wie viele der 50 gleichzeitig Anfragen senden, wie lang Prompts und Dokumente sind, von Modellgröße und Präzision und davon, ob Sie einen Reserveserver brauchen. Messen Sie einen Server mit Ihren eigenen Anfragen bei Ihrem Latenzziel und dimensionieren Sie dann für die Spitzenlast plus einen Reserveserver. Schätzungen für dieselbe Nutzerzahl gehen weit auseinander, deshalb messen wir zuerst.

Muss der Betriebsrat zustimmen?

Wenn das System erfassen kann, wer was gefragt hat, fällt es wahrscheinlich unter § 87 Abs. 1 Nr. 6 BetrVG, denn das Bundesarbeitsgericht stellt darauf ab, ob ein System objektiv zur Überwachung geeignet ist. Auf die Absicht des Arbeitgebers kommt es nicht an. Beziehen Sie den Betriebsrat früh ein und stimmen Sie das Log-Design mit ihm ab. Klären Sie die Einzelheiten mit Ihrer Arbeitsrechtsberatung.

Können wir in einer privaten Cloud anfangen und später On-Premise gehen?

Ja, wenn Anwendungen ein Gateway mit OpenAI-kompatibler API aufrufen statt des SDKs eines Anbieters und wenn Sie das Testset behalten. Der Umzug heißt dann: ein mit vLLM betriebenes Modell hinter das Gateway stellen, die Abnahmetests erneut ausführen und das Routing umstellen. Prompts müssen für das neue Modell oft angepasst werden, planen Sie also nach dem ersten Testlauf eine Korrekturrunde ein.

Mehr aus dem Blog

Selbst betreiben oder Managed API

Wie Sie entscheiden, ob eine KI-Anwendung auf eigener Infrastruktur laufen oder auf einem gemanagten Modell-Endpunkt bleiben sollte, anhand von Zugriffsanforderungen, Betriebskapazität und gemessenen Kosten.

GPU-Kapazität für Inferenz planen

Wie Sie die GPU-Kapazität für ein selbst betriebenes Modell bemessen: was eine Replika begrenzt, wie Sie sie bei Ihrem Latenzziel benchmarken, wie viele Repliken die Spitzenlast braucht und wie Sie ungenutzte Stunden vermeiden.

Berechtigungen in RAG

Wie Zugriffsregeln aus Quellsystemen in einen Retrieval-Index gelangen, wo sie verloren gehen und welche Negativtests zeigen, dass niemand abruft, was er nicht öffnen darf.

Abnahmekriterien für KI-Systeme

Wie Sie Abnahmekriterien für eine LLM-Anwendung schreiben, pro Fehlertyp einen Schwellenwert setzen und entscheiden, ob eine gemessene Quote ihn erfüllt, mit Rechner.

Quellen

Mit einem Engineer sprechen

Bringen Sie eine Aufgabe mit, die Sie verbessern möchten. Das Gespräch dauert 30 Minuten und braucht keinen Zugriff auf Ihre Systeme oder Ihre Daten.

30-minütiges Gespräch buchen

Die Buchung läuft über Google Kalender.

Lieber zuerst schreiben? Hinterlassen Sie Ihre E-Mail-Adresse und ein paar Zeilen, dann antworten wir mit Terminvorschlägen.