التصحيح قبل التصحيحات في RL

يستخدم PipelineRL vLLM كمحرك الاستدلال لإنشاء الطرح. يقوم محرك الاستدلال بتجميع عينات من الرموز المميزة وإرجاع مشكلات تسجيل الرموز المميزة؛ يستخدم المدرب تلك logprobs لحساب نسب السياسة وKL ومعدل المقطع والإنتروبيا والمكافأة. أي تناقض في كيفية حساب هذه المشاكل يمكن أن يغير ديناميكيات التدريب. هذا هو عدم تطابق استدلال التدريب الذي كنا بحاجة إلى التخلص منه أثناء ترحيل vLLM V0 إلى V1.

ليرة تركية؛ د. تطابق vLLM V1 مع مرجع vLLM V0 الخاص بنا بعد أن أصلحنا أربعة أشياء: معالجة مشكلات سجل الطرح، والإعدادات الافتراضية لوقت التشغيل الخاص بـ V1، ومسار تحديث الوزن على متن الطائرة، وfp32 lm_head تستخدم للإسقاط النهائي. لقد أصلحنا سلوك الواجهة الخلفية قبل تغيير هدف RL.

يستخدم التشغيل المرجعي vLLM 0.8.5; يستخدم تشغيل V1 vLLM 0.18.1. ويبين الشكل 1 النتيجة النهائية. التشغيل الأحمر هو محاولة V1 الأولية، والتشغيل الأخضر هو تشغيل V1 الأخير بعد الإصلاحات الموضحة أدناه.

هدف الهجرة

يعد vLLM V1 بمثابة إعادة كتابة جوهرية للمحرك V0. لذلك كان هدفنا للهجرة ضيقًا بشكل متعمد:

1. تحقق من أن V1 قام بإرجاع مشكلات سجل الطرح بالشكل الذي توقعه المدرب
2. أعد تشغيل نفس عبء العمل مقابل مرجع V0
3. تقييم التغييرات على مستوى الهدف فقط بعد استعادة تكافؤ الواجهة الخلفية

ظهرت الأعراض المرئية الأولى في:

• clamp_log_ratio_new_old_indicator
• kl_new_old
• entropy
• reward

جاءت هذه المقاييس من تدريب GSPO، وهو الهدف المستخدم لهذه التجربة. يمكن أن تظهر نفس فئة عدم التطابق في PPO أو GRPO أو أي نظام RL عبر الإنترنت يتعامل مع مشكلات السجل من جانب التشغيل كجزء من هدف التحسين.

أظهر التشغيل الأولي لـ V1 المشكلة بوضوح. ابتعدت logprobs والمكافأة من جانب المدرب عن مرجع V0 في وقت مبكر من التدريب.

يظهر نفس النمط في مقاييس المدرب. معدل المقطع هو أسهل إشارة يمكن قراءتها في المقارنة الأولية.

أوضاع الفشل

قمنا بفصل الأسباب المحتملة إلى ثلاث طبقات:

1. عدم التطابق الدلالي: تقوم الواجهة الخلفية بإرجاع logprobs بمعنى مختلف بالنسبة إلى ما يتوقعه المدرب.
2. عدم تطابق مسار الاستدلال: تستخدم الواجهة الخلفية إعدادات افتراضية مختلفة لوقت التشغيل للتخزين المؤقت أو الجدولة أو معالجة الطلبات، لذا تتبع نفس المطالبات مسار تنفيذ مختلف.
3. عدم تطابق الهدف: يحتاج هدف RL إلى تصحيح مقدار عدم التطابق أو عدم تطابق الواجهة الخلفية المتبقية.

لقد اشتبهنا في البداية في الفئة الثالثة في وقت مبكر جدًا. وجاء التشخيص المفيد من معالجة المشكلتين الأوليين باعتبارهما مشكلات سلوكية خلفية واستبعادهما أولاً.

إصلاحات الواجهة الخلفية V1

دلالات Logprob

المسألة الأولى كانت دلالية. يقوم vLLM V1 بإرجاع logprobs من مخرجات النموذج الأولي بشكل افتراضي، قبل المعالجة اللاحقة للسجلات مثل قياس درجة الحرارة والعقوبات وتصفية top-k/top-p. توقع PipelineRL تسجيل المشاكل من التوزيع المعالج الذي يستخدمه جهاز أخذ العينات.

الإعداد المطلوب كان:

• logprobs-mode=processed_logprobs

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

ويظهر مخطط نسبة السياسة هذا بشكل مباشر. مرة واحدة processed_logprobs قيد التشغيل لـ V1، يظل متوسط ​​نسبة السياسة متمركزًا بالقرب من 1.0 عبر جميع الأشواط الثلاثة. وهذا يحدد إصلاح التحيز المتوسط. يظهر عدم التطابق المتبقي في معدل المقطع، وKL، والإنتروبيا، وسلوك التدريب النهائي.

افتراضيات وقت التشغيل

قام التشغيل المبكر لـ V1 بخلط إصدار المحرك مع الإعدادات الافتراضية لوقت تشغيل V1:

• تم ترك التخزين المؤقت للبادئة بدون ضبط في التشغيل المبكر لذا فإن vLLM 0.18.1 تم تطبيقه بشكل افتراضي
• الجدولة غير المتزامنة، تم تركها بدون ضبط في التشغيل المبكر لذلك تم حذف vLLM 0.18.1 تم تطبيقه بشكل افتراضي
• مخصص disable-cascade-attn التجاوز الذي تم تعيينه من خلال مرور kwarg في وقت الإطلاق ويقع خارج وصفة التكافؤ في التكوين الملتزم

من أجل تشغيل التكافؤ، جعلنا هذه الاختيارات واضحة:

vllm_config:
  use_v1: true
  vllm_kwargs:
    logprobs-mode: processed_logprobs
    enable-prefix-caching: false
    async-scheduling: false

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

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

تحديثات الوزن على متن الطائرة

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

ما فعله V0 بفعالية كان أقرب إلى:

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

أقرب نظير V1 كان:

await engine.pause_generation(mode="keep", clear_cache=False)
await engine_client.collective_rpc_async(
    "receive_weight_update",
    args=(request.model_dump_json(),),
)
await engine.resume_generation()

هناك تفصيلان مهمان:

• mode="keep" يتطابق مع نموذج التحديث القديم على متن الطائرة بشكل أوثق من
  wait أو abort
• clear_cache=False يطابق سلوك غلاف V0، الذي ترك حالة التخزين المؤقت سليمة عند التحديث

كان التأخر تشخيصًا مفيدًا لوقت التشغيل. يحمل مسار V1 الأولي تأخيرًا أكثر استمرارًا في وقت لاحق من التدريب مقارنة بتشغيل V1 المصحح.

الفجوة المتبقية: fp32 lm_head

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

تظهر مشكلة وثيقة الصلة في التقرير الفني لـ MiniMax-M1: أظهر تشغيل RL الخاص بهم عدم تطابق احتمالية رمز التدريب/الاستدلال الذي تم تتبعه إلى رأس إخراج LM وتم إصلاحه عن طريق حساب الرأس في fp32.

وهذا أمر مهم لأن تحديث RL يستهلك سجل تسجيلات الرمز المميز مباشرةً. يمكن أن تصبح التغييرات الصغيرة في السجلات مرئية في نسب السياسة وKL والقص. وبالتالي فإن دقة الإسقاط النهائية هي جزء من سطح الصحة لـ RL عبر الإنترنت. تتضمن ورقة ScaleRL لاحقًا حساب fp32 logits/head كجزء من وصفة RL الخاصة بها وتلغيها كخيار تصميم مفيد لـ RL واسعة النطاق.

مع fp32 lm_head المسار المتضمن، المكافأة تعطي رؤية مدمجة لنتيجة التكافؤ النهائية. في الشكل 6، يتتبع تشغيل V1 النهائي مرجع V0؛ تنتج محاولة V1 الأولية منحنى مكافأة مختلفًا بشكل واضح.

الاجتثاث

النتائج السلبية مهمة لأنها تستبعد التفسيرات الشائعة.

• processed_logprobs وحيد: إصلاح الخلل الدلالي logprob؛ بقي عدم تطابق التدريب.
• ثبات الدفعة: بقي عدم التطابق في اختبار منفصل، مع تأخر أعلى، ومعدل مقطع أعلى، ومضاعفات NCCL.
• التعامل مع أول تشغيل V1 كخط أساس عادل: تم تمكين العديد من الإعدادات الافتراضية لـ V1 فقط في تشغيل V1 الأول، لذلك كانت مقارنة ترحيل مشوشة.

لماذا قمنا بإصلاح صحة الواجهة الخلفية أولاً

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

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

• هل تنتج الواجهة الخلفية للاستدلال logprobs الصحيح؟
• بالنظر إلى مشاكل السجل الصحيحة، هل لا يزال الهدف بحاجة إلى تصحيح خارج السياسة أو تصحيح غير متزامن؟

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

لا يزال من الممكن تحسين الهدف الحالي. بعد استعادة تكافؤ الاستدلال، التحسين التالي هو التنظيف المعتاد للسياسة غير المتزامنة:

• احتفظ بمشكلات سجل سياسة السلوك الصريحة من وقت بدء التشغيل
• إعادة حساب مشكلات سجل السياسة القديمة من جانب المدرب في وقت التحسين
• تصحيح عدم تطابق الواجهة الخلفية منفصل عن نسبة تحديث السياسة
• تتبع التشخيصات مثل ESS لمصطلح التصحيح جنبًا إلى جنب مع مقاييس المدرب الإجمالية

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