vLLM quantized KV cache architecture gates (vllm/config/cache.py CacheDType, vllm/v1/attention/backends/flashinfer.py NVFP4 KV cache gate)

Read from the vLLM main branch 2026-10-04. The Implementation x Hardware support table in docs/features/quantization/README.md has NO KV-cache row at all, so every KV-cache cell in the hardware-support matrices is unchecked by that table; these are the code-level gates instead. CacheDType (vllm/config/cache.py) is the authoritative list of accepted --kv-cache-dtype values and reads verbatim: 'auto', 'float16', 'bfloat16', 'fp8', 'fp8_e4m3', 'fp8_e5m2', 'fp8_inc', 'fp8_ds_mla', 'nvfp4_ds_mla', 'turboquant_k8v4', 'turboquant_4bit_nc', 'turboquant_k3v4_nc', 'turboquant_3bit_nc', 'int4_per_token_head', 'int8_per_token_head', 'fp8_per_token_head', 'nvfp4', 'nvfp4_4over6'. The field docstring states the platform split: 'CUDA 11.8+ supports fp8 (=fp8_e4m3) and fp8_e5m2. ROCm (AMD GPU) supports fp8 (=fp8_e4m3). Intel Gaudi (HPU) supports fp8 (using fp8_inc).' and adds 'nvfp4_4over6 uses the NVFP4 layout and selects between max/6 and max/4 scales per 16 values by minimizing squared reconstruction error.' Two facts a reader of the TRT-LLM matrix cannot get from it: (1) there is NO 4-bit or 3-bit KV cache dtype on NVIDIA in vLLM - the sub-8-bit entries are TurboQuant (turboquant_4bit_nc / turboquant_k3v4_nc / turboquant_3bit_nc, NCC = no-compression residuals) and int4_per_token_head; (2) there are TWO NVFP4 KV variants (nvfp4, nvfp4_4over6) plus an MLA-specific nvfp4_ds_mla, and the FlashInfer backend maps every nvfp4* dtype to storage dtype torch.uint8 rather than a torch float4 type. The NVFP4 KV cache is hard-gated to SM100 in the FlashInfer backend: vllm/v1/attention/backends/flashinfer.py sets self.is_kvcache_nvfp4 = self.cache_dtype.startswith('nvfp4') and then, if that is true, requires force_use_trtllm_attention() and supports_trtllm_attention(is_prefill=True) and supports_trtllm_attention(is_prefill=False), else raises ValueError(f'--kv-cache-dtype {self.cache_dtype} requires the SM100 trtllm-gen FlashInfer path.'). Two further structural constraints in the same file: 'NVFP4 KV cache requires the trtllm-gen backend inside the wrapper; fa2/fa3 do not support nvfp4' (decode_wrapper and prefill_wrapper both force backend='trtllm-gen' when is_kvcache_nvfp4), and 'FlashInfer non-causal attention is not supported with NVFP4 KV cache' plus 'FlashInfer non-causal prefill is not supported with DCP yet'. (3) The arch predicate is vllm/utils/flashinfer.py:supports_trtllm_attention(), whose docstring reads 'SM90 (Hopper) and SM12x support the XQA decode kernel but not TRTLLM prefill. SM100+ supports TRTLLM for both phases. All others are unsupported.' Its body returns not is_prefill for is_device_capability(90) or is_device_capability_family(120), and otherwise is_device_capability_family(100) - and is_device_capability_family(100) compares cc//10 == 100//10, so it is true for cc 100 through 109, which INCLUDES sm107 (Rubin). It also returns False under envs.VLLM_BATCH_INVARIANT and when the NVIDIA artifactory is unreachable. Note the guard is 'if force_use_trtllm_attention() is False', and force_use_trtllm_attention() returns None when --attention-config.use_trtllm_attention is unset, so the default path is not blocked by it. CONSEQUENCE FOR THE MATRIX: on NVFP4 KV cache, vLLM agrees with the TRT-LLM sm100/103=Y and sm120=off pattern, but vLLM covers sm107 as supported while the TRT-LLM matrix marks Rubin(sm107) '.'. Cross-engine difference, not a contradiction: TRT-LLM ships no Rubin NVFP4 KV kernel and vLLM does, via the sm100-family trtllm-gen path. Separately, the attention-sinks prefill branch, which covers is_device_capability(90) or is_device_capability_family(120), carries a bare 'assert not self.is_kvcache_nvfp4' - so combining an NVFP4 KV cache with attention sinks is rejected at init on Hopper and consumer Blackwell, on top of the SM100 prefill gate that already excludes those parts. Per-head KV scaling: the quantized_kvcache doc states per-attention-head quantization 'is currently available only with the Flash Attention backend and requires the calibration pathway provided by llm-compressor'.