MoE routing-instability under quantization (VSRAQ / EAQuant routing-consistency alignment)

NOT A DISTINCT FORMAT - DECLARED 2026-10-04: as with the mixed-precision record, the seven sources are arXiv papers with no ModelOpt involvement. This record documents a quantization OBJECT (routing instability under PTQ) and its mitigation, not a storage layout. A query for ModelOpt returns two literature records that are not ModelOpt's. NOT A DISTINCT FORMAT: this record documents a quantization OBJECT (routing instability under PTQ on MoE) and its mitigation terms, not a storage layout. It inherits no group size and should not be given one. Its mechanism is discussed in the sibling moe-mixed-precision record. RECORDED SEPARATELY FROM THE MIXED-PRECISION RECORD because this is a different MECHANISM, not a different allocation. VSRAQ (qlab2-arxiv-vsraq) states the problem in one sentence that is the most useful sentence in this whole area: 'Unlike dense models, MoE models are sensitive to routing instability: small quantization-induced perturbations can change the top-k expert selection, altering the computation path and degrading model quality.' The consequence is specific and easy to miss - quantization noise does not merely perturb the expert's output, it can change WHICH expert runs, so the error is not the smooth perturbation PTQ theory assumes. That also means perplexity deltas measured on MoE can understate the damage: a swapped expert is a different function, not a slightly noisier one. VSRAQ's fix is two-sided: value alignment matches the routing-relevant logits or scores, structure alignment preserves expert ORDERING and the top-k decision boundary - the second is the part that matters for top-k routing, since a perturbation that does not change the top score can still change rank-2 and swap the selection. EAQuant (qlab2-arxiv-eaquant) independently reaches the same diagnosis from the other side, naming three failures of generic PTQ on MoE - activation outliers, ROUTING INSTABILITY, and sparse expert calibration - and adds a routing-consistency alignment term plus calibration-data balancing plus smoothing aggregation. PRACTICAL READ-ACROSS for this repo: on an MoE model, a perplexity delta from a quant change is not a clean signal the way it is for a dense model. If expert selection shifts, the comparison confounds 'bits per expert' with 'different function'. The cheap diagnostic nobody runs: log the top-k expert assignment distribution before and after quantization and diff it. Nothing in the literature reports this as a standard step, which is itself the gap. Also note that the router itself is a small GEMM that is normally left unquantized - the interaction being studied is the perturbation of router INPUTS by quantized upstream layers, not a quantized router. NATIVE_SUPPORT CLASSIFIED 2026-10-04: this field is still [] and that is CORRECT, but the empty list used to be ambiguous between three different states and now is not. Reason class on this record: WEIGHT-ONLY, SO STRUCTURALLY ABSENT. The bits field keeps activations in FP16, so execution is dequantize-to-FP16 then an FP16 tensor-core GEMM; there is no INT4-x-INT4 (or sub-8-bit x sub-8-bit) silicon instruction for it to target. This is a statement about the arithmetic, not an absence of investigation. Consequence for a reader: nothing further to verify - no silicon path is possible for this format as defined. The full statement of the three-way distinction, and the worked list of all 72 empty records by class, is in gotcha quant-native-support-empty-means-three-different-things. Rule of thumb for this field everywhere in the repo: if the bits field carries an 'a16', or the scheme is KV-cache-only or a llama.cpp integer storage type, an empty native_support is a DEFINITION and needs no verification; only a W4A4/W8A8/sub-8-bit format with research kernels can have an empty list that is a real finding.