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

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

قضيت أسبوعاً في اختبار مهام حقيقية عليهما، تصحيح الأخطاء، تعليقات الكود متعددة اللغات، مغلفات API، وإعادة هيكلة طويلة السياق، لمعرفة كيف GLM-4.7 مقابل 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 منطق + كود (مثل "اشرح، ثم قم بتنفيذ Dijkstra")

لمحة عن النتائج:

• 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 يستخدم تصميم مزيج من الخبراء (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 حقيقية وليست تسويقًا.

أداء السياق الطويل

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

في سياقات تحتوي على أكثر من 40 ألف رمز (مستودعات كبيرة، وثائق تصميم طويلة)، رأيت ما يلي:

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

بالنسبة لمطالبة إعادة الهيكلة ذات 80 ألف رمز:

• 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
  • الدقة الكاملة: وحدات معالجة رسومات عالية الذاكرة متعددة (غير مناسبة للأفراد)
  • كمّية 4-بت/8-بت: لا تزال ثقيلة: فكر في 2–4 × 80GB وحدات معالجة رسومات لأداء سلس وعالٍ في التوازي
• DeepSeek V3.2
  • MoE يساعد: عدد أقل من المعلمات النشطة لكل رمز
  • نشرات معقولة على بطاقتين × 40–80GB للاستخدام متوسط الحجم

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

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

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

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

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

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

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

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

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

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

مخرجات Python وJavaScript وTypeScript

للعمل اليومي كمطور مستقل، هذه هي الجزء الذي يهم بالفعل.

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

• Python: كان GLM-4.7 يميل إلى إنتاج تعليمات برمجية أكثر نموذجية (استخدام أفضل لإدارة السياق، وتسجيل الأحداث، والكتابة). كان DeepSeek جيدًا، لكنه أكثر "نمطية دروسية."
• JavaScript: قريب جدًا. استخدم DeepSeek أحيانًا أنماطًا أقدم قليلاً (تفكير يشبه var). كان GLM-4.7 يميل إلى الحداثة ولكنه كان مطولًا.
• TypeScript: كان 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–90K رمز.
• ظل DeepSeek سريعًا لكنه ارتكب المزيد من الأخطاء السياقية مع زيادة المطالبات.

لـ:

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

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

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

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

أمثلة:

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

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

لذلك، إذا كان الاستخدام الرئيسي لديك هو:

• تطبيقات ثقيلة من حيث واجهة المستخدم
• مكونات مدركة لنظام التصميم
• توثيق + أمثلة لواجهتك الأمامية

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

متى تختار DeepSeek

تحسين التكلفة القصوى

إذا كان مؤشر الأداء الرئيسي لديك هو "الرموز لكل دولار"، فإن 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 بمجرد أن يكون شكل نظامك مستقرًا.

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