Main mfix bug when max_seqs=14 in mtp=2 scenario and raise error when cudagraph_capture_sizes can't be an integer multiple of uniform_decode_query_lentp

[zouyida2052]

What this PR does / why we need it?

1. Revert bugfix for mtp in fullgraph and support it when vllm supports
2. raise error when cudagraph_capture_sizes can't be an integer multiple of uniform_decode_query_len
3. bugfix when max_num_seqs=14 in mtp=2 scenario

Does this PR introduce any user-facing change?

no

How was this patch tested?

• vLLM version: v0.11.0
• vLLM main: vllm-project/vllm@83f478b

[github-actions]

👋 Hi! Thank you for contributing to the vLLM Ascend project. The following points will speed up your PR merge:‌‌

• A PR should do only one thing, smaller PRs enable faster reviews.
• Every PR should include unit tests and end-to-end tests ‌to ensure it works and is not broken by other future PRs.
• Write the commit message by fulfilling the PR description to help reviewer and future developers understand.

If CI fails, you can run linting and testing checks locally according Contributing and Testing.

[gemini-code-assist]

Code Review

This pull request introduces several changes, including reverting a previous bugfix, adding a validation check for cudagraph_capture_sizes, and fixing a bug related to max_num_seqs. The changes in vllm_ascend/worker/model_runner_v1.py to raise an error for invalid cudagraph_capture_sizes are well-implemented with a clear error message. The refactoring in vllm_ascend/utils.py and vllm_ascend/torchair/torchair_model_runner.py improves code structure.

However, I've identified a critical issue in vllm_ascend/torchair/torchair_model_runner.py where mc2_tokens_capacity is calculated incorrectly, which could lead to insufficient memory allocation. Additionally, there's an opportunity to improve error handling for hardware limit violations by raising exceptions instead of just logging errors. Please see my detailed comments for suggestions.

[gemini-code-assist]

There appears to be a bug in the calculation of max_graph_batch_size. The function calculate_new_torchair_graph_batch_size expects a token count, but it's being called with self.max_num_reqs, which is a request count. This will lead to an incorrect and much smaller mc2_tokens_capacity. The previous implementation correctly calculated max_num_tokens = self.max_num_reqs * self.uniform_decode_query_len. This logic should be restored before calling the new helper function.

Suggested change

	max_graph_batch_size = self.calculate_new_torchair_graph_batch_size(
	self.max_num_reqs, tp_size)
	max_num_tokens = self.max_num_reqs * self.uniform_decode_query_len
	max_graph_batch_size = self.calculate_new_torchair_graph_batch_size(
	max_num_tokens, tp_size)

[gemini-code-assist]

Using logger.error for violations of hard hardware limits might not be sufficient. An error log will be printed, but the execution will continue, potentially leading to more obscure failures later on. It would be better to raise a ValueError to halt execution immediately and provide a clear error message to the user. This also provides an opportunity to improve the error messages for clarity and grammatical correctness. Additionally, calling get_ascend_soc_version() once and storing it in a local variable would be more efficient.

        soc_version = get_ascend_soc_version()
        if soc_version == AscendSocVersion.A3 and self.mc2_tokens_capacity > 512:
            raise ValueError(
                f"On Ascend A3, the max number of tokens for mc2 must be smaller than or equal to 512, but it is {self.mc2_tokens_capacity}"
            )
        if soc_version == AscendSocVersion.A2 and self.mc2_tokens_capacity > 256:
            raise ValueError(
                f"On Ascend A2, the max number of tokens for mc2 must be smaller than or equal to 256, but it is {self.mc2_tokens_capacity}"
            )