[rollout] fix: use configured response_length as default max_tokens in vLLM async server

[yurekami]

Summary

Fixes #4568

This PR fixes the max_tokens calculation bug in the vLLM async server where short prompts could cause over-generation.

Problem

When no max_tokens is provided in sampling_params, the default was calculated as:

response_length = self.config.max_model_len - len(prompt_ids)

Since max_model_len = prompt_length + response_length, for short prompts this resulted in max_tokens being much larger than the intended response_length, causing:

• Unnecessary over-generation
• Latency spikes
• Wasted compute resources

Solution

• Default max_tokens to self.config.response_length (the configured response length)
• Apply safety clamp: min(max_tokens, max_possible_tokens) to ensure we never exceed available context space
• Honor explicit max_tokens from caller with safety clamping

Changes

• verl/workers/rollout/vllm_rollout/vllm_async_server.py: Updated generate() method

[gemini-code-assist]

Code Review

This pull request correctly fixes a bug in the vLLM async server where short prompts could lead to over-generation due to an incorrect default max_tokens calculation. The new logic properly defaults to the configured response_length and applies a safety clamp to stay within the model's context window. The change is logical and effectively resolves the issue. I have one high-severity suggestion regarding a redundant assertion that should be removed to improve code clarity and maintainability.

[gemini-code-assist]

This assertion will always pass because the preceding line max_tokens = min(max_tokens, max_possible_tokens) ensures that max_tokens is never greater than max_possible_tokens. While this doesn't cause a runtime error, it makes the assertion redundant and can be misleading for future developers who might rely on it as a safeguard. A non-functional check gives a false sense of security and could hide bugs if the clamping logic were to be changed incorrectly in the future. Since the new logic intentionally clamps the value rather than asserting against invalid user input, this assertion should be removed to improve code clarity and maintainability.