[WIP] Update newest

[22dimensions]

What this PR does / why we need it?

Does this PR introduce any user-facing change?

How was this patch tested?

• vLLM version: v0.11.0
• vLLM main: vllm-project/vllm@2918c1b

[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 updates the codebase to support a newer version of the vLLM library. The changes primarily involve adapting to moved utility functions and API modifications. While the changes appear functional, there's a significant amount of code duplication introduced for handling version-dependent imports (e.g., cdiv, init_cached_hf_modules) across numerous files. I strongly recommend refactoring this logic into a centralized compatibility utility module to enhance maintainability. Additionally, there's duplicated logic in vllm_ascend/models/qwen2_5_vl.py for processing visual inputs that could be extracted into a helper method.

[gemini-code-assist]

This conditional import logic for cdiv is repeated in many other files (attention/mla_v1.py, core/scheduler.py, distributed/mooncake/config_data.py, patch/platform/patch_mamba_config.py, spec_decode/mtp_proposer.py, torchair/torchair_attention.py, torchair/torchair_mla.py, torchair/torchair_sfa.py, worker/block_table.py, worker/model_runner_v1.py). A similar pattern exists for init_cached_hf_modules in worker/worker_v1.py and its test file. This widespread duplication makes the code harder to maintain and prone to errors if future updates are needed.

To improve this, I suggest creating a central compatibility utility module (e.g., vllm_ascend/utils/compat.py) to house all such version-dependent imports. Then, other files can import cdiv, init_cached_hf_modules, etc., directly from this new module, centralizing the version-checking logic.

[gemini-code-assist]

This if/else block to handle different vLLM versions is duplicated in _process_video_input (lines 561-567). This duplicated logic should be extracted into a private helper method to improve code clarity and maintainability. For example, you could create a _run_visual method:

def _run_visual(self, pixel_values, grid_thw):
    if vllm_version_is("0.11.0"):
        return self.visual(pixel_values, grid_thw=grid_thw)
    else:
        with set_ascend_forward_context(None, self.vllm_config):
            return self.visual(pixel_values, grid_thw=grid_thw)

Then you can call this helper in both _process_image_input and _process_video_input.

            image_embeds = self._run_visual(pixel_values, grid_thw=grid_thw)

[gemini-code-assist]

This import of vllm_version_is is a duplicate of the one on line 7 and should be removed.

[github-actions]

This pull request has conflicts, please resolve those before we can evaluate the pull request.

[github-actions]

This pull request has conflicts, please resolve those before we can evaluate the pull request.

[github-actions]

This pull request has conflicts, please resolve those before we can evaluate the pull request.