-
-
Notifications
You must be signed in to change notification settings - Fork 10.4k
[FEAT] [Performance] Add triton mrope to replace the torch code path #22375
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
Conversation
Signed-off-by: tjtanaa <[email protected]>
👋 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 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 🚀 |
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 a Triton kernel for mrope
to improve performance, along with corresponding benchmarks and tests. I've identified two critical issues: a NameError
in the benchmark script due to an out-of-scope variable, and incorrect pointer arithmetic in the Triton kernel that could lead to out-of-bounds memory access. Please review the detailed comments for fixes.
q_size = num_heads * head_dim | ||
kv_size = num_kv_heads * head_dim | ||
is_neox_style = True | ||
mrope_section = config.rope_scaling["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.
The mrope_section
variable is defined only within this if __name__ == "__main__"
block, making it inaccessible to the benchmark_mrope
function. This will cause a NameError
when benchmark_mrope
is called on line 319. To fix this, pass config.rope_scaling["mrope_section"]
to the benchmark_mrope
function.
benchmark_mrope(
model_name=model_name,
num_tokens=num_tokens,
head_dim=head_dim,
tp_size=tp_size,
num_heads=num_heads,
num_kv_heads=num_kv_heads,
max_position=max_position,
rope_theta=rope_theta,
is_neox_style=is_neox_style,
rope_scaling=config.rope_scaling,
dtype=getattr(torch, args.dtype),
seed=args.seed,
warmup_iter=args.warmup_iter,
benchmark_iter=args.benchmark_iter,
csv_writer=csv_writer,
)
t_cos = cos + pid * half_hd | ||
h_cos = t_cos + num_tokens * half_hd | ||
w_cos = h_cos + num_tokens * half_hd | ||
t_sin = sin + pid * half_hd | ||
h_sin = t_sin + num_tokens * half_hd | ||
w_sin = h_sin + num_tokens * half_hd |
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.
The offsets for h_cos
, w_cos
, h_sin
, and w_sin
are calculated incorrectly, leading to out-of-bounds memory access. The correct offsets should account for the stride of the cos
and sin
tensors, which is num_tokens * half_hd
.
The current implementation calculates offsets for the h
and w
dimensions incorrectly:
h_cos = t_cos + num_tokens * half_hd
w_cos = h_cos + num_tokens * half_hd
This results in h_cos
pointing to an offset of (pid + num_tokens) * half_hd
from the base cos
pointer, which attempts to access cos[0, pid + num_tokens, :]
, an out-of-bounds read along the num_tokens
dimension.
To fix this, calculate the offsets relative to the base pointer and consider the stride of the first dimension.
t_cos = cos + pid * half_hd | |
h_cos = t_cos + num_tokens * half_hd | |
w_cos = h_cos + num_tokens * half_hd | |
t_sin = sin + pid * half_hd | |
h_sin = t_sin + num_tokens * half_hd | |
w_sin = h_sin + num_tokens * half_hd | |
dim0_stride = num_tokens * half_hd | |
token_offset = pid * half_hd | |
t_cos = cos + token_offset | |
h_cos = cos + dim0_stride + token_offset | |
w_cos = cos + 2 * dim0_stride + token_offset | |
t_sin = sin + token_offset | |
h_sin = sin + dim0_stride + token_offset | |
w_sin = sin + 2 * dim0_stride + token_offset |
Signed-off-by: tjtanaa <[email protected]>
/gemini review |
CC. @wuhuikx |
# vLLM Native implementation of mrope forward pass | ||
# used for benchmarking and unit testing | ||
def mrope_forward_native( | ||
positions: torch.Tensor, query: torch.Tensor, key: torch.Tensor, | ||
cos: torch.Tensor, sin: torch.Tensor, mrope_section: list[int], | ||
is_neox_style: bool, head_size: int, | ||
rotary_dim: int) -> tuple[torch.Tensor, Optional[torch.Tensor]]: | ||
"""PyTorch-native implementation equivalent to forward(). | ||
Args: | ||
positions: | ||
[num_tokens,] (text only) or | ||
[3, num_tokens] (T/H/W positions with multimodal inputs) | ||
query: [num_tokens, num_heads * head_size] | ||
key: [num_tokens, num_kv_heads * head_size] | ||
cos: [3, num_tokens, head_dim // 2] | ||
sin: [3, num_tokens, head_dim // 2] | ||
""" |
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.
Can you move this to MRotaryEmbedding
's forward_native
method?
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.
added back the forward_native code path
cc @sunway513 we have a triton kernel for mrope. |
Signed-off-by: tjtanaa <[email protected]>
Signed-off-by: tjtanaa <[email protected]>
@Isotr0py Ready for another round of review. Thank you. |
Signed-off-by: tjtanaa <[email protected]>
Can you address the pre-commit issue? |
Signed-off-by: tjtanaa <[email protected]>
Signed-off-by: tjtanaa <[email protected]>
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.
LGTM now!
@Isotr0py Thank you very much for reviewing this PR and help me to iterate through at a very fast pace. Amazing ! |
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.
PR looks good for me!
Only one thought. When I experimented with covered vision part with torch.compile the performance of mrope looked good as well. I'm not sure what would better this PR or torch.compile. Like the kernel itself here is better but torch.compile have benefits from fusion with around kernels.
…llm-project#22375) Signed-off-by: tjtanaa <[email protected]> Signed-off-by: Paul Pak <[email protected]>
…llm-project#22375) Signed-off-by: tjtanaa <[email protected]> Signed-off-by: Diego-Castan <[email protected]>
…llm-project#22375) Signed-off-by: tjtanaa <[email protected]>
…llm-project#22375) Signed-off-by: tjtanaa <[email protected]>
…llm-project#22375) Signed-off-by: tjtanaa <[email protected]> Signed-off-by: Xiao Yu <[email protected]>
…llm-project#22375) Signed-off-by: tjtanaa <[email protected]>
Essential Elements of an Effective PR Description Checklist
supported_models.md
andexamples
for a new model.Purpose
This is to optimize the mrope forward pass using a triton kernel adapted from https://github.com/linkedin/Liger-Kernel/blob/main/src/liger_kernel/ops/qwen2vl_mrope.py to supports flatten input tensors from vLLM and and supports cos and sin cache with shape (3, num_tokens, head_dim // 2)
Related to #22293
Test Plan
Test Result
Kernel test: Passed
Kernel level improvement over torch implementation: ~ 2 ~ 3x
mrope_benchmark_results_20250806_173029.csv
lm_eval
Base Line:
After PR:
Benchmark command
server:
client:
(Optional) Documentation Update