gguf-tools splicer cannot read the MXFP4 GGUF this repo publishes (unsupported GGML tensor type 39)

[datanerdie]

The Flash MXFP4 GGUF (ds4f-mxfp4) cannot be used as a donor or base with gguf-tools/mixed/splice_mixed_expert_layers_gguf.py, because its GGML_QUANT_SIZES table has no entry for type 39.

error: unsupported GGML tensor type 39; add it to GGML_QUANT_SIZES

Everything else in the splicer already handles it correctly — it deliberately does not require base and donor tensor types to match, and it writes each tensor's own ggml_type through. Only the block-size table is missing an entry.

One-line fix, using the values from ds4's own table at ds4.c:2052 ([39] = {"mxfp4", 32, 17}):

 GGML_QUANT_SIZES = {
     ...
     26: (1, 4, "I32"),
+    39: (32, 17, "MXFP4"),
 }

Verified locally with --dry-run, splicing MXFP4 routed experts for layers 25-42 onto the IQ2XXS/Q2_K hybrid base:

selected donor tensors: 54
selected donor types: MXFP4:54
base tensor payload:   90.88 GiB
mixed tensor payload: 107.76 GiB

Motivation, in case it is useful: this produces a quant sized for a single 128 GB Mac. The published Flash quants are 80.8 / 90.9 GiB (fit, leaving ~21 GiB of the 112 GiB wired limit unused) then jump to 145.3 / 153.3 GiB (do not fit). Splicing MXFP4 experts into the upper layers fills that gap at 107.76 GiB.

Happy to open a PR if useful.

[Berserk-hub150]

Hi, I'd like to work on this. I'll add MXFP4 type 39 support to the splicer and include a small regression check. Please let me know if you are already preparing a PR.

[datanerdie]

Not preparing a PR — please go ahead, it's yours.

For what it's worth, a one-line addition was all my use needed:

GGML_QUANT_SIZES = {
    ...
    26: (1, 4, "I32"),
    39: (32, 17, "MXFP4"),
}

using ds4's own values from the table at ds4.c:2052 (32 values → 17 bytes: 16 B of codes + 1 B E8M0 scale). Nothing else needed changing — the splicer already writes each tensor's own ggml_type through, and deliberately does not require base and donor tensor types to match, which is the whole point of it.

Verified end-to-end on macOS/Metal: spliced layers 30-42 of the MXFP4 GGUF onto the q2-q4 hybrid, giving a 100.26 GiB model that loads and runs at ctx 262144 on a 128 GB M4 Max. Perplexity on a held-out set was 1.509144 for the spliced build against 1.513394 for the hybrid base and 1.494175 for full MXFP4 — i.e. it lands between the two, so the donor tensors are genuinely being read and placed rather than copied as garbage. That comparison is probably the cheapest end-to-end check that the size table entry is right, since a wrong stride would not produce a sane perplexity.

One note that may help the regression check: --dry-run prints the plan and the resulting file size without writing ~100 GiB, so a test can cover the type-table path without a large fixture.