模型 / Qwen3.6-27B-MTP-pi-tune (bytkim)

Qwen3.6-27B-MTP-pi-tune (bytkim)

面向无思考代理编码的MTP微调版,本地GGUF推理

作者 bytkim

仓库标识bytkim/Qwen3.6-27B-MTP-pi-tune-GGUF

显存未知许可 可商用任务 智能体最近核对 2026-08-23
运行内存
权重格式未知,无法估算显存
运行时
OLLAMA
下载
1,543

Hugging Face 源仓库 ↗

快速上手示例

ollama run hf.co/bytkim/Qwen3.6-27B-MTP-pi-tune-GGUF

依赖版本和硬件参数请以源仓库说明为准。

适合与不适合

入选理由
即用GGUF和Ollama,专为无思考代理编码优化,MTP加速解码,适合本地agent开发。基于Qwen3.6-27B微调,有Terminal-Bench基准。
对位
对位 Qwen2.5-Coder-32B
适合
无思考代理编码循环 / 工具调用与 Shell 自动化
不适合
需要安全对齐的敏感场景

独立证据与社区反馈

13 个独立来源最近验证 2026-08-23

社区普遍认为 Qwen3.6-27B 是当下最值得本地跑的 27B 稠密机型:在 agentic 编程基准上全面超过上代 397B 参数的 MoE 旗舰(9),开启 MTP 后吞吐接近翻倍、实测约 50 TPS(5,7)。口碑集中在『小尺寸、编程与代理能力强』,但社区同时提醒量化档位与显存门槛会明显影响实际体验(1,4)。

  • agentic 编程:27B 稠密架构在各项主要 agentic 编程基准上胜过上代 397B MoE 旗舰,降低『本地卡跑不动复杂编码/代理任务』的门槛(9)
  • 速度:开启 MTP 投机解码后吞吐大幅提升(53/46 TPS vs 无 MTP 的 29/27 TPS),且快过 Mistral 24B,消费级显卡即可受益(5,7,15)
  • 部署:全部装进显存、无溢出,配合 MTP 在中等配置上就有可用速度,对应『要上代旗舰表现又不想堆多卡』的需求(5)
  • 长上下文:原生 262K token 上下文,可用 YaRN 扩展到 100 万以上,适配长代码库/长文档(11,12)
  • 多模态:原生支持文本/图像/视频输入,一张卡兼顾视觉与编码场景(11)
  • 长输出:最大输出 65,536 token,可覆盖整文件生成等长输出需求(12)
  • 工具/结构化输出:BF16 精度下严格结构化输出 100% 命中、重复工具调用成功率 90.7%,满足 agent 场景的稳定性要求(4)
  • 微调红利:社区实测编程向微调/合并构建在编码上略优于原版,是该尺寸下冲编码体验的常见选择(0,2)
  • 低比特不可靠:Q3 档位被反馈『too unreliable』,建议 Q4 起跳(1)
  • 量化敏感:INT4 vs BF16 在重复工具调用(83.7% vs 90.7%)与严格结构化输出(64% vs 100%)上差距明显,求稳需上高精度(4)
  • 资源门槛:dense 27B 吃内存/显存,有用户称『needs more RAM than I have』,16GB 级平台即便开 MTP 也难跑顺(1,3)
  • 吞吐靠调参:需手动配 --spec-type draft-mtp、--spec-draft-n-max 等(乃至叠加 ngram-mod)才能拿到最佳 tok/s(6)
  • 换代压力:与 Qwen3.8-27B 直接对比时后者 10 项真实任务 9 胜 1 负(8.838 vs 6.862),社区已有迁移势头(10)
  • 量化试错成本:不同量化档位体验差异大(如 q4 k xl 有时反而更快更好),逐档下载试错耗时(1)
  • 微调选择分歧:哪个微调最好没有共识,有人推 ff711/Qwopus,有人直接转投 35B-A3B 或 Qwen3.8,选择成本高(0,1,2,10)

可信度已发布多量化GGUF,llama.cpp原生支持MTP,实测draft acceptance ~78%

完整规格

规模
27B · 256k · 权重格式未知,无法估算显存
授权
Apache-2.0 · 可商用
框架
llama.cpp / ollama
工具调用
OpenAI-style function calling
血统
量化自 Qwen3.6-27B
访问提示
Hugging Face 可能需要代理

下载动量

30天下载 329.4k → 322.5k

观测时间线

模型家族

查看全部家族 →