Open-Weight Routing op Schaal: GLM-5.1 vs Claude Opus 4.7 op TrueFoundry AI Gateway

Gebouwd voor snelheid: ~10ms latentie, zelfs onder belasting
De razendsnelle manier om je modellen te bouwen, volgen en implementeren!
- Verwerkt 350+ RPS op slechts 1 vCPU — geen tuning nodig
- Productieklaar met volledige enterprise-ondersteuning
We hebben 20 vaste prompts uitgevoerd via TrueFoundry AI Gateway waarbij vier strategieën zijn vergeleken: volledig Claude Opus 4.7, volledig Z.AI GLM-5.1, een Haiku classifier router (eenvoudig → open, complex → frontier), en een 80/20 virtueel model. Op deze mix verlaagde classifier routing de gecombineerde kosten met ~31% ten opzichte van volledig Opus ($15,72 vs $22,72 per 1M tokens) terwijl de score op onze Sonnet judge hoger uitkwam (4,94 vs 4,85). Volledig open was het goedkoopst ($3,00 / 1M), maar langzamer en met een iets lagere kwaliteit. De conclusie: u heeft geen enkele modelstring nodig voor elke request — Gateway routing in combinatie met een goedkope classifier kan frontier-kwaliteit behouden op complexe taken zonder frontier-prijzen te betalen voor eenvoudige taken.
Waarom dit nu belangrijk is
De open-weight golf is niet langer theoretisch. Modellen zoals GLM-5.1 worden geleverd met een positionering voor agentic coding, een context van 200K tokens en catalogusprijzen die een orde van grootte lager liggen dan frontier API's, terwijl Claude Opus 4.7 de referentie blijft voor complexe reasoning.
Platformteams staan voor een bekende afweging:
- Alles routen naar frontier → voorspelbare kwaliteit, maar kostbare unit economics bij hoge volumes.
- Alles routen naar open-weight → aantrekkelijke kosten, maar wisselvallige kwaliteit en lange latency tails bij complexe prompts.
- Custom routers bouwen → flexibel, maar u bent zelf verantwoordelijk voor classificatielogica, failover, facturatie-reconciliatie en cache-semantiek over verschillende providers heen.
TrueFoundry AI Gateway bevindt zich in het midden: 1000+ LLM's via een geünificeerde OpenAI-compatibele API, virtuele modellen met op gewicht gebaseerde routing, semantic cache-headers en transparante pricing-metrics voor accurate facturatie. We wilden meten of een eenvoudige EASY/HARD-classifier — één Haiku-call per request — beide extremen kon verslaan op het gebied van kosten en kwaliteit voor een realistische werklast van 20 prompts.
Wat we hebben vergeleken (technisch overzicht)
Open-weight baseline: GLM-5.1
GLM-5.1 is het vlaggenschip van Z.AI uit april 2026, toegankelijk via TrueFoundry's Gateway, gericht op langdurige agentic taken — planning, toolgebruik en multi-step coding loops.
Frontier baseline: Claude Opus 4.7
Opus 4.7 is Anthropic's topmodel voor complexe reasoning. Let op: Opus 4.7 gebruikt een nieuwe tokenizer die meer tokens kan genereren dan oudere Claude-modellen voor dezelfde tekst — kostenvergelijkingen moeten gebaseerd zijn op gemeten aantallen tokens, niet op aantallen karakters.
Classifier router op applicatieniveau
Onze router classificeert elke prompt als EASY of HARD in één enkele call (~8 output tokens). EASY → GLM-5.1; HARD → Opus 4.7. Kwaliteitsscoring gebruikt Claude Sonnet 4.6 als LLM judge (1–5 op basis van rubrieken per prompt).
Gateway virtueel model (80/20)
We hebben ook een virtueel model getest in Gateway dat is geconfigureerd voor op gewicht gebaseerde routing (80% open / 20% frontier in de UI). Dit meet load balancing aan de providerzijde zonder classificatie op applicatieniveau — een andere knop dan de Haiku router.
Over onze benchmark
Prompts: 20 taken — 10 gelabeld als eenvoudig (samenvatten, JSON formatteren, vertalen) en 10 als complex (trade-offs in gedistribueerde systemen, SQL-injectie review, ambiguïteit in contracten, K8s OOM debugging, enz.).
Metrics per strategie:
Wat we niet beweren: SWE-bench scores van leveranciers, patronen van productie-verkeer.
Leverancier pricing context (mei 2026)
GLM-5.1 is op basis van de catalogusprijs ongeveer 5× goedkoper op input en ~8× goedkoper op output dan Opus 4.7 — nog vóór routing, caching of enterprise-kortingen. De interessante vraag is hoeveel van dat verschil overblijft nadat complexe prompts naar frontier zijn gestuurd.
Onze analyse (run met 20 prompts)
Kosten per 1M tokens (tokenmix van deze run)
Verdeling router (classifier)
De Haiku router stuurde 10/20 prompts naar GLM-5.1 en 10/20 naar Opus 4.7 — een 50/50 verdeling op deze promptset (opzet van 10 eenvoudig + 10 complex). Het tokenvolume volgde hetzelfde patroon: 7.774 tokens op GLM versus 10.072 op Opus voor completion-verkeer.
Latency tails zijn van belang
Alleen open-weight had de traagste p50 (20,1s) en een extreem hoge p95 (~115s) — één lange GLM completion op een complexe prompt domineerde de tail. Alleen Opus was het snelst op p50 (9,1s) met een gematigde p95 (~21s). De classifier eindigde daartussenin op p50 (14,9s) met een p95 van ~26s.
Kwaliteit vs kosten: de sweet spot van de classifier
- Router vs volledig Opus: ~31% lagere gecombineerde $/1M ($15,72 vs $22,72) met een hogere gemiddelde judge-score (4,94 vs 4,85). De totale dollar-kosten voor 20 prompts waren vrijwel gelijk (~$0,28) omdat de overhead van judge + router de besparingen op GLM compenseerde — bij grotere volumes wordt het verschil per token steeds groter.
- Router vs volledig open: ~5,2× hogere $/1M maar +0,19 kwaliteitspunten. Het goedkoopst is niet het best als complexe prompts belangrijk zijn.
- Virtueel 80/20: $7,19 / 1M op basis van een geschatte mix van catalogusprijzen, maar de kwaliteit (4,50) bleef achter bij beide baselines. Op gewicht gebaseerde routing zonder taakbewustzijn is voor deze werklast geen vervanging voor classificatie — valideer de daadwerkelijke backendmix in Gateway Metrics, niet alleen het virtuele model-ID.
Waarom deze resultaten er toe doen
- Classificatie is goedkoop in vergelijking met frontier completions. Eén Haiku-call per request is verwaarloosbaar vergeleken met een Opus completion van 1.024 tokens op complexe taken. De economische voordelen van de router werken wanneer eenvoudig verkeer een groot deel van het volume uitmaakt — en wanneer foutieve routings zeldzaam zijn.
- Catalogusprijs ≠ uw factuur. Gateway kan routen via verschillende providers, caching toepassen of tarieven onderhandelen. We hebben publieke catalogusprijzen toegepast op gemeten tokens uit onze run; u dient dit te reconciliëren met Gateway Metrics → Download Raw Data voordat u FinOps-kaders instelt.
- Latency en kwaliteit zijn gekoppeld. 31% besparen op tokens helpt niet als de p95 latency SLO's overschrijdt. Onze open-weight baseline toonde aan dat een enkele verkeerde routingbeslissing (een complexe prompt alleen naar GLM sturen) de tail latency enorm kan verhogen.
- Twee routingpatronen, twee verhalen. App-level EASY/HARD routing optimaliseerde de prijs-kwaliteitverhouding op deze set. UI-level 80/20 virtuele modellen optimaliseerden voor operationele eenvoud, maar presteerden hier minder op kwaliteit — nuttig voor geleidelijke roll-outs, maar geen volledige vervanging voor taakbewuste routing.
Praktische inzichten voor platformteams
- Start met een frontier + open-weight koppel dat is aangesloten via één Gateway base URL. Wissel van model door de modelstring te wijzigen — geen SDK-fork per provider.
- Voeg een goedkope classifier toe (Haiku of vergelijkbaar) voordat u complexiteit toevoegt aan de gewichten van virtuele modellen. Meet het percentage verkeerde routings op een vaste representatieve subset van prompts.
- Publiceer een prompt tier-lijst (eenvoudig / complex) die aansluit bij uw rubrieken — onze set van 20 prompts is een template, niet uw productie-verdeling.
- Reconcilieer kosten in Gateway Metrics, niet in schattingen in notebooks. Exporteer ruwe billing-CSV's en koppel deze op basis van trace-metadata.
- Voeg semantic cache toe nadat de routing is gestabiliseerd — semantic caching op eenvoudige, geherformuleerde prompts is waar cache-ROI meestal zichtbaar wordt (niet gemeten in deze baseline-run).
Hoe TrueFoundry AI Gateway dit mogelijk maakte
- Geünificeerde OpenAI-compatibele API — één client, base_url gericht op Gateway; dezelfde codepath voor GLM, Opus, Haiku en Sonnet.
- Virtuele modellen — op gewicht gebaseerde 80/20 routing zonder applicatiewijzigingen (docs).
- Semantic cache — op similariteit gebaseerd hergebruik van responsen (docs).
- Observability — tokengebruik-, latency- en kosten-headers voor reconciliatie; ~3–4 ms latency en 350+ RPS op 1 vCPU in de gateway-laag voor proxy-scenario's met hoge throughput.
Conclusie
Open-weight modellen zoals GLM-5.1 zijn qua prijs aantrekkelijk om eenvoudig verkeer op te vangen. Claude Opus 4.7 bewijst nog steeds zijn waarde bij complexe prompts. Het gat daartussen is groot genoeg dat routing belangrijker is dan modelmarketing.
Op onze testopstelling met 20 prompts via TrueFoundry AI Gateway leverde een Haiku classifier router het beste gecombineerde resultaat: ~31% lagere gecombineerde kosten per miljoen tokens dan volledig Opus, met een hogere gemiddelde judge-score (4,94 vs 4,85). Volledig open bleef de ondergrens voor kosten; volledig Opus het plafond voor kwaliteit en snelheid wat betreft p50 latency.
TrueFoundry AI Gateway levert een latentie van ~3–4 ms, verwerkt 350+ RPS op 1 vCPU, schaalt moeiteloos horizontaal en is klaar voor productie, terwijl LiteLLM last heeft van hoge latentie, moeite heeft boven een gemiddeld aantal RPS, geen ingebouwde schaling heeft en het meest geschikt is voor lichte workloads of prototypes.















.png)

.webp)



.webp)








.webp)





