نحن متحمسون لـ PipelineRL مفتوح المصدر، وهو تطبيق تجريبي لـ RL يعالج تحديًا أساسيًا في التعلم المعزز واسع النطاق باستخدام LLM: المفاضلة بين إنتاجية الاستدلال وجمع البيانات المتعلقة بالسياسة. الابتكار الرئيسي لـ PipelineRL هو تحديثات الوزن على متن الطائرة أثناء تدريب RL (انظر الشكل 1 أدناه). يتيح ذلك لـ PipelineRL تحقيق إنتاجية استدلالية عالية باستمرار وتقليل الفارق بين الأوزان المستخدمة في عمليات الطرح وأحدث أوزان النماذج التي تم تحديثها. النتيجة: تدريب RL سريع ومستقر لنماذج اللغات الكبيرة.
في منشور المدونة هذا، نوضح أن 1) تحديثات الوزن على متن الطائرة لا تضر بعملية التدريب و2) تحقق PipelineRL نتائج تنافسية مقارنة بـ Open-Reasoner-Zero، مع استخدام خوارزمية RL أبسط. نقدم أيضًا بنية PipelineRL المعيارية التي تسهل تجربة مجموعات الاستدلال/المدرب الجديدة.
التقليدية RL مقابل PipelineRL
في نُهج RL التقليدية (الشكل 1 أ)، هناك مفاضلة بين الاستدلال عالي الإنتاجية وجمع البيانات المتعلقة بالسياسة. لشرح هذه المقايضة، دعونا أولاً نحدد RL التقليدية خوارزميًا:
current_policy = initial_policy
opt_state = init_optimizer(current_policy)
while True:
inference_policy = current_policy
list_of_prompts = [sample_prompts(training_batch_size) \
for _ in range(num_grad_steps)]
list_of_rollouts = [sample_rollouts(prompts, inference_policy) \
for prompts in list_of_prompts]
lag = 0
for rollouts in list_of_rollouts:
current_policy, opt_state = policy_update(current_policy, opt_state, rollouts)
lag += 1
لتحقيق إنتاجية عالية، يجب أن تستخدم خوادم الاستدلال أحجامًا كبيرة للدفعات، وبالتالي، إنشاء بيانات لخطوات تحسين السياسة المتعددة. ومع ذلك، فإن كل خطوة من خطوات التحسين تزيد من الفجوة بين السياسة الحالية والبيانات التي تم جمعها باستخدام سياسة الاستدلال، مما يجعل البيانات المجمعة تدريجيًا خارج السياسة وأقل فعالية للتدريب. يتطلب التعلم المتعلق بالسياسات بيانات لخطوة تحسين واحدة. لكن إنتاج كميات صغيرة من البيانات باستخدام العديد من وحدات معالجة الرسومات أمر غير فعال لأن هذا يعني أن حجم الدفعة لكل وحدة معالجة رسومات صغير. علاوة على ذلك، ينخفض حجم الدفعة عندما ينهي خادم الاستدلال التسلسلات القصيرة ولا يحتوي إلا على عدد قليل من التسلسلات الأطول قيد التقدم.
يعالج PipelineRL (الشكل 1 ب) هذه المقايضة من خلال تحديثات الوزن على متن الطائرة. نقوم بتحديث الأوزان في خوادم الاستدلال بعد كل خطوة للمحسن دون التوقف عن الاستدلال. نقوم بإيقاف الاستدلال مؤقتًا على جميع خوادم الاستدلال فقط للوقت اللازم لتلقي الأوزان الجديدة. تتيح تحديثات الوزن على متن الطائرة لخادم الاستدلال الحفاظ باستمرار على حجم الدفعة الأمثل مع ضمان بقاء البيانات في السياسة أو بالقرب منها في نفس الوقت، مما يؤدي إلى استخدام أفضل لوحدة معالجة الرسومات وتعلم أكثر فعالية، على التوالي.
يعمل PipelineRL!
لإثبات فعالية PipelineRL وفوائد تحديثات الوزن على متن الطائرة، قمنا بتدريب نموذج 7B ونموذج 32B على مجموعة بيانات Open-Reasoner-Zero. بالنظر إلى منحنيات التعلم، نرى أن PipelineRL يطابق أداء Open-Reasoner أو يتجاوزه في معايير اختبار الاستدلال الشائعة: AIME 2024 وMATH 500 (انظر الشكل 2 أعلاه).
والجدير بالذكر أن تنفيذ RL الخاص بنا أبسط بكثير من Open-Reasoner-Zero. بينما يستخدم Open-Reasoner-Zero دالة القيمة، فإن تطبيقنا هو نسخة مبسطة من GRPO. على وجه الخصوص، وجدنا أن تثبيت الوزن بأهمية منطقة الثقة ليس ضروريًا للتدريب المستقر. ولم يتم تصفية التسلسل الطويل أو تشكيل المكافأة من ورقة DAPO. لتطبيع الخسارة، نستخدم فقط عدد التسلسلات في الدفعة كمقام، مع إعطاء أوزان متساوية لجميع الرموز المميزة. لم نستخدم أي عقوبة KL ولا مكافأة إنتروبيا (على الرغم من أن تطبيقنا يدعم النموذج المرجعي KL). على الرغم من بساطة تنفيذنا، أو ربما بفضله، فإن التدريب مستقر للغاية كما ترون في هذا التقرير.
قد يتوقع المرء أن تحديثات الوزن على متن الطائرة قد تؤدي إلى عملية تدريب غير مستقرة يستمر إنشاء التسلسل باستخدام المفاتيح والقيم التي لا معنى لها في ذاكرة التخزين المؤقت KV التي تم حسابها مع إصدار النموذج السابق. ومع ذلك، تشير تجاربنا إلى أن هذا لا يؤثر سلبا على الاستقرار.
بنية خط الأنابيبRL
تم تصميم PipelineRL لتكون معيارية وتستفيد من التحسينات السريعة في برامج الاستدلال والتدريب عالية التخصص (SGLang، وvLLM، وNvidia Dynamo، وDeepSpeed، وFSDP، وTorchTitan، وFastLLM، وما إلى ذلك). نقترح عقودًا واضحة بين مكونات الاستدلال والتدريب، مما يتيح سهولة دمج حلول الاستدلال والتدريب الجديدة عندما تصبح متاحة.
عقد الاستدلال
يجب أن يعرض برنامج الاستدلال واجهات برمجة التطبيقات التالية إلى PipelineRL[1]:
- تهيئة مجموعة العمليات: في وقت البدء، يرسل المدرب 0 (المنسق المعين) HTTP
POST /init_process_groupطلب لجميع خوادم الاستدلال. يقوم هذا الطلب بتهيئة مجموعة العمليات التي سيتم استخدامها لإرسال تحديثات الوزن. - مشغل تحديث الوزن: بمجرد أن يكمل المدربون خطوة تعليمية (خطوة المحسّن وجمع الوزن)، يرسل المدرب 0 HTTP
POST /request_weight_updateطلب إلى نقطة النهاية الاستدلال. يحتوي الطلب على تفاصيل ترتيب وأشكال الأوزان التي سيقوم المدرب الرئيسي بنقلها عبر NCCL. يجب أن تقوم خوادم الاستدلال بإيقاف الاستدلال مؤقتًا واستقبال بث الوزن. - استكمال الدردشة: تتفاعل عملية الممثل مع LLMs الممثل باستخدام HTTP
POST /v1/chat/completionطلبات.
لو init_process_group و request_weight_update أصبحت واجهات برمجة التطبيقات (APIs) هي المعيار الصناعي، وسيتمكن المرء من محاولة التوصيل والتشغيل باستخدام تطبيقات استدلال الاختلاف مع PipelineRL.
عقد المدرب
يعمل كود تدريب PipelineRL على تغذية بيانات التدريب التي تم إنشاؤها حديثًا للعاملين المدربين بمجرد تراكم العدد المناسب من رموز التدريب المميزة لكل منهم. يمكن للمرء أن يجعل أي برنامج تدريبي يكشف عن واجهات برمجة تطبيقات Python هذه يعمل مع PipelineRL:
- تهيئة العامل أوزان تدريب الأحمال والشظايا وحالة المحسن.
- تمريرة إلى الأمام إنتاج احتمالات سجل الرمز المميز بالنظر إلى المدخلات.
- خطوة إلى الوراء: حساب وتجميع التدرج العددي الذي يمثل هدف RL المختار.
- خطوة محسن: قم بتنفيذ خطوة المحسن.
- جمع الوزن والبث: بعد خطوة التحسين، يجب على برنامج المدرب جمع أوزان النموذج المحدثة طبقة بعد طبقة استعدادًا لبثها إلى خوادم الاستدلال.
يستخدم PipelineRL حاليًا HuggingFace accelerate مكتبة لمنح المستخدم الاختيار بين DeepSpeed وFSDP. لكننا وجدنا ذلك accelerate العقد مرن للغاية ويمكن أن يكون مربكًا. سوف ننتقل إلى العقد الأكثر صرامة كما هو موضح أعلاه والذي سيجعل استخدام المدربين الآخرين أسهل.
ما هي الخطوة التالية بالنسبة لـ PipelineRL؟
الميزات القادمة. لا يزال تطبيقنا تجريبيًا ويفتقر إلى بعض الوظائف المهمة. تشمل الأولويات القصوى بالنسبة لنا استخدام coroutines للتحكم بشكل أكثر دقة في حجم دفعة الاستدلال والدعم متعدد الوسائط والتدريب المتوازي التسلسلي. نرحب أيضًا بمساهمات المزيد من عمليات تكامل خادم الاستدلال والمدرب. ومع ذلك، فإننا لن نحاول القيام بذلك pipeline-rl الريبو إطار عمل يدعم جميع الخوارزميات الممكنة ووظائف المكافأة. وجهة نظرنا هي ذلك pipeline-rl يجب أن يكون تطبيقًا مرجعيًا سريعًا وقابلاً للاختراق لـ GRPO مع مكافآت يمكن التحقق منها بسهولة. إذا كنت ترغب في القيام بمشروع بحثي باستخدام PipelineRL، فيمكنك فقط تفرع الريبو والاستمتاع باختراق الكود!
المزيد من الأبحاث قريبا. هناك حاجة إلى مزيد من التحليل لفهم كيفية تأثير تحديثات الوزن على متن الطائرة على ديناميكيات التدريب، ولقياس السرعات التي توفرها PipelineRL بعناية. أيضًا، يمكن قول الكثير عن أوجه التشابه بين PipelineRL والعمل السابق ذي الصلة للغاية بشأن التعلم المعزز غير المتزامن لطلاب LLM. لكل هذا وأكثر، ترقبوا ورقتنا البحثية القادمة!
المساهمين والتقدير
كتب Alexandre Piché أول إصدار متزامن من كود RL الخاص بنا أثناء العمل على TapeAgents. أعاد Dzmitry Bahdanau صياغة الكود ليكون غير متزامن وموزع، ونفذ تحديثات الوزن على متن الطائرة. قام رافائيل بارديناس بتنفيذ التعبئة التسلسلية. ساعد إحسان كمالو في إجراء التجارب. ساعد Xiaoyin Chen في تصحيح أخطاء إطار العمل.
نحن نعترف بـ RL السابقة لتطبيقات LLM مثل TRL وOpenRLHF وveRL للعديد من الحيل التي اقترضناها منها. كانت القطع الأثرية من مشاريع التفكير المنطقي الأخرى مفتوحة المصدر، مثل Simple-RL، وDeepscaler، وDAPO، وOpenReasoner مفيدة في تثبيت PipelineRL. نود أن نعرب عن تقديرنا لكريستوفر مانينغ ومايكل نوخوفتش على تعليقاتهما المدروسة. أخيرًا، نشكر فريق أبحاث ServiceNow الأوسع وفرق ServiceNow CoreLLM لكونهم زملاء رائعين.
[1] يختلف العقد الحالي في الكود قليلاً، لكننا نعيد هيكلته كما هو موضح أعلاه.
التفاصيل التجريبية
استخدمنا نفس المعلمات الفائقة لكل من التجارب 7B و32B التي نوردها هنا:
- حجم الدفعة 4096
- معدل التعلم 1e-6
- الحد الأقصى لعدد الرموز التي تم إنشاؤها 8192
- لاحظ أنه في تشغيل OpenReasoner سمحوا بإنشاء 16 ألف رمز مميز
الحساب الذي استخدمناه في التجارب المبلغ عنها
- ~ 3.5 أيام على عقدتين للنموذج 7B
- ~6 أيام على 4 عقد للطراز 32B
