Corrected 2026-08-22. The first version of this post reported that the repo's dense
baseline understates dense throughput by ~35%, that mxfp4 gets no speedup on this chip, and
that the gain shrinks on faster silicon. All three were measurement artifacts and are
wrong. A 37 GB workload was resident on the GPU during that run, and a later run drifted
25% from thermal throttling. What follows is a clean re-measurement. Details of the error
are in the comment below.

M5 Max results — DFlash2 works on differently-quantized targets, 1.5–1.9× measured

Hardware: Apple M5 Max, 128 GB, macOS 26.4.1, MLX 0.32.0 / mlx-lm 0.31.3.

Three targets, all qwen3_5 / 64 layers / hidden 5120:

• mlx-community/Qwen3.8-27B-mxfp4 — stock, mxfp4 group 32
• Qwen3.8-27B abliterated via Heretic (Optuna search,
  0 refusals, KL 0.0535) — MLX affine 4-bit group 64
• tozp/Qwen3.8-27B-OBLITERATED-V2-mlx-4bit (SVD + LEACE blend, MMLU −0.28pp) — same
  affine 4-bit g64

Protocol

Nine measurements, interleaved across models, 90 s cooldown before each, one dense
and one DFlash2 run per visit from a single model load. Dense measured with
mlx_lm.generate.stream_generate. Greedy, 300 tokens, the bench/test_dflash2.py LRU
prompt. GPU verified idle (oMLX loaded_count=0, GPU memory < 8 GB) before starting.

Results — medians of 3, with the per-round values

Round-to-round spread is under 2% on every cell, so the cooldown protocol holds. Your M3 Pro
figure is +57%; this chip gives +52% to +87%. The gain does not shrink on faster silicon.

1. The draft transfers to differently-quantized and modified weights

The draft is trained against the stock model. Both alternative targets are (a) abliterated
by completely different methods and (b) quantized with a different scheme (affine
4-bit g64 vs mxfp4 g32). Neither broke it — and acceptance went up, by 6–7 points,
reproducibly across all three rounds.

Two independent abliteration methods landing at 88–89% versus stock's 82% suggests the cause
is removing refusal directions as such, not any particular technique. A plausible mechanism:
lower next-token entropy after the refusal directions are gone, so the draft guesses right
more often. Untested — measuring mean token entropy across the three would settle it.

Greedy token-exactness vs dense, 120 tokens:

• mxfp4: token-exact
• OBLITERATED-V2: token-exact
• Heretic-abliterated: one flip at token 88 (' index' → ' position' in a docstring), then
  reconverges — 1 differing token in the following 32. The near-tie behaviour your
  LOSSLESS.md describes.

2. Two harness notes

Cold-start contamination. The first model load of a session measures far below steady
state — one run produced dense 1.9 t/s / speedup 18.00x. A warm-up generation before
timing would prevent a single-shot run from reporting that as a result.

Thermal drift. Running the three models back-to-back without cooldowns, this machine
decayed monotonically: the same mxfp4 measurement was 34.9 t/s at the start and 26.8 t/s
three minutes later, −23%. Sequential blocks make whichever model runs last look worst.
Your README already documents this for the M3 Pro (~14 t/s after 10 min); it applies to M5
Max too, and it is enough to invert a model-vs-model conclusion. Interleaving with cooldowns
fixed it — spread dropped from 23% to under 2%.

The dense arm of bench/test_dflash2.py also reads ~8% low versus mlx_lm.stream_generate
(30.2 vs 32.8 t/s), from the per-token .item() sync. Minor next to the two above, but it
inflates the reported speedup slightly.

Suggested changes

1. Warm-up generation before timing.
2. Interleave and cool down between models when comparing more than one.
3. Optionally use mlx_lm.generate.stream_generate for the dense arm.
4. Worth noting in the README that the target's quantization scheme is irrelevant to the
   draft — it widens the usable model set considerably.

Happy to run more on this hardware — K sweep, the 13.8k-context edit regime, KV-8bit.