近30天源站下载量
83.2万
参数
12B
上下文
未说明
架构 / 任务
image-text-to-text
许可证
gemma
MODEL POSITIONING
这个模型解决什么问题？
模型能力来自去审查调优后的 Gemma4 12B 指令底座，Balanced 变体强调先推理再回答，在代理式编码、复杂推理、创意写作与角色对话下保持可靠。仓库仅提供面向 4 比特的 Q4_K_M 文本权重、BF16 的视觉 mmproj，以及来自 Unsloth 团队的 MTP 投机解码草稿头，可通过 llama.cpp 等支持 speculative decoding 的后端提速，运行工具覆盖 llama.cpp、LM Studio、Jan、koboldcpp 等 GGUF 生态。作者明确提示 LM Studio 的 tensor-split 多卡模式在该模型上会崩溃，建议改用单卡切分。模型卡未说明具体的上下文窗口实测或训练语料分布。
更适合谁
- 希望在本地获得无明显拒答偏置的中文或英文用户
- 需要 256K 长上下文处理大型文档或代码库的开发者
- 偏好 Gemma4 生态并希望利用 MTP 提速的爱好者
- 专注代理式编程、推理与长篇创意写作的实践者
典型使用场景
- 本地代理式编程与代码调试
- 长篇创意写作、角色扮演与剧情推演
- 大文档摘要与跨章节问答
- 图片识别配合文字生成的多模态对话
SOURCE-BASED CAPABILITIES
模型卡透露的核心特点
无审查指令遵循
Balanced 调优显著降低主动拒答，边缘案例可经复述化解
Q4_K_M 接近原精度
基于 Gemma4 QAT 权重，4 比特即甜点，高精度收益有限
MTP 投机加速
随仓库附 Unsloth 的多令牌预测草稿头，显著提速长输出
多模态视觉输入
通过 mmproj 投影器支持图片理解与图文问答
256K 超长上下文
12B 稠密架构，单会话可容纳大型资料或代码工程
按当前权重估算的硬件准备
- 现有 GGUF 文件中，最低显存估算约 7.5 GB
- 为上下文缓存、系统进程和并发请求预留额外内存，不要只按模型文件大小配置设备。
量化版本怎么选
- 主模型仅提供 Q4_K_M 文本权重，作者明确其为最优量化
- 视觉 mmproj 为 168MB 的 BF16 单独文件，按需加载
- MTP 草稿头为 GGUF 格式，需后端支持 speculative decoding
- 模型卡未提供更高精度量化或对比实测
GGUF VARIANTS
量化版本与硬件要求
显存与内存数值均按权重文件体积估算，未做设备实测。多模态还需要配套投影文件并额外占用内存；分卷容量按全部分卷合计，下载时需获取完整文件组。
| 量化 | 权重合计 | 估算加载显存 | 建议显存 | 建议内存 | 来源 |
|---|---|---|---|---|---|
| Q4_K_M | 6.9 GB | 7.5 GB | 9 GB | 10.5 GB | 下载文件 ↗ |
HARDWARE MATCH
哪些显卡或设备更适合运行？
按当前最小量化文件估算，至少需要 7.5GB 显存；如果希望为运行框架和上下文保留余量，优先参考推荐显存 9GB。
阅读 12GB 显存选型指南 →可以怎样运行
- llama.cpp 的 llama-server 或 llama-cli 命令行
- LM Studio 单卡 GPU 加载避免多卡拆分
- Ollama、Jan 等兼容 GGUF 的桌面前端
- koboldcpp 与其他 llama.cpp 衍生前端
采用前要知道的限制
- 模型卡未给出上下文长度外的生成速度实测数据
- 仓库仅发布 Q4_K_M 一种文本量化，缺少更高精度对照
- LM Studio 的 tensor-split 多卡模式会导致崩溃
- 少数边缘提示仍会先拒答，需重述或调整提问策略