Qwen3.6-27B-Claude-Opus-Sonnet-DistilledV2-MTP-GGUF

Qwen3.6-27B-Claude-Opus-Sonnet-DistilledV2-MTP-GGUF

这是本地蒸馏模型 Qwen3.6-27B-Claude-Opus-Sonnet-DistilledV2-MTP 的 GGUF 量化发布版本，重点是：

保留了 Claude Opus / Sonnet 蒸馏后的回答风格与组织方式

保留了 Qwen3.5/3.6 的 MTP 相关张量和 metadata

已在支持 MTP 的 llama.cpp 上验证可用

已验证 --spec-type draft-mtp 可以直接正常打开

提供 Q2 K / Q4 K M / Q6 K / Q8 0 四个量化档位

• 这份 GGUF 的特别之处

这不是“普通 GGUF 自动支持 MTP”，而是：

• HF 源模型本身带有 mtp.* 权重
• 使用支持 Qwen3.5/3.6 MTP 导出的新版 llama.cpp 转换链路导出 BF16 GGUF
• BF16 GGUF 中已包含正确的 MTP metadata
• 再基于 BF16 GGUF 继续量化出 Q2 K / Q4 K M / Q6 K / Q8 0

核心验证点：

qwen35.block count = 65

qwen35.nextn predict layers = 1

• 文件列表

文件 大小 说明

• -- ---: ---

Qwen3.6-27B-Claude-Opus-Sonnet-DistilledV2-MTP-Q2 K.gguf 10.12 GB 最激进压缩，速度最好，质量损失最大

Qwen3.6-27B-Claude-Opus-Sonnet-DistilledV2-MTP-Q4 K M.gguf 15.66 GB 最均衡，推荐默认下载

Qwen3.6-27B-Claude-Opus-Sonnet-DistilledV2-MTP-Q6 K.gguf 20.89 GB 更偏质量，速度仍可接受

Qwen3.6-27B-Claude-Opus-Sonnet-DistilledV2-MTP-Q8 0.gguf 27.05 GB 接近高精度，带宽压力更大

• 兼容性

已验证：

Windows CUDA 版 llama.cpp

GPU: NVIDIA RTX PRO 6000 Blackwell Workstation Edition 96 GB

llama-cli

• -spec-type draft-mtp
• -spec-draft-n-max 2
• ngl 999

注意：需要使用包含 Qwen3.5/3.6 MTP 支持的新版 llama.cpp 。旧版转换器导出的 GGUF 会缺失关键 metadata，导致 failed to create MTP context 。

• 推荐档位

Q4 K M : 默认推荐，速度/质量最均衡

Q6 K : 更看重质量时推荐

Q2 K : 显存或磁盘最紧张时使用

Q8 0 : 追求更高保真时使用，但未必更快

• GPU + MTP2 实测

测试环境：

GPU: RTX PRO 6000 Blackwell 96 GB

后端: CUDA

参数: -ngl 999 --spec-type draft-mtp --spec-draft-n-max 2 --spec-draft-ngl 999

逻辑题：三人真假话推理题， n=160

• 2 是短上下文 benchmark
• 3 是长上下文 benchmark

• 1 历史参考

量化 Prompt Generation Draft acceptance

• -- ---: ---: ---:

Q4 K M + non-MTP 796.22 tok/s 69.98 tok/s -

Q4 K M + MTP2 240.55 tok/s 114.78 tok/s 80.33%

Q4 K M + MTP3 390.77 tok/s 117.16 tok/s 69.48%

• 2 本次量化对比

量化 Prompt Generation Draft acceptance 备注

• -- ---: ---: ---: ---

Q2 K + MTP2 439.73 tok/s 118.01 tok/s 68.66% 速度最快，但压缩最激进

Q4 K M + MTP2 240.55 tok/s 114.78 tok/s 80.33% 默认推荐

Q6 K + MTP2 503.87 tok/s 99.85 tok/s 78.86% 更偏质量

Q8 0 + MTP2 421.04 tok/s 78.86 tok/s 69.17% 体积最大，速度受带宽影响

• 3 长上下文补?

长上下文补充测试同样使用 GPU + MTP2 ，但 prompt 改成了长文档检索任务：

ctx8k 档实际 prompt 长度约 6616 tokens

ctx32k 档实际 prompt 长度约 26738 tokens

为了减少回答内容差异的影响，generation 设为短回复，模型通常在 17-23 tokens 内提前遇到 EOS

下表数据以原始 llama.cpp timing log 为准

档位 量化 Prompt tokens Prompt tok/s Generation tokens Generation tok/s Draft acceptance

• -- --- ---: ---: ---: ---: ---:

ctx8k Q2 K 6616 1304.11 16 104.41 83.33%

ctx8k Q4 K M 6616 2798.63 21 31.73 60.00%

ctx8k Q6 K 6616 2415.74 21 69.48 60.00%

ctx8k Q8 0 6616 2143.06 21 63.78 60.00%

ctx32k Q2 K 26738 2450.46 17 71.41 78.57%

ctx32k Q4 K M 26738 2846.65 23 87.42 83.33%

ctx32k Q6 K 26738 2620.59 17 81.02 71.43%

ctx32k Q8 0 26738 3120.27 17 71.19 71.43%

长上下文观察：

这组长上下文里， Q4 K M 仍然是最均衡档位

Q6 K 在 ctx32k 下 generation 仍保持在 81 tok/s ，更适合质量优先场景

Q8 0 在 ctx32k 下 prompt 吞吐不差，但 generation 仍未明显拉开和 Q6 K 的差距

Q2 K 在长上下文下仍然可用，但更适合极限压缩，不建议作为默认发布档位

结论：

在这台 Blackwell 工作站卡上， Q4 K M 是最均衡档位

Q2 K 的 generation 速度最高，但接受率和保真度更激进

Q6 K 的接受率表现更稳，适合作为更高质量档

Q8 0 不一定更快，说明该场景下已明显受显存带宽约束

• 4 与本地原版 qwen3.6-27b 的效率对比

为了更直观体现这个发布版的卖点，又补了一组和本地 1234 端口原版 qwen3.6-27b 的同机对比。这个对比不强调学术 benchmark，而是回答一个更实际的问题：作为可直接发布和本地部署的 GGUF 版本，它能不能在保持正确性的同时，把响应效率做得更好。

对比对象： http://127.0.0.1:1234/v1/chat/completions 上的 qwen3.6-27b

发布版代表档： Q4 K M + MTP2

对比题目： 4 道偏客观题，包含逻辑题、 sqrt(2) 证明、文学常识和长上下文检索

口径说明：下图中 GGUF 端延迟包含 llama-cli 冷启动，因此这个结论对本发布版是偏保守的

关键数字：

平均总耗时：发布版 10.09s ，原版 10.93s

正确性：发布版 4/4 ，原版 3/4

原版思考推理链条过长： 4 题累计输出了 9002 个 reasoning content 字符

发布版实测速率：平均 prompt 1035.1 tok/s ，平均 generation 118.1 tok/s

观察：

在这组题里，发布版平均总耗时更低，而且这个结果还是在把 GGUF 冷启动算进去的情况下得到的

原版的问题不是不会答，而是思考推理链条太长，单位 token 输出效率不高

原版在 sqrt(2) 证明题上把更多预算消耗在隐藏推理里，在设定输出上限内没有稳定给出完整最终答案

发布版采用更直接的回答路径，因此更符合“本地高效率部署”的核心卖点

除了效率，这个发布版还能在 llama.cpp 里直接正常打开 MTP ，这本身也是一个重要卖点

如果后续改成常驻服务方式部署，而不是每题重新启动一次 llama-cli ，发布版延迟通常还会进一步下降

结论：

在这台机器上，发布版并不是单纯依靠“牺牲正确性”换速度

它在这组对比题里同时拿到了更好的正确性和更好的平均响应效率

相比原版更长的思考推理链条，这个发布版的单位 token 输出效率更高

对于 Hugging Face 页面展示来说，这一组对比可以直接用来突出“可开 MTP、高效率、本地可部署、正确性不回退”这四个卖点

• 质量验证

已做两类验证：

• 可加载性验证
• Q2 K / Q4 K M / Q6 K / Q8 0 均通过 GGUF 文件头检查
• 四个量化档位均可在 GPU 上用 draft-mtp 正常加载
• 同题逻辑验证
• Q2 K / Q4 K M / Q6 K / Q8 0 都能沿同一道真假话逻辑题给出一致推理方向
• 结果稳定指向：
• A 在说谎
• B 说真话
• C 在说谎

质量接受度判断：

量化 质量结论 建议

• -- --- ---

Q2 K 可用，但压缩最激进，质量损失最明显 只建议极限压缩场景

Q4 K M 质量与速度最均衡 默认推荐上传后主推

Q6 K 质量更稳，适合更看重保真的场景 推荐作为高质量档

Q8 0 质量没有问题，但速度未必优于 Q6 K 推荐给高保真实验用户

补充说明：

在当前 PowerShell + CLI 环境里，直接把中文 prompt 作为命令行参数传入，偶发会出现编码噪声

因此本仓库的“质量对照”主要采用英文逻辑题做统一基准

实际中文使用建议通过 UTF-8 文件输入、API 调用或你自己的推理服务侧验证

• llama.cpp 用法

• 1 普通推理

• 2 开启 MTP

• 3 推荐参数

短回复：

长推理：

MTP3 在部分长输出场景也能继续提速，但接受率会下降，推荐你先从 MTP2 开始。

• 已知限制

需要新版 llama.cpp

旧版转换器导出的 BF16/Q4 会缺失 Qwen3.5/3.6 的关键 MTP metadata

某些 Windows 命令行环境下直接传中文 prompt 可能出现编码问题

Q8 0 不保证比 Q6 K 更快，尤其在带宽受限显卡上

• 推荐结论

如果你只想下载一个文件：

首选 Q4 K M

如果你更看重质量：

选 Q6 K

如果你更看重极限压缩：

选 Q2 K

如果你做高保真实验：

选 Q8 0