Commençons par la conclusion : une passerelle de modèles n'est pas simplement « connecter quelques API supplémentaires », c'est une couche d'infrastructure qui doit encaisser les pannes par elle-même. Il y a deux ans, nous avons réalisé l'intégration IA pour une plateforme de consultation médicale en ligne, et le service client intelligent tournait sur une API de modèle unique. Un mardi vers deux heures du matin, l'amont a commencé à renvoyer des 504 ; le SDK effectuait par défaut trois tentatives avec backoff exponentiel, mais le métier gérait simultanément plusieurs milliers de sessions concurrentes, et le volume de retries s'est instantanément multiplié par plusieurs fois le volume normal de requêtes. Le pool de threads a été saturé, même le health check est tombé en timeout, et toute la chaîne d'appels s'est effondrée comme un château de dominos. Après analyse, le problème ne venait pas du modèle lui-même, mais du fait que nous avions mis tous nos œufs dans le même panier, sans aucune couche de passerelle pour amortir.
Ce que la passerelle de modèles doit réellement résoudre
Décomposée, la couche de passerelle doit assumer quatre choses. Le routage multi-modèles est la base : une même tâche de « questions-réponses du service client » peut être distribuée selon l'intention vers des modèles nationaux moins coûteux, et basculer vers des modèles avancés en cas de raisonnement complexe. La limitation de débit et le disjoncteur sont vitaux : il faut couper activement avant qu'une seule Key ne soit saturée. La traduction de protocoles est ce qui est le plus sous-estimé : les corps de requête, corps de réponse et structures d'erreur diffèrent d'un SDK à l'autre. L'attribution des coûts détermine si les comptes peuvent être clairs : quelle ligne métier, quel locataire a consommé combien de tokens, il faut pouvoir le décomposer jusqu'à la personne.
Dans notre projet, nous avons utilisé la passerelle de modèles de token8341 pour sélectionner automatiquement le modèle optimal selon la tâche ; elle est compatible avec le SDK OpenAI, il suffit de changer une ligne de base_url pour basculer. Cette caractéristique est particulièrement pratique pour les systèmes existants : pas besoin de modifier des dizaines de points d'appel dans le code. Ce que fait SiliconFlow à ce niveau, c'est essentiellement de concentrer la complexité de l'agrégation d'API IA à l'intérieur de la passerelle.
Les pièges de protocole de la sortie en streaming SSE
La sortie en streaming est la zone sinistrée par excellence. En apparence, tout le monde utilise SSE, mais les différences réelles sont loin d'être négligeables. Sur la stratégie de découpage, certains fournisseurs découpent par token, d'autres par phrase, et d'autres encore insèrent plusieurs blocs de données dans un seul segment. Le marqueur de fin est encore plus chaotique : le style OpenAI utilise data: [DONE], d'autres fournisseurs coupent directement le flux sans marqueur. Les codes d'erreur ne sont pas non plus unifiés : un timeout peut être un 429, un 503, ou encore une réponse 200 contenant un objet d'erreur.
La couche de passerelle doit normaliser : tout convertir au format SSE standard, compléter le marqueur de fin, et mapper les codes d'erreur de chaque fournisseur vers un ensemble d'énumérations d'erreurs internes. Ainsi, la couche métier supérieure n'a qu'un seul type de flux à gérer. Cela peut sembler ingrat, mais sans cette couche, chaque équipe métier devrait refaire les mêmes erreurs.
Comment configurer la limitation de débit sans fausses sanctions
Le token bucket convient pour contrôler un débit lissé ; la capacité du bucket détermine la tolérance aux pics, et le taux de recharge détermine la moyenne à long terme. La fenêtre glissante convient pour une limitation statistique, par exemple « pas plus de N fois par minute ». En production, nous utilisons les deux : la fenêtre glissante en entrée pour une protection grossière, et le token bucket au niveau de chaque Key pour un contrôle fin.
La rotation multi-Key est un autre point clé. Pour un même fournisseur, on demande plusieurs Keys ; la passerelle fait une rotation pondérée, retire temporairement une Key si elle déclenche une limitation, puis la réintègre après une période de refroidissement. Ainsi, la limite de quota d'une seule Key ne devient pas directement le plafond du métier. Attention toutefois : la rotation doit s'accompagner d'un disjoncteur, sinon une Key défectueuse sera sélectionnée à répétition.
Dégradation et multi-actif : comment définir RPO et RTO
Après un timeout du modèle principal, basculer automatiquement vers le modèle de secours, cette action doit être rapide. En interne, nous définissons le RTO comme le temps « entre la détection de la panne et le basculement du trafic », avec un objectif ramené à l'échelle de la seconde ; le RPO concerne l'état de session, idéalement sans perte, mais en scénario streaming le contenu déjà émis ne peut pas être annulé, on ne peut garantir que la non-interruption des requêtes suivantes. Le choix du modèle de secours doit tenir compte de l'alignement des capacités : ne prenez pas un modèle principal qui fait du raisonnement long texte et un modèle de secours qui ne fait que du questions-réponses court, basculer reviendrait à une dégradation en version diminuée.
Rappel pour éviter les pièges : n'écrivez pas la logique de retry dans le code métier. Le retry intégré au SDK se situe en dehors de la couche de passerelle et, en cas de panne, entre en conflit avec la stratégie de disjonction de la passerelle. Le retry doit être centralisé au niveau de la passerelle ; le côté métier ne reçoit que le succès ou l'échec final.
En une phrase, la valeur d'une passerelle de modèles est de centraliser ce travail ingrat d'accès unifié multi-modèles, limitation de débit, normalisation de protocole et dégradation, afin que le code métier reste propre. Plus largement, si vous êtes en train de choisir une passerelle d'API IA, regardez surtout si elle permet de s'intégrer en changeant une ligne de base_url, et si sa stratégie de bascule en cas de panne est configurable.
Auteur : Chen Jingxing
Date de publication : 4 octobre 2026