AWQ (activation-aware weight quantization)

This is the canonical example of the distinction that matters: AWQ is w4a16. Weights are 4-bit; activations and the KV cache stay 16-bit, so there is NO hardware 4-bit-activation path and nothing on an INT4 tensor core is being used. Group size 128 is the scheme's defining choice and the file layout - it is not a tunable, so 'AWQ group 64' is not a thing AWQ itself defines. Runtime support is entirely software dequant-to-fp16 inside a fused GEMM; the TensorRT-LLM hardware matrix confirms W4A16 AWQ is supported on Ampere/Ada/Hopper/Blackwell as a weight-only path, not as a tensor-core INT4 op (quant-trtllm-quantization). Third-party kernel claims about ~4x come from Marlin, not from AWQ's own TinyChat, which reports >3x over HF FP16 on desktop and mobile GPUs (quant-awq-paper). GROUP SIZE CONFIRMED UPSTREAM: the canonical mit-han-lab/llm-awq examples all use --q_group_size 128 and the project's own model zoo is indexed as INT4-g128 / INT3-g128 (qlab2-awq-readme), which confirms the existing weight_group_size=128 from the repository rather than from the paper. Vendor claim from the same README, for the consumer-GPU case in this repo: TinyChat with LLaMA-3-8B on an RTX 4090 is '2.7x faster than FP16' for W4A16 (2.9x on Jetson Orin) - single-figure marketing with no batch or prompt-length methodology, so vendor-claim-grade only. Also from the README: AWQ ships a BF16 precision mode and DeepSeek-R1-Distill support (2025-02 and 2025-04), and Intel Neural Compressor integrated AWQ in 2023-09. 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.