- Hoist E8M0 scale decode: elem pairs always share a block (elem is
  even), so compute scale once per pair instead of twice
- Hardware intrinsics (CUDA 12.8+): replace LUT lookups with single-
  instruction CVT for FP8 E4M3, FP4 E2M1, FP6 E2M3 dequant; add
  cuda_fp6.h include; portable fallback for older toolkits
- Inline V multihead dequant: read directly from multihead SoA layout
  using computed offsets, eliminating the per-KV-position buffer copy
- Dockerfile: BuildKit cache mount for incremental CUDA builds

Benchmark (gpt-oss-20b, 2x RTX 5070 Ti, tg128):
  mxfp8+mxfp8: 192 -> 219 t/s (+14.2%, now exceeds f16)
  mxfp6+mxfp6: 194 -> 204 t/s (+5.0%)
  mxfp8+mxfp4: 195 -> 206 t/s (+5.8%)
  mxfp4+mxfp4: 205 -> 206 t/s (+0.6%)
  PPL unchanged across all configs.

Extract reusable helpers into mxfp-common.cuh that exploit the invariant
that elem is always even in the VEC kernel dequant loops:

- mxfp4_extract_nibble_pair: branchless nibble extraction using
  shift = (pos >= 16) ? 4 : 0 instead of branchy pos < 16 logic.
  Both nibbles always in same half (low or high) since pos is even.

- mxfp6_unpack_pair: single ggml_mxfp_unpack_fp6x4 call for both
  elements. pos0 even → pos0%4 ∈ {0,2} → grp0 == grp1 always,
  so the group-boundary branch is provably dead code. Eliminated.

Applied to all K dot, V dequant, and inline V multihead paths.
Net -39 lines (83 added, 122 removed).

Benchmark (gpt-oss-20b, 2x RTX 5070 Ti, tg128):
  mxfp8+mxfp4: 206 -> 219 t/s (exceeds f16 218.6)
  mxfp4+mxfp4: 206 -> 214 t/s (-2.0% vs f16)
  mxfp6+mxfp4: 197 -> 214 t/s (-2.1% vs f16)
  mxfp6+mxfp6: 204 -> 214 t/s (-2.2% vs f16)

Extract the repeated pattern of "unpack + scale + dequant a pair of
SoA elements" into a single template function in mxfp-common.cuh,
specialized for MXFP4, MXFP8, and MXFP6.

Each specialization encapsulates:
  - Type-specific data extraction (nibble pair / byte pair / fp6 unpack)
  - E8M0 scale decode (full or half depending on intrinsic availability)
  - Hardware intrinsic vs portable LUT fallback (#if CUDART_VERSION)
  - Returns float2{elem0, elem1}

This collapses 6 call sites (K dot, K inline, V half2, V float2,
vec_dot_mxfp4/8/6) from ~25 lines each to a single function call.
All 16 #if CUDART_VERSION guards in fattn-vec.cuh eliminated (now 0).

Add q8_0+q4_0 mixed-type FA to the default CUDA build (previously
required GGML_CUDA_FA_ALL_QUANTS). This is a common high-quality
config: q8_0 keys preserve attention pattern fidelity while q4_0
values save memory with minimal quality loss.

Changes:
- fattn.cu: add q8_0+q4_0 to default VEC dispatch and mixed-type guard
- CMakeLists.txt: compile fattn-vec-instance-q8_0-q4_0.cu by default

Before: pp=616, tg=125 (no FA, CPU fallback)
After:  pp=8691, tg=217 (full FA, GPU-accelerated)

…es (-185 lines)

Replace 9 explicit MXFP4/8/6 template specializations with if-constexpr
single-body templates. Add MXFP_DISPATCH macro for runtime type→template
dispatch, eliminating 3-way switch blocks in set-rows.cu and
mxfp-common.cuh host functions. Consolidate compiler-macro sites
(#if CUDART_VERSION) from 9 down to 4.

Three changes for MXFP flash attention on CUDA:

1. Remove Q quantization roundtrip — Q is now Hadamard-rotated only,
   not quantized/dequantized. Q is computed fresh every token and never
   stored, so injecting quantization noise was unnecessary and hurts PPL.
   Rotate-only beats f16 baseline on some models. Applied pre-kernel for
   both MMA and VEC paths (VEC no longer does internal Q rotation).

2. Add GGML_MXFP_NO_HADAMARD=1 runtime toggle — disables Hadamard
   rotation for all MXFP types via env var. Needed because Hadamard
   benefit is architecture-dependent (helps Qwen3, hurts gpt-oss SWA).

3. Add MXFP6_E3M2 and MXFP8_E5M2 element formats — the M2-mantissa
   MXFP subspecies with wider dynamic range but coarser mantissa.
   Full wiring: type enums, traits, CUDA quantize/dequant, SoA layout,
   set_rows, flash attention VEC dispatch, CLI args, CPU fallback.

Also fix int32 overflow in llama-perplexity --save-all-logits for
contexts >= 16K with large vocab models.

Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>