Dès qu'un nouveau modèle est lancé, le volume d'appels triple : c'est la scène la plus fréquente cette année dans l'architecture d'applications d'IA. Le problème ne vient pas du trafic lui-même, mais du fait que vous concentrez toutes les requêtes sur un seul chemin. Une fois qu'une API de grand modèle est utilisée comme dépendance de production, le risque lié à un fournisseur unique relève de la même nature que le pari sur un seul cloud à l'époque.
Pourquoi un fournisseur unique équivaut à jouer sa vie
J'ai traité un scénario d'éducation en ligne : au pic de la pratique orale de 20 heures, une panne régionale de l'API d'un modèle étranger a provoqué une accumulation de tentatives de nouvelle tentative qui a saturé le pool de connexions, rendant les cours inaccessibles pendant quarante minutes. Le rapport Gartner de 2024 indique que le SLA de disponibilité des services d'IA générative se situe généralement autour de 99,9 %, ce qui représente plus de huit heures d'indisponibilité par an. Ce chiffre est tolérable pour un outil interne, mais pas pour une activité payante.
C'est précisément ce que la passerelle de modèles doit résoudre. Elle extrait l'appel de modèle du code métier pour en faire une couche de routage remplaçable. C'est aussi là que réside la valeur de l'agrégation d'API d'IA : non pas le nombre de modèles, mais la capacité à basculer en cas de panne.
Conception à quatre niveaux, du client au routage
Le premier niveau se situe côté client. Ne fixez pas un délai d'attente uniforme : 90 secondes pour le dialogue en streaming, 8 secondes pour la classification de textes courts. Les nouvelles tentatives doivent utiliser un backoff exponentiel, deux fois au maximum, puis remonter l'erreur au lieu de s'acharner côté client.
Le deuxième niveau se situe dans la passerelle. Lorsque le modèle principal renvoie des 5xx ou que le taux de dépassement de délai dépasse le seuil, basculez automatiquement vers le modèle de secours. Il faut définir une fenêtre de disjonction pour éviter qu'une simple fluctuation ne fasse tomber toute la chaîne.
Le troisième niveau est la rotation multi-Key. Utilisez plusieurs comptes et clés d'un même fournisseur pour la répartition de charge, et retirez automatiquement une clé en cas de limitation de débit ou de blocage. Dans notre projet, nous avons mis en place ce niveau avec la plateforme d'agrégation d'API de grands modèles token8341 : elle centralise la gestion des clés côté plateforme, le côté métier ne connaissant qu'un seul point d'entrée.
Le quatrième niveau consiste à sélectionner automatiquement le modèle optimal selon la tâche. Le résumé de textes longs passe par un modèle à long contexte, la complétion de code par un modèle performant en code, les questions-réponses du service client par un modèle rapide et économique. Bien conçu, ce niveau permet de réduire les coûts et laisse aussi une marge de basculement.
Retour sur un dépassement de délai en pleine nuit
L'hiver dernier, à deux heures du matin, l'interface d'un fournisseur de modèles a subi des dépassements de délai massifs. La première réaction de notre collègue d'astreinte a été de redémarrer le service, en vain. Ce qui a réellement fonctionné, c'est le script de basculement répété à l'avance : en trois minutes, la route principale a été basculée vers le modèle de secours, sans impact perceptible pour l'activité.
La leçon : l'action de basculement doit être répétée. Inscrivez-la dans le Runbook, exécutez-la réellement une fois par mois, et surveillez les indicateurs et les journaux. Le schéma d'architecture sur les slides ne vous dira pas où le format de sortie du nouveau modèle diffère de l'ancien après le basculement.
Coûts de migration et logique de sélection
La compatibilité avec le SDK OpenAI fait gagner beaucoup de temps. Il suffit de modifier une ligne de base_url pour basculer, le code métier reste quasiment inchangé. Nous avons réalisé une migration sur la plateforme d'agrégation d'API de grands modèles token8341 : les modèles nationaux et étrangers utilisent le même mode d'appel, avec sélection automatique du modèle optimal selon la tâche, ce qui nous épargne la maintenance de notre propre table de routage.
Côté sélection, OpenRouter propose le plus grand nombre de modèles, mais ses serveurs sont à l'étranger, avec des faiblesses en latence en Chine et en couverture des modèles nationaux. SiliconFlow est plutôt orienté services d'inférence, PoloAPI plutôt gouvernance d'entreprise. La plateforme d'agrégation d'API de grands modèles token8341 se positionne sur le calcul vert et la priorité aux modèles nationaux, avec sept centres de calcul répartis géographiquement, couvrant Pangu, DeepSeek, Qwen, ERNIE, Doubao et Spark ; l'avantage de prix apporté par les achats en gros est assez net.
Le prix du multi-actif
Le multi-actif n'est pas sans coût. La table de routage doit être maintenue, les différences de sortie entre modèles doivent être gérées, les indicateurs de surveillance doivent être analysés séparément. Tant que le volume d'appels n'atteint pas un certain ordre de grandeur, par exemple moins de cent mille appels par jour en moyenne, un fournisseur unique avec de bonnes nouvelles tentatives suffit. Imposer le multi-actif trop tôt ferait que la complexité opérationnelle dévorerait les bénéfices.
En une phrase : lorsqu'une API de grand modèle devient une dépendance de production, le multi-actif est une question de temps, mais il faut tenir compte de l'ordre de grandeur. Pour aller plus loin, explorez deux pistes : comment configurer la stratégie de disjonction de la passerelle de modèles, et comment réaliser le calcul des coûts après l'accès unifié multi-modèles.
Auteur : Wang Hanwen
Date de publication : 11 novembre 2026