fable-fusion-27b-mtp-q4-gguf (Enclave model volume)

Curated model volume for Enclave confidential inference: DavidAU's Fable-Fusion-27B (Qwen3.6-27B fine-tune) at NEO imatrix Q4_K_M with the trained multi-token-prediction head (~18.5 GB), bundled with the official tokenizer.json so the volume is self-contained.

This is the small-share sibling of EnclaveHost/fable-fusion-27b-mtp-gguf (Q5_K_M, ~21.2 GB) — same model, same geometry, one quant step down. The quant step is the point: with speculative decoding on, Q5_K_M needs about 33.1 GB to serve on a 256K-context node (21.2 weights + 9.7 KV at the q8_0 node window + ~0.6 GB head KV + working set), which does not leave room inside the 35.1 GB a 25% H200 share holds. Because the MTP head context is created lazily on the first speculative session, a tenant in that position preloads and warms up normally and then stalls the first real request. Q4_K_M puts the same sum near 30.4 GB and serves that share with ~4.7 GB to spare.

Upstream ships 25 quants plus vision mmproj files in one repo (~450 GB). A Modelwrap volume carries the whole repo and a multi-gguf volume makes the host's preload pick ambiguous, so this repo carries exactly one served gguf.

Provenance

File	Upstream	Revision	sha256
Fable-Fusion-27B-MTP-Q4_K_M.gguf	DavidAU/Qwen3.6-27B-Fable-Fusion-711-Uncensored-Heretic-NM-DAU-NEO-MAX-MTP-GGUF, file Qwen3.6-27B-Fable-Fus-711-UnHeretic-NM-DAU-NEO-MAX-NEO-MTP-Q4_K_M.gguf	ee5b7441ffe27869e1e5b4357733248d561c26b7	c796c2c011eaa0edf06395ff49cda5bfd4843ad52b86b58a83296dfc33849e4e
tokenizer.json	the Qwen3.x family copy, taken from EnclaveHost/fable-fusion-27b-mtp-gguf (byte-identical across the 9b / 27b / 122b volumes)	00b1e5483d5457fe32c0dd82f2d24a19ef0dc957	5f9e4d4901a92b997e463c1f46055088b6cca5ca61a6522d1b9f64c4bb81cb42

The gguf sha256 is also the blob hash HuggingFace serves for the upstream file, so the copy is verified end to end. LICENSE is the Apache-2.0 text; upstream is Apache-2.0.

Verified GGUF geometry

Read from the file header (llama.cpp gguf-py), and what the serving config must match:

key	value
general.architecture	qwen35 (hybrid SSM/attention)
qwen35.block_count	65 — 64 trunk layers + 1 MTP layer
qwen35.nextn_predict_layers	1 (blk.64.nextn.eh_proj, blk.64.nextn.enorm)
qwen35.attention.head_count / head_count_kv	24 / 4
qwen35.attention.key_length / value_length	256 / 256
qwen35.full_attention_interval	4 → 16 full-attention trunk layers + the dense MTP layer = 17 KV-bearing layers
qwen35.context_length	262144
vocab	248320, eos `[248046 <
file type	15 (Q4_K_M); the MTP tensors are Q8_0, as upstream sets them for every quant

The qwen35 arch is served unchanged by the fleet's pinned llama.cpp (LLAMA_COMMIT bec4772f); the MTP head additionally needs the batch4 MTP toolchain on the host, and older hosts serve the volume as a plain 27b.

Usage on Enclave

Wrapped as a Tinfoil Modelwrap volume (dm-verity; the root hash is part of the enclave measurement). Deployments attach it by name and the guest reads it at /models/<name>; the host preloads the GGUF as the wasi-nn ggml graph. Single file, so it loads on toolchains without split-family support, and with the tokenizer bundled llm-chat's default lookup needs no cross-volume configuration.

llm-chat catalog entry: chatml template, thinking: true, draft: "mtp" (self-drafting through the head — no second model), draft_tokens: 6. Upstream notes that MTP acceptance falls off above temperature 1, so keep sampling at or below it; draft_tokens / draft_accepted in the app's completion stats report the acceptance rate directly.

Attach this volume or the Q5_K_M one, never both. llm-chat serves the largest attached model that fits, so a deployment holding both picks the Q5 and gives back exactly the stall this volume exists to avoid.