MODEL POSITIONING
这个模型解决什么问题？
模型能力方面，Neutrino-8B 是以 Qwen3-8B 为基座、经 Fermion Research 三元 QAT 与分阶段后训练得到的 8B 文本生成模型，模型卡声明其训练中包含结构化 JSON 与工具调用能力，并给出 GSM8K、IFEval、BFCL、MMLU-Redux 等非思考模式基准。量化仓库方面，仓库只发布这一个 8B SKU，主交付物为约 3.9 GB 的 .bin TRTC v4 容器，外加 tv4z 编码传输文件以及需自编译 fermion-fv5 分叉才能加载的 GGUF 包。运行工具方面，提供 pip 引擎 fermion-research、fermion-fv5 GGUF 分叉、Apple Silicon MLX 包与随仓的 fermion-run 预编译原生二进制四种入口。
更适合谁
- 需要在 CPU 或 8 GB 显存显卡上离线运行 8B 对话模型的用户
- 需要结构化 JSON 输出与工具调用能力的中型本地助手
- 在 Apple Silicon 上希望以 MLX 或预编译原生二进制推理的开发者
典型使用场景
- 离线对话助理与长文生成
- 工具调用、结构化 JSON 抽取与函数代理
- GSM8K 等数学与逻辑题的一次性离线推理
- 与 Neutrino-0.6B draft 配对的 CPU 推测解码加速
SOURCE-BASED CAPABILITIES
模型卡透露的核心特点
三元压缩
每个线性层只占亚 2 比特，6.95B 三元权重 + int8 嵌入合计约 3.9 GB
结构化输出与工具调用
训练过的全回复无围栏 JSON 与函数调用，BFCL v3 13 子集宏分 65.31
数学与推理覆盖
GSM8K 灵活抽取 51.00、固定格式 49.33，MMLU-Redux 67.84、IFEval 提示严格 73.17
多入口部署
pip 引擎、fermion-fv5 GGUF 分叉、MLX 与预编译原生二进制可任选其一
内置推测解码
与 Neutrino-0.6B 配对可在 Linux x86-64 CPU 上获得约 2.23 倍速度提升
按当前权重估算的硬件准备
- 现有 GGUF 文件中，最低显存估算约 4.5 GB
- 为上下文缓存、系统进程和并发请求预留额外内存，不要只按模型文件大小配置设备。
量化版本怎么选
- 仓库主交付物本身就是三元（亚 2 比特）量化版，整模型约 3.9 GB
- GGUF 文件采用自研 FV5 张量类型，体积约 4.1 GB，必须用 Fermion 发布的 llama.cpp 分叉读取
- 不应用 stock llama.cpp、ollama、LM Studio 直接加载该 GGUF，否则 FV5 张量类型不被识别
GGUF VARIANTS
量化版本与硬件要求
显存与内存数值均按权重文件体积估算，未做设备实测。多模态还需要配套投影文件并额外占用内存；分卷容量按全部分卷合计，下载时需获取完整文件组。
| 量化 | 权重合计 | 估算加载显存 | 建议显存 | 建议内存 | 来源 |
|---|---|---|---|---|---|
| GGUF | 3.8 GB | 4.5 GB | 5.5 GB | 8 GB | 下载文件 ↗ |
HARDWARE MATCH
哪些显卡或设备更适合运行？
按当前最小量化文件估算，至少需要 4.5GB 显存；如果希望为运行框架和上下文保留余量，优先参考推荐显存 5.5GB。
阅读 8GB 显存选型指南 →可以怎样运行
- pip install fermion-research 走随仓 fermion-run 原生二进制，是模型卡标注的最快路径
- 编译 fermionresearch/llama.cpp 的 fermion-fv5 分支，加载 gguf/neutrino-8b-fv5.gguf
- macOS / Apple Silicon 上从 mlx/ 目录运行 MLX 包
- Python 中先 import fermion 注册 trtc_v4，再用 transformers AutoModelForCausalLM 加载
采用前要知道的限制
- GGUF 仅支持 Fermion 自家 llama.cpp 分叉，普通 ollama 与 LM Studio 暂未纳入 FV5
- 模型卡所有基准与对比均为非思考模式，思考设置未重新扫参
- 非贪心模式下 PyTorch CUDA 路径与原生命令流不一定逐 token 一致
- macOS arm64 上的原生推测解码目前只验证正确性，尚未给出加速倍率