[Generative Score API] Fix on prefill-only scheduler running batch loss track problem#14320
[Generative Score API] Fix on prefill-only scheduler running batch loss track problem#14320hnyls2002 merged 7 commits intosgl-project:mainfrom
Conversation
Summary of ChangesHello @haNa-meister, I'm Gemini Code Assist1! I'm currently reviewing this pull request and will post my feedback shortly. In the meantime, here's a summary to help you and other reviewers quickly get up to speed! This pull request resolves a critical issue in the generative score API's scheduler where prefill-only requests were not being properly tracked. This led to inaccurate Highlights
Using Gemini Code AssistThe full guide for Gemini Code Assist can be found on our documentation page, here are some quick tips. Invoking Gemini You can request assistance from Gemini at any point by creating a comment using either
Customization To customize Gemini Code Assist for GitHub experience, repository maintainers can create a configuration file and/or provide a custom code review style guide (such as PEP-8 for Python) by creating and adding files to a Limitations & Feedback Gemini Code Assist may make mistakes. Please leave feedback on any instances where its feedback is incorrect or counter productive. You can react with 👍 and 👎 on @gemini-code-assist comments. If you're interested in giving your feedback about your experience with Gemini Code Assist for Github and other Google products, sign up here. You can also get AI-powered code generation, chat, as well as code reviews directly in the IDE at no cost with the Gemini Code Assist IDE Extension. Footnotes
|
There was a problem hiding this comment.
Code Review
This pull request correctly fixes an issue where prefill-only requests were not being tracked in the running_batch, leading to incorrect metrics and disabled safety mechanisms. The changes are well-reasoned and implemented cleanly. By allowing prefill-only batches to be merged into the running_batch and then explicitly skipping the decode step for them, the core issue is resolved. The addition of a manual filtering step for prefill-only running batches is a necessary and correct adjustment to ensure finished requests are properly cleaned up. The provided benchmarks also indicate a slight performance improvement, which is a great result. The code is clear and the changes are solid.
sundar24295s
left a comment
There was a problem hiding this comment.
LGTM! Thanks for fixing this
Head branch was pushed to by a user without write access
Scheduler (python): - Allow prefill-only batches to merge into running_batch so num_running_reqs reports correctly (was always 0) - Add filter_batch() for prefill-only running batches to clean up finished requests that won't go through decode - Guard decode step to skip prefill-only batches (Backport of PR sgl-project#14320) Router (rust): - Set load monitor polling interval to 1s (decoupled from worker_startup_check_interval_secs which stays at 5s) Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
Head branch was pushed to by a user without write access
|
/tag-and-rerun-ci |
|
/tag-and-rerun-ci |
|
All prefill-only tests passed. |
…ss track problem (sgl-project#14320) Co-authored-by: Wenyan Yao <wenyao@linkedin.com> Co-authored-by: Sundara Raman Ramachandran <sundar24295@gmail.com>
…ss track problem (sgl-project#14320) Co-authored-by: Wenyan Yao <wenyao@linkedin.com> Co-authored-by: Sundara Raman Ramachandran <sundar24295@gmail.com>
Motivation
Metric missing problem
Currently, in last change for prefill-only: PR, to have higher throughput, we decided to skip decode scheduling stage. However, in its implementation, it will skip
running_batchto merge withlast_batchwhich makesrunning_batchis always empty.Affects load monitor on sgl model gateway
In sgl model gateway, it uses get_load api to get load infos on sglang server, however, during a prefill benchmarking it shows 0 on requests and 0 on token is use, below are an example for polling get_load during that period:
Same polling after this fix:
Logging on model gateway:
Metrics
sglang:num_running_reqsis always 0.0 problemSafe mechanism
running_batchis always empty, and running_lens is always 0. Thus, lots of safe mechanism in scheduler is not enabled, for example: link, linkModifications
running_batchin each scheduling loop to avoid keep tracking finished requests.Accuracy Tests
Test env:
GPU: H100.
Model: Qwen3-0.6B.
Running on this PR
Running on last version
Metrics
It is clear that for prefill-only request, the sglang:num_running_reqs will be always 0.0. Because it is tracking the running_batch's length. Below is the example metrics api response during benchmark period.
Metrics before this PR
Metrics with this PR
Benchmarking and Profiling
Benchmark env:
GPU: H100.
Model: Qwen3-0.6B.
QPS: 160.
Items per request: 10.
Tokens per query: 120.
Tokens per items: 180
Running on this PR
Running on last version
Checklist