ترويض وحش Gemma 4: كيف بنينا ميزة بحث حية محلياً بالكامل على RTX 5090

مقدمة تحليلية

في عالم تطوير البرمجيات المدعوم بالذكاء الاصطناعي، تظل الفجوة بين 'كتابة الكود' و'بناء الميزات' (The Agentic Gap) هي التحدي الأكبر. قبل يومين فقط، كان نموذج Gemma 4 المفتوح المصدر يعجز عن إتمام مهمة برمجية بسيطة، ولكن اليوم، وبفضل تحسينات جذرية في بيئة التشغيل، تمكن النموذج من بناء ميزة بحث متكاملة، ورفعها على GitHub، وهي تعمل الآن بشكل حي على موقعنا. هذا التحول لم يكن سحراً في أوزان النموذج، بل كان انتصاراً لضبط الإعدادات التقنية الصحيحة وفهم كيفية عمل نماذج الاستدلال (Reasoning Models) محلياً.

التجربة التي قمنا بها في Glitch4Techs تعتمد على معالجة محلية بالكامل باستخدام بطاقة RTX 5090، دون استدعاء أي واجهات برمجة تطبيقات سحابية (Cloud APIs)، وبصفر تكلفة تشغيلية. الميزة التي يراها المستخدمون عند الضغط على ⌘K هي نتاج تعاون هجين؛ حيث قام Gemma 4 بالبناء الهيكلي والتنفيذ البرمجي، بينما قام نموذج Claude Opus بمراجعة الكود وصقله. هذا النموذج يمثل مستقبل تطوير الويب: نموذج محلي سريع للإنتاج، ونموذج سحابي قوي للجودة.

التحليل التقني

اكتشفنا أن السبب الرئيسي لفشل Gemma 4 سابقاً لم يكن ضعف قدراته البرمجية، بل 'ميزانية التفكير غير المرئية'. النماذج الحديثة تستخدم 'سلسلة الأفكار' (Chain-of-Thought) التي تستهلك توكنز (Tokens) قبل توليد المخرج النهائي. في أدوات مثل Ollama، كانت هذه التوكنز تستهلك كامل ميزانية التوليد المتاحة للنموذج، مما يجعله يتوقف قبل كتابة سطر كود واحد.

الانتقال من Ollama إلى llama.cpp

لحل هذه المشكلة، كان لزاماً علينا الانتقال إلى llama.cpp للحصول على تحكم أدق. يوفر llama.cpp خيار --reasoning-budget، وهو المفتاح السحري الذي يسمح بتحديد سقف لتوكنز التفكير (مثلاً 4096 توكن) لضمان بقاء مساحة كافية لتوليد الكود الفعلي. إليكم الإعدادات التقنية التي استخدمناها لتشغيل نسخة Gemma-4-26B-A4B-it:

• سياق الذاكرة (Context Size): تم ضبطه على 32768 ليتناسب مع ذاكرة VRAM البالغة 32 جيجابايت في RTX 5090.
• ميزانية التفكير: 4096 توكن، مما يجبر النموذج على البدء في الإنتاج الفعلي بعد مرحلة التحليل.
• تنسيق الاستدلال: استخدام تنسيق deepseek لإظهار توكنز التفكير في استجابة الـ API، مما يسمح بمراقبة عملية اتخاذ القرار لدى النموذج.
• الأداء اللحظي: حقق النموذج سرعة مذهلة بلغت 181 توكن في الثانية (tok/s) في المهام القصيرة، وحوالي 159 tok/s أثناء بناء ميزة البحث الفعلية مع سياق طويل.

بنية ميزة البحث

اعتمد Gemma 4 بنية بحث من طرف العميل (Client-side Search) باستخدام مكتبة Fuse.js. قام النموذج بكتابة سكربت يقوم بمسح جميع المقالات في مرحلة البناء (Build-time) وتوليد ملف JSON كفهرس للبحث. هذه المقاربة تعتبر مثالية لمدونة تقنية، حيث توفر نتائج فورية دون الحاجة لخادم قاعدة بيانات أو استهلاك موارد السحابة.

السياق وتأثير السوق

هذه التجربة تضع النماذج المحلية في مواجهة مباشرة مع عمالقة السحاب مثل Claude 3.5 وGPT-4. بينما يتفوق Claude في جودة الكود من المحاولة الأولى (Zero-shot)، فإن Gemma 4 أثبت أنه عند توفير البنية التحتية المناسبة (مثل RTX 5090 وllama.cpp)، يمكنه مطابقة الإنتاجية السحابية بتكلفة معدومة وخصوصية مطلقة. السوق يتجه الآن نحو 'الذكاء الاصطناعي الهجين' (Hybrid AI)، حيث يتم التطوير الثقيل محلياً والمراجعة والتدقيق سحابياً.

المقارنة بين استجابة النظام (TTFT) كانت صادمة؛ حيث حقق الاستدلال المحلي 28ms فقط مقارنة بـ 3.92 ثانية في بعض بيئات السحاب أو النسخ غير المحسنة من Ollama. هذا الفرق يعني تجربة تطوير لحظية تجعل المطور يشعر وكأن الذكاء الاصطناعي هو امتداد مباشر لعقله.

رؤية Glitch4Techs

نحن في Glitch4Techs نرى أن 'الذكاء الاصطناعي المحلي' قد تجاوز مرحلة الهواية إلى مرحلة الإنتاج الحقيقي. ومع ذلك، لا نزال نحذر من الاعتماد الكلي على المخرجات الخام للنماذج المحلية دون مراجعة. نموذج Gemma 4، رغم ذكائه، ارتكب أخطاء في معايير الوصول (Accessibility) مثل فقدان أدوار ARIA، وفشل في تنفيذ بعض الرسوم المتحركة المعقدة لـ React. التوصية المهنية هي: استخدم النماذج المحلية للبناء السريع والتكرار (Iteration)، ولكن احتفظ بنموذج قوي مثل Opus كـ 'كبير مهندسين' للمراجعة النهائية قبل النشر (Production). المستقبل هو لمن يمتلك العتاد القوي محلياً والقدرة على توظيف السحاب بذكاء.