Open Source AI-Stack: LiteLLM, OpenWebUI & souveräne Modellnutzung

Die Welt der Sprachmodelle entwickelt sich rasant – neue Modelle, neue Preise, neue Anbieter. Wer sich früh auf einen einzigen Anbieter festlegt, riskiert schnell Vendor Lock-in und mangelnde Transparenz bei Kosten und Daten.

In diesem Beitrag zeigen wir, wie wir mit LiteLLM, OpenWebUI, lokalen Modellen und automatischer Datenanonymisierung einen flexiblen Open-Source-Stack aufgebaut haben, der Sprachmodelle für unser Team nutzbar macht – ohne die Kontrolle über Infrastruktur und Daten aus der Hand zu geben.

Abstract

Die Landschaft der Sprachmodelle verändert sich derzeit in einem Tempo, das selbst erfahrene Tech-Teams gelegentlich ins Schwitzen bringt. Neue Modelle erscheinen im Wochentakt, Preise ändern sich regelmäßig, Anbieter verschwinden oder pivotieren. Was gestern noch als „State of the Art" galt, ist heute schon wieder ein Kompromiss.

Wer in so einer Umgebung sein gesamtes Setup auf ein einzelnes Modell oder einen einzelnen Anbieter ausrichtet, baut sich schnell ein strukturelles Risiko auf – technisch, wirtschaftlich und organisatorisch.

Wir haben deshalb bewusst einen anderen Weg gewählt: Statt eines einzelnen Tools oder Anbieters setzen wir auf einen modularen, Open-Source-basierten AI-Stack. Das Herzstück bildet LiteLLM als zentraler API-Proxy, kombiniert mit OpenWebUI als Team-Interface, einer lokalen GPU-Workstation für sensible Workloads und einem eigenen Tool zur strukturellen Datenanonymisierung.

Dieser Artikel beschreibt, wie dieser Stack entstanden ist, warum wir bestimmte Entscheidungen getroffen haben und welche Probleme wir noch nicht gelöst haben.

Das Problem: Warum überhaupt ein eigener Stack?

Wenn Teams anfangen, Sprachmodelle ernsthaft in ihren Arbeitsalltag zu integrieren, wiederholen sich erstaunlich schnell dieselben Probleme.

Zunächst sieht alles harmlos aus: Ein Entwickler probiert ein paar Prompts mit der OpenAI-API aus, jemand anderes testet Claude, ein dritter nutzt vielleicht ein in Azure deploytes Modell.

Ein paar Wochen später sieht die Realität dann eher so aus:

• Jeder Entwickler besitzt eigene API-Keys
• Niemand weiß genau, welche Kosten gerade entstehen
• Es ist unklar, welche Daten in welchen Prompts landen
• Modellwechsel bedeuten Änderungen in mehreren Anwendungen
• Vendor Lock-in entsteht quasi nebenbei

Kurz gesagt: Es kann einem über dem Kopf wachsen. Natürlich gibt es dafür eine naheliegende Lösung: ein fertiges SaaS-Produkt kaufen, das genau diese Probleme abstrahiert. Das ist eine vollkommen legitime Entscheidung – viele Teams fahren damit gut.

Wir haben uns trotzdem bewusst dagegen entschieden – nicht aus ideologischen Gründen, sondern aus einer pragmatischen Abwägung heraus. Für uns waren Flexibilität, Transparenz und Datenkontrolle wichtiger als ein möglichst geringer operativer Aufwand. Das bedeutet mehr Eigenverantwortung. Aber auch deutlich mehr Freiheit.

Unser Stack – vier Bausteine

Unser Setup besteht im Kern aus vier Komponenten, die zusammenarbeiten, aber jeweils eine klar definierte Rolle haben.

1. LiteLLM – ein Eingang für alle Modelle

Das Herzstück unseres Systems ist LiteLLM. Die Idee dahinter ist simpel, aber sehr wirkungsvoll: LiteLLM fungiert als universeller Proxy für Sprachmodelle. Egal ob OpenAI, Anthropic, Azure oder ein lokal laufendes Modell – nach außen präsentiert LiteLLM immer dieselbe standardisierte API. Für Anwendungen bedeutet das: Sie sprechen immer nur mit einem einzigen Endpoint, welches Modell tatsächlich im Hintergrund antwortet, wird zentral konfiguriert.

Das hat mehrere praktische Vorteile:

• Modellanbieter lassen sich austauschen, ohne Code zu ändern
• Experimente mit neuen Modellen werden trivial
• Anwendungen bleiben stabil, auch wenn sich Infrastruktur ändert

Ein besonders hilfreiches Feature ist das integrierte Token-Tracking. Jeder interne API-Key kann Teams oder Projekten zugeordnet werden. Verbrauch und Kosten sind transparent sichtbar, Budgets lassen sich sogar direkt durchsetzen. Das klingt trivial, ist in der Praxis aber unfassbar hilfreich.

Natürlich ist LiteLLM nicht das einzige Tool in diesem Bereich – es entstehen gerade viele Lösungen für das gleiche Problem (bspw. openrouter, together ai,...). Wir haben uns für LiteLLM entschieden, weil es drei Eigenschaften kombiniert, die für uns wichtig waren:

• vollständig Open Source
• problemlos self-hostbar
• aktive Community und schnelle Entwicklung

Was LiteLLM allerdings nicht löst, ist das Verhalten der Modelle selbst. Ein Prompt, der perfekt für Claude optimiert ist, funktioniert nicht automatisch genauso gut mit GPT-4 oder DeepSeek. LiteLLM abstrahiert Infrastruktur – nicht Modellcharakter. Und wie jede selbst gehostete Software braucht auch LiteLLM ein Minimum an Pflege. Der Aufwand hält sich in Grenzen. Aber er existiert.

2. OpenWebUI – Sprachmodelle für das gesamte Team

APIs sind großartig – für Entwickler. Der Rest eines Unternehmens möchte allerdings meistens einfach eine gute Chat-Oberfläche. Genau hier kommt OpenWebUI ins Spiel.

OpenWebUI ist eine selbst gehostete Chat-Oberfläche, die sich direkt mit unserem LiteLLM-Proxy verbindet. Für das Team fühlt sich das Ganze im Alltag fast genauso an wie ChatGPT. Der entscheidende Unterschied: Alles läuft auf unserer eigenen Infrastruktur – unsere Modelle (lokal oder in der Cloud), unsere Regeln, unsere Datenkontrolle.

Der Rollout im Team war überraschend unkompliziert. Die Oberfläche ist vertraut, die Einstiegshürde niedrig. Statt technischer Modellnamen haben wir mehrere sprechende Aliase definiert, zum Beispiel für verschiedene Qualitäts- oder Kostenstufen. Das Team hinter OpenWebUI veröffentlicht auch regelmäßig neue Funktionen, sodass man „fast" immer auf dem neuesten Stand ist. Mit OpenWebUI ist auch unser Marketing- und Sales-Team mit eigenen CustomGPTs ausgestattet. Für noch breiteren Funktionsumfang und mehr Autonomie integrieren wir kleine Agentensysteme – n8n ist dabei ein sehr bewährtes Tool für die Umsetzung und Integration in OpenWebUI.

3. Guardrails

LiteLLM ermöglicht es, inhaltliche Filter und Drittanbieter-Lösungen direkt auf Proxy-Ebene zu integrieren – zentral durchgesetzt, ohne dass jede Anwendung diese unabhängig implementieren muss.

Wir nutzen doccape für die Datenanonymisierung. Es ersetzt sensible Entitäten – Namen, Unternehmen, Projektreferenzen – durch neutrale Platzhalter, bevor irgendetwas ein Modell erreicht. Die Textstruktur bleibt erhalten; die realen Entitäten verlassen das Unternehmen nicht.

Das verschiebt Datenschutz von einem Verbotsregime hin zu einem technischen Standard. Kolleginnen und Kollegen können mit echten Dokumenten arbeiten, ohne jedes Mal fragen zu müssen, ob das überhaupt erlaubt ist.

4. Lokal vs. Cloud

Nicht jede Aufgabe gehört in die Cloud. Für datensensitive oder experimentelle Workloads betreiben wir zusätzlich eine lokale GPU-Workstation von AIME. Darauf laufen verschiedene Open-Source-Modelle, unter anderem:

• DeepSeek
• Qwen
• Mistral
• tulu
• glm
• …

Diese Modelle sind inzwischen erstaunlich leistungsfähig – besonders für viele interne Aufgaben oder spezialisierte Agenten (z.B. mit n8n). Die Entscheidung lokal vs. Cloud treffen wir situativ anhand von drei Faktoren:

• Datensensitivität
• Kosten
• benötigte Modellqualität

Durch LiteLLM ist dieser Wechsel für Anwendungen komplett transparent. Ein Modell-Alias wird umkonfiguriert – und die Anwendung nutzt automatisch ein anderes Backend. Keine Anpassung im Code. Keine neue Integration.

Was wir noch nicht gelöst haben

So stabil unser Setup inzwischen läuft – es gibt noch mehrere offene Baustellen.

Modell-Evaluation

Welches Modell eignet sich am besten für welchen Use Case? Im Moment passiert diese Bewertung noch relativ informell – durch Austausch im Team und kleine Experimente. Das funktioniert in einem kleinen Setup. Langfristig wird es aber strukturiertere Evaluation brauchen.

Governance

Ein weiteres Thema ist Modell-Governance. Wer entscheidet eigentlich, welche Modelle für welche Aufgaben freigegeben sind? Aktuell ist das bei uns noch relativ locker organisiert. Für größere Organisationen wäre das vermutlich zu informell.

Fazit

Unser AI-Stack gibt uns drei Dinge, die uns wichtig sind:

• Kontrolle über Kosten
• Kontrolle über Modelle
• Kontrolle über Daten

Gleichzeitig bleiben wir flexibel gegenüber einer Branche, die sich momentan schneller verändert als jede andere Infrastruktur-Technologie der letzten Jahre.

Die Kehrseite ist klar: Open Source bedeutet Eigenverantwortung. Man betreibt Infrastruktur. Man trifft Entscheidungen selbst. Und manchmal muss man Probleme lösen, für die es noch keine fertige Lösung gibt.

Für uns überwiegen die Vorteile. Aber wir sind neugierig: Wie habt ihr das gelöst?

Ausblick: Sprachmodelle als lokale Automationsschicht

Ein nächster Schritt, den wir intern bereits umgesetzt haben, geht noch weiter. Wir verbinden lokale Systeme und interne Datenquellen direkt mit OpenWebUI und LiteLLM – das bedeutet: Sprachmodelle können nicht nur chatten, sondern auch aktiv mit unserer Infrastruktur arbeiten:

• Jira-Tickets anlegen
• Termine aus internen Systemen zusammenfassen
• interne Datenquellen durchsuchen
• Workflows anstoßen

Alles lokal. Alles unter eigener Kontrolle. Ohne dass Daten das Unternehmen verlassen. Das wäre vermutlich Stoff für einen eigenen Artikel.

TL;DR

• LiteLLM vereinheitlicht alle Modellanbieter hinter einer API, mit zentralem Token-Tracking
• OpenWebUI bringt Sprachmodelle als Chat-Interface ins gesamte Team
• doccape anonymisiert Daten strukturell vor dem API-Call
• Lokale Modelle auf AIME-Workstations ergänzen Cloud-Modelle
• Offene Themen bleiben Modell-Evaluation, Governance und Skalierung