[refact] unified soc_version code

[zzzzwwjj]

What this PR does / why we need it?

Currently, there are two paths to judge the chip type in code, get_ascend_soc_version use get_soc_version api in torch_npu, and is_310p use _build_info.__soc_version__, which generate when install. We need to unify the two paths.

We need to unify these codes based on the following points:

1. We need to ensure consistency in chip type judgment between compiling and running states;
2. In compiling state, we need chip type to complete op's compilation, but in running state, we only need device type(910B/910_93/310P/910_95/etc) to make code branch judgement;
3. In compiling state, torch_npu may not have been installed yet, so we can't use torch_npu's api.

Based on the above points, we have made the following changes:

1. When user set env SOC_VERSION, use it; when not set, query soc_version by npu-smi;
2. generate device_type based on soc_version when compiling, and write __device_type__ instead of __soc_version__ in _build_info.py;
3. In running state, use __device_type__ to judge code branch.

Does this PR introduce any user-facing change?

When not set env SOC_VERSION, it will not be ASCEND910B1 by default, we will query soc_version by npu-smi. And env SOC_VERSION must be in the list soc_to_device in setup.py.

How was this patch tested?

• vLLM version: v0.11.0
• vLLM main: vllm-project/vllm@2918c1b

[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

This pull request is a good refactoring that unifies the SoC version detection and usage across the codebase. By introducing get_chip_info() and centralizing the logic, the code becomes more robust and easier to maintain. The changes are consistently applied across all relevant files, including tests.

I've found a critical bug in the chip detection logic where a string is compared to an integer, which would lead to incorrect hardware detection. I've also added a couple of high-severity comments to improve the robustness of parsing npu-smi output and handling of the SOC_VERSION configuration. Addressing these points will make the implementation more solid.

[gemini-code-assist]

The chip_count variable is a string returned from get_value_from_lines. Comparing it with an integer 1 will always evaluate to False, which is a bug. It should be compared with the string '1'.

Suggested change

	return "ascend910b" if chip_count == 1 else "ascend910_93"
	return "ascend910b" if chip_count == '1' else "ascend910_93"

[gemini-code-assist]

The value returned from line.split(':')[-1] can have leading/trailing whitespace. This can lead to subtle bugs in comparisons later on. For example, if the output of npu-smi is Chip Count : 1, this function will return ' 1'.

Suggested change

	return line.split(':')[-1]
	return line.split(':')[-1].strip()

[gemini-code-assist]

The soc_version variable, which can be set from an environment variable, is used as a key for soc_version_dict without validation. If an unsupported soc_version is provided, this will cause a KeyError and crash the setup process with an unclear error message. It's better to validate soc_version first and provide a helpful error message.

Suggested change

	soc_version_dict = {
	"ascend310p": "310P",
	"ascend910b": "A2",
	"ascend910_93": "A3",
	}
	soc_version_dict = {
	"ascend310p": "310P",
	"ascend910b": "A2",
	"ascend910_93": "A3",
	}
	if soc_version not in soc_version_dict:
	raise ValueError(
	f"Unsupported SOC_VERSION: {soc_version}. Supported versions are: "
	f"{list(soc_version_dict.keys())}")

[whx-sjtu]

A variable name starting with _ generally indicates private usage, but the _310P here is actually directly used by other modules. Why use _310P instead of 310P here?

[zzzzwwjj]

cannot start with digit.

[whx-sjtu]

Add a warning here if user setting of SOC_VERSION doesn't match with results of get_chip_info()

[whx-sjtu]

What if user sets a value of SOC_VERSION with wrong format that doesn't match with any keys in soc_version_dict?

[github-actions]

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

[ChenxiQ]

LGTM

[whx-sjtu]

Why use 300I instead of 310P here? I think 300I is confused because there are machines like 300I A2.

[whx-sjtu]

ditto