- 
          
- 
                Notifications
    You must be signed in to change notification settings 
- Fork 10.9k
[Misc] Reduce initialization time of auto_tune #23682
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
Each iteration of OOM execution when finding max available memory-utilization results in 10 min delay. Try to detect crashed situation and continue to next iteration efficiently. Signed-off-by: Weida Hong <wdhongtw@google.com>
| 👋 Hi! Thank you for contributing to the vLLM project. 💬 Join our developer Slack at https://slack.vllm.ai to discuss your PR in #pr-reviews, coordinate on features in #feat- channels, or join special interest groups in #sig- channels. Just a reminder: PRs would not trigger full CI run by default. Instead, it would only run  You ask your reviewers to trigger select CI tests on top of  Once the PR is approved and ready to go, your PR reviewer(s) can run CI to test the changes comprehensively before merging. To run CI, PR reviewers can either: Add  If you have any questions, please reach out to us on Slack at https://slack.vllm.ai. 🚀 | 
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 improves the auto_tune.sh script by detecting server crashes early, which reduces unnecessary delays during the auto-tuning process. The approach of checking the server's process ID is sound. However, it could be made more robust to prevent potential issues with PID reuse, which could lead to incorrect benchmark results. I've suggested a small change to also verify the process command line, making the check more reliable.
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.
LGTM, thanks for the improvement!
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.
LGTM, thanks for the improvement!
Signed-off-by: Weida Hong <wdhongtw@google.com>
Signed-off-by: Weida Hong <wdhongtw@google.com> Signed-off-by: yewentao256 <zhyanwentao@126.com>
Signed-off-by: Weida Hong <wdhongtw@google.com> Signed-off-by: gaojc <1055866782@qq.com>
Signed-off-by: Weida Hong <wdhongtw@google.com> Signed-off-by: xuebwang-amd <xuebwang@amd.com>
Signed-off-by: Weida Hong <wdhongtw@google.com>
Signed-off-by: Weida Hong <wdhongtw@google.com>
Signed-off-by: Weida Hong <wdhongtw@google.com> Signed-off-by: xuebwang-amd <xuebwang@amd.com>
Each iteration of OOM execution when finding max available memory-utilization results in 10 min delay.
Try to detect crashed situation and continue to next iteration efficiently.
Purpose
Currently when
auto_tune.shis scanning max available value of memory-utilization,it takes unnecessary time and it's kinda confusing. Since that user usually sees no
child process in that bash session for about 10 * N min. N is the number of iterations
until finding the available value.
This PR help reducing this confusing situation and enhance the efficiency by proactively
detects the OOM situation and continue to next iteration.
Test Plan
No test plan for this change, as this PR is related to helper script.
Test Result
N/A
Essential Elements of an Effective PR Description Checklist
supported_models.mdandexamplesfor a new model.