‏دردسرهای یادگیری تقویتی برای agentها

ایان باربر تو این پست می‌گه RL برای agentها از نظر مفهومی ساده‌ست: برای هر مسئله یه VM با harness (یعنی برنامه‌ای که مدل رو اجرا می‌کنه و tool callهاش رو انجام می‌ده) راه می‌ندازی، مدل کارش رو می‌کنه، آخرش نمره می‌گیره و وزن‌ها آپدیت می‌شن. فرض مهم اینه که مدلی که rollout رو تولید کرده با مدلی که آپدیت می‌شه یکی باشه، که بهش on policy می‌گن. بیشتر الگوریتم‌ها از نسبت policy/old_policy تو PPO استفاده می‌کنن که تو اولین آپدیت باید دقیقاً ۱ باشه. هر اختلافی یعنی مشکل.

مشکل اینه که جلسه‌ها خیلی طولانی شدن. تو مقاله QwenGyre از Alibaba، rolloutهای مدل 122B به طور میانگین حدود ۲ ساعت طول کشیدن و برای مدل اصلی 2.4T خیلی‌هاش از ۴ ساعت هم رد شدن. Alibaba مستقیم تو harnessهای اختصاصی مثل Claude Code آموزش می‌ده، چون بازسازیشون عملی نیست. ولی اینا جعبه سیاهن. پس کانتینرها رو روشن نگه می‌دارن، inference رو از یه proxy رد می‌کنن و GPUها رو تو cellهایی می‌ذارن که سریع بین rollout و training جابه‌جا می‌شن. حتی KV cache بین cellها جابه‌جا می‌شه.

DeepSeek برعکس harness خودش رو داره و می‌تونه همه چیز رو متوقف کنه. اونا rolloutهای طولانی رو مرتب preempt می‌کنن. قبل از v4.1 حلقه agent تو job خود GPU بود و باید دوباره بازسازی می‌شد. تو 4.1 harness رو بردن داخل sandbox و کل وضعیت رو فریز می‌کنن: DRAM و لایه قابل نوشتن فایل‌سیستم.

خود trajectoryها هم می‌تونن off-policy بشن. اگه بذاری سرور inference خروجی مدل رو پارس کنه، مثلاً آرگومان false ممکنه بشه False. کتابخونه Renderers از Prime Intellect روی همین کار کرده و proxy تو QwenGyre هم payload اصلی tool callها رو کش می‌کنه، چون harness بین نوبت‌ها فرمتشون رو عوض می‌کنه. از اون طرف، agentها subagent می‌سازن، tool call موازی دارن و جلسه رو فشرده می‌کنن، پس خروجی یه درخته. روش Tree Training درخت رو به یک یا چند stream تبدیل می‌کنه و هر توکن رو بر اساس درصد شاخه‌هایی که داره وزن می‌ده. QwenGyre هم تعداد مسیرها رو حداکثر ۵ تا می‌کنه.

آخرین مشکل kernelهاست. inference با batch کوچیک و برای latency بهینه می‌شه (SGLang یا vLLM) و training با batch بزرگ و برای throughput (Megatron یا TorchTitan)، پس نتیجه‌ها کمی فرق دارن. یه راه حل اینه که log-probها رو دوباره روی trainer حساب کنی که یه forward pass اضافه می‌خواد. راه دیگه، مثل QwenGyre، اینه که نسبت رو clip کنی، که تیم Megatron می‌گه فقط مشکل رو قایم می‌کنه.

راه تمیزتر محاسبه bitwise یکسان بین هر دو طرفه. مقاله‌ای از همکارهای نویسنده تو Meta نشون داده این تفاوت‌ها بیشتر از ترتیب reduction، دقت partial-sum، FMA و محل گرد کردن میان. ثابت کردن ترتیب ۱۰ تا ۲۰ درصد سرعت رو می‌گیره. کار Colfax روی FlashAttention-4 هم همینو نشون می‌ده: بهبود 1.13x تو backward pass با head-dim 64، ولی فقط 1.05x با accumulation قطعی. پروژه AReaL-TIK هم از یه kernel مشترک bitwise یکسان شروع می‌کنه و agentها اونو سریع‌تر می‌کنن بدون اینکه یکسان بودن از بین بره.

نکات کلیدی:

• rolloutهای QwenGyre روی مدل 122B به طور میانگین حدود ۲ ساعت و روی 2.4T گاهی بیش از ۴ ساعت طول کشیدن.
• DeepSeek از v4.1 harness رو داخل sandbox برده و موقع preempt شدن DRAM و فایل‌سیستم رو فریز می‌کنه.
• پارس کردن خروجی توسط سرور inference می‌تونه false رو به False تبدیل کنه و داده رو off-policy کنه.
• QwenGyre حداکثر ۵ مسیر از درخت rollout رو برای آموزش نگه می‌داره.
• محاسبه bitwise یکسان ۱۰ تا ۲۰ درصد سرعت kernelها رو کم می‌کنه.
• clip کردن نسبت importance به گفته تیم Megatron مشکل رو پنهان می‌کنه، نه حل.