Native MTP loses at 88.6% acceptance: verification is free, drafting costs more than the model

[Andrei-Dr]

docs/39 left MTP as re-runnable once the decode gap closes, and docs/57 closed it on one arm. So it was re-run — same server, flags, mounts and checkpoint as docs/57, with only --speculative-config differing. docs/59, harness in benchmarks/matrix/mtp_serve.sh + mtp_ab.sh.

The precondition was met and the conclusion still inverted.

tg256	baseline	N=1	N=2	N=3
d0	36.13	30.27	27.04	24.53
d32768	29.62	24.09	19.66	16.52
ratio @ d0	1.000	0.838	0.748	0.679

Baseline reproduces docs/57 (pp2048 @ d32768: 1058.87 here vs 1055.51 there) and every arm logged Selected AiterInt8ScaledMMLinearKernel, so no arm quietly fell back to Triton.

This is not an acceptance failure — 88.6% at position 0 (1084/1224), inside the 84.8–89.1% band docs/25 measured on the 80B.

Fitting step cost as a + bN at d0 over N=1,2,3:

• a = 1.11 — verification is nearly free at M=2..4, exactly as docs/57's M=1 30.60us vs M=8 33.64us shape predicted. That part of the bandwidth-roofline argument was right.
• b = 1.16 — one MTP draft forward costs more than all 64 layers of the target. Since b > 1, break-even is impossible at any acceptance rate, not merely unprofitable.

Mechanism, from the checkpoint's safetensors header:

	bytes/token	achieved
target (64 layers, W8A8)	26.93 GB	973 GB/s — 83% of 1170
MTP draft (1 layer + the shared bf16 lm_head)	3.29 GB	102 GB/s — 9% of 1170

102 GB/s is round 62's "113 GB/s of 1170, latency-bound, not enough work in flight" reproduced on an independent workload — a one-layer forward cannot fill a 104-CU card, while the 64-layer target amortizes the same fixed cost sixty-four times. Improving the target made speculation worse, not better, and will continue to.

lm_head is 2.54 GB of the draft's 3.29 (it is in the checkpoint's quant ignore list, and vLLM shares it with the drafter) — the one lever that moves b materially, though bytes are only 12% of the problem.

Second, separate finding, left open: prefill regresses 23-25%, flat across N, from a decode-side flag. A startup-only A/B rules out KV capacity (-5.8%), graph mode and prefill graph count (identical, 48 PIECEWISE both arms), and the GDN prefill kernel (identical). Suspect is scheduling — gdn_attn.py:112 _init_reorder_batch_threshold(1, use_spec_decode) on a 48-of-64-GDN-layer model, and/or draft slot reservation shrinking the effective prefill chunk. Not chased here because b > 1 closes the line without it, but it is a defect rather than a tradeoff.

Two ledger entries added (the MTP close, and the prefill regression as open-defect). No production change.