[NPU] Add capability-based Gemma RMSNorm dispatch

[TallMessiWu]

Important

WIP - please do not review this PR yet.

This PR is a concrete architecture-comparison branch. Please hold off on reviewing it until the WIP notice is removed.

Purpose of this draft

This draft provides a functionally equivalent alternative to #32745 together with sgl-project/sgl-kernel-npu#638, so we can compare the ownership boundary without comparing different feature coverage.

Both alternatives now implement the same product behavior:

Product family	Ordinary Gemma RMSNorm	Residual-add Gemma RMSNorm
Ascend 910B/910C	native ACLNN	native ACLNN
Ascend 950	existing sgl-kernel-npu Triton kernel	existing sgl-kernel-npu Triton kernel
unknown/unsupported	decomposed npu_rms_norm fallback	add plus decomposed npu_rms_norm fallback

Both GemmaRMSNorm and Gemma3RMSNorm delegate their ordinary and residual paths through the selected implementation.

The intended comparison is therefore only architectural:

• This PR ([NPU] Add capability-based Gemma RMSNorm dispatch #32908): SGLang detects the Ascend product family, owns the semantic capability matrix, and selects the native, Triton, or fallback provider through NPUDeviceOperator.
• PR 🐛 [NPU] Fix Qwen3.5 dense serving on Ascend 950 #32745 + sgl-kernel-npu#638: SGLang calls the unified logical kernel API, while sgl-kernel-npu owns product detection and provider selection.

The comparison should help determine the better long-term extension point for other operators with product-specific behavior, considering ownership, duplicated dispatch code, future Ascend products, dependency boundaries, and test surface.

Summary

• use formal Ascend 910B, 910C, and 950 product-family names in the cached SGLang capability layer
• model native and Triton Gemma RMSNorm availability as semantic features instead of generation helpers such as is_npu_a5()
• add an SGLang-side NPUDeviceOperator facade for ordinary and residual-add Gemma RMSNorm
• select native providers on Ascend 910B/910C, the existing sgl-kernel-npu Triton kernel on Ascend 950, and conservative decomposed fallbacks for unknown products
• support multidimensional, non-contiguous, and empty inputs in the Triton path
• route both GemmaRMSNorm and Gemma3RMSNorm ordinary/residual NPU paths through the facade
• preserve SGLANG_NPU_FORWARD_NATIVE_GEMMA_RMS_NORM as a debugging switch

Context

Qwen3.5 uses Gemma RMSNorm. The native npu_gemma_rms_norm operator is available on Ascend 910B/910C but has no registered kernel on Ascend 950, so directly calling it prevents Qwen3.5 from running on Ascend 950.

This PR intentionally keeps product detection and provider selection in SGLang. It depends only on the existing Triton Gemma kernel import path and does not require the new stable API proposed by sgl-project/sgl-kernel-npu#638.

Validation

• Windows standalone torch provider probe passed for product mapping, native, Triton, decomposed fallback, multidimensional non-contiguous input, and empty input behavior
• AST delegation probe passed for GemmaRMSNorm and Gemma3RMSNorm ordinary/residual paths
• py_compile, Black, isort, and git diff --check passed
• the registered pytest file could not be collected in the local Windows environment because the full SRT import chain requires the Unix-only resource module; it remains available for normal Linux CI
• Ascend 950 Qwen3.5 Dense W8A8 load, warmup, and deterministic request: TODO
• Ascend 910B/910C Qwen3.5 smoke and native-provider confirmation: TODO

Status

This remains a WIP comparison branch and is not proposed as a replacement for #32745 yet.

---

CI States

Latest PR Test (Base): ❌ Run #30529969847
Latest PR Test (Extra): ❌ Run #30529969638

[gemini-code-assist]

Caution

The consumer version of Gemini Code Assist on GitHub has been sunset. All code review activity has officially ceased.