挑模型、算显存、看发布资料时，几乎都会碰到「70B」「几百 B」这种写法。有人把它当模型聪明程度的尺子，有人拿它直接算显存，结果对不上。这篇不评价哪个模型好，只解决一件事：这个数字是怎么数出来的，统计口径有哪几种，你看到不同来源对不上时该按什么顺序核对。
看模型资料、算显存、和人聊选型，几乎都会碰到「70B」「几百 B」这种写法。有人把它当聪明程度的尺子，有人拿它直接估显卡够不够，结果一跑就爆显存。这个数字本身没那么玄，它就是一个统计口径问题：数的是哪部分权重、按什么结构推出来的、和激活参数是不是一回事。把口径对齐了，对不上号的数字基本都能解释清楚。
下面按四步走：先对齐单位，再看这个数是怎么推出来的，然后列常见口径坑和核对顺序，最后说它能用来干什么、什么时候别用。每一步都给能直接上手的动作，不是让你记住结论。
先对齐单位：B 到底指什么、数的是哪部分
B 是 billion 的缩写，也就是十亿。写「70B」意思是这个模型有大约七百亿个可学习参数。它不表示显存占用，不表示训练用了多少 token，也不等于权重文件有多大——文件大小还跟存储精度有关。这三件事经常被人混着说，换算之前先把它们拆开。
- 总参数
- 模型所有层权重矩阵里的数值全部加起来，包含嵌入层和输出层，MoE 结构下是所有专家之和
- 非嵌入参数
- 把词嵌入层和输出头去掉之后的参数，小模型上这个数会比总参数小一截
- 激活参数
- 处理一个 token 时实际参与计算的参数，MoE 模型里明显小于总参数，稠密模型里两者相等
被数进去的通常是权重矩阵里的可学习数值，外加偏置、归一化层参数这类零碎项。中间激活值、注意力缓存、运行时张量都不算在参数量里——它们占显存，但不进这个数。所以别拿参数量直接折算显存，中间还差着精度、KV 缓存和框架开销几层。
- 看到资料先找一句话：它报的是总参数、非嵌入参数还是激活参数；
- 稠密模型三个数差得不多，MoE 模型总参数和激活参数能差出好几倍，别混着比；
- 同一个模型不同来源数字对不上，先怀疑口径，再怀疑是不是换了版本；
- 换算显存时按激活参数、精度、并发一起算，别只看 B 数。
数字从哪来：按架构配置推，不是拆开一个个数
没有人真去数七百亿个数字。标准做法是读模型的结构配置——层数、隐藏维度、注意力头数、前馈层宽度、词表大小、专家个数——按每层的矩阵形状做行乘列，再乘层数相加起来。开源模型这些配置就在仓库里，能一条条对着算。
- 定位结构配置在模型仓库里找结构配置文件，记下层数、隐藏维度、注意力头数、前馈中间维度、词表大小；MoE 还要记专家数和每 token 激活专家数。
- 逐层算矩阵注意力部分把 Q、K、V、输出的权重矩阵各自行数乘列数；前馈部分按中间维度做两到三个大矩阵相乘；每层加起来得到单层参数量。
- 乘层数加嵌入层单层参数量乘层数，再加上词表大小乘隐藏维度的嵌入矩阵和输出层。MoE 要把所有专家矩阵都算进总参数，激活参数只算实际路由到的那几个。
- 用权重文件反推复核下载前先看权重文件个数和单文件大小，用总字节数除以数据类型位宽（例如按半精度折算）反推参数量，和宣称值对一对，差太多说明口径不同或者自己有项漏算。
常见口径坑：为什么你算出来的数和官方对不上
自己算一遍和官方数字差一截，八成不是算错，是口径不同。下面这张表把常见的错位列出来，对上之后差值通常就解释得通了。换算和测算的具体算法不用记，到 /models/deploy 看当时的换算口径。
| 你看到的数字 | 可能的真实含义 | 容易导致的误判 |
|---|---|---|
| 几百 B 的 MoE 模型 | 总参数含全部专家 | 按总参数估显存，结果严重高估需求 |
| 同一个模型的激活参数 | 单 token 实际参与计算的量 | 拿它当总参数去和稠密模型比规模 |
| 标注为非嵌入参数 | 已去掉词嵌入和输出层 | 小模型上低估了总体量 |
| 量化版本体积变小 | 存储精度降了，参数量没变 | 以为「体积小＝参数少」 |
| 旧版本号下的 B 数 | 结构可能已调整 | 直接套到新模型上做判断 |
还有两个容易忽略的点。一是词表：中文或多语种模型的词表通常更大，嵌入层在总参数里的占比不低，小模型上尤其明显，同规模不同词表的两模型参数会差出可感知的一截。二是量化：它改的是每个权重存几位，参数量一个字没少，只是文件小了、算得快了，别把这两件事混谈。
这个数该怎么用、什么时候不该用
参数量最靠谱的用途是粗筛硬件门槛：先按参数量划一个显存区间，再结合量化档位、上下文长度和并发需求往里收敛。具体换算别自己硬套，到 /tools 用站内换算工具对一遍当时的算法，比拍脑袋准。
- 判断本地能不能跑：参数量是第一关，还要看上下文长度、是否 MoE、推理框架支不支持；
- 看数量级找同类：找同规模模型做对照时可以，但别把它当能力排序；
- 同等参数下训练数据、训练阶段、架构差异很大，参数量大不代表任务效果好；
- 选型时把 /models 的模型资料和 /benchmarks 的评测放一起看，别只盯 B 数；
- 决定长期用哪个服务前，可信度和价格波动到 /price-watch 核对当时的数字。
什么时候这个数不该用：做效果横向对比时，它几乎不提供有效信息；跨架构比较（稠密对 MoE）时，总参数和激活参数各说各话，硬比没意义；评估部署成本时，只看参数量会漏掉 KV 缓存和并发的影响。这几种情况下，把它当参考线而不是结论。
B 数是一个口径，不是一把尺子——先问它数了什么，再谈它能拿来干什么。下一步拿你最近在看的那个模型，先去资料页确认它报的是总参数还是激活参数，再用站内换算工具对一遍显存估算，两个数能对上，后面的判断才站得住。→
常见问题
参数越多模型就越聪明吗？
不一定。参数量只说明模型容量上限，实际效果取决于训练数据质量、训练阶段和架构设计。同参数规模的两个模型，任务表现可能差得很远。把它当硬件门槛的粗筛条件更合适，能力判断还是要看具体任务上的评测结果。
为什么同一个模型，不同地方写的参数量不一样？
多半是统计口径不同：有的报总参数，有的报去掉嵌入层后的参数，MoE 模型还可能报激活参数。另外，公布数字和实际权重文件也可能有细微差别。看到对不上时，先确认对方写的是哪一种口径，再决定能不能直接比。
用参数量估算显存，为什么总是估不准？
参数量只决定权重部分，显存还要加上 KV 缓存、中间激活和框架开销。按精度折算时，参数量乘每个参数的字节数才是权重体积。实际部署还要留余量，量化档位和上下文长度都会影响结果，建议按测算页的方法把这几项分开算。
