vLLM V1: إصلاح الأخطاء قبل تحسين الخوارزمية

المشكلة: V1 كانت غير صحيحة

ملي vLLM انتقلات من الإصدار V0 لـ V1 (إعادة كتابة كاملة للمحرك)، الفريق بدا يشتغل على نفس الخدمة: تدريب نماذج AI باستعمال Reinforcement Learning (التعلم بالتعزيز). الفكرة بسيطة: تشغيل النموذج، جمع النتائج (rollouts)، وتحسين الخوارزمية بناءً على المكافآت.

ولكن المشكلة كانت: V1 كانت كتعطي نتائج مختلفة من V0، حتى مع نفس البيانات ونفس الإعدادات. الرسوم البيانية كانت واضحة:

• المحاولة الأولى (الخط الأحمر): كارثة. كل المقاييس كانت غير صحيحة.
• المحاولة النهائية (الخط الأخضر): تطابق تام مع V0.

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

الدرس الأساسي: فصل المشاكل

الفريق اتبع استراتيجية واضحة:

1. أولا: تأكد إن V1 كترجع البيانات اللي المدرب (trainer) كيتوقع
2. ثانيا: شغل نفس الشغل على V0 كمرجع
3. ثالثا: غير الخوارزمية غير بعد ما تكون متأكد من الأساسيات

هاد الترتيب مهم بزاف. السبب؟ إيلا ضفتي تصحيح على نظام معطوب، غادي تخلطي بين مشكلتين:

• "واش المحرك كيرجع البيانات الصحيحة؟"
• "واش الخوارزمية صحيحة؟"

لما تخلطهم، الرسوم البيانية كتصير لغز.

الإصلاح الأول: المعنى ديال الأرقام

vLLM V1 كانت كترجع logprobs (احتمالات اللوغاريتم)، اللي هي أرقام كتمثل احتمالات الكلمات. لكن المشكلة:

• V1 كترجع logprobs من النموذج الخام (قبل أي معالجة)
• المدرب كيتوقع logprobs من النموذج المعالج (بعد temperature scaling، penalties، إلخ)

الحل كان سطر واحد فالإعدادات:

<bdi>logprobs_mode</bdi>: <bdi>processed_logprobs</bdi>

هاد الإصلاح شال الفرق الأساسي. لكن الرسوم البيانية كانت لسه غير متطابقة تماما. يعني كاين شي حاجة ثانية غلط.

الإصلاح الثاني: سلوك التشغيل

V1 كانت كتستعمل إعدادات جديدة اللي ما كانتش فـ V0:

• Prefix caching: تخزين مؤقت للأجزاء المتكررة من النص (بحال مراجع الكتب — إيلا قرأت نفس الفصل مرتين، ما خاصكش تقرا مرة ثانية)
• Async scheduling: جدولة غير متزامنة (بحال طلب عدة أشياء فنفس الوقت بدل ما تنتظر واحد باش يخلص)

فـ online RL (التدريب على البيانات الحية)، هاد الأشياء كانت كتخلق مشاكل:

• الـ prefix cache كيقدر يستعمل بيانات قديمة حتى بعد ما النموذج تحدث
• الـ async scheduling كتخلي الطلبات كتشتغل بسرعات مختلفة

الحل: تعطيل هاد الميزات للمقارنة:

<bdi>enable_prefix_caching</bdi>: <bdi>false</bdi>
<bdi>async_scheduling</bdi>: <bdi>false</bdi>

هاد ماشي "أفضل" — هاد "متطابق مع V0".

الإصلاح الثالث: تحديث الأوزان

فـ online RL، النموذج كيتحدث كل شوية (يعني الأوزان كتتبدل). المشكلة:

• V0 كانت كتعمل حاجة بسيطة: توقف التنفيذ، حمل الأوزان الجديدة، استمر (بدون حذف الذاكرة المخبأة)
• V1 كانت كتفعل حاجة مختلفة: حذف الذاكرة، أو تنتظر بطريقة غير متطابقة

الحل: مطابقة سلوك V0 بالضبط:

<bdi>await engine.pause_generation</bdi>(<bdi>mode</bdi>="<bdi>keep</bdi>", <bdi>clear_cache</bdi>=<bdi>False</bdi>)
<bdi>await engine.receive_weight_update</bdi>(...)
<bdi>await engine.resume_generation</bdi>()

التفاصيل مهمة:

• <bdi>mode</bdi>="<bdi>keep</bdi>": ما تحذفش الطلبات قيد التنفيذ
• <bdi>clear_cache</bdi>=<bdi>False</bdi>: ما تحذفش الذاكرة المخبأة

الإصلاح الرابع: دقة الأرقام

هاد الإصلاح الأخير كان الأدق. المشكلة:

• المدرب كان كيستعمل fp32 (أرقام بدقة 32 بت) لـ lm_head (الطبقة الأخيرة اللي كتحول الأرقام لاحتمالات)
• V1 كانت كتستعمل fp16 أو bfloat16 (دقة أقل، أسرع لكن أقل دقة)

الفرق بدو صغير، لكن فـ RL كيصير كبير. السبب؟ RL كتستعمل الاحتمالات مباشرة — فرق صغير فالأرقام كيصير فرق واضح فالسلوك.

الحل: استعمل fp32 للـ lm_head:

<bdi>fp32_lm_head</bdi>: <bdi>true</bdi>

لماذا هاد الترتيب مهم؟

الفريق كان عندهم إغراء:

• الخيار السهل: "شنو إيلا ضفنا تصحيح فالخوارزمية؟ ربما غادي يشتغل."
• الخيار الصحيح: "لا، أولا نتأكدو إن المحرك صحيح."

لما اختارو الخيار الصحيح، اتضح إن المشكلة كانت فالمحرك، ماشي فالخوارزمية. بعد الإصلاحات 4 ديال، V1 طابقت V0 بدون أي تغيير للخوارزمية.

إيلا كانو ضافو تصحيحات من الأول:

• كانو غادي يخفيو المشاكل الحقيقية
• الرسوم البيانية كانت غادي تصير ألغاز
• التدريب كان غادي يصير بطيء وغير موثوق

شنو الخطوة الجاية؟

دابا اللي vLLM V1 صحيحة، الفريق قادر يشتغل على التحسينات الحقيقية:

• استعمل explicit behavior-policy logprobs (احتمالات صريحة من وقت التشغيل)
• أعد حساب old-policy logprobs وقت التدريب
• فصل تصحيح backend mismatch من policy update
• تتبع مقاييس مثل ESS (Effective Sample Size — حجم العينة الفعلي)

لكن هاد الحاجات غادي تصير بعد ما تكون متأكد إن الأساسيات صحيحة.

شنو كيعني هاد الشي ليك؟

هاد الدرس ماشي غير لـ vLLM. أي مشروع AI كبير — سواء كان تدريب نموذج، بناء chatbot، ولا تطوير AI Agent — كيحتاج نفس الفكرة:

إصلح الأساسيات أولا، بعدين حسّن.

المهندسين والمطورين المغاربة اللي كيشتغلو على مشاريع machine learning — سواء فشركات كبيرة ولا مشاريع شخصية — كيقدرو يتعلمو من هاد الاستراتيجية. بدل ما تضيف ميزات وتصحيحات عشوائية، قسّم المشاكل لطبقات (semantic، runtime، objective) واحدة بواحدة. هاد الطريقة كتوفر وقت وكتخليك متأكد من اللي كتعمل. وخاصة فـ remote work مع فرق أوروبية، الوضوح والتنظيم هم اللي كيفرقو بين مشروع ناجح ومشروع كيضيع الوقت.