Skip to content

Conversation

@markmc
Copy link
Member

@markmc markmc commented Jan 28, 2025

Follow on from #12516, part of #10582

Compute these intervals on the API server side as EngineCoreOutputs are processed.

The OutputProcessor needs to track per-request arrival times and the generation timestamp of the most recent token generation.

Prefill intervals are calculated when the first EngineCoreOutput is received, indicating prefill completion.

The histogram buckets match the v0 implementation, but they should probably be improved in future.

Compute these intervals on the API server side as EngineCoreOutputs
are processed.

The OutputProcessor needs to track per-request arrival times and
the generation timestamp of the most recent token generation.

Prefill intervals are calculated when the first EngineCoreOutput
is received, indicating prefill completion.

The histogram buckets match the v0 implementation, but they should
probably be improved in future.

Signed-off-by: Mark McLoughlin <[email protected]>
@github-actions
Copy link

👋 Hi! Thank you for contributing to the vLLM project.
Just a reminder: PRs would not trigger full CI run by default. Instead, it would only run fastcheck CI which starts running only a small and essential subset of CI tests to quickly catch errors. You can run other CI tests on top of those by going to your fastcheck build on Buildkite UI (linked in the PR checks section) and unblock them. If you do not have permission to unblock, ping simon-mo or khluu to add you in our Buildkite org.

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 do one of these:

  • Add ready label to the PR
  • Enable auto-merge.

🚀

return

num_new_generation_tokens = len(output.new_token_ids)
now = time.time()
Copy link
Collaborator

@robertgshaw2-redhat robertgshaw2-redhat Jan 29, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I have seen mixed use of time.time() and time.monotonic() - I think we should standardize on one or the other so we don't have a footgun down the road

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes!

I had initially changed to time.monotonic() but I backed it out because it looks like arrival_time being wall-clock time is part of the public API, so not something I wanted to rush into.

I'll make sure to do it or capture it as a TODO/FIXME before I wrap this up 👍

@robertgshaw2-redhat robertgshaw2-redhat enabled auto-merge (squash) January 29, 2025 02:41
@robertgshaw2-redhat robertgshaw2-redhat added the ready ONLY add when PR is ready to merge/full CI is needed label Jan 29, 2025
@robertgshaw2-redhat robertgshaw2-redhat merged commit 46fb056 into vllm-project:main Jan 29, 2025
60 checks passed
rasmith pushed a commit to rasmith/vllm that referenced this pull request Jan 30, 2025
Isotr0py pushed a commit to Isotr0py/vllm that referenced this pull request Feb 2, 2025
@markmc markmc deleted the metrics-v1-prometheus-logger-4 branch February 5, 2025 11:52
NickLucche pushed a commit to NickLucche/vllm that referenced this pull request Feb 7, 2025
GWS0428 pushed a commit to GWS0428/VARserve that referenced this pull request Feb 12, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

ready ONLY add when PR is ready to merge/full CI is needed

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants