fix: Npu Group MatMul op patchs only in EP

[0hujun]

PR type

• Bug Fix
• New Feature
• Document Updates
• More Models or Datasets Support

PR information

When Expert Parallelism (EP) is not enabled, each rank holds all expert weights.
weight.transpose(-2, -1) produces a large non-contiguous view that npu_grouped_matmul
forces to .contiguous() (~12.88 GB per MoE layer), creating a bandwidth bottleneck
that makes the NPU GMM patch ~8x slower than the native per-expert fallback.

When EP is enabled, each rank holds only a subset of expert weights — small and
contiguous — making npu_grouped_matmul efficient.

Experiment results

TWINKLE_NPU_GMM_PATCH=1

	EP>1	EP=1	Ratio
step 0 (warmup)	74.8s	126.6s	1.7x
step 1 (warmup)	25.8s	114.1s	4.4x
steps 3-9 avg (steady)	~14.4s	~118s	~8.2x

[gemini-code-assist]

Code Review

This pull request updates the NPU monkey patching logic to make the HuggingFace MoE Grouped MatMul (GMM) patch Expert Parallelism (EP) aware. It introduces _is_ep_enabled to check if EP is active and modifies the patching logic to skip GMM patching by default or when EP is not enabled, avoiding significant overhead from contiguous copies on transposed weights. The review comments point out two critical issues: a potential AttributeError when accessing model.device_mesh directly, and a logical contradiction where the default value for TWINKLE_NPU_GMM_PATCH is set to True instead of False, which conflicts with the intended behavior of skipping the patch by default when unset.