GGUF Q5_K_M (5-bit K-quant, medium)

CORRECTED 2026-10-04: was 256. Base type Q5_K has a 32-value scale group: dequantize_row_q5_K uses the identical `j += 64` / two-get_scale_min_k4 structure as Q4_K, adding only the high-bit plane qh[]. 8 sub-blocks of 32 per super-block. Every K-quant shares the same super-block shape: QK_K = 256 values per block (ggml/src/ggml-common.h, `#define QK_K 256`), with K_SCALE_SIZE = 12 bytes of packed sub-block scales. block_q5_K = { ggml_half d; ggml_half dmin; uint8_t scales[K_SCALE_SIZE]; // 8+8 sub-block scales/mins at 6 bits uint8_t qh[QK_K/8]; // 32 bytes: the HIGH (5th) bit of each quant, 8 quants per byte uint8_t qs[QK_K/2]; }. This is the same 4-bit-style split-bit trick as q5_0 and legacy q4_1/q5_1: qs holds the low 4 bits of each 5-bit quant (128 bytes), qh the 5th bit (32 bytes). 4+12+32+128 = 176 bytes / 256 values = 5.5 bpw, matching the header comment. 8 sub-blocks of 32, x = a*q + b. Q5_K_M IS A MIXTURE. From src/llama-quant.cpp: base q5_K; attn_v -> Q6_K when use_more_bits(i_attention_wv,n) (same predicate as Q4_K_M); ffn_down -> Q6_K when use_more_bits(i_layer,n_layer). That is the ONLY promotion - Q5_K_M does not touch attn_output, which is why it is only 0.06 bpw wider than pure q5_K (5.7036 vs 5.5) while Q4_K_M is 0.39 bpw wider than pure q4_K. The plain 'Q5_K' CLI name is an ALIAS for Q5_K_M. Q5_K_S promotes nothing and measures 5.5704 bpw - essentially pure q5_K. Also note llama-quant.cpp forces the OUTPUT tensor (and tied token embeddings) to Q6_K for most ftypes and to Q5_K for the i-quants, unless --output-tensor-type overrides it, and to Q8_0 when the row length is not a multiple of the block size (nx % qk_k != 0) or for Falcon. That is why 'Q5_K_M' is never a single type in the file. Weight-only: activations stay FP16/BF16 at runtime. Per-backend dequant+gemm; no silicon k-quant path. The official quantize tool reports Q5_K_M at +0.0569 ppl on Llama-3-8B and Q5_K_S at +0.1049, Q6_K at +0.0217 and Q8_0 at +0.0026 (qlab2-quantize-options-table). 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: LLAMA.CPP INTEGER STORAGE TYPE, SO STRUCTURALLY ABSENT. Every GGUF type here is a packed integer block format read by a dequant kernel (dequantize_row_*) and then executed as FP16; ggml publishes no int4 or sub-8-bit tensor-core path that consumes these blocks directly. The llama.cpp CUDA and Vulkan backends both run these formats by dequantizing. Consequence for a reader: nothing further to verify - and note the contrast with nvfp4/mxfp4/mxfp8 in this repo, which ARE hardware formats on Blackwell and carry populated native_support lists, so '4-bit' alone does not predict this field. 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.