بنى وكيل الذكاء الاصطناعي الخاص بي أداة للمقارنة بين وكلات الذكاء الاصطناعي.

وكيل البرمجة الذكي الخاص بي، هيرمس، كتب أداة للقياس المعياري. تقوم هذه الأداة باختبار سرعة النماذج اللغوية المحلية لديّ، بالإضافة إلى قدراتها الذهنية ومدى ملاءمتها للاستخدام كوكيل ذكاء اصطناعي؛ وهي نفس النماذج التي يستخدمها وكلاء ذكاء اصطناعي آخرون. بعد ذلك تُخرج الأداة نتائجًا بصيغة JSON بالإضافة إلى جدول في الطرفية. يتكون هذا الأداة من 1,660 سطرًا من كود بايثون، وتُسمى bench-llm؛ أي أن وكيل ذكاء اصطناعي قد بنى أداة قياس معياري لوكلاء ذكاء اصطناعي آخرين.

ما الذي ستحصل عليه في النهاية

أمر واحد يتم تنفيذه على نموذج واحد ينتج عنه شكل كهذا من المخرجات في الطرفية (مثال على التنفيذ):

$ bench-llm gemma-4-31b-it

============================================================
  bench-llm — Benchmarking: gemma-4-31b-it
  GGUF Status:   READY
  GGUF Path:     ~/.lmstudio/models/google/gemma-4-31b-it-Q4_K_M.gguf
  GGUF Size:     16.5 GB
  Arch:          gemma4
  Quant:         Q4_K_M
============================================================

  🔥 Warming up model... OK (0.23s TTFT)

  ⚡ SPEED BENCHMARKS
  ----------------------------------------
    short_50 (131 chars, 3 runs)...
      TPS:  mean=84.2 median=83.8
      TTFT: mean=0.231s median=0.228s
    medium_200 (323 chars, 3 runs)...
      TPS:  mean=85.7 median=85.2
      TTFT: mean=0.312s median=0.308s
    long_800 (769 chars, 3 runs)...
      TPS:  mean=82.1 median=81.5
      TTFT: mean=0.541s median=0.537s

  🔍 Validating speed plausibility...
    Confidence: HIGH

  🧠 ABILITY TESTS
  ----------------------------------------
    Running: Code Generation (median_of_list)... PASS
    Running: Logic Puzzle (Pet Ownership)... PASS
    Running: JSON Compliance... PASS
    Running: Instruction Following... PASS
    Running: Summarization (Key Facts)... FAIL

    Ability Score: 4/5

  🤖 AGENT FITNESS TESTS
  ----------------------------------------
    Running: Task Acknowledgment... PASS
    Running: Format Adherence... PASS
    Running: Conciseness (Output/Input Ratio)... PASS

    Agent Fitness Score: 3/3

  📄 Results saved: ~/benchmarks/gemma-4-31b-it-2026-08-11.json

================================================================================
  BENCHMARK RESULTS: gemma-4-31b-it
================================================================================

  📊 SUMMARY TABLE
  ──────────────────────────────────────────────────────────────────────
  Model ID                         gemma-4-31b-it
  GGUF Size                        16.5 GB
  Architecture                     gemma4
  Quantization                     Q4_K_M
  T/s (short, mean)                84.2
  TTFT (short, mean)               0.231s
  Ability Score                    4/5 (80.0%)
  Agent Fitness Score              3/3 (100.0%)
  Confidence                       🟢 HIGH
  ──────────────────────────────────────────────────────────────────────

كما يقوم البرنامج بكتابة ملف JSON كامل في المسار ~/benchmarks/ يحتوي على جميع القياسات الخام، وردود الاختبارات، بالإضافة إلى ملخص منظم؛ حتى تتمكن من إعادة هذه النتائج إلى وكيلك البرمجي وتسأله: "أي من نماذجي يجب أن يتعامل مع معالجة ملفات JSON بكميات كبيرة؟"

ما الذي يتم اختباره؟

ثلاثة أبعاد، تم اختيار كل منها لأنه مهم بالنسبة لأداء نظام الوكلاء المستمر.

⚡ السرعة

ثلاثة أطوال للمدخلات: قصير (~50 حرفًا، مثل “اشرح ما هو المتغير”)، متوسط (~200 حرفًا، مثل “اشرح مفهوم التكرار”)، وطويل (~800 حرفًا، مثل “قارن بين ثلاثة نماذج برمجية”). يتم إجراء ثلاث محاولات تحضيرية قبل بدء القياسات الفعلية.

ما يتم قياسه:

• TTFT (الوقت اللازم لإنتاج أول رمز): كم من الوقت يستغرق النموذج قبل أن يبدأ في الكتابة. هذا مهم جدًا لتجربة المستخدم؛ أي تأخير يتجاوز 500 مللي ثانية يُعتبر بطيئًا.
• معدل الإنتاج (الرموز/الثانية): مدى سرعة النموذج في توليد النص بعد بدء العملية. هذا مهم عند التعامل مع كتل الكود الطويلة أو التقارير.
• سرعة معالجة المدخلات: مدى سرعة النموذج في معالجة النص المدخل قبل البدء في التوليد. هذا عامل تكلفة حقيقي ولكنه غير ظاهر للعيان.

كما يتم إجراء فحص مصداقية مقارنةً بالحدود القصوى المعروفة للأجهزة. فإذا زعم نموذج بحجم 30 جيجابايت أنه يحقق معدل إنتاج قدره 200 رمز/ثانية على بطاقة 7900 XTX، فإن أداة bench-llm ستعلم أن هذا الرقم ربما مضلل نتيجة استخدام تقنيات فك التشفير التخميني أو وجود ذاكرة تخزين مؤقتة مُسخنة مسبقًا.

🧠 القدرة

خمسة اختبارات بسيطة بالنسبة للنماذج القادرة، لكنها مؤشر واضح على ضعف النماذج الأخرى:

• توليد الكود: يجب كتابة دالة median_of_list(numbers) مع مراعاة الحالات الحدية (قائمة فارغة، طول زوجي، طول فردي، وعدم تغيير المدخلات). يتم تنفيذ هذه الدالة داخل أداة bench-llm ضد ست حالات اختبار؛ لذا فهو لا يقوم بمطابقة الأنماط النصية فحسب، بل يشغل الكود فعليًا.
• ألغاز منطقية: لغز يتعلق بتملك أربعة حيوانات (أليس/سمكة، بوب/طائر، كارول/قطة، دان/كلب). يتم استخراج الإجابات من الرد باستخدام التعبيرات النمطية والتحقق من صحتها جميعًا.
• التوافق مع تنسيق JSON: يجب إرجاع كائن JSON يحتوي على مفاتيح محددة. هذا يختبر قدرة النموذج على إنتاج بيانات JSON صحيحة ومطابقة للمواصفات، وهو الحد الأدنى المطلوب للتعامل مع الأدوات البرمجية.
• الالتزام بالتعليمات: يجب كتابة الأرقام من 1 إلى 10، ووضع علامة * بجانب الأرقام الزوجية، ثم حساب مجموعها. هذا يختبر مدى دقة النموذج في الالتزام بالتنسيق المطلوب؛ فالإجابة نفسها سهلة، لكن التنسيق هو الأساس.
• التلخيص: يتم تقديم فقرة معقدة حول الحوسبة الكمومية باستخدام الهيليوم. يتم التحقق مما إذا كانت ست حقائق تقنية رئيسية قد تم الاحتفاظ بها في الملخص. معظم النماذج تفقد على الأقل واحدة منها.

🤖 ملاءمة النموذج كوكيل ذكي

هنا تقوم أداة bench-llm بشيء لم أره في أي أدوات قياس أخرى؛ فهي ترسل للنموذج مهمة وكلاء حقيقية: البحث في سجلات النظام عن أسطر تحتوي على خطأ، تجميعها حسب الخدمة، وإنتاج تقرير بصيغة JSON. ثم يتم تقييم الرد كما لو كان من قبل مشرف وكلاء ذكي:

• الإدراك المهمة: هل فهم النموذج ما هو مطلوب منه؟ وهل استطاع وضع خطة عمل وتحديد العقبات المحتملة؟ (النماذج التي تبدأ في اختلاق سجلات غير صحيحة تفشل هنا).
• الالتزام بالتنسيق: هل يتطابق المخرج مع هيكل JSON المطلوب؟ يتم التحقق من وجود مصفوفة services، وقيمة عددية total_errors، بالإضافة إلى قيمة نصية scan_period.
• الإيجاز: ما هو معدل الإخراج مقارنةً بالمدخل؟ النماذج التي ترد على طلب مكون من 1300 حرف بـ 20,000 حرف من النص الطويل يتم تصنيفها على أنها “مطولة جدًا”. فالوكيل الذي لا يستطيع التلخيص يستهلك مساحة الذاكرة المتاحة في كل مرة يتفاعل فيها.

جميع اختبارات ملاءمة النموذج كوكيل تستخدم نفس المدخل، لكنها تقيس جوانب مختلفة من الرد الواحد. هذا يضمن سرعة أداء الاختبار مع الحفاظ على قياس الصفات المهمة عند تشغيل النموذج بشكل تلقائي دون إشراف بشري.

كيف تم بناؤه

هيرمس – وهو الوكيل المبرمج على جهازي – هو من كتب كل شيء. أعطيته مواصفات تقريبية: "أحتاج إلى أداة تقوم بقياس أداء النماذج المحلية في LM Studio، وتختبر سرعتها وقدراتها الذكائية، ثم تُخرج النتائج بصيغة JSON وجدول." غادر هيرمس، ثم عاد بمخطوط عمل، وبدأنا بالتعديل عليه.

كانت الخطوات كالتالي:

1. المرحلة الأولى: اختبارات السرعة فقط – الاتصال بواجهة برمجة التطبيقات المتوافقة مع OpenAI في LM Studio، تدفق الرموز النصية، قياس زمن الاستجابة وزمن معالجة كل رمز.
2. المرحلة الثانية: اختبارات القدرات – البرمجة (مع تنفيذ فعلي للكود)، ألغاز منطقية، التزام بالصيغة المحددة في JSON، القدرة على اتباع التعليمات، والتلخيص.
3. المرحلة الثالثة: تقييم مدى ملاءمة النموذج كوكيل – تنفيذ مهام نموذجية وتقييم الاستجابات كما لو كان النموذج وكيلاً في نظامي.
4. مراحل التحسين: تحديد ملف GGUF الفعلي على القرص (وتقرير حجمه ومستوى التكميم المستخدم)، التحقق من صحة سرعة المعالجة، إنشاء جدول التلخيص، وضع --quick للتشغيل السريع، أمر --list لاكتشاف النماذج المتاحة، وأمر --check التحضيري قبل بدء الاختبار.

تم تنفيذ جميع المراحل الأربع في فترة ما بعد الظهر الواحدة. المخطوط النهائي يحتوي على 1,660 سطرًا؛ كتبها هيرمس بالكامل. قمت بمراجعتها واختبارها على نماذج حقيقية، وأشرت إلى الأخطاء (“هذا الرقم المتعلق بالسرعة لا يمكن أن يكون صحيحًا بالنسبة لنموذج بحجم 123 مليار معلمة”)، فقام هو بتصحيحها. وقد نشأ أداة التحقق من الصحة تحديدًا من هذه الدورة التغذية الراجعة.

القرارات التصميمية التي بقيت كما هي

• التدفق المستمر بدل الاستطلاع المتكرر. يستخدم برنامج bench-llm تدفق البيانات المتوافق مع OpenAI للحصول على زمن استجابة لكل رمز نصي. فاستخدام طريقة الاستطلاع المتكرر سيؤدي إلى تشويش في قياس زمن الاستجابة وفقدان التفاصيل على مستوى كل رمز.
• تنفيذ الكود الفعلي في اختبارات البرمجة. لا يكتفي البرنامج بسؤال “هل هذا يبدو كدالة وسطية؟”؛ بل يقوم باستخدام exec() لتشغيل الكود في بيئة منعزلة، ثم يختبره عبر ست حالات اختبار؛ فأي نتيجة تبدو صحيحة لكنها لا تعمل فعليًا تُعتبر فاشلة.
• استخدام التعبيرات النمطية لاستخراج الإجابات في اختبارات المنطق وJSON. تفشل أدوات القياس التي تتطلب من النموذج إخراج صيغة محددة تمامًا عندما يضيف النموذج عبارات مثل “بالطبع! هذه هي إجابتك:” قبل الإجابة الفعلية. لذا يقوم برنامج bench-llm باستخراج المحتوى المطلوب من أي صيغة إضافية يضعها النموذج حوله، مما يختبر محتوى الإجابة وليس كثرة الكلمات المستخدمة.
• تنظيف ذاكرة VRAM بين الاختبارات. يقوم البرنامج بتشغيل الأمر pkill -f llama-server ثم ينتظر حتى يُظهر برنامج LM Studio عدم وجود أي نماذج محملة قبل بدء كل اختبار. فبدون ذلك، قد تؤثر ذاكرة التخزين المؤقت للنموذج السابق على قياس زمن الاستجابة في الاختبار التالي.
• تحديد ملف GGUF الفعلي. يقوم البرنامج بربط معرفات النماذج في LM Studio بالملفات الفعلية من نوع GGUF على القرص، عبر مطابقة تقريبية لأسماء الناشرين والبنية الهيكلية للنموذج. هذا يوفر معلومات عن حجم النموذج ومستوى التكميم المستخدم، وما إذا كان الملف موجودًا أصلاً؛ مما يجيب على سؤال “هل هذا النموذج جاهز فعلاً للقياس؟” قبل إهدار الوقت في تشغيله.

الإعداد

<pثلاث خطوات فقط:

# 1. Install the two dependencies (requests talks to LM Studio's model-metadata
#    endpoint — without it every model shows as "not found")
pip install openai requests

# 2. Make sure LM Studio is running with at least one model loaded
# (it should be listening on localhost:1234 — that's the default)

# 3. Run it
./bench-llm --list                         # see what's available
./bench-llm gemma-4-31b-it --quick         # smoke test
./bench-llm gemma-4-31b-it                 # full benchmark

<pلا توجد ملفات إعداد، ولا مفاتيح API (فبرنامج LM Studio يقبل أي سلسلة نصية)، ولا قاعدة بيانات. تظهر النتائج في ~/benchmarks/.

اختياري لكن مفيد: انسخ مجلد bench-llm إلى مسار PATH حتى تتمكن من تشغيله من أي مكان.

cp bench-llm ~/bin/
chmod +x ~/bin/bench-llm

نتائج حقيقية: النماذج الأساسية على جهازي المكتبي واللابتوب

الأرقام أدناه مأخوذة من مجموعات الاختبار التابعة للإصدارات اللاحقة (نفس طريقة قياس السرعة، ومجموعة اختبار أوسع)، وهي تخص النماذج الأساسية فقط — لا تشمل النماذج التي تم تحسينها من قبل المجتمع. “Rig” هو جهاز GPU بدون شاشة، يحتوي على وحدتي RTX 5090 ووحدتي RTX 3090؛ أما “APU” فهو معالج الرسومات المدمج في هذا اللابتوب. يمكن مقارنة السرعات فقط داخل نفس الجهاز. وتنطبق التحذيرات الخاصة بمجموعات الاختبار أيضًا هنا: حيث تغطي النصوص المرجعية عدة إصدارات، لذا يجب اعتبار الفراغات الصغيرة في النص ضوضاء.

السرعة + كفاءة الوكيل (المجموعة الوسيطة، تقرير بتاريخ 2026-08-18 — معدلات النجاح في الأقسام: الكود/الأدوات/التعليمات/التفكير):

المستوى الصعب (CrucibleForge، تقرير بتاريخ 2026-08-25 – معدل النجاح في التعامل مع الـ154 حالة صعبة التي يتم تقييمها بشكل موضوعي، من أصل 158 حالة صعبة إجمالاً؛ أما الحالات الأربع المتبقية فتُقيّم يدويًا. كل صف أدناه يمثل اختبارًا كاملاً يتضمن 251 حالة، وقد تم تقييمها جميعًا بواسطة نفس المقيم المحلي الذي يمتلك قدرات توازي 122 مليار معلمة):

كل عملية تشغيل لـ DeepSeek كلفت 0.331 دولار فقط من حيث تكاليف الرموز المستخدمة؛ وهذه هي الفائدة الحقيقية من وجود نسخة مرجعية مُستضافة: فهي رخيصة بما يكفي لإعادة التشغيل كلما بدت النتائج المحلية أفضل من المتوقع.

ما أستنتجه من ذلك: نموذج MoE Gemma 4 26B (حيث يتم تفعيل 4 مليارات معلمة فقط) هو الأداة الأساسية للاستخدام اليومي في جهازي؛ حيث يحقق سرعة معالجة تبلغ 229 تريليون عملية في الثانية، وزمن استجابة يبلغ 110 مللي ثانية، وهو أداة مثالية لاستدعاء الأوامر. أما نقطة ضعفه فهي اتباع التعليمات، وهذا بالضبط ما يعتمد عليه نظام الوكلاء غير المشرفين. أما نموج Nemotron الذي يحتوي على 4 مليارات معلمة فهو مفاجأة حقيقية؛ فعلى جهاز لابتوب مجهز بمعالج APU، يتفوق في اتباع التعليمات مقارنةً بنموذج الـ26 مليار معلمة على جهازي، رغم أن سرعته أبطأ بخمس مرات (18.5 تريليون عملية في الثانية على APU مقابل 229 تريليونًا على جهازي). أما النموذج ذو الـ27 مليار معلمة الذي يعمل على بطاقات الرسوميات الخاصة بي، فقد وصل الآن إلى مستوى قريب جداً من النموذج المرجعي المُستضاف، كما أنه أسرع بنسبة 1.7 مرة في توليد النتائج؛ وهذا هو الهدف الذي سعيت لتحقيقه عند تصميم هذا المستوى من الأداء. أما النماذج ذات الـ1.5 مليار، و7 مليارات، و256 مليون معلمة، فهي تمثل ما يُعرف بـ"النماذج الصغيرة جداً لاستخدامها في أنظمة الوكلاء": لاحظوا أن قدرتها على استرجاع المعلومات من سياقات طويلة تظل مقبولة حتى بعد أن تتدهور قدرتها على البرمجة والحسابات الرياضية؛ لذا فإن قياس أدائها في هذا الجانب وحده لا يخبرنا شيئاً تقريباً.

المستوى الصعب — لوحة كاملة مكونة من 20 نموذجًا

نفس مجموعة اختبارات CrucibleForge المكونة من 251 حالة، لكن الآن على شكل لوحة اختبار تضم 20 نموذجًا (تقرير بتاريخ 2026-09-04). تم الاحتفاظ بثلاثة عشر صفًا من اللوحة السابقة؛ أما الصفوف السبعة الجديدة فجميعها عبارة عن تشغيلات قياسية حسب البروفايل — أي أنها تستخدم مجموعة محددة من 56 حالة اختبار وليس المجموعة الكاملة — لذا فإن ترتيبها التصنيفي إرشادي وغير نهائي. الصف الأول فقط لا يحمل أي علامات تحذيرية؛ أما باقي الصفوف فهي إما ذات مراجعة قديمة أو جزئية، أو تنتمي لفئة التشغيلات القياسية حسب البروفايل، أو (كالصف التاسع) تم تقييمها بواسطة محكم مختلف. كما أن المجموعة نفسها خضعت لتغييرات في إصدارها بين عمليات الاختبار؛ لذا يجب اعتبار الفراغات الصغيرة بين الصفوف التي تحمل علامة ⚠️ مجرد ضجيج، إلى أن يتم إجراء عملية تشغيل نظيفة --fresh. المحكم المستخدم هو نفسه النموذج المحلي Qwen3.5-122B-A10B، باستثناء الصف التاسع الذي تم تقييمه بواسطة Gemma4-31B-QAT-Uncensored. أربعة من أصل تسعة عشر صفًا تعود لعائلة Qwen، لذا فإن الأعمدة الخاصة بالتقييم (RP / المحتوى الصريح / Steer / Plan) تميل قليلاً لصالح هذه العائلة. المجموع يمثل المتوسط المرجح لكافة المكونات (من 0 إلى 100)؛ أما نسبة النجاح الصعبة فهي نسبة الحالات التي تم اجتيازها من بين الحالات الصعبة المستهدفة في كل صف (154 حالة للصفوف التي تستخدم المجموعة الكاملة، و38 حالة للصفوف التي تستخدم مجموعة الـ56 حالة فقط). الأعمدة RP / المحتوى الصريح / Plan تمثل درجات التقييم من 0 إلى 10 التي أعطاها المحكم (يتم تقييم الصفوف القياسية حسب البروفايل بناءً على 6 أسئلة؛ “—” تعني أنه لم يتم قياس ذلك). أما tok/s فهو رقم قابل للمقارنة فقط على نفس الجهاز المضيف؛ بينما التكلفة تمثل مجموع توكنات واجهة البرمجة للصفوف التي لها تكلفة محددة.

* حقق نموذج qwen3.8-27b-abliterated درجة 10.0؛ لكنه خطط للرد على مجرد 2 من أصل 6 أسئلة فقط؛ أما نموذج M3 فحقق درجة 9.9 في جميع الأسئلة الستة. † هناك مدخل إضافي في تقرير الاختبارات لم يتم إدراجه في هذا الجدول: وهو نموذج من نوع GGUF بحجم 122 مليار معلمة؛ يحتوي معرف النموذج على كلمة تحظرها أداة حماية المحتوى في الموقع، لذا لا يمكن ذكر اسمه هنا؛ تم إجراء اختبارات على 22 حالة، والنتيجة الإجمالية هي 70.6، بينما كانت نسبة الأسئلة الصعبة 25% (أي 1 من أصل 4).

ما أستنتجه من لوحة التقييم التي تضم 20 نموذجًا: الصف الأول لم يتغير، ولا يزال يحمل العنوان التالي: DeepSeek-V3-Pro يتصدر في المؤشر الإجمالي (90.2) ومعدل النجاح في المهام الصعبة (93%، أي 143 من أصل 154)؛ وهو الصف الوحيد الذي لم يُضع عليه أي علامات تحذيرية — تم اختباره باستخدام الحزمة الكاملة من الأدوات، ومع استخدام نظام التقييم القياسي، بتكلفة قدرها 1.10 دولار. يظل M3 النموذج الأفضل في مجال التخطيط (حيث حقق تقييمًا إجماليًا قدره 9.9 عبر جميع الاختبارات الستة، مقابل 7.6 لـ Pro و7.0 لـ Flash)، وهو أيضًا النموذج المدفوع الأسرع من حيث سرعة المعالجة (212 توكن/ثانية)؛ لم يتغير الحد الأقصى لتقييمه مقارنة باللوحة السابقة — فهو يرفض تنفيذ المهام التي تحتوي على محتوى جنسي صريح، وكذلك طلبًا واحدًا يحتوي على محتوى للبالغين (معدل الاستجابة 70%)، لكنه لا يسمح بأي محتوى ضار (نسبة الرفض التام لكل المحتويات الضارة 100%، ولا توجد حالات امتثال خاطئ أو رفض مفرط). ما هو جديد هذا الأسبوع هو ما يظهر في الصفوف الستة التالية؛ وجميع هذه الصفوف تم اختبارها على مجموعة من 56 حالة مختلفة، لذا فإن قابلية المقارنة بينها محدودة. jax-xortron-27b هو الأفضل بين هذه النماذج في المؤشر الإجمالي (82.8)، لكن هذا الترتيب يعتمد على نتائج 71% فقط من أصل 38 حالة صعبة، دون أن يُختبر في سياقات تتطلب معالجة نصوص طويلة؛ كما أن ضعفه الواضح هو في مجال الرياضيات (17% فقط من النجاح، أي 1 من أصل 6 محاولات) — وهذه النتائج مؤشرية وليست نهائية. بقية النماذج المضافة تنتمي إلى نفس العائلة المحلية، وتؤكد على النمط الذي أظهرته النماذج الأخرى في الحزمة الكاملة: فالنماذج التي تقدم نصوصًا جيدة من حيث الجودة (تقييم RP يتراوح بين 8.3 و9.3) تعاني في المقابل من ضعف واضح في أدائها في الاختبارات الرياضية؛ ففي أربعة من النماذج الستة الجديدة، كان معدل النجاح في الرياضيات صفرًا، بينما بلغ أفضل معدل نجاح 17%. hy-mt2-30b-a3b هو النموذج الذي يُعد تحذيريًا؛ فعلى الرغم من سرعته العالية (237 توكن/ثانية)، إلا أن معدل نجاحه في المهام الصعبة بلغ 18% (10% في البرمجة و10% في استخدام الأدوات). أما الصف التاسع (dark-scarlett-iq4-xs-uncat، بمؤشر إجمالي قدره 79.2) فقد تم تقييمه بواسطة نظام تقييم مختلف، لذا فإن تقييماته غير قابلة للمقارنة مع بقية النماذج؛ كما أن الصف رقم 14 لم يتم عرضه لأن معرف النموذج الخاص به لا يمكن طباعته على هذا الموقع. الصفوف الثلاثة الأخيرة تظهر نفس الفجوة بين حجم النموذج وقدرته على الأداء؛ فالنموذج بحجم 256 مليون بارامتر ليس نموذجًا للبرمجة، بينما النماذج بحجم 1.5 مليار و7 مليارات بارامتر لا ترقى إلى المستوى الذي يطالب به هذا المقال. ملخص التكاليف للصفوف المدفوعة الثلاثة: 2.85 دولار كتكلفة للمعالجة (1.10 دولار لـ Pro، و0.679 دولار لـ Flash، و1.069 دولار لـ M3)؛ ومع ذلك، فإن جميع هذه النماذج لا تزال تحمل علامات تحذيرية في هذا التقرير (إصدارات قديمة أو نتائج غير كاملة)، لذا يُنصح بإعادة الاختبار باستخدام الأمر --fresh قبل اعتبار هذه النتائج الحالية. نظام التقييم المستخدم هو نفسه النموذج المحلي بحجم 122 مليار بارامتر الذي تم استخدامه في أجزاء أخرى من هذا المقال، وهو مجاني. الصف رقم 14 اليوم (DeepSeek V4-Flash، تاريخ الاختبار: 2026-09-09، إصدار V4.1 التجريبي، بمؤشر إجمالي قدره 72.2) هو أول صف يتم تسجيله وفقًا للتنسيق الجديد لتواريخ الاختبارات؛ فالتاريخ هنا يحمل معلومات حول الإصدار المستخدم، لأن موقع api.deepseek.com يعرض فقط الاسم العام deepseek-v4-flash دون أي تفاصيل حول رقم الإصدار أو التاريخ الدقيق للتحديث.

ما الذي يجعل هذا مختلفًا؟

هناك العديد من معايير تقييم النماذج اللغوية. معظمها عبارة عن مجموعات تمارين أكاديمية (MMLU) أو أسئلة عامة مصممة خصيصًا لتحسين ترتيب النماذج في القوائم الترتيبية. لكن أداة bench-llm تقوم بثلاثة أشياء مهمة للغاية بالنسبة لأي شخص يقوم فعلاً بتشغيل نماذج لغوية محلية:

1. إنها تختبر خصائص الوكلاء الذكيين، وليس خصائص برامج الدردشة. الالتزام بالتنسيق، والقدرة على فهم المهام، والإيجاز في الردود هي العوامل الحاسمة في نجاح النموذج ضمن بيئة عمل تلقائية. فالنموذج الذي يتفوق في المحادثات لكنه لا يستطيع الالتزام بتنسيق JSON يكون عديم الفائدة في أي سير عمل يتطلب استدعاء أدوات خارجية.
2. إنها تتحقق من صحة قياساتها بنفسها. آلية التحقق من الصلاحية تكتشف الأرقام التي لا يمكن أن تكون صحيحة؛ سواءً كان ذلك نتيجة لعمليات فك التشفير التخمينية، أو ذاكرة التخزين المؤقت المُسخنة مسبقًا، أو أخطاء في القياس. إذا لم تستطع أداة التقييم أن تخبرك متى تكون نتائجها غير صحيحة، فلا يمكنك الوثوق بأي من هذه النتائج.
3. إنها عبارة عن سكريبت واحد فقط. لا حاجة لاستخدام Docker أو قواعد بيانات أو برامج تشغيل GPU، ولا حتى تنزيل مجموعة بيانات بحجم 50 جيجابايت. كل ما عليك هو ملف Python واحد، وتثبيته عبر pip، وسيبدأ العمل مع أي نموذج لغوي قمت بتحميله في LM Studio.

نقاط يجب الانتباه إليها

• يجب أن يكون LM Studio قيد التشغيل أولاً. لا يقوم برنامج bench-llm بتشغيل LM Studio نيابة عنك؛ بل يتصل بعنوان localhost:1234. إذا لم يكن هناك أي شيء يستمع على هذا العنوان، فسيفشل البرنامج مع إظهار رسالة خطأ واضحة.
• عملية تنظيف ذاكرة الفيديو (VRAM) صارمة للغاية. يقوم البرنامج بتنفيذ الأمر pkill llama-server بين كل اختبارين لتفريغ ذاكرة التخزين المؤقت KV. إذا كان لديك عمليات llama-server أخرى ترغب في الحفاظ عليها، فلا تشغل برنامج bench-llm؛ أو قم بتعديل خطوة التنظيف.
• اختبار التلخيص هو الأصعب. تقريباً كل النماذج التي اختبرتها تفوت على الأقل حقيقة مهمة واحدة. إذا حققت نموذج ما درجة 4 من أصل 5، وكان فشله الوحيد في اختبار التلخيص، فهذه نتيجة جيدة جداً؛ لا تعتبر ذلك عيباً في النموذج.
• نماذج التفكير تظهر زمن استجابة أبطأ. تقضي نماذج التفكير وقتاً في مرحلة التفكير قبل إنتاج النتيجة النهائية. يقيس برنامج bench-llm زمن الاستجابة من اللحظة التي يظهر فيها أول رمز، سواء كان رمز تفكير أم لا؛ مما يجعل هذه النماذج تبدو أبطأ مما هي عليه في الواقع، لأن رموز التفكير تظهر خلال فترات “الصمت” في عملية المعالجة. يفصل المخرج بتنسيق JSON بين زمن الاستجابة ttft_reasoning_s وttft_content_s حتى يمكنك رؤية التوزيع بدقة.
• اختبار البرمجة يقوم بتنفيذ مخرجات النموذج. يتم ذلك في بيئة منفصلة تحتوي فقط على دوال اختبار؛ ليست بيئة عزل حقيقية، لذا يجب تشغيله باستخدام مستخدم لا يوجد لديه ما يخسره. لكن إذا كنت تشعر بالقلق من تنفيذ الكود الذي يولده النموذج اللغوي، فتجاوز اختبارات القدرات باستخدام الخيار exec() --speed-only.
• العديد من النماذج تحتاج وقتاً طويلاً للاختبار. يستغرق الاختبار الكامل لنموذج واحد ما بين دقيقتين إلى 5 دقائق حسب سرعته؛ أما اختبار عدة نماذج فيستغرق مساءً كاملاً. استخدم الخيار --quick للحصول على مقارنات سريعة، واحتفظ بالاختبار الكامل للنماذج التي ترغب في اختيارها بشكل نهائي.

ما الذي حل محله: CrucibleForge

لقد “مات” مشروع bench-llm بسبب نجاحه؛ فخمسة اختبارات للقدرات وثلاثة اختبارات لتقييم أداء النماذج تشكل أداة رصد جيدة، لكنها في الوقت نفسه أداة تقييم سيئة للغاية: فما إن يحقق كل نموذج درجات 5/5 و3/3، تتوقف الأداة عن إعطاء أي معلومات مفيدة. الإصدار الجديد يُسمى CrucibleForge؛ يتكون من حوالي 7,900 سطرًا من كود بايثون بدلاً من 1,660 سطرًا، وقاعدته التنظيمية هي أن الأسئلة الصعبة يجب أن تظل سهلة التقييم.

• 251 حالة اختبار، منها 158 صعبة. تشمل هذه الحالات مسائل رياضية تنافسية ذات إجابات عددية، وألغاز منطقية، ومشكلات برمجية تتطلب مستويات تعقيد محددة (مثلاً: خوارزمية حساب الانعكاسات بتعقيد O(n²) تفشل بسبب تجاوز الوقت المسموح؛ بينما يُحل الحل المتعلق بالتكرار عند n = 10¹⁸ باستخدام التأسيس المصفوفي). كما تشمل اختبارات استخدام الأدوات مع وجود أدوات مضللة، بالإضافة إلى إمكانية حقن أوامر خبيثة في نتائج الأدوات؛ فضلاً عن اختبارات استرجاع المعلومات من سياقات طويلة تتراوح بين 12 ألف و24 ألف رمز، واختبارات الالتزام بتعليمات متعددة. حتى النماذج القوية ذات سعة 27–31 مليار معلمة التي نجحت في اختبارات bench-llm تحقق درجات أقل من 100% هنا.
• التقييم البرمجي يتم عبر تشغيل الكود. يتم تنفيذ كل حل برمجي داخل بيئة عزل آمنة bwrap؛ لا يوجد اتصال بالشبكة، والنظام للقراءة فقط، والحد الأقصى للتشغيل هو 15 ثانية. لكي يُعتبر الحل ناجحًا، يجب أن يحتوي على إشارة محددة في مخرجاته؛ وبالتالي لا يمكن للبرنامج التظاهر بالنجاح عبر الخروج بقيمة صفر. إن اختبار البرمجة الوحيد في bench-llm الذي كان يعتمد على دالة exec() هو الأصل الذي استند إليه هذا النظام، وهو السبب الذي جعلني أثق في فكرة تطويره.
• الإجابات النصية يجب أن تتطابق مع الإجابة الصحيحة تمامًا. عندما تكون الإجابة عبارة عن فقرة نصية، يتم عرض الإجابة الصحيحة لنموذج التقييم، ثم يُطلب منه فقط تحديد ما إذا كانت إجابة النموذج المختبر يعني نفس المعنى. أي نموذج تعليمي جيد يمكنه القيام بذلك؛ وبالتالي يتوقف دور نموذج التقييم عن كونه عائقًا، كما أنه لا يخضع للاختبار أبدًا.
• النظام يعتمد على مزودي الخدمات وليس على واجهات البرمجة الخلفية. يتم تحديد المزودين في ملف تسجيل؛ مثل LM Studio، StudioForge، Ollama، vLLM، أي نظام متوافق مع OpenAI، بالإضافة إلى DeepSeek وOpenRouter. النماذج التي تستخدم هذه الخدمات تُشغّل اختباراتها بشكل متزامن، وتُبلغ عن تكلفة استهلاك الرموز. يتم قراءة مفاتيح الوصول API من متغيرات البيئة فقط، ولا يتم حفظها أبدًا في ملف التسجيل.
• النظام يطلب إذنًا قبل استخدام وحدات معالجة الرسومات. على جهاز StudioForge الخاص بي، يتم طلب “إيجار” مؤقت لوحدات المعالجة الرسومية المطلوبة؛ أولاً للنموذج المختبر، ثم لنموذج التقييم. إذا كانت وحدة معالجة رسومية تُستخدم حاليًا من قبل شخص آخر، يتم الانتظار حتى تنتهي، دون طردها؛ كما يتم إعادة توزيع أي موارد تم استخدامها عند انتهاء الاختبار. هذا النظام هو التطور المباشر لآلية pkill -f llama-server المستخدمة في bench-llm، والتي كانت تحل نفس المشكلة عبر إيقاف جميع النماذج.
• النظام يستعيد الإجابات التي تفقدها النماذج القادرة على التفكير. عندما ينفد الوقت المسموح للنموذج القادر على التفكير، فإنه يعود بسبب length ويُرسل إجابة فارغة. في السابق، كان ذلك يبدو كخطأ من نموذج التقييم؛ لكن الآن يلاحظ النظام ذلك ويُعيد تشغيل الاختبار بنفسه دون استخدام قدرات التفكير، ويُسجل عدد المرات التي حدث فيها ذلك. هناك أيضًا أمر recover الذي يعيد تشغيل فقط تلك الحالات من سجل الاختبارات القديم.
• واجهة ويب متاحة على 127.0.0.1:8777؛ يمكن من خلالها اختيار النماذج والفئات والمستويات، ومتابعة سجل التشغيل، وقراءة التقارير، بالإضافة إلى فتح أي حالة فاشلة لرؤية السؤال والإجابة والمنطق المستخدم وتعليق نموذج التقييم. هذه الواجهة مبنية على مكتبات بايثون القياسية ولغة JavaScript بسيطة؛ لا تتطلب CDN أو خطوات بناء، ويجب إدخال رمز مميز قبل أن تُفعّل أي وظائف غير محلية.

الأوامر المتاحة هي: status، run، judge، recover، report، pairwise، all، gui، config، models وcases. وهناك أمران أكثر أهمية من البقية:

uv run crucibleforge all --profile standard --models my-model --yes
uv run crucibleforge cases verify

الأول هو اختيار ثابت يضم 56 حالة اختبار؛ تم تصميمه بحيث يُكمل تنفيذه في ساعة تقريبًا على نموذج بسعة 27 مليار معلمة، بما في ذلك مرحلة التقييم؛ وبالتالي يمكن تكرار هذا الاختبار دون تكاليف باهظة. أما الأمر الثاني فهو ما أفتخر به أكثر: حيث يقوم النظام بإعادة فحص جميع الأسئلة يدويًا؛ بتشغيل كل الحلول المرجعية الـ36 ضد اختباراتها الخاصة داخل بيئة العزل الآمنة، وإعادة حساب 35 إجابة رياضية ومنطقية عبر طرق القوة الغاشمة، بالإضافة إلى إعادة بناء كل “كومة” بيانات لتأكيد أن الإجابة الصحيحة موجودة في المكان المتوقع. حتى الآن، أظهر التقرير نجاح فحص 251 حالة، دون وجود أي مشاكل. كما يتم تشغيل هذا النظام ضمن مجموعة الاختبارات الأصلية التي تضم 239 اختبارًا؛ وبالتالي لا يمكن لأي سؤال خاطئ أن يُفشل جميع النماذج دون أن يُكتشف ذلك، مما يضمن دقة التقييم.

تم نشر CrucibleForge رسميًا. تم إزالة الإعدادات الخاصة بالأجهزة من المستودع، لكن الكود بقي كما هو؛ يمكن الاطلاع على المشروع عبر github.com/LaserLloyd/CrucibleForge، وهو مرخص بموجب رخصة MIT، تمامًا مثل بقية المشاريع هنا. أما ملف التحميل الخاص بـ bench-llm الموجود أدناه فهو النسخة الأصلية التي تم إيقاف استخدامها، وليس نسخة تجريبية من CrucibleForge.

التحميل

هذا هو bench-llm، النسخة الأصلية التي تم التخلي عنها الآن — وليست CrucibleForge. إنه مجرد سكريبت بايثون واحد بالإضافة إلى ملف README؛ لا يوجد خطوة بناء أو معالج تثبيت، فقط قم بفك الضغط ثم تشغيله. ولا يزال هذا هو أسرع طريقة للحصول على نتائج أولية من أي نموذج قمت بتحميله، وهو ما يصفه الجزء الأول من هذه المقالة. إذا كنت تبحث عن مستوى أعلى من الأداء، فانتظر صدور CrucibleForge.

يحتوي ملف الضغط على:

• bench-llm — سكريبت القياسات الذي يتكون من 1,660 سطرًا
• README.md — تعليمات مختصرة حول الإعداد والاستخدام

<pكُتب كلا الملفين بواسطة Hermes، وهو وكيل البرمجة الخاص بي. يخضعان لرخصة MIT؛ يمكنك استخدامهما وتعديلهما وإدراجهما في أدواتك الخاصة. المتطلبات: openai وrequests. يتوقع البرنامج وجود LM Studio على العنوان localhost:1234، كما سيقوم بأمر pkill -f llama-server بين كل تشغيل وآخر — لذا يرجى قراءة قسم الملاحظات المهمة قبل تشغيله على جهاز يقوم بخدمة تطبيقات أخرى.

مرتبط أيضًا: ما هي التكاليف الفعلية لاستخدام وكلاء الذكاء الاصطناعي (لماذا تعد سرعة المعالجة المحلية مهمة)، Reasonix وDeepSeek Harness (وكلاء البرمجة الذين يعتمدون على هذه النماذج)، بالإضافة إلى مجموعة الوكلاء الذكاء الاصطناعي المحلية التي تعمل عليها هذه الأدوات.

التنزيلات

• Download bench-llm, the original single-file script (zip — retired, still works) 18 KB

مجاني للاستخدام الشخصي. إذا وفّر لك عصرًا كاملًا من الوقت، فزر القهوة قريب منك.