[BugFix][xlite] Fix DP metadata handling in XliteWrapper and pass down the max number of tokens across all DP ranks for collective communications.

[SijieFu]

What this PR does / why we need it?

Fix XliteWrapper to consume the correct DP metadata and align the max number of tokens across all DP ranks for collective communications, and bump the pinned xlite dependency to 0.2.0rc0.

Why: Under data parallelism (DP), each DP rank serves a different number of tokens, but the xlite runtime issues collective communications that require every rank to pass an identical, padded token count. Previously XliteWrapper read forward_context.batch_descriptor.num_tokens (the per-rank token count) and sized the working hidden_states slice from it. That value diverges across DP ranks, so the collectives mismatched and produced wrong/unaligned results.

The fix sources the token count from forward_context.max_tokens_across_dp, which the vLLM-Ascend forward context already computes as max(num_tokens_across_dp_cpu) and pads to a TP-aligned length — the same value the rest of the stack uses for MoE comm method selection.

The detailed issue can be found in xlite repo's issue #15. And xlite PR #339 fixes this issue in xlite backend.

What changed (vllm_ascend/xlite/xlite.py):

• In the xlite forward path, num_tokens is now taken from forward_context.max_tokens_across_dp instead of forward_context.batch_descriptor.num_tokens. The hidden-states buffer slice self.hidden_states[:num_tokens] is therefore sized to the DP-aligned maximum, keeping all ranks in lock-step for the underlying collectives. The comment is updated to record that, under DP, num_tokens is the max number of tokens across all DP ranks for data alignment.
• XliteWrapper.__init__ no longer derives local_rank from get_world_group().local_rank; the runtime devid is now device.index and rank is torch.distributed.get_rank() directly. get_world_group is dropped from the imports, and the one-shot rank/local_rank locals are inlined at their use sites.
• StandardXliteModel: xlite_config.max_m (the full-mode capacity) is now rounded up with math.ceil(max_num_batched_tokens / tp_size) * tp_size so it is TP-aligned and consistent with the downstream.
• MiniMaxM2XliteModel: sets xlite_config.gate_captured = False.
• requirements-dev.txt: xlite==0.1.0rc12.dev210 → xlite==0.2.0rc0 to pick up the upstream runtime fixes that the metadata alignment above relies on.

DP test cases were also added to the e2e script at tests/e2e/pull_request/two_card/test_xlite.py.

Does this PR introduce any user-facing change?

No public API change. This fixes an internal correctness bug in XliteWrapper's DP metadata handling and bumps the dev-only xlite pin in requirements-dev.txt. Serving behavior for non-DP xlite configurations is unchanged; DP configurations now use the DP-aligned token count for collective communications.

How was this patch tested?

The e2e test passes locally with pytest tests/e2e/pull_request/two_card/test_xlite.py.

We also benchmarked model accuracies with multiple models using aisbench. The batch_aisbench.py script was used with the ceval dataset, comparing xlite full, xlite decode-only, and aclgraph backends across dense, MoE, and DP configurations:

# on one Atlas A3
python batch_aisbench.py /root/benchmark \
-N 128 \
--models Qwen3-32B Qwen3-VL-32B-Instruct 2~Qwen3-30B-A3B 2~MiniMax-M2.7-w8a8-QuaRot 2~GLM-4.7-W8A8-floatmtp \
--tps 4 4 4 2 8 4 8 4 \
--dps 1 1 1 1 1 2 1 2 \
--eps 0 0 1 1 1 1 1 1 \
-MNS 128 \
-MML 8192 \
--xlite 2 1 0 \
--broadcast-xlite

No accuracy regression is observed across the full matrix relative to the aclgraph baseline:

Model	Dataset	TP	EP	DP	Backend	Metric	Accuracy
Qwen3-32B	ceval-weighted	4	N	1	xlite full	weighted_average	88.26
Qwen3-32B	ceval-weighted	4	N	1	xlite decode-only	weighted_average	88.19
Qwen3-32B	ceval-weighted	4	N	1	aclgraph	weighted_average	86.70

Model	Dataset	TP	EP	DP	Backend	Metric	Accuracy
Qwen3-VL-32B-Instruct	ceval-weighted	4	N	1	xlite full	weighted_average	86.92
Qwen3-VL-32B-Instruct	ceval-weighted	4	N	1	xlite decode-only	weighted_average	86.85
Qwen3-VL-32B-Instruct	ceval-weighted	4	N	1	aclgraph	weighted_average	87.44

Model	Dataset	TP	EP	DP	Backend	Metric	Accuracy
Qwen3-30B-A3B	ceval-weighted	4	Y	1	xlite full	weighted_average	85.22
Qwen3-30B-A3B	ceval-weighted	4	Y	1	xlite decode-only	weighted_average	85.74
Qwen3-30B-A3B	ceval-weighted	4	Y	1	aclgraph	weighted_average	85.74
Qwen3-30B-A3B	ceval-weighted	2	Y	1	xlite full	weighted_average	85.74
Qwen3-30B-A3B	ceval-weighted	2	Y	1	xlite decode-only	weighted_average	86.11
Qwen3-30B-A3B	ceval-weighted	2	Y	1	aclgraph	weighted_average	85.14

Model	Dataset	TP	EP	DP	Backend	Metric	Accuracy
MiniMax-M2.7-w8a8-QuaRot	ceval-weighted	8	Y	1	xlite full	weighted_average	82.24
MiniMax-M2.7-w8a8-QuaRot	ceval-weighted	8	Y	1	xlite decode-only	weighted_average	82.76
MiniMax-M2.7-w8a8-QuaRot	ceval-weighted	8	Y	1	aclgraph	weighted_average	81.80
MiniMax-M2.7-w8a8-QuaRot	ceval-weighted	4	Y	2	xlite full	weighted_average	83.43
MiniMax-M2.7-w8a8-QuaRot	ceval-weighted	4	Y	2	xlite decode-only	weighted_average	84.03
MiniMax-M2.7-w8a8-QuaRot	ceval-weighted	4	Y	2	aclgraph	weighted_average	82.47

Model	Dataset	TP	EP	DP	Backend	Metric	Accuracy
GLM-4.7-W8A8-floatmtp	ceval-weighted	8	Y	1	xlite full	weighted_average	90.71
GLM-4.7-W8A8-floatmtp	ceval-weighted	8	Y	1	xlite decode-only	weighted_average	91.01
GLM-4.7-W8A8-floatmtp	ceval-weighted	8	Y	1	aclgraph	weighted_average	90.49
GLM-4.7-W8A8-floatmtp	ceval-weighted	4	Y	2	xlite full	weighted_average	90.12
GLM-4.7-W8A8-floatmtp	ceval-weighted	4	Y	2	xlite decode-only	weighted_average	90.56
GLM-4.7-W8A8-floatmtp	ceval-weighted	4	Y	2	aclgraph	weighted_average	90.27

• vLLM version: v0.26.0
• vLLM main: vllm-project/vllm@0351e9a

[gemini-code-assist]

Summary of Changes

Hello, I'm Gemini Code Assist¹! I'm currently reviewing this pull request and will post my feedback shortly. In the meantime, here's a summary to help you and other reviewers quickly get up to speed!

This pull request addresses a metadata handling issue in the xlite backend when Data Parallelism (DP) is enabled. By calculating and passing the maximum number of tokens across all DP ranks, the change ensures that collective communications in MoE layers remain symmetric, preventing potential errors during model execution.

Highlights

• DP Metadata Integration: Imported DPMetadata from vllm.forward_context to handle data parallel configurations.
• Token Count Alignment: Updated XliteWrapper to calculate the maximum number of tokens across all DP ranks when data parallelism is enabled, ensuring consistent collective communication in MoE layers.
• Refactored Metadata Routing: Moved the initialization of AttnMetadataRouter to occur after the early exit check for xlite graph usage to optimize performance.

New Features

🧠 You can now enable Memory (public preview) to help Gemini Code Assist learn from your team's feedback. This makes future code reviews more consistent and personalized to your project's style. Click here to enable Memory in your admin console.

Using Gemini Code Assist

The full guide for Gemini Code Assist can be found on our documentation page, here are some quick tips.

Invoking Gemini

You can request assistance from Gemini at any point by creating a comment using either /gemini <command> or @gemini-code-assist <command>. Below is a summary of the supported commands on the current page.

Feature	Command	Description
Code Review	/gemini review	Performs a code review for the current pull request in its current state.
Pull Request Summary	/gemini summary	Provides a summary of the current pull request in its current state.
Comment	@gemini-code-assist	Responds in comments when explicitly tagged, both in pull request comments and review comments.
Help	/gemini help	Displays a list of available commands.

Customization

To customize the Gemini Code Assist for GitHub experience, repository maintainers can create a configuration file and/or provide a custom code review style guide (such as PEP-8 for Python) by creating and adding files to a .gemini/ folder in the base of the repository. Detailed instructions can be found here.

Limitations & Feedback

Gemini Code Assist may make mistakes. Please leave feedback on any instances where its feedback is incorrect or counterproductive. You can react with 👍 and 👎 on @gemini-code-assist comments. If you're interested in giving your feedback about your experience with Gemini Code Assist for GitHub and other Google products, sign up here.

Footnotes

1. Review the Privacy Notices, Generative AI Prohibited Use Policy, Terms of Service, and learn how to configure Gemini Code Assist in GitHub here. Gemini can make mistakes, so double check it and use code with caution. ↩

[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.

---

Tip

💡 Consider Linking a Related Issue or RFC

Your PR title contains the [BugFix] tag, indicating a bug fix or new feature.

Linking a related issue or RFC in the PR description is strongly encouraged — it gives reviewers helpful context and speeds up the review. You can use any of these keywords:

• Fixes #<issue_number>
• Closes #<issue_number>
• Resolves #<issue_number>
• Refs #<rfc_or_issue_number> (for RFCs)

🙏 Thanks for helping us keep the project well-organized!

[gemini-code-assist]

Code Review

Suggested PR Title:

[Ops][Feature] Support Data Parallelism alignment in XLite graph runner

Suggested PR Summary:

### What this PR does / why we need it?
This PR introduces support for Data Parallelism (DP) alignment in the XLite graph runner. Specifically, when `data_parallel_size > 1`, `num_tokens` is determined by the maximum number of tokens across all DP ranks. It also defers the instantiation of `AttnMetadataRouter` to avoid unnecessary overhead when falling back to the runnable.

Feedback: A potential `AttributeError` was identified because `forward_context.dp_metadata` can be `None` during profiling or warmup runs. A defensive check should be added to ensure `dp_metadata` is not `None` before accessing its attributes.

### Does this PR introduce _any_ user-facing change?
No.

### How was this patch tested?
CI testing with DP configurations.

[github-actions]

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