DeepSeek تضغط ذاكرة التخزين المؤقت للنموذج إلى 890 بايت لكل رمز بدلًا من 3514

نشرت DeepSeek نموذج DeepSeek-V4.1-Flash على Hugging Face، ونشرت معه ورقة بحثية لا تركّز مساحتها الأكبر على جودة الإجابات، بل على كلفة تخزين الذاكرة. فحين يقرأ نموذج لغوي نصًا طويلًا، يحتفظ لكل رمز ببيانات وسيطة تخص آلية الانتباه. هذا هو KV-cache. وتكمن الحاجة إليه في تجنّب إعادة الحساب من الصفر عند توليد كل كلمة تالية. وكلما طال السياق ازداد حجمه. في V4.1-Flash يشغل الكاش العام في HBM، وهي أسرع ذاكرة في بطاقة الرسوميات، 890 بايت لكل رمز، بينما كان في V4-Flash السابق 3514. وفي جلسة من مليون رمز يعني ذلك نحو 0,9 غيغابايت بدلًا من 3,5 غيغابايت.

النموذج متعدد الوسائط ومبني وفق بنية MoE (mixture of experts)، إذ يعمل لكل رمز جزء فقط من الخبراء. ويضم الجذع الرئيسي 552 مليار معامل. وهناك 196 مليار معامل أخرى مخزنة في جداول الذاكرة Engram. والسياق مصمم لـ 1M رمز. وتضم الورقة نحو 500 مؤلف. لا تتوفر شيفرة التدريب، لكن الأوزان منشورة.

ثلاثة أساليب خفّضت كلفة التشغيل

أبرز ابتكار معماري هو بنية المشفّر-فاك الترميز السببية، واختصارها CED. فمعظم النماذج المفتوحة الرائدة تعتمد بنية decoder-only، حيث تتولى حزمة الطبقات نفسها قراءة الطلب وكتابة الإجابة. أما هنا فقد قُسمت الحزمة. ففي مرحلة prefill، حين يقرأ النموذج الموجّه (prompt)، يعمل 8 مليارات معامل. وعند فك الترميز، أي توليد الإجابة، يرتفع العدد إلى 16 مليارًا. وهذه فكرة قريبة من YOCO، حيث يُحسب الكاش مرة واحدة ثم يُعاد استخدامه.

الأسلوب الثاني هو آلية الانتباه CSA2. فهي تأخذ الكاش بصيغة FP4، أي تخزّن الأرقام في أربع بتات فقط، وتعيد استخدامه بين الطبقات. وكانت كل طبقة سابقًا تحتفظ بنسخة خاصة بها.

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

الحصيلة على صعيد الذاكرة:

• الكاش في HBM: 890 بايت لكل رمز بدلًا من 3514، أي أقل بنحو 4 مرات؛
• الكاش طويل الأمد على SSD: نحو 1/8 من حجمه لدى V4-Flash؛
• المعاملات النشطة: 8 مليارات في prefill و16 مليارًا عند فك الترميز.

ماذا أظهرت الاختبارات المعيارية

لا يكفي التوفير وحده إذا أصبح النموذج أقل ذكاءً. لذلك قارن المؤلفون النموذج بسلفه وبنموذج Opus-5 المغلق في مهام وكيلية (agentic)، يعمل فيها النموذج بنفسه مع الشيفرة والطرفية.

• DeepSWE v1.1 مجموعة مهام في هندسة البرمجيات: يعدّل الوكيل الشيفرة لإصلاح مشكلة محددة. يحل V4.1-Flash منها 74,2%. وكانت النسبة لدى V4-Flash 54,4%، ولدى Opus-5 74,0%.
• Terminal-Bench 2.1 مهام في سطر الأوامر. مقياس Pass@1، أي نسبة المهام المحلولة من المحاولة الأولى، يبلغ لدى V4.1-Flash 90,6%. وهو لدى V4-Flash 82,7%، ولدى Opus-5 89,1%.

الزيادة في DeepSWE بنحو 20 نقطة مئوية تقريبًا لافتة. وفي الاختبارين تفوق النموذج المفتوح على المغلق، مع أن الفارق في DeepSWE البالغ 0,2 نقطة يقع ضمن حدود التذبذب المعتاد.

أين تبقى الأسئلة

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

لكن هناك تحفظات. فالمؤلفون لم يعرضوا تجارب استئصال (ablation) لكل مكوّن، أي لم يعطّلوا الأساليب واحدًا تلو الآخر، ولذلك لا يتضح أيها يحقق الجزء الأكبر من التوفير. كما لا توجد منحنيات لجودة البحث في السياق عند مليون رمز كاملة. وبذلك يبقى «نافذة 1M» المعلنة مدعومة بأدلة أضعف مما ينبغي. وفي مهام علمية معقدة ضمن Terminal-Bench 4.0 يتخلف النموذج بوضوح: 31,2% مقابل 51,8% لدى Opus-5.

ومن الملفت أن V4.1-Flash تبدو، على ما يبدو، النموذج المفتوح الكبير الوحيد الذي ابتعد عن بنية decoder-only الصرفة. ولم يُرصد نهج كهذا من قبل إلا في T5Gemma ببنية المشفّر-فاك الترميز. وإذا أكدت قياسات مستقلة هذا المكسب، فقد تتبنى مختبرات أخرى فصل الحزمة إلى قراءة وتوليد.