MoE mixed-precision expert bit allocation (expert-level bit-width, not one fixed precision)

NOT A PROXY BUT A NEAR MISS, DECLARED 2026-10-04: expert-level bit allocation is not a ModelOpt recipe - the sources are seven independent arXiv papers (AlphaQ, EAQuant, MoEQuant, MoE, MXMoE, QuantMoEBench, VSRAQ). 'modelopt' is defensible only in that ModelOpt is the common production path for this, but a query for ModelOpt returns a literature record that has no ModelOpt source. The grouping axis (per-expert) is genuinely different from every other record here, which is the more useful distinction. GROUP SIZE LEFT NULL 2026-10-04: the bit allocation here is per-EXPERT or per-expert-group, i.e. the axis is the expert, not a contiguous run of weights in one tensor. Different experts carry different bit widths, so a single weight group size does not exist for the model. THE CENTRAL FINDING, and the reason this is a distinct record rather than a note on the gptq/awq records: generic PTQ applies ONE fixed precision to the whole MoE, and that is what breaks. QuantMoE-Bench (qlab2-arxiv-quantmoebench) states the mechanism precisely - MoE's sparse routing produces DIFFERENT activation patterns, because shared experts are accessed by ALL tokens while token-conditioned experts are selectively activated, so the two do not have the same quantization requirement, and consistently-activated shared experts potentially need HIGHER precision to hold model quality. MxMoE adds a second, independent axis: divergent expert activation FREQUENCIES create heterogeneous computational characteristics, so mixed-precision choice must be co-designed with hardware rather than chosen for accuracy alone. DIRECTION OF THE EXPERT BIT ALLOCATION - note this is not uniform, and the papers disagree about which experts to favour, which is worth flagging rather than smoothing over. AlphaQ (qlab2-arxiv-alphaq), which is calibration-free, allocates MORE bits to experts whose weight spectra are more heavy-tailed, on the theory that heavy-tailed means better-trained. Colla-Q instead balances activation entropy across experts so no single expert collapses. QuantMoE-Bench argues the structurally correct answer is more bits for shared/always-on experts. These are three different selection criteria; none is established as the default. WHY CALIBRATION IS THE HARD PART, and it is the practical blocker: MoEQuant (qlab2-arxiv-moequant) names two distinct failures. INTER-EXPERT IMBALANCE: uneven sample distribution across experts leaves infrequently-used experts with insufficient and biased calibration. INTRA-EXPERT IMBALANCE: MoE's aggregation mechanism makes different samples correlate differently with their assigned expert. AlphaQ's motivation is the deployment version of the same problem - frontier MoE models are trained on proprietary data, so any calibration set is an imperfect surrogate and misestimates expert utilization. This connects directly to the imatrix record: a llama.cpp imatrix built from a corpus that under-exercises rarely-routed experts inherits exactly this bias. ECONOMICS, and it explains the whole subfield: MoE deployment is memory-bound because ALL expert weights must be resident even though only k are used per token, so precision reduction buys residency while the FLOPs stayed flat. MoQE's framing is that 2-bit expert weights can still beat the dense model trained on the same dataset - robustness of expert layers to quantization is doing real work here. 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.