GGUF Q4_K_S (4-bit K-quant, small)

CORRECTED 2026-10-04: was 256. Same basis as Q4_K_M - base type Q4_K, 32-value scale group per dequantize_row_q4_K. MIXTURE CAVEAT: Q4_K_S contains a larger share of Q5_K (group 32) than Q4_K_M and some Q6_K (group 16). 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. Verify layouts in that file, not in blog posts - the per-type 'effectively N bits per weight' figures are comments in the struct definitions themselves. Structurally IDENTICAL to q4_K: block_q4_K, 8 sub-blocks of 32, uniform 4-bit weights, 6-bit sub-block scale+min on fp16 super-block scales. The difference from Q4_K_M is only the promotion schedule: src/llama-quant.cpp promotes attn_v to Q5_K for the first 4 layers (i_attention_wv < 4) and ffn_down to Q5_K for the first n_layer/8 layers (non-Falcon only). Q4_K_M instead promotes those to Q6_K and additionally hits attn_output. Hence 4.6672 vs 4.8944 bpw. Neither is 'better' - they are different points on the size/quality curve, and the independent k-quant study put Q4_K_S on a better Pareto point than Q4_K_M, which is why this pair is recorded as contested rather than resolved. Weight-only: activations stay FP16/BF16 at runtime. ggml has per-type dequant+gemm kernels; no accelerator has a k-quant silicon path. vLLM labels GGUF experimental/under-optimized. Consumer-GPU note identical to Q4_K_M: CUDA/HIP have mul_mat_vec_q, Vulkan does not and has a documented Q4_K speed regression (gotcha-llamacpp-issue-11559-vulkan-q4km-regression). 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.