下载量
0
参数
35B
上下文
未说明
架构 / 任务
未分类
许可证
mit
MODEL POSITIONING
这个模型解决什么问题？
该仓库本身只是 Ornith-1.5-35B-A3B 的量化分发，不是新模型：能力、风格与偏科都继承自基座，差异在于使用了独立的 imatrix 与 Sharp 聊天模板，并保留训练后的 MTP 头供 llama.cpp 的 draft-mtp 推测解码使用。仓库提供 llama.cpp、Ollama、LM Studio 友好的 GGUF 文件，视觉能力来自与各档位共用、未经修改的 mmproj-BF16.gguf 投影器。MTP 头默认关闭，需在启动参数中显式打开才生效；具体速度收益与硬件强相关，模型卡未给出统一承诺。
更适合谁
- 想要本地跑代理式代码修复与多轮编码协作的开发者
- 有 24 GB 至 48 GB 显存或充足统一内存、追求长上下文编码工作流的用户
- 偏好 MIT 协议、可接受中英双语限制的本地模型使用者
- 愿意自行调节推测解码参数以榨取速度的玩家
典型使用场景
- 通过工具调用与代码执行修复真实代码库问题的代理编程
- 跨多轮对话的长程编码协作与会话式调试
- 在本地完成的代码补全、解释、重构与评审
- 配合视觉投影器进行带图像理解的代码或文档问答
SOURCE-BASED CAPABILITIES
模型卡透露的核心特点
代理式代码修复能力
在 SWE-bench-Live 25 题中修复 12 题，与 Opus 4.6 medium 持平
多轮对话表现
在 Claw-Eval 多轮任务上得分 67.2，回答质量高于基座
紧凑的 MoE 显存占用
35B 总量但仅路由 8/256 专家，KV 占用小适合长上下文
MTP 推测解码支持
训练后的多 token 预测头可在 llama.cpp 启用以加速生成
视觉理解能力
复用基座 mmproj，支持图文输入
硬件怎么准备
- 16 GB 显存或内存：仅适合 Q2_K_XL 或 IQ3_XXS，作者明确标注前者为最后手段
- 24 GB 设备：建议从 IQ4_XS 或 Q4_K_XL 起步，兼顾质量与长上下文余量
- 32 GB 显存或统一内存：可舒适运行 Q5_K_XL 并保留大上下文
- 48 GB 及以上：可加载 Q6_K_XL 近乎无损或 Q8_K_XL 参考档位
量化版本怎么选
- 兜底档位 Q2_K_XL：作者标注为最后手段，2 位会显著损失能力
- 16 GB 首选 IQ3_XXS：在几乎同体积下明显优于 Q2_K_XL
- 24 GB 起步推荐 UD-Q4_K_XL：作者标注为基准测试档位
- 32 GB 推荐 UD-Q5_K_XL：质量与体积平衡的常用档位
GGUF VARIANTS
量化版本与硬件要求
数值根据文件体积和运行余量估算，不是速度或效果承诺；长上下文、并发与 GPU 层数会改变实际占用。
HARDWARE MATCH
哪些显卡或设备更适合运行？
按当前最小量化文件估算，至少需要 9GB 显存；如果希望为运行框架和上下文保留余量，优先参考推荐显存 10.5GB。
阅读 12GB 显存选型指南 →可以怎样运行
- llama.cpp 通过 llama-server 或本地加载运行，可启用 --spec-type draft-mtp 打开推测解码
- Ollama 与 LM Studio 可直接消费仓库内的 GGUF 文件
- MTP 头默认不工作，未开启推测解码时仅占用约 0.4 GB 死重
- 视觉输入需额外加载 mmproj-BF16.gguf 投影器
采用前要知道的限制
- 考试与知识问答为明显短板，MMLU-Pro 比同档 Nail 低约 10 分
- 澄清提问少于基座，对模糊请求会直接作答而非追问
- 仅支持中文与英文，能力继承自基座
- MTP 推测解码的实际收益因硬件而异，需自行调参验证