Eine private ChatGPT-Alternative für Ihr Unternehmen: Komponenten, Dimensionierung und Zugriffskontrolle

Woraus eine private ChatGPT-Alternative besteht

Eine private Alternative zu ChatGPT betreibt einen Assistenten wie ChatGPT vollständig auf Servern unter Ihrer Kontrolle, on-premise oder auf dedizierter Hardware in einem EU-Rechenzentrum. Dazu gehören ein Modellserver mit OpenAI-kompatibler API wie vLLM, ein Chat-Frontend mit Konten wie Open WebUI oder LibreChat, die Anmeldung über Ihren Identity Provider, eine Dokumentenschicht, die die Zugriffsrechte jedes Nutzers anwendet, ein Protokoll der Prompts und Antworten, Guardrails, ein Modell, dessen Lizenz zu Ihrer Nutzung passt, und GPU-Server, die für die Spitze der Anfragen in Bearbeitung ausgelegt sind.

Dokumentation von vLLM, Open WebUI, LibreChat und NeMo Guardrails, abgerufen am 6. Oktober 2026.

Modellserver: vLLM mit OpenAI-kompatibler API

vLLM steht unter der Apache-2.0-Lizenz und wird in seiner Dokumentation als „ein HTTP-Server, der OpenAIs Completions API, Chat API und mehr implementiert“ beschrieben; gestartet wird es mit vllm serve und dem Modellnamen. Seine Option --api-key prüft statische Schlüssel, von denen das Frontend einen vorlegt, auf Routen wie /v1. vLLM hat keine Nutzerkonten, und seine Dokumentation vermerkt, dass der Parameter user der Chat API ignoriert wird; wer was gefragt hat, weiß also nur das Frontend oder ein Gateway vor vLLM. Setzen Sie --max-model-len auf den Kontext, den die Gespräche brauchen, und nicht auf das Maximum des Modells, denn der Wert legt fest, wie viele Gespräche voller Länge gleichzeitig Platz haben. Außerdem sammelt vLLM „standardmäßig anonyme Nutzungsdaten“ zu Hardware und Modellkonfiguration, bis VLLM_NO_USAGE_STATS=1 gesetzt ist. Unser Vergleich der Serving-Engines für LLMs behandelt SGLang, TensorRT-LLM und Ollama.

Chat-Frontend für private LLMs: Open WebUI oder LibreChat und ihre Lizenzen

Beide Frontends verbinden sich mit jedem OpenAI-kompatiblen Endpunkt, Open WebUI unter Settings, Admin, Connections mit der /v1-URL von vLLM und LibreChat über einen Custom Endpoint mit einer baseURL in librechat.yaml. Open WebUI durchsucht Wissensdatenbanken, optional mit BM25 und Reranking; LibreChat nutzt seine RAG API auf PostgreSQL mit pgvector.

LibreChat steht unter der MIT-Lizenz, sein separates Admin-Panel unter der AGPL-3.0. Open WebUI hat seit v0.6.6 vom 19. April 2025 eine eigene Lizenz: BSD-3-Bedingungen plus eine Klausel, die verbietet, das Open-WebUI-Branding zu verändern, zu entfernen, zu verdecken oder zu ersetzen, es sei denn, eine Installation hat nicht mehr als 50 Endnutzer „innerhalb eines beliebigen rollierenden Zeitraums von dreißig (30) Tagen“, der Rechteinhaber hat schriftlich zugestimmt oder eine Enterprise-Lizenz erlaubt es. Die Lizenzseite nennt „Keine Begrenzung je Nutzer für interne, Mitarbeiter- oder unternehmensweite Nutzung, solange das Open-WebUI-Branding stets vorhanden und deutlich sichtbar ist“ und hält fest, dass die Lizenz „keine von der OSI anerkannte ‚Open Source‘-Lizenz ist“, was dort zählt, wo eine Unternehmensrichtlinie nur von der OSI anerkannte Lizenzen zulässt.

Single Sign-on mit OIDC oder SAML, Rollen und Gruppen

Sowohl Open WebUI als auch LibreChat melden Nutzer über OpenID Connect an. Open WebUI dokumentiert außerdem LDAP und einen Trusted-Header-Modus für einen authentifizierenden Reverse Proxy und warnt, dass eine falsche Konfiguration „Nutzern erlauben kann, sich als beliebiger Nutzer zu authentifizieren“. Natives SAML haben wir in seiner Dokumentation nicht gefunden; ein Identity Provider, der nur SAML spricht, lässt sich über einen Broker wie Keycloak erreichen, der über externe „OpenID-Connect- oder SAML-Identity-Provider“ authentifiziert. LibreChat unterstützt SAML direkt, aber ohne Single Logout und nicht zusammen mit OpenID Connect.

Rollen und Gruppen kommen aus dem Token. Bei eingeschalteter Rollenverwaltung nennt OAUTH_ADMIN_ROLES in Open WebUI die Rollen, die sich als Administratoren anmelden, und OAUTH_ALLOWED_ROLES die Rollen, die überhaupt Zugang erhalten. ENABLE_OAUTH_GROUP_MANAGEMENT hält die Mitgliedschaften bei jeder Anmeldung „strikt synchronisiert“ mit den Claims des Tokens, was Nutzer aus Gruppen entfernt, denen sie von Hand zugeordnet wurden. Berechtigungen sind additiv, und Gruppen können nicht entziehen, was die Standardberechtigungen gewähren; deshalb empfiehlt die Dokumentation minimale Standardberechtigungen. LibreChat beschränkt die Anmeldung mit OPENID_REQUIRED_ROLE auf die dort aufgeführten Rollen und verwaltet Funktionsberechtigungen für Rollen, Gruppen und Nutzer in seinem separaten Admin-Panel, das seine Dokumentation als „jetzt zum Testen verfügbar“ beschreibt.

Neue Konten in Open WebUI erhalten zunächst die Rolle pending, und wer ENABLE_LOGIN_FORM auf false setzt, entfernt das lokale Passwortformular. Session-Token haben standardmäßig eine Laufzeit von 4w und bleiben ohne Redis nach der Abmeldung gültig; der Härtungsleitfaden ergänzt, dass das Deaktivieren eines Kontos „das bereits dafür ausgestellte Token nicht widerruft“, obwohl die Rolle bei jeder Anfrage erneut geprüft wird. Mit eingeschaltetem SCIM 2.0 deaktiviert der Identity Provider Nutzer direkt, was ihre Rolle auf pending setzt.

Dokument-Upload, RAG und Berechtigungen je Dokument

Dokumente kommen als Uploads im Chat an oder als gemeinsame Sammlungen, die der Assistent durchsucht. In Open WebUI wird eine Wissensdatenbank über eine Zugriffsliste für Gruppen oder Nutzer freigegeben, und das Begleitwerkzeug oikb spiegelt Quellen wie Git-Repositories, Confluence-Bereiche und S3-Buckets hinein. Die Zugriffsliste gilt für die ganze Wissensdatenbank; in der Dokumentation haben wir nichts gefunden, was die Berechtigungen eines Quellsystems je Dokument in den Index überträgt.

Das genügt, wo eine Sammlung einen einzigen Leserkreis hat. Wo eine Ablage Dokumente mit unterschiedlichen Lesern mischt, müssen die Berechtigungen beim Abruf durchgesetzt werden, durch eine Suche, die vor der Bewertung auf die Identität und die Mitgliedschaften des Nutzers filtert, wie unser Artikel zu RAG auf Unternehmensdaten erklärt. Das Frontend muss die Identität des Nutzers dann an diesen Retrieval-Dienst weitergeben; in Open WebUI erhält eine Filterfunktion den vollständigen Nutzerdatensatz.

Assistenten, die wir im Rahmen unserer Leistung Private AI/ML bauen, nennen die Quelle und beachten die Zugriffsrechte jedes Nutzers, mit Daten- und Berechtigungsverwaltung und einem Query-Log. Schreiben Sie uns im Formular unten, welchen Identity Provider Sie nutzen und in welchen Systemen die Dokumente liegen.

Protokollierung von Prompts und Antworten und ihre Aufbewahrungsdauer

Open WebUI legt gespeicherte Gespräche in seiner Datenbank ab, wo Nutzer sie löschen können, wenn ihnen die Berechtigung Allow Chat Delete erteilt ist; temporäre Chats verringern, was gespeichert wird, und Administratoren können die Chats anderer Nutzer lesen, solange ENABLE_ADMIN_CHAT_ACCESS auf dem Standardwert true steht. Das separate Audit-Log ist standardmäßig ausgeschaltet; auf der Stufe METADATA erfasst es Nutzer, IP-Adresse, User-Agent, Methode, URL und Zeitpunkt, und REQUEST_RESPONSE fügt beide Bodies hinzu, gekürzt auf 2.048 Byte. Seine Standardausschlüsse, /chats, /chat und /folders, nehmen die Chat-Routen davon aus. LibreChat löscht temporäre Chats standardmäßig nach 720 Stunden.

Ein vollständiges Query-Log ist eine Designentscheidung. Auch wenn die Chat-Pfade auditiert werden, erfasst das Log jede Chat-Anfrage, die das bisherige Gespräch enthält, aber nicht die Antwort: Im Browser enthält die HTTP-Response nur Task-IDs, während die Antwort über einen WebSocket ankommt und mit dem Chat gespeichert wird. Ein vollständiges Protokoll liefern entweder die gespeicherten Chats, wenn Nutzer weder löschen noch temporäre Chats verwenden dürfen, oder ein Gateway zwischen Frontend und Modellserver, das Anfragen und Antworten protokolliert; Open WebUI schickt ihm Name, ID, E-Mail-Adresse und Rolle des Nutzers als Header, wenn ENABLE_FORWARD_USER_INFO_HEADERS auf true steht. Die Europäische Kommission hält in ihren Hinweisen fest, dass Daten „so kurz wie möglich gespeichert werden müssen“, mit „Fristen für die Löschung oder Überprüfung der gespeicherten Daten“. Die Frist selbst und die Frage, was DSGVO oder KI-Verordnung von einem internen Assistenten verlangen, sind eine rechtliche Bewertung für Ihre Rechtsabteilung.

Dasselbe Log dokumentiert die hybride Nutzung. Eine öffentliche API, die manche Aufgaben nutzen dürfen, wird als weitere Verbindung hinzugefügt, wobei ihre Modelle auf die dafür berechtigten Nutzer oder Gruppen beschränkt werden. Lassen Sie die Direct Connections von Open WebUI ausgeschaltet, denn mit ihnen „kommuniziert der Browser direkt mit dem API-Anbieter“, am Server und seinem Log vorbei. Wann sich eine hybride Aufteilung lohnt, behandelt unser Beitrag Privates LLM oder Cloud-API.

Guardrails und Lizenzen offener Modelle

Guardrails prüfen, was in das Modell hineingeht und was herauskommt. Die Filterfunktionen von Open WebUI führen vor dem Modell ein Inlet und vor dem Nutzer ein Outlet aus, und ein als global und aktiv gesetzter Filter ist „für alle Modelle zwangsweise aktiviert“. NVIDIAs NeMo Guardrails, ein Toolkit unter Apache 2.0, ergänzt Input-, Output- und Retrieval-Rails, und OpenAIs Modelle gpt-oss-safeguard, ebenfalls unter Apache 2.0, „klassifizieren Textinhalte auf Grundlage von Sicherheitsrichtlinien, die Sie vorgeben“.

Die Lizenzen unten stammen aus der jeweiligen Model Card und können sich innerhalb einer Modellfamilie unterscheiden.

Model Cards, Lizenzdateien und Metas Nutzungsrichtlinien, abgerufen am 6. Oktober 2026.

Nach Metas Nutzungsrichtlinie für Llama 4 (Acceptable Use Policy), abgerufen am 6. Oktober 2026, werden die Lizenzrechte für „alle in Llama 4 enthaltenen multimodalen Modelle“ natürlichen Personen mit Wohnsitz in der EU und Unternehmen mit Hauptgeschäftssitz in der EU nicht gewährt, ausgenommen „Endnutzer eines Produkts oder Dienstes, das solche multimodalen Modelle integriert“. Meta beschreibt die Llama-4-Modelle als „nativ multimodal“. Ob eine solche Klausel Ihre Nutzung betrifft, ist eine Frage für Ihre Rechtsabteilung.

GPU-Dimensionierung für gleichzeitige Nutzer

Dimensionieren Sie die GPU nach den Anfragen in Bearbeitung in der Hauptgeschäftsstunde, nicht nach der Kopfzahl, wie unser Artikel zu gleichzeitigen Nutzern je RTX PRO 6000 erklärt. Seine Regel gibt dem KV-Cache 0,9 × den vom Treiber gemeldeten Speicher, minus 3 GiB, minus die Gewichte; gpu_memory_utilization von vLLM legt diesen Anteil fest und steht inzwischen standardmäßig auf 0,92. Eine RTX PRO 6000 mit 96 GB meldet 95,6 GiB, der Anteil von 0,9 beträgt also 86,0 GiB. Der Checkpoint von gpt-oss-120b mit seinen Expertengewichten in MXFP4 belegt 65,3 GB oder 60,8 GiB, sodass rund 22,2 GiB bleiben. Nur 18 seiner 36 Schichten halten einen Cache für den ganzen Kontext, während die übrigen ihre Attention über ein Fenster von 128 Token berechnen. Ein Token kostet deshalb 36 KiB Cache in BF16. Bei deklarierten 32K braucht ein Gespräch 1,125 GiB, und rund 19 haben gleichzeitig Platz; vLLM gibt beim Start seinen eigenen Wert aus.

Jede Anfrage des Frontends ist zustandslos, sodass mit jeder Runde das ganze Gespräch gesendet wird, und ein langer Chat mit einem hochgeladenen Dokument kann den deklarierten Kontext füllen; das Prefix Caching von vLLM verwendet den bereits verarbeiteten Verlauf wieder. Open WebUI ruft außerdem im Hintergrund ein Modell für Titel, Tags, Vorschläge für Folgefragen, Autovervollständigung und Suchanfragen auf, und „Standardmäßig läuft all das auf dem Modell, mit dem der Nutzer chattet“. Seine Dokumentation empfiehlt ein kleines, schnelles Task-Modell ohne Reasoning und nennt die Autovervollständigung „das Erste, was man abschalten sollte“. Ein Task- oder Embedding-Modell läuft als zweite vLLM-Instanz mit einem eigenen Anteil am Speicher der Karte.

Inferenzserver für private LLMs bauen wir mit 2 bis 8 GPUs je Knoten, ausgelegt nach Modellgröße und gleichzeitigen Nutzern. Schicken Sie uns über das Formular unten das Modell, den Kontext, den Sie deklarieren wollen, und die Spitze Ihrer Anfragen in Bearbeitung.

Einführung in Schritten: Pilotgruppe, Richtlinie und Schulung

1. Wählen Sie einen Prozess und eine Pilotgruppe und vereinbaren Sie die Metriken, die der Pilot erfüllen muss, bevor er wächst.
2. Schreiben Sie die Nutzungsrichtlinie: zugelassene Datenklassen, Modelle und Verbindungen je Nutzergruppe, was protokolliert wird, wer es liest und wie lange. Was in die Richtlinie gehört, behandelt unser Leitfaden zu Schatten-KI, Richtlinie und Kontrollen.
3. Richten Sie Single Sign-on mit Rollen und Gruppen ein, schalten Sie das lokale Anmeldeformular und die Nutzungsstatistik von vLLM ab, lassen Sie die Direct Connections ausgeschaltet und verkürzen Sie die Laufzeit der Token.
4. Schulen Sie die Pilotgruppe vor dem Zugang: was eingegeben werden darf, wie man eine zitierte Quelle prüft und wie man eine falsche Antwort meldet.
5. Messen Sie Anfragen in Bearbeitung, Zeit bis zum ersten Token und Antwortqualität an den Fragen der Pilotgruppe und dimensionieren Sie die Produktivserver danach.
6. Öffnen Sie den Assistenten für die nächste Abteilung, sobald die Metriken erfüllt sind, und ergänzen Sie einen zweiten Server, bevor das ganze Unternehmen davon abhängt.

Was wir tun

Unsere Leistung Private AI/ML baut diese Plattform unter Ihrer Kontrolle, auf Ihren Servern oder auf dedizierter Hardware in einem Tier-3-Rechenzentrum in Litauen; nichts geht an öffentliche APIs, bis Sie selbst den Hybridmodus für eine konkrete Aufgabe freigeben, und was dorthin geht, zeigt das Query-Log. Die Assistenten antworten auf Basis Ihrer Dokumente, mit Quellenangabe und unter Beachtung der Zugriffsrechte jedes Nutzers. Wir starten mit einem Pilotprojekt auf einem Prozess mit klaren Metriken, skalieren nur, was seinen Wert bewiesen hat, und schulen Ihr Team für den Betrieb der Plattform. Eurokommerz hält den Vertrag und liefert die Hardware, das Engineering kommt von unserem Engineering-Partner Vixen.UNO; das erste Gespräch ist kostenlos, und der Preis des technischen Assessments steht vor Beginn fest. Wie wir während des Projekts mit Daten umgehen, beschreibt unsere Seite Sicherheit & Compliance.

FAQ