Bonsai 2:270亿参数只占约6GB,AI黑话怎么读?

Bonsai 2 科普:约 270 亿参数,FP16 理论约 54 GB,PTQ1_0 语言权重约 5.95 GB;运行还需缓存与其他内存

看到 Ternary Bonsai 2 27B,后面又跟着 FP16、1.75 bpw、GGUF、262K Context,很容易觉得自己正在读一张显卡电路图。

先记住一个比喻:大模型是一台有几百亿个“小旋钮”的数学机器。 训练负责调整旋钮;使用模型时,机器根据这些位置处理输入,一步步生成回答。

这串术语主要在回答三个问题:有多少个旋钮?每个旋钮的位置记录得多精细?机器工作时,还需要多大的桌面?把参数、精度和运行内存分开,就能看懂一大半本地模型介绍。

本文用 Ternary Bonsai 2 27B 串起这些概念。产品数据核对于 2026 年 9 月 19 日,依据 PrismML 的官方模型卡与运行说明;文中的算式是估算,性能数据是发布方报告,本文没有进行本机模型实测。

1. 模型、权重、参数:旋钮和旋钮的位置

一个语言模型的核心,是计算结构和训练好的数字。那些数字可能长这样:

0.183    -0.726    1.294    0.004    -0.532

结构规定“先算什么、后算什么”,数字决定每一步怎样影响结果。输入“中国的首都是”,模型会计算接下来各个文本片段出现的概率,再按生成规则逐步输出。模型也可能算错,或者给出看似流畅却不可靠的回答。

参数(Parameter) 是训练可以调整的数值位置。权重(Weight) 通常指参与计算的那些可学习数值。在本地模型的日常讨论里,两者经常近似混用;严格说,参数还可以包含偏置等其他可学习量。

借用旋钮比喻:参数是“可以调的旋钮”,权重值是“旋钮目前停在哪里”。知识和行为分散在大量参数及其相互作用中,不能找一个旋钮说“北京就存在这里”。

训练像反复做练习后调旋钮;推理(Inference) 则是用调好的机器处理新输入。普通聊天通常不会修改模型权重。对话中记得你的名字,主要是因为名字还在当前输入上下文里。

27B 到底有多大?

B 在模型名称中通常是 Billion,即十亿。

模型标注 约多少参数
1.7B 17 亿
7B 70 亿
14B 140 亿
27B 270 亿
70B 700 亿

27B 描述的是数量,不是下载大小,也不是智力分数。训练数据、训练方法、模型结构和后训练都会影响表现,参数更多不能单独证明回答更好。

PrismML 将 Bonsai 2 27B 的母模型列为 Qwen3.8-27B,总参数约 27.36B,其中包含视觉部分。因此,把“全模型参数总量”直接乘平均位宽,未必能精确还原“纯语言权重文件”的大小。官方 GGUF 模型卡

2. FP16、4bit、2bit:一个旋钮的位置占多少空间

同一个旋钮位置,可以记录为 0.72849365,也可以近似写成 0.73。记录方式越节省,通常就越难保留全部细节。

计算机用 bit,位 表示最基本的二进制信息。8 bit 等于 1 Byte,也就是 1 字节。注意这里的两个 B:27B 中的 B 是十亿,GB 中的 B 是字节。

FP16 是一种 16 位浮点数格式。它用总共 16 bit 表示一个数,包含符号、指数和有效数字。可以把它想成一种有限长度的科学计数法。“16 位”不等于“小数点后 16 位”。

如果用恰好 270 亿个权重做算术演示,每个都用 FP16 保存:

270 亿 × 16 bit ÷ 8
= 540 亿 Byte
≈ 54 GB

54 GB 主要来自大量数值的存储需求。它不能用来推算模型“背下了多少篇文章”。

INT8 是 8 位整数表示。Q4、Q5、Q8 等名字,则常被用来标识量化方案或精度档位。理解文件大小,可以先看一个简化表:

每个权重的位数 270 亿个权重的理论大小
16 bit 54 GB
8 bit 27 GB
4 bit 13.5 GB
2 bit 6.75 GB

这里使用十进制 GB,即 10 亿字节。系统工具还常用 GiB,1 GiB 等于 1,073,741,824 字节;同一文件用这两个单位显示,数字会不同。

表中只算了权重主体。真实文件还可能包含缩放因子、部分高精度参数和元数据。看到“4bit 模型”,不能要求下载文件恰好等于参数量乘 4 再除以 8。

3. 量化:给旋钮减少可选刻度

量化(Quantization) 是把数值映射到更有限的表示集合。一个直观但不完整的例子是:

原始: 0.127    0.493    0.817   -0.263
近似: 0.1      0.5      0.8     -0.3

真实模型量化会考虑分组、缩放、数值分布和误差,远比逐个保留一位小数复杂。这个例子只说明:表示更粗,存储成本可以更低,误差也随之产生。

减少误差很重要。一个小偏差进入很多层计算后,可能影响最终选择哪个词,也可能影响推理过程。低位宽能否保住能力,取决于模型和压缩方法,不能简单列出“8bit 永远安全、2bit 一定不能用”的等级表。

压缩后也不保证更快。权重更小,搬运量可能减少;但拆包和恢复计算需要额外工作。运行软件有没有专门优化,往往决定了节省的空间能否换成更低的延迟。

这类量化还不同于给模型文件打 ZIP:ZIP 解压后恢复原来的数据;有损量化改变了数值表示,目标是在允许的误差内完成计算。

4. Ternary 和 Scaling:三个刻度加一把比例尺

Binary 是二值,只有两种状态,例如 −1 和 +1。Ternary 是三值,常见状态为 −1、0、+1。给出零这个选项,可以让接近零的数有更合适的落点。

不过,把 −0.72、0、+0.69 直接写成 −1、0、+1,数值大小就变了。因此还要加一个 Scale,缩放因子

三值编码:  -1       0      +1
组内比例尺:0.7
还原近似值:-0.7     0      +0.7

Group-wise scaling,分组缩放,就是让一小组权重共享一把比例尺。比例尺也要占空间,但比每个数都保存完整精度节省得多。

Bonsai 2 当前模型卡采用每 128 个权重共享一个 FP16 缩放因子的描述,还包含量化前的分块 Hadamard 旋转。可以把旋转粗略想成换一个坐标方向来表示这批数字,方便压缩;运行时必须配合对应变换。三值加比例尺只是入门理解,完整方法并非把原模型逐个四舍五入。权重表示说明

三种状态为什么能少于 2 bit?

单独保存一个三值符号,直接用两位二进制最方便:四种编码里用掉三种即可。

把很多符号一起打包,就能减少浪费。例如 5 个三值符号共有 3⁵ = 243 种组合,而 8 bit 能表达 256 种组合。于是,5 个符号装进 8 bit,平均每个只用 1.6 bit。

一般地,大量三值符号的组合编码成本可以接近 log₂(3) ≈ 1.585 bit。这是编码空间的计算,不表示内存里真的有一颗“0.585 bit”的零件。

加上比例尺后,以每组 128 个权重计算:

三值编码成本 + 比例尺的平均成本
≈ 1.585 + 16 ÷ 128
≈ 1.710 bit / weight

bpw 就是 bits per weight,平均每个权重用了多少位。真正落盘还受打包方式、对齐和特殊参数影响,因此理论表示与文件体积需要分开看。

5. 5.95 GB 还能叫 27B:旋钮数量没有跟着文件缩小

压缩记录方式后,仍然可以保留约 270 亿个参数位置。文件小了,不能直接判断模型被删成了 3B。

用相机作辅助类比:一张照片保持相同像素数量,也能因为有损编码而变小。模型量化同样可能减少细节,但照片“看着差不多”不能证明模型在所有任务上表现相同。

官方当前区分了几种口径:

口径或封装 约平均位宽 语言部分大小
FP16 基线 16 bpw 54 GB
三值表示的理想口径 1.72 bpw 5.8 GB
GGUF 的 PTQ1_0 1.75 bpw 5.95 GB
GGUF 的 PQ2_0 2.13 bpw 7.21 GB

PTQ1_0 把三值符号紧密打包;PQ2_0 给每个符号留两位,解包的计算特点不同。两者各有适合的硬件,最小文件未必最快。官方封装与体积表

因此,早期介绍中的“约 1.76 bpw”不宜当成所有 Bonsai 2 文件的统一规格。下载时看完整文件名和当前模型卡,比只记一个宣传数字有用。

这里的约 5.9 GB 指语言部分。看图还涉及视觉组件,聊天还需要运行内存。27B 是参数规模,5.95 GB 是某种封装的文件大小,两者量的是不同东西。

6. Benchmark 和“98.2%”:把考试成绩读准确

Benchmark,基准测试,可以理解成给模型出的标准考卷。不同考卷测数学、代码、知识、视觉或工具调用,不同设置也会影响得分。

PrismML 当前模型卡给出的 14 项 thinking-mode 基准平均分是:FP16 参考模型 86.32,Bonsai 2 为 84.78。两者相除:

84.78 ÷ 86.32 × 100%
≈ 98.2%

这支持的说法是:在发布方这套测试与设置中,Bonsai 2 的平均分约为 FP16 参考模型的 98.2%。官方基准表

它不能换算成人类智商,也不能保证每个问题只下降 1.8%。综合平均值还可能掩盖单项差异:数学接近原版,不代表长文阅读或工具调用也接近。

如果你主要让模型改中文文案,自己的文章就是更贴近用途的考卷。如果用它查代码问题,就该拿真实代码和已知错误试。论文分数提供比较线索,日常任务决定是否合用。

7. GGUF、llama.cpp、MLX:文件和运行软件要配套

有一份模型文件,还需要软件读取它、安排计算并调用硬件。

GGUF 是模型文件格式。 文件里可以装权重张量和相关元数据,例如结构、分词器与量化信息。类比视频中的 MP4,它说明包装方式,不能保证每个播放器都支持包装里面的每一种编码。GGUF 格式规范

llama.cpp 是模型推理软件。 它负责把兼容的模型跑起来,可以在不同硬件后端工作。于是有这样一条链路:

模型文件(GGUF)
  → 兼容的运行软件(如 llama.cpp)
  → CPU / GPU
  → 逐步生成回答

MLX 是机器学习框架。 它出自 Apple 机器学习研究团队,Apple Silicon 是其重要使用场景。在这条路线中,模型常用 safetensors 等文件配合配置与加载代码,因此“GGUF 和 MLX”并不是两个同级的文件格式。MLX 官方项目

Bonsai 2 对软件兼容性有额外要求。截至本文核对时,GGUF 文件需要 PrismML 适配的 llama.cpp;MLX 包也要求配套加载代码处理模型变换。只有程序能读到文件,不能证明它算对了。运行项目MLX 加载说明

MLX 包的大小也不能照搬“5.9 GB”:当前模型卡列出语言部分约 7.67 GB,加上视觉部分后磁盘文件约 8.60 GB。框架的分组存储方式不同,可以让相同三值权重占用不同空间。MLX 封装说明

8. 显存、KV Cache、Activation:机器还需要工作台

假设 GPU 是厨师,显存(VRAM) 就是它面前的操作台。厨房里能放下一本厚菜谱,不代表已经有空间摆锅、切菜和装盘。

模型推理主要涉及几类内存:

名词 工作台上的比喻 实际保存什么
Weight,权重 固定的菜谱 已训练参数的表示
KV Cache,键值缓存 随手备忘 注意力计算中可复用的历史键和值
Activation,激活值 正在处理的食材 当前计算产生的中间结果
运行框架开销 厨具与周转空间 缓冲区、调度与其他运行数据

KV Cache 的“记忆”比喻尤其容易误导:它通常不是保存一份聊天原文,更不是把聊天内容训练进模型。它缓存已经算出的中间表示,让后续生成可以复用,少做重复计算。Hugging Face 缓存解释

估算运行需求时,可以先写下:

权重驻留 + 上下文缓存与状态 + 临时计算数据 + 框架开销

各部分分配在系统内存还是显存,要看软件和卸载设置。能够加载文件、能够生成短回答、能够流畅处理长文档,是三种不同的使用状态。

Context 越长,为什么越吃内存?

Token 是分词器把文本转换成的处理单位,可以对应一个词、词的一部分、一个字符或其他片段。它不是固定意义上的一个汉字;同一段文本在不同分词器中可能有不同长度。

Context,上下文窗口,表示模型一次处理时允许容纳的 token 范围。提示词、历史对话、工具返回和新生成内容通常都要考虑进去。标注 262K tokens,不等于 26 万个汉字,也不保证每一处细节都能被准确利用。

普通全注意力层需要为更多 token 保留 KV,因此上下文变长通常会增加缓存。混合注意力模型还包含其他状态,不能把某一个模型的每 token 用量套到全部模型上。

Bonsai 官方运行说明给出上限 262,144 tokens,并用 FP16 KV 约 64 KiB/token 做估算。按这个口径,100,000 tokens 约需 6.10 GiB;若 100K 指 100 × 1024,则是 6.25 GiB,接近文档写的约 6.3 GiB。官方上下文说明

把 5.95 GB 权重换算为约 5.54 GiB,再加 100,000 tokens 的约 6.10 GiB KV,已经约 11.64 GiB。这个加法还没有纳入其他运行开销,不能当成设备内存的购买下限。

软件也可能在启动时按配置的上下文容量预分配缓存。所以“刚开聊天就占了很多内存”,并不一定是泄漏。

9. tok/s、内存带宽、统一内存:装得下之后,还要看快不快

tok/s 是 tokens per second,每秒处理或生成多少 token。比较数字时,要先看测的是哪个阶段。

Prefill,预填充,是读入并处理提示词。Decode,解码生成,是随后逐步产出 token。读一份长文档可能花很久,但开始回答后出字很快;一个生成速度数字无法描述这两段体验。

单人、小批量生成时,程序往往需要反复读取大量权重。算力够用但数据搬得慢,就会受到内存带宽限制。带宽可以想成仓库到工作台之间的运输能力。

如果每步要读约 6 GB 数据、有效带宽是 120 GB/s,极度简化的搬运预算就是每秒约 20 步。这个算式只帮助理解瓶颈,不是测速预测:缓存访问、其他运算、量化解包和硬件利用率都会改变结果。

Mac 上常说的 Unified Memory,统一内存,指 CPU、GPU 等组件共享内存池。MLX 可利用共享内存,减少设备间的数据搬运。MLX 的统一内存说明

共享不等于独占。24 GB 统一内存还要分给系统和其他应用,可供模型使用的部分也受运行环境限制。模型进程的占用,不能直接等同于整台机器应配备的容量。

所以,看到某台机器的 tok/s,至少要连着看硬件、封装格式、上下文长度和测试阶段。Bonsai 文件变小提供了机会,具体速度仍由整条运行链路决定。

10. 再读一次模型名称,就知道该检查什么

现在再看这串介绍:

Ternary-Bonsai-2-27B
GGUF / PTQ1_0
约 1.75 bpw / 5.95 GB
262K Context / 98.2%

它描述了一组彼此相关、但不能互相替代的指标:

看到的名词 可以怎样理解
27B 参数规模约 270 亿
FP16 / 4bit / 2bit 数值表示精度或量化档位
Ternary 权重主体采用三值表示
Scaling 用共享比例尺还原数值大小
bpw 平均每个权重的存储位数
GGUF / PTQ1_0 外层文件格式 / 里面的具体封装方式
llama.cpp / MLX 运行软件 / 机器学习框架
VRAM / Unified Memory 显存 / 共享内存体系
KV Cache / Activation 历史计算缓存 / 当前中间结果
Token / Context 文本处理单位 / 上下文容量
tok/s 特定测试条件下每秒处理或生成的 token 数
Benchmark / 98.2% 测试方法 / 发布方报告的相对平均分

准备下载时,按这个顺序检查就够了:找到完整文件名和配套软件;确认权重大小;给准备使用的上下文留出空间;最后拿自己的任务检查速度和回答质量。

Bonsai 2 提供了一个很具体的例子:约 270 亿个“小旋钮”,可以用不同精度和封装保存成不同大小的文件。判断自己的电脑能不能用,还要把工作台一起算进去。

C code80.ai · AI 编码 API 聚合 Claude / GPT 多模型统一接入,稳定不限速,按量计费,几行配置接入 Claude Code。 了解一下 ›

抢沙发

评论前必须登录!

立即登录   注册