Video Rebirth تقلّص نموذج الفيديو MiniMax-H3 من 31 إلى 14 مليار معلمة

إذا كنت تطوّر خدمة لتوليد الفيديو، فإن انتظار كل محاولة سرعان ما يتحول إلى مشكلة في تجربة استخدام المنتج. يعدّل المستخدم حركة الكاميرا، ويحصل على لقطة غير موفقة، ثم يعود إلى الانتظار. أصدرت Video Rebirth نموذج HyperFlow H3 Flash، وهو نسخة مصغّرة من MiniMax-H3 تولّد الصورة والصوت معًا. وبالنسبة إلى المطور، يتيح ذلك اختبار إمكانية تنفيذ هذه المهمة على بطاقته الرسومية الخاصة بزمن انتظار مقبول.

قلّص الفريق بنية المحوّل الرئيسية من نحو 31 إلى 14 مليار معلمة. وبالإعدادات الافتراضية، يجري التوليد في ست خطوات. ونُشرت الشيفرة والتعليمات وعمليات التكامل في مستودع المشروع. وبذلك تتوافر بالفعل مقومات تجربة تقنية: بناء نموذج أولي وقياس أدائه في مهامك الخاصة.

ما الذي جرى تقليصه تحديدًا؟

جمع الفريق بين عدة أساليب للضغط. فقد أزال بعض كتل النموذج، واستبدل ببعض العمليات المصفوفية الكبيرة عمليات أكثر اختصارًا. وطبّق أيضًا INT8: إذ تستخدم الحسابات في طبقات مختارة تمثيلًا من ثماني بتات للأوزان والقيم الوسيطة. وتقليل عدد المعلمات وخفض الدقة العددية مصدران مختلفان للتوفير.

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

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

كم يستغرق الانتظار، وأي استهلاك للذاكرة ينبغي احتسابه؟

وفق القياسات التي نشرها الفريق، تولّد حزمة Python مقطعًا مدته 5.2 ثانية خلال 92 ثانية على بطاقة RTX 5090. وتذكر القياسات دقة 1344×768 وست خطوات؛ ويشمل الزمن معالجة النص والتوليد وفك ترميز الفيديو والصوت. وهذا معيار استرشادي قدّمه مطورو المشروع، ولم نتحقق منه بصورة مستقلة. وترد الإعدادات والنتائج في جدول الأداء.

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

ومن السهل الوقوع في خطأ عند تقدير الذاكرة. يشغل ملف GGUF بصيغة Q4_K_M مساحة 9.1 غيغابايت، لكن المنظومة تحتاج إلى مكونات إضافية، منها مُرمّز النص وفاكّات الترميز. ولا يمكن اعتبار حجم ملف واحد ضمانًا لإمكانية التشغيل على بطاقة رسومية تملك سعة الذاكرة نفسها. ويقول المطورون إنهم اختبروا بطاقات بسعة 24 و32 غيغابايت، بينما لم تُجرَ قياسات على بطاقات 16 غيغابايت بعد. وتعتمد المتطلبات أيضًا على طريقة التشغيل المختارة، كما توضح تعليمات الأوزان.

ما الذي ينبغي التحقق منه قبل الدمج؟

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

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

وقبل الدمج، يجب قراءة شروط التوزيع. نُشرت الشيفرة بموجب Apache-2.0، بينما تخضع الأوزان لترخيص MiniMax-H3 Community License الموروث من النموذج الأصلي، مع قيود جغرافية؛ وتوضح ذلك بطاقة المشروع. والخطوة العملية التالية هي إعداد بيئة اختبار صغيرة، والتحقق من الجودة باستخدام مشاهدك الخاصة، ثم حساب الجدوى الاقتصادية للخدمة.