Views
No views yet
--spec-type draft-mtp), no second model to wire up.quant size notes
NVFP4-MTP 18.2 GB ← Blackwell FP4 tensor cores + MTP. The one to grab on RTX 50xx / PRO 6000.
bf16-MTP 54.7 GB lossless master (exact bf16, not a lossy f16 re-map) + MTP
Q8_0-MTP 29.0 GB near-lossless reference + MTP
Q6_K-MTP ~22 GB + MTP
Q5_K_M-MTP ~19 GB + MTP
Q4_K_M-MTP ~17 GB + MTP (the common daily-driver size — and here it carries the draft head)
IQ4_XS-MTP ~14 GB imatrix low-bit + MTP [fast-follow]
Q3_K_M-MTP 13.5 GB imatrix low-bit + MTP — integrity-verified, NVFP4 parity (see below)
IQ3_M-MTP 12.8 GB imatrix low-bit + MTP — smallest full-quality rung, fits a 16 GB card
IQ2_M-MTP ~10 GB imatrix low-bit, fits a 12GB card + MTP [fast-follow]
mtp-head/… ~2.4 GB standalone draft head, for pairing with a base GGUF via --model-draftNVFP4-Q4_K_M-MTP (15.7 GB) lowers the non-FP4 base tensors to Q4 — aimed at 24 GB dual-Blackwell
(2×12 GB) where the 18.2 GB flagship + 128k KV + MTP won't fit. Honest finding: the savings are
marginal because the NVFP4 GEMMs dominate the file and are fixed — the base type only touches
~3 GB of embeddings/norms/GDN. The full curve we measured (Q8→Q6→Q5→Q4 base): 18.2 / 16.8 / 16.3 /
15.7 GB. Quality holds (quant-sensitivity + coherence verified); only the bottom rung meaningfully
helps a 24 GB budget, so that's the one shipped. GGUF GPU-speed numbers are pending (validated on CPU
here; llama.cpp CUDA testing is a follow-up).mtp-head/mtp-ThinkingCap-Qwen3.6-27B-head-Q8_0.gguf) is only for pairing with a
separate base GGUF; loading it alone crashes. It lives in a subdirectory on purpose — keeping it
out of the repo root so HF's "Use this model" / llama.cpp -hf never resolves to it by mistake.1llama-server --model ThinkingCap-Qwen3.6-27B-Q4_K_M-MTP.gguf \
2 --n-gpu-layers 99 --ctx-size 8192 --flash-attn on --jinja \
3 --spec-type draft-mtp --spec-draft-n-max 3--spec-draft-n-max 2 maximizes acceptance; 3 maximizes throughput. On Blackwell, grab the
NVFP4 file — MTP verification is nearly free on FP4 tensor cores.One critical setting: don't decode greedy. This is a thinking model; attemperature 0it can loop and never close</think>. Use the model's intended sampling (temp 0.6, top_p 0.95, top_k 20). Greedy is the #1 cause of "it rambled and gave no answer" — not the quant.
<think> and a direct solution).--linear-backend marlin on this hybrid (GDN/Mamba) arch:
the FlashInfer FP4 kernel silently hangs in CUDA-graph capture, while marlin surfaces the real
cause — a Mamba-cache-block limit fixed with --max-num-seqs 256 --gpu-memory-utilization 0.85.nextn blocks:--spec-type draft-mtp).thinking tokens (15-prompt reasoning set, temp 0.6)
base Qwen3.6-27B mean 1401 tok
ThinkingCap-NVFP4 mean 675 tok → ~40% fewer, per-prompt mean (range 3–82%)quant_sensitivity (arithmetic/exact-recall/format) 93% near-lossless
function_call 94% quant clean on tool-use
coding (hard_v2, adversarial) 50% suite is deliberately hard for a 27B;
quant-uniform damage ruled out by the two above
MTP draft acceptance (--spec-type draft-mtp) 62–91% (prompt-dependent)Q3_K_M and IQ3_M on the same integrity suites before shipping
them (imatrix computed over a standard calibration set) — they come out at parity with the NVFP4 build,
so the quant curve isn't leaking quality down to ~12 GB:suite Q3_K_M IQ3_M NVFP4 (ref)
quant_sensitivity 14/14 14/14 13/14
function_call 51/54 51/54 51/54 (same 3 misses across all builds = a
model/harness ceiling, not quant damage)--spec-type draft-mtp — a solid free
speed-up straight out of the box, confirming the authors' "MTP works well as-is."