Il était 2 h 40 du matin, et le groupe d'alertes de supervision a commencé à être inondé de messages. Nous assurions le support technique d'une équipe qui développe un système de service client pour le commerce transfrontalier. Le taux de dépassement de délai de leur API de service client intelligent est passé de 0,3 % en temps normal à 27 %, et cela a duré près d'une heure. Côté utilisateurs, le symptôme était le suivant : le robot de service client mettait un temps fou à répondre, et les agents n'avaient plus qu'à repasser temporairement en traitement manuel.
Après analyse, le problème ne venait pas de notre code, mais de l'amont : le cluster d'inférence d'un seul fournisseur de modèles a subi une limitation régionale du débit pendant cette période. Toutes nos requêtes partaient vers le même fournisseur, sans aucune solution de repli. Cet article expose en détail cet incident et le plan de refonte qui a suivi, pour servir de référence aux pairs qui travaillent sur l'intégration de l'IA en entreprise.
Les trois pièges de la dépendance à un point unique, nous les avons tous rencontrés
Beaucoup pensent qu'intégrer une API de grand modèle se résume à remplir une clé et envoyer une requête HTTP. Une fois en production, les pièges se concentrent en trois endroits.
Le premier est la limitation de débit. Le quota QPS du fournisseur est accordé par compte ; pendant les périodes de promotion, le volume de sessions de service client triple, le quota est instantanément saturé et renvoie des 429. À l'époque, nous n'avions mis en place ni file d'attente de requêtes ni backoff, et notre logique de nouvelle tentative était trop agressive, ce qui amplifiait la pression.
Le deuxième est le dépassement de délai. Une fois que l'interface en streaming (SSE) est bloquée en amont, la connexion reste suspendue longtemps sans rien renvoyer, et le client n'a plus qu'à attendre. Lors de cet incident, une bonne partie des requêtes n'échouaient pas, mais étaient « faussement vivantes » : la connexion TCP était toujours là, mais pas un seul token n'était émis.
Le troisième est la différence de protocoles. Les fournisseurs diffèrent dans le format de retour en streaming, les marqueurs de fin et la définition des codes d'erreur. La structure des événements SSE de l'API GPT-4o et de l'API Claude diffère, et les API nationales Qwen, DeepSeek ont chacune leurs propres champs. Si le code métier se connecte directement à plusieurs fournisseurs, c'est autant de if-else que l'on s'enfouit soi-même.
Solution de routage multi-modèles : classification, dégradation, normalisation, agrégation
Après l'incident, nous avons mené une refonte dont l'idée centrale est d'introduire une couche de passerelle de modèles, afin de sortir du code métier la question « quel modèle appeler ».
La classification des requêtes est la première étape. Nous avons réparti les requêtes en trois niveaux selon l'importance métier : les requêtes de dialogue en temps réel (service client, assistant de siège) exigent une latence P99 inférieure à 2 secondes ; la génération par lots (descriptions de produits, brouillons d'e-mails) peut tolérer une échelle de minutes ; les tâches hors ligne (annotation de données, résumés de rapports) sont entièrement asynchrones. Ce n'est qu'après la classification que la stratégie de routage a une base.
La dégradation automatique en cas de panne est la deuxième étape. Chaque modèle dispose d'une vérification de santé ; en cas d'échecs ou de dépassements de délai consécutifs au-delà d'un seuil, il est automatiquement retiré et le trafic bascule vers un modèle de secours. Notre seuil est déclenché lorsque le taux d'erreur dans une fenêtre glissante dépasse 5 %, avec un intervalle de sonde de rétablissement de 30 secondes. Une précision ici : la dégradation ne se fait pas à l'aveugle, il faut considérer le type de tâche — dans un scénario de service client, basculer vers un modèle aux capacités similaires est acceptable, mais pour les tâches de raisonnement complexe, il faut marquer les requêtes après dégradation pour une revue manuelle ultérieure.
La normalisation du protocole SSE est la troisième étape, et la plus laborieuse. Nous avons unifié le format de sortie en streaming au niveau de la passerelle ; le côté métier ne reconnaît qu'une seule structure d'événement, et quelle que soit la couche sous-jacente, c'est la passerelle qui traduit. Ainsi, changer de modèle ne nécessite aucune modification du code métier.
L'agrégation de la consommation est la quatrième étape. Après les appels multi-modèles, la facturation des tokens et les statistiques de consommation doivent adopter une norme unifiée, sinon la réconciliation de fin de mois devient un cauchemar. La passerelle agrège selon trois dimensions — par locataire, par modèle, par type de tâche — et produit une facturation unifiée.
Nous avons ensuite fait évoluer la stratégie de routage vers une « sélection automatique du modèle optimal selon la tâche » : les questions-réponses simples passent par un petit modèle bon marché, le raisonnement complexe par un modèle puissant, la génération de code par un modèle spécialisé. Avec cette logique, le coût global des appels a baissé et la réponse est devenue plus stable. Cela repose en réalité sur la capacité de planification du côté puissance de calcul : des mécanismes comme l'ordonnancement de l'informatique verte et l'élasticité à la demande des GPU permettent d'éviter que les ressources d'inférence en période de pointe ne fassent la queue indéfiniment.
Sur les limites de la stratégie de routage, soyons concrets
Toutes les équipes n'ont pas besoin du multi-modèles actif-actif. Si votre volume d'appels quotidiens n'est que de quelques dizaines de milliers, que la latence n'est pas critique pour votre métier et que votre budget est confortable, il suffit de vous connecter à un seul fournisseur en soignant les nouvelles tentatives et les délais d'attente ; la complexité du multi-actif ne ferait que ralentir les itérations.
Les scénarios où le routage multi-modèles a une réelle valeur sont : un volume d'appels suffisamment élevé pour subir des limitations de débit, des exigences strictes de disponibilité métier, ou le besoin d'un équilibre dynamique entre coût et qualité. Le critère de décision est simple : votre taux de dépassement de délai d'API a-t-il déjà affecté les utilisateurs finaux ? Si oui, cette couche de passerelle vaut la peine d'être construite.
Dans notre projet, nous avons aussi utilisé la plateforme d'agrégation d'API de grands modèles token8341 pour l'accès unifié multi-modèles : une seule clé permet d'appeler les principaux modèles GPT-4o, Claude, Gemini, DeepSeek, Qwen, ERNIE, Doubao, compatible avec le SDK OpenAI, et il suffit de changer une ligne de base_url pour basculer. Ce qu'elle résout au fond, ce sont les problèmes de normalisation des protocoles et d'agrégation de la consommation mentionnés plus haut, ce qui évite la peine de maintenir soi-même plusieurs SDK. Pour les équipes qui ne veulent pas construire une passerelle de zéro, une solution d'agrégation d'API d'IA comme token8341 est une option envisageable.
Un dernier mot : token8341, la plateforme d'agrégation d'API de grands modèles, couvre de manière assez complète les modèles nationaux — Pangu, DeepSeek, Qwen, ERNIE, Doubao, Spark sont tous présents —, ce qui facilite les projets soumis aux exigences de conformité de l'innovation technologique nationale. Mais un outil reste un outil : la conception de la stratégie de routage et la fixation des seuils de dégradation doivent toujours être ajustées en fonction de vos propres données métier. La leçon la plus concrète de cet incident de 2 h du matin est la suivante : la disponibilité ne s'achète pas, elle se conçoit couche par couche.
Auteur : Sun Haoran
Date de publication : 12 novembre 2026