Enable SM86 MXFP4 sparse-indexer cache

[Whamp]

Summary

Merge the reviewed DeepSeek V4 SM86 FP4 KV-cache capacity work into fork main:

• deterministic packed-KV allocation accounting and runtime reconciliation;
• MXFP4 sparse-indexer cache support on NVIDIA SM86;
• software E2M1/UE8M0 query and cache writers where Blackwell conversion PTX is unavailable;
• dedicated MXFP4 prefill and paged-decode MQA-logits kernels;
• fail-closed NVIDIA SM86/SM100-family capability gates;
• exact top-k/downstream-output, CUDA Graph, sanitizer, cubin, capacity, quality, and performance evidence.

The new indexer format remains opt-in. FP8 remains the default because the capacity gain comes with measured prefill and throughput regressions and only 25-26 MiB/card headroom at the 200K functional ceiling.

Duplicate-work check

I searched open Whamp/vllm and upstream vllm-project/vllm issues/PRs for DeepSeek V4, FP4/MXFP4, sparse indexer, and SM86.

Related upstream work is materially different:

• [Kernel] MXFP4 indexer cache for GLM-5.2 / DSA (glm_moe_dsa) vllm-project/vllm#48558 targets GLM-5.2 MXFP4 indexer caching, not this DeepSeek V4 SM86 runtime contract.
• [ROCm][Perf] Enabled FP4Indexer for DSV4 vllm-project/vllm#42908 is ROCm FP4 indexer enablement.
• [DSv4 triton] Add a pure-Triton fp4 pack fallback so the mxfp4 indexer kernel vllm-project/vllm#49282 is a pure-Triton FP4 packing fallback, not the complete SM86 write/read/logits/full-model path.
• [Feature] TRITON_MLA_SPARSE backend for SM8x/11x/12x DSA Sparse MLA Support vllm-project/vllm#38476 provides broader SM8x sparse-MLA support but not this cache format and validation.

No open Whamp/vllm PR duplicates this branch.

Validation

Focused and regression evidence is checksum-bound under:

• benchmarks/kernels/deepseek_v4/fp4_indexer_sm86/evidence/capacity_before_indexer
• benchmarks/kernels/deepseek_v4/fp4_indexer_sm86/evidence/baseline_comparison
• benchmarks/kernels/deepseek_v4/fp4_indexer_sm86/evidence/after_indexer

Key executed checks:

• 86/86 merged-main KV-cache and architecture-support CPU tests.
• 73 MQA-logits GPU regression cases.
• 40 compressor/writer-gather cases with expected backend skips.
• 21 fused-query cases with expected backend skips.
• Strengthened exact top-k-set, ordering-margin, downstream gathered-output, poisoned-tail, and CUDA Graph tests: 7/7 on RTX 3090.
• Compute Sanitizer memcheck: 0 errors.
• Compute Sanitizer racecheck: 0 hazards.
• Runtime and archived Triton cubins verified as sm_86.
• verify-full.sh passed.
• verify-stress.sh passed with exact NIAH through 195,812 tokens at the 200K profile.
• BenchLocal quick: 26/30 pass@1, 27/30 pass@3.
• Changed-file pre-commit, Ruff, formatting, mypy, SPDX, import/configuration, diff, and CodeGraph signature checks passed.

The reviewed branch was merged with current fork main; the only conflict was in vllm/v1/core/kv_cache_utils.py. The resolution preserves main's class-changing spec promotion and relocated capacity logging while retaining the reviewed allocation report. The post-resolution KV-cache suites pass 86/86.

Measured outcome

At the 175K profile, MXFP4 indexer caching increased reported cache capacity from 178,050 to 202,260 tokens. The explicit 200K profile reports 199,409 tokens and passed exact NIAH at 195,812 prompt tokens.

Matched tradeoffs versus the FP8-indexer FP4 control:

• decode: approximately -3.2%;
• concurrency-2 aggregate: approximately -3.9%;
• 10K prefill: approximately -4.8%;
• 90K prefill: approximately -29.7%;
• only 25-26 MiB/card headroom under long-context load.

Decision: retain as an explicit capacity experiment, not the default format.

Review and assistance

The change received independent standards/spec and kernel-safety review. Blocking findings were fixed, including unconditional architecture validation, optimized-Python rejection coverage, exact top-k/output tests, clean_logits=False paged tests, baseline provenance, and report claim corrections. REVIEW.md records the review and unavailable GLM reviewer quota.

AI assistance was used throughout implementation, diagnosis, testing, review synthesis, documentation, and merge-conflict resolution. The repository owner explicitly directed this merge into the Whamp fork.