[Bug] Fix AssertionError: Do not capture num_reqs > max_num_reqs for uniform batch

[yewentao256]

Purpose

FIxes #25494

Test Plan

============ Serving Benchmark Result ============
Successful requests:                     1         
Benchmark duration (s):                  0.90      
Total input tokens:                      129999    
Total generated tokens:                  1         
Request throughput (req/s):              1.11      
Output token throughput (tok/s):         1.11      
Peak output token throughput (tok/s):    1.00      
Peak concurrent requests:                1.00      
Total Token throughput (tok/s):          144353.62 
---------------Time to First Token----------------
Mean TTFT (ms):                          899.48    
Median TTFT (ms):                        899.48    
P99 TTFT (ms):                           899.48    
-----Time per Output Token (excl. 1st token)------
Mean TPOT (ms):                          0.00      
Median TPOT (ms):                        0.00      
P99 TPOT (ms):                           0.00      
---------------Inter-token Latency----------------
Mean ITL (ms):                           0.00      
Median ITL (ms):                         0.00      
P99 ITL (ms):                            0.00      
==================================================

[gemini-code-assist]

Code Review

This pull request attempts to fix an AssertionError related to num_reqs > max_num_reqs in uniform batches by modifying a call to _dummy_run. While the intention is correct, the proposed change introduces a new ZeroDivisionError under the same conditions that caused the original error. The root cause appears to be in how _dummy_run handles cases where the maximum number of requests is zero, which is not addressed by this change. A more robust solution would involve modifying _dummy_run to gracefully handle this edge case for all its call paths.

[mgoin]

Superseded by #25505