[Model][SM70][FP8] Integrate calibrated E4M3 QSA KV capacity path

[yangzhuxinyzx]

Purpose

Integrate the calibrated Qwen4Exp QSA E4M3 KV capacity path from #447 plus the independent hot-loop follow-ups #452 and #453 on current public main after #460.

This is an explicit capacity mode, not a new default. The validated contract is NVIDIA SM70, TP4, MTP0, FP16 activations, and a checkpoint-revision-bound 24-scale overlay. Unsupported combinations fail closed. Default FP16/BF16 KV and current FlashNext MTP4 serving behavior are unchanged.

Base SHA: c4c81296874771bd8cb256899ea0eb77970a4a6c.

Changes

• Store only the main QSA K/V cache in calibrated E4M3; keep raw and compressed indexer caches in FP16.
• Require all 24 finite positive per-layer K/V scales and refuse startup when the overlay is missing or incomplete.
• Add offline calibration and revision-bound overlay tooling.
• Cover Flash-V100 grouped page4, XQA, generic Triton, and mixed catch-up/decode batches.
• Use the exact bitcast E4M3 software decoder and hoist K/V scaling out of per-element Triton load loops.
• Preserve [Perf][SM70] Share Qwen4Exp QSA top-k workspace #460 model-level QSA top-k workspace sharing and its private-buffer fallback.

The only source conflict with current main was an adjacent-method insertion in qsa.py: #460 added _set_topk_indices_buffer, while #447 added validate_loaded_kv_scales. The integrated tree retains both. One #460 test fixture was updated with the now-required FP16 cache config.

Test Plan

• Run the nine focused Qwen4Exp/QSA benchmark, configuration, cache, numerical, calibration, operator, and weight-loading test files without consuming local GPUs.
• Run changed-file pre-commit, diff hygiene, and Python compile checks.
• Reuse the exact-commit V100 numerical, quality, capacity, and performance evidence recorded in [Model][SM70][FP8] Add calibrated E4M3 QSA KV cache #447, [Perf][SM70][FP8] Use bitcast E4M3 decoder in QSA #452, and [Perf][SM70][FP8] Hoist QSA E4M3 KV scales #453; do not reinterpret that evidence as MTP4 or 256K validation.

Test Result

• Integrated focused suite: 68 passed, 10 skipped. CUDA-only cases skipped because local GPUs were intentionally not used.
• All changed-file pre-commit hooks passed, including Ruff, format, mypy, clang-format, SPDX, accelerator API, configuration, and attention-backend checks.
• git diff --check and Python compile checks passed.
• Original exact-runtime-commit V100 evidence: 4x V100, TP4, MTP0, full-and-piecewise CUDA Graph, NVFP4 and AWQ W4A16 checkpoints.
• KV capacity: approximately 1.83x at the same memory budget.
• Matched quality: 128K retrieval 6/6 vs 6/6, held-out tools 10/12 vs 10/12, GSM8K 29/32 vs 29/32, HumanEval/MBPP 9/10 vs 9/10, with zero paired regressions in those gates.
• Performance tradeoff: E4M3 decode was approximately 1.92-2.54% slower and long-context server E2E approximately 1.26-3.12% slower, depending on checkpoint/matrix.

Validation boundary

• This first-phase route deliberately requires MTP0 and TP4.
• Prefix caching, MTP, TP8, and a 256K end-to-end run are not claimed as validated.
• The capacity mode requires a scale overlay generated for the exact checkpoint revision; no generic or unit-scale fallback is accepted.
• Default FlashNext FP16 KV, MTP4, prefix-cache, sampling, and output-quality paths are unchanged.

Provenance

Runtime and test commits retain the original #447/#452/#453 authorship and DCO trailers. OpenAI Codex assisted with latest-main integration, conflict review, test execution, and this write-up.