الانتقال إلى المحتوى
سايبرتاك.
الهواتف والأجهزة· ٢ دقائق قراءة

EdgeLLM-Nano وجد أن ضغط KV-cache أضر بنموذج حجمه 33.6 MB

اعتمد الاختبار على نموذج فيه 8.39M معلمة واختبار LCDF جديد لمقارنة طرق التخزين المؤقت كلمة بكلمة.

بقلم Cyberttakنُشر · 04:02
شريحة معالج MediaTek MT6582V على لوحة دوائر إلكترونية زرقاء
شريحة معالج MediaTek MT6582V على لوحة دوائر إلكترونية زرقاءالمصدر: Photo: Raimond Spekking / Wikimedia Commons · CC BY-SA 4.0 (cropped)

اختبر EdgeLLM-Nano ضغط KV-cache على نموذج لغوي صغير يعمل على الجهاز، وخلص إلى أن عدة حيل شائعة لم تكن مفيدة كما يبدو.

الاختبار استخدم transformer من نوع decoder-only فيه 8.39M معلمة، أي 33.6 MB، حتى يمكن فحص الأداء من البداية إلى النهاية على عتاد الحافة.

LCDF فصَل بين الطرق عبر إحصاءات مزدوجة عبر seeds مختلفة وحجوم الأثر.

تقول الورقة إن طرق التقييم القديمة قد تتجاهل KV-cache نفسه، وهذا يجعل المقارنات تبدو أفضل مما هي عليه فعلاً.

أحد النتائج كان قاسياً مع quantizer يعتمد على polar-guided key-cache. ويذكر المؤلفون أن وضع round-to-nearest كمرجع ألحق ضرراً أقل بنحو 10 مرات.

وظهر النمط نفسه في pruning. فـ consistency-anchored progressive weight pruner لم يتفوق على one-shot magnitude-based pruning، وأحياناً ساواه فقط.

ولقياس الجودة بشكل أدق، قدمت الورقة اختبار Long-Context Decode Fidelity أو LCDF. هذا الاختبار يقيس loss كلمة بكلمة أثناء استخدام الـ KV-cache قيد الاختبار.

وهذا مهم لأن perplexity أعطى كل الطرق الدرجة نفسها، 5.461. أما LCDF ففصل بينها عبر إحصاءات مزدوجة عبر عدة seeds وحجوم الأثر.

كما جرى اختبار الطاقة على Raspberry Pi 5. وكل طرق الضغط التي اختبرت استهلكت طاقة لكل token أعلى من FP16 inference غير المضغوط.

وكان KIVI الأقرب إلى السلوك شبه الخالي من الخسارة وفق LCDF، لكن الرسالة العامة هي أن ضغط KV-cache ما زال يحتاج تحسيناً. أيهما تثق به أكثر على جهاز صغير: رقم perplexity واحد أم اختبار كلمة بكلمة ينظر فعلاً إلى الـ cache؟

الحد الذي يظهره المصدر أن هذا ليس إطلاق منتج، كما أنه لا يذكر سوى الطرق والأجهزة التي اختبرت في هذه الدراسة القياسية.

المصدر: arXiv cs.CL