Flint FP8/BF16 — per-layer fidelity policy

Compression status: this 76.35 GB checkpoint is retained as a numerical-fidelity control. For a substantially smaller candidate, see Flint FP8/BF16 (41.73 GB), with FP8 in all routed experts, fresh 4,756-question validation and complete numerical-fidelity results.

A conservative, weight-only quantization of RecursiveSI/flint, with FP8 only in the routed experts of layers 45–48 (zero-based). Every other weight is the original BF16 bytes. Weight tensors occupy 76.350 GB, versus 79.571 GB for BF16: 3.220 GB / 4.05% saved. This policy prioritizes fidelity, with modest compression.

On fresh validation text it retains 99.03% top-1 agreement with BF16 and has KL(BF16 ∥ quant) = 0.000793. These are output-fidelity measurements, not task accuracy. The policy was selected before this validation; production capability parity is not established.

Runtime status: this is a development checkpoint for a future dgpp Flint port. It uses the custom dgpp_mixed tensor contract and is not a drop-in Transformers, SGLang, vLLM or ModelOpt checkpoint. Native compressed inference is not implemented here. The included reference expands weights to BF16 and requires roughly 80 GB of GPU weight memory.

Source revision: 2a247be0c0aec895ccb0ac7ca92229ec6df37288. Produced and checked on an RTX PRO 6000 Blackwell (SM120, 97,887 MiB VRAM).

Precision assignment

There are 3,072 FP8 matrices. All 33,662 remaining source tensors are byte-identical, including all 638 non-expert tensors. No activations or KV cache are quantized. precision-policy.json specifies every routed projection in every layer; config.json repeats that policy. This checkpoint contains no NVFP4 tensors.

FP8 payloads use weight (E4M3 [N,K]) and weight_scale_inv (FP32 [N/128,K/128]). The scale is absmax(block) / 448; zero blocks use 1. Despite its conventional name, weight_scale_inv is a multiplicative dequantization scale: float32(weight[n,k]) * weight_scale_inv[n//128,k//128]. Scales are data-free. Precision assignment was chosen using separate selection text.

Why preserve the early layers?

Small early errors can cross hard top-k routing boundaries and change later expert selections. Keeping the router weights in BF16 does not preserve its input or its selected experts. In an FP32 arithmetic control, quantizing only layer 2 gives 95.54% agreement; supplying the source model's later expert IDs raises it to 99.85%. Matching random hidden-state noise produces similar drift without quantizing any weights. The author's independent llama.cpp branch reproduces the early/late distinction: FP8 only at layer 2 gives 95.21%, and only at layer 48 gives 99.63%. Frozen teacher routes are an offline diagnostic, not a deployment remedy.

A normalization-rounding mismatch was found in the initial Python reference and corrected for this per-layer work using actual FlashInfer CUDA fused-add RMSNorm. The quantization drift persists in that corrected path and the independent runtime. These controls support a routing amplification mechanism; they do not isolate low active parameter count as the cause.

The screen tested FP8 and NVFP4 individually at all 47 MoE layers, then gate/up/down precision separately in layers 41–48. Complete policies were evaluated jointly because layer errors are not additive. The chosen policy reached 99.07% on the 6,138 selection targets. NVFP4 did not establish a better size–fidelity tradeoff near the chosen target in the tested policies. This is the best tested whole-layer policy at that target, not a globally optimal assignment.

The earlier 30.80 GB NVFP4/FP8 checkpoint remains available as an explicitly experimental, more compressed alternative with substantially lower fidelity. Its numerical and limited task diagnostics do not establish capability parity. The complete investigation is in diagnostics/investigation.md.

Fresh validation

The primary policy and four comparisons were frozen before scoring 12 × 4,096-token sequences (49,140 next-token targets), balanced across WikiText-103 prose, MBPP code and GSM8K math text. All source rows from the earlier test corpora were excluded. Dataset revisions, exact tokens, row IDs and hashes are included. MBPP/GSM8K here are text sources, not official task evaluations. No policy was retuned using this validation.

The paired paths use identical input tokens and operations: BF16 weights/activations, FP32 attention scores and softmax, FP32 output head, and actual FlashInfer 0.6.16.post1 CUDA normalization including fused residual handling. Attention/expert operations remain PyTorch; this is not a full SGLang runtime parity claim. All measured processes had zero swap. No serving throughput is reported.

The conservative NVFP4 comparison uses FP8 at layer-46 up, layer-47 gate/down, and all layer-48 projections, with NVFP4 at layer-47 up only. The late projection mix uses FP8 in layers 41–48 except layer-47 up uses NVFP4. All unlisted weights remain BF16. Their complete policies are bundled; these comparisons are not additional released checkpoints.

This checkpoint by domain:

The aggregate is not a guarantee for every domain or answer. Small NLL differences do not establish capability improvements. No coding-agent, long-context, chat/reasoning or production accuracy-parity claim is made.

Independent check and integrity

The model author's llama.cpp Flint branch at 1b44e30775dcb2f93952116b05f89e5bd797fb00 gives 99.12% agreement, KL 0.000947, and source/quant NLL 2.039571 / 2.038854 on the same 6,138 selection targets. Both paths use the same binary, exact token IDs, F32 KV, disabled flash attention, and one document per decode. The FP8 values are decoded exactly to BF16 for this check, so it validates weight quality independently of the Python implementation, not compressed FP8 kernels. Input, binary and weight hashes and full tensor-preservation checks are recorded under diagnostics.

The export was rebuilt from source with the explicit policy. audit.json verifies all 48 shard SHA-256 hashes, tensor membership/shapes/dtypes, preservation of unquantized tensors, and exact equality of freshly quantized payloads to those evaluated during selection/validation. The tokenizer, chat template, generation configuration and source license are unchanged. quantization-manifest.json pins source, format, precision counts and hashes. Four greedy generation checks (copying, arithmetic, a Python function, JSON) use actual fused normalization and the exported weights; see generation-smoke.json. These are basic functionality checks, not a capability benchmark.

Reproduction

Use Python 3.12, CUDA PyTorch and a CUDA toolkit supported by the GPU. The measured environment used torch 2.8.0+cu128, Triton 3.4.0 and FlashInfer 0.6.16.post1 with CUDA 12.9 norm compilation. Set CUDA_HOME to the installed toolkit and FLASHINFER_USE_CUDA_NORM=1. Package pins are in reproduction/requirements.txt. The runtime needs enough VRAM for BF16-expanded generation; layer-streaming evaluation uses less.

hf download HawkBearPig/flint-FP8-BF16-Layerwise --local-dir checkpoint
hf download RecursiveSI/flint --revision 2a247be0c0aec895ccb0ac7ca92229ec6df37288 --local-dir source
pip install -r checkpoint/reproduction/requirements.txt
export FLASHINFER_USE_CUDA_NORM=1
python checkpoint/reproduction/flint_quantize.py prepare --source source --work work --corpus checkpoint/reproduction/corpus-policy-validation.json --precision-policy checkpoint/precision-policy.json
python checkpoint/reproduction/flint_quantize.py export --source source --work work --corpus checkpoint/reproduction/corpus-policy-validation.json --precision-policy checkpoint/precision-policy.json --output reproduced
python checkpoint/reproduction/flint_quantize.py audit --source source --work work --corpus checkpoint/reproduction/corpus-policy-validation.json --output reproduced
python checkpoint/reproduction/flint_fused_generate.py --checkpoint-dir reproduced --prompts-json checkpoint/reproduction/smoke-prompts.json --output smoke.json

The frozen comparison policies and complete results are under diagnostics. Repeating all five comparisons requires the additional candidate layer files; prepare can build each policy's files in a separate work directory. Selection scripts and older exact producer versions are retained under reproduction/history. reproduction/file-hashes.json and diagnostics/file-hashes.json pin the bundled artifacts.