Adopt inductor fusion and define quantization fusion pass

[wxsIcey]

What this PR does / why we need it?

Adopt inductor fusion and define quantization fusion pass
refer to vllm-project/vllm#23612
needs vllm-project/vllm#28623

Does this PR introduce any user-facing change?

Yes, add new additional_config

How was this patch tested?

def main():
    prompts = [
        "The president of the United States is Mr.",
    ]

    # Create a sampling params object.
    sampling_params = SamplingParams(max_tokens=100, temperature=0.6, top_k=40, top_p=0.95)
    # Create an LLM.
    llm = LLM(
        model="/root/.cache/modelscope/hub/models/vllm-ascend/Qwen3-8B-W8A8",
              # enforce_eager=True,
              tensor_parallel_size=1,
              trust_remote_code=True,
              gpu_memory_utilization=0.7,
              quantization="ascend",
              )

    # Generate texts from the prompts.
    outputs = llm.generate(prompts, sampling_params)
    for output in outputs:
        prompt = output.prompt
        generated_text = output.outputs[0].text
        print(f"Prompt: {prompt!r}, Generated text: {generated_text!r}")

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

[github-actions]

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

[wxsIcey]

Currently, operator fusion has been achieved through pattern matching using inductors. Using aot-autograd could be a future work, but it has been found that using aot-autograd causes accuracy issues. @whx-sjtu Would you be willing to review it?

[whx-sjtu]

Nice work. Finally we make it to utilize pattern_matcher of inductor to fuse our add_rms_norm_quant kernel into Fx graph. The whole idea looks good to me with some questions about details as reviewed following.

[whx-sjtu]

The name AscendAdaptor is too vague; I suggest a more specific one like AscendCompiler.

[whx-sjtu]

Instead of fixed to 1e-6, the eps should be defined as a static variable of AddRMSNormQuantPattern, with different values of eps corresponding to different pattern objects. Some models might use different eps like 1e-5.

[whx-sjtu]

The name of self.patterns is a bit confusing here. It should be named as something like self.pattern_match_pass.

[whx-sjtu]

I don't quiet understand here. Does the format of data also influence pattern matching? Maybe we can define patterns separately for bf16 and fp16 to support them both?

[whx-sjtu]

I have another question here. With current proposal can we reuse the ready-made fusion passes defined in vLLM, like the SequenceParallel Fusion Pass. Because I'm not very familiar with the stack of the current Fusion pass in vLLM, I'm confirming it here. Reusability is what we expect.

[whx-sjtu]

This feature is very important for vllm-ascend. I also hope @jgong5 can take some time to review this PR. Thanks.

[wxsIcey]

I have another question here. With current proposal can we reuse the ready-made fusion passes defined in vLLM, like the SequenceParallel Fusion Pass. Because I'm not very familiar with the stack of the current Fusion pass in vLLM, I'm confirming it here. Reusability is what we expect.

Thank you for your reply. The current PR aims to define our own compiler backend to implement custom fusion. Reusing fusion passes in VLLM is my next goal. I will submit an RFC once the solution is finalized.