[Engine] MTP drafts never proposed on sm_89 (RTX 4060 Ti 16GB, hybrid mode, drafts accepted 0 of 0) #4575

Summary

MTP speculative decoding never produces a single draft on an RTX 4060 Ti 16 GB (sm_89) / Windows 10, so decode speed stays well below the reference numbers for this model. The MTP block is found and loaded, --mtp 2 is passed to the engine, but every session reports drafts accepted 0 of 0.

This may be relevant because docs/QWEN36.md states the sm_89 build was compiled in CI but never actually executed on real hardware.

Environment

Reproduction

strata launch --family qwen36 --model ud-q4_k_xl --context 32k --yes --no-tui

Then a plain OpenAI-compatible request (400 generated tokens):

curl -s --noproxy '*' http://127.0.0.1:8080/v1/chat/completions \
  -H "Content-Type: application/json" \
  -d '{"model":"qwen3.6-35b-a3b-ud-q4_k_xl","messages":[{"role":"user","content":"Write a detailed essay about the history of tea."}],"max_tokens":400,"temperature":0}'

Observed behaviour

Engine is launched with MTP explicitly requested, and the log confirms the MTP block was loaded:

strata.exe --serve --native ...\Qwen3.6-35B-A3B-UD-Q4_K_XL.gguf --max-context 32768 --prefill auto --mtp 2
strata-q36: 753 tensors (layout checked), 4.40 GiB on the GPU in 4.9 s
strata-q36: prompt experts on MMQ (int8)
strata-q36: context 32768 cells, prompt chunk 2048, MTP block loaded, 6.69 GiB of VRAM free
strata-q36: hybrid experts: 66 of 256 per layer in VRAM (4.83 GiB), all 18.75 GiB in pageable host memory,
            the rest of a batch of <= 128 rows on 8 CPU threads, bigger prompt chunks streamed (1.10 GiB staging)

But on every single request, including long 400-token generations:

strata serve: session 0: prompt 33 tokens = 0 reused + 33 read in 980 ms (33.7 tok/s),
              400 generated in 14135 ms (28.3 tok/s), drafts accepted 0 of 0 (length)
strata serve: session 0: prompt 11 tokens = 0 reused + 11 read in 625 ms (17.6 tok/s),
              1 generated in 2 ms (462.1 tok/s), drafts accepted 0 of 0 (length)

0 of 0 (not 0 of N) looks like drafts are never proposed, rather than proposed and rejected.

Measured speed

Reference points from the docs for the same model and quant: R9700 32 GB = 117.8 tok/s, RTX 3060 12 GB (hybrid, only 37/256 experts in VRAM) = 58.5–59.7 tok/s. This machine places more experts in VRAM (66/256) than the 3060 and has higher VRAM bandwidth, yet is ~20% slower — consistent with MTP being inactive while the 3060 numbers presumably include it.

What I already tried (none changed 0 of 0)

1. --tune quick — reports already fastest, no parameter change.
2. --context 8k instead of 32k (frees VRAM for expert cache) — slightly faster, still 0 of 0.
3. Explicit --mtp on / --set mtp=... variants — no drafts.
4. --set pool-workers=16 --set pool-affinity=all — 35% slower (30 tok/s). The engine correctly warns: "16 CPU expert workers are configured, but this process can run only 16 CPU threads. The extra workers spin... Recommended: --pool-workers 7". Reverted to default 8.

Worker scaling, measured on the same box after enabling A-XMP (400 generated tokens, engine-reported tok/s):

6 and 8 are identical within noise, and 16 is much worse. So the CPU expert path looks bandwidth-saturated at ~6 threads rather than compute-bound — which would also explain why going from DDR4-2400 to DDR4-3200 (+33% memory bandwidth) only bought +13% decode. Worth noting in case it informs default worker heuristics: the engine picks physical-core count (8), but 6 already saturates DDR4 dual channel here.

Questions

1. Is MTP draft generation expected to work when the model runs in hybrid mode with all 18.75 GiB in pageable host memory? I could not find a documented restriction, and MTP block loaded suggests it should be active.
2. Does the draft model require additional VRAM beyond the 6.69 GiB reported free? If so, the log could say so instead of silently producing zero drafts.
3. Is there a way to get more verbose MTP diagnostics (e.g. draft proposer init/failure reason)? I did not find a flag for it.

Happy to run any diagnostic build or provide full logs / traces — the machine is available and reproducible. I can also re-test on other quant levels (UD-Q6_K_XL needs 48 GB RAM, which I can add) to see whether the behaviour is quant-specific.