mudler/Qwen3.6-35B-A3B-Claude-4.7-Opus-Reasoning-Distilled-APEX-MTP-GGUF 刚刚发布！

模块描述：我以独立研究的形式托管了 **30 多个免费的 APEX MoE 量化**。我唯一的本地硬件是 **NVIDIA DGX Spark**（122 GB 统一内存）——足以处理约 30-50B 级别的 MoE，但 **更大的模型（200B+）需要在 H100/H200/Blackwell 上租用算力**，每次量化通常花费 20-100 美元。如果 APEX 量化对你有用，你的支持将直接为这些更大的运行提供资金。 [](https://huggingface.co/mudler/Qwen3.6-35B-A3B-Claude-4.7-Opus-Reasoning-Distilled-APEX-MTP-GGUF#qwen36-35b-a3b-claude-47-opus-reasoning-distilled--apex-mtp-gguf)Qwen3.6-35B-A3B-Claude-4.7-Opus-Reasoning-Distilled — APEX-MTP GGUF **APEX（Adaptive Precision for EXpert Models）** 对 [lordx64/Qwen3.6-35B-A3B-Claude-4.7-Opus-Reasoning-Distilled](https://huggingface.co/lordx64/Qwen3.6-35B-A3B-Claude-4.7-Opus-Reasoning-Distilled) 的量化，**捆绑了 MTP（多 token 预测）头**，实现即开即用的自推测解码。 [](https://huggingface.co/mudler/Qwen3.6-35B-A3B-Claude-4.7-Opus-Reasoning-Distilled-APEX-MTP-GGUF#whats-different-from-the-plain-apex-repo)与普通 APEX 仓库有何不同？这些 GGUF 文件将模型的 **MTP（多 token 预测）头** 与主干捆绑在单个文件中，这要归功于 [llama.cpp PR #22673](https://github.com/ggml-org/llama.cpp/pull/22673)。使用最新的 llama.cpp（>= 提交 255582687），你可以仅凭这一个文件启用自推测解码——无需单独的草稿模型：llama-server -m Qwen3.6-35B-A3B-Claude-4.7-Opus-Reasoning-Distilled-APEX-MTP-I-Balanced.gguf --draft-mtp 非 MTP 版本仍可在 [mudler/Qwen3.6-35B-A3B-Claude-4.7-Opus-Reasoning-Distilled-APEX-GGUF](https://huggingface.co/mudler/Qwen3.6-35B-A3B-Claude-4.7-Opus-Reasoning-Distilled-APEX-GGUF) 获取——体积稍小，但没有自推测功能。 # [](https://huggingface.co/mudler/Qwen3.6-35B-A3B-Claude-4.7-Opus-Reasoning-Distilled-APEX-MTP-GGUF#file-sizes)文件大小 每个量化版本比对应的非 MTP 版本大约大 2.5%（多出一个 transformer 块的权重，由于 MTP 共享主干的 embed_tokens，因此不会重复嵌入）。 # [](https://huggingface.co/mudler/Qwen3.6-35B-A3B-Claude-4.7-Opus-Reasoning-Distilled-APEX-MTP-GGUF#mtp-draft-head-precision)MTP 草稿头精度 捆绑的 MTP 头（包括 `blk.40.*` 以及 `nextn.*` 投影 + 归一化层）在 **除 I-Nano 之外的所有层级** 上量化为 **Q8_0**（近乎无损）。I-Nano 在 MTP 块上保持主干层级的精度（Q3_K 路由专家、Q4_K 注意力），但将 `blk.40.nextn.eh_proj` 固定为 Q4_K——请参阅 [下面的说明](https://huggingface.co/mudler/Qwen3.6-35B-A3B-Claude-4.7-Opus-Reasoning-Distilled-APEX-MTP-GGUF#why-the-mtp-head-doesnt-use-imatrix)。这保持了草稿精度（对推测解码接受率很重要），与主干层级精度相比，每个文件仅增加约 1 GB 的成本。 # [](https://huggingface.co/mudler/Qwen3.6-35B-A3B-Claude-4.7-Opus-Reasoning-Distilled-APEX-MTP-GGUF#why-the-mtp-head-doesnt-use-imatrix)为什么 MTP 头不使用 imatrix `llama-imatrix` 运行普通的前向传播，只激活主干（`blk.0..blk.39`）。MTP 头仅在 `--draft-mtp` 推测解码期间触发，因此其张量不会获得 imatrix 激活数据。我们通过使用不需要 imatrix 的静态 K-quant / Q8_0 量化 MTP 头来解决这个问题。（一个针对 `llama-imatrix` 的补丁正在开发中，该补丁在收集期间记录 MTP 激活，位于 [mudler/llama.cpp#mtp-imatrix](https://github.com/mudler/llama.cpp/tree/mtp-imatrix)——一旦上游合并，我们将能够干净地将草稿器推到更低位宽。） # [](https://huggingface.co/mudler/Qwen3.6-35B-A3B-Claude-4.7-Opus-Reasoning-Distilled-APEX-MTP-GGUF#what-is-apex)什么是 APEX？ APEX 是一种感知 MoE 的混合精度量化策略。按张量角色梯度：路由专家压缩最狠，共享专家保持高精度（始终激活），注意力/Mamba 均匀；在 40 个主干层上采用 5+5 对称边缘梯度，MTP 层 40 使用边缘精度。I 变体使用多样化的 imatrix 校准（聊天、代码、推理、工具调用、代理追踪、维基百科）。 [](https://huggingface.co/mudler/Qwen3.6-35B-A3B-Claude-4.7-Opus-Reasoning-Distilled-APEX-MTP-GGUF#architecture)**架构** * **基础**：Qwen 3.6 35B-A3B 系列（Qwen3\_5MoeForCausalLM） * **层数**：40 主干 + 1 MTP（捆绑） * **专家**：256 路由 + 1 共享（每个 token 激活 8 个） * **隐藏层大小**：2048 * **校准**：v1.3 多样化数据集 # [](https://huggingface.co/mudler/Qwen3.6-35B-A3B-Claude-4.7-Opus-Reasoning-Distilled-APEX-MTP-GGUF#credits)