Zurück zum Katalog
LiteLLM: The Universal LLM Gateway (v1.82 - 2026 Edition)
Eine umfassende Podcast-Serie über LiteLLM, vom Python SDK und einheitlichem Exception Handling bis hin zum Proxy Server, Load Balancing, Virtual Keys, Observability und Enterprise-Funktionen wie RBAC und dem MCP Gateway.
Aktuelle Wiedergabe
Click play to start
0:00
0:00
1
Der Rosetta-Stein der LLMs: Das Python SDK
Entdecken Sie die Kernidentität von LiteLLM: ein einheitliches Python-Interface für über 100 LLMs. Erfahren Sie, wie Sie LiteLLM in Ihre bestehende Codebase integrieren können, um Anthropic, Vertex oder Ollama aufzurufen, ohne Ihre OpenAI-kompatible Parsing-Logik zu ändern.
2
Magie der Parameter-Übersetzung
Machen Sie sich keine Gedanken mehr darüber, welcher Provider welchen Hyperparameter unterstützt. Erfahren Sie, wie das SDK von LiteLLM Standard-OpenAI-Inputs wie temperature, tools und max_tokens automatisch für alle Upstream-Modelle übersetzt.
3
Einheitliches Exception Handling
Schreiben Sie Ihre try-except-Blöcke nur einmal. Entdecken Sie, wie LiteLLM benutzerdefinierte Fehler von AWS, Google und Azure abfängt und sie perfekt auf Standard-OpenAI-Exceptions wie den RateLimitError abbildet.
4
Das LLM Gateway: Einrichtung des Proxy Servers
Bringen Sie LiteLLM aus Ihrem lokalen Code in eine zentralisierte Plattform. Erfahren Sie, wie Sie den LiteLLM Proxy Server über Docker starten und Ihre ersten Endpunkte über die config.yaml-Datei konfigurieren.
5
Zentralisiertes Secret Management
Halten Sie Ihre API-Keys aus Klartext-Konfigurationen fern. Erfahren Sie, wie Sie LiteLLM mit Enterprise Secret Managern wie dem AWS Secrets Manager oder Azure Key Vault verbinden, um Credentials dynamisch abzurufen.
6
Model Aliases: Das Schatten-Upgrade
Migrieren Sie Nutzer geräuschlos auf neue Modelle. Entdecken Sie, wie Sie Model Aliases in LiteLLM verwenden, um Anfragen für ein Modell auf einen völlig anderen Endpunkt umzuleiten, ohne den clientseitigen Code zu ändern.
7
Load Balancing für hohen Durchsatz
Vermeiden Sie Rate Limits und Ausfallzeiten durch intelligentes Routing des Traffics. Erfahren Sie, warum simple-shuffle die empfohlene Strategie für das Load Balancing in der Produktion über mehrere Deployments hinweg ist.
8
API-Ausfälle und Fallbacks
Erleben Sie nie wieder eine AI-Downtime. Erfahren Sie, wie Sie Model Fallbacks in LiteLLM so konfigurieren, dass der Traffic bei einem Ausfall Ihres primären Providers automatisch auf einen Backup-Provider umgeleitet wird.
9
Context Window Fallbacks
Hören Sie auf, für riesige Context Windows bei kurzen Prompts zu viel zu bezahlen. Erfahren Sie, wie Sie Pre-Call-Checks und Context Window Fallbacks nutzen, um überdimensionierte Dokumente an spezialisierte Modelle weiterzuleiten.
10
Hängende Requests mit Timeouts bändigen
Lassen Sie nicht zu, dass langsame APIs Ihre Anwendung einfrieren. Entdecken Sie, wie Sie globale Timeouts und Stream Timeouts in LiteLLM konfigurieren, um blockierte Requests abzubrechen und schnelle Fallbacks auszulösen.
11
Virtual Keys für FinOps
Sichern Sie Ihre API-Nutzung präzise ab. Erfahren Sie, wie Sie mit LiteLLM Virtual Keys generieren und strenge RPM-, TPM- und Budget-Limits festlegen, um Ihre Organisation vor ausufernden AI-Kosten zu schützen.
12
Spend Tracking und Custom Tags
Ordnen Sie jeden Cent der LLM-Ausgaben genau zu. Erfahren Sie, wie Sie Metadaten-Tags in Ihren Requests übergeben und umfassende Spend-Reports mit LiteLLM erstellen.
13
Caching für Geschwindigkeit und Einsparungen
Hören Sie auf, immer wieder für dieselben LLM-Antworten zu bezahlen. Erfahren Sie, wie Sie Exact Caching mit Redis und Semantic Caching mit Qdrant konfigurieren, um Latenzzeiten und API-Kosten drastisch zu senken.
14
RBAC: Team Admins befähigen
Verteilen Sie das Plattform-Management sicher. Verstehen Sie die Role-Based Access Control von LiteLLM, mit der Sie Befugnisse an Org Admins und Team Admins delegieren können, ohne die globale Sicherheit zu gefährden.
15
Security Guardrails
Fügen Sie Ihren LLM-Requests eine unsichtbare Sicherheitsebene hinzu. Erfahren Sie, wie Sie Pre-Call- und Post-Call-Guardrails in LiteLLM konfigurieren, um Prompt Injections zu blockieren und PII zu maskieren, bevor sie externe Provider erreichen.
16
Dynamisches Callback Management
Geben Sie Microservices die Kontrolle über den Datenschutz. Erfahren Sie, wie Sie den Header x-litellm-disable-callbacks verwenden, damit sensible API-Requests vom zentralen Observability-Logging ausgeschlossen werden.
17
Drop-in Observability
Erhalten Sie sofortige Transparenz über Ihren LLM-Traffic. Erfahren Sie, wie Sie Telemetrie, Traces und Exceptions mithilfe einfacher Success- und Failure-Callbacks an Tools wie Langfuse und Sentry weiterleiten.
18
Prometheus Metrics und Pod Health
Fühlen Sie Ihrem Proxy den Puls. Entdecken Sie, wie Sie den /metrics-Endpunkt für Prometheus freigeben, In-Flight Requests verfolgen und Custom Tags verwenden, um Daten in Grafana aufzuschlüsseln.
19
Universelles Text-to-Speech
Standardisieren Sie Ihre Sprachgenerierung. Entdecken Sie, wie Sie Text-to-Speech-Modelle von Gemini, Vertex und AWS Polly über genau dasselbe OpenAI-kompatible Audio-Endpunkt-Format aufrufen.
20
Die Assistants API Bridge
Verwalten Sie den Conversation State mühelos über verschiedene Provider hinweg. Erfahren Sie, wie LiteLLM nicht-native Modelle in das Standard-Interface der OpenAI Assistants API hüllt, sodass Sie Threads und Messages überall nutzen können.
21
Das MCP Gateway
Rüsten Sie Ihre Modelle zentral mit Tools auf. Entdecken Sie, wie Sie HTTP-, SSE- oder STDIO-Server für das Model Context Protocol (MCP) in LiteLLM konfigurieren und so jedem LLM Zugriff auf externe Fähigkeiten geben.
22
A2A: Tracking von Autonomous Agents
Bringen Sie Autonomous Agents unter Kontrolle. Erfahren Sie, wie Sie komplexe LangGraph- oder Bedrock-Agenten über den Proxy mithilfe des A2A-Protokolls aufrufen, was Trace Grouping und einheitliches Spend Tracking ermöglicht.
23
Zero-Downtime Key Rotations
Erreichen Sie Sicherheitsumstellungen ohne Ausfallzeiten. Erfahren Sie, wie Sie automatische, geplante Key Rotations und Grace Periods für Enterprise-Grade Virtual Keys in LiteLLM konfigurieren.
24
Die Admin UI und der AI Hub
Machen Sie Ihre AI-Plattform für alle zugänglich. Erfahren Sie, wie Sie die Admin UI verwalten, UI-Credentials anpassen und den AI Hub nutzen, damit Entwickler erlaubte Modelle und Agenten sicher entdecken können.
Episoden
1
Der Rosetta-Stein der LLMs: Das Python SDK
4m 14sEntdecken Sie die Kernidentität von LiteLLM: ein einheitliches Python-Interface für über 100 LLMs. Erfahren Sie, wie Sie LiteLLM in Ihre bestehende Codebase integrieren können, um Anthropic, Vertex oder Ollama aufzurufen, ohne Ihre OpenAI-kompatible Parsing-Logik zu ändern.
Hallo, hier ist Alex von DEV STORIES DOT EU. LiteLLM: Das universelle LLM-Gateway, Folge 1 von 24. Du tauschst deinen OpenAI API Key gegen einen von Anthropic aus, und plötzlich stürzt deine gesamte Anwendung ab. Jeder Provider gestaltet seine Inputs und Outputs anders, sodass du für jedes neue Modell eine eigene Parsing-Logik schreiben und pflegen musst. Der Stein von Rosetta der LLMs, das LiteLLM Python SDK, löst dieses Problem vollständig.
Es gibt das weit verbreitete Missverständnis, dass LiteLLM mit LangChain konkurriert. Das tut es nicht. LiteLLM ist kein Agent Framework. Es orchestriert keine Tools, verwaltet kein Memory und chaint keine Tasks zusammen. Es ist einfach ein Drop-in Replacement für den OpenAI Client.
Das LiteLLM Python SDK übersetzt über hundert verschiedene Provider APIs in das exakte OpenAI Chat Completion Format. Du musst die spezifischen Nuancen der Vertex AI, Anthropic oder Hugging Face APIs nicht lernen. Du schreibst deinen Code einmalig nach dem OpenAI-Standard, und LiteLLM übernimmt den Translation Layer im Hintergrund.
Das Herzstück dieses SDKs ist ein einziges, einheitliches Interface, die sogenannte Completion Function. Wenn du diese Funktion nutzt, übergibst du einen Model String. Dieser String teilt LiteLLM mit, welchen Provider es kontaktieren soll. Außerdem übergibst du Standard-OpenAI-Parameter wie Temperature, Max Tokens und die Messages List. LiteLLM nimmt diese Standardparameter und mappt sie auf die korrekten Felder für den Ziel-Provider.
Stell dir vor, du möchtest Claude 3.5 Sonnet aufrufen. Mit dem Standard-Anthropic-SDK müsstest du deine Prompt-Blöcke entsprechend den spezifischen Anforderungen ihrer Message API strukturieren. Mit LiteLLM rufst du einfach die Completion Function auf. Du übergibst den Model Name für Claude. Du übergibst dein Standard Messages Array und nutzt Dictionaries mit User und System Roles. Schließlich übergibst du deinen Anthropic API Key, entweder als Parameter oder als Environment Variable.
Hier ist der entscheidende Punkt. Das Response Object, das von dieser Funktion zurückgegeben wird, ist exakt wie ein OpenAI Chat Completion Object strukturiert.
Wenn du den von Claude generierten Text extrahieren willst, gehst du exakt denselben Pfad wie bei einem GPT-Modell. Du schaust dir das Choices Array an. Du nimmst das erste Item. Du greifst auf das Message Object zu. Du liest die Content Property aus. Deine Application Logic hat keine Ahnung, dass Anthropic den Text generiert hat. Der zugrundeliegende Network Request wurde übersetzt, an den Provider gesendet, und die Response wurde auf das OpenAI-Schema zurückgemappt, bevor sie jemals deine Variablen erreicht hat.
Diese Abstraktion gilt für die gesamte Interaktion. Sie umfasst Errors, Token Usage Statistics und sogar Streaming Responses. Wenn Anthropic einen Rate Limit Error zurückgibt, mappt LiteLLM diesen auf die Standard OpenAI Rate Limit Exception. Dein bestehender Error Handling Code fängt ihn ohne Modifikation ab. Wenn du eine Streaming Response anforderst, liefert LiteLLM Chunks, die exakt wie OpenAI Streaming Chunks aussehen.
Du kannst durch verschiedene Modelle iterieren, indem du einfach den String-Wert des Model Parameters änderst und die Environment Variable für den API Key austauschst. Dein restlicher Python-Code bleibt dabei komplett statisch. Du bist nicht länger an ein einzelnes Ökosystem gebunden, nur weil du deinen Integration Code für einen bestimmten Provider geschrieben hast.
Der wahre Wert des einheitlichen Completion Interfaces liegt darin, deine Application Logic von den endlosen Variationen der Model Provider APIs zu entkoppeln und komplexe Infrastrukturänderungen in einfache String Swaps zu verwandeln.
Danke fürs Zuhören, Happy Coding zusammen!
2
Magie der Parameter-Übersetzung
3m 55sMachen Sie sich keine Gedanken mehr darüber, welcher Provider welchen Hyperparameter unterstützt. Erfahren Sie, wie das SDK von LiteLLM Standard-OpenAI-Inputs wie temperature, tools und max_tokens automatisch für alle Upstream-Modelle übersetzt.
Hallo, hier ist Alex von DEV STORIES DOT EU. LiteLLM: Das universelle LLM Gateway, Folge 2 von 24. Erwartet Claude max tokens, max tokens to sample oder etwas ganz anderes? Jedes Mal, wenn du den Model Provider wechselst, musst du normalerweise deinen kompletten API Request Payload umschreiben, damit er zu deren spezifischen Naming Conventions passt. Parameter Translation Magic ist das Feature, das dieses Problem verschwinden lässt.
Wenn du die Completion Function in LiteLLM aufrufst, schreibst du deinen Request immer nur im Standard OpenAI Parameter Format. Du musst nicht die spezifischen Dictionary Keys für Anthropic, Vertex AI oder Cohere nachschlagen. Die Library fängt deine OpenAI-formatierten Inputs ab und übersetzt sie automatisch in die exakte Struktur, die der Target Provider benötigt.
Schauen wir uns ein konkretes Szenario an. Du möchtest ein Vertex AI Gemini Model abfragen. Du brauchst Function Calling, und du willst, dass die Responses hochgradig deterministisch sind, also setzt du die Temperature auf null Komma zwei. Wenn du eine direkte Integration schreiben würdest, hat Vertex seine ganz eigene, tief verschachtelte Art, Tools zu definieren und Model Generation Configurations zu setzen. Mit LiteLLM ignorierst du das komplett. Du baust dein Tools Array mit der Standard OpenAI JSON Syntax. Du übergibst dieses Array zusammen mit deinem Temperature Wert direkt in den Completion Call. LiteLLM schnappt sich diese OpenAI Arguments, zerlegt sie und baut den korrekten Vertex AI API Payload zusammen, bevor der Network Request gesendet wird.
Dieses automatische Mapping ist unglaublich effizient, aber es bringt einen Edge Case mit sich. Was passiert, wenn du einen OpenAI Parameter übergibst, den das Target Model einfach überhaupt nicht unterstützt? Vielleicht gibst du eine Presence Penalty an, aber dem Provider fehlt ein entsprechendes Konzept. Standardmäßig ist LiteLLM strict. Es wirft eine Exception und lässt den Completion Call fehlschlagen. Das ist eine bewusste Design Choice. Sie verhindert, dass du stillschweigend Configuration verlierst, die für das Verhalten deiner Application kritisch sein könnte.
Strict Failing ist sicher, aber es kann frustrierend sein, wenn du User Prompts in Production dynamisch über Dutzende verschiedener Models routest. Wenn du willst, dass der Call trotz kleinerer Parameter Mismatches erfolgreich ist, fügst du in deinem Completion Call ein Flag namens drop params hinzu und setzt es auf true. Wenn du das aktivierst, übersetzt LiteLLM weiterhin alles, was es erfolgreich mappen kann. Aber wenn es auf einen OpenAI Parameter stößt, den der Target Provider nicht erkennt, entfernt es diesen nicht unterstützten Parameter einfach aus dem Payload und sendet den Rest des Requests. Der Call ist erfolgreich, und der nicht unterstützte Parameter wird sicher ignoriert.
Wenn du Capabilities lieber graceful in deinem eigenen Code handlen möchtest, anstatt dich auf Silent Drops zu verlassen, gibt es ein eingebautes Introspection Tool. Du kannst eine Helper Function namens get supported openai params aufrufen. Du übergibst den Model Name als Argument, und sie gibt eine Liste aller Standard OpenAI Parameter zurück, die erfolgreich auf dieses spezifische Model gemappt werden. Dadurch kannst du zur Runtime überprüfen, was ein Model tatsächlich unterstützt, bevor du den Completion Call ausführst.
Hier ist die wichtigste Erkenntnis. Der wahre Wert der Parameter Translation ist, dass sie die OpenAI API Specification von einem Vendor-spezifischen Schema zu einer universellen Interface Language für deinen gesamten Application Stack befördert.
Danke fürs Zuhören, Happy Coding zusammen!
3
Einheitliches Exception Handling
3m 38sSchreiben Sie Ihre try-except-Blöcke nur einmal. Entdecken Sie, wie LiteLLM benutzerdefinierte Fehler von AWS, Google und Azure abfängt und sie perfekt auf Standard-OpenAI-Exceptions wie den RateLimitError abbildet.
Hallo, hier ist Alex von DEV STORIES DOT EU. LiteLLM: Das universelle LLM-Gateway, Folge 3 von 24. Custom Error Handling Logik für fünfzehn verschiedene AI APIs zu schreiben, ist eine tolle Möglichkeit, dein Wochenende zu verschwenden. Jede API hat ihre ganz eigene Art, dir zu sagen, dass du zu viele Requests sendest oder dass dein Token invalid ist. Damit du keine endlosen Conditionals schreiben musst, nutzt LiteLLM Unified Exception Handling.
Anstatt zu lernen, wie Anthropic, Cohere oder Google ihre Errors ausgeben, musst du nur einen Standard handlen. LiteLLM mappt alle zugrunde liegenden Provider Exceptions direkt auf Standard OpenAI Exception Types. Wenn ein Request fehlschlägt, fängt das Gateway den Raw Error ab, übersetzt ihn basierend auf dem HTTP Status Code und der Provider Response, und wirft den entsprechenden OpenAI Error.
Stell dir folgendes Szenario vor: Du nutzt einen Hugging Face Inference Endpoint. Zu Spitzenzeiten ist der Endpoint mit Traffic überlastet. Hugging Face wird den Request ablehnen. Wenn du ihre API direkt aufrufen würdest, müsstest du ihren spezifischen HTTP fünf null drei Service Unavailable Error oder eine Custom Throttling Message parsen. Dank Unified Exception Mapping brauchst du keinen spezifischen Hugging Face Exception Handler.
Du strukturierst deinen Code mit einem Standard Try Block um deinen Generation Call. Direkt darunter fügst du einen Except Block hinzu, der einen OpenAI Rate Limit Error catcht. Innerhalb dieses Blocks triggerst du deine Standard Exponential Backoff Funktion. Deine Application pausiert, wartet und führt einen Retry für den Request aus. Wenn du später Hugging Face durch Vertex AI austauschst, bleibt deine Backoff Logik exakt gleich. Der OpenAI Rate Limit Error catcht das Vertex Throttling Event genauso zuverlässig.
Dieses Mapping deckt das gesamte Standard-Set an Failures ab. Du kannst einen OpenAI API Timeout Error catchen, wenn ein Remote Server hängt. Du kannst einen Authentication Error catchen, wenn ein API Key rotiert oder abläuft. Du kannst einen API Connection Error bei Network Drops handlen, oder einen Bad Request Error, wenn dein Payload malformed ist. Dein Application Code behandelt das gesamte AI Ecosystem so, als würde er ausschließlich mit einem einzigen, berechenbaren Provider kommunizieren.
Hier ist die Key Insight: Manchmal versteckt eine saubere Abstraction zu viel Context. Ein generischer OpenAI Bad Request Error sagt dir zwar, dass der Call fehlgeschlagen ist, aber oft musst du genau wissen, warum. Azure zum Beispiel wendet strenge Content Policy Filter an. Wenn Azure einen Prompt ablehnt, weil er gegen Safety Guidelines verstößt, riskierst du beim Mapping auf einen generischen OpenAI Error, dass das spezifische Safety Flag verloren geht, das du loggen oder dem User anzeigen musst.
Um das zu lösen, hängt LiteLLM ein Attribut namens provider specific fields an das Exception Object an. Wenn du in deinem Code eine OpenAI Exception catchst, kannst du dieses Attribut inspizieren. Es enthält ein Dictionary mit den originalen, unmapped Error Data direkt vom Provider. Du bekommst den Unified Try und Except Flow für Routing und Retries, aber du behältst die granularen Daten für Debugging und Auditing.
Du baust deine resilienten Systeme, deine Retries und deine Circuit Breaker komplett um die OpenAI Exception Classes herum. Die Standardisierung deiner Error Boundaries verhindert, dass Provider-spezifische Failure Modes in deine Core Application Logic eindringen.
Danke fürs Zuhören, Happy Coding zusammen!
4
Das LLM Gateway: Einrichtung des Proxy Servers
4m 08sBringen Sie LiteLLM aus Ihrem lokalen Code in eine zentralisierte Plattform. Erfahren Sie, wie Sie den LiteLLM Proxy Server über Docker starten und Ihre ersten Endpunkte über die config.yaml-Datei konfigurieren.
Hallo, hier ist Alex von DEV STORIES DOT EU. LiteLLM: Das universelle LLM-Gateway, Folge 4 von 24. Was wäre, wenn dein gesamtes Unternehmen einen einzigen LLM-Endpoint nutzen könnte, ohne jemals die rohen Provider-API-Keys offenzulegen? Der Wechsel von einer lokalen SDK-Integration zu einer zentralisierten Architektur verändert, wie du Zugriffe verwaltest. Das ist das LLM-Gateway: Den Proxy-Server einrichten.
Viele Entwickler gehen davon aus, dass die Einführung eines Custom-Middleware-Proxys das Schreiben von eigenem Client-Code erfordert, um mit ihm zu kommunizieren. Das stimmt nicht. Der LiteLLM-Proxy spricht das native OpenAI-API-Format. Jede Library, jede Application oder jedes Script, das mit OpenAI kommunizieren kann, muss lediglich seine Base-URL aktualisieren, um auf deinen neuen Proxy zu zeigen.
Um den Proxy-Server zu starten, brauchst du eine Konfigurationsdatei. Das ist eine YAML-Datei, die deine Routing-Logik definiert. Das Herzstück dieser Datei ist eine Section namens Model List. Diese Liste mappt die Model-Namen, die deine internen Applications anfragen, auf die tatsächlichen Backend-Provider-Models.
Innerhalb der Model List braucht jeder Eintrag zwei Hauptbestandteile. Erstens den Model-Namen. Das ist der Alias, den du deinen Usern zur Verfügung stellst. Du könntest ihn zum Beispiel internal-chat-model nennen. Zweitens einen Block namens LiteLLM Parameters. Hier konfigurierst du das eigentliche Ziel. Diese Unterscheidung ist wichtig. Der Model-Name ist das, was dein Client anfragt, aber der LiteLLM Parameters Block definiert, was den Request tatsächlich verarbeitet.
Wenn du auf ein Azure OpenAI Deployment routest, enthält dein LiteLLM Parameters Block den spezifischen Azure Model String, deine Azure API Base-URL und die API-Version. Du teilst LiteLLM außerdem mit, welche Environment Variable den API-Key enthält. Du hardcodest den Key nicht in der YAML-Datei selbst.
Wenn die Konfigurationsdatei fertig ist, deployst du den Proxy mit Docker. Du nutzt das offizielle LiteLLM Image aus der GitHub Container Registry. Wenn du den Docker Container ausführst, machst du drei spezifische Schritte. Du mappst deinen lokalen Port viertausend auf den Container-Port viertausend. Du mountest deine YAML-Konfigurationsdatei in den Container, damit der Proxy deine Model List lesen kann. Zum Schluss übergibst du deine eigentlichen Provider Credentials als Environment Variables an den Container.
Sobald der Container läuft, ist der Proxy live und lauscht auf localhost Port viertausend. Du testest ihn genau so, wie du die offizielle OpenAI API testen würdest. Du machst einen Standard HTTP POST Request mit einem Tool wie cURL. Du sprichst localhost Port viertausend an, gefolgt vom Pfad slash chat slash completions. Im Request Body gibst du den Alias, den du vorhin definiert hast, als Model an, und du übergibst dein Messages Array.
Der Proxy empfängt diese Standard-Payload. Er liest den angefragten Alias, sucht ihn in deiner Konfigurationsdatei und extrahiert die Azure Parameters. Dann signiert er den Request mit deinem Azure API-Key, leitet ihn an Microsoft weiter und übersetzt die Response zurück in das exakte Format, das dein Client erwartet.
Hier ist die wichtigste Erkenntnis. Der Proxy abstrahiert den Backend-Provider komplett vom Application Layer. Wenn du dich entscheidest, dein Azure Deployment nächsten Monat gegen einen komplett anderen Provider auszutauschen, fasst du keine einzige Zeile deines Application Codes an. Du updatest lediglich die LiteLLM Parameters in deiner YAML-Konfigurationsdatei und startest den Container neu.
Der Hauptnutzen des Proxy-Servers ist, dass deine Client Applications nie wissen, und auch nie wissen müssen, welcher Cloud-Provider die Tokens eigentlich generiert.
Danke fürs Zuhören, Happy Coding zusammen!
5
Zentralisiertes Secret Management
3m 55sHalten Sie Ihre API-Keys aus Klartext-Konfigurationen fern. Erfahren Sie, wie Sie LiteLLM mit Enterprise Secret Managern wie dem AWS Secrets Manager oder Azure Key Vault verbinden, um Credentials dynamisch abzurufen.
Hallo, hier ist Alex von DEV STORIES DOT EU. LiteLLM: Das universelle LLM-Gateway, Folge 5 von 24. Wenn der Master-API-Key deines Unternehmens in einer Plaintext-YAML-Datei auf einem Production-Server liegt, wird dein Security-Team einen schlechten Tag haben. Hardcoded Credentials sind ein Incident, der nur darauf wartet, zu passieren. Die Lösung ist Centralized Secret Management.
Wenn du ein Gateway betreibst, braucht es Zugriff auf die API-Keys deiner Upstream-Provider, um den Traffic erfolgreich zu routen. Der Standardansatz ist oft, diese in eine lokale Environment Variable oder direkt in die Haupt-Config-Datei zu packen. Centralized Secret Management ändert dieses Pattern komplett. Es erlaubt dem Gateway, Credentials dynamisch aus einem externen Enterprise Vault zu lesen, wie zum Beispiel AWS Secrets Manager, Azure Key Vault, Google Secret Manager oder HashiCorp Vault.
Um diese Connection zu aktivieren, konfigurierst du zwei spezifische Felder im General-Settings-Block deiner Config-Datei. Das erste Feld ist das Key Management System. Hier definierst du den Identifier deines Vault-Providers. Wenn du AWS nutzt, setzt du das auf aws_kms. Das zweite Feld sind die Key Management Settings. Das ist eine Nested Structure, in der du die genauen Connection-Parameter angibst, die dein spezifischer Vault braucht, wie zum Beispiel die Target AWS Region oder andere erforderliche Authentication-Details.
Sobald die Vault-Connection steht, musst du deinen einzelnen Model-Routing-Configs sagen, dass sie ihre Keys aus diesem Vault ziehen sollen. Das machst du mit einem spezifischen String-Prefix anstelle des eigentlichen Keys.
Hier ist der entscheidende Punkt. Anstatt einen echten Key-String einzutippen, schreibst du die Phrase os dot environ forward slash, direkt gefolgt vom exakten Namen deines Secrets, wie es im Vault existiert.
Gehen wir mal ein konkretes Szenario durch. Du willst Traffic zu einem Azure-Model routen, und der echte API-Key ist sicher im AWS Secrets Manager unter dem Namen azure api key production gespeichert. In deiner Config-Datei richtest du den Model-Routing-Block ein. Aber für das API-Key-Feld setzt du den Value auf os dot environ forward slash azure api key production.
Wenn das Gateway einen Request für dieses Model verarbeitet, sieht es das Prefix. Es weiß, dass es diesen String nicht als literalen Key verwenden soll. Stattdessen macht es einen sicheren Call an den AWS Secrets Manager, fragt den Value für genau diesen Secret-Namen an und holt sich den echten Key, um den Request zu authentifizieren. Der Plaintext-Key berührt niemals deine Disk. Deine Config-Datei bleibt komplett sauber und kann sicher in die Version Control committet werden.
Damit haben wir das Pullen von Upstream-Credentials in das Gateway abgedeckt. Aber die Secret-Manager-Integration geht in beide Richtungen. Sie kann auch Daten schreiben. Wenn du das Gateway nutzt, um neue Virtual Proxy Keys für deine internen Engineering-Teams zu generieren, kannst du das System so konfigurieren, dass diese neu generierten Keys automatisch direkt in deinem Secret Manager gespeichert werden. Das stellt sicher, dass die internen Credentials, die du ausstellst, mit exakt denselben Security Controls gespeichert und gemanagt werden wie die Provider-Credentials, die du konsumierst.
Deine Config-Dateien definieren die Struktur deiner Routing-Infrastructure, aber sie sollten niemals ihre Secrets enthalten. Der sicherste Ort, um einen API-Key in deiner Gateway-Config zu speichern, ist überhaupt nirgendwo.
Danke fürs Zuhören, Happy Coding zusammen!
6
Model Aliases: Das Schatten-Upgrade
4m 26sMigrieren Sie Nutzer geräuschlos auf neue Modelle. Entdecken Sie, wie Sie Model Aliases in LiteLLM verwenden, um Anfragen für ein Modell auf einen völlig anderen Endpunkt umzuleiten, ohne den clientseitigen Code zu ändern.
Hallo, hier ist Alex von DEV STORIES DOT EU. LiteLLM: Das universelle LLM-Gateway, Folge 6 von 24. Was wäre, wenn du deine gesamte Userbase von OpenAI zu Anthropic migrieren könntest, ohne dass sie auch nur eine einzige Zeile ihres Integration Codes updaten müssen? Oder einen Free-Tier User unbemerkt auf eine Open-Source-Alternative umstellen könntest, ohne seine bestehende Application Logic zu breaken? Der Mechanismus, der diese stille Transition möglich macht, heißt Model Aliases.
Man kann Aliases leicht mit Routing verwechseln, also lass uns die beiden mal voneinander trennen. Routing übernimmt das Load Balancing über mehrere Deployments des exakt gleichen Models. Wenn du drei separate Azure OpenAI-Instanzen hast, auf denen dieselbe Version von GPT-4 läuft, verteilt das Routing den eingehenden Traffic gleichmäßig auf sie, um Rate Limits zu verhindern. Aliases machen etwas völlig anderes. Ein Alias fängt einen angefragten Model Name ab und mappt ihn auf ein komplett anderes Model hinter dem Proxy.
Du wendest dieses Mapping in dem Moment an, in dem du einen Virtual Key für einen Client erstellst. Wenn du deinen Request an den LiteLLM Key Generation Endpoint sendest, packst du ein Aliases Object in deinen Payload. Dieses Objekt ist einfach ein Dictionary, das den Model Name, nach dem der Client fragt, mit dem Model Name matcht, den du eigentlich serven willst.
Lass uns ein konkretes Szenario anschauen. Du hast ein Segment von Free-Tier Usern. Sie haben ihre Tools ursprünglich um GPT-4 herum gebaut, und genau dieser String ist aktuell in ihren Network Requests hardcoded. GPT-4 an nicht-zahlende User zu serven ist teuer, also entscheidest du dich, ihre Prompts an einen internen, hochoptimierten Mistral 7B Endpoint umzuleiten.
Um das zu erreichen, generierst du einen neuen Virtual Key speziell für diese User-Gruppe. Im Generation Payload definierst du einen Alias, der den String GPT-4 direkt auf deinen Mistral 7B Deployment Name mappt. Du gibst diesen neuen Virtual Key an die User. Sie ändern ihren Application Code nicht. Sie senden weiterhin Standard Chat Completion Requests an deinen Proxy und fragen explizit nach GPT-4.
Hier ist der entscheidende Punkt. Der LiteLLM-Proxy empfängt den eingehenden Request und authentifiziert den Virtual Key. Er liest die Configuration, die an diesen spezifischen Key gebunden ist, und entdeckt deine Alias Rule. Bevor er den Payload an einen externen Provider routet, schreibt der Proxy den Model Parameter in Memory um. Er entfernt GPT-4 und ersetzt es durch Mistral 7B. Der Request geht an dein internes Mistral Deployment, generiert den Text und routet die Response durch den Proxy zurück an den Client.
Die Client Application erhält das Standard Response Format, das sie erwartet. Ihre Parser funktionieren perfekt, und die Application läuft ganz normal weiter. Die Entwickler, die diese Client Application maintainen, bekommen überhaupt nicht mit, dass das zugrundeliegende Language Model geswappt wurde.
Weil Aliases direkt an einzelne Virtual Keys und nicht an die globale Server Configuration gebunden sind, behältst du die absolute Kontrolle über verschiedene User-Segmente. Ein Key kann Traffic für Free Users auf ein günstigeres Model aliasen, während ein anderer Key Premium Traffic unverändert durchlässt. Du kannst genau dieselbe Logik auch nutzen, um Model Deprecations zu handlen. Wenn ein Provider ein älteres Model retired, aliast du einfach den alten Namen auf die neue Version und ersparst all deinen Clients, Emergency Code Updates pushen zu müssen. Der mächtigste Aspekt eines Model Gateways ist nicht nur das Managen von Network Traffic, sondern das Entkoppeln der Erwartungen des Clients von der physischen Realität deiner Backend Architecture.
Danke fürs Zuhören, Happy Coding zusammen!
7
Load Balancing für hohen Durchsatz
3m 49sVermeiden Sie Rate Limits und Ausfallzeiten durch intelligentes Routing des Traffics. Erfahren Sie, warum simple-shuffle die empfohlene Strategie für das Load Balancing in der Produktion über mehrere Deployments hinweg ist.
Hallo, hier ist Alex von DEV STORIES DOT EU. LiteLLM: Das Universal LLM Gateway, Folge 7 von 24. Du hast endlich Production Access zu Azure OpenAI bekommen, deine App gestartet und bist beim ersten großen Traffic Spike sofort auf einen massiven Rate Limit Error gestoßen. Du hast zwar die Quota, aber der Bottleneck liegt in einer einzigen Region. Load Balancing für High Throughput löst dieses Problem. Um große Request-Volumen ohne Limitüberschreitungen zu bewältigen, musst du deinen Traffic auf mehrere identische Deployments verteilen. In LiteLLM konfigurierst du dafür einen Router. Du gruppierst mehrere Backend Endpoints unter einem einzigen logischen Model Name. Angenommen, du hast eine Application, hinter der fünf Azure Deployments stehen, die über fünf verschiedene geografische Regionen verteilt sind. Wenn deine App nach einer Completion fragt, entscheidet der Router, welche dieser fünf Regionen den Request bekommt. Du steuerst diese Entscheidungslogik, indem du in deinen Router Settings eine Routing Strategy festlegst. Der intuitive Ansatz ist Usage-based Routing, bei dem das System den Request an das Deployment mit dem aktuell geringsten Traffic sendet. Das erfordert aber das Tracking der genauen Token Usage in Echtzeit. Real-time State Tracking bedeutet, für jeden einzelnen Request einen Network Call an einen Cache wie Redis zu machen, noch bevor der Prompt überhaupt rausgeht. Das fügt deiner App eine permanente Latency Tax hinzu. In High Throughput Production Environments willst du diesen extra Hop vermeiden. Der empfohlene Ansatz ist eine Strategy namens simple-shuffle. simple-shuffle trackt keinen Live State. Es wählt zufällig einen Endpoint aus deinem Pool basierend auf vordefinierten Weights aus. Wenn du deine fünf Azure Deployments zu deinem Configuration File hinzufügst, weist du jedem ein Limit zu, normalerweise Requests Per Minute, oder RPM. Du kannst auch Tokens Per Minute, oder TPM, verwenden. Wenn deine primäre Region ein RPM Limit von zehntausend hat und eine sekundäre Region ein RPM Limit von fünftausend, liest simple-shuffle diese Zahlen und behandelt sie als Weights. Es routet automatisch doppelt so viel Traffic in die primäre Region. Under the hood nimmt der Router die Liste der verfügbaren Deployments für dieses Model, bezieht ihre RPM Weights mit ein und shuffelt sie in eine randomisierte Liste für diesen spezifischen Request. Er probiert das erste Deployment auf der Liste. Weil die Randomisierung die von dir konfigurierten RPM Limits strikt respektiert, verteilt sich dein Traffic im Laufe der Zeit perfekt über alle fünf Regionen und weicht den Rate Limits aus, ohne den Overhead von Real-time Monitoring. Um das aufzusetzen, öffnest du dein Configuration File und setzt den Routing Strategy Parameter auf simple-shuffle. Dann definierst du in deiner Model List deine fünf Azure Endpoints. Du gibst ihnen allen exakt denselben Model Name. Zum Schluss hängst du den RPM Parameter mit deinem gewünschten Weight an jede Endpoint Definition an. Wenn deine Application den Router mit diesem Model Name aufruft, übernimmt der Router die Mathematik und die Randomisierung automatisch. Du bekommst die Vorteile einer Distributed Architecture, ohne eine Redis Dependency zu brauchen. Der beste Weg, um Massive Scale zu handlen, ist oft, perfektes Real-time Tracking gegen stateless, statistisch vorhersagbare Randomisierung einzutauschen. Danke fürs Zuhören, Happy Coding zusammen!
8
API-Ausfälle und Fallbacks
3m 59sErleben Sie nie wieder eine AI-Downtime. Erfahren Sie, wie Sie Model Fallbacks in LiteLLM so konfigurieren, dass der Traffic bei einem Ausfall Ihres primären Providers automatisch auf einen Backup-Provider umgeleitet wird.
Hallo, hier ist Alex von DEV STORIES DOT EU. LiteLLM: Das universelle LLM-Gateway, Folge 8 von 24. Wenn dein primärer Language Model Provider einen Outage hat, geht deine Application dann mit down, oder wechselt sie unbemerkt zu einem Backup? Heute geht es um API Outages und Fallbacks – genau den Mechanismus, der dein System online hält, wenn externe Endpoints ausfallen.
Zuerst hilft es, das von einem verwandten Konzept zu unterscheiden. Fallbacks sind kein Load Balancing. Load Balancing verteilt deinen Traffic proaktiv auf mehrere aktive Deployments, um zu verhindern, dass ein einzelner Endpoint überlastet wird. Fallbacks hingegen sind rein reaktive Rettungsmechanismen. Sie bleiben im Normalbetrieb idle und greifen erst ein, wenn ein definitiver Fehler aufgetreten ist.
Das primäre Ziel ist es, eine hohe Uptime aufrechtzuerhalten, idealerweise diese 99,9-Prozent-Marke zu knacken, selbst wenn deine Upstream-Provider das nicht schaffen. Externe APIs werden unweigerlich 500 Internal Server Errors oder 429 Rate Limit Exceptions werfen. Wenn das passiert, sagt eine Fallback-Konfiguration dem Proxy, dass er den Error mid-flight abfangen und den Request an einen alternativen Provider routen soll. Das schirmt deinen Application Code komplett vor der Störung ab.
Du richtest das in deiner Proxy-Konfigurations-YAML-Datei mit einem Fallbacks-Array ein. Schauen wir uns ein konkretes Szenario an. Dein primäres Deployment ist gpt-4. Du willst sicherstellen, dass der Proxy automatisch claude-3-opus probiert, falls gpt-4 offline geht.
In deiner Konfigurationsdatei definierst du dein gpt-4 Model-Setup wie gewohnt. Innerhalb dieser spezifischen Model-Definition fügst du einen Fallbacks-Key hinzu. Der Wert dieses Keys ist einfach ein Array von Strings, wobei jeder String der Name eines anderen Models ist, das in deiner Konfiguration definiert ist. Du fügst claude-3-opus zu diesem Array hinzu.
Wenn deine Application einen Prompt an den Proxy sendet und gpt-4 anfragt, routet LiteLLM ihn an den primären Endpoint. Wenn dieser Endpoint einen Error zurückgibt, fängt die Proxy-Logik ihn ab. Wenn du Retries konfiguriert hast, probiert er den primären Endpoint vielleicht noch ein paar Mal. Aber sobald der primäre Endpoint definitiv fehlschlägt, triggert der Proxy die Fallback-Sequenz.
Hier wird es interessant. Der Proxy nimmt den exakten originalen Prompt und die Parameter. Weil LiteLLM das API-Format normalisiert, übersetzt es den OpenAI-formatierten Request nahtlos in das Anthropic-Format, das von Claude benötigt wird. Es sendet den übersetzten Request sofort an den Backup-Endpoint. Dein Application Code muss sich um keine Error-Logik kümmern, den Prompt nicht umschreiben und keine API-Keys für den zweiten Provider managen. Der Proxy übernimmt den kompletten Pivot intern.
Du bist nicht auf ein einzelnes Backup beschränkt. Das Fallbacks-Array akzeptiert eine Liste von Models. Wenn dein primäres gpt-4 fehlschlägt und dann auch dein erster Fallback claude-3-opus fehlschlägt, geht der Proxy zum nächsten Namen im Array über. Er geht die Liste sequenziell durch. Wenn er das Ende des Arrays erreicht und jedes einzelne Backup-Model fehlschlägt, erst dann gibt der Proxy einen Error an deine Client-Application zurück.
Hier ist der entscheidende Punkt. Indem du diverse Fallback-Models in deiner Konfiguration staffelst, isolierst du deinen Application Code effektiv vor externer Instabilität und verwandelst harte Provider Outages in nichts weiter als unsichtbare Latency Spikes für deine End User.
Danke fürs Zuhören, Happy Coding zusammen!
9
Context Window Fallbacks
3m 25sHören Sie auf, für riesige Context Windows bei kurzen Prompts zu viel zu bezahlen. Erfahren Sie, wie Sie Pre-Call-Checks und Context Window Fallbacks nutzen, um überdimensionierte Dokumente an spezialisierte Modelle weiterzuleiten.
Hallo, hier ist Alex von DEV STORIES DOT EU. LiteLLM: Das universelle LLM-Gateway, Folge 9 von 24. Ein teures 128k Context Model für jede einzelne User Query zu verwenden, ist eine massive Geldverschwendung. Wenn du stattdessen standardmäßig ein günstigeres, kleineres Model verwendest, wird ein User, der ein riesiges PDF hochlädt, deine Application sofort zum Absturz bringen. Der Mechanismus, der dieses Problem löst, nennt sich Context Window Fallbacks.
Du denkst vielleicht, dass Fallback Routing erst passiert, nachdem eine Provider API einen Failure Code zurückgibt. Das stimmt zwar für allgemeine Reliability Fallbacks, aber Context Limits funktionieren anders. LiteLLM kann Prompt Größen proaktiv handhaben, und zwar mit einem Setting namens enable pre-call checks. Wenn du diesen Boolean in deiner Router Configuration auf true setzt, stoppt der Proxy den Request und berechnet den genauen Token Count des Prompts, bevor der Provider ihn überhaupt sieht.
Hier ist der entscheidende Punkt. Du konfigurierst ein Primary Model, zum Beispiel ein sehr kostengünstiges Model, und definierst im selben Configuration Block eine Context Window Fallbacks Liste, die auf ein deutlich größeres Model zeigt. Wenn ein neuer Request reinkommt, wird der Pre-Call Check ausgeführt. Wenn der berechnete Token Count in das Limit des Primary Models passt, läuft der Request ganz normal weiter. Ist der Prompt zu groß, droppt LiteLLM die Primary Route komplett. Es leitet den Request sofort an das größere Fallback Model weiter.
Das bedeutet, du bekommst niemals einen Context Length Error von der Upstream API. Es bedeutet auch, dass du die Latency Penalty vermeidest, die entsteht, wenn du darauf wartest, dass ein Provider den initialen Payload ablehnt. Die Application, die den Request macht, hat keine Ahnung, dass sich das Routing im Hintergrund geändert hat.
LiteLLM verlässt sich auf seine interne Model Registry, um die genauen Context Limits für verschiedene Provider zu kennen. Vielleicht möchtest du aber strengere Limits erzwingen. Vielleicht willst du das Fallback früher triggern, um mehr Platz für generierte Output Tokens zu lassen, oder vielleicht routest du auf ein Custom Deployment mit einer Non-Standard Memory Allocation. Das machst du, indem du den max input tokens Parameter direkt in deiner Model Configuration überschreibst. Wenn du diesen Wert angibst, zwingst du den Proxy, dein Custom Limit zu verwenden, wenn er den Pre-Call Check auswertet.
Denk mal an ganz normalen Application Traffic. Ein User stellt eine einfache Textfrage. Der Proxy zählt fünfzig Tokens, validiert, dass es passt, und routet es an GPT-3.5. Ein paar Minuten später lädt derselbe User ein riesiges PDF mit achtzigtausend Tokens hoch. Der Proxy berechnet die neue Größe, sieht, dass sie das GPT-3.5 Limit überschreitet, und redirectet es automatisch strikt an GPT-4-128k. Deine Application Logic bleibt dabei komplett statisch. Du zahlst nur für das Premium Model, wenn der Payload es tatsächlich erfordert.
Die Token Validation aus deinem Application Code in den Proxy Layer zu verschieben, verwandelt deine Fallback Strategy von einem passiven Sicherheitsnetz in eine aktive Cost Optimization Engine.
Danke fürs Zuhören, happy coding zusammen!
10
Hängende Requests mit Timeouts bändigen
4m 19sLassen Sie nicht zu, dass langsame APIs Ihre Anwendung einfrieren. Entdecken Sie, wie Sie globale Timeouts und Stream Timeouts in LiteLLM konfigurieren, um blockierte Requests abzubrechen und schnelle Fallbacks auszulösen.
Hallo, hier ist Alex von DEV STORIES DOT EU. LiteLLM: Das universelle LLM-Gateway, Folge 10 von 24. Nichts ist für die User Experience schlimmer als ein Chatbot, der 45 Sekunden lang einen Loading Spinner anzeigt, nur weil eine Upstream-API stillschweigend hängen geblieben ist. Du brauchst einen zuverlässigen Weg, um tote Verbindungen sofort zu kappen, damit sich dein System erholen kann. Wir lösen das, indem wir hängende Requests mit Timeouts bändigen.
Wenn du Traffic an externe Language Models routest, sind Netzwerkverzögerungen und Provider-Ausfälle unvermeidlich. Wenn ein Provider nicht mehr antwortet, ist das Default-Verhalten vieler HTTP-Clients, die Verbindung lange offen zu halten. LiteLLM fängt dieses Problem mit zwei verschiedenen Timeout-Mechanismen ab. Der erste ist der Standard-Timeout-Parameter. Diese Einstellung legt die maximale Gesamtzeit fest, die LiteLLM wartet, bis ein kompletter Request abgeschlossen ist – vom Absenden bis zum letzten generierten Zeichen.
Wenn du ein Standard-Timeout von 30 Sekunden setzt und das Model 31 Sekunden braucht, um eine lange Response zu schreiben, bricht LiteLLM den Request ab. Das funktioniert super für Background Tasks oder kurze, Non-Streaming Generations. Wenn du aber ein totales Timeout auf eine Streaming-Applikation anwendest, entsteht ein strukturelles Problem. Eine ausführliche Response kann durchaus 60 Sekunden brauchen, bis sie komplett zum User gestreamt ist. Wenn du ein kurzes Gesamt-Timeout setzt, um hängende Requests abzufangen, killst du aus Versehen völlig gesunde, lang laufende Generations.
Hier wird es interessant. LiteLLM bietet einen zweiten Parameter namens Stream Timeout. Diese Einstellung misst gezielt die Zeit bis zum ersten Token. Sie steuert genau, wie lange das Gateway wartet, um den ersten Chunk an Daten vom Provider zu empfangen. Sobald dieser erste Chunk ankommt, stoppt die Stream-Timeout-Uhr, und die Verbindung bleibt für den Rest der Generation offen.
Stell dir ein konkretes Szenario vor. Du routest Traffic an einen primären Azure OpenAI Endpoint. In deinem Config File definierst du deinen Model-Block und fügst den Stream-Timeout-Parameter hinzu, den du auf zwei Sekunden setzt. Ein User schickt einen komplexen Prompt ab. LiteLLM leitet diesen Request an Azure weiter. Normalerweise verarbeitet der Upstream-Server den Prompt und liefert den ersten Chunk in Sekundenbruchteilen zurück. Aber in diesem Fall hängt sich die spezifische Azure Node auf.
Das Gateway fängt an zu zählen. Eine Sekunde vergeht. Zwei Sekunden vergehen. Der erste Chunk kommt nicht an. Weil du ein Stream Timeout von zwei Sekunden definiert hast, weigert sich LiteLLM, auf das Auslösen des Standard-HTTP-Timeouts zu warten. Es bricht die Verbindung genau an der Zwei-Sekunden-Marke rigoros ab.
Den toten Request abzubrechen, ist nur der halbe architektonische Vorteil. Durch das Erzwingen eines schnellen Fails aktiviert LiteLLM sofort deine Fallback-Logik. In dem Moment, in dem der Azure-Request ins Timeout läuft, routet das Gateway exakt denselben User Prompt an die nächste verfügbare, gesunde Node in deiner Deployment-Liste. Der User erlebt eine kaum spürbare Verzögerung von zwei Sekunden, bevor der Text zu streamen beginnt, und ein eingefrorenes Interface wird komplett vermieden.
Du hast die Flexibilität, diese Regeln auf verschiedenen Ebenen durchzusetzen. Du kannst ein globales Timeout für alle gerouteten Requests anwenden, oder du kannst sie pro Model feintunen. Ein schweres Logical Reasoning Model braucht vielleicht ein großzügiges Stream Timeout von fünf oder zehn Sekunden, während ein schnelles Classification Model schon nach einer Sekunde einen Failover machen sollte.
Die Responsiveness deiner Applikation wird nicht nur davon bestimmt, wie schnell dein primärer Provider erfolgreich ist, sondern auch davon, wie aggressiv du eine hängende Verbindung zum Fail zwingst. Danke fürs Zuhören, Happy Coding zusammen!
11
Virtual Keys für FinOps
4m 20sSichern Sie Ihre API-Nutzung präzise ab. Erfahren Sie, wie Sie mit LiteLLM Virtual Keys generieren und strenge RPM-, TPM- und Budget-Limits festlegen, um Ihre Organisation vor ausufernden AI-Kosten zu schützen.
Hallo, hier ist Alex von DEV STORIES DOT EU. LiteLLM: Das universelle LLM-Gateway, Folge 11 von 24. Ein fehlerhaftes Script von einem Junior Developer kann über Nacht schnell eine OpenAI-Rechnung von zehntausend Dollar verursachen. Die zugrunde liegende Provider-Plattform akzeptiert Requests so schnell, wie die Loop sie abfeuern kann. Virtual Keys für FinOps sind der Weg, wie du das verhinderst, bevor es passiert.
Es gibt oft Verwirrung zwischen Master Keys und Virtual Keys. Du darfst deinen Master Key niemals an einen Entwickler weitergeben. Der Master Key ist dein administratives Credential. Sein Hauptzweck ist die Authentifizierung deiner Plattform, um Virtual Keys zu erstellen. Virtual Keys sind die eingeschränkten Credentials, die du tatsächlich an Entwickler oder Applications rausgibst, damit sie diese in ihrem Code verwenden.
Du erstellst ein neues Credential, indem du einen HTTP POST Request an den Key Generate Endpoint auf deinem LiteLLM Proxy machst. Du autorisierst diesen Request mit deinem Master Key als Bearer Token. Im Body von diesem Request definierst du die finanziellen Guardrails.
Stell dir ein Szenario vor, in dem du den Access für einen Sommerpraktikanten einrichtest. Du willst sicherstellen, dass er genug Access hat, um einen Prototyp zu bauen, aber du brauchst die absolute Garantie, dass er nicht dein Infrastruktur-Budget verbrennt. Um das durchzusetzen, übergibst du zwei spezifische Parameter in deinem JSON Payload.
Erstens definierst du das finanzielle Limit, indem du den max budget Parameter setzt. Wenn du diesen Wert auf zehn setzt, weist du diesem spezifischen Key genau zehn US-Dollar zu. Das ist ein hartes Lifetime Limit. Sobald die Gesamtkosten aller Prompts und Completions, die an diesen Key gebunden sind, zehn Dollar erreichen, wird der Key automatisch deaktiviert und lehnt alle weiteren Requests ab.
Zweitens kontrollierst du die Geschwindigkeit dieser Requests, indem du den RPM limit Parameter setzt. RPM steht für Requests per Minute. Wenn du das RPM Limit auf eins setzt, erzwingt der Proxy strikt ein Fenster von einem Request pro sechzig Sekunden. Wenn eine versehentliche Infinite Loop im Code des Praktikanten versucht, hundert Requests sofort abzufeuern, verarbeitet der Proxy den ersten und lehnt die restlichen neunundneunzig sofort mit einem Standard Rate Limit Error ab.
Wenn du diesen Payload an den Generate Endpoint sendest, verarbeitet LiteLLM die Regeln und gibt eine Response zurück, die den neu generierten Virtual Key enthält. Dieser Key sieht identisch aus wie ein Standard Provider Credential und beginnt typischerweise mit einem sk Prefix. Diesen String gibst du dem Praktikanten.
Hier ist der entscheidende Punkt. Der Entwickler nutzt diesen Virtual Key genau wie einen OpenAI oder Anthropic Key, und lässt seine Standard Client Library auf deine LiteLLM Proxy URL zeigen, anstatt auf das öffentliche Internet. Wenn ein Request ankommt, fängt der Proxy ihn ab. Er fragt seine interne Database ab, um zu verifizieren, dass der Virtual Key existiert. Dann prüft er, ob der Key sein Zehn-Dollar-Budget oder sein Velocity Limit von einem Request per Minute überschritten hat.
Wenn der Request beide Checks besteht, tauscht der Proxy den Virtual Key gegen deinen tatsächlichen Corporate API Key aus und leitet den Payload an den Provider weiter. Wenn der Provider antwortet, berechnet der Proxy die genauen Kosten der Prompt und Completion Tokens basierend auf dem veröffentlichten Pricing von diesem spezifischen Model. Er zieht diesen Bruchteil eines Cents vom Zehn-Dollar-Budget des Virtual Keys ab, speichert die Transaction und sendet die Response zurück an den Entwickler. Der Entwickler bekommt von dem zugrunde liegenden Credential Swap oder dem internen Accounting absolut nichts mit.
Indem Limits auf dem Proxy Layer erzwungen werden, fangen Virtual Keys unautorisierte oder Runaway Requests ab, bevor sie jemals den Billing Provider erreichen. Das garantiert mathematisch, dass ein kompromittiertes oder schlecht geschriebenes Script sein zugewiesenes Budget niemals überschreiten kann.
Danke fürs Zuhören, Happy Coding zusammen!
12
Spend Tracking und Custom Tags
4m 04sOrdnen Sie jeden Cent der LLM-Ausgaben genau zu. Erfahren Sie, wie Sie Metadaten-Tags in Ihren Requests übergeben und umfassende Spend-Reports mit LiteLLM erstellen.
Hallo, hier ist Alex von DEV STORIES DOT EU. LiteLLM: Das universelle LLM-Gateway, Folge 12 von 24. Dein CFO kommt gerade rein und fragt genau, welches neue Product Feature das monatliche AI-Budget verbrennt. Du rufst dein Provider-Dashboard auf, aber alles, was du siehst, ist eine einzige riesige Gesamtrechnung für das ganze Unternehmen. Du hast keine Antwort. Spend Tracking und Custom Tags in LiteLLM beheben diesen blinden Fleck.
Wenn du Requests über LiteLLM routest, berechnet der Proxy automatisch die Kosten für jede Completion basierend auf dem spezifischen Model und dem Token Count. Ein Gesamtbetrag in Dollar ist nutzlos, wenn du ihn nicht einer bestimmten Quelle zuordnen kannst. Der einfachste Weg, diesen Spend zu gruppieren, ist über den Standard User Parameter in deinem Chat Completion Call. Du übergibst einen eindeutigen String, der deinen Endkunden repräsentiert. LiteLLM fängt das ab, berechnet die Kosten und loggt sie unter dieser spezifischen User-ID.
Das Tracking nach User löst zwar ein Problem, aber oft triggert ein einzelner User mehrere Backend-Prozesse. Angenommen, du hast einen Document Classification Workload, und die Abrechnungsabteilung braucht einen Report, der den Spend nach bestimmten Background Jobs gruppiert. Eine User-ID hilft hier nicht weiter. Hier kommen Custom Tags ins Spiel. LiteLLM erlaubt es dir, an jeden Request ein Array von Strings anzuhängen, und es trackt den Spend genau für diese Strings.
Hier ist die entscheidende Erkenntnis. Standard-Libraries wie das offizielle OpenAI SDK oder LangChain kennen LiteLLM-Metadata nicht nativ. Wenn du versuchst, einen unbekannten Parameter namens metadata zu übergeben, wird das SDK ihn entfernen oder einen Error werfen, bevor der Request überhaupt den Proxy erreicht. Um das zu umgehen, nutzt du einen Parameter namens extra body. Das ist eine Standard-Escape-Hatch, die in moderne SDKs eingebaut ist, speziell um Custom Fields zu injizieren.
Gehen wir das mal an einem LangChain Request durch. Du konfigurierst dein Standard Chat Model Object. Wenn du die invoke Methode aufrufst, übergibst du deinen Prompt wie gewohnt. Zusammen mit dem Prompt übergibst du einen Parameter namens extra body. Diesen setzt du auf ein Dictionary. Innerhalb dieses Dictionarys erstellst du einen Key namens metadata. Innerhalb von metadata fügst du einen Key namens tags hinzu, der auf ein Array von Strings zeigt. Du könntest zum Beispiel einen String wie job ID vier null zwei übergeben. LangChain verpackt diesen extra body genau so, wie er ist, und sendet ihn übers Netzwerk. LiteLLM empfängt den Payload, extrahiert deine Tags aus dem metadata Block und hängt die genauen Kosten dieses LLM Calls an die job ID vier null zwei an.
Das deckt die Inputs ab. Was ist mit den Outputs? Sobald dein Traffic mit diesen Tags fließt, musst du die Daten abrufen. Das machst du, indem du den global spend report Endpoint auf deinem LiteLLM Proxy abfragst. Du machst einen Standard HTTP GET Request an diesen Endpoint. Der Proxy gibt einen JSON Payload zurück, der genau detailliert, wohin das Geld geflossen ist. Er gruppiert deinen gesamten Spend nach API Key, nach User und, ganz wichtig, nach jedem Custom Tag, den du übergeben hast. Du kannst das direkt an deine Abrechnungsabteilung weitergeben. Sie können sofort sehen, dass der Document Classification Job genau vier Dollar und zwanzig Cent gekostet hat, unabhängig davon, welches zugrundeliegende Model das eigentliche Routing übernommen hat.
Deinen Traffic auf Proxy-Ebene zu taggen bedeutet, dass deine Billing-Granularität nicht mehr davon diktiert wird, wie dein Cloud Provider seine Rechnungen strukturiert; sie wird komplett durch den Kontext deiner eigenen Application definiert.
Danke fürs Zuhören, Happy Coding zusammen!
13
Caching für Geschwindigkeit und Einsparungen
3m 45sHören Sie auf, immer wieder für dieselben LLM-Antworten zu bezahlen. Erfahren Sie, wie Sie Exact Caching mit Redis und Semantic Caching mit Qdrant konfigurieren, um Latenzzeiten und API-Kosten drastisch zu senken.
Hallo, hier ist Alex von DEV STORIES DOT EU. LiteLLM: Das universelle LLM-Gateway, Folge 13 von 24. Warum solltest du eine externe API bezahlen, um tausendmal dieselbe grundlegende Erklärung zu generieren? Du verbrennst Credits und zwingst User, auf Berechnungen zu warten, die schon längst gemacht wurden. Diese Ineffizienz zu beheben, ist der Kern von Caching für Speed und Ersparnisse.
LiteLLM übernimmt das Caching komplett auf Proxy-Ebene. Wenn ein Request reinkommt, checkt der Proxy, ob er genau diesen Prompt schon mal gesehen hat. Wenn ja, gibt er die gespeicherte Response sofort zurück. Die Latenz sinkt von Sekunden auf Millisekunden, und die API-Kosten fallen auf null. Um das aufzusetzen, nutzt du deine config dot yaml Datei. Du aktivierst Caching in deinem globalen Settings-Block, indem du cache auf true setzt und deinen Cache-Typ angibst. Redis ist das Standard-Backend für Exact-Match-Caching. Du gibst deinen Redis-Host, Port und dein Passwort an, und der Proxy kümmert sich um das Speichern der Input-Output-Paare.
Aber Exact-Caching ist fragil. Es sucht nach einem perfekten String-Match. Wenn ein User fragt, schreibe ein Gedicht über LiteLLM, und ein anderer User fragt, erstelle ein LiteLLM-Gedicht, sieht ein Exact-Cache zwei völlig unterschiedliche Requests. Er leitet den zweiten Request an das rechenintensive Language Model weiter und verschwendet Zeit und Geld für eine redundante Aufgabe, nur weil sich die Formulierung leicht geändert hat.
Hier kommt Semantic Caching ins Spiel. Anstatt rohe Text-Strings zu vergleichen, vergleicht Semantic Caching die zugrundeliegende Bedeutung der Prompts. LiteLLM unterstützt Qdrant, eine Vektor-Datenbank, um das zu handhaben. Wenn du Semantic Caching konfigurierst, musst du neben deinem Haupt-Generation-Model auch ein Embedding-Model angeben. Wenn ein Request reinkommt, übergibt der Proxy den Prompt zuerst an das Embedding-Model. Dieses Model wandelt den Text in einen Vektor um, was eine mathematische Repräsentation der Bedeutung des Prompts ist.
Danach fragt der Proxy Qdrant ab, um zu sehen, ob ein ähnlicher Vektor bereits im Cache existiert. Weil schreibe ein Gedicht und erstelle ein Gedicht denselben semantischen Intent teilen, liegen ihre Vektoren im Raum nah beieinander. Qdrant erkennt diese Ähnlichkeit. Wenn der Match nah genug ist, zieht der Proxy die gecachte Response vom ersten User und liefert sie an den zweiten User aus. Du überspringst den aufwendigen Text-Generation-Schritt komplett und zahlst nur einen Bruchteil eines Cents für den schnellen Embedding-Lookup.
Das zu konfigurieren, erfordert ein paar zusätzliche Zeilen in deiner config dot yaml. Du änderst den Cache-Typ auf qdrant semantic. Du definierst Qdrant-spezifische Parameter, wie die Qdrant Endpoint-URL und deinen API-Key. Am wichtigsten ist, dass du einen Similarity Threshold definierst. Das ist ein Dezimalwert zwischen null und eins. Ein hoher Threshold, wie null Komma neun neun, erfordert nahezu identische Formulierungen. Ein niedrigerer Threshold, wie null Komma acht, erfasst breitere Variationen, erhöht aber das Risiko, eine veraltete oder leicht themenfremde Response zurückzugeben, wenn zwei Prompts ähnlich klingen, aber unterschiedliche Intents haben.
Hier ist die wichtigste Erkenntnis. Semantic Caching ist nicht nur ein Speichermechanismus, es ist ein aktiver Filter für den User-Intent. Deinen Similarity Threshold zu tunen, ist das Einzige, was zwischen einer massiven Kostenreduzierung und der Auslieferung irrelevanter Antworten an deine User steht.
Danke fürs Zuhören, Happy Coding zusammen!
14
RBAC: Team Admins befähigen
3m 33sVerteilen Sie das Plattform-Management sicher. Verstehen Sie die Role-Based Access Control von LiteLLM, mit der Sie Befugnisse an Org Admins und Team Admins delegieren können, ohne die globale Sicherheit zu gefährden.
Hallo, hier ist Alex von DEV STORIES DOT EU. LiteLLM: Das universelle LLM Gateway, Folge 14 von 24. Du bist Platform Engineer und verbringst die Hälfte deines Tages damit, Nachrichten zu beantworten, in denen nach neuen API Keys oder Budgeterhöhungen gefragt wird. Jedes Developer Onboarding wird zu einem IT-Ticket, das deren Arbeit blockiert und deine Zeit verschwendet. Die Lösung ist, die Kontrolle zu delegieren, ohne die Übersicht zu verlieren, und zwar mit Role-Based Access Control.
LiteLLM unterstützt vier spezifische User Roles, um diese Delegierung zu managen. Das sind der Proxy Admin, der Org Admin, der Team Admin und der Internal User. Der Proxy Admin steht ganz oben. Wenn du LiteLLM deployst, bist du der Proxy Admin. Du konfigurierst die Modelle, richtest die Datenbank ein und legst die globalen Regeln fest. Aber du solltest dich nicht um die täglichen Key-Anfragen kümmern müssen. Genau hier kommt die Hierarchie ins Spiel.
Du kannst dein Unternehmen in Organizations unterteilen, die riesige Abteilungen repräsentieren, und in Teams, die spezifische Arbeitsgruppen innerhalb dieser Abteilungen sind. Der Org Admin kann Teams innerhalb seiner spezifischen Organization managen. Aber die wahre operative Macht liegt beim Team Admin.
Hier ist die entscheidende Erkenntnis. Du kannst alle lokalen administrativen Aufgaben an einen Abteilungsleiter abgeben, indem du ihn zum Team Admin machst. Als Proxy Admin richtest du die anfängliche Struktur ein einziges Mal ein. Du erstellst ein Team, setzt ein hartes Budgetlimit von fünfhundert Dollar im Monat und weist dem Lead Developer die Rolle als Team Admin zu. Danach bist du komplett raus aus der Sache.
Der Team Admin hat nun die Autonomie, seine eigenen Engineers zu managen. Er kann sich in die UI einloggen oder die API nutzen, um neue User zu seinem Team hinzuzufügen. Er kann neue API Keys für diese Developer generieren und die Gesamtausgaben seiner spezifischen Gruppe überwachen. Ganz wichtig: Jeder Key, der vom Team Admin oder seinen Engineers erstellt wird, ist automatisch an dieses Teambudget von fünfhundert Dollar gebunden. Der Team Admin hat die volle lokale Kontrolle, aber er kann keinen einzigen Cent über das Limit hinaus ausgeben, das der Proxy Admin erzwungen hat.
Unter dem Team Admin steht der Internal User. Das ist die Rolle, die den Standard-Developern zugewiesen wird, die den Code schreiben. Ein Internal User hat eingeschränkten Zugriff. Er kann seinen eigenen Token Spend einsehen und, wenn der Team Admin es erlaubt, seine eigenen persönlichen API Keys generieren. Seine Sicht auf das System ist streng auf ihn selbst beschränkt. Er kann das restliche Teambudget nicht sehen, er kann keine Keys von Kollegen einsehen, und er kann schon gar keine Team Settings ändern.
Um das programmatisch einzurichten, macht der Proxy Admin einen einzigen API Request an den Team Creation Endpoint. Du übergibst den Teamnamen, den Max Budget Parameter und ein Array von User IDs, die mit der Team Admin Rolle getaggt sind. Das System gibt eine Team ID zurück. Von da an nutzt der Abteilungsleiter diese Team ID, um seine eigenen Management Requests zu routen, und umgeht das Platform Engineering Team dabei komplett.
Bei Role-Based Access Control in LiteLLM geht es nicht nur darum, Buttons in einer UI zu verstecken. Es geht darum, den Token Spend auf Gruppenebene physisch zu beschränken, während das Key Management an die Leute weitergegeben wird, die die Projekte tatsächlich leiten.
Danke fürs Zuhören und Happy Coding zusammen!
15
Security Guardrails
4m 20sFügen Sie Ihren LLM-Requests eine unsichtbare Sicherheitsebene hinzu. Erfahren Sie, wie Sie Pre-Call- und Post-Call-Guardrails in LiteLLM konfigurieren, um Prompt Injections zu blockieren und PII zu maskieren, bevor sie externe Provider erreichen.
Hallo, hier ist Alex von DEV STORIES DOT EU. LiteLLM: Das universelle LLM Gateway, Folge 15 von 24. Sich darauf zu verlassen, dass sich ein Sprachmodell von allein richtig verhält, ist keine Sicherheitsstrategie. Wenn ein User versehentlich sensible Kundendaten in einen Prompt einfügt, ist es bereits zu spät, das Modell höflich zu bitten, diese zu ignorieren. Du brauchst einen Türsteher, und genau das bieten Security Guardrails.
Security Guardrails in LiteLLM fungieren als unsichtbare Sicherheitsschicht zwischen deinen Application Clients und den Sprachmodell-Providern. Sie fangen den API-Traffic in zwei verschiedenen Phasen ab. Die erste Phase heißt Pre-Call. Sie wird ausgeführt, nachdem LiteLLM den eingehenden Request von deiner Anwendung empfangen hat, aber kurz bevor es diesen Payload an den externen Provider weiterleitet. Die zweite Phase heißt Post-Call. Sie wird ausgelöst, nachdem das Modell seine Response generiert hat, aber bevor LiteLLM diese Response an den ursprünglichen Client zurücksendet.
Du definierst diese Routing-Logik komplett in deiner config dot yaml Datei. Unter dem Proxy-Settings-Block definierst du deine Guardrails, indem du einen Endpoint oder eine unterstützte Integration angibst und dann einen Modus zuweist – entweder Pre-Call oder Post-Call.
Schauen wir uns ein konkretes Szenario mit einem Pre-Call Guardrail an. Angenommen, ein Mitarbeiter bittet ein Cloud-gehostetes Modell, ein Support-Ticket zusammenzufassen, aber dieses Ticket enthält US-Sozialversicherungsnummern. Du willst absolut nicht, dass diese Nummern dein internes Netzwerk verlassen. Du kannst Microsoft Presidio als deinen Pre-Call Guardrail konfigurieren. Wenn die Anwendung den Prompt sendet, fängt LiteLLM den Request ab und übergibt den Text an Presidio. Presidio scannt den Text, findet die Sozialversicherungsnummer und ersetzt sie durch eine generische Maske. LiteLLM nimmt dann diesen bereinigten Prompt und sendet ihn über das Internet an den Cloud-Provider. Das externe Modell generiert eine Zusammenfassung basierend auf dem maskierten Text, und dein Application Code läuft weiter, als wäre nichts Ungewöhnliches passiert.
Hier ist der entscheidende Punkt: Du musst diese Regeln nicht global auf deinen gesamten Traffic anwenden. Mit LiteLLM kannst du Guardrails auf der spezifischen Modell-Ebene hinzufügen. Das ist extrem wichtig, wenn du eine hybride Architektur betreibst. Du kannst dein Routing so konfigurieren, dass jeder Prompt, der an ein Public Cloud Modell gesendet wird, den strengen PII-Masking Guardrail durchläuft. Wenn du jedoch genau denselben Prompt an ein Open Source Modell routest, das auf deiner eigenen On-Premises-Hardware läuft, lässt du den Guardrail einfach aus dem Configuration-Block dieses Modells heraus. Das lokale Modell verarbeitet die unmaskierten Rohdaten, da die Informationen niemals deine Netzwerkgrenze überschreiten. So vermeidest du unnötigen Processing-Overhead und behältst den exakten Kontext bei.
Der Post-Call-Modus funktioniert mit genau demselben Flow, nur eben auf dem Rückweg. Wenn das externe Modell antwortet, leitet LiteLLM den Output durch deine Post-Call Guardrails. Dadurch kannst du den Text auf toxische Sprache, halluzinierte interne URLs oder unautorisierte Erwähnungen von Mitbewerbern prüfen, bevor der User ihn jemals sieht. Wenn der Post-Call Guardrail den Content flaggt, fängt LiteLLM den Rückweg ab. Es blockiert den Text und gibt einen Safety Error an den Client zurück, anstatt den schädlichen Output auszuliefern.
Indem das direkt auf der Proxy-Ebene gehandhabt wird, bleibt deine Application-Architektur komplett unverändert. Deine Entwickler senden einfach Standard-Completion-Requests, und der Proxy setzt deine Compliance-Regeln durch. Die zuverlässigsten Security-Layers sind die, über die dein Application Code niemals nachdenken muss. Danke fürs Zuhören und Happy Coding zusammen!
16
Dynamisches Callback Management
4m 01sGeben Sie Microservices die Kontrolle über den Datenschutz. Erfahren Sie, wie Sie den Header x-litellm-disable-callbacks verwenden, damit sensible API-Requests vom zentralen Observability-Logging ausgeschlossen werden.
Hallo, hier ist Alex von DEV STORIES DOT EU. LiteLLM: Das universelle LLM-Gateway, Folge 16 von 24.
Du willst den gesamten LLM-Traffic zum Debugging loggen, aber was passiert, wenn ein Microservice hochsensible Compliance-Daten übermittelt, die unter keinen Umständen gespeichert werden dürfen? Vielleicht denkst du, dass du Observability global deaktivieren musst und damit dein gesamtes System blind machst, nur um ein paar spezifische API-Routen zu schützen. Dynamic Callback Management löst diesen Konflikt, indem es dir erlaubt, das Logging für jeden Request einzeln zu steuern.
In einem Standard-Setup von LiteLLM übernehmen Callbacks das Senden deiner Request- und Response-Payloads an externe Observability-Plattformen. Du konfigurierst Plattformen wie Langfuse oder Datadog auf Proxy-Ebene, und standardmäßig erfassen sie alles, was durchläuft. Ein weit verbreitetes Missverständnis ist, dass dieses Logging ein Alles-oder-Nichts-System ist. Oft denken die Leute, dass sie für die Verarbeitung sensibler Daten einen komplett separaten Proxy mit deaktiviertem Logging deployen müssen. Dynamic Callback Management erspart dir diesen zusätzlichen Aufwand.
Stell dir einen Microservice vor, der medizinische Akten verarbeitet. Die Anwendung muss Patientensymptome durch ein Language Model verarbeiten, aber das Senden dieser sensiblen Patientendaten an einen Third-Party Logging-Stack verstößt gegen die Compliance. Um diesen Leak zu verhindern, fügt der Microservice seinem ausgehenden Request einfach einen spezifischen HTTP-Header hinzu. Dieser Header heißt x-litellm-disable-callbacks. Du setzt seinen Wert auf eine kommagetrennte Liste der spezifischen Plattformen, die du umgehen willst.
Für den Medical-Records-Service übergibt der Microservice den Header mit dem Wert langfuse Komma datadog. Wenn der LiteLLM-Proxy diesen Request empfängt, wertet er den Header aus, bevor er das Language Model triggert. Der Prompt wird an den Provider gesendet, und die Response wird wie gewohnt an den Client zurückgeroutet. Der Eingriff passiert während der Telemetrie-Phase. Der Proxy liest den Disable-Header und blockiert aktiv die Weiterleitung der Payload an die angegebenen Observability-Endpoints für diese einzelne Transaktion. Währenddessen loggen alle anderen Anwendungen, die gleichzeitig denselben Proxy ansprechen, ihren Traffic ohne Unterbrechung weiter.
Hier wird es interessant. Clients die Macht zu geben, ihre eigenen Audit-Logs zu deaktivieren, bringt ein potenzielles Sicherheitsrisiko mit sich. In stark regulierten Umgebungen sollten Entwickler nicht immer die Befugnis haben, ihren Traffic zu verbergen. Wenn deine Infrastruktur einen strikten, unveränderlichen Audit-Trail für jeden einzelnen Prompt erfordert, musst du das zentral erzwingen.
Das machst du mit Compliance Locking. In der Proxy-Konfigurationsdatei, innerhalb des General-Settings-Blocks, setzt du einen Parameter namens allow dynamic callback disabling auf false. Diese einzige Einstellung etabliert eine strikte globale Policy, die alle clientseitigen Anweisungen überschreibt.
Wenn ein Microservice versucht, den disable callbacks Header zu übergeben, während dieser Lock aktiv ist, ignoriert der Proxy den Header nicht einfach stillschweigend. Stattdessen lehnt er die Transaktion komplett ab und gibt einen HTTP 403 Forbidden Error zurück. Dieser Mechanismus garantiert, dass der Traffic entweder der obligatorischen globalen Logging-Policy entspricht, oder gedroppt wird, bevor er das Language Model erreicht.
Der wahre Nutzen von Dynamic Callback Management ist, dass es Data Privacy von einem starren Infrastructure Deployment in einen agilen Parameter auf Request-Ebene verlagert, während es Platform Engineers weiterhin das letzte Wort in Sachen Compliance gibt.
Danke fürs Zuhören, Happy Coding zusammen!
17
Drop-in Observability
3m 34sErhalten Sie sofortige Transparenz über Ihren LLM-Traffic. Erfahren Sie, wie Sie Telemetrie, Traces und Exceptions mithilfe einfacher Success- und Failure-Callbacks an Tools wie Langfuse und Sentry weiterleiten.
Hallo, hier ist Alex von DEV STORIES DOT EU. LiteLLM: Das universelle LLM-Gateway, Folge 17 von 24. Wenn sich ein User beschwert, dass die KI ihm vor drei Tagen eine seltsame Antwort gegeben hat, wie rufst du dann den genauen Prompt auf, der das verursacht hat? Das Parsen von Application Logs nach mehrzeiligen JSON-Payloads ist ein Albtraum. Du brauchst strukturierte Trace-Daten, aber Custom-Integrationen für jedes Monitoring-Tool zu bauen, verschlingt unzählige Entwicklerstunden. Genau dieses Problem löst Drop-in Observability.
Anstatt Custom-Wrapper-Funktionen zu schreiben, um deine API Calls zu timen, Tokens zu zählen und Timeouts abzufangen, fängt LiteLLM den Traffic nativ ab. Es stellt zwei zentrale Hooks in deinen Settings bereit: den Success Callback und den Failure Callback. Diese Callbacks fungieren als automatische Routing-Mechanismen für deine Telemetrie. Sie akzeptieren ein Array von Strings, die unterstützte externe Observability-Provider repräsentieren. Du nennst einfach das Tool, das du nutzen willst, und LiteLLM übersetzt seine internen Request-Daten in genau das Format, das dieses spezifische Tool erwartet.
Nehmen wir den Success Callback. Dieser triggert in dem Moment, in dem ein Sprachmodell eine gültige Response zurückgibt. Wenn das passiert, erfasst LiteLLM automatisch einen Snapshot der Transaktion. Dieser enthält den exakten Input Prompt, der an das Modell gesendet wurde, den generierten Output, die Generierungszeit und die genaue Token Usage. Um diese Daten an ein externes Tool zu senden, öffnest du deine LiteLLM-Settings und setzt die Success Callback Variable auf eine Liste, die den String "langfuse" enthält. Solange deine Langfuse Authentication Keys in deinen Environment Variables vorhanden sind, kümmert sich das System um den Rest. Hier ist der entscheidende Punkt: Der Logging-Prozess passiert asynchron im Hintergrund. Dein Main Application Thread blockiert nie, während er darauf wartet, dass der Observability-Provider den Trace bestätigt. Deine User erleben null zusätzliche Latenz.
Damit ist der Happy Path abgedeckt. Für die Fehler nutzt du den Failure Callback. Dieser triggert, wenn ein API Call in ein Timeout läuft, ein Provider Rate Limit erreicht oder komplett fehlschlägt. Ohne richtiges Tracing taucht ein LLM-Fehler oft nur als undurchsichtiger Status Code auf. Indem du deine Failure Callback Variable auf eine Liste setzt, die den String "sentry" enthält, mappst du LLM Exceptions direkt auf deinen bestehenden Error Tracking Workflow. Wenn ein Request fehlschlägt, verpackt LiteLLM den Exception Type, den Modellnamen und den versuchten Input und pusht diesen Kontext direkt in Sentry.
Um das in deinem Code aufzusetzen, musst du deine eigentlichen API Calls nicht verändern. Du fasst nur die globale Konfiguration an. Du weist deine gewählten Tools den Callback Arrays einmalig beim Application Startup zu. Ab diesem Zeitpunkt wird jeder Completion Call, den du machst, überwacht. Deine Core-Logik bleibt komplett von deiner Logging-Infrastruktur entkoppelt. Wenn du dich entscheidest, Langfuse nächsten Monat durch einen anderen Provider zu ersetzen, änderst du genau einen String in einem Array.
Die wahre Stärke von Drop-in Callbacks liegt nicht nur in der Vermeidung von Boilerplate-Code. Sie liegt darin, die Struktur deiner Telemetrie über Dutzende verschiedener LLM-Provider hinweg zu standardisieren, sodass deine Monitoring-Plattform genau ein konsistentes Format sieht, unabhängig davon, welches zugrundeliegende Modell den Prompt beantwortet hat.
Vielen Dank fürs Zuhören, Happy Coding zusammen!
18
Prometheus Metrics und Pod Health
3m 36sFühlen Sie Ihrem Proxy den Puls. Entdecken Sie, wie Sie den /metrics-Endpunkt für Prometheus freigeben, In-Flight Requests verfolgen und Custom Tags verwenden, um Daten in Grafana aufzuschlüsseln.
Hallo, hier ist Alex von DEV STORIES DOT EU. LiteLLM: Das universelle LLM-Gateway, Folge 18 von 24. Dauert ein LLM-Request zehn Sekunden, ist dann der AI-Provider langsam, oder ist der Event Loop deines Proxys komplett überlastet? Du kannst einen Bottleneck erst fixen, wenn du genau weißt, wo er liegt. Prometheus Metrics und Pod Health in LiteLLM geben dir genau diese Transparenz.
LiteLLM stellt einen Standard-Metrics-Endpoint unter dem Pfad Slash Metrics bereit. Ein häufiger Fehler beim Monitoring von AI-Gateways ist es, alle Response-Verzögerungen als LLM-Provider-Latenz zu behandeln. Das ist ungenau. Es gibt zwei unterschiedliche Wartezeiten. Erstens gibt es die Pre-ASGI-Queue-Latenz. Das ist die Zeit, die ein Request in deiner Infrastruktur wartet, bevor der Proxy überhaupt anfängt, ihn zu verarbeiten. Zweitens gibt es die eigentliche LLM-Latenz. Das ist die Zeit, die man darauf wartet, dass OpenAI, Anthropic oder ein anderer Provider Tokens zurückgibt. Der Metrics-Endpoint trennt diese Zahlen, sodass du genau weißt, wer für eine langsame Response verantwortlich ist.
Um deine Pod Health zu monitoren, verlässt du dich auf eine spezifische Gauge namens litellm in flight requests. Diese Metrik trackt die genaue Anzahl der Concurrent Requests, die in jeder beliebigen Millisekunde aktiv von einem Pod verarbeitet werden. Das ist ein Echtzeit-Maß für die Queue Depth. Wenn der Traffic ansteigt, klettert diese Zahl nach oben.
Stell dir ein konkretes Szenario vor. Dein Monitoring-Dashboard zeigt einen massiven Spike in der Total Request Duration. User beschweren sich über langsame Antworten. Wenn du dir nur die Gesamtzeit ansiehst, könntest du annehmen, dass OpenAI einen Outage hat. Aber wenn du den Metrics-Endpoint checkst, ist die Provider-Latenz stabil bei zwei Sekunden. Hier ist die entscheidende Erkenntnis. Du schaust dir litellm in flight requests an und siehst, dass der Wert von zwanzig auf zweihundert hochgeschossen ist. Das beweist, dass die Verzögerung nicht an OpenAI liegt. Deine Pod-Queue ist komplett überlastet. Ausgerüstet mit genau dieser Gauge kannst du deine Infrastruktur so konfigurieren, dass sie ein Auto-Scale-Event triggert, sobald die In-Flight Requests einen bestimmten Threshold überschreiten. So werden neue Proxy-Pods hochgefahren, bevor der Event Loop blockiert.
Du musst außerdem wissen, wer diesen Traffic generiert. LiteLLM unterstützt Custom Prometheus Tags. Wenn ein Request das Gateway erreicht, kannst du Custom Metadata im Request Payload übergeben, wie eine Project ID, eine Abteilung oder einen Application Name. LiteLLM extrahiert diese Custom Tags und hängt sie als Labels an die Prometheus Metrics an. Anstatt nur zu sehen, dass das Gateway zehntausend Tokens verarbeitet hat, siehst du, dass die Marketing-Application siebentausend Tokens verarbeitet hat und das Analytics-Dashboard dreitausend. Das gibt DevOps die Möglichkeit, Token Usage, Queue Depth und Latenz nach spezifischen Tenants zu gruppieren.
Das wichtigste Takeaway für die Gateway-Performance ist folgendes: Skaliere deinen AI-Proxy niemals automatisch basierend auf der Total Response Latency, denn du wirst Geld verschwenden, wenn du hochskalierst, nur weil der externe Provider gerade langsam ist. Skaliere basierend auf deiner In-Flight Request Gauge, um nur dann zu reagieren, wenn deine eigene Infrastructure Queue tatsächlich voll ist.
Danke fürs Zuhören, Happy Coding zusammen!
19
Universelles Text-to-Speech
3m 53sStandardisieren Sie Ihre Sprachgenerierung. Entdecken Sie, wie Sie Text-to-Speech-Modelle von Gemini, Vertex und AWS Polly über genau dasselbe OpenAI-kompatible Audio-Endpunkt-Format aufrufen.
Hallo, hier ist Alex von DEV STORIES DOT EU. LiteLLM: Das universelle LLM-Gateway, Folge 19 von 24. Du möchtest deiner App Voice Generation hinzufügen, aber Custom Integration Code für das Audioformat jedes einzelnen Providers zu schreiben, erfordert ständige Maintenance. Jedes Mal, wenn du von einem OpenAI Voice Model zu einem Google Voice Model wechselst, ändern sich die benötigten JSON-Felder, die API-Pfade und die Audio Return Types komplett. Der Mechanismus, der das löst, ist Universal Text-to-Speech über die LiteLLM Audio-Speech Bridge.
Anstatt separate API-Clients für OpenAI, Vertex AI und Gemini zu maintainen, standardisierst du deine Application auf ein einziges Format. LiteLLM stellt einen Unified Endpoint bereit, der die Standard OpenAI Audio-Speech Route exakt nachbildet. Du baust einen Request mit deinem Text, deinem gewählten Model Name und einer Voice Preference und sendest ihn an LiteLLM, als würdest du direkt mit OpenAI kommunizieren. Das Gateway übersetzt diesen standardisierten Payload dann in das spezifische Format, das dein Target Provider benötigt.
Hier ist die entscheidende Erkenntnis. Viele AI Provider bieten keine einfache, dedizierte Text-to-Speech API, die Audio Files out of the box streamt. Je nach Provider erfordert der native Zugriff auf ein Voice Model oft das Routing des Requests über einen generischen Text Completion Endpoint. Unter Umständen musst du hochspezifische Configuration Flags übergeben, einen komplexen System Prompt senden und anschließend Base64-kodierte Audio Strings extrahieren, die tief in einer JSON Response verschachtelt sind. LiteLLM abstrahiert diesen gesamten Translation Layer. Es übernimmt die API Negotiation, entpackt die proprietäre Response-Struktur und isoliert die eigentlichen Audio-Daten.
Stell dir ein konkretes Szenario vor. Du entscheidest dich, gesprochenes Audio mit Googles Gemini Flash TTS Preview Model zu generieren. In deinem Application Code lässt du deinen Standard HTTP Client auf deine LiteLLM Proxy URL beim Audio-Speech Path zeigen. Du setzt den Model Parameter auf das Gemini Flash TTS Model. Du weist dem Input Parameter deinen Plain Text zu und gibst einen gültigen Voice Identifier an.
Wenn du den Request ausführst, fängt LiteLLM den Payload ab. Es authentifiziert sich sicher bei Google Cloud oder Vertex AI, je nach deinem Setup. Es verpackt deinen Plain Text und deine Voice Selection neu in das spezifische JSON Schema, das die Google API verlangt. Wenn das Google Model den Text verarbeitet und das Result zurückgibt, fängt LiteLLM die proprietäre Response ab. Anstatt deine Client Application dazu zu zwingen, einen Custom Google Cloud Payload zu parsen, extrahiert LiteLLM die Raw Audio Bytes. Es überbrückt nahtlos den Transport Layer und streamt sofort ein Standard MP3 File an deinen Client zurück. Deine Frontend- oder Backend-Application empfängt einen Standard Audio Stream und merkt überhaupt nicht, dass die zugrundeliegende Generierung von Google statt von OpenAI durchgeführt wurde.
Diese Bridge Logic bedeutet, dass du deine Text-to-Speech Client Integration genau einmal schreibst. Wenn Vertex morgen ein neues, schnelleres Audio Model veröffentlicht, musst du lediglich den Model String in deinem Request ändern. Der Application Code, der den MP3 Stream verarbeitet, bleibt komplett unangetastet. Audio Generation exakt genauso zu behandeln wie Text Generation, erlaubt es dir, deine Application Logic zu standardisieren. Indem du alle Text-to-Speech Requests durch ein einziges Unified Interface schleust, kannst du deine Audio Generation über völlig unterschiedliche Provider hinweg routen, load-balancen und Failovers einrichten – ganz ohne eine einzige Zeile Provider-spezifischen Fallback Code zu schreiben. Danke fürs Zuhören, Happy Coding zusammen!
20
Die Assistants API Bridge
4m 18sVerwalten Sie den Conversation State mühelos über verschiedene Provider hinweg. Erfahren Sie, wie LiteLLM nicht-native Modelle in das Standard-Interface der OpenAI Assistants API hüllt, sodass Sie Threads und Messages überall nutzen können.
Hallo, hier ist Alex von DEV STORIES DOT EU. LiteLLM: Das universelle LLM-Gateway, Folge 20 von 24. OpenAI verwaltet den Conversation State elegant und hält deinen Client-Code komplett stateless. Aber deine Architektur an einen einzigen Provider zu binden, nur um dieses State Management zu behalten, ist ein hoher Preis. Die Assistants API Bridge in LiteLLM löst dieses Problem.
Die Bridge ist ein Feature des LiteLLM-Proxys, das genau die gleichen Endpoints der OpenAI Assistants API bereitstellt. Du sprichst Standard-Pfade wie die v one assistants und v one threads Endpoints an, aber du routest die eigentliche Textgenerierung an jedes beliebige Modell, das du willst.
Standard Chat Completion Interfaces sind stateless. Jedes Mal, wenn du eine Frage stellst, muss dein Client die gesamte Conversation History zurück an den Server schicken. Das verbraucht Bandbreite und macht deinen clientseitigen Code komplizierter. Die Assistants API löst das, indem sie die Conversation History auf dem Server in einem Thread-Objekt speichert. Du hängst einfach neue Messages an den Thread an und sagst dem Server, er soll den Assistant ausführen. Das Problem ist, dass die meisten anderen Provider, von lokalen Setups bis hin zu Enterprise-Cloud-Alternativen, dieses stateful Interface nicht nativ anbieten.
Die LiteLLM-Bridge polyfillt diese fehlende Funktionalität. Damit das funktioniert, konfigurierst du den LiteLLM-Proxy so, dass er sich mit einer Datenbank verbindet. Diese Datenbank dient als Storage Layer für deinen Conversation State. Dann lässt du deinen bestehenden OpenAI-Client auf die LiteLLM-Proxy-URL zeigen, anstatt auf die Standard-OpenAI-Server.
Der Logic Flow beginnt mit dem Erstellen eines Assistants. Du sendest einen Request an den Proxy, der die Assistant Instructions definiert und ein Target Model angibt. Das könnte ein Azure OpenAI Deployment oder ein OpenAI-kompatibles Astra-Modell sein. Der Proxy speichert diese Konfiguration in seiner Datenbank.
Als Nächstes erstellst du einen Thread. Ein Thread ist einfach ein leerer Container, der vom Proxy gespeichert wird. Wenn ein User etwas sagt, sendest du einen Request, um diesem spezifischen Thread eine Message hinzuzufügen. Der Proxy speichert die Message. Bis zu diesem Punkt wurde das zugrundeliegende Large Language Model noch gar nicht kontaktiert.
Hier ist der entscheidende Punkt. Die Bridge kommuniziert nur mit deinem Target Model, wenn du einen Run triggerst. Wenn du dem Proxy sagst, er soll den Assistant auf einem bestimmten Thread ausführen, ruft LiteLLM die gesamte Message History aus seiner Datenbank ab. Es formatiert diese History in eine standardmäßige, stateless Chat Completion Payload. Dann sendet es diese flache Payload an das zugrundeliegende Modell, das du vorher konfiguriert hast.
Das Modell wertet die Conversation aus und gibt eine Response an den Proxy zurück. LiteLLM nimmt diesen Text, verpackt ihn als neue Assistant Message, speichert ihn in der Thread-Datenbank und updatet den Run-Status auf completed. Dein Client pollt den Proxy, sieht den completed Status und holt sich die neueste Message genau so, wie er es normalerweise tun würde.
Dein Application Code bleibt komplett unverändert. Er denkt immer noch, er spricht mit einem nativen stateful System. Der Proxy übernimmt die Übersetzung transparent, nimmt einen stateful Client Request entgegen, führt einen stateless Model Call aus und pflegt den Persistence Layer dazwischen.
Diese Separation of Concerns bedeutet, dass sich deine Client-Architektur auf ein modernes, state-managed API Interface verlassen kann, während deine Infrastruktur völlig frei bleibt, die zugrundeliegenden Modelle basierend auf Kosten, Privacy oder Performance-Anforderungen auszutauschen.
Danke fürs Zuhören und Happy Coding zusammen!
21
Das MCP Gateway
4m 09sRüsten Sie Ihre Modelle zentral mit Tools auf. Entdecken Sie, wie Sie HTTP-, SSE- oder STDIO-Server für das Model Context Protocol (MCP) in LiteLLM konfigurieren und so jedem LLM Zugriff auf externe Fähigkeiten geben.
Hallo, hier ist Alex von DEV STORIES DOT EU. LiteLLM: Das universelle LLM Gateway, Folge 21 von 24. Du hast ein Open-Source Llama Modell, das lokal läuft, willst aber, dass es Aktionen auslöst oder Dateien über genau dieselben GitHub-Integrationen liest, die auch dein Claude Code Agent nutzt. Du willst deine Application Logic nicht umschreiben, um für jedes neue Modell ein neues Toolset zu unterstützen. Das MCP Gateway löst dieses Problem.
Lass uns zuerst MCP von A2A, also Agent-to-Agent Routing, trennen. Oft werden die beiden fälschlicherweise für dasselbe gehalten. Bei A2A routest du einen User Prompt an einen spezialisierten externen Agenten, um eine Text Response zu generieren. MCP ist etwas völlig anderes. MCP steht für Model Context Protocol. Dabei geht es darum, einem Modell ein standardisiertes Set an Tools zur Verfügung zu stellen und das Modell selbst entscheiden zu lassen, wann und wie es diese aufruft, um einen Task abzuschließen.
Das MCP Gateway Feature ermöglicht es dem LiteLLM Proxy, als Brücke zwischen jedem beliebigen Sprachmodell und deinen MCP Servern zu fungieren. Anstatt Code zu schreiben, um Tools in jeder einzelnen Client Application zu registrieren, die du baust, definierst du sie zentral im Proxy. Ab diesem Zeitpunkt kann jedes Modell, das den Proxy anspricht, diese Tools nutzen.
LiteLLM verbindet sich über zwei primäre Methoden mit MCP Servern. Die erste ist STDIO, also Standard Input und Output. Das wird für lokale Tools verwendet. Du konfigurierst den Proxy so, dass er einen bestimmten lokalen Command ausführt, wie zum Beispiel ein Node Script oder ein Python File direkt auf der Host Machine. Die zweite Methode ist HTTP mit Server-Sent Events, oder kurz SSE. Das wird genutzt, um sich über ein Netzwerk mit Remote MCP Servern zu verbinden.
Schauen wir uns ein konkretes Szenario an. Du willst einen Remote Zapier MCP Server hinzufügen, damit deine Modelle mit externen Web Apps interagieren können. Das machst du komplett in der YAML Config File des Proxys. Unter dem Main Configuration Block fügst du eine MCP Servers Section hinzu. Du benennst die Integration, zum Beispiel zapier-integration. Du definierst den Transport Type als SSE. Dann gibst du die Endpoint URL deines Zapier MCP Servers an. Weil das eine Remote Connection ist, gibst du auch die benötigten Authentication Headers, wie zum Beispiel ein Bearer Token, direkt in dieser YAML Definition an.
Jetzt weiß der Proxy, wie er mit Zapier kommunizieren muss. Der nächste Schritt ist die Execution. Wenn deine Client Application einen Standard Chat Completion Request an LiteLLM sendet, muss sie nur einen spezifischen Header mitschicken, der angibt, welche MCP Tools sie laden will.
Hier ist der entscheidende Punkt. Die Client Application muss gar nicht wissen, welche Tools Zapier eigentlich anbietet. Der Proxy fängt den Client Request ab, kontaktiert den Zapier MCP Server über die SSE Connection und ruft dynamisch die aktuelle Liste der verfügbaren Tools ab. Der Proxy fügt diese Tool Definitions dann in die Payload ein und leitet das ganze Paket an das Sprachmodell weiter.
Wenn das Sprachmodell entscheidet, ein Zapier Tool aufzurufen, sendet es einen Tool Call zurück an den Proxy. Der Proxy fängt ihn ab, führt die Action auf dem Zapier MCP Server aus, holt das Result und gibt es an das Modell zurück. Deine Client Application ist von diesem Hin und Her komplett abgeschirmt. Sie empfängt einfach nur Standard OpenAI-kompatible Tool Responses.
Die wahre Stärke des MCP Gateways ist die Entkopplung der Tool Implementation von der Modellauswahl. Das bedeutet, dass eine Integration, die für ein Ökosystem gebaut wurde, sofort mit Dutzenden verschiedener Modelle funktioniert, ohne dass man Custom Adapter Code schreiben muss.
Danke fürs Zuhören, Happy Coding zusammen!
22
A2A: Tracking von Autonomous Agents
3m 54sBringen Sie Autonomous Agents unter Kontrolle. Erfahren Sie, wie Sie komplexe LangGraph- oder Bedrock-Agenten über den Proxy mithilfe des A2A-Protokolls aufrufen, was Trace Grouping und einheitliches Spend Tracking ermöglicht.
Hallo, hier ist Alex von DEV STORIES DOT EU. LiteLLM: Das universelle LLM-Gateway, Folge 22 von 24.
Wenn dein autonomer Agent einen 50-stufigen Reasoning Loop durchläuft, wie verfolgst du die Rechnung bis zum ursprünglichen Request zurück? Wenn der Agent Dutzende isolierte Calls an verschiedene Sprachmodelle macht, werden deine Billing Logs zu einem unlesbaren Durcheinander von zusammenhangslosen Requests. Die Lösung dafür ist das LiteLLM Agent Gateway, auch bekannt als A2A-Protokoll.
Bevor wir uns die Mechanik genauer ansehen, sollten wir ein häufiges Missverständnis ausräumen. Zuhörer verwechseln das oft mit dem Model Context Protocol, oder kurz MCP. MCP wird genutzt, um einem Sprachmodell externe Tools bereitzustellen. A2A macht genau das Gegenteil. Es behandelt einen externen, autonomen Agenten wie ein Standard-Sprachmodell und ermöglicht es dir, ihn über ein zentrales Gateway aufzurufen und zu tracken.
Um das aufzusetzen, definierst du deinen Agenten in der LiteLLM-Konfigurationsdatei genau so, wie du ein Standard-Sprachmodell definieren würdest. Du gibst dem Modell einen Namen, setzt die Base URL, die auf deinen Agenten-API-Endpoint zeigt, und gibst den Provider als Custom OpenAI-Endpoint an. Jetzt weiß LiteLLM, wie es eingehende Client-Requests direkt zu deinem Agenten routen kann.
Wenn ein Client einen Request an diesen Agenten sendet, fungiert LiteLLM als Pass-Through für Context-Header. Es nimmt die Metadaten, die an den Request gebunden sind, wie User Identifiers, Team Routing Tags und Budget Limits, und verpackt sie in spezifische HTTP-Header. Der wichtigste davon ist der X-LiteLLM-Trace-Id-Header. LiteLLM leitet diese Header zusammen mit dem Prompt an deinen Agenten weiter.
Hier ist der entscheidende Punkt. Dein Agent empfängt diesen Request, startet seinen autonomen Loop und beginnt, seine eigenen internen Calls zu machen, um den Task zu verarbeiten. Wenn der Agent diese Calls direkt an einen öffentlichen Provider macht, verlierst du den Tracking-Context. Stattdessen muss der Agent seine internen Calls wieder durch LiteLLM routen. Wenn er das tut, muss er die Trace-ID mitsenden, die er im ursprünglichen Request erhalten hat.
Stell dir ein konkretes Szenario vor. Du rufst einen lokalen LangGraph-Agenten auf. Ein Client sendet einen Prompt durch LiteLLM, um den Prozess zu starten. LiteLLM weist eine eindeutige Trace-ID zu und leitet den Payload an den LangGraph-Endpoint weiter. Deine LangGraph-Anwendung liest die eingehenden HTTP-Header und extrahiert die X-LiteLLM-Trace-Id. Wenn LangGraph einen Schritt evaluieren oder Daten zusammenfassen muss, nutzt es seinen internen Client, um einen Completion Call an LiteLLM zurückzusenden. Ganz wichtig: Es hängt genau denselben Trace-ID-Header an seinen ausgehenden Request an.
Weil jeder interne Call denselben Trace-Identifier trägt, gruppiert LiteLLM sie automatisch zusammen. Wenn du dir deine Observability Platform oder Budget Logs ansiehst, siehst du nicht fünfzig zufällige Requests aus unbekannten Quellen. Du siehst einen einzigen, vereinten Trace. Du weißt genau, welcher User den Agenten getriggert hat, wie viel der gesamte Reasoning Loop gekostet hat und welche spezifischen autonomen Schritte das meiste Budget verbraucht haben.
Agenten als Standard-Model-Endpoints zu behandeln, verwandelt komplexe, mehrstufige Agenten-Workflows in trackbare, abrechenbare Compute-Einheiten.
Danke fürs Zuhören und Happy Coding zusammen!
23
Zero-Downtime Key Rotations
3m 36sErreichen Sie Sicherheitsumstellungen ohne Ausfallzeiten. Erfahren Sie, wie Sie automatische, geplante Key Rotations und Grace Periods für Enterprise-Grade Virtual Keys in LiteLLM konfigurieren.
Hallo, hier ist Alex von DEV STORIES DOT EU. LiteLLM: Das universelle LLM-Gateway, Folge 23 von 24. Production API-Keys zu rotieren bedeutet normalerweise geplante Downtime, hektische Koordination und die Hoffnung, dass kein Backend-System mit toten Credentials zurückbleibt. Ein Hard Cutover ist eine strenge Sicherheitsmaßnahme, aber eben auch ein extrem zuverlässiger Weg, um Inflight Requests abbrechen zu lassen. Die Lösung für dieses Dilemma sind Zero-Downtime Key Rotations.
In einem Enterprise-Proxy-Setup ist es ein inakzeptables Sicherheitsrisiko, statische Virtual Keys für immer zu behalten. LiteLLM löst das, indem du automatische Key Rotations planen kannst. Anstatt neue Credentials manuell zu generieren und den exakten Moment für den Wechsel zu koordinieren, überlässt du einfach dem Proxy den Lifecycle. Aber einfach nur die Erstellung eines neuen Keys zu automatisieren, löst nicht das eigentliche Zuverlässigkeitsproblem. Wenn das Gateway den alten Key in der Sekunde ablehnt, in der ein neuer erstellt wird, schlägt jeder Service, der das neue Credential noch nicht synchronisiert hat, sofort fehl.
Um das zu beheben, nutzt LiteLLM eine Grace Period. Wenn du einen Virtual Key erstellst oder updatest, konfigurierst du zwei spezifische Parameter. Erstens setzt du das Auto-Rotate-Intervall, das genau definiert, wie oft ein neuer Key generiert werden soll. Zweitens definierst du die Grace Period, die dem System sagt, wie lange der alte Key nach der Rotation noch gültig bleiben soll.
Stell dir eine typische Microservice-Architektur vor, in der deine Security Policy vorschreibt, LLM Access Keys alle dreißig Tage zu rotieren. Du machst einen Request an den LiteLLM Key Generation Endpoint. In diesem Request setzt du den Auto-Rotate-Parameter auf 30 Tage. Im exakt selben Request setzt du den Grace-Period-Parameter auf 24 Stunden. Der Proxy speichert diese Policy und startet den Timer.
Nach genau dreißig Tagen triggert die Rotation. LiteLLM generiert automatisch einen brandneuen Virtual Key. Das ist der entscheidende Punkt. Für die nächsten 24 Stunden hast du zwei komplett gültige Keys, die auf exakt dieselbe Konfiguration, dasselbe Budget und dieselbe Tracking-Logik verweisen.
Während dieses Überlappungsfensters holt sich dein Secrets Manager den neuen Key und injiziert ihn langsam in deine Production-Umgebung. Während Container cyclen oder ConfigMaps updaten, wechseln die Services unabhängig voneinander auf das neue Credential. Wenn ein bestimmter Background Worker zwölf Stunden nach Beginn der Grace Period immer noch den alten Key verwendet, akzeptiert LiteLLM den Request ohne zu meckern. Das Gateway routet den Traffic an das Large Language Model und loggt die Transaktion ganz normal.
Sobald die exakte 24-stündige Grace Period abgelaufen ist, invalidiert LiteLLM den ursprünglichen Key automatisch. Jedes verbleibende System, das weiterhin versucht, das alte Credential zu nutzen, erhält einen Authentication Error. Die Migration ist abgeschlossen.
Du hast die Erstellung des neuen Secrets vollständig von der Zerstörung des alten entkoppelt. Diese beiden Events zu trennen, verwandelt die Key Rotation von einer fragilen, hochgradig koordinierten Infrastruktur-Panik in eine ruhige, zuverlässige Background Routine.
Danke fürs Zuhören, Happy Coding zusammen!
24
Die Admin UI und der AI Hub
3m 58sMachen Sie Ihre AI-Plattform für alle zugänglich. Erfahren Sie, wie Sie die Admin UI verwalten, UI-Credentials anpassen und den AI Hub nutzen, damit Entwickler erlaubte Modelle und Agenten sicher entdecken können.
Hallo, hier ist Alex von DEV STORIES DOT EU. LiteLLM: Das universelle LLM-Gateway, Folge 24 von 24. Dein Plattform-Team hat ein hochsicheres, perfekt geroutetes LLM-Gateway gebaut. Aber wenn interne Entwickler tatsächlich etwas bauen müssen, woher wissen sie dann, welche Models und Agents sie verwenden dürfen? Ohne einen Discovery-Mechanismus ist dein Gateway eine unsichtbare Blackbox. Diese Visibility bieten die Admin UI und der AI Hub.
Die Admin UI ist ein visuelles Dashboard, das direkt in den LiteLLM-Proxy eingebaut ist. Ein LLM-Gateway rein über Config-Files und Database Queries zu betreiben, skaliert schlecht, wenn mehrere Teams Access anfordern. Die Admin UI gibt Plattform-Betreibern einen zentralen Ort, um den Proxy zu managen. Über dieses Interface kannst du neue API-Keys generieren, den Token Spend über verschiedene Teams hinweg tracken, Live Request Logs monitoren und Model Routing Rules konfigurieren.
Wenn du den LiteLLM-Proxy zum ersten Mal startest, ist dieses Dashboard by default aktiviert und mit Default-Credentials gesichert. Für lokales Testing ist das praktisch. In Production ist das eine Sicherheitslücke. Du musst diese Default-Credentials sofort ändern. Das machst du, indem du vor dem Start des Containers spezifische Environment Variables für den Admin-Username und das Passwort setzt.
Hier ist der entscheidende Punkt. Vielleicht willst du auf deinem Production-Gateway überhaupt kein grafisches Dashboard exposen. Viele Plattform-Teams provisionieren Infrastruktur strikt über automatisierte Skripte und wollen keine interaktive Control Plane, die über das Netzwerk erreichbar ist. Wenn das zu deinem Security Model passt, kannst du das Dashboard komplett abschalten. Indem du eine Environment Variable namens disable admin ui auf true setzt, entfernst du das Interface vollständig. Der Proxy wird weiterhin Traffic routen und Rules enforcen, aber der Webserver wird die Admin-Screens nicht mehr ausliefern.
Das deckt die Plattform-Betreiber ab, aber die Engineers, die die API konsumieren, brauchen eine andere Perspektive. Hier kommt der AI Hub ins Spiel. Während die Admin UI für Control da ist, ist der AI Hub für Discovery gedacht. Er fungiert als internes Developer Portal für deine Organisation.
Anstatt dem Plattform-Team zu schreiben, um zu fragen, welche Models aktuell approved sind oder wo die Documentation für einen internen Agent liegt, besuchen Developer einfach den AI Hub. Sie authentifizieren sich, typischerweise über den Single Sign-On Provider deiner Organisation, und bekommen einen Katalog präsentiert. Sie können genau sehen, welche Models sie callen dürfen, die Rate Limits für diese Models überprüfen und vorkonfigurierte Agents entdecken, die von anderen Teams gebaut wurden.
Noch wichtiger ist, dass der AI Hub den Developern Self-Service ermöglicht. Sie können ihre eigenen API-Keys generieren, die an ihre spezifischen Team-Budgets gebunden sind, ohne darauf warten zu müssen, dass ein Platform Engineer manuell einen provisioniert. Das verändert grundlegend, wie deine Organisation mit generativer KI interagiert. Es schließt die Lücke zwischen den Infrastructure Engineers, die das Gateway absichern, und den Product Engineers, die die Applications bauen.
Das Gateway ist nur so nützlich, wie es zugänglich ist, und der AI Hub verwandelt einen abgeschotteten Proxy in eine Self-Serve-Plattform, die es deinen Engineering-Teams erlaubt, schnell voranzukommen, ohne dein Budget zu sprengen. Damit schließen wir unsere Serie über LiteLLM ab. Ich ermutige dich, die offizielle Documentation zu erkunden, diese Configurations hands-on auszuprobieren und DEV STORIES DOT EU zu besuchen, um Themen für zukünftige Serien vorzuschlagen. Danke fürs Zuhören, Happy Coding zusammen!