[Bugfix] Fix iteration time for asynchronous scheduler

[maxyanghu]

Purpose

During async-scheduling, iteration time might be incorrect because the results in batch_queue could be ready when we log before time.

Fix this by adding a submission timestamp in the batch_queue.

Iteration time after the fix would be: from when the execution future is submitted to the queue to when the execution results are returned.

Test Plan

vllm serve --enable-logging-iteration-details  --async-scheduling --model Qwen/Qwen3-VL-8B-Instruct

then

vllm bench serve --base-url http://127.0.0.1:8000 --model Qwen/Qwen3-VL-8B-Instruct --dataset-name random --num-prompts 50

Test Result

no 0ms iteration time in the log. The iteration time is more accurate now.

---

Essential Elements of an Effective PR Description Checklist

• The purpose of the PR, such as "Fix some issue (link existing issues this PR will resolve)".
• The test plan, such as providing test command.
• The test results, such as pasting the results comparison before and after, or e2e results
• (Optional) The necessary documentation update, such as updating supported_models.md and examples for a new model.
• (Optional) Release notes update. If your change is user facing, please update the release notes draft in the Google Doc.

[dosubot]

Related Documentation

Checked 0 published document(s) in 1 knowledge base(s). No updates required.

^{How did I do? Any feedback?}  

[gemini-code-assist]

Code Review

The pull request correctly addresses the issue where iteration time logging was inaccurate for the asynchronous scheduler by introducing a submission timestamp in the batch_queue. This ensures that the logged time reflects the total duration from batch submission to completion, rather than just the time spent waiting for the future result after popping it from the queue. The changes are well-integrated into the existing EngineCore logic and include appropriate type hint updates.

[gemini-code-assist]

In the deferred sampling path (used for structured outputs with speculative decoding), recording time.monotonic() here only captures the duration of the sampling phase and its time in the queue. It misses the initial model execution time from the execute_model call at the beginning of the step_with_batch_queue function. This results in inconsistent iteration time metrics compared to the non-deferred path, where the timestamp is recorded immediately after the model execution starts. To ensure consistent and accurate metrics, the start time should be captured once at the beginning of the iteration and used for both paths.

[mgoin]

cc @njhill to review