-
Notifications
You must be signed in to change notification settings - Fork 2.4k
[misc] feat: remove redundant default params #3577
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
Conversation
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.
Code Review
This pull request aims to remove redundant default parameters and align warm-up step logic. The changes generally improve code clarity and consistency by relying on configuration files and dataclasses for default values. However, I've identified a critical bug in verl/utils/megatron/optimizer.py where an incorrect attribute is accessed, which would lead to a runtime error. The rest of the changes look good and correctly align with the intended logic.
Co-authored-by: gemini-code-assist[bot] <176961590+gemini-code-assist[bot]@users.noreply.github.com>
|
Could you rebase main and run CI again? |
### What does this PR do?
- As title
### Checklist Before Starting
- [ ] Search for similar PRs. Paste at least one query link here: ...
- [ ] Format the PR title as `[{modules}] {type}: {description}` (This
will be checked by the CI)
- `{modules}` include `fsdp`, `megatron`, `sglang`, `vllm`, `rollout`,
`trainer`, `ci`, `training_utils`, `recipe`, `hardware`, `deployment`,
`ray`, `worker`, `single_controller`, `misc`, `perf`, `model`, `algo`,
`env`, `tool`, `ckpt`, `doc`, `data`
- If this PR involves multiple modules, separate them with `,` like
`[megatron, fsdp, doc]`
- `{type}` is in `feat`, `fix`, `refactor`, `chore`, `test`
- If this PR breaks any API (CLI arguments, config, function signature,
etc.), add `[BREAKING]` to the beginning of the title.
- Example: `[BREAKING][fsdp, megatron] feat: dynamic batching`
### Test
> For changes that can not be tested by CI (e.g., algorithm
implementation, new model support), validate by experiment(s) and show
results like training curve plots, evaluation results, etc.
### API and Usage Example
> Demonstrate how the API changes if any, and provide usage example(s)
if possible.
```python
# Add code snippet or script demonstrating how to use this
```
### Design & Code Changes
> Demonstrate the high-level design if this PR is complex, and list the
specific changes.
### Checklist Before Submitting
> [!IMPORTANT]
> Please check all the following items before requesting a review,
otherwise the reviewer might deprioritize this PR for review.
- [ ] Read the [Contribute
Guide](https://github.com/volcengine/verl/blob/main/CONTRIBUTING.md).
- [ ] Apply [pre-commit
checks](https://github.com/volcengine/verl/blob/main/CONTRIBUTING.md#code-linting-and-formatting):
`pre-commit install && pre-commit run --all-files --show-diff-on-failure
--color=always`
- [ ] Add / Update [the
documentation](https://github.com/volcengine/verl/tree/main/docs).
- [ ] Add unit or end-to-end test(s) to [the CI
workflow](https://github.com/volcengine/verl/tree/main/.github/workflows)
to cover all the code. If not feasible, explain why: ...
- [ ] Once your PR is ready for CI, send a message in [the `ci-request`
channel](https://verl-project.slack.com/archives/C091TCESWB1) in [the
`verl` Slack
workspace](https://join.slack.com/t/verl-project/shared_invite/zt-3855yhg8g-CTkqXu~hKojPCmo7k_yXTQ).
(If not accessible, please try [the Feishu group
(飞书群)](https://applink.larkoffice.com/client/chat/chatter/add_by_link?link_token=772jd4f1-cd91-441e-a820-498c6614126a).)
### What does this PR do?
move log rollout logic to one standalone function that can be re-used in
other trainers such as `DAPORayTrainer` etc and avoid duplicated code.
### Checklist Before Starting
- [x] Search for similar PRs. Paste at least one query link here: ...
- [x] Format the PR title as `[{modules}] {type}: {description}` (This
will be checked by the CI)
- `{modules}` include `fsdp`, `megatron`, `sglang`, `vllm`, `rollout`,
`trainer`, `ci`, `training_utils`, `recipe`, `hardware`, `deployment`,
`ray`, `worker`, `single_controller`, `misc`, `perf`, `model`, `algo`,
`env`, `tool`, `ckpt`, `doc`, `data`
- If this PR involves multiple modules, separate them with `,` like
`[megatron, fsdp, doc]`
- `{type}` is in `feat`, `fix`, `refactor`, `chore`, `test`
- If this PR breaks any API (CLI arguments, config, function signature,
etc.), add `[BREAKING]` to the beginning of the title.
- Example: `[BREAKING][fsdp, megatron] feat: dynamic batching`
### Test
> For changes that can not be tested by CI (e.g., algorithm
implementation, new model support), validate by experiment(s) and show
results like training curve plots, evaluation results, etc.
### Design & Code Changes
> Demonstrate the high-level design if this PR is complex, and list the
specific changes.
### Checklist Before Submitting
> [!IMPORTANT]
> Please check all the following items before requesting a review,
otherwise the reviewer might deprioritize this PR for review.
- [x] Read the [Contribute
Guide](https://github.com/volcengine/verl/blob/main/CONTRIBUTING.md).
- [x] Apply [pre-commit
checks](https://github.com/volcengine/verl/blob/main/CONTRIBUTING.md#code-linting-and-formatting):
`pre-commit install && pre-commit run --all-files --show-diff-on-failure
--color=always`
- [ ] Add / Update [the
documentation](https://github.com/volcengine/verl/tree/main/docs).
- [ ] Add unit or end-to-end test(s) to [the CI
workflow](https://github.com/volcengine/verl/tree/main/.github/workflows)
to cover all the code. If not feasible, explain why: ...
- [ ] Once your PR is ready for CI, send a message in [the `ci-request`
channel](https://verl-project.slack.com/archives/C091TCESWB1) in [the
`verl` Slack
workspace](https://join.slack.com/t/verl-project/shared_invite/zt-3855yhg8g-CTkqXu~hKojPCmo7k_yXTQ).
(If not accessible, please try [the Feishu group
(飞书群)](https://applink.larkoffice.com/client/chat/chatter/add_by_link?link_token=772jd4f1-cd91-441e-a820-498c6614126a).)
### What does this PR do? This PR introduces two changes: 1. Removal of redundant default parameters: Default optimizer values are already set in the .yaml configuration file. Defining them again in other files is redundant and can cause confusion for users. 2. Alignment of warm-up step logic: Changed the condition from `num_warmup_steps < 0` to `num_warmup_steps <= 0`. This aligns the code with the documentation in the YAML file and matches the implementation in Megatron. https://github.com/volcengine/verl/blob/main/verl/trainer/config/actor/actor.yaml#L132 --------- Co-authored-by: gemini-code-assist[bot] <176961590+gemini-code-assist[bot]@users.noreply.github.com> Co-authored-by: Chi Zhang <[email protected]> Co-authored-by: Changlong Yu <[email protected]>
### What does this PR do? This PR introduces two changes: 1. Removal of redundant default parameters: Default optimizer values are already set in the .yaml configuration file. Defining them again in other files is redundant and can cause confusion for users. 2. Alignment of warm-up step logic: Changed the condition from `num_warmup_steps < 0` to `num_warmup_steps <= 0`. This aligns the code with the documentation in the YAML file and matches the implementation in Megatron. https://github.com/volcengine/verl/blob/main/verl/trainer/config/actor/actor.yaml#L132 --------- Co-authored-by: gemini-code-assist[bot] <176961590+gemini-code-assist[bot]@users.noreply.github.com> Co-authored-by: Chi Zhang <[email protected]> Co-authored-by: Changlong Yu <[email protected]>
### What does this PR do? This PR introduces two changes: 1. Removal of redundant default parameters: Default optimizer values are already set in the .yaml configuration file. Defining them again in other files is redundant and can cause confusion for users. 2. Alignment of warm-up step logic: Changed the condition from `num_warmup_steps < 0` to `num_warmup_steps <= 0`. This aligns the code with the documentation in the YAML file and matches the implementation in Megatron. https://github.com/volcengine/verl/blob/main/verl/trainer/config/actor/actor.yaml#L132 --------- Co-authored-by: gemini-code-assist[bot] <176961590+gemini-code-assist[bot]@users.noreply.github.com> Co-authored-by: Chi Zhang <[email protected]> Co-authored-by: Changlong Yu <[email protected]>
### What does this PR do? This PR introduces two changes: 1. Removal of redundant default parameters: Default optimizer values are already set in the .yaml configuration file. Defining them again in other files is redundant and can cause confusion for users. 2. Alignment of warm-up step logic: Changed the condition from `num_warmup_steps < 0` to `num_warmup_steps <= 0`. This aligns the code with the documentation in the YAML file and matches the implementation in Megatron. https://github.com/volcengine/verl/blob/main/verl/trainer/config/actor/actor.yaml#L132 --------- Co-authored-by: gemini-code-assist[bot] <176961590+gemini-code-assist[bot]@users.noreply.github.com> Co-authored-by: Chi Zhang <[email protected]> Co-authored-by: Changlong Yu <[email protected]>
What does this PR do?
This PR introduces two changes:
Removal of redundant default parameters: Default optimizer values are already set in the .yaml configuration file. Defining them again in other files is redundant and can cause confusion for users.
Alignment of warm-up step logic: Changed the condition from
num_warmup_steps < 0tonum_warmup_steps <= 0. This aligns the code with the documentation in the YAML file and matches the implementation in Megatron.https://github.com/volcengine/verl/blob/main/verl/trainer/config/actor/actor.yaml#L132