[AMD] [GLM-5.3-Flash Day 0] Support Quark checkpoints that mix MXFP4 with explicit block FP8

[Jacob0226]

Summary

Quark can export a model whose global scheme is MXFP4 while pinning individual layers to block FP8 in layer_quant_config. apply_weight_name_mapper rewrote only exclude_layers, so that dict kept the checkpoint's own weight names, every lookup missed, and the layer silently fell back to global MXFP4 — wrong precision, no error. _find_matched_config could not express "no explicit entry" either, because a miss returned the global config. This splits out _find_matched_layer_config, which returns None, and routes pinned layers to Fp8LinearMethod / Fp8MoEMethod.

Resolved scheme for amd/GLM-5.3-Flash-Quark-MXFP4, queried with runtime layer names:

Layer	before	after
model.layers.7.self_attn.q_a_proj	fp4 per_group	fp8_e4m3 per_block [128,128]
model.layers.45.mlp.experts.7.up_proj	fp4 per_group	fp8_e4m3 per_block [128,128]
model.layers.3.mlp.experts.0.up_proj	fp4 per_group	fp4 per_group
visual.blocks.0.attn.qkv_proj	not excluded	excluded

All 924 layer_quant_config entries in that checkpoint are block FP8.

Scope

Quark checkpoints only, no hardware gate. Resolution is unchanged for a checkpoint with no layer_quant_config and for a model defining no hf_to_sglang_mapper: the new helper returns None and the wrapper falls back to the global config exactly as before. It does change for an existing Quark checkpoint that pins layers to per_block FP8 — those now reach the FP8 methods instead of the Quark scheme, which is the intent. Other quantization backends are untouched.

#38546 owns the MXFP4 MoE weight and runner path; this PR only decides which quantization method each layer is given.

Also changed	Fires when
Fused shards partially specified now raise	layer_quant_config names some but not all shards of one fused module
should_ignore_layer direct-name match	An exclude entry names an already-fused module, e.g. a pre-fused vision qkv
kv_cache_group routed through the mapper	The model defines hf_to_sglang_mapper and the checkpoint sets that group

Test plan

The resolution table above isolates this PR as the single variable; it and the companion model-side PR #38999 are needed together, so accuracy is for the stack. Both rows below differ only in the checkpoint.

Image	rocm/sgl-dev:v0.5.19-rocm720-mi35x-20260909, AITER 4ad99832
Base	main 480b14eda + #38541–#38547 + #38999
Hardware	MI355X gfx950, TP4, decode CUDA graphs active
Sampling	--thinking, temperature 1.0, top-p 0.95, max 4,096 output tokens

Checkpoint	Examples	Score	stop	truncated	error
zai-org/GLM-5.3-Flash, block FP8	1,319	97.50%	99.85%	0.15%	0.00%
amd/GLM-5.3-Flash-Quark-MXFP4	1,319	96.89%	99.39%	0.61%	0.00%

MXFP4 lands 0.61 points below block FP8, one pass each — at the edge of this model's run-to-run spread rather than inside it: six reference runs spanned 96.82% to 97.35%, and #36607 measured 97.19% for this checkpoint at TP4. Read it as parity pending a repeat pass, not a demonstrated regression.

test_quark_config.py and test_quark_utils.py: 26 passed. isort, black and Ruff clean.

[Jacob0226]

Closing as superseded.

The config-resolution work here is now carried by #38546: routing layer_quant_config (and kv_cache_group) through the model's weight-name mapper, splitting out _find_matched_layer_config so a miss returns None instead of the global config, and dispatching explicitly pinned layers to Fp8LinearMethod / Fp8MoEMethod.

The should_ignore_layer direct fused-name match is carried by #39317, which goes further than this PR did and also honors per-expert exclusions.

Between them the MXFP4 checkpoint resolves correctly, so there is nothing left here that is not covered.