近30天源站下载量
44.1万
参数
35B
上下文
未说明
架构 / 任务
未分类
许可证
apache-2.0
MODEL POSITIONING
这个模型解决什么问题？
基础模型 ornith-ai/Ornith-1.5-35B-A3B（README 注明为 36B 参数）为 256 路由专家+共享专家、每 token 激活 8 个专家、40 层混合注意力（每 4 层含 3 层线性注意力）的视觉语言 MoE。本仓库仅托管其 APEX GGUF 量化包与 mmproj 视觉投影器，未提供原权重。量化层由作者 mudler 的 APEX 项目交付，针对路由专家占权重 89.6%、注意力仅 3.6% 的结构做分层精度：首尾层与共享专家保高精度，中间层压缩更狠；MTP 头在 Quality/Balanced/Compact 上固定 Q8_0 以保证草稿质量。运行端支持 llama.
更适合谁
- 本地有 16 GB 显存消费级显卡的入门尝试者
- 想在单卡运行 35B 级 MoE 视觉语言模型的用户
- 想用 llama.cpp 自推测解码加速推理的进阶用户
- 关注长上下文与多模态推理的研究者
典型使用场景
- 本地多模态对话与图生文推理
- 长文档摘要、上下文分析
- 代码、工具调用与 agentic 任务推理
- 研究 MoE 量化策略与推测解码加速
SOURCE-BASED CAPABILITIES
模型卡透露的核心特点
MoE 高效激活
35B 总参数下每 token 仅激活约 8 个专家+共享专家，单位算力开销相对有限
混合注意力结构
40 层中每 4 层插入 3 层线性注意力，缓解长上下文显存压力
视觉多模态能力
自带 vision tower，配 mmproj.gguf 可处理图像输入
内置 MTP 草稿头
NextN 草稿头打包为 blk.40，可与目标文件自身做推测解码
APEX 分层量化
按张量角色差异化精度，平衡路由专家体积与输出质量
按当前权重估算的硬件准备
- 现有 GGUF 文件中，最低显存估算约 14.5 GB
- 为上下文缓存、系统进程和并发请求预留额外内存，不要只按模型文件大小配置设备。
量化版本怎么选
- 入门和低显存场景选 I-Mini（带 imatrix 标定，体积最小）
- 兼顾体积与质量选 Compact 或 Balanced
- 追求最高输出质量选 Quality（MTP 头固定 Q8_0 保住草稿质量）
- Quality/Balanced/Compact 同时提供无 imatrix 与带 imatrix 两个版本可选
GGUF VARIANTS
量化版本与硬件要求
显存与内存数值均按权重文件体积估算，未做设备实测。多模态还需要配套投影文件并额外占用内存；分卷容量按全部分卷合计，下载时需获取完整文件组。
HARDWARE MATCH
哪些显卡或设备更适合运行？
按当前最小量化文件估算，至少需要 14.5GB 显存；如果希望为运行框架和上下文保留余量，优先参考推荐显存 17GB。
阅读 24GB 显存选型指南 →可以怎样运行
- llama.cpp：需近期支持 qwen3_5_moe 的构建，并启用 --spec-type draft-mtp
- Ollama：可加载 Balanced/Compact/I-Mini 等变体
- LM Studio：支持加载本地 GGUF
- 视觉能力：需把 mmproj.gguf 与文本 GGUF 放在同一目录
采用前要知道的限制
- 模型卡未公布任何吞吐量与质量基准，速度与得分无官方承诺
- 必须使用支持 qwen3_5_moe 架构的近期 llama.cpp，否则无法加载
- 推测解码的加速收益取决于上下文与实现，模型卡未量化
- 作者自述本地硬件仅一台 NVIDIA DGX Spark，更大尺寸量化依赖租用 H100/H200/Blackwell