Réponse d’abord : quelle passerelle multi-LLM couvre toute la pile ?
Une passerelle multi-LLM en production doit faire plus que relayer le même prompt vers un autre modèle. Elle doit permettre de changer de modèle sans réécrire le client, décider quand une autre route est sûre, enregistrer chaque tentative, attribuer les tokens et le coût, et stopper une boucle d’échecs avant qu’elle ne devienne un incident budgétaire.
Chacune des cinq passerelles optimise un périmètre de responsabilité différent. Portkey propose actuellement la combinaison gérée la plus claire de politiques de routage, replis natifs, traces, budgets et limites de débit. LiteLLM expose une surface de contrôle tout aussi large pour les équipes prêtes à exploiter elles-mêmes le proxy. CometAPI adopte une approche plus légère : une URL de base compatible OpenAI et un paramètre model couvrent un large catalogue hébergé, tandis que son guide officiel de repli laisse les décisions de retry et de repli dans votre application.
Comparaison rapide des passerelles multi-LLM
| Passerelle | Changement de modèle | Repli | Utilisation | Journaux | Contrôles des coûts | Meilleur cas d’usage |
|---|---|---|---|---|---|---|
| CometAPI | Oui — une URL de base ; changez le modèle | Modèle piloté par l’application | Usage de réponse plus quota et requête d’usage J+1 | Journaux de requêtes et tableau de bord | Quotas par clé et limites de sortie au niveau requête | Accès multi-modèles hébergés avec intégration minimale |
| Portkey | Oui — API universelle et configurations | Replis, retries et coupe-circuits natifs priorisés | Attribution des tokens et coûts par requête | Chaîne de tentatives avec Config ID et Trace ID | Budgets, limites de débit et garde-fous de politique | Routage géré + observabilité approfondie |
| OpenRouter | Oui — routage par modèle et fournisseur | Repli automatique de fournisseur ; routage de modèle réglable | Analyses et historique d’activité | Historique d’activité ; moins de traçage applicatif que Portkey | Tri par prix, règles de prix maximal et limites de clé | Sélection de fournisseurs façon marketplace |
| LiteLLM | Oui — proxy compatible OpenAI pour de nombreux fournisseurs | Retries et replis du routeur | Suivi des dépenses et tokens par utilisateur, clé ou projet | Hooks intégrés et callbacks de journalisation externes | Budgets et limites de débit | Contrôle auto-hébergé et personnalisable |
| Cloudflare AI Gateway | Oui — routes unifiées et dynamiques | Nœuds de repli dans les routes dynamiques | Analyses via le tableau de bord | Journaux de requêtes persistants | Limites de dépense, limites de débit et replis vers des modèles moins coûteux | Opérations edge natives Cloudflare |
Preuves : Basculement CometAPI, requête d’usage et de quota et modèle de repli ; Passerelle Portkey, replis et gestion des coûts ; Routage fournisseur OpenRouter et analyses d’usage ; Proxy et routeur LiteLLM ; Fonctionnalités Cloudflare AI Gateway, routage dynamique et limites de dépense.
Le repli piloté par l’application fonctionne en production. Le guide CometAPI documente un schéma opérationnel, mais cela signifie que la logique de retry, l’état du coupe-circuit et les budgets par route vivent dans votre base de code et doivent être réimplémentés par service, plutôt que d’être configurés une fois dans une passerelle et appliqués à tous les clients.
Les 5 capacités nécessaires à une passerelle LLM de production
Changement de modèle
Le changement de modèle conserve un contrat client stable — généralement un endpoint compatible OpenAI /chat/completions — et sélectionne le modèle par configuration, politique ou paramètre par requête, afin que vous puissiez changer de modèle sans mettre à jour chaque client.
Les cinq passerelles le prennent en charge, mais la surface de contrôle diffère : CometAPI et OpenRouter utilisent un endpoint hébergé avec un champ model ; Portkey ajoute un routage piloté par configuration ; LiteLLM mappe des alias dans une configuration auto-hébergée ; Cloudflare lie la sélection à une route edge.
Routage de repli
Le routage de repli est une séquence ordonnée de modèles ou de fournisseurs essayés lorsque la route primaire échoue, avec une distinction critique : retentez en cas d’erreurs de connexion, de délais dépassés, 408, 429 et 5xx temporaires ; échouez immédiatement sur 400, 401, 403 et 404 modèle inconnu afin qu’une mauvaise configuration ne se cache pas derrière un repli coûteux.
Portkey, LiteLLM, OpenRouter et Cloudflare exposent une configuration de repli côté passerelle ; le schéma documenté de CometAPI conserve la séquence dans le code applicatif.
Suivi d’utilisation
Le suivi d’utilisation capture les tokens d’entrée, de sortie, le nombre de requêtes et l’attribution de modèle pour chaque appel — pas seulement ceux qui réussissent — ce qui rend possible la comptabilité des coûts et la facturation par tenant. Sans données par tentative, une flambée de coûts peut provenir d’un trafic légitime, d’une boucle de retry ou d’un repli vers un modèle plus onéreux, et des tentatives échouées ayant consommé des tokens partiels restent facturées en amont.
Portkey et LiteLLM offrent une attribution au niveau requête et tentative ; CometAPI renvoie l’usage par réponse plus un endpoint de requête de quota ; OpenRouter et Cloudflare fournissent des tableaux de bord analytiques.
Journaux et traces
Les journaux et traces enregistrent chaque tentative — latence, code statut, décision de route, modèle et fournisseur — sous un même identifiant de requête, afin qu’une chaîne de repli soit traçable de bout en bout. Une réponse finale 200 seule ne prouve rien : si les tentatives échouées ne sont pas enregistrées sous le même ID, une boucle de repli silencieuse peut tourner des semaines avant d’apparaître dans le rapport de coûts.
Portkey offre le traçage le plus approfondi avec Config ID et Trace ID par tentative ; LiteLLM prend en charge des hooks et callbacks de journalisation ; l’Activity d’OpenRouter couvre l’usage mais moins le traçage de bout en bout ; Cloudflare et CometAPI fournissent des journaux de requêtes et des tableaux de bord.
Contrôle des coûts
Le contrôle des coûts signifie des garde-fous applicables — budgets, quotas, limites de débit, règles de prix maximal ou plafonds par tenant — qui stoppent une boucle d’échecs avant qu’elle ne devienne un incident budgétaire. Un tableau de bord d’usage sans limites relève du reporting, pas du contrôle : un retry mal configuré sans backoff peut multiplier une requête en des centaines de tentatives facturables, et un repli silencieux vers un modèle 10x plus cher peut doubler la facture mensuelle en un après-midi.
Portkey prend en charge les budgets et garde-fous de politique ; LiteLLM applique des limites par clé et par modèle ; OpenRouter propose des règles de prix maximal ; Cloudflare fournit des limites de dépense sur les routes edge ; CometAPI applique des quotas par clé et des limites de sortie.
Meilleures passerelles multi-LLM en 2026
CometAPI
Choisissez CometAPI quand la simplicité d’intégration prime. La route compatible OpenAI utilise https://api.cometapi.com/v1, et le même client peut sélectionner un autre modèle du catalogue en changeant le champ model. L’API publique d’annuaire de modèles offre aussi un moyen lisible par machine de valider les IDs de modèles, capacités, prix et endpoints avant déploiement. Le compromis est que la politique de retry et de repli reste à votre charge.
Portkey
Choisissez Portkey lorsque la politique et l’observabilité doivent être gérées ensemble. Sa passerelle documentée prend en charge le routage conditionnel, les replis, retries, coupe-circuits, l’équilibrage de charge, les budgets et une visibilité des tentatives au niveau trace. Cela réduit le code du plan de contrôle personnalisé, même s’il faut toujours tester le comportement spécifique à chaque fournisseur.
OpenRouter
Choisissez OpenRouter lorsque le routage façon marketplace de fournisseurs est l’exigence principale. L’ordonnancement des fournisseurs, les préférences de prix ou de latence, la compatibilité des paramètres et le repli automatique de fournisseur sont des contrôles de premier plan. Sa vue Activity est utile pour l’historique d’usage, mais les équipes nécessitant des traces applicatives de bout en bout l’associeront encore à une autre couche d’observabilité.
LiteLLM
Choisissez LiteLLM lorsque vous devez maîtriser la passerelle. Son proxy et son routeur exposent des replis, des budgets, le suivi des dépenses et des callbacks de journalisation pour de nombreux fournisseurs. L’avantage est le contrôle ; le coût est d’exploiter le proxy, le stockage, les mises à jour, les secrets et la configuration des politiques.
Cloudflare AI Gateway
Cloudflare AI Gateway est particulièrement attractive pour les équipes utilisant déjà l’infrastructure Cloudflare. Son système actuel de routage dynamique peut router les requêtes selon des conditions, appliquer des limites de débit ou de budget et envoyer les requêtes en échec ou hors limite vers des modèles de repli. Les équipes doivent néanmoins vérifier l’API et le chemin d’authentification pris en charge pour leur déploiement avant de standardiser dessus.
Comment comparer les passerelles multi-LLM en pratique
Pour une vue plus large de la plateforme, voir la comparaison des passerelles IA de CometAPI. Cet article reste plus étroit : déterminer si chaque option peut changer de modèle, observer, basculer en repli et contrôler les coûts dans un même flux de production.
Comment tester les replis d’une passerelle LLM
N’évaluez pas le repli en lisant seulement une page de fonctionnalités. Exécutez un test scripté unique pour chaque passerelle : une requête normale, une requête délibérément soumise à une limitation de débit, un délai dépassé, une clé API invalide et un ID de modèle invalide. Un défaut sûr est de retenter ou se replier sur les erreurs de connexion, délais dépassés, réponses HTTP 408, 429 et 5xx temporaires. Considérez 400, 401, 403 et un 404 modèle inconnu comme des échecs fermes afin qu’une mauvaise configuration ne soit pas masquée en un repli coûteux.
La forme de journal attendue est {"request_id": "...", "model": "...", "status": 200, "latency_ms": <measured>, "usage": {...}}. Votre test n’est réussi que si la passerelle ou l’application enregistre aussi les tentatives échouées sous le même identifiant de requête. Une réponse finale 200 seule ne peut prouver que le repli s’est comporté correctement.
Comment mesurer le coût d’une passerelle LLM
Suivez le coût par tentative, pas seulement par réponse finale. Pour chaque route, calculez :
attempt cost = (input tokens × input price + output tokens × output price) / 1,000,000
Au 02 septembre 2026, l’API publique d’annuaire de modèles CometAPI listait Gemini 3.7 Flash à 0,75 $ par million de tokens d’entrée et 3,75 $ par million de tokens de sortie, et Claude Opus 5 à 5 $ et 25 $ respectivement. Pour 1,000 requêtes Gemini réussies avec une moyenne de 2,000 tokens d’entrée et 500 de sortie, le coût modélisé est de 3,375 $. Si 5 % de ces requêtes s’exécutent aussi sur Claude Opus 5 comme repli orienté qualité avec le même volume de tokens, le repli ajoute 1,125 $, portant le total modélisé à 4,50 $ avant toute tentative primaire partielle facturable.
C’est pourquoi un tableau de bord de passerelle doit exposer séparément les tentatives primaires, les tentatives de repli, les tokens, la latence et le coût. Recoupez ces enregistrements avec la requête de quota et d’usage quotidien de CometAPI, pas seulement le nombre de réponses réussies.
Quelle passerelle multi-LLM devez-vous choisir ?
- Chemin le plus rapide vers de nombreux modèles hébergés : CometAPI, avec repli piloté par l’application.
- Politique de routage gérée la plus complète : Portkey.
- Marketplace de fournisseurs et sélection automatique de fournisseur : OpenRouter.
- Passerelle auto-hébergée avec politique personnalisable : LiteLLM.
- Journalisation, limites et routage natifs edge : Cloudflare AI Gateway.
La décision se résume à une question : où résident la politique de repli et de retry ? Dans CometAPI, elle vit dans votre code applicatif. Dans Portkey et OpenRouter, elle vit dans une configuration hébergée. Dans LiteLLM, elle vit dans une configuration auto-hébergée que vous opérez. Dans Cloudflare, elle vit dans une route edge liée à votre compte Cloudflare.
Tableau de décision：
| Votre exigence | Recommandé |
|---|---|
| Accéder à de nombreux modèles via une seule API | CometAPI |
| Politiques de routage gérées | Portkey |
| Routage au niveau fournisseur | OpenRouter |
| Passerelle auto-hébergée | LiteLLM |
| Infrastructure Cloudflare | Cloudflare AI Gateway |
| Repli piloté par l’application | CometAPI |
| Politiques de repli centralisées | Portkey / LiteLLM / Cloudflare |
Liste de contrôle de production pour une passerelle multi-LLM
- Définissez quels codes statut déclenchent retry, repli et échec ferme.
- Limitez les retries et ajoutez un disjoncteur pour qu’une panne fournisseur ne multiplie pas les dépenses.
- Vérifiez les appels d’outils, la sortie structurée, le streaming et le comportement de sécurité sur chaque modèle de repli.
- Associez un identifiant de requête unique à toutes les tentatives et enregistrez modèle, fournisseur, statut, latence, tokens et coût.
- Définissez des quotas ou budgets par tenant et alertez avant la limite stricte.
- Validez les IDs de modèles actuels contre un catalogue en temps réel avant le déploiement.
- Examinez la rétention des données, le routage des fournisseurs et les exigences régionales avant d’activer les journaux.
Une route de repli qui renvoie du texte peut tout de même échouer silencieusement à la tâche si elle rejette les appels d’outils, renvoie un JSON de schéma différent, stream dans un format incompatible ou applique une politique de contenu différente. Vérifiez ces quatre points sur chaque modèle de repli avant de considérer la route comme sûre.
Foire aux questions
Quelle passerelle multi-LLM prend en charge le changement de modèle, le suivi d’utilisation et le routage de repli ?
Les cinq options du tableau prennent en charge ces résultats, mais pas de la même manière. Portkey, LiteLLM, OpenRouter et Cloudflare exposent des fonctionnalités de routage côté passerelle. CometAPI fournit le changement de modèle, la visibilité d’usage et un accès via une seule clé, tandis que son schéma de repli documenté s’exécute dans le code applicatif.
CometAPI effectue-t-il automatiquement un repli vers un autre modèle ?
Le guide officiel actuel documente une séquence gérée par l’application : appeler un modèle CometAPI primaire, basculer vers un autre modèle CometAPI en cas d’échec retentable, et éventuellement appeler en dernier un fournisseur officiel. La même clé API CometAPI et la même URL de base peuvent être réutilisées pour le changement de modèle interne.
Puis-je changer de modèle sans modifier mon infrastructure cliente ?
En général oui, lorsque la passerelle expose un contrat compatible OpenAI. Avec CometAPI, conservez l’URL de base https://api.cometapi.com/v1 et changez la valeur de model. Testez les paramètres spécifiques au modèle avant de supposer une interchangeabilité complète.
Quand une requête doit-elle se replier plutôt qu’échouer ?
Le repli est généralement approprié pour les délais dépassés, erreurs de connexion, 408, 429 et 5xx temporaires. Les erreurs d’authentification, requêtes invalides, paramètres non pris en charge et IDs de modèle inconnus doivent normalement échouer immédiatement.
Comment vérifier le suivi d’utilisation ?
Comparez les tokens dans la réponse API, les journaux de requête de la passerelle, les rapports d’usage quotidien ou de quota et la facture finale. Les enregistrements doivent s’accorder sur le modèle, le nombre de tentatives et le volume de tokens.
Une passerelle réduit-elle automatiquement le coût LLM ?
Non. Une passerelle crée les contrôles nécessaires pour router à moindre coût, plafonner les dépenses et observer les retries. Les économies dépendent de votre politique de routage, de votre mix de modèles, du taux d’échec et du fait que des tentatives échouées aient consommé des tokens facturables.
Fondez le test de passerelle sur des éléments probants
Une évaluation utile d’une passerelle multi-LLM se conclut par des artefacts : une matrice de fonctionnalités datée, un test d’échec reproductible, des journaux au niveau des tentatives et un rapprochement des coûts. CometAPI est un point de départ pratique quand vous souhaitez un large accès à des modèles hébergés via une seule URL de base compatible OpenAI. Les équipes qui ont besoin d’une politique gérée par la passerelle ou d’un contrôle auto-hébergé doivent comparer Portkey et LiteLLM avec le même test plutôt que de se fier aux étiquettes de fonctionnalités.
Pour la prochaine étape d’implémentation, lisez comment router des requêtes entre plusieurs modèles et le guide de basculement et de repli CometAPI.