rwkv-quant: مصفوفة واحدة بصيغة bf16 تزيل 39% من خسائر التكميم في RWKV-7 2.9B

لا يزال تكميم نماذج عائلة RWKV ذات البنية الخطية المتكررة أقل دراسة مقارنةً بالمحوّلات (Transformers). لاحظ مطوّر أداة rwkv-quant، التي تضغط RWKV-7 بإعدادين مسبقين (نحو 2.1x ونحو 3.1x)، حالة شاذة: يعطي COMPRESSION الأكثر عدوانية +4.04% في البربلكسيتي (perplexity) على 2.9B، مقابل +2.85% فقط على 1.5B. وأظهر تحليل الأسباب أن جزءًا كبيرًا من الخسائر يتركز في مصفوفة واحدة بحجم 2560×2560. حفظها بصيغة bf16 يكلّف 0.5% من حجم الملف ويزيل 39% من KL.

إعدادان مسبقان وستة أحجام

تتناول الدراسة سلسلة RWKV-7 بستة أحجام. وتتيح ثلاثة أزواج فصل أثر العرض عن أثر العمق: 0.4B/1.5B (العمق نفسه والعرض أكبر بمرتين)، و2.9B/7.2B (العمق 32، والعرض 2560 مقابل 4096)، و7.2B/13.3B (العرض 4096، والعمق 32 مقابل 61).

• 0.1B: 12 طبقة، العرض 768
• 0.4B: 24 طبقة، العرض 1024
• 1.5B: 24 طبقة، العرض 2048
• 2.9B: 32 طبقة، العرض 2560
• 7.2B: 32 طبقة، العرض 4096
• 13.3B: 61 طبقة، العرض 4096

يكاد الإعداد REDUCTION يخلو من الخسائر: الإسقاطات بدقة 8 بت بتوزيع متماثل ومجموعات من 16 وزنًا، وcmix (FFN) بدقة 6 بت، والتضمين ورأس الإخراج بدقة 8 بت. أما COMPRESSION فهو أكثر عدوانية: الإسقاطات بدقة 4 بت بتوزيع غير متماثل على كتل فائقة (superblock) ومجموعات من 32، وcmix بدقة 4 بت (وffn.key بدقة 5)، ورأس الإخراج بدقة 5 بت، والتضمين بدقة 6 بت. وفي الإعدادين كليهما تُكمَّم فروع LoRA بدقة 6 بت (وg بدقة 8). ويُختار مقياس المجموعات وإزاحتها في الحالتين عبر بحث موزون بمتوسط مربع تنشيط مدخل القناة E[x²].

أين ينكسر 2.9B

أظهر تحليل KL حسب مجموعات المصفوفات بطريقة leave-one-out أن o_proj يسهم بـ 46% من إجمالي KL في 2.9B، والتضمين بـ 17%. أما في 1.5B فنسبتا المساهمة 16% و3%، ويأتي الإسهام الرئيسي من cmix.value (37%). وداخل o_proj تعود 85–86% من الضرر إلى مصفوفة واحدة، هي الإسقاط الخارج للكتلة الصفرية.

وأكدت تجربة مباشرة على 2.9B (المسار الفعلي، MLX) ذلك:

• الإعداد الأساسي: KL 0.052048، و+4.04% في ppl؛
• o_proj في الطبقة 0 بصيغة bf16: KL 0.031966، و+2.43% في ppl، والملف أكبر بمقدار 9.4 ميغابايت؛
• o_proj في الطبقة 31 بصيغة bf16: لا أثر (+4.07%)؛
• كل o_proj بدقة 5 بت: +3.54%، و+26.2 ميغابايت؛
• كل o_proj بدقة 6 بت: +2.89%، و+52.4 ميغابايت.

مصفوفة واحدة بصيغة bf16 تعطي نتيجة أفضل من رفع كل o_proj إلى 6 بت، وتكلّف أقل بأكثر من خمسة أضعاف. وفي الأحجام الأخرى يكون الأثر أضعف: ينخفض KL بنسبة 7.6% على 0.1B، و1.5% على 0.4B، و0.4% على 1.5B، و3.9% على 7.2B. ولا يُعدّ الأثر ذا دلالة إلا في 0.1B و2.9B.

يحمل مدخل هذه المصفوفة «قناة ضخمة». ففي 2.9B تستحوذ ثماني قنوات على 98% من الطاقة، ويتطابق رقم القناة 517 في سلسلتين من نقاط الحفظ (checkpoints)، أما في 1.5B فهي القناة 1202. أي أن القناة تتحدد بالعرض والبنية، لا بعملية تدريب بعينها. لكن قوة القناة لا تتنبأ بالضرر: فتركّز الطاقة في 7.2B هو الأعلى (99%)، بينما KL الأساسي فيه هو الأدنى (0.023 مقابل 0.078 في 2.9B). ومن دون تأثير AW في الأوزان، تدمّر 4 بت في o_proj نموذج 2.9B: KL 0.340، و+37.2% في ppl.

ويبيّن المؤلف أن ثلاثة مقاييس محلية طبيعية للخطأ لا تتنبأ بالضرر. أما المقياس الذي نجح فهو الخطأ في التدفق المتبقي (residual stream) مضروبًا في التضخيم المقيس.

تسرّب المعايرة والقياسات النزيهة

كانت مجموعة التقييم الأولى (38 نافذة من 512 رمزًا، en/ru/sr) داخل مجموعة المعايرة بالكامل: نسبة 16-غرامات المشتركة 100%. وقيس حجم التسرّب على GPTQ. ففي 1.5B بلغ المكسب في KL ‏−61.8% على المجموعة القديمة و−27.1% على المجموعة النظيفة، أي أن التسرّب ضخّم النتيجة 2.3 مرة. أما الاختيار التلقائي لعدد البتات فلم يحقق مكسبًا عليها: ‏−16.1% مقابل −17.6%.

لذلك تعتمد الأقسام 7–10 من الدراسة مجموعات نظيفة فقط: ويكيبيديا en/ru/sr (36 نافذة)، ومجموعة مغلقة من أكواد Python/Swift (24 نافذة)، ومجموعة مفتوحة (48 نافذة). وتُبنى فترات الثقة بطريقة بوتستراب مزدوج (paired bootstrap) على النوافذ، بـ 20 000 تكرار، ويبلغ نصف عرض فترة الثقة 95% لقيمة KL ما بين 7% و12% من القيمة.

وفوق ذلك تصف الدراسة الاختيار التلقائي لعدد البتات وفق قاعدة «الضرر لكل بايت»، وهي تعمل في الاتجاهين، وكذلك GPTQ على شبكة الإعداد المسبق من دون تغيير الصيغة أو النوى (kernels) أو حجم الملف. وتتراكم هذه الطرق بصورة شبه ضربية. وتُعرض بشكل منفصل مقارنة مع GGUF وMLX عند حجم الملف نفسه.

والخلاصة العملية بسيطة. إذا كنت تكمّم RWKV-7 للتشغيل المحلي، خصوصًا على Mac عبر MLX، فاحتفظ بـ o_proj في الطبقة الأولى بصيغة bf16: وهذا يعني 6–10 ميغابايت في نماذج 1.5B–2.9B. ويُفضَّل ألا تقل دقة التضمين عن 6 بت. وقبل الوثوق بأرقام طريقة تعتمد على المعايرة، تحقق من انعدام تقاطع 16-غرامات بين نص المعايرة ونص التقييم. ومن الأفضل قياس إسهام كل مجموعة مصفوفات بطريقة leave-one-out بدلًا من افتراض أن الخسائر في النموذج الكبير ستتوزع بالتساوي.