Automated Quantization vs GPTQ: How to Pick a Recipe for Your GPU

If your GPU is Turing-generation or newer (compute capability 7.5+, so RTX 2000 series, T4, and up), the practical answer is: standardize on calibrated GPTQ or AWQ served through a Marlin-class kernel, and keep GGUF for CPU, edge, or integration-flexible deployments where raw vLLM throughput matters less. Below that capability floor, optimized GPTQ/AWQ kernels simply do not exist for your hardware. That rule is evergreen. What is new, and what this guide treats carefully, is a preprint called AutoCompress (arXiv:2611.08290, observed 2026-11-06) that claims to automate the recipe-selection step itself by folding GPU latency, throughput, and memory constraints directly into a compression search. Its numbers are author-reported, single-source, and unreplicated as of this writing, and what it automates is architecture-level compression, not the GPTQ/AWQ/GGUF decision you make today. So the honest framing of “automation vs GPTQ” is not two interchangeable recipes. It is a question of who drafts the recipe and what verification each path owes you before deployment.

What changed: hardware-guided automation enters recipe selection

AutoCompress describes itself as “a hardware-guided compression framework that directly incorporates such constraints into differentiable architecture search,” where the constraints are the deployment hardware’s latency, throughput, and memory limits. Instead of an engineer picking a bit-width and format and then checking whether it fits and runs fast enough, the search is supposed to produce an architecture already shaped to the target GPU.

The authors report results across three deployment scenarios: improvements over a deployment-adapted Minitron baseline of 6.57, 2.35, and 0.57 percentage points of average accuracy on RTX 5070, RTX 5080, and H100 respectively, while using roughly 2-3.3x fewer search tokens. In their headline LLM-serving example, the framework compresses Nemotron 3.5 Super from 120B to 74B parameters for single-B200 BF16 serving at 128K context, retaining 95% of its mean benchmark score.

Two things deserve emphasis before these numbers do any work in your planning. First, the trend inside the authors’ own results: the gain shrinks from 6.57 points on a consumer RTX 5070 to 0.57 points on an H100. Whatever automation buys, it appears to buy most of it on constrained hardware where the search space of viable configurations is tightest. Second, the output in the demonstrated case is a smaller BF16 model, not a quantized checkpoint. The fetched paper does not show AutoCompress emitting GPTQ, AWQ, or GGUF artifacts, and there is no head-to-head against weight-only quantization on any shared task. Treating it as a drop-in replacement for your quantization pipeline would be an inference the evidence does not support.

Start from the GPU: the capability floor decides before you do

The first fork in the decision is not accuracy or bit-width; it is whether your card can run the kernels at all. According to PremAI’s 2026 quantization guide, optimized AWQ/GPTQ kernel support requires “Compute capability 7.5+ (Turing architecture: RTX 2000 series, T4, and newer). Older GPUs won’t have optimized kernel support.” This is vendor documentation rather than an independent audit, but it matches how the kernel ecosystem actually ships, and it is the kind of floor you can verify on your own hardware in an afternoon.

Memory fit is the second constraint, and the evidence here is concrete. The original GPTQ paper reports that its compressed OPT-175B runs on a single NVIDIA A100 or on two NVIDIA A6000 GPUs. More recently, a serving characterization on a single 48GB NVIDIA L20 sustained Qwen2.5-72B-Instruct-AWQ under a fixed workload of roughly 512 input and 256 output tokens, with 24-hour stability at concurrency 10 and repeated short-run throughput near 127 output tokens/s at concurrency 16. That is a useful anchor: 70B-class AWQ serving on one mid-range datacenter card is not theoretical.

AutoCompress targets a different set of cards (RTX 5070, RTX 5080, H100, and a single B200 in the reported scenarios), which tells you where its authors think automation pays: newer consumer silicon and top-end datacenter parts. If your fleet is A100s, L20s, or T4s, the preprint’s scenarios do not cover you, and the incumbent path does.

Calibration budgets: which recipes need your data

The second fork is whether the recipe needs calibration data, and whose. GPTQModel’s documentation draws the line cleanly: “GPTQ, AWQ, ParoQuant, VPTQ, and EXL3 are calibration-based. GGUF and FP8 are weight-only and should be quantized with calibration=None.”

Calibration-based means the quantization is fitted to activation statistics from sample inputs, so the quality of the result depends partly on data you supply. The AWQ paper is specific about the mechanism: it protects the roughly 1% of weight channels that matter most via an equivalent scaling transformation, and “the scale is determined by collecting the activation statistics offline.” If your calibration split does not resemble your production traffic, you are fitting the recipe to a workload you do not serve.

The cost side of the incumbent path is well documented. GPTQ “can quantize GPT models with 175 billion parameters in approximately four GPU hours, reducing the bitwidth down to 3 or 4 bits per weight, with negligible accuracy degradation relative to the uncompressed baseline,” per the GPTQ paper. Four GPU hours at 175B is cheap enough that per-model hand-tuning has never been the real bottleneck for most teams. AutoCompress reports its own search cost as 2-3.3x fewer search tokens than a Minitron baseline, but that is a comparison against another automated search method, not against the four-GPU-hour GPTQ run, and it is author-reported.

Weight-only recipes (GGUF, FP8 quantized with calibration=None) skip this entirely, which is part of their appeal for edge and CPU serving: no calibration pipeline, no data-sensitivity question, at the price of throughput on GPU serving backends.

Throughput reality check: kernels, not bit-widths, set serving speed

Here is a misconception worth correcting explicitly, because the original authors corrected it themselves. The GPTQ paper states: “our method currently does not provide speedups for the actual multiplications, due to the lack of hardware support for mixed-precision operands (e.g. FP16 x INT4) on mainstream architectures.” The 4-bit format saves memory and enables single-GPU deployment; the serving speed comes from the kernel you pair it with.

The size of that kernel effect, in one vendor-measured vLLM configuration from the PremAI guide: GGUF served about 93 tokens per second where AWQ with the Marlin kernel served about 741. That is roughly an 8x gap, and it should be read as exactly what it is, a single configuration from one vendor’s benchmark, not a universal ratio. Batch size, context length, and model will move it. But the direction is consistent with how the backends are built, and it explains the standard serving-stack advice: GGUF where flexibility wins, AWQ/GPTQ behind Marlin-class kernels where GPU throughput wins.

What AutoCompress automates, and what it leaves on your desk

If the preprint’s claims hold up, automation genuinely removes one step: the search over architecture and compression choices for a fixed hardware target. That is real labor on constrained consumer GPUs, where the reported 6.57-point gain over an already deployment-adapted baseline is not trivial.

What it does not remove is everything downstream of selection. The verification problem, the calibration-data question for whatever recipe you run alongside it, the kernel and serving-stack integration: all of it remains. And because the framework’s demonstrated output is a compressed BF16 architecture rather than a quantized checkpoint, you may still face the weight-quantization decision on top of whatever it produces. The claim that automation removes the verification step appears nowhere in the fetched evidence. The behavioral evidence, below, points the other way: automation shifts your effort from per-model tuning toward proving the selected recipe holds on your task distribution. Skipping local evals gets more expensive, not less.

The eval you cannot skip, whoever picked the recipe

The strongest evidence in this whole comparison attacks an assumption both paths share: that a chosen recipe’s aggregate accuracy delta certifies it.

A study of quantization’s effects on coding agents (arXiv:2611.02368) found that “final accuracy can conceal substantial behavioral changes: AWQ reduces Qwen-7B one-shot solves from 17 to 0 while increasing loop-based solves from 10 to 25.” Read that again. The model’s strategy distribution collapsed and reformed into something qualitatively different, and the headline accuracy number hid it. The same study found that Qwen-32B’s roughly 3-point drop under AWQ or GPTQ did not reach statistical significance after Holm correction (p_Holm = 0.21 for AWQ) or at the problem level (p = 0.051). A drop can be statistically non-significant and operationally real at the same time, which cuts against both directions of sloppy reading: “3 points is noise” and “3 points is fatal” are both claims the aggregate number cannot settle.

The L20 serving report supplies the complementary honesty check from the serving side. After documenting sustained 72B-AWQ throughput, it explicitly lists among claims “not supported by the current evidence”: “AWQ is lossless relative to BF16/FP16.” When you see “lossless 4-bit” in marketing material, that sentence is the correct response.

The practical consequence is a minimum eval set, and it is the same set regardless of who drafted the recipe:

1. Task-distribution accuracy on samples drawn from your actual traffic, not just public benchmarks, with enough samples that a 2-3 point movement is interpretable.
2. Behavioral probes matched to how your application uses the model: if you run agents, check strategy patterns (solve style, retry behavior, tool-call structure), not only final pass rates. The 17-to-0 collapse is the canonical warning.
3. Serving-shape verification on your target GPU at your real concurrency and context lengths, since the throughput figures you are relying on (741 vs 93 tok/s, 127 tok/s on an L20) are single-configuration measurements that may not transfer.

One limitation on the behavioral evidence itself: those findings come from coding-agent tasks on specific Qwen models. They establish that accuracy-can-hide-behavior is a real failure mode, not that your task distribution will exhibit the same pattern. That is precisely why the eval has to be yours.

Picking the path: a decision table

My recommendation, with its conditions: on any serving GPU that clears the 7.5 capability floor, I would standardize the pipeline on calibrated AWQ or GPTQ behind Marlin-class kernels, budget for a calibration split that mirrors production, and treat the behavioral eval as a release gate rather than a sanity check. I would trial AutoCompress only on work that can tolerate a restart if the preprint’s claims do not replicate, and I would not plan around it for anything where a lost week means rebuilding a customer’s serving stack. On the largest hardware, the authors’ own 0.57-point H100 gain argues the automation premium is thin there anyway.

The verdict in one line: pick by GPU class, prove by task. Automation may eventually draft your recipe; nothing in the current evidence excuses you from grading it.

Frequently Asked Questions

Does GPTQ quantization speed up matrix multiplications?

The GPTQ paper states: “our method currently does not provide speedups for the actual multiplications, due to the lack of hardware support for mixed-precision operands (e.g. FP16 x INT4) on mainstream architectures.” The 4-bit format saves memory and enables single-GPU deployment; the serving speed comes from the kernel you pair it with.

What evaluation steps are required after selecting a quantization recipe?

1. Task-distribution accuracy on samples drawn from your actual traffic, not just public benchmarks, with enough samples that a 2-3 point movement is interpretable.
2. Behavioral probes matched to how your application uses the model: if you run agents, check strategy patterns (solve style, retry behavior, tool-call structure), not only final pass rates. The 17-to-0 collapse is the canonical warning.
3. Serving-shape verification on your target GPU at your real concurrency and context lengths, since the throughput figures you are relying on (741 vs 93 tok/s, 127 tok/s on an L20) are single-configuration measurements that may not transfer.