أظهر اختبار مرجعي لخمسة من وكلاء نماذج اللغة الكبيرة (LLM agents) التي تعمل محلياً على بطاقة RTX 5090 واحدة أن نموذج "خليط الخبراء" (MoE) بـ 35 مليار معلمة قد تفوق على أقرانه في مهمة برمجة واقعية. وقد توج الاختبار، الذي تضمن إضافة "مدير علامات" (Tag Manager) إلى لوحة تحكم مسؤول موجودة مسبقاً دون استخدام أي واجهات برمجة تطبيقات سحابية (cloud APIs)، نموذج Qwen 3.6 35B-A3B كفائز واضح.

لماذا يكتسب هذا الاختبار أهمية

تشغيل نماذج اللغة الكبيرة على الأجهزة الشخصية يتيح للمطورين تجنب رسوم واجهات برمجة التطبيقات (API) ومخاوف خصوصية البيانات. ومع ذلك، لا يزال مصطلح "الوكلاء المحليون" (local agents) مجرد كلمة رنانة: فهل يمكنهم حقاً تعديل الملفات، واستدعاء أدوات سطر الأوامر، وإرسال كود جاهز للإنتاج دون تدخل بشري؟ هذه المقارنة العملية، المجردة من الخدمات السحابية، تمنح المطورين تصوراً ملموساً عن المستوى الذي وصلت إليه هذه التقنية.

الأجهزة والمهمة

عملت جميع النماذج الخمسة على نفس محطة العمل: وحدة معالجة رسومات RTX 5090، وهي بطاقة استهلاكية عالية الأداء، دون أي خدمات خارجية. كانت المهمة بسيطة عمداً ولكنها تمثيلية – إضافة مكون "مدير العلامات" (Tag Manager) إلى قسم مسؤول تم بناؤه بالفعل. تطلب النجاح من النموذج تحديد ملفات المصدر الصحيحة، وتعديلها، والتحقق من أن الميزة الجديدة قد دُمجت دون كسر الوظائف الحالية.

أداء النماذج

  • Qwen 3.6 35B-A3B (MoE) – أنجز المهمة بشكل مستقل، وأضاف تحسينات منطقية لم تُطلب منه، ولم يحتاج إلى أي إصلاحات برمجية بعد التشغيل.
  • Qwen 3.6 27B (dense) – أكمل المهمة ولكنه استغرق ضعف عدد خطوات التفاعل تقريباً، وأساء تفسير التعليمات في بعض الأحيان.
  • GLM-4.7-Flash (dense) – قدم تنفيذاً يعمل، ولكنه استخدم أنماط مطابقة ملفات غير صحيحة وأغفل فحوصات الأمان، مما جعل الكود عرضة للثغرات.
  • Qwythos-9B – لم ينفذ أي أدوات حقيقية؛ قد يعود الفشل إلى النموذج نفسه أو إلى الإعداد المحلي، لكن الاختبار لم يتمكن من عزل السبب.
  • Nemotron-3-Nano (hybrid) – علق في حلقة مفرغة، حيث قضى 40 دورة في البحث عن مجلد كان قد حدد موقعه بالفعل، ولم يتقدم بعد تلك النقطة.

ما تكشفه النتائج

البنية الهندسية ليست مؤشراً موثوقاً

تفوق نموذج MoE، الذي يقسم معلماته عبر عدة شبكات فرعية من الخبراء، تفوقاً ساحقاً، بينما انقسمت النماذج الكثيفة (dense) والهجينة (hybrid) بين النجاح والفشل الذريع. يشير هذا إلى أن الخيارات الهندسية البحتة لا تضمن الكفاءة في استخدام الأدوات.

لا يزال استخدام الأدوات يمثل عقبة رئيسية

لم يستخدم أي من الوكلاء الخمسة أداة لقطة الشاشة (screenshot tool) المخصصة للاختبار. حاول الجميع الارتجال، إما عن طريق تخمين أسماء الملفات أو محاولة إيجاد حلول غير مباشرة. لا تزال الفجوة كبيرة بين "القدرة على توليد الكود" و"القدرة على إدارة الأدوات الخارجية".

التشغيل محلياً يعني تصحيح أخطاء المكونات، وليس النموذج فقط

تطلب نموذجان إجراء إصلاحات فورية لقوالب الأوامر (prompt templates) الخاصة بهما قبل أن يبدأ الاختبار حتى. لقد طغى الجهد المبذول في إصلاح الأخطاء الخاصة بالنماذج على الوقت المستغرق في كتابة كود "مدير العلامات" الفعلي، مما يسلط الضوء على مدى هشاشة عمليات النشر المحلية الحالية.

ملاحظة تحذيرية

يعكس هذا الاختبار المرجعي تكويناً واحداً للأجهزة، وسيناريو برمجة واحداً، ومجموعة صغيرة من النماذج. لقد أخفق نموذج Qwen 3.6 35B-A3B سابقاً في جولة سابقة؛ وكان فشله السابق مجرد صدفة. لذلك، فإن النتائج استرشادية وليست نهائية.

ما يجب مراقبته مستقبلاً

ستحتاج الجولات القادمة إلى توسيع مجموعة المهام، وتضمين سلاسل أدوات أكثر تنوعاً، والاختبار على نطاق أوسع من الأجهزة. يجب على المراقبين تتبع ما إذا كانت نماذج MoE تتفوق باستمرار على التصميمات الكثيفة والهجينة، وما إذا كان بإمكان المطورين بناء أغلفة (wrappers) موثوقة تلغي الحاجة إلى الإصلاح اليدوي للأخطاء.

الخلاصة: يمكن لنموذج MoE بـ 35 مليار معلمة أن يعمل بالفعل كمساعد برمجة محلي كفء، ولكن النظام البيئي الأوسع — تكامل الأدوات، وهندسة الأوامر (prompt engineering)، وبيئات التشغيل المستقرة — لا يزال متأخراً. وإلى أن تترابط هذه الأجزاء، يجب على المطورين ضبط توقعاتهم بشأن الوكلاء المحليين الذين يعملون بنظام "التوصيل والتشغيل" (plug-and-play).