8B模型压成3.88GB,一份文件喂进数据中心、游戏显卡和苹果芯片

Fermion Research 发布的 Neutrino-1 8B,压缩后只有 3.88GB。这个基于 Qwen3-8B 的模型用了一套自研的专有三值权重格式,官方说同一份文件不用转换,能直接跑在数据中心 GPU、8GB 显卡和苹果芯片设备上。

要提一句:官方说的"苹果芯片设备",测试对象是 M5 MacBook 和 M5 CPU,不是 iPhone。这次能通吃的,是电脑和服务器,不是手机。

对手里攥着一张 8GB 显卡、想在本地跑大模型的开发者,这不是纯粹的技术八卦,是能不能省一次采购的具体问题。真正该细看的,是这份压缩靠什么换来,省下的空间和速度又是拿什么抵押的。

文件里装了什么,省的是哪一块

8.19B 参数里,6.95B 是 252 层 transformer 线性权重,用 Fermion 自家的专有三值格式编码。官方说这部分比 fp16 小八倍,但这个"八倍"只对这 252 层生效,不是整份文件缩小八倍。

词嵌入没有跟着一起压,还是 int8,占文件字节数的 32.1%,大约 1.24GB。它是整份文件里唯一没被三值格式覆盖的大块,也是压缩比打折的原因。

容器一共 3,875,404,812 字节,约 3.88GB。加上 4k 上下文的 KV 缓存,总占用约 4.48GB,刚好卡在 8GB 显卡的天花板上——上下文再长一点,这张卡就未必够用。

速度和跑分放在一起看:

跑分方面,MMLU 72.1,IFEval instruction-strict 80.2,GSM8K 53.4,不算亮眼但说得过去。这些数字和上面的速度、体积一样,全部来自 Fermion 自己的模型卡,目前没有第三方复测。

更关键的缺口是横向对比。官方没有给出这份专有格式跟常见的 Qwen3-8B GGUF Q4/Q8、AWQ 或 GPTQ 量化版本的直接比较。3.88GB、30 出头的 tok/s,听着不差,但到底比社区已有的 4-bit 方案快多少、准多少,现在只能靠猜。

推测解码能省多少,看任务

Neutrino-1 配了一个 0.6B 的草稿模型做无损推测解码。草稿模型先猜一串 token,8B 模型一次性核验,猜中的直接采用,输出和普通贪心解码逐字一致——这不是靠压缩质量换来的加速,是纯粹的工程手段。

但加速幅度看任务类型。H100 上,数数、列表这类规则性强的任务能到 1.93 倍;代码生成只有 1.07 倍,基本等于没加速。

这张表对写代码的开发者用处不大。真金白银的对象是做批量结构化生成的团队——报表、列表、格式化输出。用什么任务测,决定这张加速表对你有没有意义。

权重开放,工具链不开放——这对谁最重要

权重协议是 Apache-2.0,底座 Qwen3-8B 也是 Apache-2.0,pip 包同样开放。看起来没有申请门槛,没有等待名单。

但真正能跑起来,靠的是三样不在协议里的东西:自家的三值编码格式、给 CUDA 和 Metal 写的定制内核,还有一个专门维护的 llama.cpp 分叉。协议开放的是这份权重文件的使用和再分发权,没开放的是理解和替换这套格式的能力。

权重是开的,门是自己家的锁。

这像是重演一次电力行业的标准战:爱迪生的直流电和威斯汀豪斯的交流电,当年拼的不是发电效率,是谁的插座能装进别人家。这个类比不完全一样——电力标准关乎能不能通电,模型格式关乎好不好换引擎,后果轻得多。但逻辑相通:效率优势之外,还藏着一道抬高别人迁移成本的墙。

对两类人,现实影响很具体:

另外要提一个日期问题。模型卡标注的发布和测试时间是 2026 年 7 月。如果正式发布时这个日期还没到,上面这些速度和跑分数字的可用状态需要重新核实,不能直接当成已经发生的既定事实。

回到开头那个问题:这份文件到底通吃到什么程度?数据中心和 8GB 显卡这两头,证据扎实。苹果芯片这头,目前只验证到 Mac,没有手机。效率红利是真的,但真正决定你能不能带着模型换地方跑的,不是文件多小,是你愿不愿意跟着 Fermion 自己的工具链走。接下来该盯的,是社区有没有人拿现成的 GGUF Q4/Q8 版本正面比一次,以及这个 llama.cpp 分叉能不能长期跟上主线更新。