Why architecture matters here

Quantization exists because memory bandwidth, not compute, is the wall that large models hit at inference time. A 70-billion parameter model in FP16 is 140GB of weights that must be streamed from HBM into the compute units for every token generated. Drop those weights to 4 bits and the footprint falls to roughly 35GB, small enough to fit a model that previously needed multiple GPUs onto one, and — because generation is memory-bound — the token rate rises almost in proportion to the bytes saved. The prize is enormous: quantization is frequently the difference between a model that is economically deployable and one that is not.

The catch is that 4 bits gives you only sixteen distinct values to represent a distribution of weights that spans several orders of magnitude. The mapping from float to integer is governed by two numbers per group of weights — a scale (how much real value each integer step is worth) and a zero-point (which integer maps to real zero). Choose them with naive min-max and a single outlier weight forces the scale to be huge, so the sixteen levels are spread thinly across a range dominated by one value, and the hundreds of small weights that carry most of the model's behavior all collapse onto two or three adjacent integers. The error concentrates exactly where the model is most sensitive, and perplexity blows up.

The established fix — the one GPTQ and AWQ embody — is to use data to figure out which weights are important and protect them. That works, but it couples the quantization to a corpus, and the quality of the result is hostage to how representative that corpus is. For a model that will serve wildly heterogeneous traffic, or for a team that cannot legally run their eval data through a quantizer, or for anyone who simply wants a fast, reproducible, data-free pipeline, the data dependency is a real architectural cost. HQQ's contribution is to show that you can get competitive accuracy by attacking the outlier problem directly in weight space, no data required.

Framing quantization as an optimization rather than a rounding rule is the conceptual shift that makes this possible. Naive quantization asks 'what integer is each weight closest to?' and answers greedily, one weight at a time. HQQ asks a different question: 'what scale, zero-point, and per-weight error correction jointly minimize the difference between the original weights and their dequantized reconstruction?' That is a global objective over the whole group, and because it is solved to a minimum rather than assembled greedily, it can absorb the outliers into an explicit error term instead of letting them poison the grid. The cost is a small optimization per group — but it is a convex-ish problem with closed-form steps, so 'small' really does mean seconds, not the hour a data-driven second-order method spends.

Advertisement

The architecture: every piece explained

Top row: the setup. The FP16 weight block is a group of N weights (a row of a matrix, or a fixed-size chunk of one) that will share a single scale and zero-point. HQQ introduces a sparsity variable W_e — a per-weight error term whose job is to soak up the outliers so they stop distorting the grid. And it solves for the scale and zero-point, the two parameters that actually define the quantization. The objective it minimizes is the reconstruction error between the real weights and their dequantized form, plus a sparsity-promoting penalty on W_e that keeps the error term small everywhere except at genuine outliers.

Middle row: the solver. A robust objective with an L-p (p<1) sparsity penalty is normally nasty to optimize, so HQQ applies half-quadratic splitting: it introduces an auxiliary variable and decouples the hard non-convex penalty from the quadratic reconstruction term. That decoupling yields two sub-problems that each have a closed form. The first, the proximal step, is a soft-shrinkage (soft-threshold) operator that pushes small errors to zero and keeps only the outliers — pure element-wise arithmetic, no iteration. The second, the zero-point solve, is a least-squares update that, given the current error term, finds the optimal offset in closed form. Neither step touches a gradient or a calibration batch.

Bottom rows: convergence and packing. HQQ alternates the two steps a handful of times — typically well under twenty iterations — and the objective drops fast because both sub-problems are exact. Once converged, the weights are packed to the target width (int4, int3, even int2) with the group's scale and zero-point stored alongside in FP16. At runtime there is no error term to carry: the sparse correction was folded into the choice of scale and zero-point during optimization, so the served format is just packed integers plus per-group metadata, dequantized on the fly inside a fused matmul kernel exactly like any other affine-quantized model.

The sparsity penalty deserves a closer look, because it is where the half-quadratic name earns its keep. HQQ penalizes the error term W_e with an L-p norm where p is less than one — a penalty that aggressively favors solutions in which most entries are exactly zero and only a few are large, which is precisely the shape of a genuine outlier distribution. That non-convex penalty is what makes the raw objective hard, and the half-quadratic split is the classical remedy: introduce an auxiliary variable that mirrors W_e, penalize their difference quadratically, and now the problem separates into a smooth quadratic part (solved by least squares) and a purely element-wise proximal part (solved by a soft-threshold with a closed form). As the coupling weight is annealed across iterations, the auxiliary variable and W_e converge, and the solution of the split problem approaches the solution of the original robust objective — all without ever computing a gradient, running a forward pass, or touching calibration data.

Half-Quadratic Quantization — solve for a robust zero-point, no calibration data neededoptimize the quantization error, don't just roundFP16 weight blockone group of N weightsSparsity variable W_eabsorbs outliersScale + zero-pointthe quant parametersHalf-quadratic splitauxiliary variable per weightProximal (soft-shrink)closed-form outlier stepSolve zero-pointleast-squares updateAlternate until convergeda few cheap iterations, secondsPack to int4/int3/int2group scale/zero stored in FP16Runtime — dequant on the fly in the matmul kernel, fused per groupinitoutliersparamslooploopconvergeserveserve
HQQ splits the quantization objective into an outlier-absorbing sparse term and a zero-point solve, then alternates cheap closed-form updates until the rounding error is minimized — all without a calibration dataset.
Advertisement

End-to-end flow

Follow one linear layer of a transformer through HQQ. The layer's weight matrix is reshaped into groups — say group size 64, so each row of 4096 weights becomes 64 groups. For one group, HQQ initializes the scale and zero-point from the group's min and max, exactly like naive quantization would, giving a starting point that is already 'not terrible.' Then the alternating loop begins. Iteration one: with the current scale and zero-point fixed, the proximal soft-shrink computes the per-weight error W_e, and it lights up on precisely the two or three weights in the group whose magnitude dwarfs their neighbors — the outliers. Iteration one, second half: with those outliers now captured in W_e, the least-squares step re-solves the zero-point against the outlier-corrected residual, and because the outliers are no longer dragging it, the zero-point shifts to better serve the bulk of the distribution.

Iterations two through roughly ten repeat this dance. Each pass, the error term sharpens onto the true outliers and the zero-point settles, and the reconstruction error — the actual measured difference between the FP16 weights and their dequantized int4 form — drops monotonically until it plateaus. The whole group converges in milliseconds; a 70B model's worth of groups quantizes in a few minutes on a single GPU, with no data ever loaded. That data-free speed is the operational headline: you can requantize a fine-tuned checkpoint as part of CI without wrangling an eval corpus.

Now serve it. A generation request arrives and the model must compute this layer's output. The fused kernel streams the packed int4 weights from HBM — one quarter the bytes of FP16 — dequantizes each group using its stored scale and zero-point into the registers, and multiplies against the activations. The dequantization is cheap arithmetic hidden behind the memory load, so the layer runs at roughly the bandwidth-limited speed of a 4-bit model while producing outputs close to the FP16 original, because the scale and zero-point were chosen to minimize exactly this reconstruction gap. The outliers that would have wrecked a naive quantization were neutralized offline, during the optimization, and cost nothing at inference.

The contrast with the data-driven methods is sharpest at the margins. GPTQ walks the weight columns and uses the inverse Hessian estimated from calibration activations to compensate each rounding decision against the ones already made; AWQ scales salient channels up before rounding based on activation magnitude. Both need the forward passes. HQQ reaches comparable perplexity at 4 bits with none of that, and its edge grows when the deployment traffic looks nothing like any calibration set you could have assembled — because HQQ never assumed one. Where the data-driven methods still tend to win is the aggressive frontier: at 3 bits and especially 2 bits, the activation-aware protection of salient weights buys accuracy that a purely weight-space method struggles to match, which is why the honest recommendation is HQQ for fast data-free int4 and a calibrated method when you are pushing below three bits.