llama.cpp MMQ kernel-family selection (ggml_cuda_mmq_get_config) and the GGML_CUDA_CC_BLACKWELL=1200 / BLACKWELL_MMA_AVAILABLE definitions: MXFP4/NVFP4 are WIDE-ARCH integer paths on CUDA and native FP4 only on sm120+

Read 2026-10-05 from llama.cpp master. This is the engine-side kernel matrix for the GGUF/llama.cpp ecosystem that the task asks for, and it contains one finding this repo does not have. (1) THE FAMILY LADDER, quoted from ggml/src/ggml-cuda/mmq.cuh ggml_cuda_mmq_get_config(type, J, fallback, cc, prec_src1): `if (GGML_CUDA_CC_IS_AMD(cc)) { ... GCN -> gcn, CDNA -> cdna, RDNA4 -> rdna4, RDNA3_5 -> rdna3_5, RDNA3 -> rdna3, else rdna2 }`; then `if (blackwell_mma_available(cc)) { if (prec_src1 != GGML_PREC_Q4 && (type == GGML_TYPE_NVFP4 || type == GGML_TYPE_MXFP4)) return ggml_cuda_mmq_get_config_ampere(...); return ggml_cuda_mmq_get_config_blackwell(...); }`; then `if (ggml_cuda_highest_compiled_arch(cc) >= GGML_CUDA_CC_VOLTA) return ampere; if (>= GGML_CUDA_CC_DP4A) return pascal_dp4a; return pascal_older`. Six kernel families across six arch classes, and the AMD side has its own four-way split. (2) THE FINDING, and it is a verified negative about native FP4 on datacenter Blackwell: ggml/src/ggml-cuda/common.cuh defines `#define GGML_CUDA_CC_BLACKWELL 1200` with the comment 'While BW spans CC 1000, 1100 & 1200, we are integrating Tensor Core instructions available to 1200 family, see https://docs.nvidia.com/cutlass/media/docs/cpp/blackwell_functionality.html#blackwell-sm120-gemms', and separately `#define GGML_CUDA_CC_RUBIN 1300`. BLACKWELL_MMA_AVAILABLE is defined as `#if !defined(GGML_USE_HIP) && __CUDA_ARCH__ >= GGML_CUDA_CC_BLACKWELL && __CUDA_ARCH__ < GGML_CUDA_CC_RUBIN #define BLACKWELL_MMA_AVAILABLE`. Because the constant is 1200, the native FP4 MMQ config requires cc >= 1200 AND < 1300 — i.e. sm120, sm121 and Rubin, and NOT sm100/sm103. So in llama.cpp an MXFP4 or NVFP4 GGUF on a B200 or B300 runs the AMPERE integer MMQ config, not a Blackwell tensor-core FP4 config, while the same file on an RTX 5090 reaches the native Blackwell config. That is the exact inverse of vLLM (cutlass_scaled_mm_supports_fp4: 100<=cc<120 native on sm100, 120<=cc<130 on sm120) and of TensorRT-LLM (Sm100 and Sm103 FP4 templates). (3) EVEN ON sm120+, FP4 IS THE EXCEPTION, not the rule: the ampersand-branch condition is `prec_src1 != GGML_PREC_Q4`, with the comment 'only src1 at Q4 uses the native FP4 config, higher precisions keep src1 at Q8_1'. The FP4 tile layouts are named GGML_CUDA_MMQ_SRAM_LAYOUT_FP4 ('MXFP4 and NVFP4 on Blackwell') and GGML_CUDA_MMQ_SRAM_LAYOUT_NVFP4 ('Generic NVFP4'), and the MMQ tile-size table maps GGML_TYPE_MXFP4 -> MMQ_DP4A_TXS_Q8_1 and GGML_TYPE_NVFP4 -> MMQ_DP4A_TXS_Q8_0_16 against GGML_TYPE_IQ4_NL -> MMQ_DP4A_TXS_Q8_0, with MMQ_ITER_K_FP4 512 against MMQ_ITER_K 256. So the native FP4 config is reached only when the activation side is itself quantized to Q4; at Q8 activations the same quant type drops back to the ampere config. This refines the repo's existing 'GGUF has no silicon anywhere' position ([[quantization/gguf-iq4-xs]]: 'No accelerator has an i-quant or k-quant path in silicon'): that statement is right for the i-quants and the k-quants and is now WRONG for MXFP4 and NVFP4 GGUF, which do have a Blackwell-sm120 tensor-core path in llama.cpp — with the caveat that it is a MMQ (multiply-matrix-quant) kernel reached by config selection, not a CUDA-version-gated tensor-core FP4 MMA, and it is absent on sm100/sm103.