أفضل نماذج البرمجة مفتوحة الأوزان للوكلاء المستقلين في 2026

تتمثل أفضل نماذج البرمجة مفتوحة الأوزان للوكلاء المستقلين 2026 في نموذج GLM-5.3 للمهام المتقدمة، وQwen3.8-Flash-Next للحلقات الطويلة الفعالة، وNemotron-Cascade-2 لبطاقة معالجة رسومية وحيدة داخل مركز البيانات، وGemma 4 31B لمراجعة الأكواد متعددة الوسائط، وDevstral Small 1.0 لمحطات العمل المكتبية. يتصدر GLM-5.3 الترتيب، لكن حجم معماريتة البالغ 753B معامل يفرض حداً أدنى لوزن المعاملات الخام بدقة 4-bit يبلغ 376.5GB قبل حساب ذاكرة التخزين المؤقت وتكاليف التشغيل.

أفضل نماذج البرمجة مفتوحة الأوزان للوكلاء المستقلين 2026: الخلاصة المباشرة

يعد GLM-5.3 الخيار الأقوى بشكل عام عندما تعني الخصوصية بيئة تشغيل مؤسسية خاضعة للتحكم الكامل مع ميزانية تتيح مجموعة خوادم متعددة معالجات الرسوميات (multi-GPU). بينما يمثل Devstral Small 1.0 الخيار الافتراضي الأنسب عندما تعني الخصوصية محطة عمل واحدة، ومستودع برمجيات واحداً، ومطوراً واحداً. أما النماذج الأخرى بينهما فتوازن بين استهلاك الذاكرة، والتوافق مع بيئات الوكلاء، والمدخلات متعددة الوسائط، ونتائج الاختبارات بطرق تتجاوز مجرد الترتيب في قوائم المقارنة.

الأوزان متاحة مجاناً من زاوية التنزيل المباشر، لكن بيئة التشغيل ليست كذلك. وفقاً لأسعار Runpod المباشرة، فإن بطاقة RTX 4090 تعمل باستمرار لمدة 730 ساعة تكلف $540.20 شهرياً، وبطاقة A100 PCIe تكلف $1,014.70. تشغيل نموذج بحجم 753B ينقل البند المالي من مجرد اشتراك برمجي إلى تكاليف بنية تحتية وعمليات مستمرة.

أفضل نموذج برمجة مفتوح الأوزان: قاعدة اتخاذ القرار

اختر أصغر نموذج يلبي متطلبات مهام مستودعك البرمجي داخل إطار عمل الوكلاء الذي ستعتمد عليه فعلياً. لن تفيدك الدرجات العالية في الاختبارات المعيارية إذا كان النموذج يعجز عن التعامل مع استدعاء الأدوات (tool calls)، أو يتجاوز ميزانية الذاكرة، أو يرسل بيانات التتبع الحساسة خارج حدودك الآمنة.

خمسة مصطلحات أساسية تضمن دقة التقييم:

• مفتوح الأوزان (Open-weight): يعني أن ملفات المعاملات المدربة متاحة للتنزيل، ولا يعني بالضرورة توفير بيانات التدريب، أو كود التدريب كاملاً، أو الترخيص للاستخدام غير المقيد.
• الوكيل الخاص (Private agent): يعني أن نقطة نهاية النموذج، والمستودع، واستدعاءات الأدوات، والسجلات، وبيانات الاعتماد تظل جميعها داخل نطاق تتحكم فيه بالكامل. تنزيل الأوزان ليس سوى جزء بسيط من تأمين هذا النطاق.
• المعاملات النشطة (Active parameters): هي المجموعة الفرعية التي يستخدمها نموذج خليط الخبراء (Mixture-of-Experts) لكل رمز (token). تقليل المعاملات النشطة يخفض الحوسبة، لكن إجمالي المعاملات المخزنة يظل مؤثراً في استهلاك الذاكرة والنشر.
• التكميم (Quantization): تخزين الأوزان بدقة أقل، مثل 4-bit بدلاً من BF16، لتقليل الذاكرة. هذه الحسابات النظرية مفيدة للفرز الأولي، وليست ضماناً لنجاح النشر الفعلي.
• ذاكرة KV المؤقتة (KV cache): مساحة الذاكرة العاملة المخصصة للاحتفاظ بالرموز السابقة أثناء التوليد. في السياقات الطويلة، قد تستهلك هذه الذاكرة حجماً يجعل حسابات التوافق المبنية على الأوزان وحدها غير دقيقة.

القاعدة المتبعة هنا تقدم الكفاءة أولاً ثم قابلية النشر. يتصدر GLM-5.3 التصنيف لأن أوزانه المتاحة حديثاً تجمع بين أداء برمجي متقدم ومسارات تشغيل متعددة. ويفوز Qwen3.8-Flash-Next عندما تكون الحلقات الطويلة وانخفاض الحوسبة النشطة أولوية. ويتفوق Nemotron عند الاقتصار على بطاقة واحدة في مركز البيانات مع إطار OpenHands. ويبرز Gemma عندما يحتاج الوكيل لفحص المخططات أو لقطات الشاشة، بينما يظل Devstral الأنسب للأجهزة المكتبية المتوفرة حالياً.

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

1. GLM-5.3: الخيار الأفضل عموماً للوكلاء المستقلين المتقدمين

يعد GLM-5.3 أفضل نموذج مفتوح الأوزان للمهام البرمجية المعقدة داخل المستودعات، لكنه مخصص للمؤسسات القادرة على إدارته كبنية تحتية متكاملة وليس مجرد برنامج مكتبي. إتاحة أوزانه الرسمية مؤخراً حولت خيار النشر من مجرد وعود مستقبلية إلى واقع عملي.

توضح بطاقة نموذج GLM-5.3 الرسمية احتواءه على 753B معامل، مع دعم الاستضافة عبر أطر عمل مثل SGLang وvLLM وTokenSpeed وTransformers وKTransformers وUnsloth وAscend NPU. توضح Z.ai أن النموذج يحتفظ بالنموذج الأساسي لـ GLM-5.2 وأن تحسيناته نتجت عن مرحلة ما بعد التدريب (post-training). في تقييمات Z.ai الخاصة، ارتفعت نتائج Terminal Bench 3.0 من 4.6 إلى 28.3، وDeepSWE v1.1 من 46.2 إلى 66.9، وAgents' Last Exam من 23.8 إلى 28.5.

هذه المقارنات مفيدة لأنها تقيس تطور جيلين من نفس العائلة، لكنها لا تعني تطابق الأداء عند مقارنتها بنماذج المنافسين في بيئات مختلفة؛ حيث تختلف أطر عمل الوكلاء، وحجم السياق، والمهل الزمنية، ومعاملات أخذ العينات، وصلاحيات الأدوات. الاستنتاج الدقيق هو أن GLM-5.3 يمثل قفزة نوعية مقارنة بـ GLM-5.2، وليس دليلاً قاطعاً على تفوقه في كل المستودعات.

تكمن التكلفة الحقيقية في متطلبات الذاكرة؛ فحجم 753B معامل بدقة BF16 يتطلب وحدها 1,506GB. والنسخة النظرية بدقة 4-bit تتطلب 376.5GB كحد أدنى قبل احتساب ذاكرة KV، والتشغيل المجمّع (batching)، والذاكرة التشغيلية، وبيانات التكميم الوصفية. توفر خمس بطاقات A100 بسعة 80GB مساحة 400GB، وتكلف $5,073.50 لكل 730 ساعة شهرياً بمعدل $1.39 لكل ساعة GPU. يمثل ذلك حداً أدنى للأوزان الخام وليس دليلاً نهائياً لهيكلية النشر الآمنة.

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

يوفر GLM-5.3 خيارات لتحديد جهد التفكير بين low وhigh وmax (وهو الافتراضي)، مما يفيد في توجيه المهام: استخدم جهداً أقل للتعديلات المحدودة، واحتفظ بالجهد الأقصى للمشكلات المعقدة. هذا لا يعني تسريعاً مجانياً؛ فتقليل التفكير لكل دورة قد يؤدي إلى تكرار المحاولات، والمقياس الحقيقي هو حجم العمل المقبول مقابل كل ساعة GPU.

الأنسب لـ: الوكلاء المستقلين ذوي المهام المتقدمة في المؤسسات التي تمتلك بنية تحتية قوية.
أبرز ميزة: أوزان قابلة للتنزيل بحجم 753B مع دعم محلي لعدة مسارات استضافة وتحسن برمجي كبير عن GLM-5.2.
التسعير: $0 للأوزان؛ وتبلغ التكلفة النظرية لحسابات 4-bit على خمس بطاقات A100 نحو $5,073.50 شهرياً (730 ساعة) قبل التخزين والشبكات والتشغيل.
التجربة المجانية: لا ينطبق؛ الأوزان الرسمية قابلة للتنزيل المباشر.

خطة تجريبية عملية لنموذج GLM-5.3

1. 1

   تثبيت مواصفات النموذج والترخيص

   سجل الإصدار الدقيق للنموذج، ونص ترخيص glm-5.3، ونوع التكميم، ومحرك الاستضافة، وأداة الترميز (tokenizer)، وقالب المحادثة؛ فاسم عائلة النموذج وحده لا يضمن إعادة إنتاج بيئة النشر بدقة.

2. 2

   تحديد حجم الذاكرة قبل حجز الموارد

   ابدأ بالحد الأدنى النظري بدقة 4-bit البالغ 376.5GB، ثم أضف الحجم الفعلي لذاكرة KV والتشغيل والمحاولات المتزامنة والجاهزية للطوارئ. لا تعتمد على حسابات البطاقات الخمس كبنية نهائية دون قياس.

3. 3

   عزل نقطة النهاية داخل حدود الأمان

   اضبط المستودعات البرمجية في وضع القراءة فقط في البداية. وفر للوكيل خادماً محلياً معتمداً للحزم، ومساحة عمل مؤقتة، وبيانات اعتماد قصيرة الأجل، وقيوداً على الاتصال الخارجي، مع تسجيل شامل لجميع استدعاءات الأدوات.

4. 4

   احتساب تكلفة التعديلات البرمجية المقبولة

   نفذ عشرين مهمة مستودع برمجية متطابقة على كل من النموذج المقترح والحل السحابي الحالي. قسّم تكلفة استهلاك GPU على عدد التعديلات البرمجية المقبولة بشرياً، مع إضافة وقت المطور وتكاليف تنظيف المحاولات الفاشلة.

2. Qwen3.8-Flash-Next: الأفضل لحلقات الوكلاء الطويلة والسريعة

يحقق Qwen3.8-Flash-Next أفضل توازن في هذا الترتيب بين القدرات المتقدمة وانخفاض متطلبات الحوسبة النشطة. ورغم كونه نموذجاً ضخماً، فإن تفعيله لـ 6B معامل لغوي نشط يجعله خياراً عملياً لوكلاء المستودعات ذوي الإنتاجية العالية مقارنة بإجمالي حجمه البالغ 180B.

تفصل بطاقة نموذج Qwen3.8-Flash-Next الرسمية بين متطلبات التخزين والحوسبة النشطة: 125B معامل لغوي مع تنشيط 6B فقط، بالإضافة إلى 51B معامل لترميز n-gram و4B معاملات لـ MTP. يوضح موقع Hugging Face أن إجمالي حجم الملفات يبلغ 180B. هذا الفارق جوهري؛ إذ تحدد المعاملات النشطة كفاءة المعالجة لكل رمز، بينما تتطلب المعاملات الإجمالية مساحة تخزين فعلية في الذاكرة.

يدعم النموذج سياقاً أصلياً يبلغ 262,144 رمزاً مع إمكانية التوسيع حتى 1,000,000 رمز. ينبغي الاعتماد على الرقم الأصلي في خطط الإنتاج الأولية؛ فتوسيع السياق يغير تدريج المواقع ويزيد الضغط على ذاكرة KV، مما يجعل خيار المليون رمز خاضعاً للاختبار العملي وليس مجرد ميزة دعائية.

سجل النموذج 58.7 في DeepSWE 1.1، و62.5 في SWE-bench Pro، و81.0 في SWE-bench Multilingual، و73.5 في Toolathlon Verified. تحدد بطاقة النموذج إعدادات التقييم وظروف السياق بوضوح، مما يمنح هذه الأرقام مصداقية عملية. وتعد هذه الخصائص مثالية لفرق هندسة المنصات التي تدير مستودعات برمجية متعددة اللغات مع مدخلات مرئية وسلاسل أدوات ممتدة.

تظل متطلبات الذاكرة كبيرة؛ إذ يتطلب حجم 180B معامل نحو 360GB بدقة BF16 و90GB كحد أدنى نظري بدقة 4-bit. تكلف بطاقتان من نوع A100 PCIe بسعة 80GB نحو $2,029.40 شهرياً (730 ساعة) وفقاً لأسعار Runpod الحالية، وهو ما يغطي الأوزان الخام بدقة 4-bit، دون أن يضمن استقرار الإنتاج بعد احتساب الذاكرة المؤقتة والتشغيل المتزامن.

التحدي الأبرز هو مستوى الجاهزية؛ حيث تصف Qwen هذا الإصدار بأنه معاينة تجريبية للبنية التحتية لنموذج Qwen4، في حين يوفر المنتج السحابي المدار Qwen3.8-Flash ميزات مجهزة للإنتاج كدعم مليون رمز افتراضياً وأدوات مدمجة. هناك فارق تشغيلي بين المعاينة القابلة للتنزيل والخدمة السحابية، والنشر الخاص يفرض عليك بناء هذه الطبقة المفقودة.

الأنسب لـ: وكلاء البرمجة ذوي أعباء العمل الكثيفة التي تتطلب سياقاً طويلاً، وقدرات بصرية، ودعماً لتعدد اللغات، وحوسبة نشطة فعالة.
أبرز ميزة: إجمالي 180B معامل مع تنشيط 6B فقط، ونتائج موثقة في هندسة البرمجيات والوكلاء المستقلين.
التسعير: $0 للأوزان؛ وتبلغ التكلفة التقديرية لبطاقتي A100 PCIe نحو $2,029.40 شهرياً (730 ساعة) قبل التكاليف التشغيلية.
التجربة المجانية: لا ينطبق؛ الأوزان الرسمية قابلة للتنزيل.

للمقارنة بين الإصدارات الأخف حجماً، يقدم مقال مقارنة Qwen3.8 Flash مقابل GLM-5.3 Flash لوكلاء البرمجة تحليلاً مخصصاً لنماذج التجارب الأولية بدلاً من هذه الفئات الإنتاجية الكاملة.

3. Nemotron-Cascade-2-30B-A3B: الخيار الأفضل لمعالج رسومي واحد في مراكز البيانات

يعد Nemotron-Cascade-2-30B-A3B الخيار الأمثل عندما تقتصر البنية التحتية على بطاقة معالجة رسومية وحيدة بمركز البيانات ويعتمد إطار عمل الوكيل على OpenHands. فحجمه المخزن البالغ 32B يسهل إدارته، وتصميمه القائم على تفعيل 3B معاملات نشطة يوفر كفاءة عالية، مع توثيق رسمي من NVIDIA لتشغيله عبر vLLM على شريحة واحدة.

توضح بطاقة النموذج الرسمية من NVIDIA تحقيقه لدرجة 50.2 في SWE Verified باستخدام OpenHands، و21.1 في Terminal Bench 2.0، و87.2 في LiveCodeBench v6. يدعم النموذج نمطي التفكير المتقدم (thinking) والتعليمات المباشرة (instruct)، وسياقاً يصل إلى 1M رمز، مع توفير نقطة نهاية متوافقة مع معايير OpenAI عبر vLLM.

تعد متطلبات تشغيله أكثر وضوحاً مقارنة بالنماذج الكبيرة؛ إذ يتطلب حجم 32B معامل نحو 64GB بدقة BF16 و16GB كحد أدنى نظري بدقة 4-bit. تكلف بطاقة A100 بسعة 80GB نحو $1,014.70 شهرياً (730 ساعة) عبر منصة Runpod. ويمكن لبطاقة بسعة 24GB استيعاب النموذج بدقة 4-bit، إلا أن السياقات الطويلة والعمليات المتزامنة قد تستهلك الذاكرة المتبقية بسرعة.

لا يكمن التحدي الأكبر في نتائج الاختبارات، بل في توافق المنصات؛ إذ تشير NVIDIA إلى أن النموذج لا يدعم حالياً OpenCode ويركز أساساً على OpenHands لمهام البرمجة والمهام الهندسية. ويتطلب إعداده عبر vLLM إصدار 0.17.1 أو أحدث، ومحلل تفكير مخصصاً، ومحلل استدعاء أدوات خاصاً بـ Qwen3 Coder، مع تفعيل خيار trust_remote_code، وهو ما يفرض مراجعة برمجية وأمنية دقيقة لسلسلة التوريد التقنية.

يناسب النموذج مسؤولي الأنظمة عندما تكون منصة OpenHands معتمدة بالفعل، ومقيدين ببطاقة GPU واحدة، وتكون موثوقية التحكم أهم من دعم أطر عمل متعددة. لا تختر هذا النموذج لمجرد دعمه سياق مليون رمز؛ فالقدرة على الاسترجاع، والتلخيص، وإدارة الذاكرة المؤقتة، ودقة استكشاف الملفات المناسبة هي ما يحدد كفاءة استخدام هذا السياق في الواقع.

الأنسب لـ: وكلاء هندسة البرمجيات المعتمدين على OpenHands على معالج رسومي واحد بمركز البيانات.
أبرز ميزة: إجمالي 32B معامل مع 3B معاملات نشطة، ومسار تشغيل موثق على بطاقة واحدة عبر vLLM.
التسعير: $0 للأوزان؛ وتكلفة تشغيل بطاقة A100 PCIe تبلغ تقديرياً $1,014.70 شهرياً (730 ساعة).
التجربة المجانية: لا ينطبق؛ الأوزان الرسمية قابلة للتنزيل المباشر.

4. Gemma 4 31B IT: الأفضل لمراجعة الأكواد البرمجية متعددة الوسائط

يمثل Gemma 4 31B IT الخيار الأفضل إذا كان الوكيل مطالباً بقراءة الأكواد وفحص لقطات الشاشة، والمخططات، وملفات PDF، وحالات واجهات المستخدم في الوقت ذاته. فهو نموذج وكلاء عام متعدد الوسائط يتمتع بقدرات برمجية قوية، وليس مجرد نموذج تخصصي يقتصر على كتابة الشفرات.

توضح بطاقة النموذج الرسمية من Google أنه نموذج مصمت (dense) بحجم 30.7B معامل، يدعم سياقاً يبلغ 256K رمزاً، ومدخلات النصوص والصور، واستدعاء الدوال المدمج، بالإضافة إلى توليد الشفرات وإكمالها وتصحيحها. سجلت Google نسبة 80.0% في اختبار LiveCodeBench v6، وتصنيف ELO يبلغ 2,150 على Codeforces، ونسبة 76.9% في Tau2.

يلبي هذا المزيج متطلبات مهام واضحة: وكيل خاص لهندسة المنتجات يقرأ اختباراً برمجياً فاشلاً، ويقارنه بلقطة شاشة للواجهة، ويتحقق من التصميم الهندسي، ثم يقترح التصحيح المناسب. ورغم قدرة Qwen على معالجة الصور، فإن حجم Gemma (31B) وإصداراته الرسمية المدربة بتقنيات التكميم تجعل تشغيله أسهل على محطات العمل أو الخوادم الفردية.

توفر بطاقة Gemma 4 QAT الرسمية تنسيقات جاهزة مثل Q4_0 GGUF وتنسيق compressed-tensors w4a16. وتوضح Google أن التدريب المراعي للتكميم (Quantization-Aware Training) يحافظ على جودة مماثلة لدقة BF16 مع خفض كبير في استهلاك الذاكرة عند التشغيل. ينتج عن حجم 30.7B معامل حد أدنى نظري للأوزان يبلغ 15.35GB بدقة 4-bit، مع ضرورة تخصيص مساحة لمشفر الرؤية، والذاكرة المؤقتة، ونظام التشغيل، والسياق الفعلي.

تتمثل نقطة الضعف في عدم تخصصه الكامل كوكيل برمجي بحت؛ فاختبار LiveCodeBench يقيس حل المشكلات البرمجية وليس الاستقلالية في إدارة مستودعات متعددة الملفات. ورغم فائدة استدعاء الدوال، إلا أن بطاقة النموذج لا تقدم إثباتات ملموسة في هندسة البرمجيات مع أطر مثل OpenHands كتلك المتوفرة في Devstral أو Nemotron. اختر هذا النموذج لمتطلبات المهام متعددة الوسائط، وليس لمجرد كونه بحجم 31B.

الأنسب لـ: الوكلاء المستقلين الذين يدمجون مهام المستودعات البرمجية مع تحليل لقطات الشاشة أو المخططات أو المستندات.
أبرز ميزة: مدخلات متعددة الوسائط، دعم استدعاء الدوال الأصلي، سياق 256K، ترخيص Apache 2.0، وتنسيقات QAT رسمية.
التسعير: $0 للأوزان؛ وتعتمد تكلفة البنية التحتية على مستوى الدقة، وحجم السياق، ومعدل العمليات المتزامنة.
التجربة المجانية: لا ينطبق؛ الأوزان الرسمية وملفات QAT متاحة للتنزيل المباشر.

5. Devstral Small 1.0: أفضل نموذج محلي للبرمجة

يمثل Devstral Small 1.0 الخيار الأقوى لمحطات العمل المكتبية عندما يعني التشغيل المحلي الاعتماد على بطاقة RTX 4090 واحدة أو جهاز Mac بذاكرة 32GB RAM. يتخلى النموذج عن معالجة الصور والسياقات المليونية الضخمة مقابل توفير نموذج عملي يمكن للمطور الفردي تشغيله والتحكم فيه بالكامل.

توضح بطاقة Devstral Small 1.0 الرسمية اعتماده على 24B معامل، وسياق يبلغ 128K رمز، وترخيص Apache 2.0، مع معمارية تقتصر على معالجة النصوص. تؤكد Mistral إمكانية تشغيله على بطاقة RTX 4090 وحيدة أو جهاز Mac بذاكرة 32GB RAM، مسجلاً نسبة 46.8% في اختبار SWE-bench Verified عبر إطار عمل OpenHands.

هذه المواصفات تجعل من Devstral نقطة الانطلاق الأسهل والأكثر وضوحاً للتجارب الأولى للوكلاء المستقلين؛ حيث يستطيع المطور نشره على جهازه المكتبي الحالي، وربط مستودع تجريبي داخل بيئة معزولة (sandbox)، واستكشاف القيمة المضافة لامتلاك النموذج محلياً قبل الاستثمار في استئجار خوادم مراكز البيانات. تشمل بيئات تشغيله المدعومة vLLM وmistral-inference وTransformers وLM Studio وllama.cpp وOllama، بالإضافة إلى دليل رسمي للتكامل مع OpenHands.

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

تكمن حدوده الواضحة في اقتصاره على النصوص؛ فهو عاجز عن فحص لقطة شاشة لواجهة معطلة أو مقارنة مكون برمجي بتصميم مرئي. كما أن نسخته الصادرة في 2025 تظل أقدم مقارنة بنماذج 2026 الرائدة؛ فالاستقرار والتوافق البرمجي لا يلغيان الفجوة في القدرات المتقدمة.

الأنسب لـ: المطورين التقنيين المستقلين والفرق التي تبدأ أولى تجاربها لبناء وكيل مستودعات على أجهزتها الحالية.
أبرز ميزة: إمكانية التشغيل على بطاقة RTX 4090 واحدة أو جهاز Mac بسعة 32GB، مع أداء مثبت على OpenHands وترخيص Apache 2.0 وبيئة تشغيل محلية ناضجة.
التسعير: $0 للأوزان؛ لا توجد تكاليف استئجار لمحطة العمل المملوكة، بينما تكلف بطاقة RTX 4090 على Runpod عند تشغيلها المستمر لمدة 730 ساعة نحو $540.20 شهرياً.
التجربة المجانية: لا ينطبق؛ الأوزان الرسمية متاحة للتنزيل المباشر.

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

نماذج الذكاء الاصطناعي للبرمجة المحلية: موازنة العتاد والتكاليف

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

توضح صفحة أسعار Runpod المباشرة أن تكلفة بطاقة RTX A5000 بسعة 24GB تبلغ $0.27 للساعة، وبطاقة RTX 4090 بسعة 24GB تبلغ $0.74، وبطاقة A40 بسعة 48GB تبلغ $0.44، وبطاقة RTX A6000 بسعة 48GB تبلغ $0.53، وبطاقة A100 PCIe بسعة 80GB تبلغ $1.39، وبطاقة H100 PCIe بسعة 80GB تبلغ $2.89، وبطاقة B200 بسعة 180GB تبلغ $6.79. علماً بأن توفر الأجهزة والموقع الجغرافي وخيارات التخزين والشبكات والسحابة الآمنة تؤثر جميعها في الفاتورة النهائية.

وفي المقابل، تعرض صفحة خطط البرمجة في Z.ai أسعار الاشتراكات السحابية المدارة؛ حيث تبلغ الرسوم الشهرية $18 لخطة Lite، و$80 لخطة Pro، و$168 لخطة Max. وعند السداد السنوي تصبح القيم الشهرية المعادلة $12.60 و$56 و$117.60. وتبلغ خطط الفرق $88 لكل مقعد لخطة Daily Medium Repo Development، و$188 لكل مقعد لخطة Daily Medium & Large Repo Development، بما يعادل $79.20 و$169.20 عند الدفع السنوي.

هذه المقارنة لا تعني تطابق الخدمات من حيث طبيعة التشغيل؛ فالاشتراك السحابي يوفر نموذجاً مداراً مع حصة محددة، بينما تمنحك استئجار بطاقة GPU مجرد وقت حوسبة خام على جهاز، تاركاً إعداد النموذج، والاستضافة، والمراقبة، والتخزين، واستقرار النظام على عاتقك. ومع ذلك، توضح المقارنة الفروق المالية الجوهرية:

• تشغيل بطاقة RTX 4090 واحدة بتكلفة $540.20 شهرياً (730 ساعة) يتجاوز تكلفة ثلاثة مقاعد من خطة Max بسعر $168، وذلك قبل احتساب تكاليف التشغيل والإدارة.
• تشغيل بطاقة A100 PCIe واحدة بتكلفة $1,014.70 شهرياً (730 ساعة) يفوق تكلفة خمسة مقاعد لفرق العمل بسعر $188، دون احتساب الجهد البشري.
• تشغيل خمس بطاقات A100 بتكلفة $5,073.50 شهرياً يغطي بالكاد الحد الأدنى النظري لأوزان GLM-5.3 بدقة 4-bit، دون توفير مساحة إضافية تضمن استقرار الوكيل تحت ضغط العمل.

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

أما إن كانت ضرورية، فابدأ برفع كفاءة الاستخدام قبل التفكير في تكبير حجم النموذج: أوقف تشغيل الحاويات التطويرية عند الخمول، ووجه التعديلات الروتينية إلى Devstral أو Nemotron، مع حصر استخدام GLM-5.3 في المهام المعقدة التي تبرر تكلفته. وافصل بين مهام الاستجابة الفورية والمهام المجمعة (batch). واحرص على معاملة سجلات المطالبات البرمجية وتتبع الوكلاء بنفس سياسات الأمان والاحتفاظ المطبقة على الشفرة المصدرية ذاتها؛ فالاستدلال المحلي يفقد معناه بالكامل إذا كانت سجلات التتبع مكشوفة.

منهجية اختيار وترتيب النماذج

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

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

يعتمد الترتيب على جدوى الاستخدام الإنتاجي العملي بدرجة تفوق التوسع في الاختبارات القياسية:

1. الكفاءة البرمجية: الأداء المثبت في التعامل مع المستودعات، والطرفية، والأدوات، والمهام التطويرية.
2. قابلية النشر: الحجم المخزن الإجمالي، والحجم النشط، وخيارات التكميم، وأطر عمل الاستضافة المدعومة.
3. ملاءمة بيئة الوكيل: صياغة استدعاء الأدوات والتوافق الموثق مع منصات الوكلاء.
4. مستوى التحكم: قابلية تنزيل الأوزان، وإمكانية تثبيت الإصدارات، ووضوح شروط الترخيص.
5. العمليات التشغيلية: متطلبات البنية التحتية والجهد البشري اللازم لضمان أمان نقطة النهاية واستقرارها.

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

أفضل النماذج مفتوحة المصدر للبرمجة تكون عادة مفتوحة الأوزان

توصف النماذج البرمجية الرائدة القابلة للتنزيل بدقة أكبر بأنها نماذج "مفتوحة الأوزان" (open-weight) وليست مفتوحة المصدر بالمعنى التقليدي. هذا الفارق جوهري؛ فالأوزان تجيب عن سؤال "هل يمكننا تشغيل النموذج؟"، بينما يحدد الترخيص وظروف الإصدار "ما الذي يسمح لنا بتعديله، وإعادة توزيعه، واستخدامه تجارياً".

يعتمد كل من Gemma 4 31B IT وDevstral Small 1.0 على شروط ترخيص Apache 2.0 المعروفة، بينما تستخدم نماذج GLM-5.3 وQwen3.8-Flash-Next وNemotron-Cascade-2 وKimi K3 تراخيص مخصصة ومسماة لكل نموذج. وجود خيار التنزيل لا يغنيك بأي حال عن التدقيق في تلك الشروط القانونية.

كما تتطلب الخصوصية نظرة هيكلية شاملة؛ فقد يعمل النموذج داخل خادمك الخاص بينما تتسرب البيانات عبر تنزيل الحزم الخارجية، أو بيانات القياس عن بُعد (telemetry)، أو تقارير الأعطال، أو سجلات المطالبات، أو أدوات الوكيل نفسه. ارسم مسار تدفق البيانات بالكامل بدءاً من ربط المستودع البرمجي وحتى تتبع المخرجات النهائية. حدد كل نقطة اتصال شبكية، وبيانات الاعتماد، ومواقع التخزين، والمراجعات البشرية؛ فالخصوصية هي خاصية للنظام المتكامل وليست مجرد وسم ملصق على النموذج.

نماذج يُنصح بتجنبها في حالات محددة

تجنب Kimi K3 لبيئات النشر الخاصة المعتادة

يعد Kimi K3 نموذجاً متقدماً متعدد الوسائط يتمتع بإثباتات قوية في البرمجة، لكنه لا يناسب الأغلبية كوكيل محلي مستقل؛ إذ تفرض معاملاته البالغة 2.8T حداً أدنى نظرياً لذاكرة الأوزان الخام بدقة 4-bit يصل إلى 1.4TB. هذه الأعباء الضخمة تفوق الفائدة المرجوة لمحطات العمل، أو الخوادم الفردية، أو فرق المنصات المحدودة.

توضح بطاقة Kimi K3 الرسمية من Moonshot تفعيله لـ 104B معامل نشط، ودعمه لسياق 1,048,576 رمزاً، مع إتاحة الأوزان كاملة تحت ترخيص Kimi K3 License، محققاً 67.5 في DeepSWE و88.3 في Terminal Bench 2.1 وفقاً لبيانات الشركة. هذه الأرقام تجعله خياراً يستحق الدراسة للمؤسسات الكبرى المتخصصة في إدارة النماذج الضخمة، لكنها لا تجعل من نموذج بحجم 2.8T خياراً مناسباً للاستخدام المحلي المعتاد.

تجنب نماذج Gemma 4 E2B وE4B للتعديلات المستقلة على المستودعات

تعتبر إصدارات Gemma 4 E2B وE4B نماذج طرفية متميزة في فئتها، لكن تقييمات Google الخاصة على LiveCodeBench v6 تظهر تحقيقها لنسب 44.0% و52.0% على التوالي، مقارنة بـ 80.0% لنموذج Gemma 4 31B. اقتصر في استخدام هذه الإصدارات الصغيرة على المساعدة المحدودة، أو الاستخراج، أو المعالجة المباشرة داخل الأجهزة الطرفية، وتجنب منحها صلاحيات تعديل واسعة على المستودعات البرمجية وتوقع أداء مقارب لنموذج 31B.

تجنب GLM-5.2 لمشاريع النشر الجديدة

يظل استخدام GLM-5.2 منطقياً فقط إذا كانت لديك عمليات تكميم سابقة، أو تكاملات قائمة، أو مسارات عمل معتمدة مبنية عليه تحديداً. أما في مشاريع النشر الجديدة، فالأفضل البدء مباشرة بنموذج GLM-5.3؛ حيث تؤكد Z.ai اعتماده على نفس النموذج الأساسي مع تحقيق قفزة بنسبة 50% في الأداء البرمجي الداخلي عبر تحسينات ما بعد التدريب، إلى جانب مكاسب واضحة في تقييمات أداء الوكلاء. التوافق مع الأنظمة القديمة هو المبرر الوحيد لتحمل أعباء تشغيل الإصدار السابق.

تجنب اختيار أي نموذج بالاعتماد على طول السياق فقط

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

خطة عمل الاثنين: أطلق اختبارك التجريبي لعلاوة التحكم عبر 20 مهمة

ابدأ صباح الاثنين المقبل بتشغيل Devstral Small 1.0 على جهاز Mac بذاكرة 32GB أو بطاقة RTX 4090 متوفرة، ما لم تكن هناك متطلبات أمنية أو مهام تثبت حاجتك المسبقة لنموذج أضخم. الهدف ليس البحث عن بطل الاختبارات المعيارية، بل قياس ما إذا كان امتلاك النموذج يرفع نسبة التعديلات البرمجية المقبولة بدرجة تبرر تكلفة علاوة التحكم.

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

سجل في كل تشغيل:

• قبول التعديل البرمجي أو رفضه بعد المراجعة البشرية.
• الدقائق المستغرقة في التصحيح البشري اليدوي.
• وقت استخدام GPU والحد الأقصى لاستهلاك الذاكرة.
• استدعاءات الأدوات الفاشلة والمكررة.
• الملفات التي تمت قراءتها وتعديلها وتنفيذها.
• محاولات الاتصال بالشبكة الخارجية وعمليات رفض الصلاحيات.
• نتيجة الاختبارات النهائية وحالة التراجع عن التغييرات (rollback).

طبق نفس المهام على اشتراكك السحابي الحالي المدار. واحسب التكلفة بناءً على "التعديل البرمجي المقبول" وليس التكلفة لكل رمز (token)؛ فالجلسة الرخيصة التي تتطلب ثلاثين دقيقة من التدخل البشري لمعالجة أخطائها باهظة الثمن. بينما النموذج الأكبر الذي ينجز مهمة ترحيل برمجية كاملة دون تصعيد بشري قد يكون هو الخيار الأوفر حتى مع ارتفاع تكلفة ساعة GPU.

تعتمد قاعدة المتابعة على معايير صارمة: انعدام أي انتهاك لحدود الصلاحيات المعطاة، وتحقيق تكلفة أقل أو مقبولة استراتيجياً لكل تعديل مقبول، وتعيين مسؤول مباشر عن منصة الاستضافة. إذا اجتاز Devstral هذه الشروط، فاكتفِ به. وإن تعثر في القدرات البرمجية دون أن يفشل في التكامل والدمج، فانتقل بنفس المهام إلى Nemotron، ثم Gemma، ثم Qwen، وأخيراً GLM-5.3؛ فتصعيد حجم النموذج قبل استنفاد تقييم النماذج الأصغر يؤدي فقط إلى شراء مجهول باهظ التكلفة.

الأسئلة الشائعة

ما هو أفضل نموذج لغوي مفتوح المصدر للبرمجة في 2026؟

يعد GLM-5.3 أقوى خيار مفتوح الأوزان عموماً للوكلاء المستقلين ذوي المهام المتقدمة، بينما يمثل Devstral Small 1.0 الخيار العملي لمحطات العمل المكتبية. يجب التحقق من شروط "المصدر المفتوح" بالرجوع إلى التراخيص والملفات الرسمية المرفقة، وعدم افتراضها لمجرد توفر الأوزان للتنزيل.

أي النماذج هو الأفضل للبرمجة في 2026؟

يتصدر GLM-5.3 هذا التصنيف للنماذج مفتوحة الأوزان من حيث القدرات القصوى. بينما يتفوق Qwen3.8-Flash-Next في الحلقات الطويلة والفعالة، وNemotron لتشغيل شريحة وحيدة بمركز البيانات، وGemma للمراجعات متعددة الوسائط، وDevstral للأجهزة المكتبية.

ما هو أفضل نموذج برمجة مفتوح الأوزان؟

يعد GLM-5.3 الأفضل إجمالاً عندما تتوفر البنية التحتية القادرة على تشغيله. بينما يوفر Qwen3.8-Flash-Next بديلاً متقدماً أسهل في النشر، ويبقى Devstral Small 1.0 الخيار الافتراضي للتطوير المحلي.

ما هو أفضل وكيل برمجة في 2026؟

النموذج وحده لا يمثل وكيلاً برمجياً متكاملاً؛ إذ يحدد إطار العمل المساعد، وبيئة تشغيل الأوامر المعزولة، وأدوات التعامل مع المستودع البرمجي، وحدود الصلاحيات، والاختبارات، وآليات الاختصار، ودورات المراجعة ما إذا كان النظام ككل صالحاً للاستخدام في الإنتاج.

هل يُعد Claude Code أفضل وكيل برمجة؟

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

هل لا تزال البرمجة مجدية وذات صلة في 2026؟

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

ماذا قال إيلون ماسك عن مستقبل البرمجة؟

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

ما هي أفضل لغة برمجة في 2026؟

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

كيف تكتب عبارة “أحبك” برمجياً؟

عبر كتابة نص صريح (string literal) بالصيغة القياسية المعتمدة في لغة البرمجة التي تستخدمها. ولا يرتبط هذا السؤال بعملية اختيار وتقييم نماذج وكلاء البرمجة المستقلين.

ما هو أفضل نموذج لغوي محلي للبرمجة في 2026؟

يعد Devstral Small 1.0 أفضل نموذج لمحطات العمل المكتبية المحلية في هذا التصنيف؛ لتوثيق Mistral الرسمي إمكانية تشغيله على بطاقة RTX 4090 واحدة أو جهاز Mac بسعة 32GB، مع دعمه لمنصة OpenHands واعتماده ترخيص Apache 2.0.

ما هو أفضل نموذج ذكاء اصطناعي للبرمجة في 2026؟

يقود GLM-5.3 هذه القائمة المفتوحة الأوزان للمهام المتقدمة. ومع ذلك، قد تكون النماذج البديلة مثل Devstral أو Nemotron أو Gemma أو Qwen هي الخيار التجاري الأنسب لمؤسستك بناءً على إمكانيات العتاد، أو متطلبات الرؤية، أو سرعة المعالجة، أو بيئة تشغيل الوكلاء المعتمدة.

احصل على قائمة تدقيق سير عمل الذكاء الاصطناعي للشركات

حول أفكار نشر الوكلاء المستقلين إلى بيئة عمل محددة الأهداف تتمتع بمسؤولية تشغيل واضحة، وميزانية محددة، وحدود أمان صارمة، وشروط إيقاف دقيقة. اشترك الآن للحصول على قائمة التدقيق مجاناً.