مطوّر يستبدل Claude Code بنموذجَي Qwen وDeepSeek محليًا: دورة التطوير تطول من 3 إلى 4 مرات

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

ما هو المختبر وكيف صُمم

وفّر صاحب العمل العتاد، وهو شركة تؤجّر أجهزة NVIDIA DGX Spark. يعمل Qwen 3.8 Flash Next على جهاز Spark واحد بسياق 256K. أما DeepSeek-V4.1-Flash-1017 فيعمل بتكميم EXL3 على جهازي Spark بسياق 512K. المحرك في الحالتين هو TensorFold.

أوكل الكاتب نشر DeepSeek إلى Qwen نفسه. فقد استكشف النموذج، من جهاز Spark المجاور، الأجهزة وجمع المتطلبات وكتب سيناريوهات Ansible. استغرق ذلك نحو يوم عمل، وانطلق DeepSeek من المحاولة الأولى. وهذا اختبار جيد لـ Qwen نفسه: فقد حلّ مهمة بنية تحتية بشكل مستقل.

يستخدم الكاتب Pi البسيط على WSL كإطار تشغيل (harness)، وصنع إضافة لـ PhpStorm للراحة. وتوفّر الوكلاء الفرعيون سياق الجلسة الرئيسية. والمهام حقيقية: PHP على Symfony وGo وKubernetes.

الأرقام: توليد سريع وقراءة بطيئة

كتب الكاتب اختبار أداء خاصًا به: 10 قياسات لكل سياق من 2K إلى 128K، بمطالبات فريدة مع ملح عشوائي، بحيث لا يفيد التخزين المؤقت للبادئة. وكانت النتائج كالتالي:

• يولّد Qwen على جهاز Spark واحد 70–80 توكن/ث، بينما يولّد DeepSeek على جهازين 99–109 توكن/ث.
• عند احتسابها لكل جهاز Spark ينعكس الوضع: 70–80 توكن/ث لـ Qwen مقابل 49–55 لـ DeepSeek. مضاعفة العتاد تعطي زيادة قدرها 1,36–1,5 مرة فقط.
• سرعة الـ prefill لدى Qwen 2,3–2,5 ألف توكن/ث، ولدى DeepSeek 1,7–2,3 ألف توكن/ث.

ومن هنا زمن أول توكن عند 128K: 57 ثانية لدى Qwen و73 ثانية لدى DeepSeek، رغم أن الأخير يولّد أسرع. عند 32K يبلغ 13–21 ثانية، وعند 64K يبلغ 27–36 ثانية. وتوجد قيم شاذة أيضًا: فقد سُجّلت لدى DeepSeek طلبات بزمن TTFT قدره 4,8 ث عند 2K و10,2 ث عند 8K.

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

سير العمل على نموذجين

أهم اكتشافات الكاتب لا يتعلق بالسرعة بل بالعملية. في المهمة الكبيرة يكتب كل نموذج خطته منفصلًا، ثم يقرأ كل منهما خطة «زميله» ويقرر أيهما يعتمد أساسًا. وفي أغلب الحالات اتفقت الآراء: اعتُمدت خطة DeepSeek، ولمرة واحدة فقط اختار النموذجان خطة Qwen.

ثم تأتي مرحلة التنفيذ. في الصيغة البسيطة ينفذها DeepSeek مع وكلاء فرعيين وبـ commit مستقل لكل خطوة، فيما يراجع الكاتب الـ commits بالتوازي ويجمع الملاحظات. ثم تأتي مراجعات بسياق جديد يجريها DeepSeek ثم Qwen مرة أخرى. وفي الصيغة المعقدة يعمل النموذجان بالتوازي في worktrees مختلفة، ويختار الكاتب الحل الأفضل. وتُبنى الاختبارات بالطريقة نفسها: تُدمج خطتا e2e، ويشغّلهما النموذجان بالتناوب ويصلحان الأخطاء، ثم تأتي مراجعة يدوية إلزامية، فمرحلة staging، فالإصدار.

القيود والخلاصة

ثمن هذه الحرية مرتفع. وفق تقدير الكاتب المبدئي، صارت دورة التطوير أطول بمقدار 3 إلى 4 مرات مقارنة بـ Claude Code. ويعزو جزءًا من ذلك إلى قلة الاعتياد وازدواجية العمل على نموذجين، وينوي الاكتفاء بنموذج واحد. وبحسب انطباعه، DeepSeek أذكى وأكثر انتباهًا من Qwen بنحو 20%، لكنه يتطلب جهازي Spark. وهذا تقدير شخص واحد دون تحقق رسمي من الجودة، لذا ينبغي التعامل معه بوصفه تقديرًا ذاتيًا.

والاختبار الجانبي دال أيضًا. فقد أعدّ DeepSeek في ساعة واحدة تشغيل Hogwarts Legacy بالواقع الافتراضي: وجد أداة الحقن، وحمّل ملفات التعريف، وكتب سكربتًا مع تعليمات. وحين لم يعمل من المرة الأولى، شخّص المشكلة بنفسه في نصف ساعة إضافية. ويرى الكاتب أن Opus 5.5 كان سينجز ذلك أسرع بأضعاف، لكن مستوى النماذج المفتوحة يكفي بالفعل لكثير من المهام.

الخلاصة العملية للفرق: تصلح المنظومة المحلية كتأمين ضد الحظر وكخيار للبيئات المغلقة التي لا يجوز فيها إرسال الشيفرة إلى السحابة. لكن احسبوا وقتًا لانتظار الـ prefill ولإعداد العملية وللعتاد. إذا كان لديكم جهاز Spark واحد فاختاروا Qwen، وإذا كان لديكم جهازان فجرّبوا DeepSeek. وينوي الكاتب لاحقًا اختبار GLM 5.3 Flash على جهازي Spark.