Gemma 4 في Codex CLI: التشغيل المحلي ناجح عمليًا، لكنه لا يزال أضعف من السحابة

باتت Gemma 4 المحلية قادرة على العمل داخل Codex CLI بوصفها وكيلًا (agent) للبرمجة اليومية: تقرأ الملفات، وتكتب التعديلات (patches)، وتشغّل الاختبارات. لكن التجربة التي أُجريت على منصتين مختلفتين أظهرت أن نجاح التشغيل ليس سوى نصف المعادلة. فمن حيث الموثوقية ودقة الشيفرة وجودة النتيجة من المحاولة الأولى، لا يزال GPT-5.4 السحابي في المقدمة بفارق واضح.

لم يشأ صاحب الاختبار فحص «التطوير المحلي بالذكاء الاصطناعي» كمفهوم مجرد، بل سيناريو عمليًا بسيطًا: هل يمكن للنموذج أن يحل محل واجهة API السحابية في العمل اليومي مع Codex CLI؟ والدافع مفهوم: تكلفة الرموز (tokens)، ومتطلبات الخصوصية، والاعتماد على خدمات خارجية.

جُهّزت لذلك منصتان. الأولى MacBook Pro بمعالج M4 Pro وذاكرة 24 غيغابايت، شُغّل عليها نموذج Gemma 4 26B MoE بتكميم Q4_K_M عبر llama.cpp. والثانية Dell Pro Max GB10 بذاكرة موحدة (unified memory) سعتها 128 غيغابايت ومعالج NVIDIA Blackwell، شُغّل عليها نموذج Gemma 4 31B Dense عبر Ollama 0.20.5. وفي الحالتين رُبط النموذج بـ Codex CLI كمزوّد مخصص بوضع responses API.

لم يكن إعداد البيئة المحلية سهلًا. فعلى Mac، تعطّل Ollama عند استخدام tool calling بسبب أخطاء في البث (streaming)، وتجمّد مع المطالبات الطويلة، وهو أمر حرج لـ Codex CLI لأن موجّه النظام وحده يشغل نحو 27 ألف رمز. وفي النهاية كان الحل العملي هو llama.cpp مع ضبط يدوي للأعلام (flags)، وتعطيل web_search، وسياق بطول 32 768 رمزًا. أما على GB10 فلم ينجح كل شيء من أول مرة أيضًا: اصطدم vLLM بعدم توافق بين إصدارات PyTorch وبنى CUDA الخاصة بـ Blackwell، كما عالج llama.cpp المبني يدويًا بعض أنواع الأدوات معالجة غير سليمة. ونتيجة لذلك، لم يكن الحل الأنسب مجددًا هو المنظومة «المثالية»، بل المنظومة التي اشتغلت فعلًا، أي Ollama.

أُجري الاختبار في 12 أبريل 2026 على Codex CLI v0.120.0. وعبر codex exec --full-auto أُعطيت الإعدادات الثلاثة جميعها المهمة نفسها: كتابة دالة Python باسم parse_csv_summary مع معالجة الأخطاء، ثم إعداد الاختبارات وتشغيلها. وكان أداء GPT-5.4 السحابي بمستوى reasoning effort مرتفع هو الأفضل: كتب شيفرة منظمة مع type hints وسلسلة استثناءات سليمة، واجتاز الاختبارات الخمسة كلها من المحاولة الأولى في 65 ثانية.

وقدّمت Gemma 4 31B على GB10 نتيجة عاملة من المرور الأول أيضًا، لكن بجودة أبسط: دون type hints ودون التعرف على القيم المنطقية (boolean). ومع ذلك اجتازت الاختبارات الخمسة كلها فورًا، واستغرق التنفيذ نحو سبع دقائق وثلاث استدعاءات أدوات (tool calls).

وكان جهاز Mac مع نموذج 26B MoE الأكثر إشكالية: ترك النموذج شيفرة ميتة، وأعاد كتابة ملف الاختبارات عدة مرات، وارتكب أخطاء مطبعية سخيفة، مثل اسم متغير مكسور أو سطر encoding غير صحيح. واستغرقت المهمة 4 دقائق و42 ثانية، لكنها تطلبت 10 استدعاءات أدوات وخمس محاولات فاشلة لكتابة الاختبارات.

والأكثر إثارة أن Mac تفوّق بشكل غير متوقع على GB10 الأقوى من حيث السرعة «الخام». ففي llama-bench أنتج نموذج 26B MoE على Mac نحو 52 رمزًا في الثانية مقابل 10 رموز لنموذج 31B Dense على GB10، أما في معالجة المطالبة بسياق 8K فكان الجهازان متقاربين تقريبًا: 531 مقابل 548 رمزًا في الثانية. ويكمن التفسير في بنية Mixture of Experts: إذ لا تُفعَّل في كل خطوة سوى جزء من المعاملات، فينخفض حجم البيانات المسحوبة من الذاكرة لكل رمز انخفاضًا حادًا. لكن هذه الميزة لم تفد تقريبًا في المهمة الفعلية، لأن الوقت الأكبر لم تستهلكه الحسابات، بل أخطاء النموذج وتكرار استدعاءات الأدوات والتعديلات الزائدة أثناء العمل.

والخلاصة الرئيسية مزدوجة. فمن جهة، نقلت Gemma 4 البرمجة الوكيلية المحلية فعلًا من فئة «تتعطل في أغلب الأحيان» إلى فئة «يمكن التعايش معها»: ويذكّر صاحب الاختبار بأن مؤشر function calling في tau2-bench بلغ 6,6% لدى Gemma 3، مقابل 86,4% لدى Gemma 4 31B. ومن جهة أخرى، لا يكمن المهم في التطوير العملي في رقم قياسي لعدد الرموز في الثانية، بل في الموثوقية من المحاولة الأولى. ولذلك يبدو الوضع المحلي واقعيًا بالفعل للمهام الخاصة والتكرارات السريعة والعمل دون نفقات مستمرة على API، لكن النماذج السحابية تظل أقوى في السيناريوهات المعقدة.

والاستنتاج الأكثر منطقية من الاختبار هو الوضع الهجين: نموذج محلي لجزء من المهام، والسحابة أداة رئيسية حيث تفوق كلفة الخطأ أهمية السرعة أو الخصوصية.