هل يستخدم DeepSeek V4 ذاكرة أقل 98%؟ الدليل يقف عند KV Cache

عبارة «DeepSeek V4 يستخدم ذاكرة أقل بنسبة 98%» تبدو مثيرة، لكنها تختصر مسألة تقنية بطريقة قد تقود إلى استنتاج خاطئ. الخلط الأساسي هنا هو بين ضغط KV Cache، أي الذاكرة المؤقتة التي يحتفظ بها النموذج أثناء قراءة سياقات طويلة، وبين إجمالي ذاكرة بطاقة الرسوميات VRAM اللازمة لتشغيل النموذج وخدمته.

ما تدعمه المصادر العامة حتى الآن أضيق من العنوان المتداول: DeepSeek V4 يتضمن تحسينات واضحة لتقليل حجم KV Cache وتكلفة آلية الانتباه في الاستدلال طويل السياق، لكن لا تظهر في صفحة أخبار API أو بطاقة النموذج الرسمية مواصفة تقول إن إجمالي VRAM ينخفض بنسبة 98% .

الخلاصة الأكثر أماناً

الصياغة الأدق هي:

يستخدم DeepSeek V4 تصميمات مثل Hybrid Attention وCompressed Sparse Attention، أو CSA، وHeavily Compressed Attention، أو HCA، لتقليل ضغط KV Cache في الاستدلال طويل السياق. أما القول إن إجمالي VRAM ينخفض 98% فلا تسنده المعلومات المتاحة حالياً .

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

ما الذي أكدته الوثائق فعلاً؟

تسجل صفحة أخبار DeepSeek الخاصة بالـ API إصدار DeepSeek-V4 Preview في 24 أبريل 2026 . وتذكر بطاقة النموذج أن عائلة V4 تشمل DeepSeek-V4-Pro وDeepSeek-V4-Flash، وأنها سلسلة نماذج لغة من نوع Mixture-of-Experts، أو MoE، مع الاحتفاظ بإطار DeepSeekMoE واستراتيجية Multi-Token Prediction، إلى جانب تغييرات معمارية منها Hybrid Attention Architecture .

الجزء المرتبط مباشرةً بالذاكرة يظهر في معالجة الانتباه طويل السياق. يشرح مقال تقني من NVIDIA أن Compressed Sparse Attention (CSA) يستخدم ضغطاً ديناميكياً للتسلسل بهدف ضغط إدخالات KV وتقليل أثر KV Cache في الذاكرة، ثم يطبق DeepSeek Sparse Attention لجعل مصفوفات الانتباه أكثر ندرة وتقليل كلفة الحساب. أما Heavily Compressed Attention (HCA) فيدمج إدخالات KV لمجموعات من الرموز في إدخال مضغوط واحد، ما يخفض حجم KV Cache أكثر .

بعبارة أبسط: الدليل المتاح يدعم أن V4 يحاول جعل KV Cache وعمليات attention أرخص في السياقات الطويلة. لكنه لا يحول ذلك تلقائياً إلى وعد بأن كل مكونات الذاكرة ستنخفض بالنسبة نفسها.

98% و90% و9.5x: أرقام لا ينبغي خلطها

رقم 98% يظهر بوضوح في عنوان مقال منشور على LinkedIn من إنشاء مستخدم، يقول إن DeepSeek Sparse Attention يقلص ذاكرة KV بنسبة 98% في الاستخدام الحقيقي . هذا النوع من المحتوى قد يكون مفيداً كبداية للتتبع، لكنه ليس وثيقة رسمية من DeepSeek ولا يصلح وحده لبناء خطة سعة أو قرار شراء.

الرقم الأكثر قابلية للتدقيق في التغطيات الثالثة هو 10% من KV Cache. نقلت Wccftech أن DeepSeek V4 يحتاج، مقارنةً بـ DeepSeek V3.2، إلى 27% من FLOPs للاستدلال على رمز واحد و10% من KV Cache . إذا قرأنا الرقم حرفياً، فهذا يعني خفضاً يقارب 90% في KV Cache مقارنةً بـ V3.2، لا خفضاً بنسبة 90% أو 98% في إجمالي VRAM في كل ظروف التشغيل .

هناك أيضاً عنوان إخباري يتحدث عن 9.5x lower memory requirements . حتى بالحساب المباشر، 1 ÷ 9.5 تعني بقاء نحو 10.5% من المتطلبات، أي خفضاً يقارب 89.5%. هذا أيضاً ليس 98%، كما أنه يحتاج إلى توضيح: هل المقصود KV Cache فقط، أم سيناريو طويل السياق، أم الذاكرة الكاملة لخدمة النموذج؟

الادعاء	حالة الدليل	القراءة الأدق
إجمالي VRAM أقل 98%	لا يظهر كرقم رسمي في المصادر المتاحة	لا ينبغي استخدامه كمواصفة شراء أو وعد تسويقي
ضغط كبير في KV Cache	مدعوم تقنياً	CSA وHCA يستهدفان ضغط إدخالات KV في السياقات الطويلة
10% من KV Cache	منقول في تغطية طرف ثالث	يعني تقريباً 90% خفضاً في KV Cache مقارنةً بـ V3.2، وليس في كل الذاكرة
ذاكرة أقل 9.5x	عنوان إخباري لطرف ثالث	يعادل تقريباً 89.5% خفضاً، مع ضرورة معرفة نطاق المقارنة

لماذا لا تعني KV Cache إجمالي VRAM؟

في مهام الوكلاء البرمجية أو المحادثات الطويلة، تتراكم نتائج الأدوات والرسائل داخل السياق، وكل رمز جديد يحتاج إلى التعامل مع تاريخ أطول. يوضح عرض Hugging Face لـ DeepSeek V4 أن رقمين يصبحان مهمين هنا: FLOPs للاستدلال على الرمز الواحد وحجم KV Cache، وكلاهما يزيد مع طول التسلسل . وتصف نسخة GitHub من المقال فشلاً مألوفاً في هذه المهام: تجاوز ميزانية السياق، أو امتلاء GPU بسبب KV Cache، أو تباطؤ جولات استدعاء الأدوات أثناء مهمة طويلة .

لكن تشغيل نموذج كامل لا يستهلك VRAM في KV Cache فقط. حتى المقال الذي يطرح رقم 98% على LinkedIn يفصل بين أوزان مشتركة، وأوزان الخبراء في MoE، والتفعيلات، وKV Cache، وكلفة إطار التشغيل . هذه القسمة مهمة: إذا انخفضت KV Cache بقوة في سيناريو معين، فهذا لا يعني أن كل عناصر منظومة الخدمة ستنخفض بالنسبة نفسها.

CSA/HCA هندسة كفاءة، لا رقم سحري

اللافت في DeepSeek V4 ليس وجود «حيلة ذاكرة» واحدة، بل محاولة هندسية لتقليل كلفة الانتباه عندما يصبح السياق طويلاً جداً. فبحسب NVIDIA، تضغط CSA إدخالات KV وتقلل أثرها في الذاكرة، ثم تستخدم ندرة الانتباه لتقليل الحساب، بينما تطبق HCA ضغطاً أشد عبر دمج إدخالات KV لمجموعات من الرموز في إدخال واحد .

ويشير التقرير التقني لـ DeepSeek V4 أيضاً إلى تحسينات في البنية التحتية للتدريب والاستدلال، منها تصميم نواة مدمجة واحدة لوحدات MoE بحيث تتداخل عمليات الحساب والاتصال والوصول إلى الذاكرة . هذه تحسينات مهمة، لكنها لا تشكل دليلاً مباشراً على أن إجمالي VRAM أقل بنسبة 98%.

كيف تقيّم DeepSeek V4 عملياً؟

إذا كنت تفكر في DeepSeek V4 لمهام مثل قراءة ملفات طويلة، أو محادثات ممتدة، أو وكلاء يستدعون أدوات مرات كثيرة، فلا تجعل العنوان «98% ذاكرة أقل» هو نقطة البداية. السؤال العملي هو: هل عنق الزجاجة لديك هو KV Cache فعلاً؟

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

الخلاصة: من العادل القول إن DeepSeek V4 يقدم ضغطاً قوياً ومهماً لـ KV Cache في الاستدلال طويل السياق. أما عبارة «ذاكرة أقل 98%» بصفتها وصفاً لإجمالي VRAM، فهي أوسع مما تسمح به الأدلة المتاحة حالياً.