[Refactor][Config] Remove FlashComm1 environment variable

[kk-ss1999]

What this PR does / why we need it?

Removes the legacy VLLM_ASCEND_ENABLE_FLASHCOMM1 environment variable after its behavior was migrated to additional_config.enable_flashcomm1. Runtime code, deployment examples, test configurations, and documentation are migrated to the config field where applicable.

This is one independently reviewable part of the seven-variable split of #14637.

Does this PR introduce any user-facing change?

Yes. VLLM_ASCEND_ENABLE_FLASHCOMM1 is no longer read. Users must configure the behavior with --additional-config '{"enable_flashcomm1":true}'.

How was this patch tested?

• ruff check and ruff format --check on changed Python files

• Python byte-compilation of changed Python files

• YAML parsing of changed YAML files

• JSON parsing of concrete additional-config payloads

• Scan confirming no active references to VLLM_ASCEND_ENABLE_FLASHCOMM1 remain outside migration documentation and the ignored-variable unit test

• NPU end-to-end tests were not run in this Windows environment

• vLLM version: v0.27.1

• vLLM main: vllm-project/vllm@58d3918

[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 completes the migration of the legacy VLLM_ASCEND_ENABLE_FLASHCOMM1 environment variable to the additional_config JSON configuration structure. This change simplifies configuration management by centralizing settings within the additional-config payload, ensuring consistency across various deployment scenarios and test suites.

Highlights

• Environment Variable Removal: Removed the legacy VLLM_ASCEND_ENABLE_FLASHCOMM1 environment variable, which is no longer read by the runtime.
• Configuration Migration: Migrated the functionality of VLLM_ASCEND_ENABLE_FLASHCOMM1 to the additional_config.enable_flashcomm1 configuration field.
• Documentation and Test Updates: Updated deployment tutorials, developer guides, and test configurations to reflect the new configuration method.

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.

[gemini-code-assist]

Code Review

Suggested PR Title:

[Ops][Misc] Remove legacy VLLM_ASCEND_ENABLE_FLASHCOMM1 env var in favor of additional-config

Suggested PR Summary:

### What this PR does / why we need it?

This PR removes the legacy `VLLM_ASCEND_ENABLE_FLASHCOMM1` environment variable, fully transitioning the enablement of FlashComm1 optimization to the `--additional-config '{"enable_flashcomm1": true}'` option. This cleanup spans across documentation, test configurations, and core codebase. Additionally, two potential crashes were identified in the test feature extraction scripts where missing or non-dictionary JSON configurations could trigger `AttributeError`s.

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

Yes, the legacy `VLLM_ASCEND_ENABLE_FLASHCOMM1` environment variable is no longer supported. Users must now use `--additional-config '{"enable_flashcomm1": true}'` to enable FlashComm1 optimization.

### How was this patch tested?

Tested via updated E2E nightly single-node and multi-node test configurations, along with unit tests in `tests/ut/test_ascend_config.py`.

[gemini-code-assist]

There are two issues with this implementation:

1. If json.loads parses a non-dictionary JSON value (such as a list, string, or number), config will not have a .get method, resulting in an AttributeError that crashes the script. We should verify that config is a dictionary before calling .get().
2. Returning features early from inside the loop prevents any subsequent feature extraction logic from executing if more checks are added to this function in the future. It is safer to use a flag and break the loops instead of returning early.

    has_flashcomm1 = False
    for command in commands:
        for flag in ("--additional-config", "--additional_config"):
            try:
                config = json.loads(command.cmd[command.cmd.index(flag) + 1])
                if isinstance(config, dict) and config.get("enable_flashcomm1"):
                    has_flashcomm1 = True
                    break
            except (ValueError, IndexError, json.JSONDecodeError):
                continue
        if has_flashcomm1:
            features.append("flashcomm1")
            break

[gemini-code-assist]

If _parse_json_flag returns None (e.g., when the flag is not found or parsing fails), additional will be None. This will cause an AttributeError when calling additional.get(config_key) or additional.get("enable_weight_nz_layout") later in the function. Appending or {} ensures additional is always a dictionary and prevents potential crashes.

Suggested change

	additional = _parse_json_flag(cmd_list, "--additional-config") or _parse_json_flag(cmd_list, "--additional_config")
	for config_key, feature_name in _FEATURE_CONFIGS.items():
	if additional.get(config_key):
	features.append(feature_name)
	additional = _parse_json_flag(cmd_list, "--additional-config") or _parse_json_flag(cmd_list, "--additional_config") or {}
	for config_key, feature_name in _FEATURE_CONFIGS.items():
	if additional.get(config_key):
	features.append(feature_name)

[github-actions]

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