[ischencheng]

Part of #671, the qwen4exp entry of the last known issue (NVFP4 GGUF .scale still refused).

#732 applies the .scale (weight_scale_2) of NVFP4 GGUF tensors on every GPU and CPU path, but left qwen4exp refusing them because no NVFP4 qwen4exp GGUF had been tested. There is one on HF now that llama.cpp's converter wrote: magnitudedev/Qwen3.8-Flash-Next-NVFP4-GGUF, converted from nvidia/Qwen3.8-Flash-Next-NVFP4. Its routed experts are NVIDIA's NVFP4 weights with per-expert .scale and .input_scale; everything else, the n-gram table included, is Q8_0. On main it does not start:

NotImplementedError: .../Qwen3.8-Flash-Next-NVFP4-00001-of-00003.gguf: GGUF tensors with per-tensor scales are not supported (e.g. blk.0.ffn_down_exps.input_scale)

This PR makes the qwen4exp loader call check_scales() like the other families. Nothing else is qwen4exp-specific: the expert scales go through the global bank and the gguf_scaled CPU format from #732, and dense linears through fused(). The PLE table is the one qwen4exp tensor whose readers take no weight scale, so a per_layer_token_embd.scale is still refused.

Tested on H200 (sm_90, 141 GB) and L4 (sm_89, 24 GB), driver 610.57.04, CUDA 13.0, torch 2.14.1+cu130, Triton 3.8.0, on top of ecbbce4; unit tests on A10. On H200 the test container had 16 cores of an AMD Zen 4 CPU (the CPU MoE executor picked isa=zen4) and 192 GB of RAM; on L4, 16 cores and 128 GB.

ft serve --model Qwen3.8-Flash-Next-NVFP4-00001-of-00003.gguf --max-seq-len-override 4096 --max-running-requests 16 <strategy flags>
  fused:   --moe-strategy fused
  offload: --moe-strategy offload --moe-cache-rate 0.25
  hybrid:  --moe-strategy hybrid --moe-cache-rate 0.25 --moe-hybrid-max-fetch 0 --moe-cpu-threads 16
  cpu:     --moe-strategy cpu --moe-cpu-threads 16

The PLE table stays on the default --ple-backend disk. Requests: 4 greedy /v1/completions streamed one at a time (128 tokens, ignore_eos), then 16 greedy Question: what is a * b?\nAnswer: a * b = sent together. hybrid with --moe-hybrid-max-fetch 0 sends most routes to the CPU executor, which logs fmt=gguf_scaled(gate_up=NVFP4, down=NVFP4).

On H200:

	tokens identical to llama.cpp, 4 prompts (of 128)	tokens identical to fused	products correct	bs=1 tok/s
fused	26, 86, 128, 69	-	16/16	113-115
offload	26, 86, 128, 69	128, 128, 128, 128	16/16	65-80
hybrid	126, 128, 128, 69	26, 86, 128, 128	16/16	33-35
cpu	126, 128, 128, 69	26, 86, 128, 128	16/16	34-35
fused, expert scales forced to 1	0, 0, 0, 0	0, 0, 0, 0	0/16	-
llama.cpp	-	-	16/16	-

hybrid and cpu give the same tokens as each other on all 20 requests, and the burst answers are the same text on every strategy. With every expert scale read as 1 (_expert_scales in models/gguf/experts.py patched to return ones), the streamed prompts turn into !!!! after the first token and no product is right, so these comparisons do see the scales.

The llama.cpp column is llama-server from llama.cpp 418f905a4e on the same files (-ngl 999 -c 4096, /completion with temperature 0, top-k 1, the same prompt texts, n_probs 2). At each place where an output parts from llama.cpp's, llama.cpp's own top token has a log-prob between -0.68 and -1.23 and its top two are 0.13 to 0.35 apart, and both texts go on coherently. 15 of the 16 burst answers are the same text as llama.cpp's; the other has the same product and one more newline after it.

On L4 (24 GB) with --moe-strategy hybrid --moe-cache-auto --moe-cpu-threads 16, the way it would be started on a smaller card: --moe-cache-auto picked 1530 cache slots, the CPU executor ran gguf_scaled on a Cascade Lake host (isa=cascadelake), and the decode cache hit rate was 28-57%, with 3.4-7.0 routes per layer step on the CPU. 16/16 products correct, 21-22 tok/s at bs=1. The 4 prompts match llama.cpp for 0, 128, 128 and 119 tokens; at the two places they part, llama.cpp's own top two are 0.015 and 0.048 apart. 15 of the 16 burst answers are the same text as llama.cpp's; the other has the same product and one more newline after it.

python scripts/gguf_check/check.py on header stubs of the NVFP4 GGUF files of 36 HF repos (126 files of served architectures): the two qwen4exp files, magnitudedev's and auto7x/OrcaRouter-Qwen3.8-Flash-Next-Uncensored-ModelOpt-NVFP4-GGUF's orca-nvfp4.gguf, go from refused to pass. The auto7x repo keeps its n-gram table in a separate GGUF, so I did not serve it. fairfieldt/Qwen3.8-Flash-Next-NVFP4-QAD-GGUF uses ggml type 100, which gguf-py does not know, and fails the same way on both.

pytest tests/models tests/kernels/test_ggml.py tests/moe/test_cpu_moe.py tests/moe/test_mixed_expert_formats.py -m "not slow" on A10: 422 passed, 189 skipped on main and with this PR.

No new test: the loaders' check_scales() calls have none, and the end-to-end runs above are what shows the scales are right. I can add one under tests/models/qwen4_exp/ if you want it.

Not covered: the other refused families (glm4moe, qwen2, minimax-m2, minimax-m3, muse-glimmer); I found no NVFP4 GGUF of glm4moe or minimax-m3 on HF. ROCm was not run.