Wenn Sie AWS Bedrock für die LLM-Nutzung verwenden und über mehrere AWS-Konten verfügen,
kann Ihnen LiteLLM dabei helfen, eine widerstandsfähige Failover-Ebene aufzubauen, damit Ihre Benutzer keine Auswirkungen spüren, wenn bei einem Konto das Kontingent erschöpft ist oder es nicht verfügbar ist.
Die Idee ist einfach: LiteLLM sitzt zwischen Ihren Anwendungen und Bedrock, stellt einen einzigen stabilen Endpunkt für die App bereit und leitet den Datenverkehr hinter den Kulissen über mehrere Konten hinweg weiter.
Warum das wichtig ist
Bedrock ist eine solide Grundlage für KI-Workloads in Unternehmen, aber Kontingente auf Kontoebene und temporäre Dienstprobleme können Benutzer dennoch beeinträchtigen. Wenn Ihre Anwendung direkt mit einem einzelnen Bedrock-Konto kommuniziert, kann eine Kontingentüberschreitung schnell zu einem Ausfall führen.
Genau hier hilft LiteLLM. Es bietet Ihnen einen einzigen, konsistenten API-Einstiegspunkt, während es im Hintergrund mehrere Bedrock-Backends verwaltet. Ihre Anwendung ruft weiterhin denselben Endpunkt auf, während LiteLLM entscheidet, welches Konto die Anfrage verarbeiten soll.
Wie das Failover funktioniert
Das Failover-Muster ist unkompliziert:
- Konfigurieren Sie jedes AWS-Konto als separates Bedrock-Backend.
- Senden Sie den Datenverkehr zuerst an das bevorzugte Konto.
- Wenn dieses Konto ausfällt, versucht LiteLLM die Anfrage erneut.
- Wenn die Wiederholungsversuche fehlschlagen, weicht LiteLLM auf das nächste Konto in der Kette aus.
- Bei Bedarf kann dieser Vorgang über weitere Konten fortgesetzt werden, bis ein funktionierender Pfad gefunden wird.
Hier ist ein Beispiel:
Dies ist besonders nützlich, wenn es sich nicht um einen Totalausfall, sondern um die Erschöpfung eines Kontingents handelt. Aus Sicht der Anwendung ist die Anfrage entweder erfolgreich oder sie schlägt fehl. LiteLLM fügt die Routing-Logik hinzu, die die Erfolgschancen erhöht.
Was LiteLLM Ihnen bietet
Die kostenlose Version von LiteLLM deckt bereits die Kernkomponenten ab, die für ein Bedrock-Failover erforderlich sind:
- Ein einheitlicher, OpenAI-kompatibler API-Endpunkt.
- Routing über mehrere Anbieter oder Deployments hinweg.
- Wiederholungsversuche.
- Fallbacks und Anbieter-Failover.
- Rate-Limiting und grundlegende Kostenkontrollen.
- Self-Hosting.
Das macht es zu einer guten Wahl, wenn Ihr Hauptziel Zuverlässigkeit und ein kontrollierter Überlauf über mehrere AWS-Konten hinweg ist.
Empfohlene Architektur
Ein praktisches Setup sieht normalerweise so aus:
- Ihre Anwendungen senden alle KI-Anfragen an LiteLLM.
- LiteLLM verfügt über Zugriff auf vier Bedrock-Konten.
- Jedes Konto ist als separates Backend konfiguriert.
- LiteLLM leitet Anfragen an das bevorzugte Konto weiter.
- Wenn das bevorzugte Konto nicht verfügbar ist oder sein Kontingent erschöpft ist, weicht LiteLLM auf das nächste aus.
Dies bietet Ihnen einen logischen KI-Endpunkt mit mehreren physischen Ausführungspfaden. Ihre Benutzer sehen einen stabilen Dienst, selbst wenn ein vorgeschaltetes Konto erschöpft ist.
FinOps und Kontrolle
Dieses Design hat auch einen FinOps-Vorteil. Sobald die gesamte Bedrock-Nutzung über LiteLLM läuft, können Sie die Nutzung nach App, Team oder Umgebung analysieren und entscheiden, welches Konto den Überlauf-Datenverkehr aufnehmen soll.
Das gibt Ihnen eine bessere Balance zwischen Verfügbarkeit und Kostenkontrolle. Sie können Premium- oder bevorzugte Konten für kritischen Datenverkehr reservieren, während Sie Überlaufanfragen bei Bedarf auf sekundäre Konten verlagern. In der Praxis macht dies die KI-Nutzung als Plattformdienst viel einfacher zu verwalten.
Wann LiteLLM Enterprise relevant wird
Wenn Ihre Anforderung lediglich ein Multi-Account-Failover für Bedrock ist, benötigen Sie Enterprise anfangs nicht. Die kostenlose Version reicht für Routing, Wiederholungsversuche und grundlegende Ausfallsicherheit aus.
Enterprise wird relevanter, wenn Sie Funktionen wie die folgenden benötigen:
- SSO und zentralisierte Identitätsverwaltung
- Support und SLAs
- Erweiterte Governance
- Strengere Administrationskontrollen
- Umfangreichere Observability auf Enterprise-Niveau
- Unterstützung für größere organisatorische Rollouts
Empfohlener Ansatz
Für Ihren Anwendungsfall ist dies der beste Weg:
- LiteLLM installieren
- LiteLLM vor den gesamten Bedrock-Datenverkehr schalten.
- Die vier AWS-Konten als Fallback-Ziele konfigurieren.
- Sinnvolles Retry- und Cooldown-Verhalten festlegen.
- Nutzungs- und Kontingentmuster überwachen.
- Ziehen Sie Enterprise erst dann in Betracht, wenn Sie eine zentrale Identitätsverwaltung oder umfassendere Plattformkontrollen benötigen.
Dies bietet Ihnen eine reibungslose Möglichkeit, die Ausfallsicherheit zu verbessern, ohne unnötige Lizenzkomplexität einzuführen.
FAQ
Q: Kann LiteLLM helfen, wenn ein Bedrock-Konto sein tägliches Kontingent erreicht?
Ja. Sie können Fallback-Konten konfigurieren, sodass LiteLLM Anfragen an ein anderes AWS-Konto weiterleiten kann, wenn das erste nicht verfügbar ist.
Funktioniert das nur bei Ausfällen?
Nein. Es hilft auch bei Kontingentüberschreitungen, temporären Fehlern und anderen Verfügbarkeitsproblemen, die andernfalls die Benutzer beeinträchtigen würden.
Ist LiteLLM auch für FinOps nützlich?
Ja. Da der Datenverkehr über ein einziges Gateway läuft, ist es einfacher, die Nutzung zu überwachen, den Datenverkehr nach Team oder Umgebung zu trennen und das Überlaufverhalten zu steuern.
Benötige ich LiteLLM Enterprise für das Bedrock-Failover?
Nicht unbedingt. Für Routing, Retries und Multi-Account-Failover reicht die kostenlose Open-Source-Edition in der Regel aus.
Wann sollte ich Enterprise in Betracht ziehen?
Ziehen Sie Enterprise in Betracht, wenn Sie SSO, stärkere Governance, umfassendere Admin-Kontrollen oder die Verwaltung von Rollouts auf Unternehmensebene benötigen.
