MoziAier 9B-TQ — 6 GB 显卡跑 150K 上下文的轻量三值量化模型
English | 简体中文 | 繁體中文 | 日本語 | 한국어 | हिन्दी | Deutsch | Français | Nederlands | Italiano | Русский | Español | Português | العربية | Bahasa Indonesia | Türkçe | Tiếng Việt | Polski
版本:V1.0 · 权重:1.86 GiB · 发布日期:2026-11-01
📑 概览 · 特性 · 规格 · 快速开始 · 启动 · 参数 · 量化对比 · MTP · 显存 · 部署 · 评测 · 许可证 · 联系 · 致谢
1. 模型概览
MoziAier 9B-TQ 是面向本地私有化部署的 9B 三值量化模型。每个权重压到 {-1, 0, +1},权重只有 1.86 GiB,却保留 150K 默认上下文与视觉能力,可在 6 GB 显存的消费级显卡上完全离线运行。对话模板已内嵌在主权重中,无需另配。
一句话定位:用一张 6 GB 显卡,在本机跑一个长上下文、能看图、输出格式稳定的中文助手。
与同系列的差异:
- 相比 27B / 35B,9B-TQ 追求的不是榜单分数,而是最低硬件门槛 + 最长上下文
- 相比通用 4-bit 量化,三值容器体积更小(1.86 GiB vs 约 5–6 GiB),解码也更快
- 相比两套上游底座,本版增加了 MoziAier 的行为规则与对话模板
适用人群:个人开发者、无外网环境的团队、想在消费级显卡上做长文档分析的用户。
MoziAier 自研特性
| 特性 | 说明 |
|---|---|
| 七维思考体系 | 先判任务复杂度,再动态展开 2 / 5 / 7 维推理,而非套固定模板 |
| Agent LOOP 迭代 | 复杂任务进入「执行 → 评估 → 调整 → 验证」循环,简单任务自动跳过 |
| Agent 长任务优化 | 分阶段推进、每阶段带验收判据;结构化输出便于外部任务系统接管 |
| 工具调用优化 | 输出规范的工具调用格式;关闭思考实测成功率 20/20 |
| 时效性检索 | 时效问题明确要求联网检索,不凭记忆作答(需外接工具) |
| 防止死循环 | Loop 内置退出规则与收敛判据 |
| 体积优势 | 1.86 GiB 权重,6 GB 显卡跑 150K 上下文 |
以上为 MoziAier 原创增量。底座权重来自上游开源模型(见 3),整体以 Apache-2.0 分发,归属见
NOTICE。
2. 核心特性
三值量化容器 —— 权重取值只有 -1 / 0 / +1,以 PTQ1.0 容器封装。每生成一个 token 只需读取极少字节,解码速度不受显存带宽严重限制。
结构化输出 —— 先给判型行,再按复杂度展开七维思考,复杂任务进入 Loop:
| 层级 | 适用场景 | 展开维度 |
|---|---|---|
| 简单问答 | 名词解释、事实查询、翻译、摘要 | 2 维 |
| 分析诊断 | 数据分析、报告解读、方案评估 | 5 维 |
| 复杂任务 | 代码开发、架构设计、多步流程 | 7 维 + Loop |
七维:① 理解任务 ② 复杂度评估 ③ 依赖关系 ④ 风险评估 ⑤ 资源需求 ⑥ 验收标准 ⑦ 执行策略
超长上下文 —— 默认 150K(153,600 tokens),最大 256K(256,000)。可一次读完整本书或中等规模代码库。最低 16K:系统提示渲染后约 8,884 tokens,4K 会报错 request (8884 tokens) exceeds the available context size。
视觉输入 —— 通过 mmproj 投影器(Q8_0,595 MB)支持图片。🔴 必须用 Q8_0 版本,BF16 版本在并发图片请求下会崩溃。
拒绝编造 —— 被问到不存在的历史记录时回答「我这边查不到」,而不是编一个答案。私有化场景下,编造比说不知道危害更大。
3. 技术规格
| 项目 | 规格 |
|---|---|
| 底座 | Qwen3.5-9B(预训练)+ Ternary-Bonsai-2-9B(三值量化基座) |
| 参数量 | 9B(Dense) |
| 量化方式 | 三值(-1 / 0 / +1),PTQ1.0 容器(GGUF type 143) |
| 权重文件 | 1,997,527,168 B(1.86 GiB,HF 页面显示约 2.0 GB) |
| 上下文 | 默认 150K(153,600)/ 最大 256K(256,000) |
| 最低上下文 | 16K(系统提示约 8,884 tokens) |
| 视觉 | mmproj-Q8_0(595 MB) |
| 思考模式 | 默认关闭(推荐,必须) |
| 推理框架 | llama.cpp 三值专用构建(Prism 血统,MIT;官方原版不支持),见 10.1 |
| 推理速度 | R9700 / ROCm / 150K:121.1 tok/s |
| 评测环境 | AMD Radeon AI PRO R9700(32 GB)/ ROCm 7.13 |
能力边界:本地私有化部署、长文档分析(150K–256K)、视觉问答(需 mmproj)、结构化输出、中英双语(中文优先)、工具调用(关闭思考成功率 100%)。
4. 快速开始
⚠️ 本模型需要 2 个文件。缺视觉投影器则无法读图;对话模板已内嵌在主权重里,不需要另外准备。
MoziAier-9B-TQ-V1.0-Q2_0-PTQ1_0.gguf ← 主权重(必需,1.86 GiB,已内嵌 MoziAier 模板)
moziAier-9B-TQ-V3.5-mmproj-Q8_0.gguf ← 视觉投影器(必需,595 MB,必须 Q8_0)
| 平台 | 地址 |
|---|---|
| HuggingFace | chenyumo/MoziAier-9B-TQ |
| ModelScope | chenyumo/MoziAier-9B-TQ |
📁 两个文件都位于仓库的
V1.0/目录。
对话模板已内嵌:MoziAier 模板(26,492 字符)写在
tokenizer.chat_template里。不需要下载任何外部模板文件,也不需要传--chat-template-file。
把两个文件放进同一目录,执行 5.1 的命令,浏览器打开 http://localhost:8080 即可对话。客户端务必带 enable_thinking: false(见 6.2),否则 content 恒为空。
5. 启动命令
5.1 完整启动命令
llama-server \
--model MoziAier-9B-TQ-V1.0-Q2_0-PTQ1_0.gguf \
--mmproj moziAier-9B-TQ-V3.5-mmproj-Q8_0.gguf \
--ctx-size 153600 \
--cache-type-k q4_0 --cache-type-v q4_0 \
--flash-attn on --n-gpu-layers 999 --parallel 1 \
--batch-size 2048 --ubatch-size 512 --threads 28 \
--jinja --reasoning off \
--host 0.0.0.0 --port 8080 \
--temp 0.7 --top-p 0.8 --top-k 20 --min-p 0.0 \
--presence-penalty 1.5 --repeat-penalty 1.0 --repeat-last-n 64 \
--n-predict 65536
💡
--reasoning off与服务端思考开关有关。漏掉它、客户端又没传enable_thinking: false时,token 会全部用在思考上,正文为空(finish_reason=length),表现为「所有答题都失败」——容易被误判成模型退化。
5.2 Windows 单行形式
上面的 \ 是 Linux/macOS 的续行符,cmd 与 PowerShell 直接粘贴会报错。Windows 用一行:
llama-server --model MoziAier-9B-TQ-V1.0-Q2_0-PTQ1_0.gguf --mmproj moziAier-9B-TQ-V3.5-mmproj-Q8_0.gguf --ctx-size 153600 --cache-type-k q4_0 --cache-type-v q4_0 --flash-attn on --n-gpu-layers 999 --parallel 1 --batch-size 2048 --ubatch-size 512 --threads 28 --jinja --reasoning off --host 0.0.0.0 --port 8080 --temp 0.7 --top-p 0.8 --top-k 20 --min-p 0.0 --presence-penalty 1.5 --repeat-penalty 1.0 --repeat-last-n 64 --n-predict 65536
🔧
--threads按你的 CPU 物理核心数改(示例里的 28 是测试机数值,不是推荐值);不确定就删掉这个参数,llama.cpp 会自动选。
5.3 三个必须解释的参数
| 参数 | 值 | 为什么必须这么设 |
|---|---|---|
--parallel |
1 | 默认 4,会把上下文均分,150K 变成每槽 37K |
--cache-type-k/v |
q4_0 | KV cache 量化,显存占用约减半;f16 会撞显存单片上限 |
--flash-attn |
on | 长上下文必需;关闭后三值 kernel 不生效,输出退化成基座行为 |
5.4 按任务调上下文
| 场景 | --ctx-size |
|---|---|
| 日常对话(推荐默认) | 153600 |
| 复杂任务 / 整库分析 | 256000(需 8 GB 以上显存) |
| 最小可用 | 16384(低于此值无法加载系统提示) |
6. 推荐推理参数
6.1 三套出厂预设
按「温度光谱」设计三档。9B 三档一律关闭思考(实测开启会死循环,见 6.3)。
| 档位 | 上下文 | temperature | top_p | top_k | min_p | presence_penalty | 思考 |
|---|---|---|---|---|---|---|---|
| 办公 / 日常 | 150K | 0.7 | 0.80 | 20 | 0 | 1.5 | 关 |
| 灵感 / 创意 | 256K | 1.1 | 0.90 | 40 | 0.02 | 0.3 | 关 |
| 编程 / 严谨 | 256K | 0.4 | 0.90 | 20 | 0 | 0.3 | 关 |
通用参数三档一致:repeat_penalty 1.0 / repeat_last_n 64 / flash_attn on / kv_cache q4_0。
- 办公 = 上游 Prism Instruct 档,稳定输出,适合文档与问答
- 创意 = 在 Thinking 档基础上提 0.1(temp 1.1)+ top_k 40,但 top_p 收到 0.90(27B 是 0.95)—— 9B 不能开思考,更高发散度没有对等收益,反而容易跑偏
- 编程 = 比通常的 0.6 更严谨(0.4),适合代码与精确计算
6.2 客户端必须传的参数
{ "chat_template_kwargs": { "enable_thinking": false } }
这是最容易漏的一条。 不传时全部输出落在 reasoning_content,content 恒为空——所有依赖 content 的调用都会判 0 分。服务端参数不能替代它(--reasoning-budget 0 也不行)。
6.3 9B 必须关闭思考
| 配置 | Agent 150 题 | 现象 |
|---|---|---|
| 关闭(出厂默认) | 146/150 = 97.3% | 平均 2.3 轮,撞 8 轮 2 次,373s |
| 开启(medium) | 122/150 = 81.3% | 死循环,28 题正文全空,1845s(5 倍) |
原因:9B 规模不足以控制思考长度,max_tokens 给到 8000 也会被吃满、正文 0 字符,finish_reason=length。上游只给 27B 提供了 thinking_budget_tokens。
27B 结论相反:开思考 93.3% > 关思考 92.0%。两个模型不能套用同一套建议。
7. 量化格式对比
| 项 | 本版(PTQ1.0 三值) | Q4_K_M |
|---|---|---|
| 权重体积 | 1.86 GiB | 5.38 GB |
| 256K 上下文显存 | 6.73 GiB(Total Committed) | 13.59 GiB(Dedicated) |
| 跑满 150K 的最低显卡 | 6 GB | 12 GB(临界) |
| 跑满 256K 的最低显卡 | 8 GB | 16 GB 以上 |
| decode(生成) | 121.1 t/s(150K) | 8.19 t/s(100K) |
| 官方 llama.cpp 加载 | ❌ 需专用构建 | ✅ 直接支持 |
两种显存口径不同(Total Committed 含 reserved),不可逐位相减;速度来自不同批次与上下文档位,仅作量级参考。
三值容器的优势是体积与解码速度;Q4_K_M 的优势是生态成熟——可直接用官方 llama.cpp / Ollama / LM Studio 加载。
8. MTP 推测解码
本版不含 MTP —— 而且 9B 这条线实测表明它不该开。
本版权重使用 PTQ1.0 容器,不含 MTP 张量(无 blk.32.nextn.*),无法启用推测解码,也不需要配置相关参数。
实测(在带 MTP 层的 PQ2_0 容器上):关闭 121.1 tok/s → 开启 104.5 tok/s,−13.7%。9B 主模型本身够快,草稿解码的调度与验证开销占比过高,把接受率带来的收益全吃掉了。
与 27B 相反:27B 慢(47.3 → 61.2 tok/s,+29.4%,接受率 57.19%),省下的 decode 步数足够填平开销。原因很简单——主模型速度差 2.5 倍就是分水岭。
想在 9B 上自己试,需要带 MTP 张量的 9B 容器(本版没有),且 MTP 层精度必须 ≥ Q5(误差 ≤5.3%)。低于此阈值接受率直接归零,比不开还慢。MTP 层的完整精度谱与体积归因见 27B-TQ 说明书。
9. 显存配置建议
实测值,口径为 Windows「专用 GPU 内存」的 Total Committed(含 reserved),与任务管理器一致。按进程级 Dedicated Usage 读取时 150K 约 5.17 GiB,两种口径相差约 2%。选卡以 Total Committed 为准。
| 上下文 | 显存(Total Committed) | 最低显卡 |
|---|---|---|
| 150K(默认) | 5.26 GiB | 6 GB |
| 200K | 6.33 GiB | 8 GB |
| 256K(最大) | 6.73 GiB | 8 GB |
经验拟合:显存(GiB) ≈ 3.12 + 0.01444 × 上下文(K),每增加 50K 约多占 0.72 GiB。200K 实测点略高于拟合线,以实测为准。
| 显卡显存 | 可跑上下文 | 说明 |
|---|---|---|
| 6 GB | 150K | 最低门槛,余量约 0.7 GB(RTX 3060 6G / RX 6600) |
| 8 GB | 256K | 余量约 1.3 GB(RTX 4060 8G / RX 7600) |
| 12 GB 以上 | 256K | 无压力,可留视觉与并发余量 |
💡 显存不足时先降
--ctx-size,不要降--parallel(那会切分上下文)。
10. 部署方式
| 方式 | 支持 | 说明 |
|---|---|---|
| llama.cpp(三值专用构建) | ✅ 推荐 | 唯一支持的路径 |
| llama.cpp(官方原版) | ❌ | 无法加载 PTQ1_0 容器 |
| Ollama / LM Studio / Jan | ❌ | 内置引擎为官方 llama.cpp,不认三值容器 |
三值容器需要专门的推理后端。若工作流依赖 Ollama 或 LM Studio,需等其内置引擎支持该格式。
10.1 关于推理引擎
本模型权重是 GGUF 类型 PTQ1_0(type 143)——上游定义、标准 llama.cpp 不支持的私有扩展类型。
| 来源 | 说明 |
|---|---|
PrismML-Eng/llama.cpp(prism 分支) |
上游实现,MIT。实测数据即在该血统的 b10826 上取得。发布页 |
| MoziAier 品牌化构建 | 基于上游的 fork,仅重命名程序与文档,MIT,未改动内核逻辑 |
版本要求:PTQ1_0 支持自 b10658 起,建议 b10826 或更新。用不支持的构建加载可能不报错,但输出会退化成基座行为。
平台支持(只列实测跑通的组合):
| 系统 | 后端 | 状态 | 说明 |
|---|---|---|---|
| Windows 10 / 11 | AMD ROCm(HIP) | ✅ 已验证 | 256K 长上下文唯一可行 |
| Windows 10 / 11 | Vulkan | ✅ AMD 实测通过 | 100K–150K 稳定,256K 会崩 |
| Windows 10 / 11 | CPU | ✅ 已验证 | 速度慢,用于验收与兜底 |
| Windows + NVIDIA | CUDA 12.4 / 13.3 | ⚠️ 已下载校验,未实测 | 两台测试机都是 AMD |
| Linux / macOS | — | ⚠️ 本团队未构建 | 可按 prism 分支自建 |
Windows + AMD 是唯一由我们实测背书的组合,不承诺「全平台开箱即用」。重新分发该构建请随附其
LICENSE与归属声明(MIT 强制要求)。
10.2 搭配 MoziAier 桌面软件(推荐)
官方桌面客户端:下载 → 选模型 → 启动,不需要敲任何命令行。
| 能力 | 说明 |
|---|---|
| 一键部署 9B-TQ | 自动配好上下文、KV 量化、显存分档、并行度与推理引擎 |
| 专门适配 | 预设按 9B-TQ 实测显存曲线标定(150K / 256K 两档),默认关思考并透传 enable_thinking: false |
| 多模型统一管理 | 也支持挂载其他本地 GGUF 模型,同一界面切换、看显存、管自启 |
| 本地优先 | 对话与文件不出本机 |
⚠️ 别和 Ollama / LM Studio 混用——它们不认
PTQ1_0容器,加载会失败或输出退化。
11. 评测结果
自建评测,不是第三方榜单。 两套题库并行,环境 R9700 / ROCm / 150K,关闭思考(出厂默认)。
11.1 Agent 任务 150 题:97.3%
| 类别 | 得分 | 通过率 |
|---|---|---|
| MCP 调用 / 安全边界 / 数据库 CRUD / 综合任务 / 错误恢复 / 数据库结构 / 文件读取 / 文件搜索 | 各 15/15 | 100%(八类) |
| DSH 工具能力 | 14/15 | 93% |
| 文件写入 | 12/15 | 80% |
| 合计 | 146/150 | 97.3% |
平均 2.3 轮、撞 8 轮 2 次、总耗时 373s。两处不是满分:文件写入 80%(多步写文件偶有漏项)、DSH 工具 93%。
11.2 六维基础能力 120 题:86%
| 维度 | 得分 | 通过率 |
|---|---|---|
| 七维思考 | 20/20 | 100% |
| 身份认同 / Loop 纪律 | 各 18/20 | 90% |
| 检索诚实 | 17/20 | 85% |
| 工具认知 | 16/20 | 80% |
| 记忆诚实 | 14/20 | 70% |
| 合计 | 103/120 | 86% |
七维思考满分;记忆诚实 70% 是真实短板(不是判据问题):被问到不存在的历史记录时,有时会给出一个像是记录的回答,而不是明确说「查不到」。这是 9B 相对 27B 最明显的差距(27B 该项 95%)。
11.3 版本演进
| 六维版本 | 总分 | 关键变化 |
|---|---|---|
| 初版 | 72% | — |
| v3 | 82% | 工具认知 9 → 16 |
| v4 | 85% | 身份认同 15 → 18 |
| v5(本版) | 86% | 定稿 |
速度:R9700 / ROCm / 150K = 121.1 tok/s(关闭 MTP)。
12. 许可证
本模型以 Apache License 2.0 分发,可免费商用。
权重上游组件(Qwen3.5-9B、Ternary-Bonsai-2-9B)同为 Apache-2.0;推理引擎为 MIT(见 10.1)。归属见 NOTICE,修改声明见 MODIFICATIONS.md,全文见 LICENSE。
13. 联系方式
- HuggingFace:@chenyumo · GitHub:@chenyumo166
- 微博:@rimochen · 邮箱:263515@qq.com
Copyright (c) 2026 Chen Yumo / chenyumo166. Licensed under the Apache License, Version 2.0.
特别鸣谢
本模型站在两个开源团队的工作之上:
- 感谢 Qwen 团队(阿里巴巴) ——
Qwen3.5-9B是整条技术路线的起点。预训练底座的扎实程度决定了三值量化后还能剩多少能力;Apache-2.0 的开放许可让小团队也能在此基础上探索。 - 感谢 PrismML-Eng ——
Ternary-Bonsai-2-9B提供了可直接使用的三值基座,llama.cpp的prism分支让PTQ1_0容器真正跑得起来。本文档所有实测数据都来自这条血统。 - 感谢 ggml / llama.cpp 社区 —— MIT 许可下的本地推理地基。
我们与以上团队无隶属、赞助或背书关系,名称仅用于说明技术来源。若本模型对你有帮助,也请给这些上游项目一个 star。
上游许可声明 / Upstream License Notice
License: Apache License 2.0 — authoritative text: LICENSE. The weights are distributed under Apache-2.0 (upstream Qwen3.5-9B and Ternary-Bonsai-2-9B are Apache-2.0; MoziAier's own additions are likewise Apache-2.0). The inference engine (llama.cpp / Prism lineage) is MIT licensed and distributed separately. Attribution: NOTICE; modifications: MODIFICATIONS.md.