下载量
0
参数
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 分层量化
按张量角色差异化精度，平衡路由专家体积与输出质量
硬件怎么准备
- I-Mini 14.4 GB：适合 16 GB 显存单卡或 32 GB 内存的入门配置
- Compact 17.4 GB：24 GB 消费级显卡可尝试全 GPU 加载
- Quality 23.7 GB / Balanced（metadata 估算 25–31 GB 内存或 22–26 GB 显存）建议 32 GB+ 显存或 64 GB+ 内存
- mmproj 0.9 GB：体积小，与文本 GGUF 合并加载即可
量化版本怎么选
- 入门和低显存场景选 I-Mini（带 imatrix 标定，体积最小）
- 兼顾体积与质量选 Compact 或 Balanced
- 追求最高输出质量选 Quality（MTP 头固定 Q8_0 保住草稿质量）
- Quality/Balanced/Compact 同时提供无 imatrix 与带 imatrix 两个版本可选
GGUF VARIANTS
量化版本与硬件要求
数值根据文件体积和运行余量估算，不是速度或效果承诺；长上下文、并发与 GPU 层数会改变实际占用。
| 量化 | 文件 | 最低显存 | 推荐显存 | 推荐内存 | 来源 |
|---|---|---|---|---|---|
| GGUF | 20 GB | 22.5 GB | 26 GB | 31 GB | 文件 ↗ |
HARDWARE MATCH
哪些显卡或设备更适合运行？
按当前最小量化文件估算，至少需要 22.5GB 显存；如果希望为运行框架和上下文保留余量，优先参考推荐显存 26GB。
阅读 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