HQQ (half-quadratic quantization)

HQQ is calibration-free by design: it minimizes weight-reconstruction error directly with a half-quadratic (proximal) solver rather than using a calibration set to minimize layer-output error. The upstream claim is that this reaches calibration-based quality at calibration-free speed, which is a genuinely different tradeoff from AWQ/GPTQ, not a weaker version of them. Weight-only - group size is not part of the defining scheme, hence null rather than a guess. Provenance warning: HQQ has NO arXiv paper. The only primary technical source found is the Dropbox/Mobius engineering blog (the 2023 post republished 2025-10-22 with an editor's note), so every HQQ number here is vendor-claim-grade and confidence is kept low. Do not cite an 'HQQ paper'. GROUP SIZE AND BACKENDS, added from the upstream repo README (qlab2-hqq-readme), which is the primary technical source since HQQ has no arXiv paper. group_size: no restriction beyond weight.numel() being divisible by it; the project's own recommended starting point is explicitly nbits=4, group_size=64, axis=1, and its accuracy report is ~158 tok/s for Llama3-8B 4-bit on an RTX 4090 (vendor claim, single number, no batch/prompt methodology given). BACKEND MATRIX - this is the part most guides omit: axis is the grouping axis and axis=0 gives better quality than axis=1 (especially at low bits), but every optimized inference backend supports axis=1 ONLY. Native backends: PYTORCH (default), PYTORCH_COMPILE (fullgraph torch.compile, works with any settings), ATEN (its own CUDA kernels, axis=0 only). Optimized external backends via prepare_for_inference: 'gemlite' (nbits 4/2/1, compute_dtype float16, axis=1) and torchao tiny_gemm 'torchao_int4' (nbits 4, compute_dtype bfloat16, axis=1, documented as fast for batch size < 4). Additional group-size restrictions apply per backend, and hqq silently falls back to the native backend when a config is unsupported - so a config mismatch is a speed cliff, not an error. For vLLM, hqq ships on-the-fly quantizers for A8W4 (mxfp8_dynamic), A4W4 (mxfp4_dynamic) and A4W4 (nvfp4_dynamic), i.e. HQQ has moved into genuine activation quantization, which the original HQQ record did not capture. It is also one of the algorithms ONNX Runtime's MatMulNBits INT4 path accepts alongside GPTQ and RTN (qlab2-ort-quant-doc), and one of the backends transformers integrates via HqqConfig. 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.