Bedrock via LiteLLM

Utilisez cette page lorsque votre organisation achemine les requêtes de Codex vers Amazon Bedrock via LiteLLM. Si une passerelle LiteLLM existe déjà, connectez d’abord Codex. Déployez LiteLLM uniquement lorsque votre organisation a besoin d’une nouvelle passerelle.

Les autres produits de passerelle suivent les mêmes exigences relatives aux passerelles et la même procédure de connexion de Codex.

Se connecter à une passerelle existante

Obtenez ces valeurs auprès de l’administrateur de votre passerelle :

• L’URL de base HTTPS, par exemple https://gateway.example.com/v1.
• L’alias de modèle que LiteLLM achemine vers un modèle Bedrock approuvé.
• L’identifiant du fournisseur à utiliser dans la configuration de Codex.
• Un identifiant de passerelle avec des droits limités ou un utilitaire d’authentification qui le renvoie.
• Tout catalogue de modèles distribué avec la configuration de votre organisation.

Effectuez ensuite la connexion dans cet ordre :

1. Demandez à votre équipe passerelle de confirmer que la passerelle expose POST /v1/responses, diffuse les réponses en continu, préserve les échanges de suivi et les appels d’outils, et achemine l’alias approuvé. Consultez Compatibilité des passerelles.
2. Suivez la procédure Se connecter à une passerelle pour configurer le fournisseur, le modèle et l’identifiant.
3. Vérifiez le fournisseur et l’alias actifs, envoyez le prompt court gateway-ok du guide de connexion, puis confirmez que le journal de LiteLLM indique l’utilisateur et l’alias attendus.
4. Pour une distribution à l’échelle de l’organisation, poursuivez avec Déployer Codex via une passerelle.

Votre identifiant de passerelle vous authentifie auprès de LiteLLM. La passerelle gère ses propres identifiants Bedrock ; vous n’avez pas besoin de les copier sur votre poste de travail.

Préparer une passerelle

Utilisez cette section uniquement si vous devez créer une passerelle LiteLLM avant de connecter Codex.

Avant le déploiement

Vérifiez que vous disposez des éléments suivants :

• L’autorisation de déployer l’architecture LiteLLM approuvée dans votre environnement AWS.
• L’accès Bedrock aux modèles ou profils d’inférence vers lesquels vous acheminerez les requêtes.
• Une image LiteLLM et un schéma de déploiement validés.
• Un nom d’hôte HTTPS et un certificat de confiance.
• Une plage réseau restreinte pour les clients.

Pour l’exemple Runtime ci-dessous, l’identité AWS de la passerelle a besoin de bedrock:InvokeModel pour le profil d’inférence sélectionné et le projet par défaut du compte. Consultez les instructions de configuration de GPT-6 Sol d’AWS pour connaître les autorisations requises.

Architecture

Le déploiement place LiteLLM entre Codex et Bedrock, avec HTTPS à l’interface avec le client. L’équilibreur de charge et LiteLLM se trouvent dans le périmètre de la passerelle de votre organisation ; l’identifiant du fournisseur reste sur la passerelle.

Limitez l’accès entrant aux clients approuvés, gardez les ports de la base de données et du cache privés, et accordez à la passerelle uniquement les autorisations Bedrock dont elle a besoin. Fixez l’image déployée par son empreinte afin qu’un redémarrage ne modifie pas silencieusement l’implémentation.

Les prompts, les extraits de code source et les résultats d’outils passent par la passerelle et peuvent figurer dans ses journaux. Définissez les règles de conservation, d’accès et de masquage des données sensibles avant d’activer la journalisation des requêtes. Les MCP servers et les plugins ont des connexions et une authentification distinctes ; cette configuration de passerelle ne les configure pas.

Étapes de contrôle du déploiement

Effectuez ces étapes de contrôle dans l’ordre avant de mettre la passerelle à disposition des développeurs :

Les sections ci-dessous couvrent chaque étape de contrôle. Pour un déploiement en production, testez également les échanges de suivi, les outils et la révocation des identifiants.

Choisir la route Bedrock

La route en amont de LiteLLM détermine le point de terminaison Bedrock, l’identifiant du modèle et la méthode d’authentification. Traitez ces choix ensemble lorsque vous déployez ou modifiez la passerelle.

Utilisez Bedrock Runtime pour les nouvelles configurations. L’exemple ci-dessous utilise son point de terminaison Responses compatible avec OpenAI.

Consultez l’intégration Bedrock Mantle de LiteLLM pour l’autre route possible.

Pour un exemple de déploiement AWS, utilisez la référence LiteLLM sur ECS dont la version est fixée. Cette implémentation utilise Bedrock Runtime et renouvelle l’authentification à partir du rôle de tâche ECS. Suivez conjointement ses étapes de déploiement et d’authentification, et évaluez ses exigences de production au regard de vos politiques de réseau, de TLS, de journalisation et de conservation des ressources.

Quelle que soit la route choisie, vérifiez la combinaison déployée de version de passerelle, de point de terminaison en amont et de modèle au regard de la Compatibilité des passerelles. La présence d’un modèle en amont dans la liste des modèles de la passerelle ne garantit pas que sa diffusion en continu, sa continuité des échanges et son comportement avec les outils fonctionnent avec Codex.

Configurer une route de modèle Runtime

Associez un alias stable exposé à Codex au modèle en amont approuvé. Confirmez l’accès dans votre compte et votre région AWS avant d’utiliser cet exemple Runtime.

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

Fournissez une API key Bedrock valide sous la forme AWS_BEARER_TOKEN_BEDROCK via votre système de gestion des secrets. Pour une clé à courte durée de validité, émettez une clé de remplacement avant son expiration, mettez à jour l’environnement du processus de passerelle, puis redémarrez ou redéployez les processus de travail qui l’utilisent. La référence ECS renouvelle quant à elle les identifiants au sein du processus à partir de son rôle de tâche ; utilisez ensemble sa configuration et son point d’entrée.

Le préfixe openai/ sélectionne l’adaptateur de LiteLLM compatible avec OpenAI ; la valeur configurée de api_base envoie les requêtes à Bedrock Runtime. Le profil d’inférence Global peut acheminer les requêtes hors de la région source. Choisissez un profil et une région qui respectent vos autorisations AWS et vos exigences de résidence des données, et remplacez ces deux valeurs si nécessaire.

Le client envoie company-coding-model ; LiteLLM utilise la route en amont configurée. Cet alias personnalisé nécessite le catalogue client correspondant décrit ci-après. Une passerelle générique n’hérite pas des ajustements de métadonnées du fournisseur Bedrock intégré.

Préparer le catalogue client

Pour cet exemple GPT-6 Sol/Runtime avec Codex 0.158.0, partez de l’entrée complète gpt-6-sol du catalogue de modèles de cette version. Appliquez toutes les modifications suivantes à cette entrée :

Préservez les autres champs, y compris les instructions du modèle et les limites de contexte. Conservez l’entrée modifiée dans le tableau models de premier niveau du catalogue. Ces modifications reproduisent les ajustements de métadonnées Bedrock et la restriction de recherche de Runtime publiés. Vérifiez-les à nouveau dans le code source correspondant lorsque vous changez de version du client ou de modèle en amont.

Distribuez le fichier JSON complet et configurez model_catalog_json en suivant Déployer Codex via une passerelle. Conservez web_search = "disabled" dans la configuration du client Runtime. Vérifiez le catalogue modifié via la passerelle avant de le distribuer à davantage d’utilisateurs.

Vérifier la prise en charge de Responses

Exposez POST /v1/responses sur le point de terminaison HTTPS destiné aux clients. Configurez l’équilibreur de charge et tout proxy inverse pour transmettre les événements en continu sans mise en mémoire tampon. Préservez les échanges de suivi et les résultats d’appels de fonctions. Un point de terminaison Chat Completions fonctionnel ne suffit pas à lui seul pour cette connexion.

Effectuez les vérifications de la section Compatibilité des passerelles avant de distribuer la configuration client. Testez avec le même nom d’hôte, les mêmes contrôles réseau et le même chemin d’authentification que ceux qu’utiliseront vos utilisateurs.

Délivrer un identifiant de test

Créez une clé virtuelle LiteLLM avec des droits limités pour un utilisateur de test. Limitez-la à l’alias approuvé et configurez son expiration, ses limites de débit et son budget. Consultez la documentation des clés virtuelles de LiteLLM pour connaître les contrôles applicables.

Distribuez la clé via votre processus de gestion des secrets ou un utilitaire d’authentification. Ne donnez pas aux utilisateurs la clé d’administration de LiteLLM et n’intégrez pas d’identifiants de passerelle dans config.toml.

Vérifier la connexion de l’utilisateur

Effectuez ces vérifications avant d’élargir l’accès :

1. Confirmez que le certificat HTTPS correspond au nom d’hôte de la passerelle et que le service fonctionne correctement.
2. Connectez un utilisateur en suivant Se connecter à une passerelle.
3. Exécutez un prompt court, un échange de suivi et une tâche utilisant un outil en lecture seule.
4. Confirmez que les journaux de la passerelle indiquent l’identité, l’alias et la route en amont attendus, sans exposer d’identifiants ni de contenu sensible des prompts.
5. Testez l’expiration ou la révocation des identifiants et confirmez que les alias de modèles non autorisés sont rejetés.

Conservez la version de l’image déployée, la configuration des routes et les résultats des tests dans votre dossier de déploiement. Poursuivez avec Déployer Codex via une passerelle pour la distribution à l’équipe et l’exploitation courante.

Résoudre les problèmes de connexion

Appuyez-vous sur la couche défaillante pour cerner le problème :

Après une correction, testez à nouveau le même parcours utilisateur. Un contrôle d’état réussi de la passerelle ne valide pas une requête d’inférence authentifiée ni un échange Codex complet.