DeepSeek V4.1 Flash: ثورة الذكاء الاصطناعي الصيني الجديدة في الأداء مقابل السعر
بقلم Gab
المحتويات
يقدّم @kimmonismus نموذج DeepSeek V4.1 Flash بوصفه تطورًا فائق السرعة، يأتي بعد ستة أسابيع من تحديث V4-Flash الصادر في يوليو. وتورد رسالته الأرقام الأساسية: بنية Causal Encoder Decoder، و552 مليار مُعامِل بنظام MoE، منها 8 مليارات مُعامِل نشط عند الإدخال و16 مليارًا أثناء التوليد، إلى جانب ذاكرة KV المؤقتة بحجم لا يتجاوز ربع ذاكرة HBM وثُمن مساحة تخزين SSD مقارنةً بالجيل السابق. ويضيف أن DeepSeek بات يتفوق على DeepSeek V4 Pro من حيث القدرات والتكلفة والسرعة، وأن حركة مرور V4 Pro ستُوجَّه مؤقتًا إلى V4.1 Flash بدءًا من 14 سبتمبر.
هذه القراءة أمينة للإعلان إجمالًا، لكنها تركز بصورة أساسية على وتيرة الإصدارات والقفزة التي حققها المنتج. أما سلسلة المنشورات الرسمية فتقدم صورة أكثر اكتمالًا: إذ لا تُعزى المكاسب إلى البنية وحدها، بل أيضًا إلى أساليب جديدة للتدريب المسبق وإلى تدريب لاحق بالتعلم المعزز (RL) نُفِّذ على نطاق أوسع. والأهم أن أبرز تغيير من الناحية التشغيلية، وراء الحديث عن نموذج Flash «أكثر ذكاءً وسرعةً وكفاءةً»، يتعلق بحجم الذاكرة اللازمة للاستدلال على السياقات الطويلة، وهو موضوع حاسم لوكلاء الذكاء الاصطناعي.
ويُظهر الرسم البياني الذي شاركه @kimmonismus واقعًا أقل تجانسًا من السردية التسويقية: فنموذج DeepSeek V4.1 Flash قادر على المنافسة في عدة تقييمات، لكنه لا يتفوق بصورة منهجية على النماذج الرائدة في Terminal-Bench.
يستند منشور @kimmonismus، المنشور في 10 سبتمبر، صراحةً إلى سلسلة منشورات الحساب الرسمي لـ DeepSeek. وهذه نقطة مهمة: فالأرقام وترحيل نقاط النهاية ووعود الأداء صادرة أساسًا عن مطوّر النموذج، لا عن المحلل الذي لخّصها.
فيما يلي المنشور المصدر الذي نشرته DeepSeek قبل ذلك ببضع ساعات:
سلسلة المنشورات الرسمية: عائلة جديدة، لا مجرد تحديث بسيط لـ Flash
في رسالته الأولى، يقدّم @deepseek_ai نموذج V4.1 Flash بوصفه «أصغر نموذج في عائلة بنيتنا الجديدة»، مع قدرة أصلية على الفهم البصري. والتموضع واضح: لم يعد Flash مجرد إصدار خفيف، بل أصبح أول نموذج ضمن عائلة مصممة للسرعة ومعدل المعالجة وقابلية التوسع.
ويتناول الجزء الثاني من سلسلة المنشورات تفاصيل البنية. يعتمد DeepSeek V4.1 Flash على نظام MoE يضم 552 مليار مُعامِل، لكنه لا يستخدم الشبكة بأكملها في كل خطوة. ووفقًا لـ DeepSeek، لا ينشط سوى 8 مليارات مُعامِل أثناء معالجة الإدخال، ثم 16 مليارًا أثناء التوليد.
يمثّل هذا التباين جوهر بنية Causal Encoder Decoder. فلم تعد معالجة السياق وإنتاج الرموز الجديدة تتطلبان التكلفة نفسها، كما أنهما لا تستخدمان الموارد نفسها تمامًا. وفي حالات الاستخدام التي تتطلب قراءة سياق ضخم قبل توليد إجابة قصيرة نسبيًا، يمكن لهذا الفصل أن يحسّن نسبة التكلفة إلى الأداء.
يقارن الجدول الرسمي V4.1 Flash بـ V4 Pro 0813 وV4 Flash 0731 وعدة نماذج منافسة. ويشير، على وجه الخصوص، إلى حصول V4.1 Flash على 30,0 في Terminal-Bench 3.0 و31,2 في Terminal-Bench 4.0 و74,2 في DeepSWE v1.1.
الاختبارات المعيارية الرئيسية لـ DeepSeek V4.1 Flash
| الاختبار المعياري | النتيجة المعلنة لـ V4.1 Flash | القراءة |
|---|---|---|
| Terminal-Bench 3.0 | 30,0 | يتقدم V4.1 Flash على GLM 5.3 في الجدول الرسمي. |
| Terminal-Bench 4.0 | 31,2 | يظل النموذج خلف GLM 5.3، الذي سجل 37,9. |
| DeepSWE v1.1 | 74,2 | نتيجة تبرزها DeepSeek لمهام هندسة البرمجيات. |
تؤكد DeepSeek أن أساليبها الجديدة للتدريب المسبق، إلى جانب تدريب لاحق أكثر طموحًا بالتعلم المعزز، تضع النموذج في موقع متقدم على أنظمة بارزة، من بينها DeepSeek V4 Pro. وهذا التوضيح مهم مقارنةً بملخص @kimmonismus: فالبنية عنصر محوري، لكنها لا تفسر وحدها النتائج المُعلنة.
الصياغة الرسمية بسيطة عن قصد:
"ذاكرة KV مؤقتة أصغر. وفورات أكبر." @deepseek_ai
وبالتالي، قد لا يتمثل الوعد الأكثر واقعية في V4.1 Flash في تحقيق نتيجة خام أعلى بالضرورة، بل في خفض تكلفة الذاكرة بصورة ملحوظة لأعباء العمل الطويلة والمتكررة.
ذاكرة KV المؤقتة في DeepSeek، الرافعة الحقيقية للوكلاء
تخزّن ذاكرة KV المؤقتة التمثيلات اللازمة لتجنّب إعادة حساب السياق بالكامل مع كل رمز مُولَّد. وتُعد هذه الذاكرة ضرورية للمحادثات الطويلة، والوكلاء الذين يستدعون الأدوات، وسير عمل البرمجة، وعمليات البحث التكرارية، والأنظمة التي تحتفظ بسجلّ موسّع.
تعلن DeepSeek أن ذاكرة التخزين المؤقت في V4.1 Flash لم تعد تتطلب سوى:
- ربع ذاكرة HBM التي كان يتطلبها الجيل السابق.
- ثُمن مساحة تخزين SSD التي كانت مطلوبة سابقًا.
- نحو 890 بايتًا لكل رمز من ذاكرة التخزين المؤقت الإجمالية، مقارنةً بـ 3 514 بايتًا في V4 Flash وفقًا للرسم البياني الذي نشرته الشركة.
يوضّح الرسم الرسمي انخفاضًا هائلًا منذ DeepSeek-V1: 389 120 بايتًا لكل رمز في V1، و48 068 في V3.2، و3 514 في V4 Flash، ثم 890 في V4.1 Flash.
بالنسبة إلى مشغّل الوكلاء، قد يكون هذا التحسّن أكثر تأثيرًا من فارق هامشي في اختبار معياري. فغالبًا ما تمثّل إصابات ذاكرة التخزين المؤقت جزءًا مهمًا من التكلفة عندما يعيد الوكيل استخدام سياق ضخم بصورة متكررة. ويؤدي ضغط هذه الذاكرة المؤقتة إلى تقليل الضغط على ذاكرة GPU وسعة التخزين المطلوبة على نطاق واسع في آنٍ واحد.
وهذا تحديدًا ما أشار إليه @datachad في الردود على منشور @kimmonismus:
"إن تقليص ذاكرة KV المؤقتة إلى ربع سعة HBM هو العامل الأهم للاستدلال المحلي" @datachad
هذه الملاحظة صحيحة، لكنها تحتاج إلى بعض التحفّظ. فوجود ذاكرة KV مؤقتة في DeepSeek أكثر إحكامًا يجعل الاستضافة الذاتية للذكاء الاصطناعي أسهل منالًا للبنى التحتية المجهّزة بالفعل. لكنه لا يحوّل نموذج MoE يضم 552 مليار مُعلَمة إلى برنامج يسهل تشغيله على حاسوب شخصي.
وتقرّ DeepSeek بذلك بصورة غير مباشرة عندما تتحدث بنفسها عن عمليات نشر على نطاق مختلف تمامًا:
"هل تخطط لعملية نشر واسعة النطاق تضم أكثر من 2,000 وحدة GPU وعنقود تخزين؟ لنتحدث." @deepseek_ai
يُحسّن تقليص ذاكرة التخزين المؤقت اقتصاديات تقديم الخدمة بدرجة كبيرة، لكنه لا يزيل حاجز العتاد المرتبط بحجم النموذج.
يتوفر النموذج وتقريره التقني عبر صفحة DeepSeek-V4.1-Flash على Hugging Face والتقرير التقني لـ DeepSeek V4.1. غير أن المواد المتاحة في سلسلة المنشورات لا تتيح تأكيد التفاصيل التي ذكرها @UnslothAI في أحد الردود بشأن «196B engram». لذلك، ينبغي عدم التعامل مع هذه المعلومة على أنها مواصفة موثّقة من دون قراءة التقرير التقني مباشرةً.
انتقال في واجهة API يجعل Flash المنتج الافتراضي
لا يقتصر الإعلان على الترويج لنموذج جديد، بل يعيد أيضًا تنظيم مجموعة منتجات DeepSeek.
تشير سلسلة المنشورات الرسمية إلى ما يلي:
- تم سحب V4 Flash وV4 Flash Vision Exp.
- يُعاد توجيه المعرّفين القديمين
deepseek-v4-flashوdeepseek-v4-flash-vision-expمؤقتًا إلى V4.1 Flash للحفاظ على التوافق. - اعتبارًا من 14 سبتمبر 2026 الساعة 04:00 بالتوقيت العالمي المنسق (UTC)، ستُوجَّه أيضًا الطلبات المرسلة إلى DeepSeek V4 Pro نحو V4.1 Flash.
- سيستمر هذا الوضع حتى إطلاق V4.1 Pro.
- ستُحتسب تكلفة الطلبات المنقولة من V4 Pro وفق أسعار V4.1 Flash.
يتجاوز هذا القرار بكثير مجرد مقارنة ترويجية. تجعل DeepSeek من V4.1 Flash منتجها المرجعي لواجهة API حتى قبل وصول V4.1 Pro. وبالنسبة إلى الفرق التي تستخدم واجهة API بالفعل، تقلّل عملية الانتقال خطر حدوث انقطاع فوري. لكنها لا تلغي الحاجة إلى إعادة التحقق من المخرجات، وزمن الاستجابة، واستدعاءات الأدوات، والرؤية الأصلية، وسلوك النموذج في بيئة الإنتاج.
يلخّص @bygregorr المشكلة من وجهة نظر مطوّري التطبيقات:
"ستة أسابيع بين عائلات البنى المعمارية هي مهلة قصيرة لمطوّري واجهات API." @bygregorr
تستجيب DeepSeek من خلال توفير توافق انتقالي وإعادة توجيه المعرّفات القديمة. وهذا حل عملي من حيث استمرارية الخدمة، لكنه لا يضمن تكافؤًا وظيفيًا كاملًا. ومع ذلك، يجب إعادة اختبار أي تطبيق قائم على الوكلاء وحسّاس لتنسيقات المخرجات أو استدعاءات الأدوات أو سياسات الاستدلال.
يعرض جدول أسعار DeepSeek أسعارًا مختلفة بحسب ساعات الاستخدام، لكل مليون رمز. وخارج أوقات الذروة، يبيّن سعرًا قدره 0,003 دولار للإدخال مع استخدام ذاكرة التخزين المؤقت، و0,15 دولار للإدخال من دونها، و0,6 دولار للإخراج. أما خلال ساعات الذروة، فترتفع هذه المبالغ على التوالي إلى 0,006 و0,3 و1,2 دولار.
توضح DeepSeek أن الأسعار خارج أوقات الذروة تمثل 50 % من أسعار أوقات الذروة. ويعزز هيكل التسعير هذا الجدوى الاقتصادية لأعباء العمل المرنة، ولا سيما المعالجة الدفعية، والتقييمات المؤتمتة، أو المهام الوكيلية غير المتزامنة.
يشير منشور لطرف ثالث من @ns123abc، ورد ذكره في النقاش الموسع، إلى تكلفة تشغيل أقل بنحو 86 مرة لكل مليون توكن ومعدل إنتاجية يتراوح بين 420 و507 توكنات في الثانية. وقد تسهم هذه الأرقام في إثراء النقاش، لكنها لا تظهر في سلسلة المنشورات الرسمية المقدمة. ولذلك، ينبغي اعتبارها ادعاءات صادرة عن طرف ثالث وتعتمد على العتاد، وطول السياق، ومستوى التكميم، وحِمل الاختبار، لا بيانات مؤكدة من DeepSeek.
Terminal-Bench: تفوق مُعلن، لكنه ليس حكمًا شاملًا
تؤكد DeepSeek أن «اختبارات أجرتها جهات متعددة» تضع V4.1 Flash في مرتبة متقدمة على V4 Pro من حيث الأداء والتكلفة والسرعة وإجمالي وقت التنفيذ. وقد يدعم هذا الادعاء موقعه التنافسي، إلا أن سلسلة المنشورات لا توثق بما يكفي البروتوكولات أو مزودي الخدمة أو إعدادات الاستدلال أو التكوين الدقيق لهذه الاختبارات.
تتمحور نقطة الخلاف الرئيسية حول Terminal-Bench، وهو معيار يحظى بمتابعة خاصة لتقييم القدرات الوكيلية في استخدام الحاسوب والبرمجة.
يشير @Greg_GL_87 إلى تناقض ظاهري بين إصدارين من التقييم:
"يُظهر الجدول أنه يخسر أمام GLM 5.3 في Terminal-Bench 4.0 بنتيجة 31.2 مقابل 37.9، لكنه يفوز في الإصدار 3.0. انقسام غريب بين إصدارين من التقييم نفسه" @Greg_GL_87
لم يتلقَّ هذا الانتقاد ردًا في السلسلة. وهو انتقاد دقيق ومهم. يعرض الجدول الرسمي بالفعل نتيجة 31,2 لنموذج V4.1 Flash في Terminal-Bench 4.0، بينما يقارن @Greg_GL_87 هذه النتيجة بنتيجة 37,9 التي حققها GLM 5.3. وفي الوقت نفسه، يحقق V4.1 Flash نتيجة 30,0 في Terminal-Bench 3.0 ويتقدم فيه على GLM 5.3.
يمكن لنموذج أن يتفوق على V4 Pro في عدة مؤشرات من دون أن يكون الخيار الأفضل لجميع مهام البرمجة الوكيلية. ومن دون بروتوكول مفصل، يظل من المستحيل تحديد ما إذا كان الفارق بين Terminal-Bench 3.0 و4.0 ناتجًا عن المهام أو البيئات أو معلمات الاختبار أو عامل منهجي آخر.
يطرح @kryptosopus اعتراضًا أوسع من خلال مقارنة V4.1 Flash بـ Claude Opus 5:
"قدرات الرؤية الأصلية مدمجة في أصغر نموذج، لكنه لا يزال يخسر أمام Opus5 في Terminal-Bench بفارق 13 نقطة. من الواضح أن Flash هو خيار «الرخيص والسريع»، وليس نموذجًا رائدًا. خط التوسع في الأسفل هو المؤشر الحقيقي هنا" @kryptosopus
لا تتعارض هذه القراءة بالكامل مع رؤية DeepSeek. فقد يكون V4.1 Flash أفضل من DeepSeek V4 Pro وفقًا لعدة مقاييس اعتمدتها الشركة، مع بقائه خلف Opus 5 في معيار وكيلي معين. وتظهر المشكلة عندما يتحول تحسن نسبي داخل سلسلة من النماذج إلى ادعاء بالتفوق الشامل.
ردود الفعل: حماس للمصدر المفتوح، وحذر بشأن المنتج، وتساؤلات حول إصدار Pro المستقبلي
تتسم الردود على سلسلة المنشورات الرسمية بحماس واسع تجاه إتاحة النموذج ودمجه السريع. فعلى سبيل المثال، يشير @MrAhmadAwais إلى أن V4.1 Flash متاح بالفعل ضمن خدمته CommandCodeAI. أما @Presidentlin، فيشيد خصوصًا بمساهمة DeepSeek في منظومة المصدر المفتوح:
"شكرًا لكم مجددًا على دفع المصدر المفتوح إلى الأمام" "كما هو الحال دائمًا، هذا واجب" "إلى أي مدى سترتفع حدودكم؟!!" @Presidentlin
كان الرد مصحوبًا بصفحة مانغا تجسد هذا المزيج من الانبهار والتحدي أمام وتيرة DeepSeek.
من جانبه، يلخص @ParthM1001 الأجواء باستعارة من عالم الطهي:
"لقد أبدع الحوت شيئًا جميلًا من جديد." @ParthM1001
أما الردود على منشور @kimmonismus، فتركز بدرجة أكبر على موقع النماذج ضمن السلسلة. ويرى @elshayib_ أن إصدار Pro القديم فقد جدواه:
"أصبح V4 pro بلا أهمية إلى حد ما الآن" @elshayib_
ويرد عليه @kimmonismus:
"نعم، ننتظر فقط إصدارًا جديدًا من نسخة pro" @kimmonismus
يتسق هذا الرد مع الإعلان الرسمي: إذ إن V4 Pro يمر بالفعل بمرحلة سحب مؤقت، لكن DeepSeek تعلن صراحة عن إصدار مستقبلي من V4.1 Pro. ولذلك، فإن استنتاج أن سلسلة Pro بأكملها أصبحت عديمة الفائدة نهائيًا يتجاوز الحقائق المثبتة.
ويظهر التساؤل نفسه لدى @RimasXYZ:
"إذا كان Flash يتفوق الآن على v4-pro من حيث القدرات والتكلفة والسرعة، فما المجال المتبقي أمام v4.1-pro ليتفوق فيه؟" @RimasXYZ
لا تجيب سلسلة المنشورات عن هذا السؤال. فهي تترك تعريف منتج Pro المستقبلي مفتوحًا بالكامل: جودة أفضل في المهام الصعبة، أو قدرات استدلال معززة، أو سياق أطول، أو موثوقية أعلى في أداء الوكلاء، أو مقايضة أخرى في الأداء.
بنية المرمّز السببي وفاك الترميز: ما الذي يتغير تقنيًا
ردّ @austinyuhao، «مرحبًا بعودة بنية المرمّز وفاك الترميز»، قصير لكنه وجيه. لا تقترح DeepSeek مجرد ضغط لذاكرة التخزين المؤقت، بل تعيد تقديم فصل معماري بين مسار الترميز السببي وفاك الترميز.
"مرحبًا بعودة بنية المرمّز وفاك الترميز" @austinyuhao
يوضح المخطط الذي تمت مشاركته في الرد مرمّزًا سببيًا (Causal Encoder) وفاك ترميز (Decoder) يتكون كل منهما من عشرين طبقة، ليبلغ إجمالي طبقات الشبكة أربعين طبقة. كما يُظهر مكونات MoE وCSA2 وSWA وVision Encoder وText Embedding وEngram وDSpark وCandidate Pool.
يوضح هذا التنظيم سبب ارتباط موضوعي الاستدلال متعدد الوسائط وذاكرة KV المؤقتة. تسعى DeepSeek إلى دعم الرؤية بصورة أصلية مع الحفاظ على تكلفة معقولة عند التعامل مع التسلسلات الطويلة. ويُعد هذا الوعد جذابًا بوجه خاص للوكلاء الذين يتعين عليهم قراءة المستندات، وتحليل الواجهات، والتعامل مع الشيفرات البرمجية، والاحتفاظ بذاكرة عمل مستمرة.
الأسئلة الشائعة حول DeepSeek V4.1 Flash
كم عدد المعلمات النشطة في DeepSeek V4.1 Flash؟
تعلن DeepSeek عن نموذج MoE يضم 552 مليار معلمة. ومن المفترض أن تنشط 8 مليارات معلمة فقط أثناء معالجة المدخلات، ثم 16 مليارًا أثناء التوليد.
لماذا تُعد ذاكرة KV المؤقتة في DeepSeek مهمة لوكلاء الذكاء الاصطناعي؟
تتيح ذاكرة KV المؤقتة الاحتفاظ بتمثيلات السياق الذي سبق أن تمت معالجته. وتقلل الذاكرة المؤقتة الأكثر إحكامًا متطلبات ذاكرة GPU والتخزين، ما قد يخفض تكلفة المحادثات الطويلة والوكلاء الذين يستدعون الأدوات وسير العمل الذي يعيد استخدام السياق نفسه بصورة متكررة.
ماذا سيحدث لمستخدمي DeepSeek V4 Pro؟
اعتبارًا من 14 سبتمبر 2026 عند الساعة 04:00 بالتوقيت العالمي المنسق (UTC)، يجب توجيه الطلبات المخصصة لـ DeepSeek V4 Pro مؤقتًا إلى V4.1 Flash، إلى حين إطلاق V4.1 Pro. ويتعين على الفرق المعنية إعادة التحقق من صلاحية استخداماتها في بيئة الإنتاج، حتى مع الحفاظ على توافق API خلال الفترة الانتقالية.
أبرز الخلاصات
لا يُعد DeepSeek V4.1 Flash مجرد تحديث سريع إضافي. إذ يجمع الإعلان بين بنية جديدة غير متماثلة، وتفعيل متباين لـ MoE بين الإدخال والتوليد، وضغط كبير لذاكرة KV المؤقتة، وأسعار API تنافسية، ونقل فعلي لحركة البيانات من V4 Pro.
بالنسبة إلى المتخصصين، التداعيات واضحة:
- يمكن أن يؤدي تقليص ذاكرة KV المؤقتة إلى تحسين تكلفة الوكلاء ذوي السياق الطويل بصورة ملموسة.
- أصبحت الاستضافة الذاتية للذكاء الاصطناعي أكثر واقعية للمشغلين الذين يمتلكون بالفعل بنية تحتية كبيرة.
- يفرض تحويل V4 Pro إلى Flash مرحلة للتحقق من التطبيقات.
- لا تكفي ادعاءات الأداء مقارنةً بـ V4 Pro لإثبات التفوق في جميع معايير قياس أداء الوكلاء.
- يظل Terminal-Bench نقطة تستدعي الانتباه، خصوصًا في ضوء التباين بين الإصدارين 3.0 و4.0 الذي أشار إليه @Greg_GL_87.
وهكذا تترك سلسلة المنشورات عدة أسئلة مفتوحة: ما البروتوكولات التي تبرر عبارة «اختبارات أجرتها جهات متعددة»، ولماذا تختلف النتائج باختلاف إصدار Terminal-Bench، وما الدور المميز الذي سيؤديه V4.1 Pro، وما مواصفات العتاد التي تجعل الاستضافة الذاتية عملية حقًا؟
والخلاصة الأكثر منطقية هي أيضًا الأكثر فائدة: يبدو أن V4.1 Flash يمثل تقدمًا كبيرًا من حيث الكفاءة والنشر، لكنه لم يثبت بعد أن نموذجًا من فئة Flash قد ألغى المقايضات الملازمة للنماذج الرائدة.