Routage à poids ouverts à l'échelle : GLM-5.1 contre Claude Opus 4.7 sur TrueFoundry AI Gateway

Nous avons exécuté 20 invites fixes via TrueFoundry AI Gateway en comparant quatre stratégies : toutes Claude Opus 4.7, toutes Z.AI GLM-5.1, un routeur classificateur Haiku (facile → ouvert, difficile → frontière), et un modèle virtuel 80/20. Sur ce mélange, le routage classificateur a réduit le coût moyen d'environ 31 % par rapport à la stratégie tout-Opus (15,72 $ contre 22,72 $ par million de jetons) tout en obtenant un score plus élevé sur notre juge Sonnet (4,94 contre 4,85). All-open était le moins cher (3,00 $ / 1M) mais plus lent et de qualité légèrement inférieure. À retenir : vous n'avez pas besoin d'une chaîne de modèle unique pour chaque requête — le routage par passerelle (Gateway routing) associé à un classificateur bon marché peut préserver la qualité de pointe sur les tâches difficiles sans payer les prix de pointe sur les tâches faciles.

Pourquoi c'est important maintenant

La vague des modèles à poids ouverts n'est plus théorique. Des modèles comme GLM-5.1 sont livrés avec agentic coding positionnement, 200 000 jetons de contexte, et des prix catalogue un ordre de grandeur en dessous des API de pointe, tandis que Claude Opus 4.7 reste la référence pour le raisonnement complexe.

Les équipes de plateforme sont confrontées à un compromis familier :

• Tout acheminer vers le modèle de pointe → qualité prévisible, économie unitaire douloureuse à grande échelle.
• Acheminer tout vers à poids ouvert → coût attractif, qualité inégale et latences importantes sur les requêtes complexes.
• Construire des routeurs personnalisés → flexible, mais vous gérez la logique de classification, le basculement, la réconciliation de la facturation et la sémantique du cache entre les fournisseurs.

La passerelle TrueFoundry AI se positionne au milieu : plus de 1000 LLM via une API unifiée compatible OpenAI, des modèles virtuels avec routage basé sur le poids, des en-têtes de cache sémantique et des métriques de tarification transparentes pour une facturation juste. Nous voulions mesurer si un simple classificateur FACILE/DIFFICILE — un appel Haiku par requête — pouvait surpasser les deux extrêmes en termes de coût et de qualité pour une charge de travail réaliste de 20 requêtes.

Ce que nous avons comparé (aperçu technique)

Référence à poids ouvert : GLM-5.1

GLM-5.1 est le modèle phare de Z.AI pour avril 2026, accessible via la passerelle de TrueFoundry, destiné aux tâches agentiques à long terme — planification, utilisation d'outils et boucles de codage multi-étapes.

Référence de pointe : Claude Opus 4.7

Opus 4.7 est le modèle haut de gamme d'Anthropic pour le raisonnement complexe. Remarque : Opus 4.7 utilise un nouveau tokenizer qui peut émettre plus de tokens que les anciens modèles Claude pour le même texte — les comparaisons de coûts doivent utiliser le nombre de tokens mesurés, et non le nombre de caractères.

Routeur classificateur au niveau de l'application

Notre routeur classe chaque requête comme FACILE ou DIFFICILE en un seul appel (environ 8 tokens de sortie). FACILE → GLM-5.1 ; DIFFICILE → Opus 4.7. L'évaluation de la qualité utilise Claude Sonnet 4.6 comme juge LLM (1 à 5 par rapport aux rubriques par requête).

Modèle virtuel de passerelle (80/20)

Nous avons également testé un modèle virtuel dans la passerelle configuré pour le routage basé sur le poids (80 % ouvert / 20 % de pointe dans l'interface utilisateur). Cela mesure l'équilibrage de charge côté fournisseur sans classification au niveau de l'application — un levier différent de celui du routeur Haiku.

À propos de notre benchmark

Requêtes : 20 tâches — 10 étiquetées faciles (résumer, formater du JSON, traduire) et 10 difficiles (compromis des systèmes distribués, examen d'injection SQL, ambiguïté contractuelle, débogage K8s OOM, etc.).

Métriques par stratégie :

Ce que nous n'avons pas affirmé : scores SWE-bench des fournisseurs, formes de trafic de production.
‍

Contexte tarifaire des fournisseurs (mai 2026)

GLM-5.1 est environ 5 fois moins cher en entrée et environ 8 fois moins cher en sortie qu'Opus 4.7 au prix catalogue — avant routage, mise en cache ou remises d'entreprise. La question intéressante est de savoir quelle part de cet écart vous conservez après avoir envoyé des invites complexes à la frontière.
‍

Notre analyse (exécution de 20 invites)

Coût par million de jetons (mix de jetons de cette exécution)

‍

Répartition du routeur (classificateur)

Le routeur Haiku a envoyé 10/20 invites à GLM-5.1 et 10/20 à Opus 4.7 — une répartition 50/50 sur cet ensemble d'invites (10 faciles + 10 difficiles par conception). Le volume de jetons a suivi : 7 774 jetons sur GLM contre 10 072 sur Opus pour le trafic de complétion.

Les queues de latence sont importantes

Les modèles à poids ouverts uniquement avaient la latence p50 la plus lente (20,1s) et une latence extrême p95 (~115s) — une longue complétion GLM sur une requête difficile dominait la queue de latence. Le modèle Opus uniquement était le plus rapide en p50 (9,1s) avec un p95 modéré (~21s). Le classifieur se situait entre les deux pour le p50 (14,9s) avec un p95 d'environ 26s.

Qualité vs coût : le point idéal du classifieur

• Routeur vs tout-Opus : ~31 % inférieur coût moyen par million de jetons (15,72 $ contre 22,72 $) avec un score plus élevé score moyen des juges (4,94 contre 4,85). Le coût total en dollars pour 20 requêtes était pratiquement le même (~0,28 $) car les frais généraux du juge + du routeur ont compensé les économies du GLM — à volume plus élevé, l'écart par jeton s'accentue.
• Routeur vs tout-ouvert : ~5.2× plus élevé de $/1M mais +0.19 points de qualité. Le moins cher n'est pas le meilleur si les requêtes complexes sont importantes.
• Virtuel 80/20 : $7,19 / 1M sur une estimation de mélange de prix catalogue, mais la qualité (4,50) était en deçà des deux références. Le routage basé sur le poids sans connaissance de la tâche ne remplace pas la classification pour cette charge de travail — validez le mix réel des backends dans Gateway Metrics, et pas seulement l'ID du modèle virtuel.

Pourquoi ces résultats sont importants

1. La classification est bon marché par rapport aux complétions de pointe. Un appel Haiku par requête est négligeable comparé à une complétion Opus de 1 024 tokens sur des tâches complexes. L'économie du routeur fonctionne lorsque le trafic facile représente une part importante du volume — et lorsque les erreurs de routage sont rares.
2. Le prix catalogue ≠ votre facture. Gateway peut acheminer via différents fournisseurs, appliquer la mise en cache ou négocier les tarifs. Nous avons appliqué les prix catalogue publics aux tokens mesurés de notre exécution ; vous devriez rapprocher avec Gateway Metrics → Télécharger les données brutes avant de définir les garde-fous FinOps.
3. La latence et la qualité sont liées. Économiser 31 % sur les jetons n'aide pas si la latence p95 dépasse les SLO. Notre base de référence open-weight a montré qu'une seule mauvaise décision de routage (envoyer une invite difficile uniquement à GLM) peut faire exploser la latence de queue.
4. Deux schémas de routage, deux histoires. Niveau application FACILE/DIFFICILE le routage a optimisé le rapport qualité-coût sur cet ensemble. Niveau UI modèles virtuels 80/20 optimisés pour la simplicité opérationnelle mais sous-performants en termes de qualité ici — utiles pour les déploiements progressifs, pas un remplacement complet du routage sensible aux tâches.

Enseignements pratiques pour les équipes plateforme

1. Commencez avec une paire modèle de pointe + open-weight connectée via une seule URL de base de la passerelle. Changez de modèle en modifiant la chaîne de modèle — pas de fork de SDK par fournisseur.
2. Ajoutez un classifieur peu coûteux (Haiku ou similaire) avant d'ajouter de la complexité aux poids des modèles virtuels. Mesurez le taux d'erreurs de routage sur un sous-ensemble de prompts de référence.
3. Publiez une liste de niveaux de prompts (facile / difficile) alignée sur vos critères — notre ensemble de 20 prompts est un modèle, pas votre distribution de production.
4. Rapprochez les coûts dans les Métriques de la passerelle, et non dans les estimations de notebook. Exportez le CSV de facturation brut et joignez sur les métadonnées de trace
5. Mettez en place un cache sémantique après la stabilisation du routage — le cache sémantique sur les prompts faciles et paraphrasés est l'endroit où le ROI du cache apparaît généralement (non mesuré dans cette exécution de référence).

Comment TrueFoundry AI Gateway a rendu cela possible

• API unifiée compatible OpenAI — un client, base_url pointant vers la passerelle ; même chemin de code pour GLM, Opus, Haiku et Sonnet.
• Modèles virtuels — routage 80/20 basé sur le poids sans modifications de l'application (documentation).
• Cache sémantique — réutilisation des réponses basée sur la similarité (documentation).
• Observabilité — en-têtes d'utilisation des jetons, de latence et de coût pour la réconciliation ; latence d'environ 3 à 4 ms et plus de 350 RPS sur 1 vCPU au niveau de la couche passerelle pour les scénarios de proxy à haut débit.

Conclusion

Les modèles open-weight comme GLM-5.1 sont tarifés pour attirer facilement le trafic. Claude Opus 4.7 reste pertinent pour les requêtes complexes. L'écart entre eux est suffisamment important pour que le routage compte plus que le marketing des modèles.

Sur notre banc d'essai de 20 prompts à travers TrueFoundry AI Gateway, un routeur classificateur Haiku a présenté le meilleur résultat combiné : un coût combiné par million de jetons inférieur d'environ 31 % à celui du tout-Opus, avec un score moyen des juges plus élevé (4,94 contre 4,85). Le tout-ouvert est resté le plancher des coûts ; le tout-Opus, le plafond de qualité et de vitesse pour la latence p50.

‍