-
Notifications
You must be signed in to change notification settings - Fork 513
add mrope fusion op #3680
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
add mrope fusion op #3680
Conversation
Signed-off-by: shaopeng666 <[email protected]>
|
👋 Hi! Thank you for contributing to the vLLM Ascend project. The following points will speed up your PR merge:
If CI fails, you can run linting and testing checks locally according Contributing and Testing. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Code Review
This pull request introduces the MRotaryEmbedding to the vllm-ascend project, along with corresponding tests. The MRotaryEmbedding is integrated into the rotary embedding operations and registered as a custom operator. The changes include modifications to tests/ut/ops/test_rotary_embedding.py, vllm_ascend/ops/rotary_embedding.py, and vllm_ascend/utils.py. I have identified a critical issue related to the instantiation of MRotaryEmbedding in the test suite, where the incorrect class is being used, potentially leading to incorrect behavior during testing.
| self.layer = MRotaryEmbedding(self.head_size, | ||
| self.head_size, | ||
| self.max_position_embeddings, | ||
| base=self.rope_theta, | ||
| is_neox_style=self.is_neox_style, | ||
| dtype=torch.bfloat16, | ||
| mrope_section=self.mrope_section) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
critical: The test case is instantiating MRotaryEmbedding from vllm.model_executor.layers.rotary_embedding instead of vllm_ascend.ops.rotary_embedding.AscendMRotaryEmbedding. This will lead to incorrect behavior during testing, as the test will not be using the Ascend-specific implementation.
To fix this, import AscendMRotaryEmbedding from vllm_ascend.ops.rotary_embedding and use that class to instantiate self.layer.
| self.layer = MRotaryEmbedding(self.head_size, | |
| self.head_size, | |
| self.max_position_embeddings, | |
| base=self.rope_theta, | |
| is_neox_style=self.is_neox_style, | |
| dtype=torch.bfloat16, | |
| mrope_section=self.mrope_section) | |
| from vllm_ascend.ops.rotary_embedding import AscendMRotaryEmbedding | |
| self.layer = AscendMRotaryEmbedding(self.head_size, | |
| self.head_size, | |
| self.max_position_embeddings, | |
| base=self.rope_theta, | |
| is_neox_style=self.is_neox_style, | |
| dtype=torch.bfloat16, | |
| mrope_section=self.mrope_section) |
What this PR does / why we need it?
Add mrope fusion op for qwen2.5-vl. This mrope operator dosen't support Qwen3-VL currently. Thus could only take affect in qwen2.5-vl
Does this PR introduce any user-facing change?
How was this patch tested?