近30天源站下载量
88.9万
参数
未知
上下文
未说明
架构 / 任务
image-text-to-text
许可证
apache-2.0
MODEL POSITIONING
这个模型解决什么问题？
基础模型规模为 176.9B，采用 512 专家 MoE、每层每 token 激活 10 个专家；本版本通过 GSQ 与 RCO 删除 50% 专家，保留权重使用 3.5 bpw，并针对代码、代理工具调用、视觉和空间推理进行校准。仓库是面向能力定向压缩的 GGUF 量化发布，不是未剪枝基础模型；模型卡称总计 58.4 GB，其中约 29.6 GB 转换器权重需常驻内存。运行时可使用 llama.cpp、Ollama、LM Studio，模型卡还提及第三方 Strata。基础模型、量化变体和运行工具应分开判断，下载前还需核对仓库实际分片。
更适合谁
- 需要代码生成、仓库级修改与代理工具调用的开发者
- 希望保留图像理解和空间推理能力的用户
- 配备高内存工作站或服务器、能够加载约 58.4 GB GGUF 的用户
- 接受专家剪枝带来部分通用能力损失的研究者
典型使用场景
- 代码生成、调试与代码库级任务
- 代理式工具调用和多步骤软件工程任务
- 图片问答、视觉描述与 SVG 等图文联合生成
- 研究低比特量化、专家剪枝和 MoE 本地部署
SOURCE-BASED CAPABILITIES
模型卡透露的核心特点
代码能力定向
围绕代码、代理轨迹与视觉任务选择保留专家，并以模型卡中的代码评测说明能力保留情况
专家剪枝
从每层 512 个专家中保留 256 个，直接减少模型参数与常驻内存需求
低比特量化
保留权重按 3.5 bpw 存储，模型卡将综合效果折算为原始 Transformer 的 1.89 bpw
多模态保留
校准集合加入视觉样本，用于保留对象识别、空间组合和图像到文本能力
按当前权重估算的硬件准备
- 现有 GGUF 文件中，最低显存估算约 59 GB
- 为上下文缓存、系统进程和并发请求预留额外内存，不要只按模型文件大小配置设备。
量化版本怎么选
- 当前来源只列出 IQ1_M，没有提供其他量化等级可作横向选择
- 该文件属于 GSQ-RCO 专家剪枝版本，不应按普通单一量化 GGUF 理解
- 模型卡要求两个分片配合使用，向 llama.cpp 加载时提供第一分片
- 1.89 bpw 是计入专家删除后的综合等效值，并非单个权重实际只存 1.89 bit
GGUF VARIANTS
量化版本与硬件要求
显存与内存数值均按权重文件体积估算，未做设备实测。多模态还需要配套投影文件并额外占用内存；分卷容量按全部分卷合计，下载时需获取完整文件组。
| 量化 | 权重合计 | 估算加载显存 | 建议显存 | 建议内存 | 来源 |
|---|---|---|---|---|---|
| IQ1_M需全部分卷 | 54 GB | 59 GB | 67.5 GB | 82 GB | 查看文件组 ↗ |
HARDWARE MATCH
哪些显卡或设备更适合运行？
按当前最小量化文件估算，至少需要 59GB 显存；如果希望为运行框架和上下文保留余量，优先参考推荐显存 67.5GB。
阅读 24GB 显存选型指南 →可以怎样运行
- 使用 llama.cpp 加载两个 GGUF 分片
- 可通过 Ollama 部署，来源标记为兼容
- 可通过 LM Studio 使用，来源标记为兼容
- 可尝试模型卡提及的第三方 Strata，但实际兼容性与表现需自行核验
采用前要知道的限制
- 实验性发布，模型卡建议反馈未被校准数据覆盖的能力表现
- 专家剪枝必然带来能力损失，目标领域之外的退化被明确接受
- 长程、多步骤代理任务更容易累积误差，代码评测也未显示所有指标完全无损
- GGUF 变体元数据与模型卡的文件大小、分片描述存在不一致