Bedrock über LiteLLM

Verwenden Sie diese Seite, wenn Ihre Organisation Codex über LiteLLM an Amazon Bedrock weiterleitet. Wenn bereits ein LiteLLM-Gateway vorhanden ist, verbinden Sie zuerst Codex. Stellen Sie LiteLLM nur bereit, wenn Ihre Organisation ein neues Gateway benötigt.

Für andere Gateway-Produkte gelten dieselben Gateway-Anforderungen und derselbe Ablauf zum Verbinden von Codex.

Verbindung mit einem vorhandenen Gateway herstellen

Fordern Sie diese Werte von Ihrem Gateway-Administrator an:

• Die HTTPS-Basis-URL, etwa https://gateway.example.com/v1.
• Den Modellalias, den LiteLLM an ein genehmigtes Bedrock-Modell weiterleitet.
• Die in der Codex-Konfiguration zu verwendende Anbieter-ID.
• Gateway-Zugangsdaten mit eingeschränktem Berechtigungsumfang oder ein Authentifizierungshilfsprogramm, das diese zurückgibt.
• Einen gegebenenfalls mit der Konfiguration Ihrer Organisation verteilten Modellkatalog.

Stellen Sie die Verbindung anschließend in dieser Reihenfolge her:

1. Bitten Sie Ihr Gateway-Team zu bestätigen, dass das Gateway POST /v1/responses bereitstellt, Antworten streamt, Folgerunden und Tool-Aufrufe beibehält und den genehmigten Alias weiterleitet. Siehe Gateway-Kompatibilität.
2. Folgen Sie Verbindung mit einem Gateway herstellen, um Anbieter, Modell und Zugangsdaten zu konfigurieren.
3. Überprüfen Sie den aktiven Anbieter und Alias, senden Sie den kurzen Prompt gateway-ok aus der Verbindungsanleitung und bestätigen Sie, dass der LiteLLM-Protokolleintrag den erwarteten Benutzer und Alias zeigt.
4. Fahren Sie für eine organisationsweite Verteilung mit Codex über ein Gateway bereitstellen fort.

Ihre Gateway-Zugangsdaten authentifizieren Sie bei LiteLLM. Das Gateway verwaltet seine eigenen Bedrock-Zugangsdaten; Sie müssen diese Zugangsdaten nicht auf Ihren Arbeitsplatzrechner kopieren.

Ein Gateway vorbereiten

Verwenden Sie diesen Abschnitt nur, wenn Sie vor dem Verbinden von Codex ein LiteLLM-Gateway erstellen müssen.

Vor der Bereitstellung

Vergewissern Sie sich, dass Folgendes vorhanden ist:

• Die Berechtigung, die genehmigte LiteLLM-Architektur in Ihrer AWS-Umgebung bereitzustellen.
• Bedrock-Zugriff auf die Modelle oder Inferenzprofile, an die Sie Anfragen weiterleiten werden.
• Ein geprüftes LiteLLM-Image und Bereitstellungsmuster.
• Ein vertrauenswürdiger HTTPS-Hostname und ein entsprechendes Zertifikat.
• Ein eingeschränkter Clientnetzwerkbereich.

Für das folgende Runtime-Beispiel benötigt die AWS-Identität des Gateways bedrock:InvokeModel für das ausgewählte Inferenzprofil und das Standardprojekt des Kontos. Die erforderlichen Berechtigungen finden Sie in der Einrichtungsanleitung für GPT-6 Sol von AWS.

Architektur

Bei dieser Bereitstellung liegt LiteLLM zwischen Codex und Bedrock, mit HTTPS an der Schnittstelle zum Client. Der Load Balancer und LiteLLM befinden sich innerhalb der Gateway-Grenze Ihrer Organisation; die Anbieterzugangsdaten verbleiben auf dem Gateway.

Beschränken Sie eingehenden Zugriff auf genehmigte Clients, halten Sie Datenbank- und Cache-Ports privat und gewähren Sie dem Gateway nur die benötigten Bedrock-Berechtigungen. Fixieren Sie das bereitgestellte Image anhand seines Digests, damit ein Neustart die Implementierung nicht unbemerkt ändert.

Prompts, Quellcodeauszüge und Tool-Ergebnisse passieren das Gateway und können in dessen Protokollen landen. Legen Sie Aufbewahrung, Zugriff und Schwärzung fest, bevor Sie die Anfrageprotokollierung aktivieren. MCP server und Plugins haben separate Verbindungen und Authentifizierung; diese Gateway-Konfiguration konfiguriert sie nicht.

Prüfpunkte für die Bereitstellung

Durchlaufen Sie diese Prüfpunkte in der angegebenen Reihenfolge, bevor Sie das Gateway an Entwickler übergeben:

Die folgenden Abschnitte behandeln jeden Prüfpunkt. Testen Sie für die Einführung in der Produktion auch Folgerunden, Tools und den Widerruf von Zugangsdaten.

Die Bedrock-Route wählen

Die LiteLLM-Upstream-Route bestimmt den Bedrock-Endpunkt, die Modellkennung und die Authentifizierungsmethode. Behandeln Sie diese Entscheidungen gemeinsam, wenn Sie das Gateway bereitstellen oder ändern.

Verwenden Sie Bedrock Runtime für neue Konfigurationen. Das folgende Beispiel verwendet dessen OpenAI-kompatiblen Responses-Endpunkt.

Informationen zur alternativen Route finden Sie in der Bedrock-Mantle-Integration von LiteLLM.

Verwenden Sie als AWS-Bereitstellungsbeispiel die auf eine feste Version festgelegte Referenz für LiteLLM auf ECS. Diese Implementierung verwendet Bedrock Runtime und aktualisiert die Authentifizierung über die ECS-Task-Rolle. Befolgen Sie die Bereitstellungs- und Authentifizierungsschritte gemeinsam und gleichen Sie die Produktionsanforderungen mit Ihren Richtlinien für Netzwerk, TLS, Protokollierung und Ressourcenaufbewahrung ab.

Unabhängig von der gewählten Route müssen Sie die bereitgestellte Kombination aus Gateway-Version, Upstream-Endpunkt und Modell anhand der Gateway-Kompatibilität überprüfen. Dass ein Upstream-Modell in der Modellliste des Gateways erscheint, belegt nicht, dass sein Streaming-, Fortsetzungs- und Tool-Verhalten mit Codex funktioniert.

Eine Runtime-Modellroute konfigurieren

Ordnen Sie einen stabilen, für Codex sichtbaren Alias dem genehmigten Upstream-Modell zu. Bestätigen Sie den Zugriff in Ihrem AWS-Konto und Ihrer Region, bevor Sie dieses Runtime-Beispiel verwenden.

model_list:
  - model_name: company-coding-model
    litellm_params:
      model: openai/global.openai.gpt-6-sol
      api_key: os.environ/AWS_BEARER_TOKEN_BEDROCK
      api_base: https://bedrock-runtime.us-east-1.amazonaws.com/openai/v1

Stellen Sie einen gültigen Bedrock API key als AWS_BEARER_TOKEN_BEDROCK über Ihr Geheimnisverwaltungssystem bereit. Stellen Sie bei einem kurzlebigen Schlüssel vor dessen Ablauf einen Ersatz aus, aktualisieren Sie die Prozessumgebung des Gateways und starten Sie die Worker, die ihn verwenden, neu oder stellen Sie diese erneut bereit. Die ECS-Referenz aktualisiert Zugangsdaten stattdessen innerhalb des Prozesses über ihre Task-Rolle; verwenden Sie deren Konfiguration und Einstiegspunkt gemeinsam.

Das Präfix openai/ wählt den OpenAI-kompatiblen Adapter von LiteLLM aus; der konfigurierte Wert api_base sendet Anfragen an Bedrock Runtime. Das globale Inferenzprofil kann Anfragen außerhalb der Ursprungsregion weiterleiten. Wählen Sie ein Profil und eine Region, die Ihren AWS-Berechtigungen und Anforderungen an die Datenresidenz entsprechen, und ersetzen Sie beide Werte nach Bedarf.

Der Client sendet company-coding-model; LiteLLM verwendet die konfigurierte Upstream-Route. Dieser benutzerdefinierte Alias benötigt den im nächsten Abschnitt beschriebenen passenden Clientkatalog. Ein allgemeines Gateway übernimmt nicht die Metadatenanpassungen des integrierten Bedrock-Anbieters.

Den Clientkatalog vorbereiten

Beginnen Sie für dieses GPT-6 Sol/Runtime-Beispiel mit Codex 0.158.0 mit dem vollständigen Eintrag gpt-6-sol aus dem Modellkatalog dieser Version. Wenden Sie alle folgenden Änderungen auf diesen Eintrag an:

Behalten Sie die übrigen Felder bei, einschließlich der Anweisungen und Kontextgrenzen des Modells. Belassen Sie den bearbeiteten Eintrag im Array models auf der obersten Ebene des Katalogs. Diese Änderungen entsprechen den veröffentlichten Bedrock-Metadatenanpassungen und der Runtime-Suchbeschränkung. Prüfen Sie diese erneut anhand des zugehörigen Quellcodes, wenn Sie die Clientversion oder das Upstream-Modell ändern.

Verteilen Sie die vollständige JSON-Datei und konfigurieren Sie model_catalog_json gemäß Codex über ein Gateway bereitstellen. Behalten Sie web_search = "disabled" in der Runtime-Clientkonfiguration bei. Überprüfen Sie den bearbeiteten Katalog über das Gateway, bevor Sie ihn an weitere Benutzer verteilen.

Responses-Unterstützung überprüfen

Stellen Sie POST /v1/responses am clientseitigen HTTPS-Endpunkt bereit. Konfigurieren Sie den Load Balancer und alle Reverse Proxys so, dass sie Streaming-Ereignisse ohne Pufferung weiterleiten. Behalten Sie Folgerunden und Funktionsaufrufergebnisse bei. Ein funktionierender Chat-Completions-Endpunkt allein reicht für diese Verbindung nicht aus.

Führen Sie die Prüfungen unter Gateway-Kompatibilität durch, bevor Sie die Clientkonfiguration verteilen. Testen Sie über denselben Hostnamen, dieselben Netzwerkkontrollen und denselben Authentifizierungsweg, die Ihre Benutzer verwenden werden.

Testzugangsdaten ausstellen

Erstellen Sie einen virtuellen LiteLLM-Schlüssel mit eingeschränktem Berechtigungsumfang für einen Testbenutzer. Beschränken Sie ihn auf den genehmigten Alias und konfigurieren Sie Ablaufzeitpunkt, Ratenbegrenzungen und Budget. Die verfügbaren Steuerungsmöglichkeiten finden Sie in der Dokumentation zu virtuellen Schlüsseln von LiteLLM.

Verteilen Sie den Schlüssel über Ihren Geheimnisverwaltungsprozess oder ein Authentifizierungshilfsprogramm. Geben Sie Benutzern nicht den LiteLLM-Administratorschlüssel und betten Sie keine Gateway-Zugangsdaten in config.toml ein.

Die Benutzerverbindung überprüfen

Führen Sie diese Prüfungen durch, bevor Sie den Zugriff erweitern:

1. Bestätigen Sie, dass das HTTPS-Zertifikat zum Gateway-Hostnamen passt und der Dienst ordnungsgemäß funktioniert.
2. Verbinden Sie einen Benutzer gemäß Verbindung mit einem Gateway herstellen.
3. Führen Sie einen kurzen Prompt, eine Folgerunde und eine schreibgeschützte Tool-Aufgabe aus.
4. Bestätigen Sie, dass die Gateway-Protokolle die erwartete Identität, den Alias und die Upstream-Route zeigen, ohne Zugangsdaten oder sensible Prompt-Inhalte offenzulegen.
5. Testen Sie den Ablauf oder Widerruf von Zugangsdaten und bestätigen Sie, dass nicht autorisierte Modellaliase abgelehnt werden.

Bewahren Sie die bereitgestellte Image-Version, die Routenkonfiguration und die Testergebnisse zusammen mit Ihrer Einführungsdokumentation auf. Fahren Sie für die Verteilung im Team und den laufenden Betrieb mit Codex über ein Gateway bereitstellen fort.

Verbindungsprobleme beheben

Grenzen Sie das Problem anhand der fehlerhaften Ebene ein:

Testen Sie nach einer Korrektur denselben Benutzerverbindungsweg erneut. Eine erfolgreiche Gateway-Zustandsprüfung überprüft weder eine authentifizierte Inferenzanfrage noch eine vollständige Codex-Runde.