DeepSeek V4.1 Flash: ما الجديد مقارنةً بـ V4 Flash وV4 Pro؟

أطلقت DeepSeek نموذج DeepSeek-V4.1-Flash في 10 سبتمبر 2026، وهو نموذج متعدد الوسائط بأوزان مفتوحة. أبرز ما يميّزه ليس حجم النموذج وحده، بل الجمع بين بنية «مزيج الخبراء» (MoE)، والتفعيل المتناثر للمعلمات، وتقليص كبير لذاكرة KV Cache؛ وهي الذاكرة التي يحتفظ بها النموذج بحالة الانتباه أثناء توليد النص. والهدف هو جعل الاستدلال على سياقات شديدة الطول أكثر قابلية للتشغيل عملياً. 1735

ما الذي تغيّر في واجهة API؟

للمشروعات الجديدة، توصي DeepSeek باستخدام المعرّف deepseek-flash، وهو الذي يستدعي V4.1 Flash حالياً. ويضيف النموذج فهماً بصرياً أصلياً إلى جانب النص. 1517

أما V4 Flash وV4 Flash Vision Exp فقد أُحيلا إلى التقاعد. ومع ذلك، تقبل DeepSeek مؤقتاً المعرّفين القديمين deepseek-v4-flash وdeepseek-v4-flash-vision-exp لأغراض التوافق، لكن الطلبات تُخدم عبر V4.1 Flash وتُحاسب بتسعيرة Flash. 1523

وضع V4 Pro مختلف: كانت تقارير الانتقال المبكرة تشير إلى تحويل حركة مروره إلى V4.1 Flash حتى وصول V4.1 Pro. لكن سجل التغييرات الرسمي اللاحق من DeepSeek يقول إن خدمة API الخاصة بـ V4 Pro ستستمر بعد 14 سبتمبر 2026 استجابةً لطلب المستخدمين، مع بقاء أسلوب الفوترة بلا تغيير. لذلك، من يحتاج إلى سلوك قابل لإعادة الإنتاج ينبغي أن يستخدم معرّفات النماذج الحالية الموثقة ويجري اختبارات انحدار، بدلاً من افتراض أن أي مسار قديم سيؤدي دائماً إلى V4.1 Flash. 1523

552 مليار معلمة، لكن ليس كلها تعمل في كل خطوة

يضم V4.1 Flash 552 مليار معلمة أساسية ضمن بنية MoE. في هذا النوع من النماذج، لا تُشغَّل كل المعلمات عند معالجة كل رمز؛ بل يُنتقى جزء منها بحسب المدخل.

تقول DeepSeek إن النموذج يفعّل 8 مليارات معلمة عند معالجة المدخلات (مرحلة prefill)، و16 مليار معلمة عند توليد المخرجات (مرحلة decoding). ويعتمد ما تسميه الشركة بنية Causal Encoder–Decoder، وهي تفرّق بين كلفة قراءة الطلبات الطويلة وكلفة توليد إجابات طويلة. 1735

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

لماذا يحتاج سياق المليون رمز إلى ضغط ذاكرة KV؟

يدعم V4.1 Flash سياقاً يصل إلى مليون رمز. 35

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

وفق بطاقة النموذج، تستمد بنية Causal Encoder–Decoder ذاكرة KV العامة الخاصة بالمفكك من الحالات المخفية النهائية للمشفّر، بدلاً من اشتقاقها بشكل مستقل من كل طبقة في المفكك. كما يجمع الإصدار بين Compressed Sparse Attention 2 وذاكرة KV بتنسيق FP4. وتقول DeepSeek إن ذلك يخفض بصمة ذاكرة KV العامة إلى نحو 890 بايتاً لكل رمز، أي ما يقارب ربع البصمة المناظرة في DeepSeek V4 Flash. 3539

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

أوزان مفتوحة وترخيص MIT

نشرت DeepSeek أوزان V4.1 Flash على Hugging Face بموجب ترخيص MIT. وهذا يتيح للجهات تنزيل النموذج ونشره ذاتياً وفق شروط الترخيص. 35

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

هل يتفوق على V4 Pro؟

تقول DeepSeek إن أساليب تدريب مسبق جديدة، إلى جانب تدريب لاحق بالتعلم المعزز على نطاق أوسع، حققت نتائج معيارية تتقدم على نماذج رائدة، بما فيها V4 Pro. كما تشير الشركة إلى اختبارات من جهات متعددة تضع V4.1 Flash في المقدمة من حيث الأداء والكلفة والسرعة والمدة الإجمالية للتنفيذ. 17

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

حضور مبكر على OpenRouter: إشارة طلب لا مقياس للسوق كله

وصل V4.1 Flash إلى سوق كانت نماذج DeepSeek وغيرها من المزودين الصينيين تحظى فيه بالفعل بحركة مرور كبيرة عبر المنصات الوسيطة. يرتب OpenRouter النماذج وفق عدد رموز الطلبات والإكمالات التي مرت عبر واجهة API الخاصة به. وفي ترتيبه بتاريخ 13 سبتمبر، سجّل DeepSeek V4.1 Flash نحو 4.94 تريليون رمز بوصفه نموذجاً جديداً؛ وسجّل DeepSeek V4 Flash 0731 نحو 11.6 تريليوناً، وV4 Flash 0423 نحو 4.36 تريليوناً، بينما بلغ Xiaomi MiMo-V2.5 نحو 7.77 تريليون رمز. 57

كما أظهرت لقطة أقدم في أغسطس مدى سرعة تغيّر الترتيب: فقد سجّل V4 Flash حينها 7.1 تريليون رمز أسبوعياً، وكانت تسعة من النماذج العشرة الأكثر استخداماً في ذلك الترتيب صينية. 50

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

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

أقوى سبب لاختبار V4.1 Flash هو جمعه بين تعدد الوسائط الأصلي، وسياق المليون رمز، والأوزان المفتوحة، وتصميم يستهدف خفض كلفة ذاكرة الاستدلال طويل المدى. 1735

خطوات عملية مقترحة:

1. استخدم deepseek-flash في تكاملات Flash الجديدة.
2. تعامل مع معرّفات Flash القديمة وVision Exp كمسارات توافق، لا كإشارات ثابتة لإصدار محدد.
3. قارن V4.1 Flash وV4 Pro على طلباتك ومعايير نجاحك أنت.
4. قِس استرجاع المعلومات في السياقات الطويلة وزمن التنفيذ من البداية إلى النهاية، كلٌّ على حدة، ولا تكتفِ برقم سعة السياق.
5. استخدم تصنيفات OpenRouter كمؤشر للطلب، لا بديلاً عن اختبار الإنتاج.

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