卡尺卡得上的和卡不进去的：三行视觉塔，外加 MoE 要分段

前几天我一直想用一句话讲清"参数量怎么手算"，画了张图才说明白。

图里是两座砖塔加一柜子抽屉。两座砖塔整整齐齐，一层层码上去，卡尺随便卡——那就是 dense 模型：层数一样、宽度一样、每层结构一样，一个式子从头卡到尾。那柜子抽屉就不行了，三百多个小格子，有的开着一半，有的压根没装东西，你拿卡尺去卡"这个柜子多大"，卡出来的数跟你实际能用的东西完全是两码事。那就是 MoE。

先把那一个式子摆出来

一层 Transformer（注意力 + 前馈，不含 embedding）的参数量：

≈ (4 + 2m) · L · d²

• d 是隐藏层宽度
• L 是层数
• m 是前馈中间层的宽度是 d 的几倍（常见 4 倍，也有 3 倍、8/3 倍）

4 是注意力的四块矩阵（q、k、v、o），2m 是前馈的两块（升维、降维）。norm 的缩放和偏置、各处的 bias 都是零头，手算时先扔掉。

我自己定的规矩是：只记式子，不记数字。数字会过期，式子不会。

三行视觉塔的账

第一行是我最满意的一次。84.9M 是纯式子的结果，真配置 86.1M，差的 1.14M 我把它一项项挖出来了：

• patch embed：3×16×16=768 维投影到 768，589,824 + 768 = 0.59M
• 位置嵌入：14×14=196 个块 + 1 个 class = 197 行，197×768 = 0.15M
• 输出投影：768→512，393,216 + 512 = 0.39M

加起来 1,135,616。分毫不差。那 1.2M 的缺口不是我算错了，是式子本来就不管这些门口摆设。

第二行提醒我一件事：厂商名字里的参数量是档位，不是规格。so400m 按式子算 430M，加上零头 432M 左右，人家写 400m。你要是拿"400M"去反推层数宽度，能推出个四不像。

第三行是我这次唯一没核上的。我去翻了 Qwen2.5-VL 技术报告的正文，架构写得很细：原生动态分辨率的 ViT、SwiGLU 前馈、RMSNorm、窗口注意力。但通篇没有视觉塔的参数量。外面流传的"约 670M"是从 HF config 反推的，不是我查到的。所以这张表里它只能标"推算"。查不到就写查不到，比硬凑一个数强。

MoE 得把账分两段算

回到那个柜子。MoE 的每层结构是：一份注意力 + 一堆专家前馈 + 一个路由器。所以式子要拆开：

每层 ≈ d² · (4 + 2m·E) + d·E

E 是专家总数，d·E 是路由器那点小钱（每层就一个 d×E 的矩阵）。关键是 E 取多少——这里就是大多数人（包括之前的我）算错的地方：

• 算存储/参数量：E = 全部专家数。 专家是实打实存在内存里的，8 个就得占 8 份地方。
• 算前向计算量：E = 每次激活的专家数。 一个 token 只走其中 2 个，另外 6 个这一层是空转的。

两个数差好几倍，但都叫"参数量"，混着用就乱。

名字里"30B-A3B"这种写法就是在同时报这两个数，前一个是柜子占多大地方，后一次你实际开了几格抽屉。看名字的时候顺手把这两栏分开读，能省很多误会。

式子卡不到的地方

说到底，(4+2m)·L·d² 只负责砖塔部分。剩下这些它一律不管：

1. 门口摆设：patch embed、位置嵌入、输出投影、跨模态投影层。加起来常常 1%~2%，但在小模型上很显眼（ViT-B/16 上就是那 1.14M）。
2. 词表和输出头：vocab × d，再乘一份 lm_head。多语言大词表这块能吃掉好几 B，跟层数宽度一点关系都没有。
3. MoE 的柜门：路由器、共享专家（有些模型有专门的 shared expert）、专家间的 load-balancing 参数。
4. 动态的东西：动态分辨率的视觉塔，位置编码是 RoPE 一类"算出来"的，几乎不占参数——这类模型参数密度和低分辨率模型完全不一样，不能拿老经验套。

所以手算的正确用法不是"算出一个精确数"，是快速判断量级、并且知道误差该落在哪。算完 84.9M 我就能预判真配置在 86M 附近，偏差不可能超过 2%；算完 MoE 我知道总参和激活差 3~14 倍，看到"30B-A3B"不会被吓到。

卡尺能卡住的，是码得整齐的那部分。剩下卡不进去的，你得知道它在哪个抽屉里。