عندما بدأت لأول مرة في إعداد سير عمل GLM-4.7 مقابل DeepSeek للتشفير، توقعت الأمر المعتاد: شعارات مختلفة قليلاً، تجربة تقريباً نفس الشيء. بدلاً من ذلك، وجدت نفسي مع شخصيتين مختلفتين تمامًا على شاشتي.

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

لقد قضيت أسبوعًا في إلقاء مهام حقيقية عليهما، إصلاح الأخطاء، تعليقات الشفرة متعددة اللغات، مغلفات API، وإعادة بناء السياق الطويل، لمعرفة كيفية مقارنة GLM-4.7 vs DeepSeek في التطبيق العملي، وليس فقط على الورق.

المواجهة بين نماذج التشفير المفتوحة الوزن

نموذجان صينيان مفتوحا الوزن

لنقم بتهيئة المشهد.

في هذه المقارنة بين GLM-4.7 وDeepSeek، اختبرت:

• GLM-4.7 (358B كثيف، مفتوح الوزن، عبر API + تشغيل محلي مُكمم)
• DeepSeek V3.2 (مزيج من الخبراء، مُتفرق، أيضًا مفتوح الوزن عبر الأنظمة الخلفية المجتمعية)

كلاهما يضعان أنفسهما كالتالي:

• قوي في البرمجة والاستدلال
• ينافس أو يتفوق على العديد من النماذج الخاصة في الاختبارات
• مناسب للاستضافة الذاتية والنشر الإقليمي (خاصة في آسيا)

في اختباراتي، ركزت على تدفقات العمل البرمجية التي يستخدمها البناة المستقلون:

• إصلاح أخطاء حقيقية في تطبيق صغير باستخدام Flask + React
• توليد أنواع TypeScript من JSON غير مرتب
• كتابة سكربتات قابلة للنشر بسرعة (Python, JS)
• إعادة الهيكلة بسياق طويل (40-80 ألف رمز من الكود المختلط والمستندات)

لماذا هذا مهم للمطورين العالميين

الشيء المثير للاهتمام حول هذين النموذجين ليس الأداء فقط، بل لمن هما محسنان.

• يبدو أن GLM-4.7 مضبط للثبات والتفكير طويل المدى. فكر في: عمليات إعادة الهيكلة الكبيرة، المستندات الفنية الطويلة، تفسيرات الكود الهيكلية.
• يبدو أن DeepSeek V3.2 مضبط للسرعة والتكلفة. مثالي لوكلاء البرمجة بالذكاء الاصطناعي، توليد الكود بالجملة، أو استخدام API بكميات كبيرة.

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

مقارنة الاختبارات

SWE-bench موثوق

ليس لدي مختبر كامل SWE-bench في غرفة المعيشة (حتى الآن)، لكنني قمت باختبار صغير بنمط التكرار على 20 مشكلة في GitHub:

• 10 مشكلات في الخلفية (Python، Flask، Django-style)
• 10 مشكلات في الواجهة الأمامية (React + TS)

النجاح = تم تطبيق التصحيح، اجتازت الاختبارات، يطابق السلوك الوصف.

في تجربتي الصغيرة المشابهة لـ SWE:

• حلت GLM-4.7 عدد 13 من أصل 20 مشكلة (65%)
• حلت DeepSeek عدد 10 من أصل 20 مشكلة (50%)

ليس درجة علمية SWE-bench-verified ولكن توجهياً:

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

إذا كان سير عمل البرمجة لديك يعتمد بشكل كبير على "قراءة المشكلة الطويلة في GitHub، فهم السياق، والتصحيح بأمان"، فإن GLM-4.7 تفوقت بوضوح في اختباراتي.

أداء التشفير متعدد اللغات

كما اختبرت مطالبات متعددة اللغات:

• المشكلة موضحة بالصينية، الكود بـ Python
• المشكلة موصوفة بالإنجليزية، التعليقات الموجودة باليابانية
• تلميحات تسمية المتغيرات بالإسبانية

نمط النتائج العام:

• أنتجت GLM-4.7 أسماء أنظف وأكثر اتساقاً عندما كانت الوصف وتلميحات المتغيرات بلغات مختلفة.
• DeepSeek أحياناً "تعلق" في لغة الطلب الأولي وتجاهلت جزئياً التعليمات اللاحقة بلغة أخرى.

بالنسبة لمهام التشفير متعددة اللغات، سأقيمها على النحو التالي:

• GLM-4.7: ~9/10 في اتباع التعليمات المختلطة اللغات
• DeepSeek: ~7/10، لا يزال جيدًا، ولكنه أكثر هشاشة قليلاً عند تبديل السياقات بين اللغات في منتصف المطالبة.

قدرات الرياضيات والمنطق

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

• 10 رياضيات بحتة
• 10 رياضيات في الكود (Python)
• 10 منطق + كود (مثل "اشرح، ثم نفذ ديكسترا")

ملخص النتائج:

• GLM-4.7: ~83% صحيح تمامًا (25/30)
• DeepSeek: ~70% صحيح تمامًا (21/30)

الفرق لم يكن فقط في صحة النتائج:

• قدم GLM-4.7 توضيحات أوضح للمنطق الوسيط، وكان الكود يطابق منطقه معظم الوقت.
• كانت DeepSeek لديها أحيانًا منطق صحيح لكن الكود كان خاطئًا قليلاً، خاصة حول الحيود عن الواحد وظروف الحدود.

إذا كنت تقوم بعمل كثيف بالخوارزميات أو مهام بيانات حيث تؤذي الأخطاء الرياضية، فشعرت أن GLM-4.7 كان أكثر أمانًا.

الغوص العميق في الهندسة المعمارية

GLM-4.7: نموذج كثيف 358B

GLM-4.7 هو نموذج كثيف تمامًا بحوالي 358 مليار معلمة. ببساطة: يمر كل رمز عبر الشبكة بأكملها. لا خبراء، لا توجيه.

ما يعنيه هذا عادةً في الممارسة:

• سلوك أكثر قابلية للتنبؤ عبر أنواع المهام
• ثقل أكبر في الحوسبة لكل رمز
• غالبًا ما يكون التفكير السلس في السياقات الطويلة لأن جميع الطبقات ترى كل شيء

في تجاربي، شعرت أن GLM-4.7 "ثقيل ولكنه مدروس." أبطأ قليلاً، لكنه أكثر استقرارًا بشكل ملحوظ عندما يكون المدخل فوضويًا أو مفرط الشرح (والذي، لنكن صادقين، هو كيف تبدو المدخلات الحقيقية).

DeepSeek V3.2: MoE مع انتباه متفرق

يستخدم DeepSeek V3.2 تصميم Mixture-of-Experts (MoE) مع تفعيل متفرق:

• يتم تفعيل مجموعة فرعية فقط من "الخبراء" لكل رمز
• تكلفة حسابية أقل لكل رمز
• قدرة محتملة أكبر بشكل عام لنفس ميزانية الأجهزة

عمليًا، يمنح هذا DeepSeek سرعته وميزته في التكلفة ولكنه أيضًا يقدم بعض الغرائب:

• أحيانًا "يستنفر" إلى نمط أو أسلوب معين
• نادرًا، لكني رأيت سلوكًا غير متسق على مدخلات متشابهة تقريبًا

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

الآثار على الاستنتاج والنشر

يهم الاختلاف الهيكلي بين GLM-4.7 وDeepSeek إذا كنت:

• تدير مجموعة GPU الخاصة بك
• تهتم بالتأخير تحت الحمل
• تحتاج إلى سلوك متوقع عبر فريق

قواعد عامة من اختباراتي:

• للاستخدام عبر API فقط، غالبًا ما يفوز DeepSeek من حيث التكلفة/السرعة، بينما يفوز GLM-4.7 من حيث الاستقرار.
• للاستضافة الذاتية، يعتبر DeepSeek قابل للتنفيذ على عدد أقل من البطاقات المتطورة (MoE)، بينما يفضل GLM-4.7 الطبيعة الكثيفة المزيد من وحدة معالجة الرسومات الخام والذاكرة.

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

السرعة والاستجابة

الوقت للوصول إلى الرمز الأول

قمت بقياس الوقت للوصول إلى الرمز الأول (TTFT) على مدار 50 طلبًا لكل منها، عبر نقاط نهاية مستضافة بجودة مماثلة.

متوسط TTFT على موجه 2K رمز:

• GLM-4.7: حوالي 1.3–1.5 ثانية
• DeepSeek: حوالي 0.7–0.9 ثانية

لذلك، يبدأ DeepSeek في التحدث أسرع بحوالي 40–50%. عندما تكون في حلقة تغذية راجعة ضيقة ("أصلح هذه الوظيفة... لا، ليس هكذا")، ستشعر بسرعته بشكل ملحوظ.

الرموز في الثانية

بالنسبة للإنتاجية، اختبرت أطوال إكمال تتراوح بين 1K–2K.

متوسط الرموز/ثانية:

• GLM-4.7: 25–30 رمز/ثانية
• DeepSeek: 45–55 رمز/ثانية

هذا يعني توليد أسرع بنسبة حوالي 60–80% مع DeepSeek في بيئتي.

إذا كنت تبني مساعد ترميز AI يبث الاقتراحات، فإن سرعة DeepSeek حقيقية وليست تسويقية.

الأداء في سياقات طويلة

لكن السرعة ليست كل القصة.

في سياقات تتجاوز 40K رمز (مستودعات كبيرة، مستندات تصميم طويلة)، لاحظت ما يلي:

• GLM-4.7 بقي متماسكًا لفترة أطول، مع عدد أقل من "هلوسات السياق."
• DeepSeek بقي سريعًا ولكن أحيانًا أساء قراءة الأجزاء الأقدم من السياق أو أعطى وزنًا زائدًا لآخر الشاشات من الكود.

بالنسبة لموجه إعادة هيكلة يتجاوز 80K رمز:

• GLM-4.7: 3 مشكلات طفيفة، لكنه اتبع القيود على مستوى الملف بشكل صحيح
• DeepSeek: 6 مشكلات، بما في ذلك تعديل ملف قلت بوضوح أن يترك دون مساس

إذا كنت تقارن بين GLM-4.7 و DeepSeek في سياق طويل، فإن GLM-4.7 أبطأ لكنه أكثر موثوقية عند التعامل مع قواعد بيانات برمجية ضخمة.

تحليل التكلفة

مقارنة أسعار API

الأرقام الدقيقة ستختلف حسب المزود، لكن النمط الذي لاحظته كان باستمرار:

• نقاط نهاية من نوع DeepSeek-MoE كانت عادة أرخص بنسبة 30-60% لكل مليون رمز مقارنة بنقاط نهاية GLM-4.7 الدنسة.
• في إعداد مستضاف واحد، كانت تكلفة التوليد لـ DeepSeek حوالي $0.60 لكل مليون رمز ناتج، بينما كانت تكلفة GLM-4.7 أقرب إلى $1.10 لكل مليون.

إذا كنت تدير:

• مشروع جانبي بحجم منخفض → كلاهما معقول التكلفة
• SaaS بملايين الرموز يوميًا → ميزة DeepSeek تتضاعف بسرعة كبيرة

متطلبات استضافة GPU الذاتية

الصورة التقريبية للنشر بناءً على تجاربي والمستندات:

• GLM-4.7
  • دقة كاملة: يحتاج إلى عدة وحدات GPU بذاكرة عالية (غير مناسب للأفراد)
  • 4-بت/8-بت مكمي: لا يزال ثقيلًا: تحتاج إلى 2–4 وحدات GPU بذاكرة 80GB لتشغيل سلس عالي التوازي
• DeepSeek V3.2
  • MoE يساعد: عدد أقل من المعايير النشطة لكل رمز
  • نشرات معقولة على 2 × 40–80GB بطاقات للاستخدام المتوسط

إذا كنت ترغب فقط في نشر هواية على جهاز 3090/4090 في المنزل، فمن المحتمل أن يحتاج كلاهما إلى تكميش ثقيل وتنازلات، لكن DeepSeek هو الخيار الأكثر واقعية.

التكلفة الفعالة لكل مليون رمز

بأخذ الأجهزة + الكهرباء + وقت الانتظار في الاعتبار، كانت نسبتي التقريبية للتكلفة الفعالة:

• DeepSeek: تكلفة أساسية = 1.0x
• GLM-4.7: حوالي 1.4–1.8x تكلفة فعالة لكل مليون رمز

لذا من منظور تكلفة بحتة بين GLM-4.7 و DeepSeek:

• تفوز DeepSeek للأحمال الكبيرة لواجهة برمجة التطبيقات، العملاء، وإنشاء المستندات بالجملة.
• يجعل GLM-4.7 أكثر منطقية عندما تكون كل مكالمة "مهمة" أكثر من سعر الرمز الخام، مثل إعادة الهيكلة الحرجة، كود يواجه العميل، وظائف التفكير المعقدة.

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

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

إذا كنت فضوليًا حول كيف يبدو توجيه النموذج في منتج حقيقي، فإن Macaron هو مثال ملموس.

جودة الكود في التطبيق

مخرجات بايثون، جافا سكريبت، وتايب سكريبت

بالنسبة للعمل اليومي للمطورين الفرديين، هذا هو الجزء الذي يهم بالفعل.

عبر ~50 مهمة ترميز:

• بايثون: مال GLM-4.7 إلى إنتاج كود أكثر اصطلاحية (استخدام أفضل لمديري السياق، التسجيل، الكتابة). كانت DeepSeek جيدة، لكنها أكثر "أسلوب تعليمي."
• جافا سكريبت: قريب جدًا. استخدمت DeepSeek أحيانًا أنماطًا أقدم قليلاً (تفكير يشبه var). مال GLM-4.7 إلى الحداثة ولكنه مفصل.
• تايب سكريبت: كان GLM-4.7 أفضل بوضوح في استدلال الأنواع والعناصر العامة. كانت DeepSeek تتجاهل أحيانًا حالات الحافة من عدم القابلية أو الحقول الاختيارية.

إذا كانت حزمة تقنيتك تعتمد بشكل كبير على TS، فأنا أميل إلى GLM-4.7.

أنماط معالجة الأخطاء

هذا هو المكان الذي أبهرتني فيه GLM-4.7 بهدوء.

• GLM-4.7:
  • استخدمت معالجة الأخطاء المنظمة بشكل متكرر (فئات أخطاء مخصصة، حراس محددة)
  • أضافت رسائل سجل معقولة بدون إفراط في السجلات
• DeepSeek:
  • أسرع في تقديم حل مسار سعيد فعال
  • أحيانًا فروع أخطاء غير محددة أو نماذج عامة (catch (e))

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

توليد الوثائق

بالنسبة لسلاسل الوثائق ومقتطفات README والتعليقات المضمنة:

• كتبت GLM-4.7 تفسيرات أكثر وضوحًا للبشر مع بنية أفضل (أقسام، قوائم نقطية، أمثلة).
• أنتجت DeepSeek أوصافًا أقصر وأكثر تكثيفًا، وهو أمر جيد للوثائق الداخلية السريعة ولكن أقل ملاءمة للدروس أو الأدلة الموجهة للمستخدمين.

على معيار توليد الوثائق الذي ارتجلته (10 وظائف، طلبت من كلا النموذجين تقديم سلاسل وثائق كاملة + ملاحظات استخدام):

• GLM-4.7: احتفظت بحوالي 80% من المحتوى مع تحرير خفيف
• DeepSeek: احتفظت بحوالي 60%: كانت هناك حاجة لإعادة الكتابة أكثر للوضوح والنبرة

إذا كنت تنشئ محتوى أو وثائق للمطورين حول الكود الخاص بك، كان ناتج GLM-4.7 يبدو أقرب إلى "يمكن نشره مع تعديلات" مقابل "مسودة يجب علي إعادة كتابتها بشكل كبير."

متى تختار GLM-4.7

الحاجة إلى مخرجات طويلة جدًا (128K)

إذا كان سير العمل الخاص بك يعتمد على سياق طويل، 128K من الرموز للكود والملاحظات والمواصفات والسجلات، فإن GLM-4.7 هو الاختيار الأكثر أمانًا.

في الاختبارات ذات السياق المختلط:

• GLM-4.7 احترم حدود الملفات والقيود وقواعد الأسلوب عبر مطالبات تتراوح بين 60 و90 ألف رمز.
• DeepSeek ظل سريعاً لكنه ارتكب المزيد من الأخطاء في السياق مع نمو حجم المطالبات.

لـ:

• إعادة صياغة المشاريع بالكامل
• مراجعة مستندات التصميم الكبيرة
• توليد الوثائق بكميات كبيرة من الشيفرة

GLM-4.7 تصرف بشكل يشبه المطور البارع الذي يقرأ كل شيء بعناية قبل لمس لوحة المفاتيح.

حساسية أقوى تجاه الواجهة الأمامية وتجربة المستخدم

كان هذا مفاجئًا: في مهام الواجهة الأمامية وتجربة المستخدم، كثيرًا ما كان GLM-4.7 يبدو أكثر "ذوقًا."

أمثلة:

• مكونات React بأسماء خواص معقولة
• تعليقات مضمّنة أفضل تشرح سبب وجود جزء من منطق الواجهة
• أنماط CSS/فئات الأداة أكثر اتساقًا عند إعطاء دليل أسلوب مختصر

DeepSeek يمكنه بالتأكيد بناء نفس المكونات، لكن GLM-4.7 كان غالبًا ينتج شيفرة أرتاح لإسقاطها مباشرة في مستودع واجهة أمامية يشبه الإنتاج.

لذا إذا كانت حالتكم الرئيسية:

• تطبيقات ثقيلة الواجهة
• مكونات واعية لنظام التصميم
• توثيق + أمثلة لواجهتكم الأمامية

GLM-4.7 هو المرجح الأفضل في شجرة القرار بين GLM-4.7 وDeepSeek.

متى تختار DeepSeek

تحسين التكلفة بشكل متطرف

إذا كان مؤشر الأداء الرئيسي (KPI) الخاص بك هو "الرموز لكل دولار"، فإن DeepSeek مصمم لك.

الحالات النموذجية حيث سأختار DeepSeek أولاً:

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

في سجلاتي جنبًا إلى جنب على مدى ~5 ملايين رمز:

• كانت تكلفة DeepSeek أقل بنسبة ~45% مقارنة بـ GLM-4.7 لنفس أعباء العمل.
• كان معدل الخطأ أعلى ولكنه لا يزال مقبولًا للمسارات غير الحرجة.

أسرع سرعة استدلال ممكنة

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

في إعداد "الإكمال التلقائي بينما أكتب" الواقعي:

• شعر DeepSeek بأنه "فوري" تقريبًا بمجرد أن يعمل بشكل جيد.
• كان GLM-4.7 قابلًا للاستخدام ولكنه أبطأ بشكل ملحوظ، خاصة في الطلبات الأولى.

لذا قاعدتي الشخصية للاختيار بين GLM-4.7 و DeepSeek:

• اختر GLM-4.7 عندما: تكون الدقة، والسياق الطويل، وجودة الكود أكثر أهمية من التكلفة.
• اختر DeepSeek عندما: تكون في حالة توسيع كبير، وتريد أقصى إنتاجية، ويمكنك قبول المزيد من الإشراف.

إذا كنت لا تزال غير متأكد، ابدأ بـ DeepSeek للاستكشاف والإنتاج بالجملة، ثم انقل المسارات الحاسمة (إعادة هيكلة الإنتاج، المنطق الموجه للعملاء) إلى GLM-4.7 بمجرد استقرار شكل نظامك.

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