NCA Social Media
Aktualisiert:
Autor:
Roland Golla
Isometrischer LITELLM Chip mit einem Schlüssel links und drei Modellkarten rechts

Was ist LiteLLM?

LiteLLM ist ein Open Source Gateway, das sich zwischen eure Anwendungen und die Sprachmodelle setzt. Jeder Aufruf läuft über einen Endpunkt in OpenAI kompatiblem Format, egal ob dahinter ein lokales Modell über Ollama steht oder eine Cloud API. Dabei werden Verbrauch und Kosten pro Schlüssel, Nutzer, Team und Organisation erfasst.

Der Nutzen zeigt sich, sobald mehr als eine Person mit Modellen arbeitet. Wer einen Anbieterschlüssel im Team teilt, hat am Monatsende eine Rechnung und keine Ahnung, welcher Anteil davon aus welchem Projekt kommt. Ein Gateway löst das, indem es eigene Schlüssel ausgibt und jeden Aufruf dem richtigen Topf zuordnet.

Dazu kommt seit den jüngeren Versionen der MCP Teil. LiteLLM verteilt nicht nur Modelle, sondern auch MCP Server und Agents über denselben Endpunkt, mit Zugriffskontrolle je Schlüssel. Damit ist es eines der wenigen Werkzeuge, das Modellzugang, Kostenkontrolle und Werkzeugverteilung an einer Stelle bündelt.

Nach eigenen Angaben unterstützt das Projekt inzwischen über 140 Provider und rund 1.900 Modelle und liegt bei mehr als 53.000 Sternen auf GitHub. Entstanden ist es 2023 bei BerriAI, gegründet von Krrish Dholakia und Ishaan Jaffer.

Inhalt

LiteLLM mit NCA: Schnelle Hilfe vom Experten

Never Code Alone arbeitet aus Duisburg heraus an Softwarequalität und KI gestützter Entwicklung. LiteLLM setzen wir selbst ein, um in Projekten den Überblick über Token und Kosten zu behalten, harte Budgets zu ziehen und MCP Server an die Nutzer zu verteilen. Der Betrieb läuft dabei über eigene Server in Deutschland.

Wir kennen beide Enden der Kette. Auf der einen Seite lokale Modelle über Ollama und offene Modelle wie Qwen, auf der anderen Seite die Frage, wie ein Team damit produktiv und nachvollziehbar arbeitet, ohne dass die Kosten aus dem Blick geraten.

Passend dazu beraten wir im Vibe Coding Consulting, richten AI Coding Guidelines für PHP Projekte ein, bauen CI CD Pipelines für KI Code und begleiten den Weg zu Self Hosted KI im Unternehmen mit Mandantentrennung. Für Teams mit hohen Datenschutzanforderungen kommt unser Duisburger Netzwerkpartner Conversis mit gehosteter Inferenz dazu.

Kosten und Zugriffe für eure KI Nutzung im Griff

Finde das passende Angebot für dein Projekt

Anfrage-Konfiguration

Starten Sie Ihre Anfrage

Projektart
Infos
Nachricht

Eliminierung technischer Schulden mit PHPStan, Rector PHP und PHPUnit. Über 20 Jahre Praxiserfahrung in skalierbaren Backends.

CORE EXPERTISE

Gesetzliche Konformität & Inklusion. Optimierung von Performance und Conversion durch radikal nutzerzentriertes, universelles Design.

BFSG COMPLIANT

Skalierbare KI-Systeme mit echtem Code Ownership. CI/CD, Backup-Strategien und Infrastruktur, die mit deinem Team wächst.

ENTERPRISE READY

Virtuelle Schlüssel statt geteilter Anbieterschlüssel

Der übliche Einstieg sieht so aus: Ein Anbieterschlüssel wandert in eine Konfiguration, dann in eine zweite, irgendwann steht er in einem Chatverlauf. Wer ihn hat, kann jedes Modell in beliebiger Menge ansprechen, und niemand kann später zuordnen, welcher Aufruf woher kam.

LiteLLM gibt stattdessen eigene Schlüssel aus, die nur der Proxy kennt. Die echten Anbieterschlüssel liegen ausschließlich in der Gateway Konfiguration. Jeder ausgegebene Schlüssel bekommt eine Zuordnung zu Nutzer oder Team und trägt seine eigenen Grenzen mit sich.

Pro Schlüssel lässt sich hinterlegen, welche Modelle erreichbar sind, wie hoch Anfragen und Token pro Minute liegen dürfen, wann der Schlüssel abläuft und welches Budget er verbrauchen darf. Verliert jemand seinen Schlüssel oder verlässt das Team, wird genau dieser eine gesperrt und nicht der Zugang für alle.

Für Teams, die zusätzlich detaillierte Auswertung brauchen, lässt sich Langfuse als Observability Schicht daneben stellen.

Auf welchen Ebenen LiteLLM Budgets kennt

Ebene Wofür sie gedacht ist Typischer Einsatz
Schlüssel Grenze für einen einzelnen Zugang Ein Agent, ein Skript, ein automatisierter Job
Nutzer Grenze über alle Schlüssel einer Person Entwickler mit mehreren Projekten und Werkzeugen
Team Gemeinsamer Topf für eine Gruppe Abteilung oder Projektteam mit eigenem Kostenrahmen
Organisation Obergrenze über alles Gesamtdeckel, der am Monatsende niemanden überrascht

Harte Budget Limits, die tatsächlich abschalten

Eine Warnmail bei achtzig Prozent hilft niemandem, der nachts schläft. Der Unterschied bei einem harten Limit ist, dass am Ende des Topfes keine Anfrage mehr durchgeht. Der Proxy antwortet mit einem Fehler, bis das Budget zurückgesetzt wird oder jemand es bewusst anhebt.

Das ist genau der Schutz, den man bei autonomen Agenten braucht. Ein Agent Loop, der sich in einer Schleife verfängt, arbeitet nicht langsamer, weil er teuer wird. Er läuft weiter, bis ihn jemand stoppt. Ein Budget mit Tages oder Monatsreset übernimmt dieses Stoppen zuverlässiger als ein Mensch.

Beim Setzen der Grenzen gehen wir von unten nach oben vor. Zuerst der einzelne Schlüssel für automatisierte Jobs, dann der Nutzer, dann das Team. Der Wert für den Schlüssel eines Agenten darf ruhig unbequem niedrig liegen, weil auffällt, wenn er regelmäßig anschlägt. Genau diese Meldungen sind das Signal, dass an der Stelle etwas nicht rundläuft.

Code: 
          
model_list:
  - model_name: coder-lokal
    litellm_params:
      model: ollama/qwen3-coder
      api_base: http://localhost:11434

litellm_settings:
  max_budget: 500
  budget_duration: 30d

general_settings:
  master_key: os.environ/LITELLM_MASTER_KEY
  database_url: os.environ/DATABASE_URL

Die Werte in der Konfiguration sind Beispiele und keine Empfehlung. Was sinnvoll ist, hängt von Teamgröße, Modellwahl und Arbeitsweise ab. Für den Betrieb braucht der Proxy eine Datenbank, meist PostgreSQL, in der Schlüssel, Verbrauch und Grenzen liegen.

MCP Server zentral an das Team verteilen

Der Teil, der in den meisten Beschreibungen untergeht, ist im Alltag der praktischste. LiteLLM verteilt nicht nur Modelle, sondern auch MCP Server über denselben Endpunkt, mit Zugriffskontrolle je Schlüssel.

Ohne diese Stelle pflegt jeder seine MCP Konfiguration lokal. Kommt ein neuer Server dazu, geht eine Nachricht durch den Chat und jeder trägt ihn selbst ein. Wer Zugangsdaten braucht, bekommt sie irgendwie zugeschickt. Bei drei Leuten geht das, bei fünfzehn nicht mehr.

Über das Gateway wird einmal hinterlegt, welcher Server existiert und welcher Schlüssel ihn erreichen darf. Neue Kollegen bekommen ihren Schlüssel und damit genau den Satz an Werkzeugen, der zu ihrer Rolle passt. Verlässt jemand das Team, fällt mit dem Schlüssel auch der Zugriff auf alle Server weg.

Praktisch ist das etwa beim GitHub MCP Server oder bei eigenen Servern für interne Systeme. Der Verbrauch wird dabei auch für Tool Aufrufe erfasst, sodass sichtbar wird, welche Werkzeuge tatsächlich genutzt werden.

Wann LiteLLM passt und wann der Aufwand zu groß ist

Für einen einzelnen Entwickler mit einem Modell lohnt das Gateway nicht. Es kommt eine Datenbank dazu, ein Dienst, der laufen muss, und eine Konfiguration, die gepflegt werden will. Bei einem Nutzer und einem Anbieter steht dem kein Nutzen gegenüber.

Sinnvoll wird es ab dem Punkt, an dem mehrere Personen mit mehreren Modellen arbeiten oder Agenten unbeaufsichtigt laufen. Dann liefert der Proxy drei Dinge auf einmal: Kostentransparenz, Zugriffskontrolle und eine Stelle, an der sich ein Anbieter austauschen lässt, ohne in jeder Anwendung etwas zu ändern.

Zu bedenken ist, dass die Open Source Fassung Auswertung und Alarmierung nicht mitbringt. Wer detaillierte Auswertungen braucht, stellt Langfuse daneben oder greift auf vorhandenes Monitoring zurück. Einige Enterprise Funktionen wie SSO und Audit Log liegen hinter einer kostenpflichtigen Lizenz.

Als Alternativen gibt es kommerzielle Gateways, die den Betrieb abnehmen. Für Teams, die aus Datenschutzgründen ohnehin selbst hosten, fällt dieser Vorteil weg. Wer die Modelle selbst betreiben will, kombiniert LiteLLM meist mit Ollama für den Einstieg oder vLLM für höheren Durchsatz.

Der Supply Chain Vorfall und was Teams daraus lernen

Im März 2026 wurden zwei Versionen des Python Pakets litellm auf PyPI mit Schadcode ausgeliefert. Der Weg dorthin ist lehrreich: Angreifer hatten zuvor den Sicherheitsscanner Trivy kompromittiert. Trivy lief ungepinnt in der Build Pipeline von LiteLLM. Über diesen Umweg gelangten die Angreifer an die Veröffentlichungsschlüssel und luden manipulierte Pakete hoch.

Der Schadcode sammelte Zugangsdaten, versuchte sich in Kubernetes Clustern seitlich zu bewegen und richtete eine dauerhafte Hintertür ein. PyPI stellte die Pakete nach wenigen Stunden unter Quarantäne. Das offizielle Docker Image des Proxy war nicht betroffen, weil dieser Weg seine Abhängigkeiten fest gepinnt mitbringt.

Wer damals über pip ohne feste Version installiert hat, prüft die installierte Version, entfernt Paket Caches und tauscht alle Zugangsdaten aus, die auf dem betroffenen Rechner erreichbar waren. Nicht nur Modellschlüssel, sondern auch Cloud Zugänge, SSH Schlüssel und Datenbankpasswörter.

Die eigentliche Lehre geht über LiteLLM hinaus. Ein Gateway ist per Definition der Ort, an dem alle Anbieterschlüssel zusammenlaufen. Genau das macht es zu einem lohnenden Ziel. Wer so eine Komponente betreibt, pinnt Versionen fest, bevorzugt das offizielle Container Image, prüft Signaturen und schirmt den Dienst im Netz ab. Das ist dieselbe Sorgfalt, die wir bei CI CD Pipelines und beim Thema lokale KI für Compliance ansetzen.

Put your full AI stack behind one key.

LiteLLM, Projekt Tagline – litellm.ai

LiteLLM in der NCA Praxis

Wir setzen LiteLLM in eigenen Projekten ein, um Token und Kosten sichtbar zu machen, harte Budgets zu ziehen und MCP Server an die Nutzer zu verteilen. Der Betrieb läuft auf eigenen Servern in Deutschland, ohne US Anbieter für die eigene Inferenz.

In Beratungsprojekten ist das Gateway oft der ruhige Baustein zwischen zwei lauteren Themen: der Modellwahl auf der einen und den Regeln für den Agenten auf der anderen Seite. Wer Budgets und Zugriffe geklärt hat, kann bei beidem entspannter experimentieren.

Rund um das Thema helfen wir an mehreren Stellen. Den Rahmen für KI gestützte Entwicklung setzt das Vibe Coding Consulting. Für PHP Teams richten wir die NCA PHP AI Coding Guidelines ein, dazu passt das PHP Consulting und das PHP Refactoring. Automatische Prüfungen laufen über die Vibe Coding CI CD Pipelines und das automatisierte KI Code Review.

Beim Betrieb der Modelle helfen die Einträge zu Ollama, vLLM, llama.cpp, LM Studio und Open WebUI. Beim Thema Auswertung und Compliance passen Langfuse und lokale KI für Compliance. Zur Steuerung von Agenten gibt es Agent Looping, Paperclip und Vise Coding mit Guardrails.

CYPRESS.IO Ambassador und IT Consultant für QA Engenieering und Qualität in PHP Projekten.

NCA Vibe Coding Consulting

Roland Golla ist Entwickler aus Leidenschaft – seit über 20 Jahren. Er hat hunderte Projekte begleitet, von Legacy-Refactoring bis KI-Integration. Bei Vibe Coding verbindet er das Beste aus beiden Welten: Die Geschwindigkeit von KI-generiertem Code mit der Qualität professioneller Softwareentwicklung. Kein Bullshit, keine Agentur-Floskeln – direkte Hilfe von jemandem, der selbst täglich im Code steckt.

E-Mail Kontakt

Häufige Fragen zu LiteLLM

Die wichtigsten Fragen zu Einsatz, Betrieb und Grenzen des Gateways, von der Installation über Budgets bis zur Verteilung von MCP Servern.

Was ist LiteLLM 2026?

Ein Open Source Gateway, das sich zwischen Anwendungen und Sprachmodelle setzt. Alle Aufrufe laufen über einen OpenAI kompatiblen Endpunkt, der Verbrauch und Kosten pro Schlüssel, Nutzer, Team und Organisation erfasst. Nach eigenen Angaben unterstützt das Projekt über 140 Provider und rund 1.900 Modelle.

Ab wann lohnt sich ein LLM Gateway 2026?

Sobald mehrere Personen mit mehreren Modellen arbeiten oder Agenten unbeaufsichtigt laufen. Für einen einzelnen Entwickler mit einem Anbieter steht der Betriebsaufwand aus Dienst und Datenbank in keinem Verhältnis zum Nutzen. Ab Teamgröße kippt die Rechnung deutlich.

Ist LiteLLM 2026 kostenlos?

Der Kern ist Open Source und frei nutzbar, inklusive Proxy, virtueller Schlüssel und Budgets. Einige Funktionen für größere Organisationen wie SSO und Audit Log liegen hinter einer kostenpflichtigen Lizenz. Die Betriebskosten für Server und Datenbank kommen in jedem Fall dazu.

Funktioniert LiteLLM 2026 mit lokalen Modellen?

Ja. Ollama, vLLM und llama.cpp lassen sich genauso einbinden wie Cloud APIs, teilweise nebeneinander in derselben Konfiguration. Damit kann ein Team unkritische Aufgaben lokal fahren und nur für bestimmte Fälle nach außen gehen, ohne dass der Aufrufer etwas davon merkt.

Verteilt LiteLLM 2026 auch MCP Server?

Ja, das ist einer der interessanteren Teile. MCP Server werden über denselben Endpunkt bereitgestellt, mit Zugriffskontrolle je Schlüssel. Wer welchen Server erreichen darf, wird zentral vergeben statt in jeder lokalen Konfiguration gepflegt. Der Verbrauch wird auch für Tool Aufrufe erfasst.

Was passiert, wenn ein Budget aufgebraucht ist?

Der Proxy nimmt weitere Anfragen für diesen Schlüssel nicht mehr an und antwortet mit einem Fehler. Das gilt bis zum Reset nach Tages oder Monatsintervall oder bis jemand das Limit bewusst anhebt. Genau dieses harte Verhalten unterscheidet es von einer Warnmail.

Brauchen wir eine Datenbank für den Betrieb?

Ja, für den Proxy mit Schlüsselverwaltung. Dort liegen die ausgegebenen Schlüssel, der laufende Verbrauch und die Grenzen. Üblich ist PostgreSQL, zusätzlich wird oft Redis für Rate Limits eingesetzt. Ohne Datenbank lässt sich nur das Python SDK ohne Verwaltungsfunktionen nutzen.

Müssen wir unseren Anwendungscode ändern?

In der Regel kaum. Wer bereits gegen eine OpenAI kompatible Schnittstelle arbeitet, tauscht die Basis URL und den Schlüssel aus. Danach entscheidet die Gateway Konfiguration, welches Modell tatsächlich antwortet, ohne dass in der Anwendung etwas angepasst werden muss.

Wie sicher sind die virtuellen Schlüssel?

Die echten Anbieterschlüssel liegen nur in der Gateway Konfiguration und verlassen sie nicht. Ausgegebene Schlüssel lassen sich auf bestimmte Modelle beschränken, mit Ablaufdatum versehen und einzeln sperren. Geht einer verloren, ist genau dieser Zugang betroffen und nicht der aller Nutzer.

Bringt LiteLLM eine Auswertung mit?

Eine Übersicht zu Verbrauch und Kosten ist vorhanden. Für tiefere Auswertung, Tracing und Alarmierung wird üblicherweise Langfuse oder ein vorhandenes Monitoring daneben gestellt. Wer Prometheus und Grafana ohnehin betreibt, hängt den Proxy dort mit an.

Können wir LiteLLM ohne Internet betreiben?

Ja, in Kombination mit lokalen Modellen. Wenn hinter dem Gateway ausschließlich Ollama oder vLLM auf eigener Hardware stehen, verlässt keine Anfrage das Netz. Für Umgebungen mit strengen Vorgaben ist das der übliche Aufbau.

Wie hilft NCA beim Einsatz?

Wir richten das Gateway ein, legen die Budgetstruktur für Schlüssel, Nutzer und Teams fest und verbinden es mit euren Modellen und MCP Servern. Danach zeigen wir dem Team, wie neue Schlüssel und Zugriffe vergeben werden. Der Einstieg ist ein kostenloses Kennenlernen.

Was kostet die Einrichtung bei NCA?

Es gibt keine Pakete und keine Festpreise. Nach einem kostenlosen Kennenlernen schätzen wir den Aufwand ein und rechnen minutengenau ab. Der tatsächliche Umfang hängt davon ab, wie viele Modelle, Teams und MCP Server angebunden werden sollen.

Ist LiteLLM nach dem Supply Chain Vorfall noch sicher einsetzbar?

Ja, mit der richtigen Betriebsweise. Betroffen waren zwei manipulierte Pakete auf PyPI, nicht das offizielle Docker Image des Proxy. Wer das Container Image nutzt, Versionen fest pinnt und den Dienst im Netz abschirmt, betreibt das Gateway sauber. Der Vorfall zeigt vor allem, dass ein Gateway alle Anbieterschlüssel bündelt und deshalb wie eine sicherheitskritische Komponente behandelt gehört.

Wie schützt man ein LLM Gateway gegen Angriffe über Abhängigkeiten?

Feste Versionen in Lockfiles, das offizielle Container Image statt pip Installation, Prüfung von Signaturen und Hashes, ein eigener Paketspiegel und Netzwerkregeln, die ausgehenden Verkehr begrenzen. Dazu Protokollierung, die ungewöhnliche Verbindungen sichtbar macht. Genau diese Sorgfalt gehört in jede Pipeline, nicht nur rund um KI Werkzeuge.