← 返回模型库

peculiar-ragdoll/Nail-Qwen3.6-35B-A3B-GGUF

Nail-Qwen3.6-35B-A3B-GGUF:高速MoE对话与视觉编程

Nail 是基于 Qwen3.6-35B-A3B 重新调参的 35B 参数 MoE 量化模型,专为追求极速响应的多轮对话、推理与自主软件工程场景设计。它内置精简系统提示以抑制过度思考,并通过 llama.cpp 与 ollama 等运行时支持文本与视觉任务。

长上下文对话代理编程多模态视觉MoE 量化
查看模型源页面
下载量
0
参数
35B
上下文
未说明
架构 / 任务
未分类
许可证
apache-2.0

MODEL POSITIONING

这个模型解决什么问题?

本仓库是 Unsloth UD 量化版的 GGUF 重新分发,并未自行重新量化,量化质量由 Unsloth 保证,仓库作者仅修改了一条元数据字符串。模型本体 Qwen3.6-35B-A3B 来自阿里 Qwen 团队,35B 总参数下激活约 3.4B,融合高效思考、token 节流与代理编程三大特性,并支持原生的 262k 上下文与图像理解。系统提示内嵌于 chat 模板中,用户自带的系统提示仍会被保留并拼接在最前。量化仓库运行依赖 llama.cpp、ollama 与 LM Studio 等 GGUF 兼容运行时;Apple Silicon 用户建议改用 MLX 构建版本以获得更好的实测表现。模型卡未说明本 GGUF 在常见桌面硬件上的实测速度与显存占用,本档案不承诺推理速度。

更适合谁

  • 希望本地运行长上下文多轮对话与代理编程的中高阶用户
  • 需要同时使用文本与图像理解的多模态应用开发者
  • 在 16 至 32 GB 显存之间寻找高吞吐替代品的重度本地玩家
  • 偏好 GGUF 与 Unsloth 量化生态的 llama.cpp 用户

典型使用场景

  • 单机本地代理式软件工程与代码修复
  • 长文档总结与跨章节多轮研究助手
  • 图像内容理解配合文本推理的多模态工作流
  • 在受限硬件上替代 27B 稠密模型的高吞吐场景

SOURCE-BASED CAPABILITIES

模型卡透露的核心特点

极速响应

在 27B 同类模型对比中速度领先,思考更克制

多轮代理编程

在 Claw-Eval 等多轮代理任务中表现稳定

长上下文原生支持

262k 原生上下文窗口,长任务不丢线索

原生视觉能力

通过 mmproj-F16 同时处理图像与文本

MoE 性价比

35B 总参数仅激活 3.4B,KV 占用低,硬件门槛友好

硬件怎么准备

  • 16 GB 显存或等效统一内存可选 IQ3_S 量化
  • 24 GB 显存建议使用 Q4_K_XL,是仓库主推起点
  • 32 GB 统一内存 Mac 可尝试 Q5_K_XL 并跑满长上下文
  • 40 GB 以上显存可选择 Q6_K_XL 获得最高位宽

量化版本怎么选

  • Q4_K_XL 为仓库推荐起点,速度与质量平衡最佳
  • 显存紧张时退回 IQ3_S,但需接受最低位宽带来的质量损失
  • Q5_K_XL 与 Q6_K_XL 解码速度大致随文件体积下降
  • 视觉功能需额外下载 mmproj-F16.gguf 配合 llama-mtmd-cli

GGUF VARIANTS

量化版本与硬件要求

数值根据文件体积和运行余量估算,不是速度或效果承诺;长上下文、并发与 GPU 层数会改变实际占用。

量化文件最低显存推荐显存推荐内存来源
IQ312 GB13.5 GB15.5 GB18.5 GB文件 ↗
Q416 GB18 GB20.5 GB24.5 GB文件 ↗
Q520 GB22.5 GB26 GB31 GB文件 ↗
F1620 GB22.5 GB26 GB31 GB文件 ↗
Q624 GB26.5 GB30.5 GB37 GB文件 ↗

HARDWARE MATCH

哪些显卡或设备更适合运行?

按当前最小量化文件估算,至少需要 13.5GB 显存;如果希望为运行框架和上下文保留余量,优先参考推荐显存 15.5GB。

阅读 24GB 显存选型指南 →

可以怎样运行

  • llama.cpp 通过 :UD-Q4_K_XL 等 hf 标签直接拉取运行
  • ollama 兼容 GGUF,:quant 标签同样适用
  • LM Studio 支持本地加载 Q4 以上量化文件
  • 视觉任务改用 llama-mtmd-cli 而非普通 llama-cli

采用前要知道的限制

  • 公布基准均来自 MLX 构建版本而非本 GGUF 实测
  • 系统提示固定在 chat 模板,无法通过 API 关闭
  • 视觉功能依赖单独的 mmproj-F16 与 mtmd 前端
  • 仓库作者未做重新量化,量化质量完全归 Unsloth