LiteLLM v1.93.0 bringt drei eher unspektakuläre, aber für produktive AI-Gateways relevante Änderungen zusammen: einen MCP-Identitätsfluss für Microsoft Entra On-Behalf-Of, getrennte Eingabe-/Ausgabe-Limits im Router und einen Sicherheitsfix rund um Bearer-API-Keys in Spend-Logs.
Warum das Release für Plattformteams zählt
Ein Gateway sitzt zwischen Anwendungen, Modellen, Kostenkontrolle und Zugriffspolitik. Genau dort werden kleine Defaults schnell zu Betriebsproblemen: Ein gemeinsames Rate-Limit verschleiert, ob lange Prompts oder lange Antworten den Engpass verursachen; ein unklarer Identitätsfluss macht delegierte Zugriffe schwer auditierbar; sensible Schlüssel in Telemetrie gehören nicht in Auswertungen.
Die Release Notes führen für den Router getrennte Limits für Input und Output auf. Das ist ein nützliches Modell für heterogene Workloads: Retrieval-lastige Anfragen und generation-lastige Antworten erzeugen sehr unterschiedliche Tokenprofile. Teams können damit Kapazität und Fairness näher an den tatsächlichen Lasttreiber koppeln statt nur einen Gesamttokenzähler zu drosseln.
MCP und Entra: Identität nicht nur weiterreichen
Neu ist außerdem ein Microsoft-Entra-OBO-Pfad für MCP. Das Thema ist weniger ein Komfort-Feature als eine Architekturfrage: Wenn ein Agent über einen MCP-Server auf geschützte Ressourcen zugreift, sollte nachvollziehbar bleiben, in wessen Kontext der Zugriff erfolgt. Delegierte Identität reduziert nicht automatisch die Rechte; sie macht die Kette aus Nutzer, Anwendung und Tool aber expliziter.
Für AI-Gateways ist Observability nur dann hilfreich, wenn sie Auslastung erklärt, ohne dabei Zugangsdaten selbst zur neuen Angriffsfläche zu machen.
Der Security-Fix gehört in den Rollout
LiteLLM nennt außerdem einen Fix für das Maskieren von Bearer-API-Keys in Spend-Logs. Wer diese Logs in ein zentrales Observability- oder Billing-System exportiert, sollte das Update nicht als reine Pflege behandeln: Version anheben, prüfen, welche historischen Log-Sinks existieren, und die eigene Redaction-Policy testen. Ein Patch schützt keine bereits exportierten Secrets.
Praktischer nächster Schritt
- Router-Metriken aufteilen: Input- und Output-Token getrennt messen, bevor neue Limits gesetzt werden.
- OBO nur mit klarer Policy aktivieren: Scopes, Downstream-Audience und Audit-Logs vor dem produktiven MCP-Einsatz festlegen.
- Log-Pipeline kontrollieren: Redaction mit einem Test-Key prüfen und bereits gespeicherte Spend-Logs nach Zugangsdaten durchsuchen.
Einordnung
Das ist kein Modell-Launch. Gerade deshalb ist es relevant: Der Nutzen von AI-Gateways entscheidet sich in Identität, Routing und Telemetrie. v1.93.0 schiebt alle drei Bereiche in die richtige Richtung, ersetzt aber weder Rechtekonzept noch Kapazitätsplanung.
Quelle
- LiteLLM auf GitHub: Release v1.93.0 (19. Juli 2026)
Schreibe einen Kommentar