CacheScope يسرّع نماذج الانتشار حتى 3,57x ويخفض LPIPS بنسبة 70%

اقترح فريق من مؤلفي ورقة بحثية على arXiv طريقة CacheScope، وهي طبقة إضافية فوق تخزين الميزات مؤقتًا في محوّلات الانتشار. تسرّع الطريقة الاستدلال (inference) حتى 3,57 مرة، وتخفض وسيط LPIPS إلى 70,1% مقارنة بأقوى طريقة أساسية قائمة على المجسّات. أُجريت الاختبارات على ثلاثة نماذج: FLUX.1-dev للصور، وWan2.1-T2V-1.3B وOpen-Sora 1.2 للفيديو. ولا تحتاج الطريقة إلى إعادة تدريب ولا إلى تدرجات ولا إلى شبكات مساعدة.

أين يتعثر تخزين الميزات مؤقتًا

منطق التسريع دون تدريب (training-free) بسيط. في خطوات مختارة من إزالة الضوضاء (denoising) لا يحسب النموذج جميع الكتل، بل يستبدل بها تقريبًا مأخوذًا من كاش جُمع في الخطوات السابقة. وانصبّ جهد الباحثين حتى الآن على استعادة الميزات المتخطّاة بدقة أكبر، أي على ابتكار مُعيدات بناء (reconstructors) أكثر تعقيدًا.

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

إشارة الخطر بدل التباين الخام

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

الحل هو التطبيع (normalization). يُقسم تباين خرج المجسّ على انزياح المدخل المقابل له، فينتج معامل تضخيم اتجاهي لكل وحدة حركة في المسار. وهذا المعامل هو المؤشر المعتمد.

استنادًا إليه، يرصد CacheScope أثناء التشغيل (online) الخطوات التي يرتفع فيها خطر إعادة استخدام الكاش، ويتحول فيها إلى الحساب الكامل. ويبقى مُعيد بناء الكاش على حاله. وتستغني الطريقة عن التدرجات والتدريب الإضافي والشبكات المساعدة، وعن تحسين الجدول الزمني خارج الاتصال (offline) لكل prompt بعينه.

ما المعلن بالأرقام

• التسريع: حتى 3,57x مقارنة بإزالة الضوضاء الكاملة.
• الجودة: وسيط LPIPS أقل حتى 70,1% مقارنة بأقوى طريقة أساسية قائمة على المجسّات.
• النماذج: FLUX.1-dev وWan2.1-T2V-1.3B وOpen-Sora 1.2.
• المتطلبات: دون تدريب أو تدرجات أو شبكات مساعدة أو جداول زمنية خاصة بكل prompt.
• مُعيد بناء الكاش: دون تغيير، وتُضاف الطريقة فوق ما هو قائم.

صياغة «حتى» مهمة. فالأرجح أن أقصى تسريع وأفضل تحسّن في LPIPS يخصّان نماذج وأنماط تشغيل مختلفة. ولا يتضح من الملخص أي عتاد استُخدم، ولا كيف تتغير الأرقام مع إعدادات أكثر تحفظًا. وهذه نسخة أولى من ورقة بحثية (preprint)، لم تخضع لمراجعة الأقران ولا لإعادة إنتاج مستقلة.

ما الذي ينبغي اختباره عمليًا

بالنسبة إلى الفرق التي تطبّق تخزين الميزات مؤقتًا على FLUX أو نماذج الفيديو، ثمة تفصيل معماري لافت: CacheScope لا يستبدل مُعيد البناء، بل يقرر متى لا يجوز استخدامه. وهذا يتيح نظريًا ربطه بخط المعالجة (pipeline) الحالي دون إعادة كتابة الكاش، ودون مرحلة معايرة منفصلة لكل prompt.

قبل الاعتماد على الطريقة، يُستحسن التحقق من ثلاثة أمور. أولًا، مقارنتها بالكاش الذي تستخدمونه حاليًا على prompts حقيقية، وليس بمقياس LPIPS وحده: فالمقياس مفيد لكنه لا يغني عن التقييم البصري. ثانيًا، قياس التكلفة الإضافية للمجسّ وللقرارات أثناء التشغيل على عتادكم، لأن المكسب النهائي يتحدد بها. ثالثًا، مراقبة السلوك عند أطوال مختلفة للمسار وأعداد مختلفة للخطوات. وهذا بالغ الأهمية في الفيديو، حيث تتراكم العيوب البصرية (artifacts) من إطار إلى آخر.

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