Skalierbares Open-Weight-Routing: GLM-5.1 vs Claude Opus 4.7 auf TrueFoundry AI Gateway

Wir haben 20 feste Prompts über TrueFoundry AI Gateway laufen lassen und dabei vier Strategien verglichen: alle Claude Opus 4.7, alle Z.AI GLM-5.1, einen Haiku-Klassifikator-Router (einfach → offen, schwer → Frontier), und ein virtuelles 80/20-Modell. Bei dieser Mischung senkte das Klassifikator-Routing die Gesamtkosten um ~31 % im Vergleich zu reinem Opus ($15,72 vs. $22,72 pro 1 Mio. Tokens) und erzielte dabei höhere Werte bei unserem Sonnet-Judge (4.94 vs. 4.85). All-open war am günstigsten (3,00 $ / 1 Mio.), aber langsamer und von etwas geringerer Qualität. Die Quintessenz: Sie benötigen nicht für jede Anfrage einen einzigen Modell-String – Gateway-Routing plus ein günstiger Klassifikator können die „Frontier“-Qualität bei schwierigen Aufgaben bewahren, ohne bei einfachen Aufgaben „Frontier“-Preise zahlen zu müssen.

Warum das jetzt wichtig ist

Die Open-Weight-Welle ist nicht länger nur Theorie. Modelle wie GLM-5.1 werden mit agentischem Coding-Positioning und einem 200K-Token- Kontext ausgeliefert und bieten Listenpreise, die eine Größenordnung unter denen von Frontier-APIs liegen, während Claude Opus 4.7 weiterhin die Referenz für komplexes Denken bleibt.

Plattform-Teams stehen vor einem bekannten Kompromiss:

• Alles an Frontier leiten → vorhersagbare Qualität, schmerzhafte Stückkosten bei hohem Volumen.
• Alles weiterleiten an Open-Weight → attraktive Kosten, uneinheitliche Qualität und Latenzspitzen bei komplexen Prompts.
• Erstellen benutzerdefinierte Router → flexibel, aber Sie sind für die Klassifizierungslogik, das Failover, den Abrechnungsabgleich und die Cache-Semantik über alle Anbieter hinweg selbst verantwortlich.

Das TrueFoundry AI Gateway positioniert sich dazwischen: über 1000 LLMs über eine einheitliche, OpenAI-kompatible API, virtuelle Modelle mit gewichtsbasiertem Routing, semantische Cache-Header und transparente Preismodelle für eine nachvollziehbare Abrechnung. Wir wollten messen, ob ein einfacher EASY/HARD-Klassifikator – ein Haiku-Aufruf pro Anfrage – beide Extreme hinsichtlich Kosten und Qualität bei einer realistischen Arbeitslast von 20 Prompts übertreffen könnte.

Was wir verglichen haben (technischer Überblick)

Open-Weight-Baseline: GLM-5.1

GLM-5.1 ist das Flaggschiff von Z.AI für April 2026, zugänglich über das TrueFoundry Gateway, und ist für langfristige agentische Aufgaben konzipiert – Planung, Werkzeugnutzung und mehrstufige Code-Schleifen.

Frontier-Baseline: Claude Opus 4.7

Opus 4.7 ist das Spitzenmodell von Anthropic für komplexes Reasoning. Hinweis: Opus 4.7 verwendet einen neuen Tokenizer, der für denselben Text mehr Tokens ausgeben kann als ältere Claude-Modelle – Kostenvergleiche sollten gemessene Token-Anzahlen verwenden, nicht Zeichenanzahlen.

Klassifikator-Router auf App-Ebene

Unser Router klassifiziert jeden Prompt in einem einzigen Aufruf (~8 Ausgabe-Tokens) als EINFACH oder SCHWER. EINFACH → GLM-5.1; SCHWER → Opus 4.7. Die Qualitätsbewertung verwendet Claude Sonnet 4.6 als LLM-Richter (1–5 Punkte anhand von pro-Prompt-Rubriken).

Virtuelles Gateway-Modell (80/20)

Wir haben auch ein virtuelles Modell im Gateway getestet, das für gewichtsbasiertes Routing konfiguriert ist (80 % Open / 20 % Frontier in der Benutzeroberfläche). Dies misst den anbieterseitigen Lastausgleich ohne Klassifizierung auf App-Ebene – eine andere Stellschraube als der Haiku-Router.

Über unseren Benchmark

Prompts: 20 Aufgaben – 10 als einfach gekennzeichnet (zusammenfassen, JSON formatieren, übersetzen) und 10 als schwer (Kompromisse bei verteilten Systemen, SQL-Injection-Überprüfung, Vertragsmehrdeutigkeit, K8s OOM-Debugging usw.).

Metriken pro Strategie:

Was wir nicht behauptet haben: SWE-bench-Ergebnisse der Anbieter, Formen des Produktions-Traffics.
‍

Preiskontext der Anbieter (Mai 2026)

GLM-5.1 ist beim Input etwa 5-mal und beim Output etwa 8-mal günstiger als Opus 4.7 zum Listenpreis – vor Routing, Caching oder Unternehmensrabatten. Die interessante Frage ist, wie viel von diesem Unterschied Sie beibehalten, nachdem Sie anspruchsvolle Prompts an Frontier gesendet haben.
‍

Unsere Analyse (20-Prompt-Durchlauf)

Kosten pro 1 Mio. Tokens (Token-Mix dieses Durchlaufs)

‍

Router-Aufteilung (Klassifikator)

Der Haiku-Router sandte 10 von 20 Prompts an GLM-5.1 und 10 von 20 an Opus 4.7 — eine 50/50-Aufteilung bei diesem Prompt-Set (10 einfache + 10 schwierige, designbedingt). Das Token-Volumen verhielt sich entsprechend: 7 774 Tokens auf GLM vs. 10 072 auf Opus für den Completion-Traffic.

Latenz-Spitzen sind entscheidend

Nur Open-Weight hatte die langsamste p50 (20,1s) und eine extreme p95 (~115s) – eine lange GLM-Vervollständigung bei einer schwierigen Anfrage dominierte die Spitze. Nur Opus war am schnellsten bei p50 (9,1s) mit einem moderaten p95 (~21s). Der Klassifikator lag dazwischen bei p50 (14,9s) mit p95 ~26s.

Qualität vs. Kosten: der Sweet Spot des Klassifikators

• Router vs. reines Opus: ~31 % niedriger gemischte $/1M ($15,72 vs. $22,72) mit höherem durchschnittlichem Bewertungs-Score (4,94 vs. 4,85). Die Gesamtkosten in Dollar für 20 Prompts waren im Wesentlichen gleich (~$0,28), da der Overhead für Richter + Router die GLM-Einsparungen ausglich – bei höherem Volumen verstärkt sich der Pro-Token-Unterschied.
• Router vs. reine Open-Modelle: ~5,2-fach höher $/1M, aber +0,19 Qualitätspunkte. Das Günstigste ist nicht das Beste, wenn anspruchsvolle Prompts wichtig sind.
• Virtuell 80/20: 7,19 $ / 1M basierend auf einer Schätzung des Listenpreismixes, aber die Qualität (4,50) blieb hinter beiden Baselines zurück. Gewichtsbasiertes Routing ohne Aufgabenbewusstsein ist kein Ersatz für die Klassifizierung bei dieser Arbeitslast — überprüfen Sie die tatsächliche Backend-Mischung in Gateway Metrics, nicht nur die virtuelle Modell-ID.

Warum diese Ergebnisse wichtig sind

1. Klassifizierung ist günstig im Vergleich zu Frontier-Completions. Ein Haiku-Aufruf pro Anfrage ist vernachlässigbar im Vergleich zu einer 1.024-Token-Opus-Completion bei schwierigen Aufgaben. Die Wirtschaftlichkeit des Routers funktioniert, wenn einfacher Traffic einen großen Anteil am Volumen ausmacht — und wenn Fehlleitungen selten sind.
2. Listenpreis ≠ Ihre Rechnung. Gateway kann über verschiedene Anbieter routen, Caching anwenden oder Tarife verhandeln. Wir haben öffentliche Listenpreise auf gemessene Token aus unserem Durchlauf angewendet; Sie sollten dies mit Gateway Metrics → Rohdaten herunterladen abgleichen, bevor Sie FinOps-Leitplanken festlegen.
3. Latenz und Qualität sind gekoppelt. 31 % Token-Einsparung nützen nichts, wenn die p95-Latenz die SLOs verletzt. Unsere Open-Weight-Baseline zeigte, dass eine einzige schlechte Routing-Entscheidung (einen schwierigen Prompt nur an GLM zu senden) die Tail-Latenz explodieren lassen kann.
4. Zwei Routing-Muster, zwei Geschichten. App-Ebene EINFACH/SCHWER Routing optimierte das Kosten-Qualität-Verhältnis in diesem Set. UI-Ebene 80/20 virtuelle Modelle optimiert für operationale Einfachheit, aber hier bei der Qualität unterdurchschnittlich — nützlich für schrittweise Rollouts, aber kein vollständiger Ersatz für aufgabenbasiertes Routing.

Praktische Empfehlungen für Plattform-Teams

1. Beginnen Sie mit einem Frontier- + Open-Weight-Paar verbunden über eine einzige Gateway-Basis-URL. Tauschen Sie Modelle, indem Sie den Modell-String ändern — kein SDK-Fork pro Anbieter.
2. Fügen Sie einen kostengünstigen Klassifikator (Haiku oder Ähnliches) hinzu, bevor Sie die Komplexität der Gewichte virtueller Modelle erhöhen. Messen Sie die Fehlrouting-Rate an einer Gold-Untermenge von Prompts.
3. Veröffentlichen Sie eine Prompt-Rangliste (einfach / schwer), abgestimmt auf Ihre Bewertungskriterien — unser 20-Prompt-Set ist eine Vorlage, nicht Ihre Produktionsverteilung.
4. Kosten in Gateway Metrics abgleichen, nicht in Notebook-Schätzungen. Exportieren Sie die Roh-Abrechnungs-CSV und verknüpfen Sie sie mit Trace-Metadaten
5. Implementieren Sie einen semantischen Cache, nachdem das Routing stabilisiert ist — semantisches Caching bei einfachen, paraphrasierten Prompts ist der Bereich, in dem sich der Cache-ROI üblicherweise zeigt (in diesem Baseline-Lauf nicht gemessen).

Wie TrueFoundry AI Gateway dies ermöglichte

• Vereinheitlichte OpenAI-kompatible API — A client, base_url points to Gateway; same code path for GLM, Opus, Haiku, and Sonnet.
• Virtual Models — weight-based 80/20 routing without application changes (Documentation).
• Semantic Cache — Similarity-based response reuse (Documentation).
• Observability — Token usage, latency, and cost headers for reconciliation; ~3–4ms latency and over 350 RPS on 1 vCPU at the gateway layer for high-throughput proxy scenarios.

Conclusion

Open-weight models like GLM-5.1 are designed to win simple traffic. Claude Opus 4.7 still earns its place on difficult prompts. The difference between them is large enough that routing is more important than model marketing.

In our 20-prompt test run through TrueFoundry AI Gateway, ein Haiku-Klassifizierungs-Router erzielte das beste Gesamtergebnis: etwa 31 % niedrigere durchschnittliche Kosten pro Million Tokens als bei reinem Opus, mit einem höheren durchschnittlichen Bewertungs-Score (4.94 vs 4.85)Rein Open bildete die Kostenuntergrenze; rein Opus die Qualitäts- und Geschwindigkeits-Obergrenze für die p50-Latenz.

‍