Qwen3.6-35B-A3B Uncensored · 1M Context + MTP

---

English

Overview

This is HauhauCS’s Aggressive uncensored build of Qwen3.6-35B-A3B, extended to a 1,010,000-token context (YaRN rope scaling, factor 4) and fused with the official MTP speculative-decoding layer at the GGUF tensor level. Weights are bit-identical to the HauhauCS release apart from rope metadata and the added MTP layer.

This repo publishes the model for Ollama with two tags that share the same 21 GB Q4_K_M GGUF (qwen35moe, 35.5B, context 1,010,000) but differ in Modelfile parameters — forming a clean MTP on/off twin pair for A/B comparison. Note: “1M” is an approximate label — the actual maximum context is 1,010,000 tokens (there is no 1,048,576 window); the :mtp tag drops it to 524,288 (512k) for performance. The MTP layer was activated on Ollama (it is dormant by default for imported GGUFs) and the Modelfile was optimized for coding-agent use, with full benchmark data included.

Capabilities

Capability	Status	Evidence
1M context (1,010,000)	Certified	70⁄70 needles, full ladder 64K→1M, 10 depths per rung, f16 KV, temp 0
MTP speculative decoding	Grafted & vetted	284.6 → 380.1 tok/s (+33.6%), acceptance 0.864 (RTX 5090, llama-server)
Uncensored	HauhauCS Aggressive	Trunk weights bit-identical to the HauhauCS release
Vision	mmproj available	mmproj-qwen36-hauhau-f16.gguf (899 MB), attach at runtime
Thinking / Tools	Native	Qwen3 thinking mode + tool calling (RENDERER/PARSER qwen3.5)

Two tags, one weight

Tag	MTP	num_ctx	Sampling	Purpose
:mtp	✅ On (draft_num_predict 4)	524,288 (512k)	0.6 / 0.95 / 20	Coding / long generation — decode-first
:normal	❌ Off (pure autoregressive)	1,010,000 (1.01M)	0.6 / 0.95 / 20	Long-context Q&A — prefill-first

Both tags ship with RENDERER qwen3.5 / PARSER qwen3.5 and stop <|im_end|> — required for tool-heavy coding-agent use (imported GGUFs without a native renderer hit chat-template bugs under tool calls).

MTP on Ollama — the key fix

The GGUF carries 1 embedded MTP layer (qwen35moe.nextn_predict_layers=1, tensors blk.40.nextn.*). Ollama does not enable speculative decoding for imported GGUFs automatically — without PARAMETER draft_num_predict, the MTP tensors sit dormant (no implementations specified for speculative decoding).

vs. satgeze’s Ollama build: the satgeze/qwen36-35b-uncensored-1m Ollama release ships the same MTP-carrying GGUF (:latest, 23 GB), but its Modelfile sets no draft_num_predict — the MTP tensors stay dormant and you must pass the parameter manually at runtime (/set parameter draft_num_predict 4 in ollama run, or options.draft_num_predict in the API). This repo’s :mtp tag has draft_num_predict 4 baked into the Modelfile — MTP is on by default, no extra parameters needed.

Fix: add PARAMETER draft_num_predict 4 to the Modelfile. Measured on 2× TITAN RTX (48 GB), same prompt / num_ctx / num_predict:

Config	Median decode
MTP active (draft_num_predict 1, short-context test)	36.03 tok/s
MTP dormant (no draft)	23.98 tok/s
Speedup	≈ 1.50×

A 1-layer MTP has a theoretical ceiling of ~2×; 1.5× is close to it. On a MoE the per-step expert compute is expensive, so the autoregressive steps MTP saves are worth more. The 1.5× figure is from an early short-context run at draft_num_predict 1; the shipped :mtp tag uses 4 (tuned below).

Modelfile optimization for coding

Three config defects were fixed for coding-agent use:

#	Issue	Fix
1	Missing RENDERER/PARSER → tool-heavy template bugs	Add RENDERER qwen3.5 / PARSER qwen3.5
2	draft_num_predict 8 overshoots a 1-layer MTP	Tuned to 4 (measured 8→4 gives +10% decode on this MoE)
3	Invalid presence_penalty 0.0 line (silently ignored)	Removed
4	No num_ctx default	:mtp → 524,288; :normal → 1,010,000
5	num_ctx scientific-notation round-trip bug (1.01e+06 breaks ollama create)	Stored as plain integer

Sampling 0.6 / 0.95 / 20 is the official Qwen3 thinking-mode recommendation and is kept for both tags.

Benchmark data

All measured on 2× TITAN RTX (48 GB VRAM), Ollama dev build, OLLAMA_NUM_PARALLEL=1, OLLAMA_FLASH_ATTENTION=1, OLLAMA_KV_CACHE_TYPE=q8_0. Full reports in docs/qwen-perf-comparison/.

MTP on/off twin comparison (same 21 GB weight, only draft_num_predict differs, 10-run trimmed mean, 262k ctx):

Metric	:normal (MTP off)	:mtp (draft=4)	Change
decode (tok/s)	19.21	27.72	+44.3%
prefill (tok/s)	1360.5	800.7	−41.2%

MTP trades prefill for decode. It pays off when output is long (decode-dominated); for pure long-context Q&A (prefill-dominated) prefer :normal.

draft_num_predict tuning (same model, only draft changed, cold-to-cold):

draft	decode (tok/s)
8	26.59
4	29.22 (+9.9%)

draft_num_predict is not “bigger is faster” — on this MoE the sweet spot is ~4 (draft=8 overshoots; the draft-context overhead outweighs extra accepted tokens).

Long-context throughput — fleet of 4 (qwen35-claude-distill:9b-q8_0 Q8_0 dense 9.2B, qwen35-claude-distill:latest F16 dense 9.2B, qwen3.6:35b-a3b-mtp-q8_0 Q8_0 MoE A3B, this model Q4_K_M MoE A3B+Mamba); only this model completed all three rungs. R2/R3 measured with num_ctx raised to 1,010,000 — the 696k/977k figures are fill lengths within that window:

Rung	prefill (tok/s)	decode (tok/s)	VRAM peak
R1 · 238k	1200.7	21.0	41,950 MB
R2 · 696k	504.2	9.1	45,800 MB
R3 · 977k	361.9	6.4	48,130 MB

Mamba/SSM layers keep KV near-constant (238k→977k KV only +6 GB), which is why 977k fits in 48 GB. Dense models OOM/timeout at 696k+ without Flash Attention.

VRAM reality check: the “1M context” model’s hidden cost is KV-cache preallocation — 21 GB weights → 40.9 GB VRAM at 1M ctx. On a 48 GB card it nearly fills the card. (The 48,130 MB peak at 977k includes weights + KV + compute buffers; 40.9 GB is the KV preallocation alone.)

MTP prefill at runtime (live log excerpts)

Captured from server.log while running :mtp (512k ctx, q4_0 KV, Flash Attention). MTP is active by default — no manual parameters needed:

llama-server.exe ... -c 524288 -np 1 --spec-type draft-mtp --spec-draft-n-max 4 --spec-draft-backend-sampling --cache-type-k q4_0 --cache-type-v q4_0 --flash-attn on
spec common_specu: adding speculative implementation 'draft-mtp' (n_max=4)

Two prefill scenarios — one incremental (warm cache), one full cold prefill:

Case A — incremental prefill, 585 new tokens on a cached 117k context (task 8982):

slot print_timing: id 0 | task 8982 | prompt eval time = 1987.04 ms / 585 tokens (3.40 ms per token, 294.41 tokens per second)      
slot print_timing: id 0 | task 8982 |        eval time = 6312.91 ms / 332 tokens (19.01 ms per token, 52.59 tokens per second)      
slot print_timing: id 0 | task 8982 | draft acceptance = 0.57108 (233 accepted / 408 generated), mean len = 3.28
srv prompt_save: - saving prompt with length 118892, total state size = 952.653 MiB (draft: 234.479 MiB)

Case B — full cold prefill, 146,631 tokens from scratch (task 0); throughput decays as the context grows:

slot print_timing: id 0 | task 0 | prompt processing, n_tokens = 10240,  progress = 0.07, t = 6.75 s / 1516.37 tok/s
slot print_timing: id 0 | task 0 | prompt processing, n_tokens = 51200,  progress = 0.35, t = 36.82 s / 1390.70 tok/s
slot print_timing: id 0 | task 0 | prompt processing, n_tokens = 146627, progress = 1.00, t = 152.53 s / 961.33 tok/s
slot print_timing: id 0 | task 0 | prompt eval time = 152890.14 ms / 146631 tokens (1.04 ms per token, 959.06 tokens per second)    
slot print_timing: id 0 | task 0 |        eval time = 10719.56 ms / 446 tokens (24.03 ms per token, 41.61 tokens per second)        
slot print_timing: id 0 | task 0 | draft acceptance = 0.43140 (283 accepted / 656 generated), mean len = 2.73

Key observations:

Case	prefill tokens	Throughput	Note
A · incremental (warm cache)	585 new (117k cached)	294 tok/s	Only new tokens prefilled; context already cached
B · full cold prefill	146,631 (100%)	1516 → 961 tok/s (−37%), avg 959	Decays as KV cache grows

Observation	Data	Implication
MTP active by default	draft-mtp + n_max=4	No manual draft_num_predict needed
Small-prompt prefill	13 tok → 13.2 tok/s; 19 tok → 47 tok/s	MTP draft-context prefill overhead dominates
Draft KV cost	prompt_save: total 952.7 MiB (draft: 234.5 MiB)	Draft context KV ≈ 25% of total state (q4_0)
Draft acceptance	0.43–0.57; mean len 2.73–3.28	~2.7–3.3 draft tokens per step
Decode throughput	41.6–52.6 tok/s	MTP decode speedup in effect

Both cases confirm “MTP trades prefill for decode”: incremental prefill on a warm cache is fast (294 tok/s), while full cold prefill throughput decays as the context grows (1516 → 961 tok/s over 146k tokens). Use :normal for prefill-dominated long-context Q&A, :mtp for decode-dominated long generation.

Strengths

1. 1M context, certified — YaRN factor 4, ⁷⁰⁄₇₀ needles across the full 64K→1M ladder. Ideal for very long documents, codebase analysis, and RAG over large corpora.
2. MTP speculative decoding actually works on Ollama — activated via draft_num_predict, measured 1.5× decode speedup (36.03 vs 23.98 tok/s); twin comparison shows +44% decode.
3. Uncensored — HauhauCS Aggressive trunk, bit-identical weights, no alignment hedging.
4. Fast prefill — MoE A3B (3B active) + Q4_K_M gives the fastest prefill in its class (1200 tok/s at 238k).
5. Long-context VRAM control — Mamba/SSM layers keep KV near-constant; the only model in the test fleet to complete 238k→696k→977k on 48 GB.
6. Coding-agent ready — RENDERER/PARSER qwen3.5, thinking + tools, Qwen3 official sampling values.
7. Clean A/B pair — :mtp vs :normal on the same weight lets you pick decode-first or prefill-first without switching models.
8. Compact single file — 21 GB Q4_K_M, memory-friendly relative to Q8/F16.

Limitations & trade-offs

1. 1M context eats VRAM — KV preallocation pushes 21 GB weights to 40.9 GB actual usage; a 48 GB card is nearly full, leaving little room for other models.
2. MTP trades prefill for decode — +44% decode but −41% prefill. For long-context Q&A (prefill-dominated) enabling MTP makes total response time longer; use :normal there.
3. draft_num_predict needs tuning — not bigger-is-better; sweet spot ~4 on this MoE. Draft context doubles compute buffers at long ctx (OOM risk on ≤48 GB near 512k).
4. MoE is slow on Turing GPUs — without MTP, decode (19.2 tok/s) is slower than a 9B dense Q4 (26.6). The MoE advantage needs newer GPUs + MTP to materialize.
5. Default thinking mode — without explicit "think": false, small num_predict returns an empty response (tokens all spent in the thinking segment). Harnesses must handle thinking.
6. Vision not bundled — the mmproj vision tower (899 MB) is not included in these tags; attach it separately if needed. That is a deliberate gap rooted in Ollama’s scheduler: server/sched.go hard-caps multimodal architectures at num_parallel = 1 with the comment “Some architectures are not safe with num_parallel > 1” (ref: ollama#4165) — the vision-encoder cache cannot be shared across concurrent requests, so multi-modal parallelism errors with failed processing images. qwen35/qwen35moe sat on that blocklist too; this repo’s build removes them for text-only use (that’s what lets :mtp/:normal serve num_parallel > 1), and the removal is only safe while no projector is attached. Once you attach mmproj and send images, you’re back in the unsafe territory — keep num_parallel = 1 for image-mode requests.
7. Q4_K_M quantization loss — lossy vs F16/Q8; base capability carries over modulo quantization.
8. Slow cold load & long-context decode — 21 GB cold load ~10–16 s; decode drops to 6.4 tok/s at 977k.

Usage

# MTP on — coding / long generation
ollama run lucloner/wen36-35b-uncensored-1m:mtp

# MTP off — long-context Q&A
ollama run lucloner/wen36-35b-uncensored-1m:normal

For coding agents that don’t handle thinking segments, pass "think": false in the API request.

VRAM notes

• :mtp at 512k: MTP creates a draft context with the same n_ctx as the main context → compute buffers roughly double. On ≤48 GB cards, ~512k with MTP is near the ceiling; if it OOMs, set draft_num_predict 0 to disable MTP (prefill +47% at 238k, only lose decode speculation).
• :normal at 1.01M: KV preallocation alone is ~20 GB on top of the 21 GB weights.

Credits

• Base model: Qwen (Apache-2.0), including the official MTP layer
• Uncensoring & trunk quant: HauhauCS
• MTP GGUF packaging: Unsloth
• 1M YaRN extension, MTP graft, certification: SatGeze
• Ollama MTP activation, Modelfile optimization & benchmarking: lucloner

Original model card: satgeze/Qwen3.6-35B-Uncensored-HauhauCS-1M-GGUF · Mirrors: Hugging Face | ModelScope

License

Apache-2.0 (same as the Qwen3.6-35B-A3B base).

---

中文

概览

本模型是 HauhauCS 的 Aggressive 去审查版 的 Qwen3.6-35B-A3B，经 YaRN rope 缩放（factor 4）扩展至 1,010,000 token 上下文，并在 GGUF 张量层融合了官方 MTP 投机解码层。除 rope 元数据与新增的 MTP 层外，权重与 HauhauCS 原版逐位一致。

本仓库为 Ollama 平台发布该模型，两个 tag 共用同一份 21 GB Q4_K_M GGUF（qwen35moe，35.5B，上下文 1,010,000），仅 Modelfile 参数不同——构成一组纯净的 MTP 开/关对照。注意：「1M」是近似叫法——实际最大上下文为 1,010,000 token（并不存在 1,048,576 的窗口 ）；:mtp tag 为性能将其降至 524,288（512k）。MTP 层已在 Ollama 上激活（导入式 GGUF 默认休眠），Modelfile 针对编程 / Coding-Agent 使用做了优化，并附完整实测数据。

能力

能力	状态	依据
1M 上下文（1,010,000）	已认证	70⁄70 needles，64K→1M 全阶梯，10 depths/rung，f16 KV，temp 0
MTP 投机解码	已移植并验证	284.6 → 380.1 tok/s（+33.6%），acceptance 0.864（RTX 5090，llama-server）
去审查	HauhauCS Aggressive	主干权重与 HauhauCS 原版逐位一致
视觉	可附加	mmproj-qwen36-hauhau-f16.gguf（899 MB），运行时挂载
思考 / 工具	原生支持	Qwen3 thinking 模式 + 工具调用（RENDERER/PARSER qwen3.5）

两个 tag，同一份权重

Tag	MTP	num_ctx	采样	用途
:mtp	✅ 开（draft_num_predict 4）	524,288（512k）	0.6 / 0.95 / 20	编程 / 长输出——decode 优先
:normal	❌ 关（纯自回归）	1,010,000（1.01M）	0.6 / 0.95 / 20	长上下文问答——prefill 优先

两个 tag 均带 RENDERER qwen3.5 / PARSER qwen3.5 与 stop <|im_end|>——导入式 GGUF 在工具调用密集的编程场景下必须显式指定 renderer，否则 chat template 会出错。

Ollama 上的 MTP 激活（核心工作）

该 GGUF 内嵌 1 层 MTP（qwen35moe.nextn_predict_layers=1，张量 blk.40.nextn.*）。Ollama 对导入式 GGUF 不会自动启用投机解 码——缺 PARAMETER draft_num_predict 时 MTP 张量处于休眠状态（no implementations specified for speculative decoding）。

与 satgeze 的 Ollama 版对比：satgeze/qwen36-35b-uncensored-1m 是模型作者 satgeze 在 Ollama 上发布的版本（:latest，23 GB），使用同一份含 MTP 层的 GGUF，但其 Modelfile 未设置 draft_num_predict——MTP 张量保持休眠，需在运行时手动传入参数（ollama run 中 /set parameter draft_num_predict 4，或 API 的 options.draft_num_predict） 才能激活。本仓库的 :mtp tag 已将 draft_num_predict 4 写入 Modelfile——MTP 默认启用，开箱即用，无需额外参数。

修复：在 Modelfile 中加入 PARAMETER draft_num_predict 4。实测（2× TITAN RTX 48 GB，同 prompt / num_ctx / num_predict）：

配置	中位 decode
MTP 激活（draft_num_predict 1，短上下文实测）	36.03 tok/s
MTP 休眠（无 draft）	23.98 tok/s
加速比	≈ 1.50×

1 层 MTP 理论上限约 2×，实测 1.5× 已接近上限——MoE 单步激活专家计算贵，MTP 省下的自回归步价值更大。1.5× 为早期短上下文 draft_num_predict 1 实测；正式 :mtp tag 用 4（见下方调优）。

编程使用优化

针对编程 / Coding-Agent 使用修复了三处配置缺陷：

#	问题	修复
1	缺 RENDERER/PARSER → 工具调用场景模板出错	加 RENDERER qwen3.5 / PARSER qwen3.5
2	draft_num_predict 8 超出 1 层 MTP 甜点	调优为 4（本 MoE 上实测 8→4 后 decode +10%）
3	非法 presence_penalty 0.0 行（被静默忽略）	删除
4	缺 num_ctx 默认值	:mtp → 524,288；:normal → 1,010,000
5	num_ctx 科学计数法 round-trip bug（1.01e+06 使 ollama create 报错）	存储为普通整数

采样 0.6 / 0.95 / 20 是 Qwen3 thinking 模式官方推荐值，两个 tag 均保留。

实测数据

以下数据均在 2× TITAN RTX（48 GB）、Ollama dev 版上实测，环境 OLLAMA_NUM_PARALLEL=1、OLLAMA_FLASH_ATTENTION=1、OLLAMA_KV_CACHE_TYPE=q8_0。完整报告见 docs/qwen-perf-comparison/。

MTP 开/关同权重对照（同一份 21 GB 权重，仅 draft_num_predict 不同，10 跑截尾平均，262k 上下文）：

指标	:normal（MTP 关）	:mtp（draft=4）	变化
decode (tok/s)	19.21	27.72	+44.3%
prefill (tok/s)	1360.5	800.7	−41.2%

MTP 以 prefill 换 decode。生成长输出（decode 主导）时值得；纯长上下文问答（prefill 主导）建议用 :normal。

draft_num_predict 单变量复测（同模型仅改 draft，冷对冷）：

draft	decode (tok/s)
8	26.59
4	29.22（+9.9%）

draft_num_predict 并非越大越快——本 MoE 模型甜点约 4（draft=8 已过甜点，草稿上下文开销超过多接受的 token 收益）。

长上下文吞吐——本批 4 个模型（qwen35-claude-distill:9b-q8_0 Q8_0 dense 9.2B、qwen35-claude-distill:latest F16 dense 9.2B、qwen3.6:35b-a3b-mtp-q8_0 Q8_0 MoE A3B、本模型 Q4_K_M MoE A3B+Mamba），仅本模型全程三轮成功；R2/R3 测试时 num_ctx 参数扩大至 1,010,000——696k/977k 是该窗口内的实际填充长度：

档位	prefill (tok/s)	decode (tok/s)	显存峰值
R1 · 238k	1200.7	21.0	41,950 MB
R2 · 696k	504.2	9.1	45,800 MB
R3 · 977k	361.9	6.4	48,130 MB

Mamba/SSM 层使 KV 近恒定（238k→977k KV 仅 +6 GB），这是 977k 能在 48 GB 内跑通的关键；dense 模型在 696k+ 无 Flash Attention 时超时/OOM。

显存真相：「1M 上下文」模型的隐形代价是 KV cache 预分配——21 GB 权重在 1M 上下文下实际占用 40.9 GB 显存。48 GB 显卡上几乎吃满。（977k 实测峰值 48,130 MB 含权重 + KV + 计算缓冲；40.9 GB 仅为 KV 预分配。）

MTP prefill 运行时日志截取（实测）

运行 :mtp（512k 上下文，q4_0 KV，Flash Attention）时从 server.log 截取。MTP 默认启用，无需手动传参：

llama-server.exe ... -c 524288 -np 1 --spec-type draft-mtp --spec-draft-n-max 4 --spec-draft-backend-sampling --cache-type-k q4_0 --cache-type-v q4_0 --flash-attn on
spec common_specu: adding speculative implementation 'draft-mtp' (n_max=4)

两个 prefill 场景——增量（热缓存）与全量冷启动：

案例 A —— 增量 prefill，117k 缓存上下文上新 prefill 585 tokens（task 8982）：

slot print_timing: id 0 | task 8982 | prompt eval time = 1987.04 ms / 585 tokens (3.40 ms per token, 294.41 tokens per second)      
slot print_timing: id 0 | task 8982 |        eval time = 6312.91 ms / 332 tokens (19.01 ms per token, 52.59 tokens per second)      
slot print_timing: id 0 | task 8982 | draft acceptance = 0.57108 (233 accepted / 408 generated), mean len = 3.28
srv prompt_save: - saving prompt with length 118892, total state size = 952.653 MiB (draft: 234.479 MiB)

案例 B —— 全量冷启动 prefill，146,631 tokens 从头处理（task 0）；吞吐随上下文增长而衰减：

slot print_timing: id 0 | task 0 | prompt processing, n_tokens = 10240,  progress = 0.07, t = 6.75 s / 1516.37 tok/s
slot print_timing: id 0 | task 0 | prompt processing, n_tokens = 51200,  progress = 0.35, t = 36.82 s / 1390.70 tok/s
slot print_timing: id 0 | task 0 | prompt processing, n_tokens = 146627, progress = 1.00, t = 152.53 s / 961.33 tok/s
slot print_timing: id 0 | task 0 | prompt eval time = 152890.14 ms / 146631 tokens (1.04 ms per token, 959.06 tokens per second)    
slot print_timing: id 0 | task 0 |        eval time = 10719.56 ms / 446 tokens (24.03 ms per token, 41.61 tokens per second)        
slot print_timing: id 0 | task 0 | draft acceptance = 0.43140 (283 accepted / 656 generated), mean len = 2.73

关键观察：

案例	prefill tokens	吞吐	说明
A · 增量（热缓存）	585 新增（117k 已缓存）	294 tok/s	只 prefill 新增 token，上下文已缓存
B · 全量冷启动	146,631（100%）	1516 → 961 tok/s（−37%），平均 959	随 KV cache 增长而衰减

观察点	数据	含义
MTP 默认启用	draft-mtp + n_max=4	无需手动传 draft_num_predict
小 prompt prefill	13 tok → 13.2 tok/s；19 tok → 47 tok/s	MTP draft context prefill 固定开销主导
draft KV 占用	prompt_save: total 952.7 MiB (draft: 234.5 MiB)	draft context KV ≈ 总 state 的 25%（q4_0）
draft acceptance	0.43–0.57；mean len 2.73–3.28	每步平均约 2.7–3.3 个草稿 token
decode 吞吐	41.6–52.6 tok/s	MTP decode 加速生效

两个案例共同印证「MTP 以 prefill 换 decode」：热缓存下的增量 prefill 快（294 tok/s），而全量冷启动 prefill 吞吐随上下文增长而衰减（146k tokens 内从 1516 降至 961 tok/s）。prefill 主导的长上下文问答用 :normal，decode 主导的长输出用 :mtp。

优点

1. 1M 上下文，已认证——YaRN factor 4，64K→1M 全阶梯 ⁷⁰⁄₇₀ needles。适合超长文档、代码库分析、大规模 RAG。
2. MTP 投机解码在 Ollama 上真正可用——通过 draft_num_predict 激活，实测 1.5× decode 加速（36.03 vs 23.98 t/s）；同权重对照 +44% decode。
3. 去审查——HauhauCS Aggressive 主干，权重逐位一致，无对齐顾虑。
4. prefill 快——MoE A3B（3B 激活）+ Q4_K_M，同类中 prefill 最快（238k 下 1200 tok/s）。
5. 长上下文显存可控——Mamba/SSM 层使 KV 近恒定；测试舰队中唯一在 48 GB 上跑通 238k→696k→977k 的模型。
6. 编程 agent 就绪——RENDERER/PARSER qwen3.5、thinking + tools、Qwen3 官方采样值。
7. 纯净 A/B 对照——:mtp vs :normal 同一份权重，按需选 decode 优先或 prefill 优先，无需换模型。
8. 单文件紧凑——21 GB Q4_K_M，相对 Q8/F16 更省显存。

缺点与权衡

1. 1M 上下文吃显存——KV 预分配使 21 GB 权重实际占用 40.9 GB；48 GB 卡几乎吃满，难与其他模型并行。
2. MTP 以 prefill 换 decode——+44% decode 但 −41% prefill。长上下文问答（prefill 主导）开 MTP 反而延长总响应时间，应改用 :normal。
3. draft_num_predict 需调优——非越大越好，本 MoE 甜点约 4。长上下文下草稿上下文使 compute buffer 翻倍（≤48 GB 在 ~512k 有 OOM 风险）。
4. MoE 在 Turing 上慢——无 MTP 时 decode（19.2 tok/s）慢于 9B dense Q4（26.6）。MoE 优势需新 GPU + MTP 才能兑现。
5. 默认 thinking 模式——不显式 "think": false 时，num_predict 较小会返回空响应（token 全耗在思考段）。应用层需处理 thinking。
6. 视觉未捆绑——mmproj 视觉塔（899 MB）未包含在本 tag 中，需要时需单独挂载。这并非疏漏，而是源于 Ollama 调度器（server/sched.go）的并行安全约束：多模态架构被强制 num_parallel = 1（源码注释 “Some architectures are not safe with num_parallel > 1”，ref ollama#4165）——vision encoder cache 无法在并发请求间安全共享，多模态并发会报 failed processing images。qwen35/qwen35moe 原本也在此黑名单中；本仓库编译版为纯文本用途将其移除（:mtp/:normal 因此才能 num_parallel > 1），但该移除仅在未挂载投影器时安全——一旦挂载 mmproj 并发送图像，即回到不安全区域，图像模式请求应保持 num_parallel = 1。
7. Q4_K_M 量化有损——相对 F16/Q8 有精度损失；基础能力按量化程度折算。
8. 冷加载与长上下文 decode 慢——21 GB 冷加载约 10–16 s；977k 下 decode 降至 6.4 tok/s。

使用

# MTP 开——编程 / 长输出
ollama run lucloner/wen36-35b-uncensored-1m:mtp

# MTP 关——长上下文问答
ollama run lucloner/wen36-35b-uncensored-1m:normal

编程 agent 若未处理 thinking 段，请在 API 请求中显式 "think": false。

显存提示

• :mtp 在 512k：MTP 会创建与主 context 同 n_ctx 的草稿上下文，compute buffer 近似翻倍。≤48 GB 显存在 ~512k 带 MTP 接近触顶；若 OOM，把 draft_num_predict 改 0 禁用 MTP（238k 下实测 prefill +47%，仅损失 decode 投机加速）。
• :normal 在 1.01M：仅 KV 预分配就在 21 GB 权重之上再加约 20 GB。

致谢

• 基座模型：Qwen（Apache-2.0，含官方 MTP 层）
• 去审查与主干量化：HauhauCS
• MTP GGUF 打包：Unsloth
• 1M YaRN 扩展、MTP 移植、认证：SatGeze
• Ollama MTP 激活、Modelfile 优化与基准测试：lucloner

原始模型卡：satgeze/Qwen3.6-35B-Uncensored-HauhauCS-1M-GGUF · 镜像：Hugging Face | ModelScope

许可

Apache-2.0（与 Qwen3.6-35B-A3B 基座一致）。