RedOneX

التقرير الثالث من 53.6 إلى 110.78 توكن بالثانية كيف تغير أداء Qwen3.8-27B بعد إعادة هندسة MTP على 16GB VRAM في التقريرين السابقين انتهيت إلى نقطة واضحة بعد تجربة Qwen3.8-27B بإصدارات مختلفة من التكميم أصبحت نسخة UD-IQ3_XXS هي الإعداد العملي الذي اعتمدته للتشغيل المحلي لم يعد السؤال بالنسبة لي: هل يمكن تشغيل نموذج 27B على بطاقة 16GB؟ ولا هل IQ3 أفضل من IQ4 على هذا الجهاز؟ هذه النقاط حُسمت في الاختبارات السابقة السؤال الجديد أصبح هل يمكن استثمار المساحة التي وفرها IQ3 ليس فقط في إبقاء النموذج على الـGPU بل في مضاعفة سرعة التوليد نفسها؟ ومن هنا بدأت المرحلة الجديدة من التجربة ━━━━━━━━━━━━━━━━━━ 1. نقطة البداية ━━━━━━━━━━━━━━━━━━ الإعداد الذي انتهيت إليه سابقًا كان يحقق تقريبًا التوليد: 53.6 توكن مع تشغيل طبقات FFN على الـGPU وعدم الاعتماد على CPU FFN Offload هذه أصبحت نقطة الأساس الجديدة وبدل العودة إلى تغيير التكميم أو التضحية بالسياق ركزت هذه المرة بالكامل على مسار التوليد نفسه وتحديد الـMTP (Multi Token Prediction) الفكرة ببساطة أن النموذج لا يحاول اعتماد توكن واحد فقط في كل دورة بل يمكنه اقتراح عدة توكنات مستقبلية والتحقق منها دفعة واحدة نظريًا هذه الطريقة تستطيع رفع سرعة فك الرموز بشكل كبير لكن الاختبار الحقيقي أثبت أن المسألة أصعب من مجرد رفع قيمة Draft Tokens ━━━━━━━━━━━━━━━━━━ 2. أول مشكلة: نتائج البنش مارك لم تنتقل إلى هيرمس ━━━━━━━━━━━━━━━━━━ في الاختبارات المنفصلة ظهرت نتائج MTP مرتفعة جدًا لكن عند نقل نفس الفكرة إلى استخدام وكيل هيرمس على التيرمنال ظهرت مشكلة كبيرة مع MTP11 على البناء القديم من llama.cpp انخفضت نسبة قبول Draft Tokens في بعض الجلسات إلى حدود 18–21% وبدل أن ترتفع السرعة أصبحت الاستفادة من MTP ضعيفة وغير مستقرة في تلك المرحلة كانت السرعات الواقعية في أجزاء كثيرة من الجلسة تدور حول 41–53 توكن بالثانية أي أن الأرقام العالية التي ظهرت في الاختبارات البنش مارك لم تكن تعكس أداء الوكيل الحقيقي وهذه كانت نقطة مهمة جدًا في التجربة بنش مارك ناجح لا يعني بالضرورة أن نفس الإعداد ناجح داخل وكيل فعلي هيرمس يرسل سياقات طويلة System Prompts، أدوات، وسجل محادثة متغير باستمرار وهذا يغير سلوك MTP جذريًا ━━━━━━━━━━━━━━━━━━ 3. الـMTP6 كان أكثر استقرارًا… لكنه لم يكن النهاية ━━━━━━━━━━━━━━━━━━ بعد تقليل عمق MTP إلى 6 Draft Tokens تحسن الاستقرار في الاستخدام الفعلي داخل هيرمس وصل الأداء إلى متوسط يقارب: 59.5 توكن بالثانية وهذا كان بالفعل أسرع من نقطة الأساس السابقة البالغة 53.6 توكن بالثانية لكن الزيادة كانت محدودة نسبيًا لذلك لم أعتبر MTP6 نهاية التجربة المشكلة لم تكن في فكرة MTP نفسها بل في أن العمق الأعلى لم يكن يعمل بكفاءة كافية على البناء الذي كنت أستخدمه ━━━━━━━━━━━━━━━━━━ 4. تغيير المحرك غيّر النتيجة ━━━━━━━━━━━━━━━━━━ بدل الاستمرار في تعديل النموذج أو إعادة التكميم إنتقلت إلى نسخة أحدث من upstream llama.cpp وبنيت نسخة CUDA جديدة مخصصة لـBlackwell SM120 وهنا ظهر الفرق الحقيقي. بعد تحديث البناء MTP11 الذي كان يعاني سابقًا من انهيار كبير في Draft Acceptance بدأ يحقق نسب قبول مرتفعة جدًا على وكيل هيرمس في أجزاء متعددة من الجلسة ظهرت نسب 80% 90% وأكثر من 94% وهذا كان التحول الأساسي في المرحلة الجديدة لم يتغير النموذج ولم يتغير التكميم الذي تغير هو كفاءة مسار التنفيذ نفسه ━━━━━━━━━━━━━━━━━━ 5. البحث عن نقطة استقرار لـMTP11 ━━━━━━━━━━━━━━━━━━ بعد ذلك اعتمدت إعدادًا أكثر تحفظًا بدل السماح لـMTP11 بالعمل بدون حدود الـMaximum Draft 11 الـMinimum Draft 3 الـMinimum Probability 0.70 الـBackend Sampling الـON الفكرة كانت أن MTP لا يحتاج أن يجبر نفسه على إنتاج 11 توكن في كل مرة إذا كانت الثقة منخفضة يستطيع الاكتفاء بسلسلة أقصرالنتيجة كانت تحسنًا واضحًا في الاستخدام الحقيقي. ومع إعداد الـBatch 1024 الـUBatch 256 وصلت إحدى استجابات هيرمس إلى 90.28 توكن بالثانية لأول مرة أصبحت المسافة إلى حاجز 100 توكن بالثانية صغيرة جدًا ━━━━━━━━━━━━━━━━━━ 6. التغيير الذي كسر حاجز 100 ━━━━━━━━━━━━━━━━━━ في المرحلة التالية لم أغير إعدادات MTP غيرت عاملًا واحدًا فقط الـBatch 1024 → 2048 الـUBatch 256 → 512 وهنا حصلت أكبر قفزة في التجربة داخل وكيل هيرمس تم تسجيل 101.94 توكن بالثانية مع: الـDraft Acceptance 88.46% الـMean Draft Length 8.36 ثم جاءت أفضل نتيجة حتى الآن 110.78 توكن بالثانية مع: الـDraft Acceptance 94.15% الـMean Draft Length 10.19 وفي استجابة أخرى وصلت السرعة إلى 99.03 توكن بالثانية مع نسبة قبول تقارب 94.15% وبذلك تم كسر حاجز 100 توكن بالثانية 💪 فعليًا داخل وكيل هيرمس على التيرمنال وليس داخل بنش مارك ━━━━━━━━━━━━━━━━━━ 7. ماذا يعني رقم 110.78 فعلًا ━━━━━━━━━━━━━━━━━━ من المهم هنا عدم تقديم الرقم بطريقة مضللة 110.78 توكن بالثانية هو الـPeak كامل لاستجابة حقيقية داخل وكيل هيرمس وليس متوسطًا ثابتًا لكل الاستجابات السيرفر كان مضبوط على Context Capacity قدره 81.920 توكن لكن الاستجابة التي حققت 110.78 توكن بالثانية كانت تعمل عند سياق فعلي يقارب 28.3 ألف توكن وهذا فرق مهم الأهم من رقم القمة نفسه أن الاختبارات كشفت علاقة واضحة جدًا بين MTP Acceptance والأداء عندما وصل Draft Acceptance إلى قرابة 94% ومع Mean Draft Length قريب من 9–10 توكنات أصبح الأداء في نطاق 99–111 توكن بالثانية أما عندما ينخفض Acceptance إلى حدود 55–65% وتصبح سلاسل Draft أقصر، في حدود 4–5 توكنات فإن السرعة تعود غالبًا إلى نطاق 40–50 توكن بمعنى آخر: الـMTP11 لا يمنح سرعة ثابتة إنه يرفع السقف الأعلى للأداء بشكل ضخم عندما يستطيع التنبؤ بسلسلة طويلة وصحيحة من التوكنات. ━━━━━━━━━━━━━━━━━━ 8. من 53.6 إلى 110.78 ━━━━━━━━━━━━━━━━━━ لو قارنت أعلى نتيجة بالسرعة الأساسية التي إنتهيت إليها في التقرير السابق 53.6 توكن بالثانية → 110.78 توكن بالثانية فالقفزة في Peak Performance بلغت تقريبًا +106.7% أي 2.07× تقريبًا على نفس النموذج ونفس التكميم وهذا بالنسبة لي هو أهم ما في النتيجة الزيادة لم تأتِ من الانتقال إلى GPU أكبر ولا من نموذج أصغر ولا من تقليل حجم النموذج مرة أخرى بل من تحسين طريقة تنفيذ Decode والاستفادة من MTP. ━━━━━━━━━━━━━━━━━━ 9. هل النتيجة مرتبطة بـهيرمس ━━━━━━━━━━━━━━━━━━ بعد الوصول إلى أكثر من 100 توكن بالثانية داخل هيرمس أردت اختبار واجهة مختلفة على نفس llama server لهذا استخدمت Open WebUI الهدف لم يكن معرفة أي واجهة "أسرع" بشكل سطحي بل معرفة هل الأداء الذي حققناه مرتبط بهيرمس نفسه أم أن نفس Backend يستطيع الحفاظ على أدائه مع عميل آخر ━━━━━━━━━━━━━━━━━━ 10. الـOpen WebUI بدون وكيل هيرمس ━━━━━━━━━━━━━━━━━━ بعد تشغيل Open WebUI بصورة معزولة وإعادة تشغيل llama server بحالة نظيفة سجلت ثلاث استجابات طويلة متتالية 56.86 توكن بالثانية 55.91 توكن بالثانية 58.22 توكن بالثانية المتوسط 56.997 توكن بالثانية أي تقريبًا 57 توكن بالثانية واللافت أن السياق استمر في النمو خلال المحادثة 561 برومت توكن ثم: 3.057 ثم: 5.844 ومع ذلك بقي متوسط Decode قريبًا جدًا من 56–58 توكن بالثانية وهذا أعطى إستقرار كما ظهر أثناء إحدى الاستجابات Peak لحظي لثلاث ثوانٍ بلغ 111.16 توكن بالثانية لكن متوسط الاستجابة الكاملة بقي 58.22 توكن بالثانية وهنا يظهر مرة أخرى الفرق بين الـInstantaneous Throughput وبين: الـFull response Average ━━━━━━━━━━━━━━━━━━ 11. لماذا كان Open WebUI أحيان أبطأ؟ ━━━━━━━━━━━━━━━━━━ في أول استجابة نظيفة لـOpen WebUI وصلت السرعة إلى 37.24 توكن بالثانية لكن Draft Acceptance كان منخفضًا 49.14% وعندما ارتفع Acceptance في الاستجابات التالية إلى قرابة 63–65% إستقر الأداء حول 56–58 توكن بالثانية وهذا يعزز النتيجة التي ظهرت داخل هيرمس نوع النص وشكل برومت يؤثران مباشرة على نجاح MTP لذلك لا يمكن أخذ رقم واحد من هيرمس ورقم واحد من أوبن ويب يو إيِ والقول إن إحدى الواجهتين أسرع من الأخرى الواجهة تغير الـSystem Prompt الـConversation History الـTool Definitions الـFormatting وكل ذلك يغير احتمالية نجاح Draft Tokens ━━━━━━━━━━━━━━━━━━ 12. المفاجأة الحقيقية تشغيل وكيل هيرمس وأوبن ويب يو إيِ معًا ━━━━━━━━━━━━━━━━━━ أثناء الاختبار ظهر اكتشاف لم أكن أبحث عنه أصلًا لاما سيرفر المستخدم في التجربة يعمل بـ الـ1 Slot الـParallel = 1 عندما كان أوبن ويب يو إيِ يعمل بدون وكيل هيرمس ≈57 توكن بالثانية لكن بعد إعادة تشغيل Hermes Gateway واستخدام Hermes وOpen WebUI على نفس السيرفر حدث انخفاض حاد ظهر أولًا طلب Hermes بسياق يقارب الـ26,022 Prompt Tokens وكان Prompt Processing لا يزال سريعًا ≈1,381 توكن بعده مباشرة جاء طلب Open WebUI والنتيجة: 15.86 توكن ثم ظهر طلب صغير إضافي من Open WebUI وانخفض إلى 11.51 توكن مقارنة بمتوسط Open WebUI المنفرد ≈57 توكن فالانخفاض في الاستجابة الرئيسية بلغ تقريبًا 72% أو: 3.6× أبطأ ━━━━━━━━━━━━━━━━━━ 13. الغريب أن MTP لم يكن المتهم هذه المرة ━━━━━━━━━━━━━━━━━━ هذه النتيجة كانت مثيرة لأن طلب Open WebUI الذي انخفض إلى 15.86 توكن كان لديه Draft Acceptance 69.8% أي أعلى من بعض الاستجابات التي كانت تعمل أسرع بكثير لذلك لا يمكن تفسير هذا الانخفاض بمجرد ضعف MTP Acceptance كما أن فحص WSL وقت المشكلة أظهر الـSwap Used 0 والذاكرة المتاحة داخل WSL كانت كبيرة لذلك لا يوجد دليل على أن النظام دخل Swap أو نفدت منه RAM الرئيسية في المقابل كان llama server يعمل على سلوت واحد فقط وكانت الواجهتان ترسلان أنماط سياق مختلفة جدًا إلى نفس Runtime كما ظهر أن Open WebUI يرسل طلبات صغيرة إضافية بعد بعض الردود على الأرجح لمهام خلفية مرتبطة بالواجهة. حتى الآن لا أعتبر السبب الجذري محسومًا بشكل نهائي لكن التجربة أثبتت شيئًا عمليًا بوضوح: تشغيل Hermes وOpen WebUI بالتناوب على نفس llama server ذا سلوت واحد قادر على إدخال السيرفر في حالة أداء سيئة جدًا وبمجرد عزل الخدمات وإعادة تشغيل السيرفر عاد Open WebUI إلى نطاقه الطبيعي قرب 57 توكن ━━━━━━━━━━━━━━━━━━ 14. ماذا تعلمت من هذه المرحلة؟ ━━━━━━━━━━━━━━━━━━ التجربة بدأت كسؤال عن كيفية تجاوز 53.6 توكن بالثانية لكنها انتهت إلى نتيجة أوسع بكثير أولًا: أداء نموذج محلي لا يحدده حجم النموذج والتكميم فقط طبقة Runtime نفسها تستطيع تغيير النتيجة بأكثر من الضعف ثانيًا: نتائج Speculative Decoding يجب اختبارها داخل workload حقيقي الـMTP11 كان رائعًا في الاختبارات بنش مارك وفشل في أول تجربة مع وكيل هيرمس ثم تحول بعد تحديث المحرك وضبطه إلى أسرع إعداد اختبرته ثالثًا: الـDraft Acceptance وحده لا يكفي الـMean Draft Length مهم جدًا أيضًا نجاح عشر توكنات تقريبًا في الدورة الواحدة هو ما جعل الوصول إلى أكثر من 100 توكن بالثانية ممكن رابعًا: الـPeak Performance وSustained Performance رقمان مختلفان أفضل نتيجة 110.78 توكن لكن الأداء المستمر يتغير حسب طبيعة النص ونجاح MTP خامسًا: الـClient نفسه ليس مجرد واجهة رسومية طريقة بناء برومت وإدارة السياق والطلبات الخلفية يمكن أن تغير حالة Backend وسلوكه بصورة ملموسة ━━━━━━━━━━━━━━━━━━ 15. أين وصلت التجربة الآن؟ ━━━━━━━━━━━━━━━━━━ في التقرير السابق كانت النتيجة الأساسية الـQwen3.8-27B IQ3 ≈53.6 توكن بالثانية اليوم أصبحت النتيجة الـReal Hermes Peak 110.78 توكن بالثانية الـ 100+ توكن بالثانية تم تحقيقها الـOpen WebUI isolated: ≈57 توكن بالثانية مستقرة الـPrompt Processing في السياقات الكبيرة ≈1.300–1.500 توكن بالثانية والأهم: تم تحديد مشكلة أداء منفصلة تظهر عند مشاركة Hermes وOpen WebUI لنفس llama server ذا سلوت واحد ━━━━━━━━━━━━━━━━━━ الخلاصة ━━━━━━━━━━━━━━━━━━ بعد التقريرين السابقين لم أعد أحاول إثبات أن نموذج 27B يمكن تشغيله على بطاقة 16GB هذه المرحلة انتهت التحدي أصبح كم يمكن استخراج أداء إضافي من نفس النموذج ونفس العتاد؟ والنتيجة الحالية هي أن سرعة التوليد التي بدأت عند 53.6 توكن بالثانية استطاعت الوصول في استجابة حقيقية داخل هيرمس إلى 110.78 توكن بالثانية أي زيادة في Peak Performance تقارب 106.7% بدون تغيير النموذج أو الانتقال إلى تكميم أصغر لكن النتيجة الأهم من رقم 110.78 نفسه هي أن الاختبارات كشفت أين أصبح عنق الزجاجة الجديد لم يعد السؤال هل النموذج يدخل في VRAM؟ بل أصبح: كيف نحافظ على MTP Acceptance مرتفعًا؟ كيف نحافظ على Draft Length طويلًا؟ كيف ندير KV/runtime بين أنواع السياقات المختلفة؟ وكيف نمنع عميلًا من التأثير في حالة العميل الآخر؟ بمعنى آخر: بعد أن كانت المرحلة السابقة عبارة عن هندسة ذاكرة وتشغيل النموذج داخل 16GBأصبحت المرحلة الحالية هندسة لمسار الاستدلال نفسه وهذا بالنسبة لي هو التطور الحقيقي في التجربة #تقنية