perf: N-based tile selection for XPU bf16/fp16 MoE grouped GEMM

[Copilot]

Description

The XPU bf16/fp16 MoE grouped GEMM (ark.moe_gemm, the accumulation path for MoE prefill) used a single hard-coded 256x128 (8x2) work-group tile for every shape, leaving the large-N up/down projections that dominate prefill under-tiled. Following the w16a16 large-M tile-policy heuristic in vllm-project/vllm-xpu-kernels, the launcher now selects the tile from the output width N.

Changes (auto_round_extension/ark/auto_round_kernel/wrapper/include/sycl_tla_moe.hpp):

• Templatized the launcher — moe_gemm_launcher / choose_tiled_mma are now parameterized over WGTile / SGLayout; the scheduler TileShape tracks the same WGTile.
• N-based dispatch in moe_gemm, mirroring vLLM's large-M branch:
  • N ≤ 64 → 256x64x32, SGLayout 8x1
  • N ≤ 512 → 256x128x32, SGLayout 8x2 (historical default)
  • N > 512 → 256x256x32, SGLayout 8x4
• Copy atoms unchanged — all three policies keep 8 sub-group rows in M, so the per-sub-group tile stays 32x64x32 and the existing XE_LOAD_2D / XE_LOAD_2D_VNNI / XE_STORE_2D atoms remain valid (vLLM uses the identical XE_STORE_2D<16,8,32> for its 256x256 policy).
• Unique kernel names — the SYCL kernel-name tag is parameterized by the tile policy.
• Escape hatch — ARK_MOE_GEMM_FIXED_TILE=1 forces the historical fixed 256x128 tile for per-device tuning/regressions.
• Docs — heuristic and env flag documented in README_MOE_PREFILL_PERF.md and its CN counterpart.

The benchmarked shapes in test_moe_prefill_perf.py (N=1536 up-proj, N=3072 down-proj) both fall in the N>512 bucket and now use the 256x256 tile.

Type of Change

Performance

Related Issues

Checklist Before Submitting

• My code has been tested locally.
• Documentation has been updated as needed.
• New or updated tests are included where applicable.
• The CUDA CI has passed. You can trigger it by commenting /azp run Unit-Test-CUDA-AutoRound.

Note: This change targets XPU kernels and could not be compiled or benchmarked in the development sandbox (no XPU device / oneAPI toolchain; the MoE kernel is a header-only FetchContent dependency from luoyu-intel/sycl-tla). On-device validation with pytest -v -s auto_round_extension/ark/test/test_moe_prefill_perf.py is recommended before merge to confirm the expected TFLOPS gain and numerical parity.