[lczgreat1222]

What this PR does / why we need it?

The docs contain isolated --device-ids examples but do not explain how integer IDs compose with ASCEND_RT_VISIBLE_DEVICES. For example, visibility 4,5,6,7 plus --device-ids 3,1 selects 7,5; treating both settings as physical IDs can select the wrong devices or fail validation.

Add a central NPU Device Selection guide with a mapping table, single-node multiprocessing TP/DP examples, disjoint P/D device assignments, and allocation checks. Explain that the visibility variable remains supported and that Ray ignores --device-ids in favor of placement groups. Link the guide from configuration, environment-variable, Ray, and single-node PD documentation.

Does this PR introduce any user-facing change?

No runtime or API changes. Documentation only; no release-note fragment is needed.

How was this patch tested?

• python -m mkdocs build --site-dir <temporary-output>: passed; no link/anchor diagnostics for the changed pages. The build reports existing unrelated anchor notices.
• markdownlint v0.45.0 on all five changed Markdown pages, using the repository configuration: passed.
• git diff --check: passed.
• Cross-checked argument resolution and DP slicing against the pinned vLLM commit 24420b7a341af37a9bc3186e6fc6062512e0aa58, plus current Ascend worker device initialization.
• Attempted the required bash format.sh ci on Windows. Stopped after dependency setup stalled while installing the actionlint environment; the full repository check has not passed locally and remains for CI. The focused Markdown check above completed separately.

No NPU workload was rerun for this documentation-only patch. The PD table describes device assignment, not a complete deployment command, and links to the existing connector tutorials.

---

Checklist

Testing

Runtime test checklist items are not applicable to this documentation-only change.

• Boundary / edge-case coverage

• Regression test

• Error / failure path coverage

• Meaningful & reliable tests

• Performance impact

• vLLM main: vllm-project/vllm@24420b7

[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 introduces a centralized documentation guide for NPU device selection in vLLM-Ascend. The primary goal is to resolve ambiguity regarding how environment-level visibility settings interact with command-line device IDs, providing clear mapping tables and usage examples for various deployment scenarios including multiprocessing, DP, and PD disaggregation. The changes ensure users can correctly configure their environments and avoid common pitfalls when managing NPU resources.

Highlights

• New NPU Device Selection Guide: Added a comprehensive documentation page explaining the interaction between ASCEND_RT_VISIBLE_DEVICES and --device-ids for NPU device selection.
• Configuration Examples: Included detailed examples for multiprocessing, data parallelism (DP), and prefill-decode (PD) disaggregation to clarify device assignment.
• Ray Integration Clarification: Explicitly documented that --device-ids is ignored by Ray, which relies on placement groups for resource allocation.
• Documentation Navigation: Updated the mkdocs.yml navigation and added cross-references in existing configuration and tutorial pages to improve discoverability.

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

[gemini-code-assist]

Code Review

This pull request introduces a new documentation page, 'device_selection.md', which provides a comprehensive guide on NPU Device Selection for vLLM Ascend. It details the interaction between the 'ASCEND_RT_VISIBLE_DEVICES' environment variable and the '--device-ids' argument, offering clear examples for Tensor Parallelism, Data Parallelism, Prefill-Decode disaggregation, and Ray. The new guide is integrated into the existing documentation and navigation. The reviewer provided a suggested PR Title and PR Summary in markdown code blocks, adhering to the repository's style guide.

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