[V1] Ensure using int64 for sampled token ids

[WoosukKwon]

A more fundamental solution to the bug in #14999 and #15049

[github-actions]

👋 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 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 either: Add ready label to the PR or enable auto-merge.

🚀

[WoosukKwon]

cc @houseroad

[houseroad]

actually I am debating to keep this in the gather_logprobs, since we may skip the conversion if gather_logprobs is not called. what do you think?

[WoosukKwon]

1. I think that's error prone. For example, other ops in the future might try to use this tensor for indexing and get the same error.
2. The op should be very cheap, it's supposed to be a no-op for common case (no top-p or top-k) where sampled is already a long tensor. Even if it's not, sampled tensor here is pretty small, so I don't think its overhead will matter.

[ywang96]

Agreed with @WoosukKwon here, sampled here is pretty small even in the worst case (1024)

[houseroad]

Okay, if we see overhead, we can always optimize it :-)