Enterprise-LLM-Stack 2026: Sieben Tools im Praxisvergleich für Kubernetes

Wann Sie LibreChat, Open WebUI, Ollama, LM Studio, LiteLLM, LangChain oder Langfuse einsetzen – und warum die richtige Architektur wichtiger ist als jedes einzelne Tool.

Wenn IT-Entscheider im DACH-Raum 2026 über den Aufbau einer internen KI-Infrastruktur sprechen, fallen schnell dieselben Namen: Ollama, Open WebUI, LibreChat, LiteLLM. Die Tools sind Open Source, gut dokumentiert und versprechen Unabhängigkeit von US-Cloud-Anbietern. Was in der Diskussion oft untergeht: Keines dieser Tools löst das Problem allein. Die eigentliche Herausforderung liegt nicht in der Auswahl einzelner Komponenten, sondern im Verständnis ihrer architektonischen Rolle – und in der Frage, welche Kombination zur eigenen Organisation passt.

Dieser Beitrag ordnet sieben verbreitete Open-Source-Tools in eine praxistaugliche Referenzarchitektur ein. Die Perspektive ist bewusst die eines IT-Verantwortlichen, der einen Kubernetes-Cluster mit NVIDIA-GPU-Node betreibt und gleichzeitig Azure OpenAI nutzen möchte – ein Szenario, das in mittelständischen und großen Unternehmen im DACH-Raum zunehmend Standard wird.

Vier Schichten, ein Cluster: Die Referenzarchitektur

Bevor wir einzelne Tools bewerten, lohnt sich ein Blick auf die Gesamtarchitektur. Ein produktionsreifer Enterprise-LLM-Stack besteht aus vier klar getrennten Schichten:

Schicht 1 – Chat-Frontend: Die Oberfläche, über die Mitarbeiter mit LLMs interagieren. Hier laufen Authentifizierung, Benutzer- und Gruppenverwaltung, RAG-Uploads und die Modellauswahl zusammen. Die beiden relevanten Kandidaten sind Open WebUI und LibreChat.

Schicht 2 – API-Gateway: Eine Zwischenschicht, die alle LLM-Anfragen vereinheitlicht, an verschiedene Provider routet, Kosten trackt und Rate Limits durchsetzt. LiteLLM ist hier der De-facto-Standard.

Schicht 3 – Lokale Inferenz: Der Dienst, der Open-Source-Modelle auf der eigenen GPU ausführt. Ollama übernimmt diese Rolle; LM Studio ist eine Desktop-Alternative für Einzelplätze.

Schicht 4 – Observability: Monitoring, Tracing, Kosten-Analyse und Prompt-Management über alle Schichten hinweg. Langfuse ist die führende Open-Source-Lösung – und stammt aus Berlin.

LangChain ist bewusst nicht als Schicht aufgeführt. Es ist ein Entwicklungs-Framework, kein deploybarer Service – dazu später mehr.

┌─────────────────────────────────────────────────┐
│  Schicht 1: Chat-Frontend                       │
│  Open WebUI  oder  LibreChat                    │
│  (LDAP/SSO, RAG, Agents, MCP, File-Uploads)     │
└──────────────────────┬──────────────────────────┘
                       │
┌──────────────────────▼──────────────────────────┐
│  Schicht 2: API-Gateway                         │
│  LiteLLM Proxy                                  │
│  (Routing, Load Balancing, Kosten, Rate Limits)  │
└──────┬───────────────────────────────┬──────────┘
       │                               │
┌──────▼──────────┐     ┌─────────────▼───────────┐
│ Schicht 3: Lokal │     │ Azure OpenAI (Frankfurt) │
│ Ollama (GPU)     │     │ Mistral, Anthropic, ...  │
└─────────────────┘     └─────────────────────────┘
                       │
┌──────────────────────▼──────────────────────────┐
│  Schicht 4: Observability                       │
│  Langfuse                                       │
│  (Tracing, Kosten, Prompt-Mgmt, Evaluierung)    │
└─────────────────────────────────────────────────┘

Der Vorteil dieser Trennung: Jede Schicht lässt sich unabhängig skalieren, austauschen und absichern. Alle Komponenten haben offizielle oder gut gepflegte Helm Charts und lassen sich über GitOps-Workflows (ArgoCD, FluxCD) verwalten. Der NVIDIA GPU Operator übernimmt Treiber-Installation und GPU-Scheduling automatisch.

Schicht 3: Ollama vs. LM Studio vs. llama.cpp – Lokale Inferenz verstehen

Diese drei Tools werden häufig verwechselt, obwohl sie auf völlig unterschiedlichen Ebenen arbeiten.

llama.cpp ist die Basis. Eine reine C/C++-Bibliothek, die LLMs auf CPU und GPU ausführt. Kein GUI, keine Modellverwaltung, keine REST-API im engeren Sinne. Hochoptimierte Inferenz-Engine für GGUF-Modelle – das Fundament, auf dem alles andere aufbaut.

Ollama ist ein benutzerfreundlicher Inference-Server, der llama.cpp unter der Haube nutzt. Es fügt hinzu, was llama.cpp fehlt: ein Docker-artiges Modellmanagement (ollama pull llama3), eine OpenAI-kompatible REST-API, automatische GPU-Erkennung und reproduzierbare Modell-Konfigurationen über sogenannte Modelfiles. Ollama ist als Hintergrunddienst konzipiert, den andere Tools ansprechen – nicht als Endanwender-Produkt.

Die Kubernetes-Bereitstellung ist ausgereift: Der Community Helm Chart von OTWLD unterstützt NVIDIA- und AMD-GPUs, persistenten Storage für Modell-Caching, Modell-Vorladung beim Start und Knative Serverless mit Scale-to-Zero. GPU-Zuordnung erfolgt über Standard-nvidia.com/gpu-Resource-Limits. Für GPU-Sharing bietet NVIDIA Time-Slicing (auf jeder GPU, ohne Speicherisolation) und MIG auf A100/H100 (Hardware-Level-Isolation mit bis zu 7 Instanzen pro GPU).

Das kritische Enterprise-Defizit: Ollama hat keinerlei Authentifizierung. Keine API-Keys, kein RBAC, kein Rate Limiting. Die Entwickler haben bewusst entschieden, keine Auth-Schicht einzubauen – Ollama soll ein Backend-Service sein, der nie direkt im Netzwerk exponiert wird. Sicherheitsforscher fanden Anfang 2026 über 175.000 ungeschützte Ollama-Instanzen weltweit, und CVE-2025-63389 dokumentierte einen Authentication-Bypass in Versionen bis 0.12.3. Für den Enterprise-Einsatz bedeutet das: Ollama darf ausschließlich hinter einem API-Gateway (LiteLLM) oder einem authentifizierten Frontend (Open WebUI, LibreChat) betrieben werden.

LM Studio ist eine Desktop-Anwendung mit eigenem llama.cpp-Fork und grafischer Oberfläche. Modelle lassen sich direkt von Hugging Face durchsuchen und laden, Parameter können visuell getunt werden, und seit v0.3.17 gibt es MCP-Support. Seit Januar 2026 existiert mit llmster ein Headless-Daemon – allerdings nur als CPU-only-Docker-Preview ohne GPU-Unterstützung und ohne Helm Chart. LM Studio ist ein Entwickler-Werkzeug für den Einzelplatz, kein Enterprise-Inference-Server. Nutzen Sie es zum lokalen Experimentieren; für Produktion bleibt Ollama die einzige Option.

Schicht 1: Open WebUI vs. LibreChat – Die Frontend-Entscheidung

Beide Tools sind produktionsreife Chat-Oberflächen, bedienen aber unterschiedliche Enterprise-Profile.

Open WebUI: Beste Ollama-Integration, stärkstes User-Management

Open WebUI (v0.6.31+, ca. 125.000 GitHub-Stars) entstand ursprünglich als „Ollama WebUI” und bietet die engste Integration mit Ollama: Modellverwaltung direkt aus der Oberfläche, gebündelte Docker-Images mit eingebettetem Ollama und Load Balancing über mehrere Ollama-Instanzen.

Für Enterprise-Umgebungen besonders relevant:

Authentifizierung und Benutzerverwaltung: Native LDAP-Integration mit Gruppenverwaltung plus SCIM 2.0 Provisioning für Okta, Azure AD und Google Workspace. Automatisierte Benutzer-Lifecycle-Verwaltung – Onboarding und Offboarding laufen über bestehende Identity-Provider. Federated SSO (OIDC, SAML) erfordert allerdings einen Trusted-Header-Reverse-Proxy statt nativer Protokollunterstützung.

RAG und Wissensmanagement: Die eingebaute RAG-Engine unterstützt neun Vektor-Datenbanken (ChromaDB, PGVector, Qdrant, Milvus, Elasticsearch, OpenSearch, Pinecone, S3Vector, Oracle 23ai). Dokumente lassen sich direkt in der Oberfläche hochladen und stehen sofort als Kontext zur Verfügung.

MCP-Support: Seit v0.6.31 nativ, allerdings nur über Streamable HTTP. Für stdio- oder SSE-basierte MCP-Server ist die mcpo-Bridge als Zwischenschicht nötig.

Bildgenerierung: Integrierte Unterstützung für DALL-E, Automatic1111 und ComfyUI. Bilder können direkt im Chat generiert und bearbeitet werden.

Agents und Tools: Benutzerdefinierte Agents mit konfigurierbaren System-Prompts, Tool-Zugriff und Modellauswahl. Ein Marketplace für Community-Tools und -Pipelines existiert.

Praxisvalidierung: Die Johannes-Gutenberg-Universität Mainz betreibt Open WebUI für über 35.000 Benutzer – ein Beleg für die Skalierbarkeit im deutschsprachigen Raum.

Der offizielle Helm Chart liegt unter helm.openwebui.com.

LibreChat: Beste Azure-Integration, stärkstes MCP-Ökosystem

LibreChat (v0.8.1, im November 2025 von ClickHouse akquiriert, MIT-Lizenz) ist die bessere Wahl in Azure-zentrierten Umgebungen. Es bietet eine dedizierte azureOpenAI-Endpoint-Konfiguration mit Unterstützung für mehrere Deployments, Regionen und Serverless-Inference.

Authentifizierung: Native Unterstützung für OIDC, SAML und LDAP – ohne Reverse-Proxy-Workarounds. Die Konfiguration erfolgt direkt in der librechat.yaml.

MCP-Support: Die ausgereifteste Implementierung im Ökosystem. Unterstützt stdio, SSE und Streamable HTTP Transports mit nutzerspezifischer Isolation und OAuth für MCP-Server. Shopify berichtet von unternehmensweiter Nutzung mit über 30 internen MCP-Servern.

Agents: Ein No-Code-Agent-Builder, Agent-to-Agent-Transfers und ein Agent-Marketplace. Daimler Truck (DAX 40) hat LibreChat unternehmensweit ausgerollt.

RAG: Separate RAG-API basierend auf pgvector – weniger Vektor-DB-Optionen als Open WebUI, aber funktional für die meisten Anwendungsfälle.

Lizenz: Reine MIT-Lizenz ohne Einschränkungen. Whitelabeling und Modifikation sind uneingeschränkt möglich.

Der Helm Chart publiziert zu ghcr.io/danny-avila/librechat-chart/librechat mit MongoDB, Redis und Meilisearch als Abhängigkeiten.

Der entscheidende Lizenzunterschied

LibreChat steht unter reiner MIT-Lizenz. Open WebUI wechselte im April 2025 zu einer modifizierten BSD-3-Clause-Lizenz mit einer Branding-Klausel: Ab 50 Benutzern muss die Bezeichnung „Open WebUI” erhalten bleiben – es sei denn, eine Enterprise-Lizenz wird erworben. Für Organisationen, die eine individuell gebrandete Lösung planen, ist das ein relevanter Unterschied für die Beschaffung.

Feature-Vergleich auf einen Blick

Fähigkeit	LibreChat	Open WebUI
Azure OpenAI	Dedizierte Konfiguration, erstklassig	Über OpenAI-kompatiblen Endpunkt
LDAP/SSO	Nativ (LDAP + OIDC + SAML)	Nativ LDAP + SCIM; SSO via Proxy
MCP	Nativ (stdio, SSE, HTTP)	Nativ HTTP; stdio via mcpo-Bridge
RAG	Separate API, pgvector	Eingebaut, 9 Vektor-DB-Optionen
Ollama-Integration	Über Custom-Endpoint-Konfiguration	Primäre Integration, Modell-Management-UI
Bildgenerierung	DALL-E-3	DALL-E, Automatic1111, ComfyUI
File-Uploads	Ja, mit Agenten-Kontext	Ja, mit RAG-Integration
Lizenz	MIT	Modifizierte BSD-3 (Branding-Klausel)
GitHub-Stars	ca. 34.300	ca. 125.000

Empfehlung: Open WebUI, wenn Ollama die primäre Inferenz-Quelle ist und starkes User-Management (SCIM) gebraucht wird. LibreChat, wenn Azure OpenAI im Vordergrund steht und MCP-Integration Priorität hat.

Schicht 2: LiteLLM – Das Gateway, das alles verbindet

LiteLLM (v1.82.0, MIT-Kern) ist für Multi-Provider-Umgebungen die kritischste Infrastrukturkomponente. Der Proxy-Server sitzt zwischen allen Anwendungen und LLM-Providern und übersetzt Anfragen über 100 Provider-APIs in ein einheitliches OpenAI-kompatibles Format.

Warum ein API-Gateway unverzichtbar ist

Ohne zentrale Steuerungsschicht passiert in der Praxis Folgendes: Jedes Team konfiguriert eigene API-Keys, Kosten laufen unkontrolliert auf, es gibt keine einheitlichen Logs, und ein Providerwechsel erfordert Änderungen an jedem einzelnen Consumer. LiteLLM löst all diese Probleme durch eine einzelne API-Adresse, die intern intelligent routet.

Azure-OpenAI-Integration im Detail

Für DACH-Unternehmen mit Azure-Fokus bietet LiteLLM erstklassige Unterstützung: Mehrere Azure-Deployments lassen sich unter einem logischen Modellnamen zusammenfassen, automatisches Load Balancing über Regionen (z.B. Frankfurt + West Europe), Fallback-Ketten (Azure GPT-4o → direkte OpenAI-API → lokales Ollama) und Azure-AD-Token-Authentifizierung. Das ermöglicht ein besonders DSGVO-relevantes Muster: Sensible Anfragen werden an lokales Ollama geroutet, nicht-sensible Anfragen an Azure OpenAI Frankfurt – alles über einen einzigen API-Endpunkt.

Enterprise-Governance

Die Governance-Features umfassen virtuelle API-Keys mit Budget- und Rate-Limits pro Key, eine Team-/Organisations-Hierarchie mit RBAC, Kosten-Tracking mit Tag-basierter Analyse, automatische Key-Rotation und PII-Erkennung über Presidio-Integration. Das Team-Management ermöglicht pro Team unterschiedliche Modellzugriffe und separate Langfuse-Logging-Instanzen – ideal für abteilungsbezogene Kostenzuordnung und Compliance-Isolation.

Wichtige Einschränkung

SSO, granulares RBAC und Budget-Enforcement-Tiers erfordern die Enterprise-Lizenz. Die Open-Source Community Edition liefert den Kern-Proxy, Routing, Load Balancing, Basis-Kosten-Tracking und virtuelle Keys – für viele Deployments ausreichend, aber ohne die Governance-Features, die CISOs typischerweise erwarten. Prüfen Sie vor der Entscheidung, ob die Community-Version Ihre Compliance-Anforderungen erfüllt.

Der offizielle Helm Chart deployt über OCI bei docker.litellm.ai/berriai/litellm-helm mit PostgreSQL und optionalem Redis.

Schicht 4: Langfuse – Berliner Observability für den DACH-Raum

Langfuse ist für DACH-Unternehmen einzigartig positioniert. Als Berliner GmbH (im Januar 2026 von ClickHouse akquiriert) mit Product Engineering ausschließlich in Europa ist DSGVO-Konformität kein nachträglicher Compliance-Layer, sondern Teil der Unternehmens-DNA. Die Plattform besitzt SOC 2 Type II und ISO 27001 Zertifizierungen. Merck’s Chief Data & AI Officer hat sich öffentlich als Referenz positioniert – ein starkes Signal für deutsche Enterprise-Adoption.

Was Langfuse leistet

Die v3-Architektur basiert auf ClickHouse für Trace-Storage und liefert performante Analysen über Terabytes an LLM-Interaktionsdaten. Die Kernfunktionen umfassen hierarchisches Tracing aller LLM- und Non-LLM-Aufrufe, automatisches Kosten-Tracking pro Modell/Benutzer/Session, zentrales Prompt-Management mit Versionierung und A/B-Testing, LLM-as-a-Judge-Evaluierung, Human-Annotation-Queues und anpassbare Dashboards.

Integration mit LiteLLM

Die Verbindung zu LiteLLM ist besonders nahtlos: langfuse_otel als Callback in der LiteLLM-Proxy-Konfiguration einrichten, und jede Anfrage über das Gateway erzeugt automatisch Traces in Langfuse – mit Modell, Kosten, Latenz und Token-Daten. Keine Code-Änderungen in den Consumer-Anwendungen nötig.

Lizenzmodell und Kosten

Alle Kernfeatures sind MIT-lizenziert und unbegrenzt nutzbar in der selbst gehosteten Version – einschließlich SSO (Okta, Azure AD, Keycloak, Auth0), organisations-basiertem RBAC und unbegrenzter Benutzerzahl. Enterprise-Features (ca. 500 €/Monat) ergänzen projektbezogenes RBAC, Audit-Logs, Datenaufbewahrungsrichtlinien, SCIM 2.0 und UI-Customization. Für die meisten initialen Deployments reicht der OSS-Tier.

Der offizielle Helm Chart liegt bei langfuse.github.io/langfuse-k8s mit optionalen PostgreSQL-, ClickHouse-, Redis- und S3/MinIO-Subcharts.

LangChain: Ein Framework, keine Infrastruktur

LangChain (über 70 Millionen monatliche Downloads) unterscheidet sich fundamental von den anderen Tools – es ist ein Python/TypeScript-Entwicklungs-Framework, kein deploybarer Service. Es bietet Abstraktionen für Prompt-Templates, Chains, Agents, RAG-Pipelines und Memory-Management. LangGraph, seit Ende 2025 in stabiler Version 1.0, ergänzt Graph-basierte Agent-Orchestrierung mit Schleifen, Verzweigungen, Human-in-the-Loop und persistentem State.

Wann LangChain sinnvoll ist

Das Framework macht Sinn, wenn Entwicklungsteams eigene LLM-Anwendungen jenseits einfacher Chat-Oberflächen bauen – komplexe Multi-Step-Agent-Workflows, RAG-Pipelines mit spezialisierter Retrieval-Logik oder Anwendungen mit dutzenden integrierten Tools.

Wann LangChain Overkill ist

Für Teams, die primär eine Chat-Oberfläche mit Modellzugriff brauchen (dafür Open WebUI oder LibreChat nutzen) oder einfache API-Aufrufe an einen einzelnen Provider machen (dafür direkt das OpenAI SDK oder LiteLLM verwenden).

LangSmith vs. Langfuse

LangSmith, die proprietäre Observability-Plattform von LangChain (39 USD/Nutzer/Monat), konkurriert direkt mit Langfuse. Für DACH-Unternehmen empfiehlt sich Langfuse: Open Source, deutsches Unternehmen, nutzungsbasierte statt seat-basierte Preisgestaltung, volle Selbst-Hosting-Option. LangChain integriert nativ sowohl mit LiteLLM (als Provider) als auch mit Langfuse (über Callback-Handler).

Enterprise-Features im Quervergleich

MCP-Support (Model Context Protocol)

MCP, im Dezember 2025 von Anthropic an die Linux Foundation übergeben, ist der aufkommende Standard für die Anbindung von LLM-Anwendungen an externe Tools und Datenquellen.

Tool	MCP-Support	Details
LibreChat	Vollständig	stdio, SSE, Streamable HTTP; Per-User-Isolation; OAuth
Open WebUI	Nativ (eingeschränkt)	Nur Streamable HTTP nativ; stdio/SSE via mcpo-Bridge
LiteLLM	Als Gateway	Leitet MCP-Tools an geroutete Provider weiter
LM Studio	Desktop-Host	MCP-Host für lokale Desktop-Nutzung
LangChain	Via Adapter	`langchain-mcp-adapters` Paket
Ollama	Kein Support	Reiner Inference-Server
Langfuse	Kein Support	Observability-Tool, kein LLM-Consumer

LDAP und Active Directory

Tool	LDAP	SSO/OIDC	SCIM
Open WebUI	Nativ mit Gruppen	Via Reverse-Proxy	Ja (2.0)
LibreChat	Nativ	Nativ (OIDC + SAML)	Nein
LiteLLM	Nein	Enterprise-Lizenz	Nein
Langfuse	Nein	Ja (Okta, Azure AD, Keycloak)	Enterprise
Ollama	Kein Auth	Kein Auth	Kein Auth
LM Studio	Kein Auth	Kein Auth	Kein Auth

Empfohlenes Muster: Keycloak als zentralen OIDC/SAML-Identity-Provider vor Active Directory deployen, dann alle Tools gegen Keycloak authentifizieren. So bleibt die Identity-Infrastruktur zentral und wartbar.

RAG, File-Uploads und Bildgenerierung

Feature	Open WebUI	LibreChat
RAG-Engine	Eingebaut, 9 Vektor-DBs	Separate API, pgvector
File-Uploads	Ja, direkt in Chat	Ja, über Agenten
Bildgenerierung	DALL-E, Automatic1111, ComfyUI	DALL-E-3
Code-Interpreter	Ja	Ja (Sandbox)
Web-Suche	Ja (mehrere Anbieter)	Ja (mehrere Anbieter)

DSGVO-Konformität durch Self-Hosted-Souveränität

Jedes Tool im empfohlenen Stack lässt sich vollständig selbst gehostet auf EU-Kubernetes-Infrastruktur betreiben. Keine Prompts, Antworten oder Nutzungsdaten verlassen den Unternehmensperimeter. Dieser Ansatz erfüllt DSGVO Artikel 46 ohne Standardvertragsklauseln, vermeidet US CLOUD Act-Exposition und erfüllt die BDSG-Anforderungen an die Verarbeitung von Mitarbeiterdaten.

Für die Cloud-Modell-Schicht bietet Azure OpenAI in der Region Frankfurt EU-Datenresidenz für OpenAI-Modelle. LiteLLM kann Routing-Policies erzwingen – sensible Workloads gehen an lokales Ollama, nicht-sensible Anfragen an Azure. Für maximale Souveränität sind Mistral AI (französisch, offene Modellgewichte, lokal deploybar) oder Aleph Alpha (deutsch, BSI-C5-zertifiziert) Alternativen zu OpenAI-Modellen.

Der EU AI Act (volle Anwendung ab August 2026) klassifiziert die meisten internen Enterprise-LLM-Deployments als „begrenztes Risiko” mit Transparenzpflichten und Content-Labeling. Selbst gehostete Open-Weight-Modelle bieten die Auditierbarkeit, die das Gesetz verlangt. Eine Datenschutz-Folgenabschätzung (DSFA) wird vor jedem Produktiv-Deployment empfohlen.

Tools sind nicht alles: Die organisatorischen Voraussetzungen

Die Erfahrung zeigt: Der häufigste Grund für gescheiterte Enterprise-LLM-Projekte ist nicht die falsche Tool-Wahl, sondern mangelnde organisatorische Vorbereitung. Drei Aspekte, die mindestens genauso wichtig sind wie die Technologie:

Governance vor Features. Bevor die erste Ollama-Instanz läuft, braucht es Antworten auf: Wer darf welche Modelle nutzen? Welche Daten dürfen in welche Modelle fließen? Wer trägt die Kosten? Welche Anwendungsfälle sind erlaubt, welche nicht? Ein LLM-Nutzungskonzept, abgestimmt mit Datenschutz, Betriebsrat und Informationssicherheit, ist Voraussetzung – nicht Nachbereitung.

Kompetenzaufbau vor Skalierung. Ein Kubernetes-Cluster mit GPU-Node und fünf deployte Services nützt wenig, wenn das Operations-Team keine LLM-spezifischen Failure-Modes versteht. Prompt-Injection, Halluzinationen, Token-Limits, Modell-Drift – das sind neue Betriebsrisiken, für die klassisches IT-Operations-Wissen nicht ausreicht. Investieren Sie in Schulung, bevor Sie skalieren.

Pilotierung vor Architektur. Starten Sie nicht mit der Vier-Schichten-Referenzarchitektur. Starten Sie mit Open WebUI + Ollama auf einem einzelnen Node für ein begrenztes Pilotteam. Sammeln Sie Erfahrungen, verstehen Sie die tatsächlichen Nutzungsmuster, und erweitern Sie dann schrittweise um LiteLLM (wenn Multi-Provider nötig wird) und Langfuse (wenn Observability und Kosten-Tracking relevant werden).

Was Sie wissen sollten, bevor Sie entscheiden

Drei Erkenntnisse, die in der Tool-Evaluierung oft untergehen:

Erstens: Ollamas fehlende Authentifizierung ist eine bewusste Designentscheidung. Behandeln Sie Ollama wie eine Datenbank – ein Backend-Service, der nie direkt im Netzwerk exponiert wird. Jeder Zugriff läuft über authentifizierte Frontends oder API-Gateways.

Zweitens: Langfuse und LibreChat gehören jetzt beide zu ClickHouse. Die Akquisitionen von Januar und November 2025 bedeuten, dass zwei kritische Stack-Komponenten denselben Corporate Parent haben. Das kann Integration beschleunigen, konzentriert aber auch Abhängigkeiten. Beobachten Sie die Lizenzentwicklung.

Drittens: Die Lizenzlandschaft verschiebt sich. Open WebUIs Branding-Klausel und LiteLLMs Enterprise-Feature-Gating repräsentieren die Open-Core-Spannung, die DACH-Einkaufsabteilungen sorgfältig evaluieren sollten. Bevorzugen Sie MIT-lizenzierte Komponenten (LibreChat, Ollama, Langfuse-Kern, LiteLLM-Kern) wo möglich, und budgetieren Sie Enterprise-Tiers dort, wo Compliance SSO-Enforcement, Audit-Logs oder SCIM-Provisioning erfordert.

Fazit: Inkrementell aufbauen, nicht Big Bang

Die Enterprise-LLM-Landschaft ist Anfang 2026 reif genug für den Produktiveinsatz – aber kein einzelnes Tool deckt alle Anforderungen ab. Die Vier-Schichten-Architektur (Frontend + Gateway + Inferenz + Observability) bietet eine Trennung der Zuständigkeiten, die sauber auf Enterprise-IT-Betrieb abbildet.

Der pragmatische Weg: Open WebUI + Ollama für schnellen Mehrwert mit lokalen Modellen starten. LiteLLM ergänzen, wenn Azure-OpenAI-Integration und Kosten-Governance nötig werden. Langfuse deployen, wenn Observability und Prompt-Management relevant werden. LangChain/LangGraph einsetzen, wenn eigene Agent-Anwendungen entwickelt werden. Und bei allem: Die organisatorischen Voraussetzungen nicht vergessen – sie entscheiden mindestens genauso über Erfolg oder Misserfolg wie die Technologie.

Dieser Beitrag erschien auf stagl.systems. Für Fragen zur Architektur oder Implementierung im DACH-Raum stehe ich gerne zur Verfügung.