Skip to content

Don't block the Ray transport loop on training RPCs - #104

Open
sfc-gh-truwase wants to merge 1 commit into
mainfrom
fix/ray-nonblocking-gather
Open

Don't block the Ray transport loop on training RPCs#104
sfc-gh-truwase wants to merge 1 commit into
mainfrom
fix/ray-nonblocking-gather

Conversation

@sfc-gh-truwase

Copy link
Copy Markdown
Collaborator

Summary

  • Replace blocking ray.get in ArcticRLRayServer.forward_backward / forward / step / save / load_checkpoint with await asyncio.gather (same as the HTTP server) so the in-process vLLM request scheduler can keep running during train.
  • Serialize those training-worker RPCs with an asyncio.Lock so unblocking the loop cannot interleave two DP collectives.
  • Add a CPU unit test that step does not call ray.get and that two in-flight steps stay single-flight.

This is independent of the TRL backend. On the current TRL branch the same commit is cherry-picked as 8339f97 on fix/ray-transport-nonblocking-gather for a GSM8K Ray before/after.

Test plan

  • pytest tests/common/test_ray_server_training_gather.py
  • GSM8K 4+4 Ray no-ZoRRo / ZoRRo epoch on TRL branch (fix/ray-transport-nonblocking-gather vs trl-training-client) — compare wall, step p50/p95, weight_sync p50, idle
  • Confirm verl Ray path still inits and a short fwd_bwd + step succeeds (no new hang)

Made with Cursor

ray.get in forward_backward/step froze the in-process vLLM scheduler
that shares RayTransport's event loop. Await ObjectRefs under a
train-op lock so generate can progress and DP collectives stay
single-flight.

Co-authored-by: Cursor <cursoragent@cursor.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant