ماذا يخبرنا معدل 2,122 رمزًا في الثانية، وما الذي لا يكشفه؟

في 27 سبتمبر، نشرت NaiveAI مقالها التقني عن Naive-N0.5-Flash. ووفقًا لما أعلنته، يصل NaiveRT، المحسّن لفك ترميز تدفق واحد أثناء توليد مسارات التعلم المعزز (RL rollouts)، إلى 2,122 رمزًا في الثانية باستخدام نموذج DFlash أولي مدمج لفك الترميز التخميني. ولشروط القياس أهميتها: ثماني وحدات GPU، وأفضل نافذة مدتها ثانية واحدة من بين 41 طلبًا بصيغتي HTML وSVG، مع تعطيل وضع التفكير واستبعاد مرحلة المعالجة الأولية للمدخلات (prefill). هذا قياس أعلن عنه المطوّر نفسه، ولم تُعد SlateMoth إنتاجه بصورة مستقلة. [1]

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

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

لنفترض مهمة تعديل برمجي تستغرق فيها قراءة المشروع والوصول إلى أول مخرجات 12 ثانية، ويستغرق التوليد 8 ثوانٍ، والاختبارات 40 ثانية. حتى لو أصبح التوليد أسرع أربع مرات، فلن ينخفض الإجمالي إلا من 60 إلى 54 ثانية، أي توفير بنسبة 10%. هذه أرقام توضيحية وليست قياسات أجرتها NaiveAI. لذا ينبغي معرفة أين يُستهلك الوقت قبل تعميم زيادة السرعة المعلنة على سير العمل كله.

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

تذكر بطاقة النموذج أن إجمالي معاملاته يبلغ 309 مليارات، منها 15.5 مليار معامل نشط. ووفق إرشادات نشره بدقة FP8، تشغل الأوزان نحو 315 GB، ويتطلب الاستدلال ذاكرة إضافية على وحدات GPU. وتذكر البطاقة أيضًا أن تصميم الانتباه المتناثر يحتفظ بذاكرة KV المؤقتة كاملة. تمنع هذه التفاصيل سوء فهم شائعًا: لا يعني عدد المعاملات النشطة أن النموذج الكامل يتسع في مقدار الذاكرة الذي يحتاج إليه نموذج كثيف بهذا الحجم. [2]

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

هناك حد لما كان منشورًا ويجب توضيحه. يصف المقال التقني NaiveRT بأنه مفتوح المصدر، لكنه يقول أيضًا إن محتوى الشيفرة المصدرية المشار إليه سيتاح بحلول 12 أكتوبر. وعند تحققنا في 28 سبتمبر، أعاد مستودع NaiveRT المرتبط بالمقال الرمز 404. لذلك لم نتمكن من فحص بيئة التشغيل والبرامج النصية لاختبارات الأداء في ذلك العنوان. وهذا لا يثبت أن النتيجة خاطئة أو أن أوزان النموذج غير متاحة؛ بل يحد فقط مما استطعنا التحقق منه وقت الفحص. [1] [3]

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

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

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

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

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