NeUQI grid search for optimized RTN (--enable_neuqi: joint asym scale/zp search, two-stage sym search, frozen-init anchor)

[avtc]

Description

This PR adds the NeUQI grid search (arXiv 2505.17595) to the optimized-RTN path, opt-in via --enable_neuqi (CLI, or enable_neuqi=True in the API; carried by both RTNConfig and SignRoundConfig):

• Asymmetric layers — joint (scale, integer zero-point) search: a two-stage weighted grid search per group (coarse log-spaced scale candidates, then fine refinement; all zero points evaluated per candidate). Asymmetric layers previously had no optimized initializer at all — plain min/max RTN was the only path.
• Symmetric layers — two-stage signed scale search: replaces the incumbent min/max clip search when enabled; which clamp convention wins per group is searched, not assumed.
• On the zero-shot path (iters=0) both searches are weighted by the activation imatrix, collected automatically when the flag is set (asymmetric layers previously never consumed one — plain min/max RTN was their only path). With iters > 0 the anchor runs unweighted; tuning itself is data-driven.
• iters > 0: frozen-init anchor. The search runs once at wrapper init and anchors the SignRound tuning grid — range margins are pinned to the winner, tuning proceeds on the rounding values only. Measured quality-neutral at iters=50 on sym with SignRoundV2 (0.02191 vs 0.02203 without), so the anchor is a no-cost initialization once tuning runs.
• MoE expert batching: same-shape expert projections (both symmetry classes) quantize in one stacked search call — bit-identical to per-module results.
• Backends: the search runs on the fastest available backend — a Triton kernel (auto_round_extension), a torch.compile implementation, or plain eager PyTorch — and falls back to the next one if a backend fails at runtime (the failed one is disabled for the rest of the process, with a warning). AR_NEUQI_BACKEND=triton|compile|eager pins a backend, mainly for debugging. Measured on the joint search (2M groups, group size 128, 64+32 candidates, RTX 3090): eager 23.8 s, torch.compile 0.43 s (~55x faster than eager), Triton 0.33 s (~72x).
• Grid sizes: AR_NEUQI_COARSE / AR_NEUQI_FINE control the grid. Defaults are 256/64 when Triton or torch.compile serves the search and 64/32 with eager — the eager cost is proportional to the grid size and measured quality is flat between the two (Qwen3.8-27B W4A16 g128, iters=0: mean KL 0.02570 at 64/32 vs 0.02579 at 256/64). Explicit values always win.

Validation — full-vocabulary fp32 KL vs the BF16 base, openwebtext 8x8192 positions; Qwen3.8-27B, W4A16, group size 128, single RTX 3090. Protocol and full statistics: docs/neuqi_acc.md. Sorted by mean KL (lower is better):

mean	median	p90	p99	top1	top5	wall	recipe
0.01921	0.00905	0.03591	0.17297	0.9370	0.8727	2:57:21	iters=200, asym, SignRoundV2 + NeUQI (64/32 grid)
0.02106	0.01050	0.04071	0.18038	0.9317	0.8661	0:49:07	iters=50, asym, SignRoundV2 + NeUQI
0.02191	0.01116	0.04237	0.18473	0.9304	0.8627	0:56:52	iters=50, sym, SignRoundV2 + NeUQI
0.02203	0.01112	0.04307	0.18239	0.9295	0.8630	0:55:40	iters=50, sym, SignRoundV2, no NeUQI
0.02579	0.01361	0.05046	0.21753	0.9234	0.8514	0:11:00	iters=0, asym, NeUQI
0.02734	0.01468	0.05358	0.22014	0.9213	0.8463	0:09:00	iters=0, sym, NeUQI
0.02852	0.01533	0.05678	0.23453	0.9191	0.8429	0:13:19	iters=0, sym, incumbent OptRTN search (no NeUQI)

All iters > 0 rows use SignRoundV2 (enable_alg_ext).

Type of Change

New feature

Related Issues

Relates to #2010 — NeUQI support was requested there.

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.

[avtc]

/azp run Unit-Test-CUDA-AutoRound.

[azure-pipelines]

Commenter does not have sufficient privileges for PR 2341 in repo intel/auto-round

[chensuyue]

/azp run Unit-Test-CUDA-AutoRound

[azure-pipelines]

Azure Pipelines successfully started running 1 pipeline(s).

[wenhuach21]

@avtc Really appreciate this PR! May I know the additional quantization cost and accuracy results on a few representative tasks, like mmlu? If the accuracy looks good and cost is low, we could consider setting it as the default.

[avtc]

@wenhuach21

Both NeUQI sym/asym are faster than opt-rtn sym at least on CUDA (triton or torch.compile backend), as can be seen in table for iters=0: sym optrtn=13m, sym optrtn+neuqi=9m, asym optrtn+neuqi=11m.
eager mode is 74x times slower than triton and 54x times slower than torch.compile, so on CPU could be slow.

iters=50 passes were running in parallel on the same host, so could be less representative.

mmlu	score	stderr
iters=0, optrtn, sym	0.8281	± 0.0030
iters=0, optrtn, neuqi, sym	0.8271	± 0.0031
iters=0, optrtn, neuqi, asym	0.8294	± 0.0030

[wenhuach21]

How about moving this to the algorithm? It feels more like an algorithm than a data type, although there may be some coupling if different algorithms want to use it.

@n1ck-guo, what do you suggest?

[wenhuach21]

@n1ck-guo Should we consolidate this with disable_opt_rtn into a unified qparams_init_method ?

[wenhuach21]

@WeiweiZhang1 If the author doesn’t have enough resources to evaluate accuracy on some typical models and tasks, could you help run some evaluations and link the results as we usually do? It would also be helpful to provide users with some guidance on when to trigger this.