Scaling asynchronous RLHF is a classic "choose your poison" dilemma: synchronous is too slow, but asynchronous often leads to instability. Our own researcher Tianyu Shi, recently dove into why this happens, identifying "staleness" as the culprit behind the sudden, catastrophic collapses often seen in asynchronous GRPO training. In his latest article, Tianyu moves beyond the "noise" explanation to show that staleness actually introduces a systematic, bias-driven drift. He introduces a "Two-Constraint Stability Rule" that provides actionable guidance for balancing throughput with training stability.
Just published a technical report on one of the most overlooked pain points in scaling RLHF: staleness. When you decouple rollout generation from policy optimization for throughput, your training becomes off-policy — and stale rollouts introduce a systematic bias that scales with S × η (staleness × learning rate). We derive a Two-Constraint Stability Rule that explains why training can suddenly collapse , and how to configure your async RLHF system to stay in the stable regime. Key takeaways: → Stale rollouts are not just noisy — they introduce a directional bias → Two training regimes: diffusive (stable) vs. ballistic (collapse) → Scaling law: η << min{ R_batch/(S·G), R_crit/(T·G) } Full technical report: https://lnkd.in/gfeDxuAi