توجيه الأوزان المفتوحة على نطاق واسع: GLM-5.1 مقابل Claude Opus 4.7 على بوابة TrueFoundry للذكاء الاصطناعي

We ran 20 fixed prompts through TrueFoundry AI Gateway comparing four strategies: all Claude Opus 4.7, all Z.AI GLM-5.1, a Haiku classifier router (easy → open, hard → frontier), and an 80/20 virtual model. On this mix, classifier routing cut blended cost ~31% versus all- Opus ($15.72 vs $22.72 per 1M tokens) while scoring higher on our Sonnet judge (4.94 vs 4.85). All-open was cheapest ($3.00 / 1M) but slower and slightly lower quality. The takeaway: you do not need a single model string for every request — Gateway routing plus a cheap classifier can preserve frontier quality on hard tasks without paying frontier prices on easy ones.

Why this matters now

The open-weight wave is no longer theoretical. Models like GLM-5.1 ship with agentic coding positioning, 200K-token context, and list prices an order of magnitude below frontier APIs, while, Claude Opus 4.7 remains the reference for hard reasoning.

Platform teams face a familiar tradeoff:

• Route everything to frontier → predictable quality, painful unit economics at volume.
• Route everything to open-weight → attractive cost, uneven quality and latency tails on hard prompts.
• Build custom routers → flexible, but you own classification logic, failover, billing reconciliation, and cache semantics across providers.

TrueFoundry AI Gateway sits in the middle: 1000+ LLMs through a unified OpenAI compatible API, virtual models with weight-based routing, semantic cache headers, and transparent pricing metrics for billing truth. We wanted to measure whether a simple EASY/HARD classifier — one Haiku call per request — could beat both extremes on cost and quality for a realistic 20-prompt workload.

What we compared (technical tour)

Open-weight baseline: GLM-5.1

GLM-5.1 is Z.AI's April 2026 flagship, accessed via TrueFoundry's Gateway, aimed at long-horizon agentic work — planning, tool use, and multi-step coding loops.

Frontier baseline: Claude Opus 4.7

Opus 4.7 is Anthropic's top-tier model for complex reasoning. Note: Opus 4.7uses a new tokenizer that can emit more tokens than older Claude models for the same text — cost comparisons should use measured token counts, not character counts.

App-level classifier router

Our router classifies each prompt as EASY or HARD in a single call (~8 output tokens). EASY → GLM-5.1; HARD → Opus 4.7. Quality scoring uses Claude Sonnet 4.6 as an LLM judge (1–5 against per-prompt rubrics).

Gateway virtual model (80/20)

We also tested a virtual-model in Gateway configured for weight-based routing (80% open / 20% frontier in the UI). This measures provider-side load balancing without app-level classification — a different knob than the Haiku router.

About our benchmark

Prompts: 20 tasks — 10 labeled easy (summarize, format JSON, translate) and 10 hard (distributed systems tradeoffs, SQL injection review, contract ambiguity, K8s OOM debug, etc.).

Metrics per strategy:

What we did not claim: vendor SWE-bench scores, production traffic shapes.
‍

Vendor pricing context (May 2026)

GLM-5.1 is roughly 5× cheaper on input and ~8× cheaper on output than Opus 4.7 at list price — before routing, caching, or enterprise discounts. The interesting question is how much of that gap you keep after sending hard prompts to frontier.
‍

Our analysis (20-prompt run)

Cost per 1M tokens (this run's token mix)

‍

Router split (classifier)

The Haiku router sent 10/20 prompts to GLM-5.1 and 10/20 to Opus 4.7 — a 50/50 split on this prompt set (10 easy + 10 hard by design). Token volume followed suit: 7,774 tokens on GLM vs 10,072 on Opus for completion traffic.

Latency tails matter

Open-weight-only had the slowest p50 (20.1s) and an extreme p95 (~115s) — one long GLM completion on a hard prompt dominated the tail. Opus-only was fastest at p50 (9.1s) with a moderate p95 (~21s). The classifier landed in between on p50 (14.9s) with p95 ~26s.

Quality vs cost: the classifier sweet spot

• Router vs all-Opus: ~31% lower blended $/1M ($15.72 vs $22.72) with higher mean judge score (4.94 vs 4.85). Total dollar cost for 20 prompts was essentially the same (~$0.28) because judge + router overhead offset GLM savings — at higher volume, the per-token gap compounds.
• Router vs all-open: ~5.2× أعلى $/1M ولكن +0.19 نقطة جودة. الأرخص ليس الأفضل إذا كانت المطالبات الصعبة مهمة.
• 80/20 الافتراضي: 7.19 دولار / 1M بناءً على تقدير مزيج سعر القائمة، ولكن الجودة (4.50) تخلفت عن كلا الخطين الأساسيين. التوجيه القائم على الوزن بدون وعي بالمهمة ليس بديلاً للتصنيف في عبء العمل هذا — تحقق من المزيج الفعلي للواجهة الخلفية في Gateway Metrics، وليس فقط معرف النموذج الافتراضي.

لماذا تهم هذه النتائج

1. التصنيف غير مكلف مقارنة بإنجازات النماذج المتطورة. استدعاء Haiku واحد لكل طلب يُعد ضوضاء مقارنة بإنجاز Opus بحجم 1,024 رمزًا في المهام الصعبة. تنجح اقتصاديات الموجه عندما يشكل المرور السهل حصة كبيرة من الحجم — وعندما تكون الأخطاء في التوجيه نادرة.
2. سعر القائمة لا يساوي فاتورتك. قد تقوم البوابة بالتوجيه عبر مزودين مختلفين، أو تطبيق التخزين المؤقت، أو التفاوض على الأسعار. لقد طبقنا أسعار القائمة العامة على الرموز المقاسة من تشغيلنا؛ يجب عليك المطابقة مع Gateway Metrics → تنزيل البيانات الخام قبل تحديد ضوابط FinOps.
3. الكمون والجودة مرتبطان. توفير 31% من الرموز لا يجدي نفعًا إذا تجاوز زمن الاستجابة p95 اتفاقيات مستوى الخدمة (SLOs). أظهر خط الأساس مفتوح الوزن لدينا أن قرار توجيه خاطئ واحد (إرسال مطالبة صعبة فقط إلى GLM) يمكن أن يؤدي إلى ارتفاع كبير في زمن الاستجابة الطرفي.
4. نمطان للتوجيه، قصتان. على مستوى التطبيق سهل/صعب التوجيه الذي حسّن الجودة والتكلفة على هذه المجموعة. على مستوى واجهة المستخدم نماذج افتراضية بنسبة 80/20 محسّنة للبساطة التشغيلية لكنها لم تحقق الأداء المطلوب من حيث الجودة هنا — مفيدة للنشر التدريجي، وليست بديلاً كاملاً للتوجيه المدرك للمهام.

دروس عملية لفرق المنصات

1. ابدأ بزوج من النماذج الرائدة ومفتوحة الوزن متصل عبر عنوان URL أساسي واحد للبوابة. بدّل النماذج بتغيير سلسلة النموذج — لا حاجة لتفرع SDK لكل مزود.
2. أضف مصنفًا منخفض التكلفة (مثل Haiku أو ما شابه) قبل إضافة تعقيد إلى أوزان النموذج الافتراضي. قم بقياس معدل التوجيه الخاطئ على مجموعة فرعية ذهبية من المطالبات.
3. انشر قائمة مستويات المطالبات (سهل / صعب) متوافقة مع معاييرك — مجموعتنا المكونة من 20 مطالبة هي قالب، وليست توزيعك الإنتاجي.
4. سوّي التكلفة في مقاييس البوابة، وليس في تقديرات الدفاتر. صدّر ملف CSV للفواتير الخام وادمجها مع بيانات تتبع التعريف
5. أضف طبقة التخزين المؤقت الدلالي بعد استقرار التوجيه — التخزين المؤقت الدلالي للمطالبات السهلة والمعاد صياغتها هو المكان الذي يظهر فيه عادةً عائد الاستثمار من التخزين المؤقت (لم يتم قياسه في هذا التشغيل الأساسي).

كيف جعلت بوابة TrueFoundry AI هذا ممكنًا

• واجهة برمجة تطبيقات موحدة متوافقة مع OpenAI — عميل واحد، عنوان URL أساسي يشير إلى البوابة؛ نفس مسار الكود لـ GLM و Opus و Haiku و Sonnet.
• نماذج افتراضية — توجيه 80/20 قائم على الوزن دون تغييرات في التطبيق (الوثائق).
• ذاكرة التخزين المؤقت الدلالية — إعادة استخدام الاستجابة بناءً على التشابه (الوثائق).
• قابلية المراقبة — استخدام الرموز، زمن الاستجابة، ورؤوس التكلفة للمطابقة؛ زمن استجابة يتراوح بين 3-4 مللي ثانية وأكثر من 350 طلبًا في الثانية على وحدة معالجة مركزية افتراضية واحدة عند طبقة البوابة لسيناريوهات الوكيل عالية الإنتاجية.

خاتمة

نماذج مفتوحة الوزن مثل GLM-5.1 مصممة لجذب حركة المرور السهلة. Claude Opus 4.7 لا يزال يثبت جدارته في المطالبات الصعبة. الفجوة بينهما كبيرة بما يكفي لدرجة أن التوجيه أهم من تسويق النموذج.

في اختبارنا المكون من 20 مطالبة عبر بوابة TrueFoundry للذكاء الاصطناعي، وهو موجه مصنف Haiku قدم أفضل نتيجة مجمعة: تكلفة مجمعة أقل بنحو 31% لكل مليون رمز مقارنة بـ Opus بالكامل، مع متوسط درجة حكم أعلى (4.94 مقابل 4.85)ظل استخدام النماذج المفتوحة هو الحد الأدنى للتكلفة؛ بينما كان استخدام Opus بالكامل هو الحد الأقصى للجودة والسرعة لزمن الاستجابة p50.

‍