Concevoir le basculement entre fournisseurs de modèles OpenAI

Lorsqu’une entreprise dépend d’un workflow d’IA, même une panne de courte durée chez un fournisseur peut retarder des décisions ou interrompre des services. Nous travaillons avec des clients du secteur financier qui utilisent les modèles OpenAI pour développer des applications agentiques et des workflows de cybersécurité. Cet article présente notre approche du routage en production et de la reprise des charges de travail critiques. Nous prenons comme fil conducteur une évaluation du risque de fraude en lecture seule dans un workflow de paiement.

Dans cet article, l’accès direct (1P) désigne l’accès à l’API OpenAI et l’accès tiers (3P) désigne l’accès aux modèles OpenAI par l’intermédiaire d’un fournisseur cloud, quel que soit l’environnement d’exécution de l’application. Nous verrons ce qu’apporte l’accès direct aux modèles et aux fonctionnalités en préversion, comment les besoins du workflow et les connexions privées orientent le choix de la route, et quelles opérations peuvent basculer en toute sécurité. Nous proposerons ensuite un prompt Codex pour mettre en œuvre la politique de basculement dans une passerelle existante et préciserons les vérifications à effectuer avant de l’activer.

Pourquoi utiliser les deux routes ?

L’accès direct à OpenAI présente un intérêt même si le trafic de production passe par un fournisseur cloud. L’un de ses principaux avantages est l’accès aux modèles et aux fonctionnalités en préversion. Lorsqu’ils sont disponibles via l’API directe, les équipes éligibles peuvent les évaluer sur leurs propres workflows avant leur prise en charge par le fournisseur cloud qu’elles ont choisi.

L’environnement d’exécution du workflow influe souvent sur le choix de la route de production. Un service cloud tiers peut s’intégrer à l’infrastructure et aux contrôles d’exploitation existants d’une application, tandis qu’un accès direct à OpenAI peut mieux répondre aux exigences d’un autre workflow. Validez les modèles, les fonctionnalités et le comportement requis sur la route retenue, et utilisez l’accès direct à OpenAI pour poursuivre vos expérimentations. Les possibilités dépendent du fournisseur, du point de terminaison, de la région et de votre compte.

Pour les charges de travail critiques, nous envisageons aussi le basculement entre les routes 1P et 3P après validation. Basculer vers un autre fournisseur consiste à retenter une requête auprès d’un fournisseur approuvé lorsque le fournisseur principal ne peut pas la traiter. Cette solution n’est utile que si la requête peut être répétée sans risque et si la route de secours répond aux exigences du workflow.

Un prestataire mondial de services de paiement pourrait utiliser l’API Responses pour réaliser une évaluation autonome du risque de fraude en lecture seule. Si le délai d’attente de l’appel expire avant que son résultat soit utilisé, l’application peut retenter l’appel via une route secondaire validée, dans le délai imparti à la transaction.

Une session en cours de l’API Agents nécessite une autre stratégie de reprise. Changer de fournisseur ne suffit pas à reprendre la conversation et le travail enregistré, ni à vérifier et à rapprocher les résultats des actions déjà engagées. Cette reprise est nettement plus complexe et dépasse le cadre de cet article.

Nous distinguons donc deux responsabilités : la plateforme prend en charge plusieurs fournisseurs et chaque workflow détermine si un basculement est approprié.

Routage planifié et basculement

Choisir une route de production et approuver le basculement sont deux décisions distinctes. Le routage planifié peut consister à répartir le trafic entre plusieurs fournisseurs ou à acheminer le surplus de requêtes vers une autre route. Ces stratégies nécessitent leurs propres tests de capacité, de coût, de qualité et de reprise.

Certains de nos clients utilisent l’API Decisions comme source d’information facultative pour leurs décisions de routage. Pour que le workflow reste opérationnel, définissez le comportement du routage en cas d’indisponibilité de ce service.

Dans les schémas, la route 1P est la route principale et une route 3P approuvée sert de route secondaire. Selon la charge de travail, l’une ou l’autre peut être la route principale.

Rôle du routeur

Figure 1. L’API OpenAI sert de route principale et un fournisseur tiers approuvé de route secondaire. La plateforme exploite le routeur et l’application définit la politique. Les modèles, les fonctionnalités, la capacité, les contrôles et la disponibilité peuvent varier d’une route à l’autre.

Vous pouvez utiliser votre routeur de modèles ou votre passerelle LLM existante si le composant choisi permet d’appliquer des règles distinctes à chaque route. Acheminez le trafic normal vers la route principale. Utilisez la route secondaire testée uniquement lorsque les conditions de basculement sont réunies.

Définissez qui peut utiliser chaque route, dans quelles régions et avec quels modèles et API. Consignez les entités juridiques, les équipes et les comptes ou projets approuvés chez les fournisseurs, ainsi que les règles de traitement des données. L’approbation ne vaut que pour les charges de travail et les régions convenues.

Connexions privées et choix de la route

Dans les secteurs réglementés, de nombreux clients exigent des connexions privées dans le cadre de leurs contrôles de sécurité. Pour eux, choisir une route suppose aussi de vérifier comment l’environnement cloud de leur application peut se connecter à chaque fournisseur par un réseau privé. Le schéma montre une application et une passerelle dans le réseau privé d’un client, avec une liaison privée distincte vers chaque fournisseur.

Figure 2. L’API OpenAI (1P) sert de route principale et un fournisseur approuvé (3P), tel qu’Amazon Bedrock ou Azure OpenAI, de route secondaire. Seul le trafic de reprise éligible emprunte la route secondaire.

À la date de publication, les options de connexion privée diffèrent entre les routes 1P et 3P. Pour l’accès direct à OpenAI (1P), OpenAI Private Link utilise un point de terminaison privé Azure. Pour emprunter cette route privée vers l’API directe d’OpenAI depuis AWS ou Google Cloud, le client doit gérer lui-même la connexion à Azure.

Pour l’accès tiers (3P), Amazon Bedrock utilise des points de terminaison de VPC de type interface propres à chaque API via AWS PrivateLink, tandis qu’Azure OpenAI utilise des points de terminaison privés Azure. Avant d’activer le basculement, vérifiez le DNS, les accès et la prise en charge régionale des modèles et des API sur les deux routes. OpenAI Private Link ne bascule pas automatiquement d’un point de terminaison régional à l’autre. La reprise dans une autre région nécessite donc une configuration et des tests distincts. Toute reprise via un accès public en HTTPS nécessite également une approbation explicite.

Les fonctionnalités prises en charge par les fournisseurs peuvent évoluer. Consultez la documentation officielle avant de choisir ou d’activer une route.

Quelles opérations peuvent basculer ?

Certaines opérations ne disposent pas d’une route secondaire adaptée. Par exemple :

• Fonctionnalité manquante : un workflow peut utiliser la recherche web via l’API directe d’OpenAI pour vérifier des informations à jour. Si la route secondaire ne prend pas en charge cette fonctionnalité, ne sautez pas l’étape de recherche sans le signaler. Validez une autre implémentation ou laissez le basculement désactivé pour cette opération.
• Comportement non validé : un nom de modèle identique ou une API compatible ne suffit pas. Exécutez le harnais existant du workflow et ses évaluations sur la route secondaire avant de l’activer.
• Contraintes de résidence des données ou d’état : ne basculez pas vers une destination qui enfreint les exigences approuvées de localisation des données ou qui ne peut pas accéder à l’état nécessaire pour terminer l’opération en toute sécurité.

Si aucune route secondaire ne remplit les conditions, mettez les tâches en file d’attente dans la limite du délai convenu, utilisez un mode dégradé approuvé ou une procédure manuelle approuvée, ou arrêtez le traitement en toute sécurité. Une étape d’inférence qui peut être répétée peut remplir les conditions de basculement, même si le workflow complet ne les remplit pas.

Si le délai d’attente d’une évaluation du risque de fraude en lecture seule expire, une nouvelle tentative est envisageable à condition que son résultat n’ait pas été utilisé et qu’il reste suffisamment de temps. Dès que la sortie atteint un autre système, la reprise nécessite une procédure de redémarrage testée. Si une action a peut-être déjà abouti, vérifiez son résultat et prenez les mesures nécessaires pour éviter de l’exécuter deux fois avant de redémarrer.

Quand et comment basculer

Dans notre exemple de paiement, si un modèle est saturé ou indisponible, un autre modèle approuvé peut le remplacer : c’est le recours à un modèle de secours. Retenter l’évaluation auprès d’un autre fournisseur constitue un basculement de fournisseur. Il arrive que l’on change à la fois de modèle et de fournisseur.

Nous cherchons d’abord à savoir si changer de fournisseur résoudrait le problème. Une passerelle, un service de récupération de données ou un système d’identité commun peut affecter les deux routes. Testez la connectivité, les accès et la capacité de la route secondaire. Vérifiez que la reprise régionale est possible pour vos modèles et vos outils hébergés, dans le respect de vos exigences de localisation des données.

Si les échecs ou les lenteurs persistent, un disjoncteur peut suspendre l’envoi de nouvelles requêtes sur la route touchée. Fixez des seuils d’erreur et de temps de réponse par fournisseur, modèle, région et workflow. Chaque requête doit toujours remplir les conditions de basculement.

Avant de retenter une requête, vérifiez qu’elle peut être répétée sans risque et aboutir dans le délai imparti au workflow. La route secondaire doit être approuvée, activée, opérationnelle et testée pour la charge supplémentaire. Il doit aussi rester du budget. Consultez la documentation d’OpenAI sur les codes d’erreur et les limites de débit. Vérifiez également les règles des autres fournisseurs en matière d’erreurs, de nouvelles tentatives, de quotas et de facturation.

Le tableau ci-dessous propose des règles prudentes pour commencer à automatiser le basculement. Tenez compte des détails de l’erreur fournis par chaque fournisseur, au-delà du seul code de statut HTTP.

Confiez le contrôle des nouvelles tentatives à une seule couche pour éviter que celles de l’application, du SDK et de la passerelle se multiplient. Utilisez un budget de tentatives commun et respectez les indications Retry-After lorsqu’elles sont valides. À défaut, appliquez une temporisation exponentielle bornée avec une part d’aléa : augmentez le délai entre les tentatives, faites-le varier aléatoirement et limitez le nombre de tentatives. Ne retentez que les appels d’inférence qui peuvent être répétés sans risque, en respectant à la fois le délai de la requête et celui du workflow.

Limitez le trafic de basculement pour éviter de saturer la route secondaire. Rétablissez progressivement le trafic sur la route principale une fois que des requêtes représentatives respectent les seuils d’erreur et de temps de réponse pendant une durée définie. Suspendez cette montée en charge si les seuils sont dépassés. Si les deux routes atteignent leurs limites, appliquez la politique de reprise convenue pour le workflow.

Mettre en œuvre la politique de basculement avec Codex

Nous pouvons maintenant utiliser Codex pour intégrer ces règles de reprise à une passerelle LLM existante. Dans l’exemple du paiement, nous limitons les modifications à l’étape autonome d’évaluation du risque de fraude en lecture seule. La route principale reste en place et le basculement reste désactivé jusqu’à l’approbation et à la validation de la route secondaire.

Dans Codex, ouvrez le dépôt qui contient la configuration de la passerelle ou la logique de routage de l’application, puis adaptez le prompt ci-dessous à votre workflow et aux routes envisagées.

Ajoutez un mécanisme de basculement vers un autre fournisseur, désactivé par défaut, pour [workflow’s self-contained, read-only inference step] dans [repository/gateway]. Conservez la route principale et réutilisez la passerelle existante, les routes approuvées de la plateforme et la politique du workflow.

Examinez les versions de la passerelle, du SDK et des adaptateurs, la configuration de déploiement, les API et la documentation officielle à jour. Distinguez les modifications de l’application de celles de la passerelle et précisez, pour chacune, le responsable et la revue requise. Fournissez la configuration et les tests d’intégration pour les dépendances qui relèvent d’autres équipes. Signalez les contrôles non pris en charge. Ne présumez ni des approbations ni des limites applicables. Tant que vous ne les avez pas vérifiées, laissez désactivées les routes de basculement qui en dépendent.

Utilisez une classification des erreurs testée pour chaque fournisseur. N’autorisez le basculement qu’en cas de défaillance passagère du service ou du réseau, ou de limitation de débit dont le caractère temporaire est confirmé. Dans tous ces cas, vérifiez que la requête peut être répétée sans risque et que la route secondaire est approuvée, activée et opérationnelle. Elle doit aussi offrir les fonctionnalités et les contrôles sur les données requis, disposer d’une capacité vérifiée par des tests et avoir suffisamment de budget et de temps pour terminer la requête. Bloquez le basculement en cas de requête invalide, d’échec d’accès, de refus, d’épuisement du quota, des crédits ou du budget, d’erreur inconnue ou d’erreur 429 ambiguë.

Utilisez un seul mécanisme de contrôle des nouvelles tentatives pour le client, la passerelle et le SDK. Désactivez les enchaînements de nouvelles tentatives et de basculements qui entrent en conflit. Imposez un plafond commun au nombre total de tentatives et respectez à la fois le délai de la requête et celui du workflow. Appliquez à chaque tentative le délai d’attente configuré, sans dépasser le délai global. N’acceptez qu’un résultat par requête logique et ignorez les réponses tardives des tentatives précédentes. Respectez la valeur de Retry-After lorsqu’elle est valide. À défaut, appliquez une temporisation exponentielle bornée avec une part d’aléa. Ne relancez jamais à l’aveugle une requête qui a produit une sortie partielle. Ne répétez jamais à l’aveugle une action dont le résultat est incertain. Ne supposez pas que l’état se transfère d’un fournisseur à l’autre. Appliquez la politique approuvée, qu’elle prévoie une mise en file d’attente, un résultat réduit ou un arrêt. Prévoyez la désactivation manuelle du basculement, un disjoncteur et le retour progressif à la route principale.

Testez le chemin réellement emprunté par les requêtes à l’aide de services HTTP simulés localement, en bloquant les connexions réseau externes. Vérifiez par des assertions l’ordre des routes empruntées, le nombre d’appels et le temps écoulé dans chacun des cas suivants : réussite, défaillance autorisant le basculement, chaque catégorie d’erreurs bloquant le basculement, condition d’éligibilité non remplie, sortie partielle, action au résultat incertain, épuisement des budgets, défaillance des deux routes et déclenchement des contrôles de reprise. Dans les cas bloqués, vérifiez qu’aucun appel n’est envoyé à la route secondaire. Réservez les limites fictives aux jeux de données de test et protégez les secrets. Sans autorisation, n’effectuez aucun appel aux services réels et ne procédez à aucun déploiement.

Fournissez des correctifs minimaux, les tests en indiquant les exigences couvertes par chacun, les résultats, les instructions de retour arrière et la liste des vérifications restant à effectuer sur les services réels. Laissez désactivées toutes les routes de basculement qui n’ont pas été vérifiées.

Ce prompt demande à Codex une modification ciblée de la passerelle, des tests qui montrent dans quels cas la route secondaire doit être appelée ou écartée, et la liste des vérifications restant à effectuer sur les routes réelles. Examinez d’abord le correctif et les résultats des tests locaux. Avant d’activer le basculement, validez ensuite le comportement des modèles, les contrôles sur les données, la capacité et la reprise sous charge.

Valider les routes et la reprise

L’exemple du paiement illustre des vérifications qui s’appliquent aussi à d’autres charges de travail critiques. Testez les deux routes au regard des critères d’acceptation du workflow en matière de qualité, de sécurité, de format de sortie, d’utilisation des outils et de limites de contexte. Consignez la configuration testée, la disponibilité et les conditions d’accès, y compris les niveaux de traitement et les fonctionnalités hébergées, puis définissez quand renouveler les tests.

Les restrictions sur les données de l’évaluation, notamment les limites de journalisation des prompts et des sorties, s’appliquent en fonctionnement normal comme en phase de reprise. Avant d’activer l’une ou l’autre route, examinez les identifiants d’accès, les chemins réseau, la récupération de données, les outils, l’état enregistré et les journaux avec les responsables des affaires juridiques, de la protection de la vie privée, de la sécurité et de la gouvernance des données.

Pour cet examen, appuyez-vous sur la documentation des services et les contrats afin de confirmer où les données sont traitées et stockées, combien de temps elles sont conservées, comment elles sont chiffrées et qui contrôle les clés et les accès. L’emplacement d’un point de terminaison ou le recours à une connexion privée ne suffit pas à répondre à ces questions. Les contrôles, les conditions d’éligibilité et les responsabilités varient selon le point de terminaison. Consultez les contrôles des données d’OpenAI.

Même lorsqu’une route répond aux exigences, elle doit encore disposer d’une capacité suffisante pour absorber le trafic de reprise. Un tableau de bord agrégé à l’échelle du fournisseur peut masquer une limitation du débit sur le modèle d’évaluation du risque de fraude. Pour chaque route, suivez donc le débit de requêtes et de tokens, le nombre de requêtes simultanées, les limitations de débit, les temps de réponse et le budget approuvé restant, par modèle, compte ou projet, et région.

Pour vérifier que la route secondaire peut absorber la charge, testez-la en combinant son trafic habituel avec le trafic attendu des évaluations du risque de fraude et des nouvelles tentatives. Utilisez les résultats pour plafonner le trafic de basculement et déterminer quelles requêtes peuvent attendre, être traitées en mode dégradé ou être arrêtées. Le quota seul ne garantit pas que le traitement se terminera dans les délais.

Changer de route pour l’évaluation peut aussi modifier son coût et son temps de réponse. Comparez le coût par évaluation réussie en tenant compte des défauts de cache, des frais de transfert de données et des coûts de connexion. Mesurez également les délais supplémentaires dus aux défauts de cache ou au passage des requêtes d’un environnement cloud à un autre.

Enfin, testez sous charge les scénarios de défaillance du tableau, ainsi que les cas où une fonctionnalité manque ou la route secondaire est saturée ou indisponible. Vérifiez que la politique de reprise fonctionne comme prévu, y compris la limitation du trafic, l’arrêt manuel et le retour progressif à la route principale.

Évaluez la reprise selon le temps nécessaire au rétablissement du service, le nombre d’évaluations terminées dans les délais, la qualité des résultats, le coût et le nombre d’actions exécutées en double. Des exercices réguliers permettent de maintenir ces vérifications à jour à mesure que les identifiants expirent, que les configurations changent ou que la capacité évolue.

Qui est responsable de la reprise ?

Une organisation possible consiste à séparer les responsabilités du service de routage et de l’application. Une équipe plateforme pourrait gérer les intégrations avec les fournisseurs, le routeur, la supervision et les journaux d’audit. Elle veillerait à ce que le service de routage soit prêt pour la production et ferait appliquer les contrôles relatifs aux destinations, aux identités, aux données, au trafic et aux dépenses. Des responsables d’astreinte désignés pourraient désactiver les routes et gérer le retour à la route principale.

Dans cette organisation, les responsables de l’application définissent les opérations qui peuvent basculer, les objectifs de service et de qualité, ainsi que les fonctionnalités dont le workflow peut se passer en mode dégradé. Ils sont également responsables des résultats métier, du contexte enregistré pour la reprise, des autorisations accordées aux outils, de la vérification des réponses et de la prévention des actions en double, y compris lorsque l’état ou les outils sont partagés.

Votre équipe peut réunir ces rôles ou les répartir autrement. Avant d’activer le basculement, convenez ensemble de la répartition des responsabilités : qui approuve les contrôles, qui est responsable des tests des routes et des procédures d’exploitation, et qui a autorité pour intervenir en cas d’incident ?

Conclusion

Envisagez l’accès direct à OpenAI parmi les options à votre disposition, même si le trafic de production passe par un fournisseur cloud. Il permet aux équipes éligibles d’évaluer les modèles et les fonctionnalités en préversion et peut servir de route de reprise pour les charges de travail critiques. Pour la production, choisissez la route 1P ou 3P en fonction des fonctionnalités du workflow, de son environnement d’hébergement et de ses contrôles, notamment de la nécessité d’une connexion privée.

Pour une charge de travail critique, commencez par une seule étape d’inférence autonome en lecture seule. Codex peut vous aider à mettre en œuvre sa politique de routage dans la passerelle et à écrire les tests locaux. La validation sur les routes réelles permet ensuite d’établir si la route secondaire répond aux exigences du workflow. L’équipe dispose ainsi d’un plan de reprise concret qui précise quand basculer, quand arrêter le traitement et qui prend la décision.