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

يستطيع Gemma 4 المحلي بالفعل أن يعمل في Codex CLI كعامل لمهام البرمجة اليومية: قراءة الملفات وكتابة التصحيحات وتشغيل الاختبارات. لكن تجربة باستخدام إعدادين مختلفين أظهرت أن حقيقة التشغيل ليست سوى نصف النجاح. من حيث الموثوقية ودقة الكود وجودة النتائج من المحاولة الأولى، لا يزال GPT-5.

4 القائم على السحابة في المقدمة بشكل ملحوظ. أراد مؤلف الاختبار التحقق لا من "تطوير ذكاء اصطناعي محلي" مجرد، بل من سيناريو معملي واقعي: هل يمكن للنموذج أن يحل محل واجهة البرمجة السحابية في العمل اليومي مع Codex CLI؟ الدافع واضح: تكاليف الرموز ومتطلبات الخصوصية والاعتماد على الخدمات الخارجية. للتحقق، تم تجميع إعدادين.

الأول — MacBook Pro بمعالج M4 Pro وذاكرة 24 جيجابايت، حيث كان يعمل Gemma 4 26B MoE في تكميم Q4_K_M عبر llama.cpp. الثاني — Dell Pro Max GB10 مع ذاكرة موحدة 128 جيجابايت و NVIDIA Blackwell، حيث استخدم Gemma 4 31B Dense عبر Ollama 0.

20.5. في كلا الحالتين، كان النموذج متصلاً بـ Codex CLI كموفر مخصص في وضع responses API.

تبين أن إعداد المكدس المحلي لم يكن سهلاً جداً. على Mac، كانت نسخة Ollama تنقطع عند استدعاء الأدوات بسبب أخطاء البث وتتعطل على الرسائل الطويلة، وهذا حرج للغاية بالنسبة لـ Codex CLI: رسالة نظام واحدة فقط هناك تأخذ حوالي 27 ألف رمز. كان الحل الفعلي في النهاية هو llama.

cpp مع ضبط يدوي للعلامات وتعطيل web_search وسياق 32768 رمز. على 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 وبدون تعرف على القيم المنطقية. ومع ذلك، اجتازت جميع الاختبارات الخمسة أيضاً على الفور، واستغرق التنفيذ حوالي سبع دقائق وثلاث استدعاءات أدوات.

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

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

الخلاصة الرئيسية هنا ذات جانبين. من جهة، نقل Gemma 4 فعلاً الترميز العاملي المحلي من فئة "ينقطع دائماً تقريباً" إلى فئة "يمكنك العيش مع هذا": يذكرنا المؤلف بأنه على tau2-bench، كان أداء استدعاء الدوال لـ Gemma 3 6.6٪، بينما كانت 86.

4٪ لـ Gemma 4 31B. من جهة أخرى، في التطوير العملي، الموثوقية من المحاولة الأولى أكثر أهمية من سجلات الرموز في الثانية. لذلك يبدو الوضع المحلي واقعياً بالفعل للمهام الخاصة والتكرارات السريعة والعمل بدون نفقات API مستمرة، لكن في السيناريوهات المعقدة تبقى النماذج السحابية أقوى حالياً.

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