-
Notifications
You must be signed in to change notification settings - Fork 0
[DO NOT MERGE, WIP] feat: ray-less SFT #4
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
base: main
Are you sure you want to change the base?
Conversation
maharajamihir
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
tested up to qwen 32B. works.
|
I'm just wondering whether we should wait for upstream lora support (for the default codepath + RL), or not. For some reason the seem to be constantly reverting their lora implementation lol |
|
I don't think they found a 'proper' solution for lora-based RL with sglang yet as the current proposal still unloads and reloads the lora adapter from disk (surely we can do better than that). |
|
Question is whether we should:
|
* feat: support lora in ray-less SFT codepath * chore: add assert * chore: fail fast if no lora-compatible modules found * fix: set default lora dropout to 0 * fix: skip dataloader checkpoint loading if non-existent * chore: change lora defaults * feat: checkpoint in run script * feat: separate load and save paths * fix: only store trainable params in optimizer * fix: only load adapter weights on lora restore * feat: support lora in the ray-full SFT codepath (+assert that grad check. is off)
74f4820 to
e15e2a3
Compare
|
Merging now that we have a working workflow to keep in sync with upstream. |
|
Actually, let's first merge #10 into this branch and then merge the entire thing into main. That way, we frontload most of the conflict resolution down the line when lora is finally merged into upstream main. |
No description provided.